仕事の切り分け

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

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

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