ソフトウェア開発、2026.01
設計やコーディング
当たり前のように生成AIを使った設計の壁打ちやコーディングの指示をしている
設計前にコンセプトの壁打ちに多く生成AIを使っている
いまのアイディアをストックさせてセッションを終えたあとに再度壁打ちでも使う
途中出てきたアイディアはまた別のストックとして保存させる
時間に余裕がある状況であれば最終的に設計を荒い実装で完成させる
ほとんどはその荒い実装をベースにして自分で捨てたり足したりすることがほとんど
簡易的な作業は完全に任せている
すでに存在するコンポーネントの指針に従えば事足りる場合、指示を明確にしてやらせることが多い
また動的型付け言語のような、静的解析で担保できずにテストケースが増える場面では、生成AIに網羅するテストを書かせたほうが早い
ただし生成AIがやりすぎるくらいテストを書く傾向があるのでここも指示は明確にしておいたほうがよい
LLMがコードを書いて人間はレビューするにもあるとおり、ボトルネックがレビューになっていると感じる
生産が進んでも(レビューが済んでいないので)仕掛りの在庫だけがたまっていくので、体感としてリリースサイクルが早くなっているということはまったく感じていない
レビュー
前述のようにレビューには多くの時間を割いているように感じる
つまりこれは、変更差分のコードリーディングに多くの時間を割いているように感じる、と同義であろう
これまで直感的だった判断が、ソフトウェア設計の結合バランスのおかげで言語化できるようになった
位置引数ではなく名前付き引数にすることでコナーセンスのレベルが弱くなるからよい、任意の処理だけをうまくやる関数にほかの知識を混入しない (外部・共通結合を避ける、必要以上のデータを共有しない=スタンプ結合を避ける) など、直感が言語になっている変化を感じている
Rails 以外はいわゆるレイヤードアーキテクチャを採用するプロジェクトに関わっているが、依存の方向やレビューで危険な香りを感じとったら一生懸命言語化を試みている。試みているということは整理しないとまだ言葉にできない、ということだ
コンポーネントにおける上位・下位の混同をしない
責任や労働としての請け負い方
ずいぶん楽にみがまえるようになった
当然のことだが、労働の現場においてソフトウェア開発というのは複数人が集って行うものだ
自分ひとりでは何もできないという大前提にたったうえで、なんとか自分で切り盛りするようになった
2年前くらいに新しいシステムにGoを使おうと決めて腹がくくれたし自信を再び持てるようになったことも相乗する
(時間がかかったとしても) 最終的にひとりで作れるしな、と強がれる状態にあることは精神を安定させる
これは前々職の上司が言ってた言葉だったが身にしみて早くこの状態になっていればよかった
なので2022年あたりに不眠をともなったストレス過多の労働冬の時代は終えたといってもいいだろう
とはいえいまだに不眠は稀に現れるのでそれはそれとして付き合う必要がある