以降、4つの事例をΛVモデルのケーススタディとして考察してみます。 ケース1:伝統領域でのソフトウェア開発会社 • 中堅の独立系ソフトウェア開発会社の事業部 • 数十人月〜百人月程度の中規模案件の請負受注が多い。 • 2005年頃よりアジャイルプロセスの味見(なんちゃってアジャイル) • 2007年頃よりアジャイル・ソフトウェアセル生産方式を確立 • 日常的に、タスクカード(ソフトかんばん)、バーンダウンチャート、朝会、ふりかえり等のプラクティスを行っている。 • 新人は定常的に採用しており、アジャイルプロセスの実践チームは、人材育成のために研修的に参加することもある。 • 進化型のフレームワーク(Groovy/Grailsなど)やプロセスの構築も継続的に行っている。 〔プロジェクト例〕 • 請負契約による約1年程度の受注 • 顧客から要件定義書が提示。要件定義の曖昧や不備などがあるが、基本的に変更はない。 • ソフトウェアは、実験などの測定データを管理する目的で使用され、顧客側のビジネスに直結するものではない。 • 開発チームは10名程度。内5名がエキスパート、残りが新人。 • 開発プロセスは、インクリメンタル(段階的拡充)型開発プロセスとし、1〜2ヶ月程度のイテレーションを繰り返すものとする。 • イテレーションごとに顧客側の確認をとり、要件の変更もある。従って、安定しているもの、重要なものから実装していくこととする。 • 実装環境は、Java, Groovy, Struts, Spring, Hibernateなど。デザインパターンやアスペクト指向設計なども行う。 • テストは、イテレーションごとに回帰テストを行う。 顧客と開発企業との間の組織境界は、ΛVモデルにおける実世界と計算機世界との境界と一致しています。従来の典型的な請負受発注と考えられます。 時系列でプロセスを俯瞰してみると、以下のようになります。 ソフトウェアの価値は、クライアントの世界や意味Sに関わることです。開発企業からは見えません。要求Rは、最初にクライアント側から文書の形で提示されます。これを受けて、開発企業では基本設計やそれに続く詳細設計が進められます。インクリメンタル型の開発プロセスをとるために、最初の段階で、全体の要求に基づいてイテレーションの分割を行い、各段階での要求を明確にします。 それぞれのイテレーションは、決められた要求Rn(n=1〜3)に対し、実現Inを開発します。Rnを意味付けている意味Snは、おそらくこのソフトウェアに関わる全体の意味Sの一部です。テストTnは、実現Inが要求Rnを満たしていることを確認する行為です。Inの実行による認識の変更も発生し、これは、次のイテレーションの要求Rn+1に反映されます。 イテレーションnとイテレーションn+1との関係は、前者の拡充が後者という位置づけです。実現は、Inを拡充してIn+1とします。Tn+1は、Tnのテスト項目を回帰的に適用することになります。 最終イテレーションの結果が、このプロジェクト全体の結果となります。 ケース2:Webサービス領域のソフトウェア開発会社 • アジャイルプロセスを積極的に取入れている小規模のソフトウェア開発会社 • Webシステム開発の分野を得意としている。 • 独自のアジャイル・ソフトウェアセル生産方式を確立している。 • アジャイルプロセスを、より組織化し、より大きな案件も開発できるようにしていきたいと考えている。 • アジャイルプロセスの基本的なプラクティス:朝会、振返り、イテレーション、バーンダウンチャート、週40時間労働などは全て導入している。 この会社のアジャイル・ソフトウェアセル生産の特徴は、タイムボックス方式と呼ばれる固定間隔(2週間)のイテレーティブな方法を取入れている点です。クライアント側から見ると、定期的にリリースを受入れ、検収を行わなくてはならないことになります。イテレーションを継続していき、先々の予想は困難ですから、契約は、本来、保守契約のようなものが適していると考えられます。 もう一つの特徴が、「セル」の導入です。これは所定の作業をこなす仮想的な人格と見なすことができます。「人月からの脱却」という観点では、仕事の工数を「セル・月」で把握するということになります。このように作業(役割)と人的リソースとを切り離すことは、マネジメント上、多くのメリットを得ることができます。 (1)クライアント側に対して人員(人月)を隠蔽することができる。 (2)セルはクライアントからの注文に直接対応しているため進捗が可視化できる。 (3)セルは並行に実行できるため段取りに気を使わなくてよい。 (4)チームメンバは、セルのスループットを向上させることのみに注力すればよく、上位のマネジメントに無駄がなく軽量化できる。 (5)セルの進捗を見てダイナミックに人の割当もチーム内で調整しながら進めることができる。 顧客と開発企業との間の組織境界は、ΛVモデルにおける実世界と計算機世界との境界と一致しています。従来の典型的な請負受発注と同様です。 クライアントからの要求は、いつどれくらいでてくるかは不確実です。アジャイルプロセスとは、明確になった要求(仕様)を、明確になった時点で速やかに実現するということです。 タイムボックスマネジメントによる、ダイナミックな要求とセルによるタスク消化の状況は、以下のように表わすことができます。 クライアント側からの要求は、時々刻々と不確実に出されます。これを注文バックログとして溜めます。これが、クライアントと開発企業との間のバッファとなります。注文は、開発チーム側でセルに割当てられ消化されていきます。注文の量は、波があると考えられ、多くなりそうな時期にはセルをたくさん用意して準備しておきます。 ケース3:ユーザ企業内製のシステム部門 • インテーネットからアクセスする顧客に対して商品案内から契約に至る支援をするWebシステムを継続的に構築・維持している。 • ユーザ企業内製型のプロセスである。 • 営業、業務部門などとのコミュニケーションを密にして、常時、新規フィーチャ、改善要求について検討している。 • プロジェクトという概念は無く、システム部門の約10名の体制で、週1回のリリースを繰り返す方法を採っている。 • 開発チームは、長い年月をかけて成長・改善をしてきており、レベルが高い。 ・文献や書籍の読込みと、徹底した討論をすることによって、チームに導入すべきものを吟味している。 ・システム開発の負荷が少ない時に、育成対象の人材に責任を持たせて業務を遂行することによって、業務ノウハウの伝承を行っている。 • エゴレスシステム開発を実践し、チームメンバ全員がどの部分、どういった開発も可能なようにして(チーム内の)非属人化を図っている。 エンドユーザの提供Webサービスに対する意味、文脈、理解(誤解)などの状況は、営業部門などとシステム部門とがコミュニケーションを密にとることによって、ニーズの把握、既存システムに対する改善項目など、常に的確に把握できるようにしています。すなわち、システムの意味が時間とともに変化していきます。 ケース4:新規領域開拓型研究機関 • 「連想検索」と呼ばれる人間の創造的活動を支援するための新しい情報アクセス方式を核とした活動 • 基礎研究によって得られた「連想検索」の方式に基づくエンジンを開発 これは3回ゼロからコードを書き直す方法で、順次、インタフェースやアルゴリズムを洗練化(約6年程度かけている)。 • 連想検索エンジンを活用したWebサイトの構築をプロデュース。 (書店、図書館、古書店など) • 連想を効果的に、価値あるものにするために、書籍のカテゴリ分類を行う。 これは出版社の編集長レベルの人に2年がかりで作成してもらった。 • 連想検索の効果を実証できたため、複数のサイトを連携して検索を行う仕組みを作り、実現した。 基本エンジンを開発するところは、従来の開発プロセスと考えてよいでしょう。仕様や方式をしっかりと固めてから、コードを書くというものです(次図左下部分)。次の各ドメインのWebサイトの構築は、基本エンジンを活用しながら、それぞれの分野の知識やノウハウをコンテンツとして埋込んでいく作業です。古本屋のおやじさんがどういった仕事をしているのか、図書館の司書さんの仕事、分類の仕方はどうなっているのかといったことが解明されていきます(次図中央部分)。ここで重要なことは、システムに埋込むべき知識が、システム外から来ることです。その中でキーになるものが、出版物のカテゴリ情報です。これを、ゼロからの発想で、出版社の編集長に参加して作ったというところが、連想検索の価値を高めています。そもそも、人間が創造的活動をして検索を行う場合、何か目的があって探し物をするわけではなく(そういう場合にはGoogleのキーワード検索を使えばよい)、何か関連しているもの、想いもよらないものなどを発想の刺激として出してほしいわけですから、出版社の編集長のような横断的に見る力というのが組込まれていることがよい結果を生みそうだと直感的に思えます。 最後のサイトを横断した連想検索を行う統合部分については、それぞれのドメインでの結果を、他の検索に活かす方式を、分散検索の方式を考え実現したものです。これは、ソフトとしてはAjaxを使って、小さな規模(数ヶ月)で実装できるものです(次図右下部分)。 所謂、ソフトウェア開発という観点からは、受発注の関係や、要求をどうするかといった観点はさほど重要ではなく、人間の発想とはどういうものかとか、今までにないディスコース(言説)をデザインしていく活動で、まさに「知働的」なものと言えます。 |