ビジネスとしてのソフトウェア開発？

　ソフトウェア開発案件を外部の開発業者に任せたいとき，スコープの確認は大変重要であることを再認識させられた．発注者側が開発仕様書を書いたとしても，それが伝わらない事態というのがある．発注者としてのわれわれが当然の作業と思っていたことが，開発業者では当然ではないらしい．よくSLA（サービスレベルアグリーメント）が重要というが，作業前にこれをよく決定しておかないといけない．しかし，事前の決定といってもやはり決定事項というのは変更される場合や追加される場合，後で明示される場合は多々あって，最終的にはあらかじめの契約金額に対してどれだけ誠実にワークをしたかということをもって，発注者も開発者も納得してプロジェクトを終了するということに尽きるのであろう．
　これがビジネスのこととなった時，どうも性善説では語れない何かがあるのかもしれない．開発業者は意図して誤解を生じさせてプロジェクトを混乱させ，また平然とプロジェクトを立て直す．発注者側の意思決定は，プロジェクトが終了するまで続く．発注者側の意思決定は包括的にはプログラムのような形式的完全系を細部までは持っていないので，必ずどこかで不整合が生じる．この不整合を顧客のミスだと指摘して，追加作業として位置付けて追加料金を請求する．これを受け入れない顧客は，顧客の目的である最終プロダクトを調達できない．当然だが，プロジェクトがとん挫すれば開発者も契約不履行で料金を請求できない．さて，このビジネススタイルは一般的なものとなり得るのか．長期的に見た場合には，このようなビジネススタイルは顧客への信頼を失い，ブランドの低下をもたらすのではないか．

仕事の切り分け

　ソフトウェアを開発するときの仕事の切り分けについて考えてみる．我々はいわゆるサービス提供者として位置づけられているので，基本的にはサービスの仕様を決定することが主たる仕事となる．サービスをどう実現するかは，それをうけて開発する業者に任される．しかしながら，時間的制約から，われわれ自らがサービスを構成するシステムをいくつかに切り分けて複数の業者に同時間的に発注を行うことがある．これにかかる大きな制約は，国の税金を使った事業である場合の金額規模に応じた事務処理の量に起因する．金額が大きくなれば受注者の公平性を担保するために，より発注手続きに時間をかける．システム開発そのものが大規模・短納期を要求するならば，いっそのこといくつかに仕事を分割してしまえばそれで容易に大規模と短納期を実現できると思うかもしれない．ところが，ソフトウェアシステムは，分割すればするほどシステムインテグレートにかかる労力を増大させてしまう．
　ことの複雑さは，仕事によって切り分けられたサブシステム同士をどのようにつなぐか，つなぐとしたらどの業者がサブシステム間インタフェースの接続方法に対して責任を持つのかということのネゴシエーションを要求する．我々の経験では，ネゴシエーションは，仕事の押し付け合いとなるのがどうも基本的な展開らしい．融通をきかせるというのは，ビジネス上個々の業者間ではありえなく，むしろ仕事を分割した発注者しかそのインセンティブを働かすことができないのかもしれない．
　発注者サイドとして，分割した仕事のインテグレーションをどのように実現するのか，その役割分担方法は2つある．ひとつは発注者自らがインテグレーションに必要な設計に手をかける方法，もうひとつはもっともシステムインテグレートを高次のレベルで実現する仕事を担う業者が行う方法である．いずれにしても発注者がネゴシエーションの主導権を発揮しなければならない．

要求仕様の方程式

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インタフェースの策定を担い，この仕様の具体化をするものであった．開発の意思決定は基本トップダウンに行われ，最短時間で具現化するというものである．ソフトウェアの仕様は，最高の価値を生み出そうとして概況に応じて変化を要求する．変化に耐えられるチームが最高の成果を生み出すポテンシャルを持つ．このポテンシャルは，チームの士気と密接に関係していると思われる．士気が低下していると，変更に耐えるエネルギーが備わらない．今回，要求仕様の揺れから，スケジュール超過の予兆が出た．士気の低下とあいまって，プロジェクト計画の見直し要求が起こったのである．しかし，上席マネージャーによる，高い意識を保つようなエネルギーの注入により予定超過は回避された．実働部隊の士気は，上席マネージャーの助けによって高まるのである．

書き込みのテスト

ブログの書き込みテストをしてみる．
強調とイタリック
赤と青