変幻する実行可能知識 20セル, 制約, 価値, アジャイル I「アジャイルなソフトウェア･プロセス」という考え方がもたらされて早くも数年がたった. 根強い反感や偏見はあるものの, アジャイルなソフトウェア･プロセスはさまざまな場所で使われ, 確かめられ, 拡張され続けている. それらの拡張の中にはささやかではあるけれど現場レベルで非常に有用なものもあるし, もっと大きなフレームワークとして考えるべきものもある. その中から今回は下記の本と資料を元にセル生産方式+アジャイルという枠組みを考えてみよう.
セル生産方式とは比較的最近になって (といっても十数年前から) 注目を集めているモノの作り方である. (2) によれば「一人ないし数人の作業者が一つの製品を作り上げる自己完結性の高い生産方式」と定義されている. 従来の長いコンベアによる生産とは対照的に, セル生産方式では屋台のようなブースで少人数がそれぞれ異なる複数の作業を行って製品を作る. 職人による手作り生産の新たな復活という側面もあるようだ. セル生産方式はコンベアによる生産に較べると次のような利点があるとされている.
こうしてみると, アジャイルの考え方に慣れている読者にはアジャイル･ソフトウェア･プロセスとの親和性, 類似点は一目瞭然であろう. 長いコンベアによる専門作業の連続はまさにウォータフォール･プロセスに対応しそうである. しかしこれはあくまで「モノ」の作り方であって, ソフトウェアの作り方ではない. リーン･ソフトウェア開発 (注) と同様, モノの作り方をソフトウェア作りに応用するには慎重でなければならない.
セル生産方式のソフトウェア･プロセスへの応用の一つは京都高度技術研究所の松本吉弘先生のグループで研究されているソフトウェア･セル生産 (1) である. これはソフトウェア･プロダクト･ライン, ソフトウェア･ファクトリの考え方に「セル」を取り込んだ, かなり形式的で重量級のプロセス (メタ･プロセスというべきか) だ. まだまだ発展中とはいえ, 「アジャイル」と呼ぶにはいささか気の引ける内容のようにも思えるが, ここではソフトウェア･セル生産をアジャイルの立場から (なかなか深遠な内容なのでその表面だけをさらっと) 見直してみたい. まずソフトウェア開発における「セル」とは何だと考えればいいだろうか. 従来のプロジェクト管理手法ではWBS (Work Breakdown Structure) という, 作業単位をツリー状に詳細化した作業一覧を作成する. またこの作業単位を「ワーク･パッケージ」(するべき作業を梱包した小包ですね) と呼ぶ. WBSはその依存関係に基づいてアクティビティ・ネットワーク (注) へと展開されるもととなる重要なものだが, ソフトウェア開発では特に
などの理由から, 結構な厄介者でもある.
ソフトウェア開発における「セル」はこのワーク･パッケージに近い. ただしワーク･パッケージと大きく異なっているのは次の点だ.
セルを入れ子にできるのはワーク･パッケージと同様. ワーク･パッケージのラベルには担当者, 事前条件, 事後条件, 入力, 出力, 期間, 作業内容, リスクなどが記述されるが, セルもほぼ同様. XPなどをご存じならば, このラベルとしてタスク･カードを想像していただければよい. セルはワーク･パッケージよりもダイナミックだから, 必要に応じて分割したり, 統合したり, 他のセルに委譲したりすることもできる. セル同士の間では, さまざまな情報 (ティップスとか問題点とか) や成果物が交換されるし, あるセルの作業中に別のセルに注意を促す必要があれば割り込みを掛けることになるだろう. と, 見てくると, セルは我々がよく知っている何かに似ていないだろうか? そう, セルはオブジェクトなのだ. だからインタフェース (受け取れるメッセージ群) さえちゃんと定義されていれば, その中身は何でも構わない. 一人でやっているかもしれないし, 10人かもしれない. 最初は二人だったけど大変だからその場でセルを三つフォークする場合もある(注). 人じゃなく, ソフトウェア･ツールでもよいわけだ. オブジェクトと同様, メッセージを受け取ってどう反応するかはセルの自律性に任されている. セルは他のセルと協調しながらメッセージに応答する. オブジェクトのデザイン･パターンやアーキテクチャ･パターンなどと同様, セルにも協調関係のパターンがある. セルがワーク･パッケージに較べてダイナミックな性質を持っていてもちゃんと作業ができるのは, セルの自律性に依る. そしてセルの自律性がセル生産方式の最大の利点なのである.
またセルはワーク･パッケージと同様に, アーティファクト (作り出すモノ) に対応したセル (例えばあるストーリを実現するセル, このセルには分析, 設計, テスト, 実装というプロセス一式がパッケージングされている, これをアーティファクト･セルと呼ぼう) と工程に対応したセル (例えば統合テストを実行するセル, このセルにはすべてのモジュールが集められテストされる, これをアクティビティ･セルと呼ぼう) がある (注).
XPでは二人単位 (ペア･プログラミング), 生存期間 (イテレーション) 1~2週間のアーティファクト･セル (= 二人アーティファクト･セル) が中心で, そのラベルはタスク･カードで与えられる, ということができる. Scrumの場合には7人前後のチーム全体が一つのアーティファクト・セルで, セルの生存期間は一ヶ月, そのラベルはバックログで与えられる. このセルの内部はカプセル化されていて外からは見えないが, 内部的には非常に小さなセルが時間単位で絶えず生起していることだろう. さて, このソフトウェア･セルの考え方からはモノ･セルと同様に, 変化に対応しやすい/作業者のモチベーションが上がる/生産性, 品質の向上が図れる/無駄 (仕掛かり在庫) が少ないという利点を本当に得られるのか? 我々はそう信じるが, その点についてはまだまだ探求が必要そうだ. |