はじめに

要求仕様をまとめるのは顧客の仕事だとか、SEの仕事だとかばかり言って、何も動こうとはしない頭の固い開発チームのなんと多いことでしょうか。自分たちが相手とする顧客ないしはベンダー側SEで要求仕様を作成する能力がまだ残っているのかどうかをよく見極める必要があります。

能力がない相手に対して、いつまでも要求仕様が出てくることを待っていても何も得るものはないでしょう。失ってはいけない重要な時間が失われていくだけの結果を招きます。あなたならどうしますか。

#15：仕様調査法のいろは

合格点をつけられる要求仕様書はほとんどありません。それらの内容は多くの不明点や疑問点を必ず含んでいるという前提に立って以下のことを実行する必要があります。

• まずは仕様の全体像の把握から始める
• 疑問点・不明点を発掘し、その解消に向け要求元に対して積極的にアプローチする
• 仕様検討の段階で要求者と徹底的に仕様を検討する
• 仕様決定のQ＆Aは直接対話で確認する
• 不明なことは直ちにわかっている人に聞く
• 要求仕様の背景や意味を必ず明確にしておく
• 習得した内容を、ドキュメントによって他のメンバーに伝える
• 早期に仕様を凍結する
• 基幹の仕様が未決定なら開発に着手しない

それでも決まらない要求仕様。

着眼大局、着手小局

全局のことでも、また局部、局部のことでも、その一手の差を慎重に、そして最善をつくす人が、“⁠勝ち⁠”にゆくわけで、一手ぐらいなどといって、気楽にしとるやつが、結局は敗北につながる。せんじつめていえば、そのもっている欠点を長所にする、これがプロの芸ということになるわけです。イチかバチかのやけっぱちみたいなことをやるのを勝負師という人があるが、これは間違いです。そういうのは勝負師とはいわない、賭博師という。

升田幸三、将棋棋士、『⁠勝負―人生は日々これ戦場』

#16：ぶれない軸～コンセプトの効用

コンセプトはものごとの全体像を一言で表したもので、そのものごとの本質を表している。たとえば新しいシステムの開発の基本コンセプトが“⁠オープンソフトウェアの採用による高品質開発⁠”というふうに明確になっていれば、間違ってもシステムの中核部分に独自ソフトウェアを使用するというとんでもない間違いは起こらない。

ものごとの大小を問わず、その基本コンセプトを最初に明確にしておくことは不要な間違いやリスクを避ける効用がある。

叡智への最初の一歩は、すべてのものに疑問をもつことだ。そして最後の一歩は、すべてのものと折り合いをつけることだ。

ゲオルク・クリストフ・リヒテンベルク

#17：傑出することよりも高度の平凡さを

何かをやろうと思えば、たとえ他の人より出遅れていたとしても遅すぎることはない。肝心なのは、それを継続することにある。一気にやろうと力まず身近なことから一つずつ取り組めば必ず成果は上がる。

仕事には知恵も才能も大事。しかし、より大事なのは平凡、些細なことを疎かにしない心がけです。

松下幸之助、松下電器創業者

#18：大事なことを聞き逃している～空気読みの空気知らず

論語読みの論語知らずということと同じように、物事の本質を読もうとせずに自分の利を中心に立ててから相手の空気を読もうとしても、相手の真意は見えてこない。相手の言葉が理解できない場合、それに先立つ自分の発言に独りよがりがなかったかどうか点検してみることだ。相手のメッセージがわからないこと自体が重要なメッセージである場合もある。

5分間の法則

依頼主はつねに自分の問題の解き方を知っていて、その解答を最初の5分間に口にする。

G.M.ワインバーグ、『⁠コンサルタントの道具箱』

#19：アジャイル開発

Agile（俊敏な）開発は、要件の変更や追加を積極的に受け入れる開発プロセス、変化即対応型プロセスである。ユーザとのコミュニケーションをベースとして、必要な機能を一緒に決めていこうとする思想が流れている。型にはまった無味乾燥なプロセスや取り決めに縛られるのではなく、開発者のモチベーションや相互のコミュニケーションを重視し、本当に必要なソフトウエアを短期間で、かつ柔軟に構築するための考え方を備えた開発プロセスである。つまりコミュニケーション重視の人間中心のプロセスである。ウォーターフォール開発の原点も最初はそのようであった。

アジャイル開発の4つの価値

• 価値1：プロセスやツールの価値を認めつつも、個人とその相互作用を重んじること
• 価値2：包括的なドキュメントの価値を認めつつも、動作するソフトウェアを重んじること
• 価値3：契約交渉の価値を認めつつも、顧客との強調を重んじること
• 価値4：計画に従うことの価値を認めつつも、変化への対応を重んじること

アジャイルソフトウェア開発宣言

#20：どこまでも譲れるわけもない（時間編）

物事の実行には一定の時間が必要だ。必要な時間は実行する者や組織の能力に依存するが、誰がやったとしても、それ以上の早さではできないという限界がある。限界を超えた行為は必ず破綻する。限界を超えた要求をする者は破綻の責任を負う必要があり、破綻することを承知のうえで実行した者も共に責任を免れ得ない。

要求を受ける立場にあるものは、どこまでも譲れるものではないという強い認識を常にもっておく必要がある。

責任について考える

自由と義務を均衡させる手段の第一歩として人間の責任に関し、もう一度自分の頭で何をすべきか個々人で考えなければならない。日本人全体を覆う無責任主義下における思考停止傾向から脱却し「考える日本人」にならなければならない。

朝日新聞 1998/1/18

#21：日本語文章のあいまいさを避ける

論理性や正確性が要求される業務文書においては、日本語の豊かな情緒性やあいまいな表現が大きな障害となっており、以下に示した注意点を押さえておく必要があります。

• 主語がない文章には主語を書き加える
• 可能な限り短い文にする
• 並列的な表現は箇条書きにする
• 時間軸にて整理したチャートで現在・過去・未来の時制を明確にする
• 読み聞かせで聞き手がきちんと理解できるか
• 単位・期限・期間・対象範囲などの基準を明確にする
• ％表記は何を100％としたのかを明記する
• 程度表現を避け数値で表す（例：すごく、適当、ちょうど、およそ）
• 強調表現を避け数値で表す（例：ちゃんと、しっかり）
• 推測表現を避け数値で表す（例：～くらい、およそ～）
• その他の曖昧表現を避ける（～の予定、できるだけ～）

日本語と英語の違い

日本語	英語
あいまいで明言を避ける	直接的、断定的な表現
省略語（主語などの省略）が多い	省略語が少ない
文が長くなりがち	比較的簡潔
無生物は主語になりにくい	無生物でも主語になる
結論（話題の中心）が最後	結論（話題の中心）が最初

出典：日英翻訳のコツ

おわりに

要求仕様を決定できない理由は、次の4つが挙げられます。

• 仕様知識の低下
• 外注依存の傾向
• プロジェクト・マネジメント力の低下
• 開発能力の低下

対して、ベンダ側にて必要な行動は次のとおりです。

• 仕様ノウハウを学習・蓄積する
• 一定の割合で設計・製造を実行し、開発技術力を保持しておく
• 外注まで含めた統合的プロジェクトマネジメントを実行する

さらに、下請け側で取るべき必要な行動を挙げておきます。

• 仕様ノウハウを学習・蓄積する
• 設計能力を進化させる
• 製造能力を進化させる
• 評価能力を進化させる
• プロジェクトマネジメントを実行する

要求仕様の精度はプロジェクト成功の必須要件のひとつであり、それは要求する側および受ける側双方の同時連携が必要となります。これは「相互義務の履行」という重要な組織行動規範のひとつだと言えます。