要件定義の極意は「急がば回れ」②
成果物のイメージを決めろ
要件定義の成果物はいわずもがな「要件定義書」となります。
とはいえ、この「要件定義書」の体裁には共通の定義がありません。ある意味でフリーフォーマットです。イメージするものは人によってまちまちとなることでしょう。
Google検索で「ユースケース」を画像で検索すると似たような画像が表示されますし、「テーブル定義書」と検索すればこれまた同じような画像が表示されます。まったく同じでは無くても、要点は酷似します。
ですが「要件定義書」は目次構成や表、図、スケジュールなどバリエーションは非常に富んでいます。要件定義と呼ばれる工程で作成する資料も同様です。
同じ企業内、同じ組織内で過去に成功したプロジェクトの既存成果物を流用すれば似通ってくることはあるのでしょう。ですが、そういった場合は大抵のケースで「プロジェクト特性」を無視したものであることが多く、過去の成功を次の成功に活かせずに終わってしまうシーンもよく見かけます。
そして、過去のプロジェクトを踏襲しなかったプロジェクトの場合、「要件定義書」や要件定義工程で作成される成果物は、ほとんどの場合が統一感も無くプロジェクトごとに自由な構成で作成しようとします。
そう、一言でいえば
無法地帯
なわけです。要件定義は「要求を抽出し、要件として整理する」ことが目的であって必ずしも成果物様式を揃えなければならないわけではありませんが、あまりにも個々のプロジェクトが好き勝手に無法地帯を続ければ、当然そこに参画するエンジニアたちは過去の知見・経験を活用することができず、プロジェクトが変わるたびにコミュニケーション齟齬や負担が増え、櫃の低下を招き、大きなコストを要する可能性が増えることになります。
たとえば、現場レベルでは画面の仕様を伝えるドキュメントについて「設計図で十分」と考える人もいれば、「モックアップが必要だ」という人もいるでしょう。仮にモックアップを作成するとして「ワイヤーフレームのみでよい」と考えるチームもあれば「実際に動くものが必要」と考えるチームも出てきます。そこに論理性はありません。
人の数だけパターンがあると言ってもいいくらいです。
顧客にとって、信用・信頼する相手は個人ではなく組織であり、企業である以上、せめて企業単位ではそろえるべきだと思うのですが、大手SIerのなかでもごく一部しかいないのではないでしょうか。ですが私の見てきた中では、要件定義工程の成果物を共通化させようと考える企業というのは２桁もいません。
共通で認識できるイメージがないのであれば、自らが定義するしかありませんよね。
要件定義で決めるべきは、単純に要件定義工程の中だけに閉じるのではなく、その次の工程でインプットとして使われる情報です。つまり、
システム化の仕様
です。もちろんシステム化に至るまでの情報整理も大事なのですが、最終的に決定すべきは「仕様（specification）」いわゆるスペックです。それに加えて仕様で定めた各機能の複雑性も明確にする必要があります。設計フェーズ以降の作業規模を見積もらなくてはならないからです。
さらに仕様を検討した経緯や、それぞれの機能を実装するに至った理由もまとめておかなくてはなりません。最後の最後に「仕様」そのものを評価できるようにしておく必要があるからです。
具体的には「現行の仕組み」や「将来のイメージ」、「業務フロー」や「データの流れ」「データモデル」などをそろえておきます。
当然、それらのシステム要件や機能要件が明らかになってきたところで、非機能要件にも着手しなければなりません。非機能というとバカの一つ覚えみたいに「性能」だけ考えればいい…と教え込む企業も多いようですが、実際には
・信頼性（可用性）
・効率性
・セキュリティ（…今となっては機能要件の１つですが）
などもあります。特に24時間365日稼働し続けなくてはならないシステムや事業の根幹を担う基幹システムなどはBCPに根付いた検討（災害対策）も考慮しなくてはなりません。そのほかにも「移行要件」や「運用保守要件」なども整理しなくてはなりません。ただ単に「モノを作ればいい」というものではないのです。
要件定義とその次のフェーズである設計での成果物を定義し、「いつ」「何を」作るか、「何と何を」連携するかを明らかにしましょう。
この時点で設計の成果物まで提示しているのは、ドキュメントの網羅性を示しつつ、要件定義で作成するものを明確にするためです。たとえば、
「画面仕様書は要件定義では作成しないが、設計で作成する」
というスコープの明示が可能になります。もちろんそうすることの根拠であったり、有効性や利点も明らかになっていなければなりませんが、そうすることで顧客もメンバーも安心して任せることが可能になります。
また、各成果物のサンプルも添付して内容についても関係者間で合意しておきましょう。これを怠ると
「違ったものを作成された」
「この内容では記述が足りない」
といった問題が発生しかねませんし、結果的にクレームにつながりかねません。
なお、システム開発における成果物標準（サンプルも含む）を定義するのは企業の仕事です。プロジェクトは「プロジェクト」と言うスコープの範囲内でのみ責任を負います。部門は部門の中に閉じたスコープに対して責任を負います。企業として共通化を図るのであればそれは企業としての取り組みとならなくてはなりません。適当に指示して「現場でやっとけ」ではできるはずもありません。
スイッチングコストの低減を図り、また標準化することで成果物の質を向上していこうと考えるのであれば前もって成果物を定義する必要がありますし、実際に開発が発生する場合にはその標準の適用検討を促すのです。
この推進ばかりはボトムアップでどうにかなるものではありません。
もちろんそのまま流用すればいいというわけではなく、テーラリングは必要でしょう。プロジェクト特性にあわせて取捨選択も必要になると思います。ですが企業として信用されたければ、成果物品質の定義を現場任せにしていてはダメです。
推進を始めるのはそれほど大変な作業ではありません。既存のシステムを何個か評価し、優れたものを採用して「標準」とすればいいのです。どうせテーラリングが必要になることは大前提で検討するのですから、最初から完璧である必要はありません。あくまでも現場になんでもかんでも一から作成させる負担を賭けさせない程度に参考になればいいのです。
役割分担を決めるときは忖度しない
プロジェクトの役割分担はしばしば曖昧になりがちです。
特に日本の開発者は頼まれると「ノー」とは言えない人が多い傾向にあります。面倒な仕事でもついつい受け入れてしまいがちです（後で文句を言うのですが）。その結果、開発チームが役割外の仕事を抱え込んでしまうケースは異様なほどに多いと言われています。
発注側と受注側の関係では、それがとても顕著に出てきます。
「担当が明確に決まっていない作業」を開発側が引き取ることは珍しくありません。プロジェクトによっては既存業務の突っ込んだ整理や、業務のあるべき将来像の策定、どのレベルで機能を実現するかの判断など、発注側でなければこなせないタスクを受注側に任せていることもあります。
受注側の内部でも役割外の作業が発生します。
たとえば「プロジェクトでトラブルが発生したときに、上長から経営層への説明資料や品質リポートをまとめるよう指示された」という経験はないでしょうか。現場にしてみれば「資料が必要ならどうぞご自分で作成ください」と言いたいところでしょうけど、現実的には断ることは難しいのではないでしょうか。
こうして役割外、計画外の作業が発生すると本来やるべき仕事ができなくなってしまいます。それが残業などを助長し、助長された残業などのせいでコストを消費し、著しく利益率を損ねたり、離職率を高めることになるとわかっていても企業というのは「計画に無い」ことを押し付けたがります。
これを回避するには作業分担を明確にしておくしかありません。
裏を返せば、役割定義を曖昧に従るプロジェクトマネージャーや上司は、確信犯的に計画外のアレコレを押し付ける気が満々だということにつながります。実際、数ヵ月～数プロジェクト経験してみると、そのことが嫌と言うほどわかるのではないでしょうか。
具体的に回避するには、プロジェクト開始前に作業の概要レベルで一覧化するといいでしょう。たとえば
「既存資料の提供」
「既存業務の説明」
「新業務の判断」
「新業務を決定するための検討資料作成」
「議事録の作成」
「経営層への報告」
「経営層用の報告資料作成」
「打ち合わせ日時調整」
といった具合です。細かい作業に至るまで誰が実施するのか、支援止まりなのかをRACIチャートでまとめ、関係者全員で合意しておくのです。
この時、役割分担を決める際、遠慮は絶対に禁物です。
責任や役割に見合った権限、裁量、報酬をもらってそこに鎮座している以上、一人ひとりの関係者にはその待遇にみあった責任を果たす義務があります。逆にいえば、その義務を果たさないのであればそこにいる資格はありません。
やるべきことは、本来担当すべき人物に作業を割り振るだけです。
もしそれでもやむを得ず開発側で引き取る場合は、スケジュールへの影響を必ず考慮し、無理をする必要がない計画の中で実施できるよう取り計らうことを忘れないようにしましょう。
「できそう？」
「大丈夫？」
「なんとかなりそう？」
なんて考えることすら無意味です。そのような懸念がある相手に振り分けるべきではありませんし、能力的にできないのであればそのメンバー配置に問題があるということになります。
また、影響度合いが大きい場合はスケジュールの再考を申し出るようにしましょう。「悪いけどやっておいてよ」と言葉で丸め込まれるとやるべき作業がやれなくなります。とにかく役割を真剣に考えることが大切です。ここで適当な判断しか下せないようでは、ロクな結果になりません。
そして最後に、決定事項は文書化することです。先述の通り、RACIチャートにするのが一番だと思います。表現力次第でなんとでも解釈できてしまうような文書にはしない方が後々の憂いを残す腰になってしまいかねません。それぞれの作業の責任の所在を明確にしよう。
まとめ
余談ですが「システムの受託開発が失敗する原因は要件定義にある」とよく言われるのは、ある意味で概ね正解です。要件定義はここまでにも説明してきたようにプロジェクトごと、エンジニアごとに自由な幅がありすぎるせいでとにかく様々なものが曖昧になりがちです。
・計画が曖昧
・成果物が曖昧
・役割分担が曖昧
・スケジュールが曖昧
・コミュニケーションが曖昧
なんとなくしっかり定めているつもりでも、定めたこと自体の根拠もあいまいで、あくまで仮決めのような域を抜け出せないままで進むことになります。そうした「曖昧すぎる」ことが後々の問題につながっているのです。
その結果、曖昧であるがゆえに発注側が自らの責務を理解しないまま受注側に仕事を頼み過ぎているように思う部分もありますし、受注してしまった手前、失敗させてはいけないという危機感だけが心理的に先行してしまう受注側にも責任があります。
元来、業務の内容は発注側で整理するべきであり、どう変えるべきかの判断も発注側が決断すべき責務です。
過度のベンダー依存は発注側のリスクです。
情報システム部門や業務部門は使い勝手の良い受注側の開発者を重宝しますが、ある日突然いなくなるかもしれません。不測の事態に備えるためには発注側自身が情報を整理し「考える」スキルを身に付けておかなくてはなりません。発注側がこなすべき作業を意識して、実践することで防げるトラブルもたくさんあるのです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。