前回までの記事

新人が機能追加分のユニットテストを担当することに

前回、期日と期限切れ表示の仕様が追加されたとき、若手は「判断ロジックは reducer に集約する」という方針で設計を整理していた。
そのおかげで、新しい仕様にも冷静に対応でき、迷いなくユニットテスト範囲も定められる感覚を得ていた。

その設計が、他の人にも伝わるかどうか──
それを、今回新人に説明することで試されようとしていた。

ふんわりした雰囲気の新人だった。言葉選びや動きは柔らかいのに、
ユニットテスト設計の話になると急に研修モードになって真面目になる、ちょっと不思議なタイプだった。

若手：「期日と期限切れ表示のユニットテスト、○○さんにお願いしていい？」

そう言われて、若手は少し驚いた。新人に任せるには少し早い気もしたが、
最近は吸収も早いし、ちょうどいいかもしれない。

新人は、目をぱちくりさせながら答えた。

新人：「えっ、私が一人でやるんですか？　えーっと……じゃあ、まずは仕様をぜんぶ洗い出して……
あ、いや、研修では最初に“同値クラスと境界値”ってやるって……えーっと……」

いつものふんわりした口調のまま、研修で習った言葉だけはしっかり飛び出してくる。

構造はしっかり分けた。ユニットテスト観点も reducer に集まっている。
設計の意図をちゃんと伝えれば、ユニットテストもやりやすいはず――そう思って、
若手はコードを見せながら説明を始めた。

コードで説明しても、伝わらない

だが、新人の表情は曇ったままだった。

新人：「App.tsx 全体を見て、どこからユニットテストするのかって考えると……わからなくなってきて……
研修では、まず境界値テストでケースを出すって言われて……」

彼女は感覚派で、普段はふわっとしている。
なのに、ユニットテストの話になると妙にマニュアル的だった。

若手は一生懸命、コードを指しながら説明した。

若手：「この useReducer が、期日を受け取って、それが期限切れかどうかを判断するロジックを持ってて……」

新人：「あっ、でもこの state、UIでも使われてますよね？
ってことは、“画面の動きも含めて確認した方がよくないですか？”」

若手：「いや、UIはただその結果を表示してるだけで、ロジック自体には関与してないから……」

新人：「でも、“表示されるかどうか”も含めて、ユニットテストするのが丁寧じゃないですか？
研修では“期待される振る舞いを全体で確認する”って教わってて……」

若手：「（うーん、言ってることはわかるけど、見てほしいのはそこじゃないんだよな……）」

新人：「ここで期日を入力して、ここで reducer が期限切れを判断して……」
だが、新人はまた首をかしげた。

図にしたら伝わった。“どこで責任が決まるか”を見せただけ

その瞬間だった。
背後から、紙を一枚持った師匠が近づいてきた。

師匠は近づいてくると、紙とペンを手に取りながら口を開いた。

師匠：「お前さー……ちゃんと“どこで何を判断してるか”を伝えなきゃ、テストする側は迷うだけだ」

そう言って、サラサラと紙に図を描き始めた。

新人：「……なるほど、責任ごとに分かれてるってことですね」

師匠は静かに言った。

「ユニットテストってのは、本来全部見る必要はない。
“誰が何を受け持っているか”が分かっていれば、そこだけ見ればいい」

そして去っていった。

若手はその図を見て、ようやく気づいた。
コードではなく、“責務の位置”とその関係を見せなければならなかったのだ。

若手：「期日のロジックは reducer に閉じている。
だからそこだけ見ればいい。
UIや入力は関係ない。そう、ユニットテスト対象は reducer の責任の中だけなんだ」

新人は目を見開いた。

新人：「……それなら、わかります！今回はreducer の中だけ見ればいいんですね！」

設計が伝わるとは、“責任の範囲”が見えること

その日の作業が終わり、若手が帰り支度をしていると、師匠がぽつりと話しかけてきた。

師匠：「なんとかなったようだな。
WHATで語れ。何を、どこで、誰が決めてるか──
それが見えてれば、設計もユニットテストも、ブレないんだよ」

師匠：「HOWで会話を始めると、いちいち細かい前提が必要になる。
でもWHATで共有できていれば、本質だけで伝わる。
プログラマーも、テスターも、同じ土俵で向き合えるんだよ」

若手：「確かに。前教わったのに、まだ意識が足りなかったです」

師匠：「HOWで仕事をすると、毎回“詳細まで把握してる人”しか進められない。
でもWHATで捉えていれば、“意味が決まる場所”さえ押さえておけばいい。
結果、テストも説明も速くなる。仕事の質も、スピードも、一気に上がるんだよ」

若手は思わずうなずいた。
その言葉が、今日の自分の動きとぴったり重なっていたからだ。

設計ってのは、コードを整理することじゃない。
どこを触ればいいか、どこだけ見ればいいかが“人に伝わる構造”にすることだ。
だからこそ、責任は分けて閉じておく必要がある。
その構造があれば、テストも説明も、最短距離で伝わる。
無駄な確認が減って、仕事の質もスピードも一気に上がる。
振り返ってみると、あの一枚の図がすべてを変えた気がした。
若手は、ようやくそれに気づいた。

ひょっとして、AIにも設計意図を伝えることができたら・・・

※本記事ではストーリーの流れに焦点を当てるため、条件網羅や詳細なユニットテスト設計（同値/境界値等）には触れていません。
「責務が閉じた設計」によってユニットテスト範囲が自然と見える──という観点に絞っています。

次回の記事予告

ここまでお読みいただき、ありがとうございました。
本記事では、AIを使って開発を進める中で直面した「設計不在」の怖さと、それを乗り越えるために必要な“伝わる設計”の視点について紹介しました。

次回は、師匠から教わった設計の基本――「STS設計（入力・変換・出力）」というシンプルで強力な考え方を軸に、実際にReactアプリの構造を改善していくプロセスを紹介します。

もし、AIの出力をそのまま使ってコードが混乱してきた方、自分の設計に不安を感じている方には、きっと役立つ内容になるはずです。ぜひご期待ください！

また、今回紹介した内容をより実践的に学びたい方には、以下のUdemy講座もおすすめです。

Udemyコース（8,800円 → クーポンで割引中）

▶️ AIとC#で極める！クリーンコードの技法（限定クーポン付き）

C#でクリーンコードと設計力を身につける実践講座
ChatGPTの活用方法や、伝わるコードの考え方を解説

出版書籍『あきらめない者たち』

▶️ Amazonで見る

技術の基礎からやり直すために、なぜ一歩勇気を振り絞れたのかのノンフィクション作品です。