6話 WHATの図で説明したら、設計の意図もテストの範囲も一瞬で伝わった

# 前回までの記事
https://qiita.com/Siras-inc/items/f400c1165fe57a12c4c2

https://qiita.com/Siras-inc/items/4ffd00d710f4a2255839

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

![STS_APPtx.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4079641/1469332c-6188-4d6a-80a6-68bc63fbc269.png)

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

----------------

師匠は静かに言った。

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

そして去っていった。

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

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

新人は目を見開いた。

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

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

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

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

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

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

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

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

----------------

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

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

----------------

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

 # 次回の記事予告

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

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

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

---

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

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

▶️ [AIとC#で極める！クリーンコードの技法（限定クーポン付き）](https://www.udemy.com/course/aic-hjke/?couponCode=C49C4B16FBE249DDFFDA)

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

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

▶️ [Amazonで見る](https://amzn.asia/d/dK37sIu)

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