この記事は Akerun - Qiita Advent Calendar 2024 - Qiita の 3 日目の記事です。
こんにちは、 AkiAbe - Qiita です。ご無沙汰しています。
フォトシンスに入って 5 年目となりました。そして VPoE ロールをやらせてもらって 2 年が経とうとしています。
時間の経つのは早いですね。
この 2 年で開発に関するプロセスやフォーマットなどをルール化し、運用を立て付けてきました。
2 年やってようやく板についてきて、ある程度サイクルが回る状態ができました。
フォトシンスとしてどのような開発フローや開発プロジェクトの管理をしているかをご紹介できればと思います。
プロダクト開発のプロセス
フォトシンスではプロダクト開発が始まってリリースされるまでに 3 つのフェーズ/ゲートを設けています。
各フェーズではたくさんの活動がありますが、今回は割愛します。
企画フェーズ / 企画承認
プロダクトを作るときのファーストステップですね。
大抵はプロダクトマネージャーロールのお仕事になると思いますが、めちゃくちゃざっくり書くとこういう活動をしていると思います。
- ユーザは何をもとめているか？ユーザの課題は何か？を考え、ユーザの要求を整理する
- それを解決するプロダクトを作るのにどれだけの予算が必要か。どれだけのリターンが得られるのか ROI を計算する。
会社は営利活動を行う組織である以上、「何をいくらで作り、どれだけの利益を生むか」を具体的かつ明確に企画情報に組み込む必要があります。
要件定義フェーズ / 開発着手承認
要求から要件へ落とします。
技術的な課題を改めて確認して、企画時の予算とスケジュールで実現可能か？実現するにはどのような体制が必要かなどを検討します。
開発フェーズ / リリース承認
あとは開発プロジェクトとして設計/実装/テストというごく一般的なフローをたどります。
イメージ図
こんな感じのフローで、承認ゲートをおき、その時々で計画通りか？を確認する形で運営しています。
いざ、開発プロジェクトのはじまり！
さて、みなさんは「要求や要件がふわっとしているけど、とにかく開発を始めないといけない。」みたいな経験はありませんか？
私はあります。
別にそれ自体は悪いことではないと思います。
すべてきっちり決まっていて、言われたことをやるだけの開発なんて多分つまらないし、生成 AI にやってもらったほうがよいと思います。
ただ、ある程度の決まり事を作っておかないと開発はどんどんカオスになっていきます。
ブランチ運用ルール、コーディングルール、プルリク (レビュー) フォーマットだったりの開発ルール、全体スケジュールについてなどは、みなさんほぼ無意識で開発を開始する前にチームで合意を取ってやっているのではないでしょうか。
意外と抜けやすいのが 「成果物として何を作る / 作らない」の定義です。
受託開発だと納品物の有無で決まることが多いですが、自社開発だと結構曖昧なことが多いのではないかと思います。
作業者の力量や意識の差によって、ドキュメントの有無が決まったりすることが結構あるような印象を持っています。
何を作るか、何を作らないかを決める
開発着手前に、「今回の開発だとどの工程で何を作る/作らない」を決めるような動きを最近ではしています。
以下、各作業工程における input/output のイメージです。
企業や現場によって多少違うかもですが、大きくはずれていないかと思います。
たとえば、「今回の開発プロジェクトだとフロントエンドは変更しないから画面に関わるものはいらないね。」とかを事前にチームで共通認識とするイメージです。
自分のアウトプットは誰かへのインプットになる
ものづくりの現場では、「前工程は神様、後工程はお客様」という言葉が有名です。
- 各工程に対してちゃんとしたインプットがないと、正しいものはくれない
- 自分の作ったアウトプットは、次の工程のインプットとなる
というのはソフトウェアに関しても同じだと思います。
一例として、設計書や仕様書をもとに QA エンジニアはテスト分析/設計をして、テストケースに落とし込みます。
設計書や仕様書をきちんとアウトプットしていないのであれば、正しく品質保証ができません。
形式だけの無駄なドキュメントは不要だと思いますが、ソフトウェア開発もこの意識をもつのは重要だと思っています。
設計コラム (余談)
余談ですが、たとえば自分の家を建てるとき、
「どんなものを、どれくらいのお金をかけて、いつまでにつくるか」
を業者さんと話し合って進めますよね。
当然、間取りなどに関しても口頭での依頼や確認だけではなく、図面を見ながら進めるのが普通だと思います。
もしその業者が「設計図をつくらずにいきなり施工をはじめた」としたら、きっと私はものすごく怒るでしょう。
でも、私たちが子どもとレゴで何かを作ったり、粘土で何かをつくるときって、設計図なんて書きませんよね。
それは多分、いつでもやり直しができるし、手戻りをしても痛みを感じないからだと思います。
ソフトウェア開発も、ついその感覚で進めがちです。
個人開発や小規模のプロダクト開発ではそれでも問題ないかもしれません。
しかし、開発の規模が大きくなり、関わる人が増えると、それに比例して手戻りによって失われるお金や時間も大きくなります。
さらに、上流工程からすべてやり直すことになると、もう地獄の始まりです。
私も実際に、途中まで作ったものをすべて作り直した経験が何度かあります😢
とはいえ、「すべての仕様書や設計書をもれなく作成しましょう！」というのは現実的には非常に難しいです。
過去に「できる限りドキュメントに残そう」というコンセプトで開発を進めたことがありましたが、その結果、似たような内容のドキュメントが複数存在し、各々が好きなフォーマットで書いたため、「結局どれが正しい情報なの、、、？」という混乱が生じたことがあります。
その経験を踏まえ、正しい情報をどこに書くべきかを最初に定義することが重要だと感じています。
（閑話休題）
プロジェクト計画書、はじめました
上記の何を作る/作らないを決めるのは、開発プロジェクトを開始する前に決めます。
ベタな感じですが、プロジェクト開始時に「プロジェクト計画書」というのを書いてもらう取り組みを始めました。
PMBOK に書いてあるプロジェクト計画書をより簡素にした感じですかね。
ざっと以下のことを書くようなフォーマットを用意して進めています。
- プロジェクトスコープの定義
- プロジェクトの目的、範囲、制約、ゴールを明確にする
- プロジェクトで「やること」と「やらないこと」を明確に定義する
- プロジェクトのゴール基準としてQ(Quality)、C(Cost)、D(Delivery)の指標を立て、その達成に向けたアクションを定義する
- 開発作業量の見積もり
- 人的リソースの見積もり
- WBSを誰に割り当てるか、社内・外注から調達するかも含め、必要な人的リソースを割り当てる
- スケジュールの決定
- 作業の順序や必要な期間から、全体のスケジュールを立てる
- 全体日程 / マイルストーン / リリース日
- 作業の順序や必要な期間から、全体のスケジュールを立てる
- コストの見積もり
- 必要な作業量と作業期間を見積もってからコストを見積もる
- リスクアセスメントの実施
- ゴール到達までに想定される障害をできる限り明確にして、対応方針を決める
- プロジェクトの進行に影響のある外的リスク・内的リスクを抽出する
- 抽出したリスクに対しての方針（受容、回避、低減）を決める
- プロジェクト外の成果
- プロジェクトの実行を通じて得られる人的、組織的な成長を考察する
- メンバーをどのような成長を促すのか？
- 組織にどのような成長・成果をもたらすのか？
運用を回そう
さらに、上記の計画書を運用していくためのフォーマットも用意しました。
それぞれのマイルストーンでどの成果物がでてくるか？をプロジェクトマネージャーに記載してもらいます。
提出されたプロジェクト計画書をもとに、週次で成果物の有無を PMO チームで確認することで、各プロジェクト運営が良好そうかを判断しています。
進捗が怪しそうなところに、直接 PMO ロールの人が状況ヒアリング、フォローに入るような動きをしています。
(ちなみに PMO チームは、有志での集まりで構成しています)
まとめ
このサイクルをやってみて、「オンスケって聞いてたけど、全然進んでなかった」みたいなことはほとんど無くなりました。
マネージャーの目線から話すと、アウトプットベースで進捗を見れるのはやはりいいですね。
「なんでこれが出てないのに、次の工程いってるの？」みたいな話ができるようになりました。
別にプロジェクトがキレイに予定通りいく必要はないと考えていますし、「こういう理由があって、今はこれをしています」という話ができて、ちゃんとした理由があれば良いと思っています。
このサイクルがたてついたおかげで、そのコミュニケーションがとりやすくなったかなと感じています。
また、これらの活動の主題は、「開発プロジェクトが安定して動き、状況を把握しやすくするように」ではありますが
おそらくどの企業でも不足しているであろう「プロジェクトマネージャーロールの育成」という側面もあります。
プロジェクト進行においてどういう観点を意識すべきか？をプロジェクト計画書の記載から運用フェーズを経ることで学びがあると思っています。
さいごに
開発だけに当てはまる話ではないですが、ある程度の規模の組織やプロダクトになるとルールって大事だと思います。
でも、ルールは道標であって、鎖ではありません。
存在しない人が作ったルールに縛られる必要はありません。
でも、過去はそのルールが必要だったかもしれませんし、そのルールのおかげで今があるのは事実です。リスペクトを払いましょう。
会社やプロダクトは生き物です。毎年何かしらの形が変わります。
そのうえで 「そのルールは今の状況にあってるのか？」と考え、最適な道標を立てれるようになりたいと、私は思います。
また、立てたガイドライン (道標) を守り運用できるようにサポートしていけるようになりたいとも思います。
株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 photosynth.co.jp Akerunにご興味のある方はこちらから akerun.com
