ブログ

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

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

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

ムダの原因

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

生み出されたムダ

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

作業におけるムダ

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

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

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

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

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

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