セル生産方式＋アジャイルという枠組み：ソフトウェア開発をちゃんと考える（8）

今回はセル生産方式＋アジャイルという枠組みを考える。

　「アジャイルなソフトウェア・プロセス」という考え方がもたらされて早くも数年がたった。根強い反感や偏見はあるものの、アジャイルなソフトウェア・プロセスはさまざまな場所で使われ、確かめられ、拡張され続けている。それらの拡張の中にはささやかではあるけれど現場レベルで非常に有用なものもあるし、もっと大きなフレームワークとして考えるべきものもある。その中から今回は下記の本と資料を基にセル生産方式＋アジャイルという枠組みを考えてみよう。

1. 「ソフトウェア・セル生産方式の概要［PDF］」（松本吉弘氏のサイトへ）
2. 「セル生産システム」（岩室 宏=著／日刊工業新聞社／2002年）

　セル生産方式とは比較的最近になって（といっても十数年前から）注目を集めているモノの作り方である。（2）によれば「1人ないし数人の作業者が1つの製品を作り上げる自己完結性の高い生産方式」と定義されている。従来の長いコンベアによる生産とは対照的に、セル生産方式では屋台のようなブースで少人数がそれぞれ異なる複数の作業を行って製品を作る。職人による手作り生産の新たな復活という側面もあるようだ。

　セル生産方式はコンベアによる生産に比べると次のような利点があるとされている。

• 多品種少量生産に向いている
• 変化に対応しやすい
• 作業者のモチベーションが上がる
• 生産性、品質の向上が図れる
• 無駄（仕掛かり在庫）が少ない

　こうしてみると、アジャイルの考え方に慣れている読者にはアジャイル・ソフトウェア・プロセスとの親和性、類似点は一目瞭然であろう。長いコンベアによる専門作業の連続はまさにウォーターフォール・プロセスに対応しそうである。しかしこれはあくまで「モノ」の作り方であって、ソフトウェアの作り方ではない。リーン・ソフトウェア開発（注1）と同様、モノの作り方をソフトウェア作りに応用するには慎重でなければならない。

　セル生産方式のソフトウェア・プロセスへの応用の1つは京都高度技術研究所の松本吉弘先生のグループで研究されているソフトウェア・セル生産（1）である。これはソフトウェア・プロダクト・ライン、ソフトウェア・ファクトリの考え方に「セル」を取り込んだ、かなり形式的で重量級のプロセス（メタ・プロセスというべきか）だ。まだまだ発展中とはいえ、「アジャイル」と呼ぶにはいささか気の引ける内容のようにも思えるが、ここではソフトウェア・セル生産をアジャイルの立場から（なかなか深遠な内容なのでその表面だけをさらっと）見直してみたい。

　まずソフトウェア開発における「セル」とは何だと考えればいいだろうか。従来のプロジェクト管理手法ではWBS（Work Breakdown Structure）という、作業単位をツリー状に詳細化した作業一覧を作成する。またこの作業単位を「ワーク・パッケージ」（するべき作業を梱包した小包ですね）と呼ぶ。WBSはその依存関係に基づいてアクティビティ・ネットワーク（注2）へと展開される基となる重要なものだが、ソフトウェア開発では特に

• WBSを最初から先の方まで見通すことが難しい
• 状況の変化やプロジェクトの進展に伴って、WBSを頻繁に変更する必要のある場合が多い

などの理由から、結構な厄介者でもある。

　ソフトウェア開発における「セル」はこのワーク・パッケージに近い。ただしワーク・パッケージと大きく異なっているのは次の点だ。

• ワーク・パッケージ同士は詳細化の関係でツリー状に接続されているが、セル同士は情報／成果物交換の関係でネットワーク状に接続されている
• ワーク・パッケージは比較的静的に定義されるが、セルはダイナミックに生成／消滅する

　セルを入れ子にできるのはワーク・パッケージと同様。ワーク・パッケージのラベルには担当者、事前条件、事後条件、入力、出力、期間、作業内容、リスクなどが記述されるが、セルもほぼ同様。XPなどをご存じならば、このラベルとしてタスク・カードを想像していただければよい。セルはワーク・パッケージよりもダイナミックだから、必要に応じて分割したり、統合したり、ほかのセルに委譲したりすることもできる。セル同士の間では、さまざまな情報（ティップスとか問題点とか）や成果物が交換されるし、あるセルの作業中に別のセルに注意を促す必要があれば割り込みを掛けることになるだろう。

　セルはわれわれがよく知っている何かに似ていないだろうか？ そう、セルはオブジェクトなのだ。だからインターフェイス（受け取れるメッセージ群）さえちゃんと定義されていれば、その中身は何でも構わない。1人でやっているかもしれないし、10人かもしれない。最初は2人だったけど大変だからその場でセルを3つフォークする場合もある（注3）。人じゃなく、ソフトウェア・ツールでもよいわけだ。オブジェクトと同様、メッセージを受け取ってどう反応するかはセルの自律性に任されている。セルはほかのセルと協調しながらメッセージに応答する。オブジェクトのデザイン・パターンやアーキテクチャ・パターンなどと同様、セルにも協調関係のパターンがある。セルがワーク・パッケージに比べてダイナミックな性質を持っていてもちゃんと作業ができるのは、セルの自律性による。そしてセルの自律性がセル生産方式の最大の利点なのである。

　また、セルはワーク・パッケージと同様に、アーティファクト（作り出すモノ）に対応したセル（例えば、あるストーリを実現するセル、このセルには分析、設計、テスト、実装というプロセス一式がパッケージングされている。これをアーティファクト・セルと呼ぼう）と工程に対応したセル（例えば、統合テストを実行するセル、このセルにはすべてのモジュールが集められテストされる。これをアクティビティ・セルと呼ぼう）がある（注4）。

　XPでは2人単位（ペア・プログラミング）、生存期間（イテレーション）1〜2週間のアーティファクト・セル（＝2人アーティファクト・セル）が中心で、そのラベルはタスク・カードで与えられる、ということができる。Scrumの場合には7人前後のチーム全体が1つのアーティファクト・セルで、セルの生存期間は1カ月、そのラベルはバックログで与えられる。このセルの内部はカプセル化されていて外からは見えないが、内部的には非常に小さなセルが時間単位で絶えず生起していることだろう。

　さて、このソフトウェア・セルの考え方からはモノ・セルと同様に、変化に対応しやすい／作業者のモチベーションが上がる／生産性、品質の向上が図れる／無駄（仕掛かり在庫）が少ないという利点を本当に得られるのか？ われわれはそう信じるが、その点についてはまだまだ探求が必要そうだ（注5）。