プロセス改善を進めるには会社全体で取り組むべき

売上が飛躍的に伸びなくても利益を伸ばすことは原価を圧縮すれば可能で、人月をベースに考えれば期間を圧縮して人数を削ってその分のカネを単価に回して技術者にカネを与える。ひがさんのプログラミングファーストはこういう方向だよね。売上1億で儲けが3000万と、売上20億で儲けが3000万と、どっちがいいかって話。結局コストで食われたら意味無いじゃんっていう。分母と分子なら分母を変えるほうが影響がでかいし、コスト削減は自助努力でがんばれる部分が大きいから、まずそっちからみんな手をつける。売上に影響されない要素を作ったほうが経営基盤が磐石になるから。

http://d.hatena.ne.jp/aroundthedistance/20091020/1255974778

単金を上げるだけでなく、無駄なくスキルを活用する環境が必要だと思います。

昨日のエントリでは「いくら研究開発費を投資してプロセスを改善したとしても、意志決定が行われるレベルで単金を下げる選択肢がある限りは現場のプロセスは改善されない」と書いたけど、プロセス改善を進めるには会社全体で取り組むべきです。

現場ではプロセス改善が必要という認識はありますが、その時に足を引っ張るのが会社のルールです。プログラミングファーストでやるなら、思いっきり社内標準を無視しなきゃいけない。工程ごとに報告会議が必要だとか、規則通りに品質管理が行われていないとか。下請けは新しい方法論に不安を感じて、見積りにリスクを積むことを要求するでしょう。

社内標準と部署内の開発ルールを無視することは、サラリーマンである以上とても難しいことなのです。それゆえ、意志決定者の判断材料（報告書）より低いレベルでしか現場のプロセスは進みません。TDDなのに単体試験品質のバグ密度を報告する必要があるとか最たる例でしょう。意志決定者と作業者が別の会社になると、報告書と実態の乖離はより広がります。

現場でのプロセス改善はそろそろ限界で、足を引っ張る社内標準を見直すべきだと思います。ひがさんのように会社全体に影響力を持つ立場が必要ですけどね。

単に社内やグループ内で決まっている開発ルールに過ぎないのだから、変えるべき確固たる理由がある場合、必要に応じて変えていくべきではないだろうか。自分たちの作業を効率化し、作業方法から属人性を排除するのがルールが存在する趣旨のはずだ。効率の悪いやり方がルールで定められているのなら、もっと効率の良い方法にルールに変えるべきだし、そもそもそんなやり方で効率を落とす事に疑問を感じないのは大きな問題だと思う。

http://d.hatena.ne.jp/rabbit2go/20091004/1254640353

やり方に疑問を持たないのは論外。疑問を持っても具体的なアクションに落とせないことが多いのではないでしょうか。