Tbpgr Blog

Employee Experience Engineer tbpgr(てぃーびー) のブログ

カイゼンしっぱなしにせずに成果をまとめ、記録する

何かの改善施策の提案時や実施後、実施しっぱなしではなく、
定性的な成果と定量的な成果をまとめます。
仮に提出する先がなくても、自身の中でどのようなインパクトのある事をしたかを
個人史として残してけば、自分の手札として把握しやすくなりますし、
人にも具体的な説明をしやすくなります。

以下の記事の事例は工数を数値でみつもったことが提案の成功につながりました

tbpgr.hatenablog.com

リファクタリングで工数を 1/10 にした、という話です。
具体的な行数を忘れたので、仮の値にします。

改善前

-- 行数
一人あたりの開発行数 10,000 行
全体(6名) 60,000 行

改善後

-- 行数
共通部 5,400 行
一人あたりの開発行数 100 行
全体(6名) 6,000 行

また、今後機能追加する際に、共通部以外の変更であれば 100 行の追加で
済むようになっています。工数 1 / 100 です。

その他の利点には

  • 冗長だった箇所の変更コストが大幅に下る
  • 今後の機能追加時の障害発生量が減る

などがあったでしょう。
(この件はステップ数見積りというオチがあるので、その会社にとっては利点になりませんが)

例えばこのケースで、私は多重請負の末端プログラマだったので
6人の開発者の中で一番単価が低かったと予想されます。

しかし、実際は全体の工数を 1/10 に減らし、その作り込んだ対象をみると
私は共通部 5,400 行+100行 を作りましたが、他のメンバーは一人 100 行です。
ここで、自分が他の同ランクの単価で仕事をしている開発者とは
全く異なる価値を提供できていることを確認できます。

当時の私にアドバイスするなら、この数値を材料にうまいこと転職しなよ、
ということが言えそうです。

まとめ

定性・定量双方の成果をまとめることで、生み出した価値を自分・他者に確認可能にします。
また、地味に重要なのが成果の内容をできるだけ具体的にすることで、
自身に対するポジティブなフィードバックになることです。
以降も改善をしていく気持ちが高まります。