はじめに
みなさんこんにちは。今岡です。
テラスカイはお客様やパートナーの皆様に支えられ、おかげさまで案件数が2500件（2017/03/29現在）を突破しました。確実な品質と納期の積み重ねが評価・信頼されたものと大変喜ばしく思っております。大部分の案件がご期待する品質と納期でお届けできているものの、残念ながらプロジェクトが長期化してカットオーバーを迎えた案件もゼロではありません。
いわゆる炎上プロジェクトとなった原因を探ると、高い割合で「要件定義の失敗」が理由として挙げられます。プロジェクトの成功の鍵はいくつかあると思いますが、プロジェクト成功の重要な位置付けとなる「要件定義」の進め方について、いくつかのポイントを概略でお届けしたいと思います。
認定テクニカルアーキテクトの合格を目指す読者の方もいらっしゃると思います。認定テクニカルアーキテクト試験というと、プラットフォーム特性や制限を理解し、より大規模かつ複雑なプロジェクトに対応できる技術的な設計・実装スキルに着目しがちですが、プロジェクトのライフサイクル、様々なタイプの開発パターンや開発方法、プロジェクト全体のリスク検知なども必要スキルとして求められます。
危険なプロジェクトの香り
提案時やプロジェクトが開始した直後に「このプロジェクトはなんだか上手く進まない気がする」といった感覚を覚えたことはありませんか？ ここでは、そのような感覚を「危険なプロジェクトの香り」と称して、危うさ漂うプロジェクトの典型的なケースを挙げてみます。
ケース１
提案者：「アジャイルなので早く安く失敗しません！ ドキュメントも作りません。」
提案する側の典型的なよくない提案例です。Salesforceの標準カスタマイズは確かに高品質・高生産性を約束するでしょう。しかし、標準カスタマイズの生産性が高いとはいえ、データモデルの変更を伴う変更要求のインパクトは大きいものです。また、ユーザインターフェースやビジネスロジックの一部をVisualforceやApexで実装するケース、外部システムとのインテグレーションを伴うケースなど、従来のスクラッチ開発相当な期間と工数を要するでしょう。また、業務フローや機能要件一覧などの最低限のドキュメントは作成する必要があるでしょう。ユーザに耳当たりの良い話をして開発者が後から苦労するような提案をしていませんか？
ケース２
開発者：「要件が収束しません！後から知らない仕様を言われました...」
プロジェクトの開始時にユーザとスコープの認識は合意できていますか？ 例えばRFPが提示されるような案件の場合、それに含まれる業務フローや機能要件一覧などからスコープを検討し、要件定義でヒアリングする業務を決めることでしょう。ところがプロジェクトがいざ始まったら、ユーザから「業務全般を理解してもらった上で今回対象とするシステムの要件定義を進めて欲しい」という話があったとします。スケジュールは気になりつつも、ヒアリングしなければ先に進まないという開発者の焦りから、当初想定していない業務までヒアリングを続けた結果として、要求が膨れ上がり要件定義が収束しない、ようやく収束したものの当初予算を大幅に超過することが判明して次工程に進めない、要件定義の収束を優先した結果として、要求仕様の詳細な詰めが甘く後工程で品質面に課題が出るといった事態を招きかねません。
ケース３
お客様：「予算も納期も要求も全部決まっていますが、アジャイル的にお願いします！」
アジャイル開発の考え方や進め方を誤解されていませんか？ プロジェクトの中で当初想定していなかった新たな要求仕様や変更要求が出てくることはあります。アジャイルで進めることが前提であれば、要求仕様の追加や変更要求が発生した場合、その優先順序は見直され、常にスコープ調整とセットであるべきでしょう。要求が全部決まっているという中には「現在使われているかよくわからないが、既存システムにあるから...」というようなものが含まれる場合もあります。「当初要求すべてが実装されないと受け入れられない」ではなく、「作らないことの良さ」という選択肢もあってもよいのではないでしょうか？
ケース４
お客様：「この要件は別担当です。ただし、仕様は現行踏襲でお願いします！」
要件定義で業務を確認していく過程で、仕様に関する決定ができずユーザ内で担当がたらい回しになるケースです。開発者は仕様を早急に決定したいものの、誰に確認したらよいか判らずスケジュールだけが差し迫る事態となるでしょう。また、「現行踏襲」がうたわれるケースも要注意です。現行システムからプラットフォームも変わり、その特性や制限も異なる中、何をどこまで踏襲すればよいのでしょう？ ユーザがユーザインターフェースの振る舞いは理解していても、内部的なビジネスロジックまで仕様提示できないケースもあります。結果として、現行システムの膨大なドキュメントや場合によってはソースコードから読み解くという事態になり兼ねません。
開発手法の選択
Salesforceを導入する上で、ウォーターフォール、アジャイル、あるいはその両方をハイブリッドに取り入れて行うケースがあります。ウォーターフォールに慣れ親しんだユーザからすると、アジャイルでの進め方がイメージできなかったり、誤解している場合があります。最悪の場合「いつ仕様を合意したかわからなかった...」という切ない事態が生じることがあるかもしれません。 やはりユーザとプロジェクトを進める上で開発手法の十分な説明と理解が必要でしょう。また、お客様の文化やシステムの特性がその選択に影響を及ぼすケースも考慮したいところです。
要件定義のアプローチ
要件定義を進める上で、ユーザは現在直面する課題解決や新たな取り組みに対する期待効果の検討に注力したいものです。開発者はそれを理解しつつも、ユーザ自身が気付いていない課題を抽出したり、ユーザ自身が詳しく把握していない仕様を掘り下げることが必要となります。そのためにはどのようなアプローチが考えられるでしょうか？
プロトタイピング
Salesforceの要件定義において、標準カスタマイズを用いたプロトタイピングを行わないケースはないでしょう。プロトタイピングは実際に動くものが見れるため、ユーザにとって業務での利用シーンをイメージしやすく、意思決定がしやすいというメリットがあります。非常に有効な手段の一方で、デメリットもあります。
ユーザにとってわかりやすい反面、機能や操作性に偏ったレビューや要望になる場合があります。結果として、業務的な観点での検討やビジネスロジックの検討が不十分となるリスクがあるでしょう。
キーマン
このような出来事が起こったらどうでしょう...
要件定義も終盤に差し掛かり、これまで取りまとめた成果をレビューする場面において、今まであまり姿を見なかったユーザ部門の方がいらっしゃいました。開発者が説明を終えるとその方から「こういうものを作って欲しいのではない！ 我々のビジネス構想をわかっていない！」とちゃぶ台をひっくり返されました。。
極端な例ですが、真にシステム化の目的やゴールを理解しているのが、必ずしも要件定義の中で積極的な発言や要望を出すユーザとは限りません。システム化を進める中では多くのステークホルダーが参加します。最終的な意思決定に影響を及ぼすユーザの把握や、予算執行の権限を持つ人物などの把握とコミュニケーションは必要でしょう。
ワーキンググループ
要件定義に毎回大勢のユーザがミーティングに参加し、ユーザ間で議論が白熱してしまい遅々としてヒアリングが進まないということはありませんか？ あるいは「仕様面の最終的な決定はユーザ部門に確認しないと決められない」として、いつまでも仕様が確定しないケースもあるでしょう。要件定義を円滑に進める上で、意思決定可能な少数ユーザと集中して要件定義を進めることは重要になります。
現場見学
ユーザの現場を見ると、その現場で起こっている生の課題や雰囲気を肌で感じることができます。そしてユーザの考えるシステム化の目的やゴールの理解がより高まり、開発者としてシステムを作る上での意気込みや思いも高まることでしょう。例えばコールセンターで数百席のオペレーターが業務を行っている様子を見ると、開発者として「絶対止まらないシステムにしなくては！」や「オペレーターのみなさんに喜んでもらえるシステムを作るぞ！」といった気持ちになると思います。
現行システム
ユーザの業務を理解する上で現行システムに関するヒアリングを行う場面があると思います。ユーザから操作マニュアルや設計書が提示され、それにもとづきヒアリングすることも多いと思いますが、実際に動く現行システムの説明を受けながらヒアリングすると、ドキュメントでは気付かなかった仕様が確認できたり、ユーザが機能面で重要視しているポイントなどがより具体的に把握できることでしょう。
設計書
ユーザが現行システムに関する仕様を十分に説明できない場合はあるでしょう。開発者として現行システムを俯瞰的に把握したい時、現行システムのデータモデルを見ることはそれを助けると思います。また、外部システムとのインテグレーションなどを検討する上で、既存システムのテーブル定義書からキー項目やデータ型を把握することは設計の精度をあげるでしょう。さらにユーザ自身が詳細に把握しづらい入出力のチェック仕様やステータスによるアクセスコントロールなども設計書から得られる重要事項になるでしょう。
生データ
初期データ移行や外部システムとのインテグレーションなどを検討する上で、実際の生データを見ることが時として重要になります。ユーザ自身がトランザクションのキー項目として認識していた項目を調べてみると重複するデータが含まれていたり、Nullを許容しない想定の項目に値が入っていない、日付型として扱う想定の項目に日付としてあり得ないデータが含まれているなどは実例です。
要件定義のアウトプット
最終的な要件定義完了までに具体的にどのようなアウトプットを作っていますか？ Salesforceの導入では比較的ドキュメントが少ないと言われますが、最低限必要であろうアウトプットを紹介します。
- プロトタイプ
- データモデル
- 主要項目・ステータス
- 業務フロー
- 機能要件一覧
- セキュリティモデル
上記で挙げたアウトプットは、それ自体を要件定義の終盤で作るというものではありません。業務フローを検討し、システム全体を通して業務が回ることに主眼を置いたプロトタイプで確認し、システム全体の骨格となるデータモデルに落とし込みます。さらに、業務を行う上で重要となる主要項目や業務上の分岐や状態を表すステータスを明確化します。これらを要件定義の過程でサイクリックに実施し、機能要件一覧へと取りまとめます。要件定義ではどうしても機能面に着目しがちですが、セキュリティモデルはシステムの非常に重要な位置付けとなりますので、確実に確認しアウトプットしましょう。
要件のスコーピング
要件定義では多くの要求仕様が提示されますが、限られた予算と納期の中で常に優先順序をつけてスコープの調整を図る必要があります。優先順序の付け方は様々なやり方があると思いますが、ここでは「狩野モデル」を紹介します。例えば、ある機能についてユーザに「あればどう思いますか？」という質問と、「なければどう思いますか？」という２つの質問をします。ユーザからあればどう思うかの質問に対して「当然である」という回答が得られ、なければ「気に入らない」という回答だったとします。あれば当然でなければ気に入らないと怒り出すのですから、この機能は「必須」として必ず作らなければならない機能となるわけです。
M："必須"がおのずと優先順序を高くして開発する対象となり、E："魅力的"は従来のシステムや競合他社との差別化が図れることになります。L："線形"はあればあるほど満足度が上がることになるため、コストと納期の見合いになるでしょう。I："無関心"はあってもなくても気にならないので優先度を下げ、R："逆効果"はあると困りますので作りません。Q："懐疑的回答"は回答がおかしいので要求として取り下げて構わないでしょう。
要件のトレーサビリティ
要件定義を通じて収集された要件が現在どのような状態にあるかをトレースできますか？ 要件がいつ発生し、その優先順序はどう設定され、フェージング、いつ着手する、あるいは現在開発中、テスト中である、リリース済みであるなど...システムは一度のリリースを経たのちも随時新たな要望やエンハンス、改修要望などが発生し続けます。これら全体が管理され常にスコープ調整と状態が把握できる仕組みを作ることも検討してみては如何でしょう？
おわりに
要件定義をテーマに寄稿しましたが、要件定義をテーマに１冊の書籍が書き上がるほど奥深いものなので、内容に物足りなさを感じられる方もいらっしゃると思います。ただ、ここで記載した内容は多少のアレンジはありますが、実体験にもとづきます。恥ずかしながらの事例公開ということになりますが、開発者のみなさんが同じ轍を踏まず、生き生きとプロジェクトが遂行されればと思った次第です。
