インドカレーファンクラブ

パソコン、カメラ

技術的負債を生みにくい組織の夢想

あらすじ

しばらく自社開発をしていて、ローンチ1年以内のプロジェクト以外、どの現場でも負債を溜め込んでいるのを見てきた

事業を開始して間もない内は内部の散らかり具合はさておき開発速度優先で機能を実装していくパターンが多いと聞く
そしてそこでテストが省略される場合もあったり

このあたりはここで多くを語らずとも一般的な話だからほどほどでいいか

そういうことをしたまま、ひたすら走り続けていると「アチャ~もう手遅れ!」みたいなことになるわけだけど、これは不可避なのか?いや組織として頑張ればどうにかなるんじゃないか?と、そういう話がしたい

個人的に負債を嫌う理由

いや負債なんて誰でも嫌いでしょとは思うんだけど、今回は僕の話

例えば2つの組織があってそれぞれで開発すること考えた時に...

負債のあんまりない組織のコード:
解読する時間があんまりかからない
設計がしっかりしていればそのレールに乗るだけでいいので業務ロジックの実装に集中できる
ライブラリも整然としているから不要な迷いや車輪の再発明のリスクは少ない

負債の溜まった組織のコード:
まず解読するところから始まる。解読の時間で開発時間が減る
その実装や設計が素敵(≠嫌味)でない場合には良い時間だけど、解読が必要なレベルのコードでそんな素敵なことがあるわけがない
ついでにライブラリが散っていてどれを使えばいいのかわからない

どう考えても負債がない組織で開発した方が単位時間あたりの学びが大きい
それが日々蓄積していったら自分の開発者としての伸びは鈍化していく気がする

負債の解決も開発者としての学びと言えなくもないけど、そればっかりは嫌だなぁ
逆に言うと一回くらい経験してもいいかも一回くらいは......(で、経験したら転職)

負債をなるべく生まないために組織として最低限どうすればいいのか考えたこと

負債を崩す・返却する方法は既に多くの人に語られている気がするけど、
そもそも負債をなるべく生まない組織レベルでの方法論はあんまり語られていないのでは?
(コードの設計レベルでなら沢山あると思う)

ということで個人的な経験から色々考えた
論理の飛躍がちょっとあるかも。いつか直す

  • 開発のド初期の準備
  • 開発
    • コメントをちゃんと書く
    • ソースチェックでしっかり設計をチェックする
    • 処理が叙述的であるようにする
      • そういうコメントを書く
      • ソースチェックで読みにくいと思ったらコメント増やしてもらう
    • 開発後の後処理を大事にする
      • 仕様書見直して追記するとか
      • やり残したことをメモするとか
  • 組織
    • 技術的負債の課題感に理解のある人が経営層にいる

開発のド初期の準備

アーキテクチャめっちゃ練る

時間を掛けたい

全員それなりにテストを書けるようにする

思うにテストの書き方自体を知らない人類はそこそこいる
テストを書けるようにすることは、それ即ち適切な債務分割ができるようになることに繋がると思う。断言してもいいかも
クラス設計とかする前にテスト書けるようにしたほうがいいと思う
(そもそもしっかりテスト書ける人間だけが設計・実装していったらスパゲッティは調理され得ないのでは?という仮説が僕の中にある)

カバレッジを計測できるようにする

最初からカバレッジを計測できるようにすることでチームの危機感を煽ることができると思う
事業判断としてリファクタを推進したい時も「プロジェクトの中の30%のコードは動作を担保されていない状態で走っています」と言えば合意が取れやすいのではないか?!
「リファクタすることでn%作業効率が上がり、ひいては案件ごとの工数がm%低減されます!」なんて数字はそうそう出せないし、でも一方で偉い人は冷淡にそういう数字を求める。そこに使えそう

開発

コメントをちゃんと書く
特にクリーンアーキテクチャ文脈でのEntityのフィールド相当部分

ドメイン駆動設計なんて言葉があるのに、その駆動元の定義が大変なことになってたら駆動どころではないと思う
ついでに言うとテーブル定義で各カラムの記述をサボってる場合もだめ

ソースチェックでしっかり設計をチェックする

そこで食い止めないと数年後にスパゲッティに苦しみコミットログを見た知らない誰かに呪われる
設計レベルの大仰な話だと「後で直す」は為されない場合が多いと思う

処理が叙述的であるようにする
そういうコメントを書く
ソースチェックで読みにくいと思ったらコメント増やしてもらう

自分で書いてて叙述的ってどういうことかわからなくなってきた

開発後の後処理を大事にする
仕様書見直して追記するとか
やり残したことをメモするとか

事業を優先させて後処理をサボる人間はとても多い
そうならないために後処理で色々やったりドキュメント残したりする時間を明示的に作業内容に含めて、それ込みで工数を出すべきだと思う
そもそも後処理という概念が頭にないが故に後処理が実行されてない可能性がある!

組織

技術的負債の課題感に理解のある人が経営層にいる

技術職あがりが上にいる会社に入りたいかも(そうであれば今までとは違うかもしれない)と最近思う

総括

この二日間スパゲッティコード、スパゲッティ仕様に苦しめられて書いた
はやく社長あるいはCTOになりたい