100以上のプロダクトを作ってきたエンジニアが教える 要件定義でつまずくプロジェクトに共通する7つの兆候
筆者紹介
15年間、ホテル・旅館向けの基幹システム開発や価格推移の分析、競合分析、レピュテーション分析といった新規事業の開発に携わってきました。2016年からはフリーランスエンジニアとして、スタートアップ企業の開発支援に従事。2022年4月に株式会社パースツリーを設立し、「ゼロからのスタートを支援する」をコンセプトに事業支援を展開しています。
これまでに100以上のプロダクトの立ち上げ・開発に関わってきました。現在も横浜を拠点に、多様な業種の事業づくりを支援しています。
対象
システム開発をこれから外注する経営者や管理者
社内にエンジニアがいないまま、開発の窓口を任されている方
要件定義の打ち合わせに何度も出ているが、何を決めているのかよく分からない方
過去に「思っていたものと違うものが納品された」経験がある方
読んで得られること
開発が始まる前に失敗が決まってしまう、7つの分かれ道
要件定義の場で、発注側が確認すべき具体的な質問
打ち合わせを止めてでも先に片づけるべきことの見分け方
要件定義でつまずいたプロジェクトを、これまでいくつも見てきました。だいたいは、開発が始まってから問題が出るのではありません。始まる前に、もう決まっています。
先に立場をはっきりさせておきます。要件定義書は、厚ければ厚いほどいいものではありません。むしろ私の経験では、分厚い要件定義書が出てきたプロジェクトほど、後で揉めています。 決められなかったことを全部書き足していった結果として厚くなっているだけ、というケースが少なくないからです。
ここでは、要件定義の場に出てくる7つの兆候を挙げます。どれも、開発が始まる前なら手を打てるものです。
1. 決める人が決まっていない
打ち合わせの参加者は多いのに、最後に誰が決めるのかが決まっていない。これが一番多い兆候で、一番あとに響きます。
「持ち帰って確認します」が3回続いたら、確認の相手が誰なのかを聞いてください。部長なのか、本部長なのか、社長なのか。決裁のルートが見えないまま進むと、開発の途中で「聞いていない」という人が現れて、そこから作り直しになります。
発注側が最初にやるべきことは、機能を並べることではなく、この人が決めると言い切れる人を1人置くことです。
2. 今の業務をそのまま動かす前提になっている
「今やっていることを、そのままシステムでできるようにしてほしい」
この依頼は自然に聞こえますが、要注意です。今の業務のやり方は、紙とエクセルと人の記憶で回すために最適化されています。それをそのまま移すと、たいてい手作業が増えます。
たとえば、担当者が経験で判断していた例外処理を、そのままシステムに落とそうとすると、条件分岐が10も20も必要になる。作れないことはありませんが、費用と期間はふくらみます。
システムに合わせて業務を変えられる部分がどこかを、要件定義の段階で決めておく。ここを避けたまま進んだプロジェクトは、私が知る限り一つも楽になっていません。
3. 画面の話から始まっている
初回の打ち合わせで、いきなり画面の配置やボタンの位置の話になることがあります。話としては盛り上がるのですが、順番が逆です。
先に決めるのは、誰がどんなときに何をするか。それが決まっていないのに画面を描くと、後から「そもそもこの画面、誰が使うんでしたっけ」という話に戻ります。実際、戻ります。
画面の議論が早すぎるときは、一度止めて、業務の流れを紙に書き出したほうが早いです。
4. 例外処理が「あとで」になっている
正常なケースだけで話が進み、例外の話が出てこない。あるいは出てきても「そこは運用でカバーします」で流れていく。
運用でカバーする、は判断としてありえます。ただ、誰がどれだけの手間をかけてカバーするのかまで決めていないなら、それは判断ではなく先送りです。稼働してから現場に負担が集中して、結局は追加開発になります。
例外を全部つぶす必要はありません。数が少なくて影響が小さいものは、運用で受けたほうが安上がりです。決めるべきは、どれを作ってどれを人が受けるか、その線引きです。
5. 数字の定義が揃っていない
「売上」と言ったときに、税込か税抜か。受注ベースか、入金ベースか。キャンセル分をどう扱うか。
部署ごとに違う定義のまま要件定義が進み、稼働してから「この数字、営業の数字と合わないんですけど」となる。ここまで来ると、集計のロジックを作り直すことになります。
打ち合わせの中で数字の名前が出てきたら、その場で定義を聞いてください。数分で終わる確認が、あとの数十万円を防ぎます。
6. 現場の担当者が一度も出てきていない
要件定義の場に、実際にそのシステムを毎日触る人がいない。経営層と情報システム部門だけで話が進んでいる。
これは、悪意があって外しているわけではなく、忙しいから呼べていないだけ、ということが多いです。ただ結果として、現場が知らないうちに現場のやり方が決まります。導入したあとで使われないシステムは、だいたいこの経路をたどっています。
偉そうに書いていますが、私たち自身がやりました。ある会社の業務システムの相談で、新しい入力用のアプリを作り、そこから基幹システムへ書き戻す構成を提案していたときのことです。打ち合わせの席で、先方の担当の方にこう言われました。
「端的に言うと、その機能はちょっと違う形で相談したいんです」
聞いていくと、欲しかったのは新しいアプリではありませんでした。基幹システムの手前に、入力の窓を一枚挟みたい。それだけでした。二重に持つと、どちらが正しい数字なのか分からなくなる。実際に毎日入力する人からすれば、当然の話です。
私たちは、その人に一度も会わないまま構成を組んでいたわけです。設計の腕とは関係のないところで、ずれていました。
7. とりあえず全部入れておこう、が出てくる
「あとで追加すると高くなるらしいから、今のうちに入れておいて」
気持ちは分かります。でも、この判断はたいてい裏目に出ます。使われない機能にも、テストの工数と、保守の手間と、画面の複雑さが乗ってくるからです。使わない機能が並んだ画面は、それだけで現場の学習コストを上げます。
最初に入れるのは、なくなると業務が止まるものだけでいい。あとは動かしてから決めても、そんなに高くつきません。少なくとも、使われない機能を10個抱えるよりは安いはずです。
7つの兆候と、いま打てる手
最後に
7つ挙げましたが、根っこはだいたい同じです。決めていないことを、決めていないまま先へ運んでしまう。 それだけです。
要件定義は、作るものを決める場だと思われがちですが、実際には作らないものを決める場でもあります。何を諦めるかを先に決めたプロジェクトは、そのあとが速い。
先日担当したサイトの案件では、扱う部門をひとつ、構成から外しました。その部門を今後どうするかが先方の社内でも決まっていなくて、決まるのを待っていると全体が止まる。外すと決めた場で残りの構成が固まり、公開日から逆算した日程がその日のうちに引けました。外した部門は、公開のあとに改めて考えることにしています。
もし今、要件定義の打ち合わせが何度も続いていて、何が決まっていないのかが分からなくなっているなら、一度手を止めて、この7つを上から確認してみてください。だいたいどれかで止まっているはずです。
＊月額10万円からの定額制のアジャイル開発
「新規事業開発を開始したいけどエンジニアがいない」
「開発を依頼したいけど相談する相手がいない」 などでお困りの際には、お気軽にご連絡下さいませ。
無料相談受付中です。まずはご相談下さい。
＊時間とタスクを、同時に可視化
稼働の現在・過去・未来を、ひとつに。
「タスクは管理できているのに、どのタスクに何時間かかったかが分からない」
そんなチームのための稼働マネジメントツールです。
