スポンサーリンク
ソニーストア
スポンサーリンク
au PAY マーケット

研究開発プロジェクトが上手く行く方法

マネジメント

「研究開発プロジェクトが上手く行く方法」について相談され、自分なりに考えた結果をメールで展開したら評価が高かった。

——————————————————-

先週、「どうやったら開発が上手く行くか?」という質問を〇〇さんにされたので、自分なりに考えてみました。

20年間、日本企業、外資企業、ベンチャー企業、中小企業、大企業、小規模PJT、大規模PJT、ウォーターフォール開発、アジャイル開発、製品開発、研究開発、etc、、、
様々なIT系の開発プロジェクトに関わった経験を振り返ってみると、どんな開発PJTでも、「これをやったら開発が上手く行く」という定石が、1つありました。

大きな開発方針に「開発のスピード勝負」を掲げているチームは、お客さんからの評価が高く、お客さんと良好な関係を築けていて、開発チームは悩まずに開発を進め、開発生産性も高い傾向にあります。

市販する組込み製品は「品質第1」かと思いますが、〇〇のような研究開発寄りのITシステムは、「開発スピード第1」の方が上手く行く傾向にあります。
具体的には、、、早くリリースする為には、省けるものは省くです。

  • 開発スピードを上げて、お客さんが困っているバグがあれば修正版を1週間以内にリリースする。
  • 必要な機能があれば、即実装して最短リリースする。最短リリースが難しい場合は段階リリースする。
  • コメントは必要最小限(ソースコードと重複するコメントは不要)。
  • ソースコードも必要最小限(変数の型名を変数名に加えない、なるべくvarを使う)。
  • ドキュメントも必要最小限(納品しないドキュメントは、要になるドキュメント以外作らない)。
  • お客さんに渡す製品以外の成果物、納品物が必要最小限になるよう、お客さんと交渉する。
  • スケジュール管理はマスタースケジュールベースで行う(WBSは細かく書かない)。など。

「開発のスピード勝負」をする場合、開発作業を改善する時の第1判断基準は、「これは開発スピードを上げられるか?開発スピードを下げないか?」になります。

開発スピード勝負をしている開発チームに比べて、1つ1つ真面目に、細かくやろうとするチームは、1つ1つの作業に時間がかかり、リリーススピードが遅く、お客さんのフラストレーションが溜まり、開発メンバのストレスも溜まっていきます。

お客さんが困っているバグを、次の定例までにリリース出来れば、資料を提出しなくてもお客さんは怒りませんが、1ヵ月かかると、お客さんが怒りだし、資料を作成し現状報告するよう求められ、更に開発スピードが低下し、関係者のフラストレーションが増加して行く悪循環に陥ります。

更に、1つ1つ真面目にやる開発チームは、必ず残業が増え、部長、役員から「残業を減らせ」と注意され、お客さんと自社の両方から攻撃を受け、特にリーダーが疲弊して行きます。

ITブラック全盛の2010年以前では、1つ1つ真面目に完璧にやり、更に開発スピード勝負する為に、毎日終電で帰る「どれだけ働けるか勝負」を求められていましたが、その結果、過労で自殺者が増え、社会問題化したので、2010年以降は、定時帰りで、尚且つ開発スピード勝負を求められるようになり、どれだけ作業を削り、どれだけツールを効率的に活用できるかの、「開発生産性のスピード勝負」になって来ています。

※先入観やこれまでの慣習をどれだけ捨てて、「開発生産性のスピード勝負」に勝利できるかは、リーダーの決断次第です。

コメント

スポンサーリンク
イーカプコン 東京ゲームショウ2020 オンライン ショップ バナー
スポンサーリンク
イオンスーパーセンターオンラインショップ
タイトルとURLをコピーしました