お気に入り
私はプロジェクト管理システムのデリバリーフローに魅せられ、開発者としてたびたび考えています。これまでに『Agile Management for Software Engineering』『The Art of Agile Development』『Slack』、お気に入りの『The Phoenix Project』といった本を読みました。
The Phoenix Projectを読んで、誰もが直面するたくさんのムダに気付かされました。私はいろいろな開発手法を学ぶことに加え、開発チームを管理する過程で実践できる機会を持てるので、本当に幸運だと思います。
この記事では、私が好きな2つのこと、ソフトウェアエンジニアリングとデリバリーフローを組み合わせて紹介します。
実際に、簡単なスループットシミュレーターを作ってみました。
この記事で紹介すること
- 手待ち時間を増加させる8つのムダ
- 次のデリバリーフローがどのように実践されるか
- ウォーターフォール方式
- スクラム方式
- かんばん方式
- 落ち着いて時間的余裕を持つべき理由
- 効率性に関して考える場合、待ち時間が悪の根源である理由
- ソフトウェアを開発する場合、個人プレイよりもチームプレイが大切なこと
ソフトウェア開発における8つのムダ
はじめに、ソフトウェア開発におけるさまざまなムダを理解することが重要です。
以下のリストですべてが網羅されているわけではありません。ソフトウェア開発に関するムダについて説明しようとすると、数百ページに及ぶ本が書けるほどですから。しかし、このリストにある項目を見るだけでも大枠はつかめます（日本版編注：以下のリストのうち7つはトヨタ生産方式の「7つのムダ」に沿って訳している）。
1.運搬のムダ
このムダは成果物を移動させるときに生じます。コードを複数のブランチに送信したり、チェリーピック（つまみ食い）したりするときかもしれません。
2.在庫のムダ
成果物が利用されないムダです。例として以下のようなものがあります。
- 要件定義書
- アーキテクチャ設計書
- グラフィックおよびワイヤーフレーム
- PoC（コンセプト検証）
- コード
これらの成果物は（製品が世に出る）数週間または数カ月も前に作成されます。完成したときにはすでに時代遅れのものとなり、修正が必要になります。
3.動作のムダ
成果物の制作時に生じるムダです。
開発者はほとんどの場合、同時並行でたくさんのタスクをこなす必要があります。頭の切り替えやマルチタスクに伴う負担が発生したり、さまざまなソフトウェアのバージョンやプロジェクト、ロードマップを覚えておいたりする必要があります。
あるいは、誰かが絶え間なく電話をかけてきたり、なにかを聞きにやってきたりすることもあるでしょう。
何日も何カ月も何年間も放置された仕事を再開する場合なら、過去の仕事を思い出す必要があります。
4.手待ちのムダ
作業環境の確立やほかの人が作業を終えるのを待つムダです。
ITインフラが不安定で、コンピュータがフリーズしたり、インターネットが繋がらなくなったり、メールサーバーに障害が発生したりする場合もあります。
チームのテスターなら何日間も待って、開発サイクルの最後の作業を担います。
要件を誤解していたことが発覚し、もっとすべき仕事があったことに気付く場合もあります。
あるいは、自分のコードを誰かがチェックしてくれるのを待っているかもしれません。
5. 作り過ぎのムダ
ソフトウェアを開発したものの納品していない場合のムダです。
在庫として保管され、誰も購入する人はいません。あなたが作った作品はもう必要なくなっています。
6. 加工そのもののムダ
要求されていない成果物を作成したときに起こるムダです。コードを改善し、今後組み込まれる優れた機能用の拡張コードを追加します。「良かれ」と思い、誰も要求していない作業をしています。
7. 不良をつくるムダ
成果物にエラーがある場合に起こるムダです。
開発したものが検収基準に満たない場合です。または技術的な基準（パフォーマンス、セリュリティ、保全性）を満たしていない場合です。
8. スキルのムダ
開発者の労働力が十分に活用されていないときのムダです。
仕事に必要な訓練を十分に受けていない、またはもっと複雑な仕事ができるのに任せてもらえないときに発生します。
Slackとはなにか？
Slackは、そうです、メッセージアプリです。しかし、ここで言及するSlackは『Slack：Getting Past Burnout, Busywork, and the Myth of Total Efficiency』というタイトルの本です。209ページもありますが、すべてに触れるのではなく要旨を取り上げます。
チームがよりハッピーに、燃え尽きることなくもっと革新的になり、かつ組織が変化に柔軟に対応できるようにするために、開発プロセスに「アイドル時間」を設けることをおすすめします。
開発サイクルの計画を練るときに、イノベーションのための時間を全体の10％か20％、または任意のパーセンテージに決定し確保するだけです。
記事では、シミュレーションでこの理論をテストし、いかに開発スピードが速くなるかを検証します。
シミュレーション
3つのプロジェクト管理手法をシミュレーションしました。以下で結果を紹介します。また、各開発アプローチのスループットスピードを比較したチャートも用意しました。
ルール
シミュレーションは便宜的に単純化してあります。列になっているボールは前に動くことも、その場に留まる（ターンをスキップする）こともできます。ただし、前にボールがあると前に動けません。列がいっぱいになると新しいボールは追加されません。
ルールはどのように関係するか？
こう思っているかもしれません。なぜボールは一カ所に留まるのか、なぜターンをスキップすることがあるのか。私は実世界をシミュレーションしようと考えました。
8つのムダを覚えているでしょうか。8つのムダはすべて待ち時間を発生させます。これがボールがターンをスキップするかもしれない理由です。
しかし、それはボールの後ろにあるすべてのボールが前に進めないことを意味します。後ろにあるボールはブロックされ、ブロックされたボールは点滅します。
実世界では物事は雑然としており、予測できないところがあります。シミュレーションを実世界により近づけるために、すべてのデリバリーフローにランダムなブロックを追加しました。
たとえば、理論上は、かんばん方式は8つのムダを最小限にとどめる大きな効果があるとされています。しかし、人間は間違いも犯しますし、顧客の優先度が変わることもあります。
では、実際にいくつかあるデリバリー方法をシミュレートしてみます！
ウォーターフォール
この方式は順序立ったバッチを利用した方法です。ある特定の分野を得意とするチームがまず作業し、次に別の分野を得意とするチームに作業を引き継いでいくということを繰り返し製品を完成させます。
通常、フィードバックはほとんどありません。フィードバックがあると、プロセスが非常に遅くなります。
大人数のチームでバッチ処理的に作業し、下位のチェーンに引き継いでいきます。
しかし、次のチェーンに引き継がれる前に前工程の制作チームに戻ることもよく起こります。
通常のシミュレーション
slackを取り入れたシミュレーション
かんばん方式
かんばん方式は 一個流しのフローです。複数の分野に精通したチームまたは複数に分かれたチームが作業し、製品を素早くリリースします。
フィードバックは即座に返され、その場で作業が追加、削除されます。
通常のシミュレーション
slackを取り入れたシミュレーション
スクラム
スクラム方式は並行バッチ処理です。複数の分野に精通したチームが短期間、同時に同じ問題解決に取り組み、ソフトウェアをリリースします。
チームは振り返り会議、企画会議、調整会議などを開きます。準備や改善には時間が必要です。
通常のシミュレーション
開発スピード比較
下のチャートは開発プロセスが1万回繰り返されたときに、各開発手法でデリバリーされたボールの数を示しています。
シミュレーションから分かること
1. 落ち着いて時間的余裕を作る
イレギュラーなことが発生するシステムでは、時間的余裕も考慮に入れるべきです。イレギュラーなことが発生する可能性が高いほど、必要な時間的余裕も多くなります。
時間的余裕を持たせることでイレギュラーな事態に対応します。インターロックを削減し、リードタイムを短縮できます。余裕さえあればより効率的に作業できるようになります。ただし、余裕時間に対して給与を払っています。
余裕時間に給与を払っても、実際にはそれ以上の時間的な見返りがあります。作業者のミスが減り、より質の良いディスカッションができ、労働のやりがいが向上し、知識をより広く共有でき、手直しを減らし、離職率を下げられます。
しかし、優れた効果的なプロセスを利用するとより良い結果が得られます。そうすると、イレギュラーな事態を可能な限り減らし、時間的な余裕にも配慮できます。
2. デリバリー速度を上げるために待ち時間を減らす必要がある
（デリバリー速度）− （システムにおける待ち時間）＝実際の開発速度
この方程式は息苦しくなるかもしれません。
しかし、周りを見回してください。あなたの組織では待ち時間を減らす仕組みが設けられているでしょうか。おそらく、答えは「いいえ」となるでしょう。
待ち時間をどのように減らせば良いでしょうか？ 以下にコツを記載します。
- 同時に実行するプロジェクト数を減らす
- 開発チームの人員を少なくする。チームが大きいとより大きなコミュニケーションやマネジメントが必要になり、まさにムダそのものだからだ
- INVEST基準を利用して、開発作業範囲を必ず明確にする
- ジャストインタイムでデリバリーする
- 必要十分なぶんだけ提供する
- 本来の作業に従事する時間を確保する。会議の回数やそのほか業務の妨げとなることを減らす
- 仕事を細分化することで仕事の進捗を把握できるようにする
- 任せている仕事に必要な時間以上の時間を与える。最悪の場合、なんらかの別の問題が発生して時間がかかることがある（追加で作業が必要な仕事を見つけたり、邪魔が入ったりしたなど）。最良の場合、早く仕事が終わり、高いモチベーションで次の作業に取りかかれる
このリストは直感的なものではありません。反対のことをすべきだと感じるかもしれません。なぜなら、一般的に人には大きな圧力を加えれば、推定開発時間を短縮でき、よりすばやく質の良い仕事ができると考えられている社会で生活しているからです。
Parkinson’s Lawの解釈を「仕事は完了するまでに使える時間がある限り広がっていく」というように誤って伝えている自己啓発書はおすすめできません。
確かに、科学的な「法則」ではなく、証明できる証拠はありませんし、文脈によって意味が変わってきます。また、人はよく効果的であることが単に効率的であるのよりもずっと大事だということを忘れます。効果的にするには、人はポジティブに考えられる環境で考える時間が必要です。
3.個人プレーよりもチームプレイが大事
覚えておいてほしい重要な考え方があります。組織の中で重要なのは個人の開発スピードではありません。組織全体の開発スピードが重要です。
自分は非常に効率的に作業できるかもしれませんし、仕事が好きなので残業をして手待ち時間を補えるかもしれません。それでは、仮に自分をプログラマーだとして、次のようなことを想像してください。
自分の思うように企業アナリストから要件をもらえなかった場合、最終的に次にすべきことはなにかと考え、ひたすらコードを書いて在庫や不良品を作ります。これはほぼ確実に作り過ぎです。
書いたコードに満足できず、コードをリファクタリングしたいと思うときがあるでしょう。コードはまだ在庫に残っており、納品されていません。単に自分が満足できないので納品したくないと考えているからです。ただ、このような場合、加工のしすぎでムダを作っています。
バックエンド開発者であり、フロントエンド開発者の作業がまだ終わっていない場合、どうなるでしょうか。フロントエンド開発者が仕事を完成させる間にほかの作業を始めてしまいます。つまり、2つの作業をすることになります。フロントエンド担当者が風邪にかかったらどうでしょう？ 作業対象が3つ、4つ、5つと増えていきます。その間、組織に価値は生じません。なぜなら、なにも納品されないからです。誰も自分が書いたコードを使っていないからです。在庫を作っただけで、カスタマーからフィードバックをもらえないので、なにも得るものがありません。
信じてもらえるか分かりませんが、非常に効率的に作業する会社員が間違った作業をすると、利益を生み出すどころか損失を生んでしまいます。
一生懸命働きたいのは良いことです。納品したもののバグの多いコードをリファクタリングし、サービスの質（パフォーマンス、セキュリティなど）を高め、部下のエンジニアとペアを組み内部プロセスを改善したりリサーチしたりしてください。
組織の中では、個人はもっとも生産性の低い人と同じだということです。生産性の低い人を手助けして、開発スピードを上げてください。
これがTheory of Constraints （ToC）の実例です。詳しくは私が執筆したToCの記事を読んでください。
最後に
組織にイレギュラーな事態があるほど、開発スピードを上げるために時間的余裕を考慮する必要があります。
全体的な開発スピードを上げるために障害となる部分を見つけ、待ち時間を減らすためにできることはすべてやってみてください（これはTheory of Constraintsが教えてくれたことです）。
8つのムダを忘れず、思い切ってプロセスからムダを取り除いてください。
シミュレーションの利用法に興味があったり、独自のシミュレーションを作成するためにシミュレーションを応用したい場合は、GitHubにあるコードを参照してください。
（原文：We Simulated Waterfall, Kanban & Scrum. Which Works Best?）
［翻訳：中村文也／編集：Livit］
