「研究開発プロジェクトが上手く行く方法」について相談され、自分なりに考えた結果をメールで展開したら評価が高かった。
——————————————————-
先週、「どうやったら開発が上手く行くか？」という質問を〇〇さんにされたので、自分なりに考えてみました。
20年間、日本企業、外資企業、ベンチャー企業、中小企業、大企業、小規模PJT、大規模PJT、ウォーターフォール開発、アジャイル開発、製品開発、研究開発、etc、、、
様々なIT系の開発プロジェクトに関わった経験を振り返ってみると、どんな開発PJTでも、「これをやったら開発が上手く行く」という定石が、１つありました。
大きな開発方針に「開発のスピード勝負」を掲げているチームは、お客さんからの評価が高く、お客さんと良好な関係を築けていて、開発チームは悩まずに開発を進め、開発生産性も高い傾向にあります。
市販する組込み製品は「品質第１」かと思いますが、〇〇のような研究開発寄りのITシステムは、「開発スピード第１」の方が上手く行く傾向にあります。
具体的には、、、早くリリースする為には、省けるものは省くです。
- 開発スピードを上げて、お客さんが困っているバグがあれば修正版を１週間以内にリリースする。
- 必要な機能があれば、即実装して最短リリースする。最短リリースが難しい場合は段階リリースする。
- コメントは必要最小限（ソースコードと重複するコメントは不要）。
- ソースコードも必要最小限（変数の型名を変数名に加えない、なるべくvarを使う）。
- ドキュメントも必要最小限（納品しないドキュメントは、要になるドキュメント以外作らない）。
- お客さんに渡す製品以外の成果物、納品物が必要最小限になるよう、お客さんと交渉する。
- スケジュール管理はマスタースケジュールベースで行う（WBSは細かく書かない）。など。
「開発のスピード勝負」をする場合、開発作業を改善する時の第１判断基準は、「これは開発スピードを上げられるか？開発スピードを下げないか？」になります。
開発スピード勝負をしている開発チームに比べて、１つ１つ真面目に、細かくやろうとするチームは、１つ１つの作業に時間がかかり、リリーススピードが遅く、お客さんのフラストレーションが溜まり、開発メンバのストレスも溜まっていきます。
お客さんが困っているバグを、次の定例までにリリース出来れば、資料を提出しなくてもお客さんは怒りませんが、１ヵ月かかると、お客さんが怒りだし、資料を作成し現状報告するよう求められ、更に開発スピードが低下し、関係者のフラストレーションが増加して行く悪循環に陥ります。
更に、１つ１つ真面目にやる開発チームは、必ず残業が増え、部長、役員から「残業を減らせ」と注意され、お客さんと自社の両方から攻撃を受け、特にリーダーが疲弊して行きます。
ITブラック全盛の2010年以前では、１つ１つ真面目に完璧にやり、更に開発スピード勝負する為に、毎日終電で帰る「どれだけ働けるか勝負」を求められていましたが、その結果、過労で自殺者が増え、社会問題化したので、2010年以降は、定時帰りで、尚且つ開発スピード勝負を求められるようになり、どれだけ作業を削り、どれだけツールを効率的に活用できるかの、「開発生産性のスピード勝負」になって来ています。
※先入観やこれまでの慣習をどれだけ捨てて、「開発生産性のスピード勝負」に勝利できるかは、リーダーの決断次第です。
コメント