要求仕様の方程式

S⊕W(Res,Coh)⊦R
Ec⋃Pc⊦Coh

ただし，S：仕様，W：重み，Res：責任，Coh：合理性，Ec：環境視点合理性，Pc：製品視点合理性，R：要求仕様

クリエイティブリソースの配分

　WebUIの要求仕様の策定やデザインを行うとき，特にユーザー中心設計を行っているときには，常に具体的なユースケース（シナリオ）を取り上げて情報のレイアウトとインタラクションを定義していく．我々のプロジェクトで対象としているのは検索サービスであるので，複数のユーザー像とそれぞれに応じた情報のレイアウト，検索プロセスのインタラクションを決定していく．複数のユーザー像の中でも，検索の一般利用者とエキスパートとは明らかに2分して想定でき，2つのユーザーの検索プロセスは異なることを想定している．たとえば，検索対象から検索結果を得るための検索キーワードの指定や検索結果集合に対する追加的な絞り込みの方法などが異なるのである．しかし，実際にはちょうど中間のユーザーも存在するであろう．したがって，状況によっては双方のユーザーの検索プロセスをスイッチして許容するようなシステムである方が検索プロセスという点だけに着目してみればよりユーザーの思いを妨げない．ちょうど地図を画面上で表示するときにLOD（Level Of Detail）を考慮する方法が有効であるのと同様に，ユーザーの心の状況に応じて検索プロセスをスイッチできることはより使い勝手が良いといえるのではなかろうか．
　このような発見はユーザー中心設計を取り行って議論をしている最中に出てくることがある．これがいつ何時気付きとなって現れるかどうかは予測できない．このとき，プロジェクトに与えられた時間は限られているため設計変更をするかまたは見送るかの決定をしなければならない．根本的な設計変更は付随する細部の変更を余儀なくされる．根本的な設計変更にかかわるクリエイティブなアイデアの創出は設計の初期の段階で出しつくしておきたいものである．

トラッキングシステムの状態遷移

　複数の組織がかかわるようなソフトウェア開発プロジェクトでは，よく顧客要求を整理するためにエクセルを用いた要求管理が行われる．要求案件が発生した日時や要求内容，起案者，回答，担当，案件の処理状態などが細かく記録され，案件解決漏れがないように管理される．もちろん，このような要件整理の方法は，顧客要求の整理だけでなく，ソフトウェアバグ管理や運用管理にも使われる．細かな要求をすべてこなしていかなければならない多くのプロジェクト管理に必須のツールとなっている．
　エクセルの次に変わる媒体は，CMS（Contents Management System）ベースのトラッキングシステム(Issue/Bug Tracking System)である．Wikipediaにはその比較表があり(http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems)，我々のプロジェクトで利用しているトラッキングシステムもそのうちの一つとして含まれている．
　このようなツールを用いて個々の案件を一覧して整理し，取りこぼしの無いようにすることは人間の記憶メカニズムの観点からすれば必然であったといえる．ソフトウェアに関して言えば，要件そのものはソフトウェアが作られる背景となる利用シナリオを基に作られ，一つ一つのシナリオ（ペルソナ）を抽象化することによって汎用性のある利用形態を前提としたソフトウェアを作ることができるであろう．実際に汎用性があり実利的なシナリオを作ることにはコストのかかることであるため，コスト最適をとって個別の想定シナリオに特化したソフトウェアが作られることが一般的であろう．そう考えれば，個々の案件はプロジェクトの業務に個別的であることが多く，ソフトウェア開発のドメインが同一であったとしてもその数が減ることはないであろう．個々の案件を長期記憶にとどめることができないため，このようなトラッキングシステムを利用することになる．
　トラッキングシステムを用いる際に，案件の状態を遷移させるかどうかを決定するときがある．とくにクローズするかどうかを判定することは，我々のミーティングにおいて気を使う一つの事項である．問題が解決していないのに解決したことにしてしまうと，成果として出てくるソフトウェアの品質に打撃を与えるからである．もしくはプロジェクトそのものの手戻りを誘発するかもしれない．しかしながら，すべての案件に対して十分な議論をつくす時間は限られている．発注サイドとして案件の状態遷移に同意する作業はプロジェクトの生命線を制御していることなのである．

アジャイルソフトウェア開発が可能なチームの特質

　アジャイルソフトウェア開発(http://www.agilemanifesto.org/)とは，たとえば著名なKent Beckの「エクストリームプログラミング（XP，またはeXtreme Programming）」(http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0201616416)の前提となる開発スタイルのことであり，顧客の要求を徐々に明らかにそして適時に要求仕様に変更を加えて，顧客の意思決定をサポートするようにプロトタイプシステムに反映させる漸次的反復型の開発プロセスを意味する．
　ソフトウェアに対する要求仕様を反映させるタイミングという観点からすると，アジャイルソフトウェア開発とウォーターフォールモデルは開発プロセスとしては対極に位置する．要求仕様の決定から伝播する意思決定プロセスの結果がソフトウェアであると考えれば，開発チームの構成員が大規模になれば，意思の伝達コストもしくはコミュニケーションコストを考えてウォーターフォールモデルによる開発プロセスを取らざるを得ない．一方，開発チームの構成員が比較的小規模であれば，アジャイルソフトウェア開発もしくはウォーターフォールモデルのどちらかを選択することができる．
　我々のソフトウェア開発チームは，3つのサブチームに分かれており，WebUI，検索エンジン，XMLデータ生成をそれぞれ担う．要求定義の順序からいえば，WebUIとXMLデータの構成が決定されたのち，検索エンジンを中心としたシステム開発がそれらを受けて動き出す．ここで，それぞれのサブチームはプロダクトに責任を持った実務担当が一人いて，それをサポートするように必要事項のネゴシエーションを行う．サブチームが全体のチームを構成する要員であるという自覚が存在すれば，サブチーム間のネゴシエーションはスムーズに行われ，要求仕様の変更に対する許容度を高く維持できる．結果としてアジャイルソフトウェア開発が可能となる．これが，ひとたび責任のなすりつけ合いのような状況に陥れば，どこが主導権を握るか，言った言わないの攻防が予想され，お金の流れと一致した一通りの意思決定ルートだけが確保され，さながら後戻りの許されないウォーターフォール開発となる．
　アジャイルソフトウェア開発を実践すること，それは究極的にユーザーの要求を反映させた適時に役立つソフトウェアの開発可能性を高めることであり，チーム全体の場のエネルギーをどのように維持していくかがプロジェクトの成否のカギを握る．したがって，全体を統括するリーダーの力量とそのチーム構成員との良好な関係は必要条件である．

ソフトウェア開発現場の士気

　発注者の立場でソフトウェアの開発を行っている．発注者と受注者により構成されるチームでのミーティングは開発を進めるためのマイルストーンの役割を担い，常に開発のドライビングフォースとなっている．この場における発注者の仕事は，根本的には仕様の策定と開発成果のチェックである．
　発注者も受注者も成果物に対して責任を持ち，成功に導きたいと願っているはずである．ところが，ソフトウェア開発プロジェクトの混乱と失敗がかなりの割合でおきる．よく引用されるStandish Group(http://www.standishgroup.com/)のChaosという最初の報告書(1995)は，31.1%のプロジェクトが開発の途中でキャンセルとなり，52.7%がコスト超過であることを示している．逆算して，残った16.2%が，予定通りのコストおよび納期で進められているということである．継続的に調査報告されている．（http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS）
　我々のチームにも，Standish Groupの報告が示すような“成功のためのトップ10の要因(Top Ten Reasons for Success)”を意識する出来事があった．今回の開発チームは，Webインタフェースの策定を担い，この仕様の具体化をするものであった．開発の意思決定は基本トップダウンに行われ，最短時間で具現化するというものである．ソフトウェアの仕様は，最高の価値を生み出そうとして概況に応じて変化を要求する．変化に耐えられるチームが最高の成果を生み出すポテンシャルを持つ．このポテンシャルは，チームの士気と密接に関係していると思われる．士気が低下していると，変更に耐えるエネルギーが備わらない．今回，要求仕様の揺れから，スケジュール超過の予兆が出た．士気の低下とあいまって，プロジェクト計画の見直し要求が起こったのである．しかし，上席マネージャーによる，高い意識を保つようなエネルギーの注入により予定超過は回避された．実働部隊の士気は，上席マネージャーの助けによって高まるのである．