「ミノ駆動さん・ログラス松岡さんに聞く！技術的負債のお悩み解消質問会」に参加してきました。
表記イベントに参加してきたので感想を記載します。
下記アジェンダに対して松岡さんとミノ駆動さんがディスカッションするという内容でした。（アジェンダの状況が衝撃ですが・・・)
本編
・ローンチから約5年経過
・ソースコード10万行以上
・開発メンバー約50名
・コードのどこかを少しでも変更するとバグが発生する
・バグ修正すると、別の箇所でバグが発生する
・重大インシデントが慢性的に市場発生するほど低品質
・バグの原因を特定したり、仕様変更の影響範囲を特定するのに非常に時間がかかる。酷いものでは1～2週間要するものも。
・「仕様書を書き、仕様通りにとりあえず動くものを作る」が常態化
・テストコードなし、品質保証は手動動作確認のみ
・数千行オーダーの神クラスが数柱存在する
・ミュータブルなインスタンス変数を何十個も抱えた超巨大データクラスが数個存在する。それらデータクラスはどこのソースコードにも顔を出している（依存している）
・メンバーの設計リテラシが著しく低い。設計と聞くとフローチャート図を想起するレベル。クラス設計と言うとポカンとされる。
・リファクタリングの必要性を感じているメンバーが極わずかに存在する
・「リファクタリングなんかやったら機能開発が遅れる、競合他社に負けてしまう、俺たちの評価が下がる」と考えているメンバーが多数派
・ひどいような印象はあるが、こういう現場は多い。マネージャを巻き込むことがメンバーだと重要
・リファクタリングと聞くと、個人の趣味でコードをきれいにするといったように受け取る上位層もいる。そのため、「リファクタリングしたいではなく、変更容易性を高めて変更失敗性を下げたい」と言った方が伝わる
・反リファクタ派が多数派という事については、評価や採用にも関わってくる。リリース期日を守るを一番評価するとこういった文化になりやすい
・最悪なのは人対人の戦い、問題があっても何とかしなきゃと目線が揃っていれば大丈夫だが、そもそも目線が合わないと辛い
・負債自体が認知が難しいので、リテラシーが高くないと難しい。負債は変更容易性が高い理想的な状況とのGAPなので、その理想的な状況が見えないと議論しづらい。それは自分で手を動かしいかないと見えてこない。設計に興味がある人を巻き込んで進めていく事が重要。色々な方法で巻き込んでいかないといけない
・リファクタリングは低く見られがちなので、プロダクションチームと同様のレベルで専門チームを作って進めた。
・価値観等の共有が重要。組織作りから大事で、マネジメント層の責任がでかい
・リプレースについてはビッグバンリリースは絶対、絶対、絶対やめる。リプレースする場合に不確実性が大きすぎるので、絶対爆発する。なので極力部分的に差し替えていく
感想
他の事をやりながら聞いていたので、つまみ食いでの記載ですが、技術的負債については非常に重要な問題だと思います。理想的な状態が無いと、差が見えないというのもその通りで、理想の状態をちょっとずつでも見える化・言語化・図示化していくスキルが重要だなー。また他の人にしっかりする説明するスキルが重要だなーと感じました。
また、ディスカッションの中で下記本を紹介していました。アートオブアジャイルデベロップメントは現在読書中。コードもう一切書いてないけど、リファクタリングの話とかマネージャーなので分からないとも言えないので、ミノ駆動本も読もうかなー。
この記事が気に入ったらサポートをしてみませんか？