技術的負債を抱えた状態で技術者がすべきこと - sandbox

この Qiita のエントリに触発され、元文章の目的はさておき、技術的負債についての自分の考えを書いてみようと思う。 技術的負債の定義や、問題は下記エントリを参照して頂くとして、なかでも最後の「技術者がすべきこと」について、「自分だったらこの様にアプローチするか」ということを書く。 技術者がすべきこと 大前提 開発前にステークホルダー(ここではプロジェクトの責任者とする)に、プロジェクトの性質として何を重視するかを認識、選択してもらう。 短期的な価値実現を最優先とし、初速を重視、ソフトウェアの健全さ、プロダクトの成長速度を犠牲にする 長期的な価値実現を最優先とし、ソフトウェアの健全さ、プロダクトの成長速度を重視し、初速を犠牲にする 1 を選択するという事について、健全でない状態や、成長速度が犠牲になった状態がどの様なものかを、プロジェクトが走り出す前に十分に認識してもらう必要がある。 …と

[snjx]

この、数値化とストーリー化。なんかうまいやり方があるかな。

[hibiki_koyo]

開発者にステークホルダーのメール内容伝えて、工数見積もりしたらプロジェクトマネジメント完了！という世界もあり...技術を測定出来ない者がどうやって技術者をマネジメント出来のだろう。

[Dai_Kamijo]

技術的負債を抱えた状態で技術者がすべきこと - sandbox — 上條　大 (@Dai_Kamijo) September 9, 2015 from Twitter https://twitter.com/Dai_Kamijo September 09, 2015 at 02:33PM via IFTTT

[yohichidate]

この考え方は開発サイドもそうなんだけど、それ以上に運用保守サイドでも積極的に取り組むべき。

[te2u]

自分の経験上、大前提の(1)はビジネス上の判断で技術者でない人が決め、技術者が反対しその理由を説明ても、大抵は無視され押し通された。だからこういう話が通用する環境は羨ましい。