詰め込み型のソフトウェアプロダクト開発は誰も得しない｜mtx2s
チームのキャパシティを超える要求を抱えたプロジェクトが、なんの問題もなく完了するはずがありません。なんとか作り上げられた機能は、表面上は要求通りでも、どこかぎこちなさを感じます。ユーザー体験が悪く、それがユーザー価値を押し下げ、ビジネス価値を削り取ります。触るたびに新しい欠陥も見つかるかもしれません。内部品質も最低です。それが今後の追加開発の足を引っ張ることにもなるでしょう。そして、ただ消費するような働き方によって、チームは成長も達成感も感じられず、疲弊します。 詰め込み型のプロジェクトは、誰にとっても利点がなく、そのうえ持続不可能なやり方なのです。 「詰め込んでもなんとかなる」という楽観主義詰め込み型のアプローチは、組織内でプラクティス化しやすいプロジェクト計画手法です。この手法で完了したプロジェクトは、一見すると、上手くいったように見えます。多少の遅延があったとしても、概ね一通りの機能
「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号｜mtx2s
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく｜mtx2s
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
