「アジャイルと聞くと“うさん臭い”と感じる」。率直な意見交換の中で、この言葉を耳にすることがまだまだ多い。変革に併うリスクもコストも少なくないにもかかわらず、得られるものが腹落ちできていないからだ。その状況を無視して、夢のような開発手法として売り込むような、筋の悪いアジャイルの押しつけが残念ながら多い。

 実際のところ、ウォーターフォールでもアジャイルでも、コーディングやレビュー、結合テストといったタスク単体の作業内容は変わらない。変わるのはタスクの流し方だ。ウォーターフォールが「バッチ型」、アジャイルやリーンは「ストリーム型」と捉えると分かりやすい。バッチ型はあるタイミングまでタスクを貯めておき、一括で消化する。ストリーム型ではタスクが発生したらすぐに(ジャストインタイムで)着手し消化していく。

 どちらが向くのかは、システムの特性やプロジェクトの性格で異なる。目的に特化したWebサービスやモバイルアプリは、機能やデータの独立性が高い。こうしたシステムは、ストリーム型のタスクの流し方にすると効率良く開発を進められる。一方、基幹システムの開発のように1カ所の変更がほかの機能やデータに大きく影響するようなプロジェクトでは、依存関係を踏まえた設計が前提になる。これはバッチ型のタスクの流し方と相性が良い。

 かつては都度発生する結合やテストの負荷を軽減させる技術が未成熟で、ストリーム型のタスクの流し方は実施が難しかった。そのため、長くバッチ型が標準的なタスクの流し方であり続けた。今もその伝統に縛られ、システムの特性にかかわらず、杓子定規にバッチ型でタスクを流している現場が少なくない。そうした現場では、「特定の人に過大な負荷が掛かる」「課題が発生するとしばらくメンバーが動けなくなる」「忙しいのに事務仕事ばかり増える」といった問題が生じがちだ。  筆者が支援した、

 新事業でWebサービスに取り組んだチームの話をしよう。そのチームは当初、基幹システムの開発と同じ開発プロセスを採用していた。このタスクの流し方では負荷の変動が大きく、チームは疲弊していた。例えば、実装やテストのレビュー依頼は、週次の進捗定例の直前に集中して上がってくる。レビュー対象は、2週間近く掛けたタスクの成果であることも少なくない。しわ寄せはリーダーが一身に受けていた。コードレビューの依頼が来ると、徹夜で大量のソースコードと格闘する生活を送っていた。

 そこで、筆者はストリーム型でタスクを流せるように開発プロセスを変える手伝いをした。まず、タスクの粒度を従来の数日単位から数十分や数時間単位まで小さくした。さらに、メンバーの活動を可視化し、リーダーがチームの次の動きを予測できるようなツールなどの環境を整えた。

 その結果、リーダーは会議の合間のすきま時間を活用してソースコードや仕様書のレビューができるようになり、徹夜することもなくなった。タスクの作業内容やボリュームは変わっていないが、タスクの流し方を変えるだけで時間を有効活用できる。肉体的、精神的な負担が減り、品質が向上するとともにチームの雰囲気も明るくなった。

 タスクの流し方をストリーム型に変えるための手法は様々あるが、ゼロから試行錯誤するよりも実証済みの手法を採用した方がシンプル。これがアジャイルを採用する理由の一つだ。そう捉えると、うさん臭さの雲も少しは晴れるのではないだろうか。