ソフトウェア開発におけるムダ

みなさんこんにちは。@ryuzeeです。

Alan Shalloway氏のWastes of Software Developmentが良い記事でしたので、抜粋・意訳にてご紹介します。

僕のトレーニングではいつもトヨタ生産方式の話やStandishのレポートの話をしています。 7つのムダのうち特に作り過ぎのムダをなくすことはとても重要で（もちろんほかも重要）、これがないと頻繁に継続的に顧客に価値あるフィーチャーを届けることはできなくなるからです。さらに開発のプロセスの中で、常にどこにムダがあるのかを考えて改善していくことはチームに課された責任でもあります。

例えば思いつく限り以下のようなものはムダです。

使わない機能
たくさんのオプション設定
読まない仕様書
読まない報告書
やたらと体裁にこだわった文書
更新されない文書
目的のない会議
決定事項が守られない会議
遅いPC
小さいディスプレイ
行動の監視
目的化された報告
同じ間違いのくり返し
自動化できる作業の手動実行
マルチタスク
詰め込み
バグ
作りかけで放置されたもの
チェックインされていないコード
テストされていないコード
顧客価値と一致しない役割分担（デプロイ担当者やテスト担当者など）
長すぎるフィードバックプロセス
過度な先読み

以下が抜粋・意訳です。

製造業における７つのムダをソフトウェア開発におけるムダにあてはめようという流れがある。その話自体は悪いスタート地点ではないが、そうは言ってもただのスタート地点だ。物理的な製品開発の世界とソフトウェア開発ではいくつも異なる点がある。たとえば

ソフトウェアはムダが見えにくい
バグのないコードを書く開発者とバグを作ってしまう開発者を見た目では区別できない
ソフトウェアにおけるエラーは時間がたつにつれて修正に労力がかかるようになる。
製造業におけるエラーは、同じことが繰り返されやすいが、ソフトウェアにおけるエラーは毎回個別事象であることが多い。

ポイントは、我々がソフトウェア開発における新たなムダのリストを欲しているということだ。以下ははじめの切り口だ。

ムダの原因

多すぎる仕掛り中の作業
遅延
仕事の引き継ぎや受け渡し
官僚主義
割り込み
不明瞭なワークフロー

生み出されたムダ

必要以上の機能
不具合
複雑さ

作業におけるムダ

割り込みや不適切なやり方による非効率
バグの修正
必要な作業のやりなおし
非同期で作業を進めたことによるバタバタ（貧弱なイングレーション）
再学習
レベルの低い技術的プラクティス
不適切な作業順序
重複コード
作り込みすぎのフレームワーク

問題の多くは、多くの作業をし過ぎていることに起因している。チームの作業を管理するためには２つの一般的なやり方がある。

作業を前もって計画し、チームに与える
チームがReadyになったら作業をプルする

ウォーターフォールやアジャイル以前の計画においては前者を使う。全てのアジャイルなやり方では後者を使う。各チーム固有のキャパシティとそれが尊重されなければならないことについてどうやって管理職に理解させるか、という点については大きなチャレンジだ。これらの点から、我々は以下の情報を提供しなければならないだろう。

チームがうまく機能しているという証拠
チームがキャパシティにしたがって働いているという証拠

我々は常により良い方法を学習しようとしている。我々にとって変化を経験することは、我々がサービスを提供している相手の人と同じように大変なことだ。この状況においてはチームのやり方を明らかにすることはほとんどの場合良いアイデアだ。どうやったらよりよい仕事ができるかを学んでいるチームにとっても、なぜ変化が起こったのか知りたい人たちにとっても、改善の良い機会となる。

なお、Alan Shalloway氏はオンラインで定期的にセミナーを実施されている（当然全編英語ですが）ので、興味がある方はこちらを参照すると良いでしょう。

それでは。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料）