📝論文紹介: Software Development Waste(ソフトウェア開発におけるムダ)

ICSE 2017 勉強会のために論文を眺めてたら、リーンソフトウェア開発におけるムダについて調査した論文*1がおもしろそうだったので読んだ。

🐾背景: リーンソフトウェア開発

Womackはトヨタ生産方式を分析し、リーン思考を提案した*2。これは、「資源を消費し、価値を生まない活動」であるムダ(waste)の発見と除去を基本原則する。

リーンソフトウェア開発は、リーン思考とトヨタ生産方式をソフトウェア開発に適用した手法である。リーンソフトウェア開発ではムダとして以下のものが挙げている。*3

トヨタ生産方式におけるムダ	リーンソフトウェア開発におけるムダ
在庫	未完成の作業
加工しすぎ	再学習
作りすぎ	使われないコードや余分な機能
物の運搬	作業の引き継ぎ
手待ち	開発の遅れ
人の動作	作業の切り替え
不良・手直し	欠陥
価値	なし
活用されない才能	なし

しかし、ここでムダとされるものが妥当かを検証した研究はない。

🎯目的: ムダの発見

リーンソフトウェア開発には、どのような種類のムダが存在するかを調べる。

🔬調査方法: Pivotalにおける調査

Pivotalで行なわれたソフトウェア開発を対象とし、グラウンデッド・セオリーを構築した。

以下の3つの方法で、データを収集した。

Pivotal Labのプロジェクトに参加し、観察した。 2年と5ヶ月間をかけて8個のプロジェクトに参加した。
Pivotalの社員33人にインタビューを行なった。これにはソフトウェアエンジニア、インタラクションデザイナー、プロダクトマネージャが含まれる。
レトロスペクティブ(ふりかえり)のトピックを分析した。 1年間の間に行なわれた91のミーティングを対象とした。

📊発見した9種類のムダ

調査の結果、9種類のムダを発見した。

誤った機能や製品の作成

誰も必要としない機能や製品を作ると、参加している全員の時間や労力が無駄になる。これは、チームの士気やオーナーシップ、顧客満足度に影響する。

調査したプロジェクトにあった実例:

ペルソナにもとづいて開発をしたが、その後の調査でペルソナがあやまっていることがわかった。
マーケティングのために、ユーザの必要としない機能を追加した。

バックログ管理の失敗

プロダクトバックログの管理を失敗すると、プロジェクトの遅延や生産性の低下につながる。

調査したプロジェクトにあった実例:

一度に複数の作業を進めることを優先したため、最初のリリースでは一部の作業が未完了のままだった。その機能は無効化されてリリースされた。
ビジネス側の要求に応じてユーザ登録プロセスを何度も変更したため遅延した。
プロダクトマネージャーが変更をくり返したため遅延した。

作業のやり直し

作業の遣り直しがムダなのは自明である。これは以下の原因で発生する。

技術負債。調査したプロジェクトの中には、リリース日を優先したため、リリース後に数週間にわたるやり直しが必要になったものがあった。
作業中における欠陥の発。調査したプロジェクトの中には、いくつかの画面を作ったのちに、モバイル対応が必要であることが発覚したものがあった。
ストーリーの拒否。実装が不十分のために、プロダクトマネージャーが受け入れを拒否することがある。
完了条件が不明瞭なストーリー。調査したプロジェクトの中には、開発者が実装を完了したのち、ストーリーとモックアップにインタラクションが不足していることが判明したものがあった。

不必要に複雑な解決策

機能が不必要に複雑だと、ユーザの時間を浪費する。

調査したプロジェクトにあった実例:

操作フローが、一部画面では左から右になっているのに、別の画面では上から下になっていた。
複数のインタラクションデザイナーがいるため、レイアウト、リスト、警告、ボタンなどが複数作られた。
インタラクションデザイナーが2種類のフォームデザインを作ったために、複数のCSSが必要になった。
顧客側の開発者が「複雑であればあるほど、重要な仕事をしていると実感できるのでよい」という態度でいることに開発者が不満をもらした。

本質でない認知負荷

認知負荷理論(Cognitive Load Theory)は、人間の作業記憶には限りがあるため、負荷が多すぎると学習や問題解決が阻害されるとしている。本質的な認知負荷とは、タスクをこなす上で避けられないものを指す。一方で本質的でない認知負荷とは周囲の環境などに追加されるものを指す。*4

ソフトウェア開発には認知負荷が高いもの多いため、開発者の思考力は貴重な資源である。そのため、本質でない認知負荷はムダであるとみなす。これは以下の原因がある。

過度に複雑なストーリー。不必要に長く複雑で不明瞭なストーリーは開発者の作業記憶を消費してしまう。
非効率なツール。機能不足だったり複雑なライブラリや貧弱な開発環境、貧弱な開発プロセスなども含む。
技術負債。技術負債はコードの理解や変更を難しくする。調査したプロジェクトの中には、テストスイートを実行すると大量の警告が出力され重要な情報が埋もれてしまうものがあった。
マルチタスク。複数のタスクを同時にやろうとすると、作業記憶に多数の情報を保持する必要があるため、認知負荷が増加する。

精神的苦痛

精神的苦痛は貴重なリソースである開発者を消費してしまう。精神的苦痛は生産性の低下や燃え尽き症候群や欠勤、健康問題などにつながる。

調査したプロジェクトの中には、機能とリリース日が変更不能なプロジェクトがあった。このプロジェクトでは、チームの士気や一体感が低下したり、メンバー間の問題解決に時間がかかった。

待機/マルチタスク

優先度の高い機能に着手できない場合、開発者は待ったり、優先度の低い機能に着手してしまう。これはプロジェクトの遅延につながる。

調査したプロジェクトにあった実例:

受け入れ環境が不安定だったため、プロダクトマネージャーが受け入れ作業を放置して別の作業を始めた。
ビデオ会議設備が不足しており待ちが発生した。
テストの実行に17分かかるため、開発者が別の作業をはじめてしまった。

知識の損失

知識の損失は、特定の知識をもったチーメメンバーがいなくなったときに発生する。そして失なわれた知識を再獲得が必要になってしまう。

調査したプロジェクトの中には、全メンバーが入れ替わったプロジェクトがあった。システムの理解に数ヶ月かかり、その間のベロシティはほぼ0になった。

非効率なコミュニケーション

非効率なコミュニケーションは不完全だったり誤解を産むコミュニケーションである。チームの規模や非同期コミュニケーション、非対称なコミュニケーションが増えると、チームの生産性が低下する。

調査したプロジェクトにあった実例:

移動に一時間かかるオフィスにチームが分割された。リモートコミュニケーションを活用したが、次第にレトロスペクティブで議題にのぼるようになっていった。
ミーティングを特定の人が支配し、おとなしい人が意見を言えないようになった。
iOSチームが自身のプロセスにチームの決定をうまく反映できなかった。レトロスペクティブを繰替えすことで改善した。

🔁既存のリーンソフトウェア開発におけるムダとの比較

リーンソフトウェア開発のムダとされているものとは、以下の違いがあった。

「引き継ぎのムダ」とされるものは観察できなかった。
新規で「不必要に複雑な解決策」「本質でない認知負荷」「精神的苦痛」「非効率なコミュニケーション」の4つを観察した。
それ以外は類似のものがあった。

まとめ

この論文ではソフトウェア開発におけるムダとその原因をエビデンスに基づいて示した。そのために2年と5ヶ月をかけてデータを集め、グラウンデッド・セオリーを構築した。

その結果、既存のリーンソフトウェア開発におけるムダは支持されたが、いくつかの点で異なっていた。新規で4つ導入した一方、引き継ぎのムダは支持できなかった。

*1:Todd Sedano, Paul Ralph, and Cécile Péraire. 2017. Software development waste. In Proceedings of the 39th International Conference on Software Engineering (ICSE ‘17). IEEE Press, Piscataway, NJ, USA, 130-140. DOI: https://doi.org/10.1109/ICSE.2017.20

*2:J. P. Womack and D. T. Jones, Lean thinking: banish waste and create wealth in your corporation. Simon and Schuster, 1996.

*3:TABLE II: Comparison of Manufacturing Waste with Lean Software Development Wasteより引用

*4:http://miwalab.cog.human.nagoya-u.ac.jp/database/resume/2016-10-25.pdf を参考にした