以前、デザインパターンを使ってある現場の開発工数を 1/10 にした話を記事にしました。
この現場は、お世辞にも変化に柔軟と言える場所ではなかったのですが、
現場に入場したばかりの1下請け若手開発者である自分の提案がすんなり通りました。
物事の改善というのは、実際に改善するのも大変ですが、
一番大変なのは変化を嫌う傾向のある場で、実際に改善の意思決定を勝ち取ることです。
思い返すと、そこそこ変化を嫌う現場で、しかも信頼貯金ゼロの状態から
随分すんなりと改善できたことに気づきました。
その理由を整理します。
要約
この案件の詳細は冒頭の記事で確認していただくとして、大雑把に説明すると
- 炎上プロジェクト。納期に間に合わない可能性大
- 開発工程の少し前に参加した私が大幅に共通化できる場所を発見し、改善提案
- 共通化したことで余裕で納期に間に合った
という話です。
改善が許容された理由
開発工数を 1/10 にする提案はなぜ実施の機会を得ることになった理由は
以下の様なものであると考えす。
1. 切羽詰まっていた
このままでは納品に間に合わずにお客様に迷惑をかけてしまう。
また、その結果として今後の受注が危うくなってしまうだろう。
2. 余力があった
中途半端な時期に参入したため、最初にキャッチアップの時間と称した自由な時間が与えられた。
早い段階でキャッチアップを済ませたため、
工数削減のための検証をする余力があった。
3. 削減工数を具体的に伝えた
共通化によりコード量が 1/10 程度になることを伝えました。
それならばと、仮実装することを依頼されました。
4. 実現可能性をプロトタイプでみせた
仮実装することで、実際に 1/10 にすることが可能であるという縮図を見せることができました。
ここで Go サインをもらい、実際に共通化による工数削減が実現することになりました。
まとめ
「 切羽詰まっている状況 」というのは短期的には意図的に作り出すことが難しいですが、
何かを改善しないことによる長期的な損失を理解可能な形で可能な限り具体的に示すことは有効そうに思います。
「 余力 」については、当時はたまたま参入タイミングによって発生したものでした。
組織を継続的に改善し、「学習する組織」であり続けようとするのであれば、
常に既存の業務だけで手一杯になってしまっているような状況にせず、
業務に関して定期的に振り返り、改善をしたり、誰かが突発的に閃いてよさそうな案を試す
余力をもっておくとよいよいに思います。
「 効果を具体的に伝えること 」は領域によって難しい部分もあり、
今回はコード量を示すことができたのが、幸いしました。
例えば「情報共有の効果」などは数値で示すのは難しいので、伝え方の工夫が必要そうです。
「効果を具体的に伝えること」「 実現可能性を見せる 」がセットになることで
どのくらいの利益を得ることができるかが現実問題として伝わることになります。
実現可能性が伝わらないと「そうはいってもできるかどうかわからない」となりがちです。
当時は特に意識していませんでしたが、必要なものをきっちり揃えて提案から改善の実施をしていたのだな、
ということを確認することができました。
