要件漏れに翻弄されないために〜翻弄された一年から振り返る要件漏れに立ち向かう手段〜
この記事は株式会社パーソンリンクアドベントカレンダー7日目の記事です。 Webエンジニア積極採用中です。ご応募お待ちしております(｀･ω･´)
会社のYoutube配信などやってます。
---------------
日々湧き出てくる開発要件を捌いていくことが多いITエンジニアの皆様。急遽発生する要件漏れによる追加対応に苦慮されていることかと思います。
絶対に起きないように！と意識して注意していても、なぜか湧き出てる「要件漏れ」。多かれ少なかれ、開発していくうちにアレ足りない、コレ足りない、ソレ違う、が生まれてくるツラみから逃げ出したいなーと日々思っています。
要件漏れが発生するには様々な理由があります。発注者がそもそも考慮してなかった、考えていたけど伝え忘れていた。開発者が意識していなかった。作ってみた結果なにか違う...となってしまった。色々です。
私がJoinして、ここ一年間携わってきた受託開発の案件でも多く生まれてしまいました。リリースから一年近く。メジャーバージョンが5まで上がりましたが、PMとして顧客側のビジネスオーナーと会話をしてきましたが、日々要件漏れとの戦いに明け暮れてしまいました。
本日は、その失敗談を元に要件漏れを防ぐためにやるべきだった4つのことをお話します。
プロジェクト開発は当初の想定どおりに動かぬ！
残念ながら、プロジェクト。まったくもって予想どおりに動いてくれません。予算、期限、品質。実際に開発してみて表面化してくる問題3兄弟です。
皆様、胸に手をあてて考えてみましょう。こいつらを概ね予想通りにコントロールできたことあるでしょうか？残念ながら私はありません。とっても難しい。私が考えるにそんなことができるのは、めちゃくちゃ優秀なPMがいるプロジェクトだけだと思います。(そんな神のような方がいればぜひ弊社へ...)
弊社では自社開発ではなく受託開発が多く、自社でコントロールできない部分が大部分を占めます。担当していたプロジェクトも発注元の以降次第でプロジェクトのロードマップが大幅に変わってしまいました。
今年はコロナの影響も大きかったですね...投資扱いの開発案件が止まる止まる。担当プロジェクトは止まることはありませんでしたが、発注元側での優先度が変わり人員調整や要件変更に明け暮れることになりました。
リリース日も開発すべき機能も都度変動していきます。ある程度それを織り込んで請負ではなく準委任の契約で開発してきましたが、それでも翻弄されることは変わりません。状況が変わるたびに開発要件を整理しなおし、リリース日を決め、開発を進めていく。そうするとまた必要な開発要件が変わっていく。その繰り返しです。一体、これをどのような形で対処すればよいのでしょうか？
一年かけてたどり着いた境地。それは 計画を固めすぎない・信頼すぎない ことです。3ヶ月先くらいの計画は当然固まっている必要がありますが、半年先、一年先で計画を詳細しても崩れることがほとんどです。
開発も結局ビジネスです。市場環境や競合他社の動きによって、我々の動き方も変えていかないといけません。現代は不確実性の高い世界未来を予測することはほぼ不可能。何が起きるかわからない世界です。発注元企業が調子悪くなる可能性もありますし、業界自体が下火になることもあります。ブラックスワンはいつ飛んでくるかわかりません。
そのような状態で長期計画を作り、それを守ってプロジェクトを進行していく。それが通用する時代ではなくなってきているわけですね。せっかく固めて決まったものもすぐ使いものにならなくなってしまう。必要なものは変化していく周囲の動向に合わせて決断をしていくこと。
ある程度計画どおりに進行しないことを織り込んで期待しすぎないように要件を組み立てて行く。提供するべき価値を意識していく。動きが変わったら決断して短期の計画を継続的に作っていく。
一度決めた要件に固執せずに、ある程度遊びをもって考えていくことが必要
開発要件に妥協しない
最低限の工数で最低限の成果を出す。ビジネスとしてエンジニアやっている以上最大の成果をだしていきたいところですが、プロジェクト開発ではQCDの観点から少ない工数でとりあえず動くものを作る判断をすることもあります。特にデリバリー。「この日までに動くもの作ってね」、「プレス出してるし、絶対だからね」あるあるですね。
この一年私が感じたのは、妥協した開発をすると確実に負債化し、後から対応に追われることになります。なりました。私は見事にこの沼にハマってしまったのです(´・ω・`)
その時は5月までに動画アップロード機能を作り込まないと行けない。今3月末。何も要件が固まってない。そういう状況でした。オーダーは最大2GBの動画をアップロードできる機能を開発しているWebサービスに導入することでした。S3に動画をPutしてAmazon Elastic TranscoderでHLSに変換して配信する。まあ動画扱うにはスタンダードな構成ですね。
もともと10MB程度の画像をアップロードできる機能があり、「時間がないから同じような仕組みで動画アップロードできるようにしよう。一番工数ミニマムだし」という軽い気持ちで、既存の仕組みの延長で開発をすすめました。当時の画像アップロードはファイルをブラウザで選択肢、保存ボタンを押したらまとめてPutする処理でアップロードおこなっていました。アップロード中は処理中を表示してユーザー操作を待たせる。無事にアップロードが完了できたら操作可能になる。そういうものです。
「ちょっと気になる仕様だ...」、「ファイル大きいとめちゃくちゃ待たされるよな...」そういう気持ちもありましたが、やはりリリースが近い。迫っている。ちょっと微妙だけどこのまま作っていくしか間に合わせる方法はない。
結果、保存ボタン押下した後、選択している大容量の動画がアップロード完了するまで操作できない機能が追加されたのです(実際にユーザーから参考になるご意見が多々...)
工数に間に合わせるため急ぎで無理やり実装していった結果、盛大に実装が荒れることにもなりました 。そうして頑張って開発した機能でしたが、結局、そのわずか3ヶ月後にはこの機能が作り直されることになりました。既存の延長で保存時にまとめてアップロードして待たせるのではなく、ファイルを選択したら即ファイル単体を非同期アップロードしユーザーを待たせない仕様に変わりました。もちろん実装も大きく変わりました。以前の仕様や実装がほとんど無駄になってしまったのです。
短絡的で簡単に解決できるやり方を選んでしまったが故の悲劇です。その時かけた開発コストも安くない。結局作り直すことになり更に工数が膨らんだのです。デリバリーを守って妥協した機能を作ってしまった私を待つ結末は、荒れ果てたコードだけだったのです。
この機能は何を目的にして、どのような体験を与えるべきなのだろうか？を常に考えて、妥協ではなく本来あるべき機能を提供する。大事なのはデリバリーを死守するのではなく、顧客に正しい価値を与えることであることを改めて学びました。
妥協はするな！ぜったいだぞ！！
受け入れのゴールを明確にしよう
最終的にどうなっているべきなのか。どうなっていれば完了したと見なせるのか。プロジェクト開発において、開発のゴールを明確にしておくことは非常に重要です。
私が担当していたプロジェクトでは、顧客側のビジネスオーナーと会話して、こういう機能を作りましょうねーって合意し、開発をしていくスタイルでした。「こういう機能を作ります」、「UIはこんな感じです」資料をまとめて提案し、開発を進めていく。そこまでは非常に順調に進んでいました。
しかし、開発して機能ができた！さあテストだ！という時に、「このユースケースでの振る舞いが決まってなかった」、「この条件のときは、この動きをしてくれ」という要望や不満が噴出する。あれ、おかしいな。作る機能は合意したのに...そんな沼にハマりこんでしまったのです。
この追加の要望や不満が生まれている時点では、実装が終わりテストフェーズに入っています。そこで仕様変更の議論が新たに為される。直前であーでもないこーでもないと議論した結果、リリース日が近いのにどんどん要件が積まれていく。まさに悪夢です。
幸い、担当しているプロジェクトでは開発内容が期間のスコープに収める調整が可能だったので「次バージョンで対応します！！」という回避策が取れましたが、そうではないプロジェクトもあります。
ここで私が本当に気をつけるべきだったのは、「開発後のイメージを顧客と綿密にすりあわせてゴールを決めておくこと」だったのです。曖昧なゴールだとやるべきことが霞みます。どこまでやったら解決するのか。それがわからないが故に実装で作り込んだりすることが多くあったのです。
まだ実践し始めたばかりではありますが、受け入れ試験テスト項目を計画の時点でまとめておくことが、1手段として結構アリだと考えています。このテストが通ればあるべき姿を担っている。それが整理し可視化されていると不足に気づきやすくなります。「このケースはどう？」、「あのケースは？」の議論にも繋がりますし、完了条件が明記されることで開発者ごとの認識相違も減らせます。
機能の本来あるべき姿を意識し、皆で認識を合わせておくべし
品質を大事にしよう
担当しているプロジェクトは2020年頭にリリースされました。もともとPoCレベルでコードを書いていた且つ、リリース前に要件が大きく変更せざるをえないタイミングがあったこともあり、リリース前の時点からコードがジェンガ化してました。その上、テストコードや各種自動化へのコストがかけられず、リリースから一年経って未だにテストがない状態になっています。無念。
もともとリリース前〜直後のタイミングでリファクタリングの工数を引いていたんですが、機能開発を優先することになりリファクタリングの工数分も使って開発を進めてきました。今思えば後悔しかない(´・ω・`)。コードの品質を上げていくアクションも進めていくべきでした。コードが整理されていない、量産されていく重複コード、リグレッションテストなし。当然その状態で機能開発ガンガン進めていけば、盛大にバグが生まれます。
大量のバグが生まれ、常にバグと戦う一年間でした。バグの対応に工数を取られてしまい、本来開発に使うべきコストをバグに払い続けることになってしまいました。その上でリリースは容赦なく襲いかかってきます。バグに使っていたコストを要件整理に使えていれば、要件漏れの問題は多少緩和できたかもしれません。必要な時間を持っていかれることを考えると、品質は絶対におろそかにするべきではありません。
テストコード導入してないチームからよく出る話として「急いで開発しないといけないのでテストコード書いてる時間ありません」というものがあります。短期的な話をすればそれは正しい一面もあります。1度しか更新しないプログラムへのテストコードの必要性は極端に低いのです。
しかし我々が開発しているのは何度も更新して大きくなっていく価値あるサービスです。最初にテストコードを書くために払うコストと、テストコードがないために発生するコスト。確実に後者のテストコードがないために発生するコストが勝っていきます。変更するたびにバグが発生する状況は、テストを正しく書き常に回し続けることで回避できるのです。
急いで開発するためにはそのスピードを支えるための自動テストもあって初めて成り立ちます。急ぐためにテストコードを書かない。戯言です。これを読んで今すぐその考えを捨ててください。
品質は必要な開発をするための時間を捻出するため、優先して守るべきものである
終わりに
私も数年ほどPMやってきてはいるんですが、初めての受託開発のPMで顧客調整がうまくやりきれず、本来やらないといけないことに踏み込めていなかったと反省しています(´・ω・`)
頭では理解できていたが実際に行動に移せていなかったのがここ一年で得られた反省です。しかし、実際にやってみて見事失敗した結果、要件漏れをふせぐために絶対に死守しないといけないラインがなんとなく見えてきました。プロジェクトを円滑に進めるため、開発メンバーに負荷を与える稼働を避けるために。要件漏れをうまいこと回避して、変化していくプロジェクトをうまく乗り切って行ければなと思っております。
---------------
明日8日目のパーソンリンクアドベントカレンダーは、弊社のリードフロントエンドエンジニアの hanetsuki_devから、今話題のSapperの導入について書いてもらおうと思います。
Svelte随分盛り上がってきてますよね。Vue.js、React.js、Angular.jsの牙城を崩せるかどうか個人的も期待しています。
それでは！
この記事が気に入ったらサポートをしてみませんか？