質問があります。
後で要求が変わる事が多々あるかと思いますが、その様な変化に素早く対応するにはどうすればよいと思いますか？
何故このような事を聞くのかといいますと、この記事の要求分析書が多いと感じたからです。
変化があるたびにこれらの書類を書き直すのは大変だと私は感じたのです。

前の方が質問されているように、最近は変化が多く激しく感じます。

社内外統廃合による人事、新技術発表による変化など始めにこれで決定したはずですとはなかなか言えない状況です。

要求仕様からさらに基本設計など後工程も変化するはずですから、いちいち書き直すのは膨大な手間隙がかかります。

変化にすばやく、なるべく負担をかけずに対応する方法があるならお聞きしたいです。

インドリさん、

　高橋です。多忙にしていて返答が遅れました。大変失礼しました。
　
　要求分析についてのアウトプットが多いので、後々の変更要求に対応するのが大変ではないか、というご質問と理解しました。

　要求分析の成果物は基本的に要求モデルのみと考えています。
(私の場合、ロジックツリーの目的/手段での階層表現)

　記述のあった関与者利害関連表、WHYツリー、流れとつなぎ図などは、要求をまとめるための手段という位置づけです。
　そのあたりの説明は次回にと考えていましたが、先行して簡単にお話しすると、次のようになります。

・関与者利害関連表
　システムに対する要求は、責任部門として事業部門から出します。システム要求を出す側は、自らの責任範囲(主に組織)内における要求を主張することが多いと言えます。ところが、分析者サイドとしては対象範囲全体を見ないといけないということと、要求を出す側にも他者との関係や位置づけを知り、さらに建設的な意見を出してもらう必要があります。よく言うブレーンストーミングのための素材として、これを使用します。結果として関係者の共通認識を促し、より具体的で現実的な要求を引き出すことができます。

・WHYツリー
　先述の通り、私は要求モデルをロジックツリー形式で表現します。
　目的から手段を洗い出すトップダウン型と、これは何のためにという考えでＫＪ法などを使ってポトムアップ型の両方でまとめていきます。
　そのときに、どうしても要求モデルを下位展開できない場合、つまり原因がわからないので対処法も浮かばない、という場合に結果から原因を導き出すＷＨＹツリーを利用すると便利です。

・流れとつなぎ図
　この手法も、原因を突き止めて要求モデルの会展開を促すものですが、どちらかというと組織間のプロセス上での問題を突き止めるために使用します。

　この3つの中間成果物の中で、関与者利害関連表を要求分析の成果物とする場合もありますが、他の2つはモデルを策定するための手法です。

　要求モデルは、この中でも今回実現する、次のステップで対応する、また、これこれこういう理由で対象外とするということを明らかにします。

　後に要求モデルを見直す必要が出るケースは、要求分析に漏れがあった場合と、何らかの外的要因(予算、スケジュールの変更など)が発生した場合ですが、
どうするかはその時点で責任者を交え判断するしかないと思います。
　実装手段は要求分析では取り上げないので、技術動向からの直接的な変更は無いと考えています。

　どちらにしても、おっしゃる通りで、書き直さないといけないのは大変になるので、できるだけシンプルにした方がいいというのは同感です。

きじまさん、

　高橋です。コメントありがとうございます。
返答が遅れまして、大変失礼しました。
　インドリさんにもリターンしましたが、言われるように後々の変更で遡って対応するのは、困難なケースが多いと思います。

　先ほども書きましたが、システム分析フェーズでの要求分析ステップの成果物への変更は、大きく分けて以下の2通りと考えられます。

①要求分析作業上での漏れ
②予算、スケジュールやシステム化対象の変更など、プロジェクトの外的要因による変更の発生

　ここでは、成果物に対して事業部門の承認が必要ですので、極力技術的な実装手段は省くべきと考えています。

　②から先に取り上げると、機能分析や実現手段検討のステップに入って、当初予算やスケジュールを見直さなければならなくなり、その結果システム化対象領域の縮小などが発生する場合があります。
　このケースは、システム分析フェーズでシステム基本構想を策定した結果、ありうるということで、あらかじめ想定しておくくらいのリスクテイキングが必要だと思います。もちろん、プロジェクトマネージャレベルではなく、経営層レベルでの話です。

　①は、世の中に多く存在する業務分析のメソッドで論理的にプロセスと成果物の流れを認識しながら進めることで、カバーできる範囲もありますが、突き詰めるとユーザー企業の事業戦略を理解できていたか、まで行ってしまいます。

　単なる要求モデルへの変更を簡単にできる方法はあるか、ということだけでは解決するのは難しいと思います。また、システム構築におけるユーザーとＩＴベンダの役割分担にも話が及ぶと思います。
　
　以前セブンイレブンの情報システム部門の責任者の方にインタビューする機会があり、その考え方に感心したことがあります。

　上流工程(システム分析)は自社で実施されて、下流(システム設計以降)はベンダに任すという方針は一般的ですが、ある方法を取られて全体コストを下げ、納期遅延をなくしたという内容でした。

　長くなるので簡単に言いますと、システム分析では実装手段に言及はしませんが、機能の確定と帳票、画面、及び画面設計は済ませておくというものです。
　システム部門だけではできないので、事業部門も巻き込んで、喧々諤々の議論をしたそうです。事業部門には実装手段の話をしてもあまり通じないので、見える部分を中心に話し合う、そうすると機能的なものも見えてくる、ということだと思います。

　システム部門の方が実装手段を全く分からなくていいわけはありませんが、もう1つ見逃せないのは、その事業部門との議論の中に、下流を担当するエンジニアも参加させていたことです。

　この辺りまで踏み込めるユーザー企業はざらにないかもしれませんが、これくらいのことをやると、変更が少なくコストが抑えられ納期遅延も無い、ユーザーとベンダ、もしくはSIerがWIN-WINの関係になれるのだと思います。

高橋さん丁寧な返信有難うございます。
非常に勉強になります。
高橋さんの趣旨がよく分かりました。
高橋さんの仰るとおりで、要求が複雑な場合、要求を分析するために色々な図を使うのは合理的だと思います。

ビガーです。

このあたりのフェーズでは特にはヒトというか「キーマン」を如何に抑えるかが重要と思います。
その手段として、関与者利害関連表なるものを使うんだろうなと思いました。

WHYツリーなるものも興味深いですね。おっしゃる通り、トップから詳細化する中で
迷いが出たときに事実を収集するというのは基本です。
如何に効率よくやるかが腕の見せ所でしょうか。

セブンイレブンの話、絶対にそうあるべきです。
どんな手法を用いようともエンジニアが要求の源泉を理解できるような状態でないと
意味あるシステムなどできないし、顧客が満足するモノにならない可能性が高い。
要求を整理するエンジニアだって自分たちの作業に価値があると判断されるのは、
結局出来上がったモノである思います。

まぁ、モノ(クラウドサービスなど)は使いどころで選択できるようになってきたから
一概に言えなくなってきたとは思いますが、サービスという形であってもモノを創っていくことの
価値は不変だと思います。

要は、エンジニアリングに最も価値がある(これは完全な主観です)のは今後も変わらないから
エンジニアの方々もこの辺りの話を勉強する必要があると云いたいのですが、
その辺りを高橋さんのコラムと今後リンクさせてもらいたいと考えています。
失礼しました。

ビガーさん、

　ありがとうございます。
システム構築に対する技術的アプローチも重要ですが、言われるように対顧客視点で誰がキーマンかを認識してうまく進めるのも同じくらい重要ですね。単なる窓口で虚勢を張る方も結構いるので、過去に何度見誤って自分の眼力に愕然としたことか・・・。

　そのキーマンをターゲットしマークしていくのは、アーキテクトかPMか、もしくは営業かという役割の話もありますが、大きく網を張ることができるのがコンサルタントと言うことができると思います。こちらの戦力や体制を見て最適な動き方ができるセンスを持つ、ということでしょうか。

これは要望です。
次回の予告を見てふと思ったのですが、そういった表があるという事や書き方だけではなくて、実際のプロジェクトでやる「根回し」などの生臭い現実なども書いて欲しいです。

インドリさん、

　了解しました。

うまいタイミングで現場感のある話を挟みたいと思います。

有難うございます。
楽しみにしています。