はじめに
仕様書は読める。
I/Fの内容も理解できる。
シーケンス図もなんとなく分かる。
でも、
・どこで処理を書けばいいのか分からない
・どのタイミングでI/Fを呼ぶのか分からない
・コードにどう落とせばいいのか分からない
そんな状態で、手が止まってしまうことはありませんか？
これは新人・初心者に限らず、
現場に入ったばかりの人がよくつまずくポイントです。
前提：資料は理解できている
多くの場合、
・画面フローは読めている
・シーケンス図も理解できている
・I/F仕様も分かっている
それぞれ単体では理解できています。
それでも手が止まるのは、
それらが繋がっていないからです。
なぜ「繋ぐ必要」があるのか
それぞれの資料は役割が違います。
・画面フロー → 画面全体の流れ
・シーケンス図 → 処理の流れ
・I/F仕様 → 外部とのやり取り
これらは単体では「部分の説明」です。
しかし実装では、
「どの画面で、どの処理をして、どのI/Fを呼ぶのか」
を決める必要があります。
そのためには、
これらの情報を繋げて
1つの流れとして理解する必要があります。
設計がないのではなく「繋がっていない」
本来であれば、
・画面フロー
・I/F仕様
・シーケンス図
これらを繋いだ設計が整理され、
実装に入るのが理想です。
しかし実際の現場では、
スケジュールの都合
発注側が既に理解している前提
「見れば分かる」という判断
などにより、
資料が分断された状態のまま
実装フェーズに入ることも少なくありません。
ここで重要なのは、
「設計がない」のではなく、
“繋がっていない状態で存在している”
という点です。
さらにこの問題は、
個人のスキルだけでなく、
資料の分断や前提共有不足によって
チーム全体で発生しやすい問題でもあります。
どう繋げていくのか（線で理解する）
では、どうやって繋げて考えるのか。
UI開発を例にすると、次の順番で整理します。
まず、画面フローを見て、
画面の遷移と全体の流れを把握します。
次に、シーケンス図を見て、
その画面遷移を実現するために
・どこと
・どんなやり取りをするのか
を確認します。
ここで、
・今の画面で必要な処理
・次の画面に遷移する条件
を整理します。
この必要な処理や遷移する条件を
I/F仕様書を見て、
・どのI/Fを呼ぶのか
・どんな引数を渡すのか
・どんな値が返るのか
を確認します。
データが見えない問題
ここまで整理できても、
まだコードに落とせないことがあります。
それは、
必要なデータがどこにあるか分からないからです。
I/F仕様書には、
・渡すべき引数
・返ってくる値
は書かれています。
しかし、
・そのデータをどこから取得するのか
・いつ取得するのか
・どのように管理するのか
までは書かれていないことが多くあります。
そのため、
「I/Fは分かった。
でもこの値、どこから持ってくるの？」
というところで手が止まります。
設計が必要になる理由
そしてここからは、
設計の領域に入ります。
どの単位でデータを持つのか
どのクラスに責務を持たせるのか
共通的に扱う仕組みが必要か
といった判断は、資料には書かれていません。
そのため、
「何をするかは分かった」
「必要なデータも分かった」
でも、
どういう形でコードにするか分からない
という状態になります。
どこに実装するかという判断
さらに実装では、
どこに記述するのか
も決める必要があります。
例えば、
画面構成 → View
画面の動き → ViewModel
外部連携 → Service
といった形で役割を分けていきます。
まとめ
コードに落とすためには、次の順番で整理する必要があります。
画面フローとシーケンスを繋ぎ、処理の流れを理解する
I/Fと繋ぎ、やり取りの内容を理解する
必要なデータを見つける
データの管理方法を設計する
どこに実装するかを決める
この流れが繋がって初めて、
仕様書とコードは繋がります。
おわりに
同じような状況で困っている方がいれば、
どこで詰まっているのか
どの部分が繋がらないのか
をコメントで教えてください。
今後の記事で取り上げていきます。
※仕事の都合上、返信が遅れる場合がありますが、必ず目は通しています。