組織パフォーマンスを改善しよう! http://kakakakakku.hatenablog.com/entry/2017/06/24/004845
![技術的負債を "なるべく" 作らないためのコツ / Organization Performance Tips](https://cdn-ak-scissors.b.st-hatena.com/image/square/79dfa9822f9928b6b9ba2f3b7e622a1b1274554c/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F4dfd1bcd4768463f9d36a435e8257754%2Fslide_0.jpg%3F8183309)
実に2年ぶりのエントリになりますが;、今日はこちらの話題を。 少し前の話になりますが、5 月下旬に弊社イベント de:code 2016 で、ちょっと変わったセッション「拝啓『変わらない開発現場』を嘆く皆様へ ~エンプラ系 SI 開発現場の「今」を変えていくために~」を担当させていただきました。内容は、エンプラ系 SIer のプロパー(PL, PjM, SE)の方々向けに、設計やテスト手法の改善テクニックの要点などを通して、開発現場を改善していくための考え方を解説する、というもの。未来をお届けするイベントなのに最新技術を一切説明しないという異色のセッションにもかかわらず、参加者満足度(NSAT)ランキングで全 125 セッション中 2 位という結果になったことに大変感謝する一方で、私自身、いかに日本のエンプラ系 SI の闇が深いのか、を改めて実感することになりました。 セッションの内容につ
(編注:2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く