大学における研究者，大学共同利用機関の学術公共事業，情報基盤開発

　大学の教育研究者は自らの学術成果を広く普及させ社会貢献をしなければならない状況が明白になっている．同じ分野で，一方は教育研究フィールド，一方は事業フィールドという役割分担の中で，教育研究から事業への経路で知識移転をし，結果を事業から教育研究へフィードバックする流れをなして協調してきた．その協調の流れを加速して社会の発展をより強力に推し進めることが経済不況の中で期待されている．
　産官学の区分けの中で，学術公共事業は税金を利用した行政の中に位置づけられている．学術政策は，大学や研究機関の学識経験者が行政官僚のマネージメントの中で議論をして決定される．大学共同利用機関法人の一つである国立情報学研究所が事業として担っているのは，大学や国の研究機関の図書館や情報基盤センターと連携して学術情報基盤を形作ることである．
　最も共同利用機関として手をつけやすいことは，上級官庁から事業政策に付随する事業費を調達して，各大学の要望となるような意見を集約・議論する場を設け，決定事項に応じて事業を推し進めることであろう．今のところ，行政の意思決定の方向性は上級官庁からの指揮監督に基づく指示ではなくて，実働組織自体の判断で動くように仕向けられている．大学の学術情報基盤に関しても，各大学が自立して，そして，協調していくように仕向けられている．そのため，共同利用機関法人としては何も意思決定をしないという，強烈なメッセージが今のところ発信されている．
　大学の情報基盤センターは，計算資源，計算機ネットワーク基盤，大学間認証基盤を構築し，図書館は，図書と目録，アーカイブ（機関リポジトリ）を構築している．また，博物館も，図書館と類似の活動を有している．大学共同利用機関としては，これらの活動に関してあくまで意思決定の場と資金の提供であって，国立情報学研究所は特に図書館に対して何も意思決定しないという姿勢は相変わらず変わらない．
　さて，大学共同利用機関という組織として最低限行わなければならないことが，上記の意思決定の場と資金の提供であるのであるが，そのような事業体が自ら行う情報基盤開発として行うべきことは何であろうか．ここでは図書館寄りのコンテンツ事業および情報基盤開発について考えてみる．
　信頼性のある知識や知見といったときに，それが迅速な流通を前提としたとき，論文や図書の形式をとるのは一般的で，手元にあるPCや携帯電話などを用いて閲覧するというのは即時性という意味では好都合である．この知識流通の形式はゆるぎないものであり，学術情報流通の関係者は，この方向に標準を合わせて活動をシフトさせている．たとえば，研究者は雑誌論文を，紙メディアをベースとしながらも，ネット上からダウンロードしてはプリントアウトしたりまたは画面上で閲覧したりする．Webというコントロールの存在しない情報発信形式から必要な論文を探し出すには，インターネットのIPアドレスと80番ポートをやみくもにクローロングして，その取得したデータをもとに個々の研究者に必要な情報の候補をダイナミックに提供するという情報検索サービスは必要不可欠であった．紙メディアからWebに論文や図書の媒体がシフトしたおかげで，そのアーカイブの受け皿である図書館は機関リポジトリを始めざるを得なくなった．また，出版社も同時に電子出版物をWeb上で提供したため，図書館はそれらへアクセスするための図書館としての契約と関係する組織メンバーへの利用促進をせざるを得なくなった．
　これまで，大学共同利用機関である国立情報学研究所が図書館系事業として行ってきたことは，目録システムによる図書の整理と貸借の促進，機関リポジトリの普及促進，電子出版物の契約・管理・利用促進のためのシステム導入実験である．学会とのかかわりの中では，SPARCという国際学術情報流通基盤整備事業と，学会論文電子出版支援および検索・閲覧サービスを含めたCiNiiシステムの提供が主なものである．
　Web上への論文の出版と検索サービスの提供が基本的なシフト先の骨格であって，これに付随する技術的・制度的な要件は方々で研究開発されている．国立情報学研究所の研究スタッフはサービス開発のための身近なシードとなりうる．
　わが国には，国立情報学研究所と類似のサービスを行っている事業体が存在する．科学技術振興機構（JST）である．関連事業の中心は，やはりWeb上での論文の提供であって，そこにかかわる事業性質は共通である．異なるところは事業主体の出自にかかわる．国立情報学研究所は大学図書館，JSTは財界の資料センターである．出自の差として，国立情報学研究所固有のものとするところは，総合目録，および，機関リポジトリであろう．
　では，国立情報学研究所がWeb上での論文の提供という骨格に対してなすべき活動は何か．この事業に限定すれば，実のところJSTは優位にある．関連スタッフ，事業費という観点からすると，国立情報学研究所の10倍の予算がJSTにあてがわれている．しかも，JSTは中国ビジネスをも展開している．一方で，国立情報学研究所が優位な点は何か．それは研究開発基盤である．大学が先に指摘した産業界や官界に対する貢献を加速していく必要があるから，身近な研究者の成果を積極的に事業基盤に取り入れて，実証してみせることはやりやすいに違いない．その上で確実な事業を展開する出口となる道を見つけるのである．

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

　ソフトウェア開発案件を外部の開発業者に任せたいとき，スコープの確認は大変重要であることを再認識させられた．発注者側が開発仕様書を書いたとしても，それが伝わらない事態というのがある．発注者としてのわれわれが当然の作業と思っていたことが，開発業者では当然ではないらしい．よく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データの構成が決定されたのち，検索エンジンを中心としたシステム開発がそれらを受けて動き出す．ここで，それぞれのサブチームはプロダクトに責任を持った実務担当が一人いて，それをサポートするように必要事項のネゴシエーションを行う．サブチームが全体のチームを構成する要員であるという自覚が存在すれば，サブチーム間のネゴシエーションはスムーズに行われ，要求仕様の変更に対する許容度を高く維持できる．結果としてアジャイルソフトウェア開発が可能となる．これが，ひとたび責任のなすりつけ合いのような状況に陥れば，どこが主導権を握るか，言った言わないの攻防が予想され，お金の流れと一致した一通りの意思決定ルートだけが確保され，さながら後戻りの許されないウォーターフォール開発となる．
　アジャイルソフトウェア開発を実践すること，それは究極的にユーザーの要求を反映させた適時に役立つソフトウェアの開発可能性を高めることであり，チーム全体の場のエネルギーをどのように維持していくかがプロジェクトの成否のカギを握る．したがって，全体を統括するリーダーの力量とそのチーム構成員との良好な関係は必要条件である．