実践ソフトウェアエンジニアリング 第７章の感想

昨日に引き続き実践ソフトウェアエンジニアリングの感想を書いていきます。今日は第7章、要求エンジニアリングです。

大規模案件の要件定義はそんなに経験がないですが、細かい機能追加案件は千本ノック状態でやっています。第６章の原則にも通じるところがあり、今日もやっぱり耳が痛いなあという感想になるのでしょうｗ

要求エンジニアリングとは

現場で要求エンジニアリングという言葉を口にしたことも耳にしたこともありません。今の会社では「要求管理」、以前の会社では「要求・要件定義工程」を広く指していたかな。 以前いた会社で要求工学を教えてもらって、REBOKベースでガイドラインを作るようになったので、に関する「知識」はまああるほうかなと思います。

この節にあるプロセスの中では自分は圧倒的に「精緻化」が難しいと感じています。REBOKでは要求分析。まだビジネス目的や業務要求から落とし込んで行ける時はいいんですが、自社製品のリプレイスとかなると要求が完全に仕様になっているので頭を抱えます。詳細化されまくった数千の要求をマインドマップで分類し続けた日々を思い出されて胃が痛くなるｗ

重要なのは、設計を始められるよう、適切に問題を記述することである。不必要な水準まで詳細化しようと、思い悩むべきでない。

そう、詳細化は設計に入ってからでいい。でもどの要素にこの要求はぶら下がるのか？ってことが見えてないと漏れそうで怖かったんですよね。

仕様化をどこまでするのかも悩ましいところ。

より理解しやすい一貫性のある形式で要求を表現できるようにするため「標準テンプレート」にしたがって仕様を作成するべきだと提案されている。だが、仕様の作成に柔軟性が求められることもある。

要件定義書のフォーマット作成を何社かで行ってきたので、これを読んでちょっとホッとしました。フォーマット化すると「枠があることしか書かなくなる」と一部の管理者層には言われていたので。スキルがある人はどんなフォーマットでも書けるので、枠があることで書くことが増えて面倒に思われましたが、多くのメンバーには「書くことが明確になって内容に時間を使えるようになった」と言われました。項目レベルの漏れがなくなりますしね。

要求の妥当性確認チェックリスト、凄く助かります！
同様の要求レビュー観点表は構築しているのですが、そこにないものがありました。例えば、「相互に関連する要求は相互参照表のような仕組みで明示しているか」これ、ほんとあったほうがいい。たくさんあると作成するの大変でうんざりするけど、ハイレベルで作ればそう多くはならないから。（でもハイレベルだとマトリクスに〇が付き過ぎるんだけど）

トレーサビリティに関するチェックが多く、やはりそこが重要だよな、と再確認できました。最初は頑張って作るんだけど、追加や変更の時に更新忘れてナアナアになっていくのも反省。。。

土台の整備

じゃあ要求聞いていきますねー、では始められないのが要求獲得。誰に聞くのか、多数のステークホルダーの誰を優先するのか、決定権のある人は誰か、をとらえておかないといけない。この辺はPMBOKのステークホルダーの特定に関するツールが有用ですね。
といっても、これ最初から全部捉えるのは結構難しいと思ってます。
「他に話をしたほうがいい人をご存じですか」は、いい質問ですね！あ、でも「あの人は聞かなくていいです」が実は影のキーマンでした、ってことも経験あるけどorz

最初の質問、に書いてあることがいい内容だなぁ。ここ刺さりました。ああ、聞けてないなと思って。表面的なヒアリングしかできてないな、って痛感しました。

要求収集

REBOKの要求獲得と同じと捉えていいのかな。
要求収集ミーティングの指針に記載されていることはできているつもりだけど、「難しい人」がいると「自由な発想を促進できるインフォーマルな形式」になりにくい。その人の要求や要求仕様に異論を唱えにくく、「じゃあそれで」って言われたものの、他の人には不要で面倒な仕様ってことも多々ある。それを察知しても対応に迷うよね。。。

「成果物は要求獲得参加者全員でレビューしなければならない」って、それやってないな（＠＠；
一堂に会せるならともかく、全く別組織のステークホルダーもいるじゃない？それこそ顧客と自社の製品戦略室なんてある種相反した立場にいるわけで。顧客側だけでも、「これは正直言いにくいんだけど」みたいな要求もあったりして、経営層のレビュー前に表現を変えたりすることもあったな。

ユースケースの作成

ユースケース作成のための質問いいですね！これ、記載ガイドに使う！！

ユースケース記述のサンプルもありがたいですね。うちはアクターとシステムの列を分けた形式で書いています。その方がレビューしやすい。技術の人が書くとシステムが連続するからすぐ怪しいのを発見できるｗ

よくできたユースケースは分野が違ってもほんと参考になるので、ネットでも上手なのを見つけたらすぐコピーして保存しています。

分析モデルの構築

うちは要求モデルで書くのは、ユースケース図、ハイレベルのクラス図（これを概念モデルと呼んでる？）、アクティビティ図くらいでしょうか。
画面に関する要件の箇所にハイレベルの画面遷移図を載せたりはするかな。

複数のプロジェクトで要求エンジニアリングを行ったことがあれば、どんなプロジェクトにもそれぞれのアプリケーションドメインに共通して発生する問題があることに気づいているはずである。アプリケーションドメインのモデリングに、再利用可能な解決手段（クラスや機能やふるまい等）を提案するのが「アナリシスパターン」である。

お恥ずかしながら、アナリシスパターンというものの存在をよく知りませんでした。特定のドメインでたびたび出てくるモデルをパターンにしたもの、なのかな？うちみたいな業種特化の業務システム作ってるとこにはめちゃくちゃ有用な考え方なのではないのか。。。すぐ調べます。。。

要求に関する交渉

難しいよね・・・（としか言えない）

要求の監視

PMBOKの「スコープのコントロール」に近いですかね。スコープクリープ（承認を得ないスコープ拡大）を防ぐというよりは、日々改善されていく機能や仕様がそもそものニーズと合致しているのかを監視する意味合いが強そうです。

そうですよね～、動くものを目にすると、「ここはこっちの方が使いやすい」と思いつきやすいですが、それってそもそものシステムの目的に合致してますっけ（例えばメンテナンスしやすい、とか）ってことって、誰かが監視しないと続々出てきそうです。ビジネス目標の追跡、って設計に入ってしまうと忘れますからね・・・。

要求の妥当性確認

うちは、要求獲得（要求事項一覧作成まで）、要求分析（モデル作成まで）、要求仕様化（要件定義書作成まで）でそれぞれレビューしてその時点で妥当性確認もします。特に一貫性、整合性、要求→機能要件の漏れ、あたりを重視しますが、ここのレビューができる人は少ないですね。なので、記載してあるレビュー時の質問項目は非常に有用だと思いました。この質問でレビューアトレーニング作ってみようかな？

第７章の感想まとめ

ポイントがまとめてあって非常にありがたいです。ただ、これだけで落とし込めるレベルの人は多くはないかな（少なくともうちには）。要求アナリストとかシステムアナリストとかって方なら生かせるかと思いますが、「こんど要件定義やらせてもらえることになりました！」って若手にはしんどいかな。ステークホルダー分析みたいなプロジェクトマネジメント領域も出てきますしね。

REBOKと併用するとよいと思いました。

明日は８章かな？これから考えます。