システム内製化における新規開発の勘所
自己紹介
岡本浩治 (38)
プログラマー18年生
https://motchang.com/resume.pdf
企業の特徴
学習・企業研修領域
IT企業ではない
2017年くらいからITを内製で開発していく機運が高まっていた
ジョイン
社内で前年から構築しているプラットフォームの開発エンジニアとして
キーワード
Rails
React / SPA
toC, toB 両方の経験あり
新規開発に強い
プロジェクトの背景
これまで社内の業務を支えてきた LMS (Leening Manageme Service) は社外のパッケージソフトウェア（ASPサービス）
2018年いっぱいで、このサービスがクローズすることに
次期システムに移行するか、内製化に踏み切るのか
プロジェクトの目的
社内サービスを運用するためのシステムがほしい
社外開発だと思い通りのスピードで開発成果が上がって来ない
社外サービスにしてしまうと、ユーザーの行動記録などが貯められない
内製するにあたって、これまでのLMS機能に加えて、ユーザー側のもつ研修コンテンツも配信できるシステムにしたい
プロジェクトの立ち上げ
プロダクトのビジョン等はしっかり整っていたものの、スケジュールやスコープの設定がなかった
マイルストーンを設定
三ヶ月後に小さいゴールを設定
最初のゴールは、シンプルな業務が一周できるところまで
業務のサイクルをまわしてフィードバックが得られる状態を最速で組む
人員（4名）
PO
ドメインエキスパート
自分
もう1名 Rails エンジニア
ドメインモデルの抽出/テーブル設計
社内で利用していた二つのソフトウェアからモデルを取り出す作業
実際使ってみる
チュートリアルなどが発生した場合など、適宜スクリーンショットをとりながら
ユーザーマニュアルから言葉を取り出して Wiki 形式にまとめる
対象ソフトウェアの紹介本から取り扱っている概念の言葉を取り出す
https://images-fe.ssl-images-amazon.com/images/I/51WpUlWVxWL.jpg
Key Feature
マルチテナント
さまざまな企業のデータを一箇所で取り扱う必要がある
様々な企業のデータはそれぞれ独立していなくてはいけない
頑張ってライブラリを探した
ファイルのアップロードとダウンロードが多い
アップロードしたファイルも全て秘匿データなので、アクセス権など最大の配慮をする必要があった
こちらは有名かつ枯れたライブラリがあるので悩まず選定完了
MVPの作成
Rails
デザイナーが未アサインだったのでサーバーサイド（自分）がやれる範囲でやった
管理画面は無料テンプレート
ユーザー側画面は Twitter Bootstrap で適当に
再出発
ゴールの再設定
別のプロダクトへの機能追加という方針が決定されたので、乗り入れるプロダクトの機能分析をおこなった
使えるものの再利用
マルチテナントライブラリや、シングルサインオン機能などは一部再利用可能だった
社内の研修業務を回すという役割が強固になった
開発の優先度を再考することになった
ここで5分くらいだと良さそう
ゴールの再設定
スケジュールの設定
2018年12月にプロトタイプのリリース
スコープの設定
"2018年12月に開発が完了できる機能" を主眼
十分なQA期間
2019年12月にプロトタイプのリリーススケジュールを置いたので、開発期間のバッファとQA期間として1ヶ月を用
2018年10月末に開発終了する機能までを１次リリースの範囲とした
本格的な開発の始まり
"付加価値" と戦う
ビジネスサイドの人がよく使いがちな「付加価値」という概念は UNIX 哲学と食い合わせがよくない
乗り入れ先のプロダクトと、新規追加機能とでドメインの侵食が発生しないような設計をこころがけた
一度プロジェクトが息継ぎをしたことによって、人的リソースがしっかり配置された
デザイナー
フロントエンドエンジニア
スクラムへの挑戦
プロジェクト前半では「スクラムの要素を取り入れた開発」だったが、仕切り直し後はスクラムに全力で則った開発に
１スプリント１週間
デイリースタンドアップ
Trello 導入
ストーリーベースの開発
ストーリー見積もり
カンバン
スプリント・レトロスペクティブ
MVPを意識して作る
プロジェクトが新しくなると企画をする人がどうしても色気を出して新機能を実装したくなってっしまう
色気を感じたら、すぐに対処することが必要
リリース後に実装する場合と、今実装することでメリットに差があるのか
その機能が直近のリリースまでに含まれなくても問題ない場合は、優先度を下げてもらう積極的な働きかけ
スクラムイベントのうち「見積もり」の時に不要そうな機能が出て来たら優先度を下げてもらっていた
"最小限" に含まれない機能
画面で動的に要素を入れ替えられる機能
一括でデータを操作する機能
など
増員させない
プロダクト開発の序盤で人を追加しても開発スピードは上がらない
Ruby on Rails というフレームワークも少人数で高速開発をおこなうもの
作らないといけない機能がたくさんあって増員したくなる気持ちはわかる
人月の神話の頃からこの問題を解決するものはなく、MVPを速いスピードで粛々と作るしかない
2018年現在、IT業界は売り手市場になっていて中途採用オーダーを出したところで、オーダー通りの人材が思うスピードで採用できるのはほぼ奇跡に近い
QA期間
小規模案件、かつ柔軟な運用に対応していただける顧客を探し、トライアルとして実際に使っていただいた
この期間で、社内のオペレーションの方々にも新規システムに慣れていただく必要がある
新たに見えた問題として、マニュアルへの依存が見つかった
よくできたマニュアルはメンテナンスのコストが高い
マニュアルが不要なUIを構築していく必要がある
最小限の機能しか実装していないため、導入も問題なく終わり、以降は要望ベースでの開発に移ることができる
本当にサービスのユーザーが求めている機能の開発
まとめ
システムリプレースプロジェクトを成功裏におさめる勘所
"夢" を膨らませない
仕様を膨らませない
可能なら既存機能で使われていない機能を減らす
人を膨らませない
人を増やしても全体の開発スピードは上がらない