「会話が成立しない」と書くと聞こえが悪いが、正直なところそういう状態だった。
YesかNoで答えられるように聞いても、聞いていないことまで話し足してくる。何が言いたいのかわからない。指示した内容と関係のない話が入ってくる。
そしてコードを書き始めると、手が止まる。止まると考え込む。助けを求めてくるときには「どこで詰まっているか」ではなく「なんかうまくいきません」という状態で来る。
これが何ヶ月も続いた。根性はある。へこたれない。でも会話と作業プロセスに問題があった。
コードを書く前に「説明させる」ことにした
試行錯誤の末に定着させたのが、タスクを着手する前に「何を作るか箇条書きで説明する」 というステップだ。
コードの前に、言葉で説明できなければ着手させない。
自分「じゃあ次はこれをやってみて。被験者の来院記録を登録する機能の追加ね」
Aさん「わかりました」（すぐPCに向かおうとする）
自分「ちょっと待って。コードを書く前に、何を作るか言葉にして説明してみて。箇条書きで」
Aさん「えーと……被験者IDと来院日を受け取るAPIを作って、DBに保存する。バリデーションは被験者IDが存在するかと、来院日が未来の日付かどうか……」
自分「いいね。来院日が未来の日付、という制約はどこに書いてあった？」
Aさん「あ、仕様書には……書いてないかもしれないです」
自分「そうなんだよ。それ、今確認しておこう」
この一往復で、実装に入る前に仕様の曖昧さが表面化した。コードを30分書いた後で気づくより、はるかに安いコストで修正できる。
なぜ言語化が詰まりを防ぐか
「なんかうまくいきません」が来るときは、ほぼ必ず「何を作るかが整理されていないまま実装に入っていた」状態だ。
コードのイメージが先に浮かんで手を動かし始めると、途中で「あれ、このデータどこから来るんだっけ」「バリデーションはどこでやるべきだっけ」と詰まる。そこで初めて「何を作るか」に戻ることになる。これが「迷子になる」の正体だった。
言語化のステップを先に入れると、詰まる場所が変わる。コードの中で詰まるのではなく、言葉にする段階で詰まる。その段階で詰まる方が、対処がずっと早い。
修行でもある
正直に言うと、これは会話の訓練でもある。
「何を作るか説明して」という質問に答える練習は、「要件を整理して話す」という能力と直結している。コードを書く前に言語化するのは、コーディングのスキルより先に必要なコミュニケーションの基礎だと思っている。
会話が成立しない問題は、今も完全には解決していない。でも「この機能は何をするものか」を自分の言葉で説明できるようになったことは、確かな変化だ。
治験システムという文脈での重みが違う
一般的なWebアプリでも仕様の誤解はバグになるが、治験システムの場合は影響の性質が変わる。
治験データはGxPの観点から正確性と追跡可能性が求められる。「想定外のデータが入った」「ステータスが意図しないタイミングで変わった」は、単なるバグではなくデータの完全性への影響として扱わなければならない場面がある。
「動けばいい」では済まないシステムを作っている、という認識を早い段階で持ってほしかった理由はそこにある。
次のステップに向けて
「着手前に箇条書きで説明する」ができるようになったら、次はシーケンス図に起こす練習をする。その次は、API仕様（エンドポイント・リクエスト・レスポンス）を先に書いてからコードを書く習慣に移行する。
「実装ができるエンジニア」ではなく「設計と実装の両方ができるエンジニア」を目指している。コードより先に言語化する、はその一番手前のステップだ。
まだ途中だ。でも方向は変わらない。
関連記事: