俺達はなぜ良いコードを書くのか 〜『良いコードの道しるべ』著者と探る変化に強いソフトウェア〜 に参加しました。
イベントの概要
新刊『良いコードの道しるべ 変化に強いソフトウェアを作る原則と実践』の出版を記念して、トークイベントを開催します。 このイベントでは、本書の筆者である森 篤史に加え、豪華ゲストを迎えて、本書の魅力やソフトウェア開発における「良いコード」の秘訣について語り合います。
引用：
イベント参加の背景
- 久しぶりの実装体験から良いコードを書くことを学びなおしたいと考えている
- プロダクトチームで「良いコード」に対する共通理解を育てたい。
- 登壇者が手がけた翻訳書から多くの刺激を受けており、直接話を聞きたかった。
セッション
ディスカッション1 『良いコードの道しるべ』の誕生秘話と見どころ紹介
なぜこの本を書くに至ったか
高専ではいろいろなプロジェクトに携わった。
書くのは速かったが、読みづらいという評価があった。
それを契機に保守性に対する意識が生まれ、書籍やブログ記事から学び実践した。
４年前、新卒向けのスライドを公開したところ好評を得て書籍出版に至った。
本書の見どころ、活用方法
見どころ①：命名、コメント、関数やクラス
見どころ②：アプリケーション全体
徐々に視野が広がるように構成している。
コードは書くより変更する方が難しい。（８章）
ボーイスカウトルール、ゼロベースでの理解 など。
見どころ③：保守性に関する知識。
アーキテクチャの話（９章）、自動化テスト、チームで書く良いコード
見どころ④：挿絵。
読んで欲しい人
- コードを書けるようになってきた頃の若手エンジニア。
- 中堅エンジニア。ふりかえるきっかけ、若手育成、共有意識作りに。
苦労した点
- スライドを書籍迄育てること。
- レビュー。大勢の人に見て貰っている。
- 今まで無意識にやってきたことに対する改めての言語化。
- イメージはしやすく、視野を限定しないように。
パネルディスカッション2 類書執筆・翻訳者と徹底議論 〜良いコードとはなにか〜
コメントを書くとき書かないとき
・森さん
コメントしても情報量が増えない場合は不要。情報量増えるなら書いた方が良い。
メソッドのレスポンスなど、ソースコードから読み取りにくい部分にはコメントを書く。
クラスの意図を示すコメントは有意義。ただし、プロダクトのフェーズ次第でオプショナルにする。
全部の関数にコメントを書くなどのルールは微妙。
クラスの意図を書くことには意義がある。
但し、プロダクトのフェーズにも依る。場合によってはオプショナルにする。
・高田さん
背景事情など、新しい情報を補足できるコメントは有効。
・石川さん
ドキュメントコメントとインラインコメントは別物。
コードを読まなくても理解をさせるコメントと、コードを読む助けとなるコメントを別物として扱う。
単純なデータモデルにもコンテキストを明示するためのコメントは有効で、言語化の訓練にもなる。
・秋さん
ソースコードには表れない伝えたいことをコメントにする。
YAGNIと無計画はどうちがう？
・高田さん
状況によってバランスが違う。
計画をガチガチに立てるとうまくいかないことがある。
何も考えないでコードを書くことは時間を無駄にしているともいえる。
ある程度計画を立て、予測を立て、柔軟にコードを書けるのが良い。
・秋さん
必要ないものを実装しない、にも解釈がある。
無計画にやって、リファクタしていくのが好き。
・石川さん
YAGNIは今必要とされていないものを実装しないこと。
設計やそこに至るまでの議論は対象にしていない。
なので、YAGNIと無計画は別の議論。
・森さん
YAGNIは計画的にすべき。
ただ、未来の予想は必要だが、時間をかけすぎることも問題。
ある程度の段階で将来の予測を打ち切り、その時点での求められる姿を実現すべき。
生成AIによってソフトウェアの保守性はどう変わる？
・高田さん
変わらない。
コード書く量は少なくなる。ただ、最終的判断は人。
コードの良し悪しの判断は時間がかかるため、結局は保守性は必要となる。
・秋さん
人間という最終的なゴールは変わらない。
・石川さん
人間が認識できないといけない。
生成AIのソースも人間が書いたコードがソース。保守性が高いものの方が読みやすい。
生成AIは大雑把。リファクタを考えるとまだ人の手が必要。
保守性の観点で変わるのは人間が見なくても済む部分。一方で、人間がきちんと見なければならない領域が上がると感じている。
・森さん
来月何がでるか分からないから何とも言えない。
人間のレビューが必要な間は保守性に求められる考え方が重要だと思う。
直近で考えると生成AIのコードを評価する必要はあるため、価値はあがると思う。
質疑応答
いかにチームに保守性に対する意識を浸透させるか
・石川さん
チームに浸透させたくてプレゼン、書籍を作った。
言語化してアウトプットした。そうすることでチームに浸透させた。
・森さん
新卒研修は課題感より自分の気持ちから。
チーム内でのコミュニケーションは重要だと思っている。
気軽に雑談できる関係性。もっとコードをよくできないか会話できる関係。
生成AIのレビューについて
・高田さん
良いと思う。初回レビューをAIに任せるとつまらないミスは拾える。
AIの信頼レベルをあげることで、有効活用もできる。
100%頼ることはしない。AIに依存しない。人の判断力は重要。
プログラミングの初学者には良いコード、動くコードどっちが大事？
・久野さん
まずは動くコード。コードを書くことに詰まったら良いコードを学ぶのが良い。
・森さん
コードを書くことが楽しいなら、いったん動くコードを書いていくのが良い。
タイミングが合わず得た知識は頭でっかちになってしまう。
執筆が止まった時のモチベーションの上げ方
・秋さん
趣味に没頭して余裕を取り戻す。
・石川さん
１か月の有給。ON/OFFをはっきりさせた。共著者を巻き込む。
・森さん
毎月出版社の方とのMTG。締め切り駆動。
王道であるリーダブルコードとの違い
・森さん
『良いコードの道しるべ』は日本語で書かれた本。
最新のプラクティスを取り入れている。広範囲でもある。
会場交流会 & サイン会
『クリエイティブプログラミング』翻訳者の秋さん高田さんにサインを頂いてしまいました！！嬉しい！！
今、同じプロダクトチームのメンバーが『ストリートコーダー』を読んでいて、時おり感想を聞かせてもらうたびに「自分も読んでみたい」と思っていました。
そんな一冊に関わる方に直接ご挨拶できて、とても嬉しかったです。
改めて、感想を語り合うためにも早く読みたいと思いました。
また、『Looks Good To Me: ~ みんなのコードレビュー』の監訳者である増井さんにもお話をお伺いできたことも嬉しかったです。
今、チーム開発におけるレビューの取り扱いに悩んでいます。
レビューはボトルネックになりやすく、上下関係を生んでしまうこともある。
しかし、保守性をチーム全体で意識できなければ、ソースコードは静かに、そしてじわじわと理解不能な状態へと向かっていってしまう。
けど、保守性をチームで意識できないとソースコードは静かにゆっくりと訳の分からない状態になっていく。
ただ、レビューのことを考えているタイミングはなかなか訪れない。
そうしたもやもやを持っていたので、本書はずっと気になる一冊でした。
今回、改めてそうした課題感に対する参考になりそうと思ったため、改めて読まねばと思いました。
また、ここぞとばかりに増井さんにObsidianについてもお話を聞いてしまいました。
Obisidianは手元のファイルを編集できることと、プラグインで色々拡張できるところが魅力。
お相手してくださり本当に感謝です。
Obsidianが流行っているけれど、なぜ注目されているのかわからない、という声があったので、https://t.co/IU07xRwwvxで記事を書きました。
— 増井敏克 (@masuipeo) 2025年5月12日
なぜObsidianが2025年になって注目されているのかhttps://t.co/TK5gAkBQOi
増井さんのご本を初めて読んだのはこの本でしたが、ご挨拶できて嬉しかったです。
まとめ
いつも刺激を頂いている書籍の翻訳者の方たちにご挨拶でき幸せな時間でした。
森さんの仰っていた品質に対して気軽に雑談できる関係性をチームで築く重要性は首がもげるほど同意でした。
今のチームでは少しずつですが、互いにとって大事だと感じることを言葉にし、それを納得のいく迄議論することができ始めました。
そうした時に、我々の知識だけではなく、書籍や誰かのアウトプットを介して得た知識が触媒になってチームにエネルギーを与えてくれていることに気付きます。
そうした書籍の出版イベントに参加できて嬉しかったです。
Forkwellさんの動画ももう一度見たい。
