体験の良い開発プロセス

エンジニアとしていくつかの会社で働いてきて、体験が良かった開発プロセスをまとめる。仕事で関わる組織の中には、以下のプロセスのどれかが十分ではなかったり、順番が異なったりして、手戻りが発生することが多い。このプロセスなら、大分手戻りを減らせるのではないかと思うので、内容を紹介する。

要求定義

顧客が作って欲しいものを定義する。

顧客が作って欲しいものをドキュメントにまとめる。次に、ステークホルダーを洗い出し、該当する方に機能の役割を説明し、合意を得る。この時点でステークホルダーが漏れていると、後になって鶴の一声で開発がストップする場合があるので注意。

要件定義

要求を満たす要件を書き起こす。

ステークホルダーとの合意が取れたら、要件をドキュメントにまとめる。特に重要な要件に対しては「なぜその意思決定をしたのか」を明文化する。

また、不要な要件は削る努力をする。本当にその要件が必要なのか、なくても困らないかを考える。一つ要件が減れば、それに対する設計・実装・テストの行程がなくなり、早く確実なリリースに繋がる。例を挙げると、A から B に対して期日が切れると無効になるリクエストを飛ばせて、B はリクエストを却下できる要件の場合、B の却下の操作は無くても良いかも知れない。(何をしなくても、自動で無効になるため

法務やレピュテーションリスク、現在のシステム構成を踏まえると実現が難しい要件もあるので、関係者各所のレビューが入る。

デザイン

上記の要件に対して、UX/UI を決定する。

要件のドキュメントを元にデザインを行う。デザイナーが書き起こしたデザインを PdM がフィードバックをする。実装が難しいデザインになることを防ぐため、エンジニアがフィードバック会議に参加することがある。

仕様策定

出来上がったデザインを元にエンジニアが仕様を書き出す。

デザインを元に、ユーザーの行動に対するアプリケーションの振る舞いを書き出す。書き出した仕様は PdM がフィードバックをし、仕様を Fix させていく。エンジニアが仕様を書き出すことで、実装時にあれこれ仕様を確認することが少なくなる。

その際に足りていないデザインが見つかった際は、デザインに戻す場合がある。エラー表示などは忘れがちである。

見積もり

仕様に対してエンジニアチームで見積もりをする。

仕様書を見ながら見積もりを複数人で行う。プランニングポーカーを用いてどれぐらいの粒度になりそうか洗い出す。例えば、ある仕様に対して、Aさんは粒度3、Bさんは粒度7と見積もった場合、差分の4が見えていなかった実装範囲として表面化することが多くある。これによって、精度の高い見積もりを実現する。

見積もりの結果を踏まえて、リリーススケジュールが前後することがある。

システム設計

仕様書を見てシステム設計をする。

システム設計をしたタイミングで、別のエンジニアにレビューをもらう。ここでのレビューを疎かにすると、実装時のレビューでもっと良い設計が判明した場合に作業内容が無に帰す。また、設計時に合意が取れていると、実装のレビューもしやすい。

実装

仕様書・システム設計書を見て実装する。

上記を元に実装し、別のエンジニアが要件・仕様を漏れなく満たしているかレビューする。セキュリティやパフォーマンスなど非機能要件についてもチェックする。

また、実装時にしか気づかないような仕様も出てくる。その際は、PdM に仕様の確認をした後、仕様のドキュメントに内容を反映する。

テスト

第三者がテストをする。

実装とレビューを終えた機能をテスト環境にあげて、要件や仕様を満たしているかテストをする。上記で作成した仕様書はそのままテスト項目として使うことができる。

実装者、レビュー者はバイアスがかかっているので、異なる人物によってテストされるのが好ましい。重大なバグなどに気づいた際は、修正をする。

評価

リリースした機能を評価する。

リリースしたら、ユーザーからのフィードバックや BI ツールを見て、機能の継続か撤退かの判断を行う。その機能によって、別の重大な数字が下がった場合、機能を引っ込める場合がある。

撤退の判断ができないと、機能もコードもモリモリな悲惨なプロダクトになってしまう。

終わりに

以上が実務を通して体験の良かった開発プロセスになる。

毎回この通りに開発が行われるわけではないが、手戻りが多くて困っているチームがあれば、参考にしてみて欲しい。