Abstract
主に自社サービスエンジニアを念頭に置いています
- エンジニアも、施策のコンテクストとストーリーを把握しよう
- コードにおける機能の位置付けを把握してコード設計をしよう
- 時にはエンジニアからも代案を出そう
はじめに
仕様の把握。これはエンジニア側にとっても、企画側にとっても大事です。
しかし仕様は、単に「作りたいもの」を示すに過ぎません。自社サービスのエンジニアという、同じコードベースで開発をし続ける立場としては、単に仕様を把握するだけでは、全くもって不十分です。
「良いコード設計を行うには、施策の仕様だけでなく、その施策のコンテクストとストーリーを深く理解することが不可欠である。」
今回はそんな話をします。
コンテクストとストーリー
では、コンテクストとストーリーとは、一体何なのでしょうか。
施策のコンテクスト: 課題背景を把握する
コンテクストとは、その施策が生まれた文脈や背景です。
施策を企画した人は、サービスに対して何かしらの課題感を抱いているはずです。あるいは、チームとして注力している課題があるかもしれません。
- どのような課題を解決したいのか
- どのような動機で、その課題を解決したいのか
などを理解し、「どのような背景でその施策が生まれたのか」を把握します。
施策のストーリー: 仮説を把握する
ストーリーとは、企画した人が考える、その施策の未来予想図です。
施策には、動かしたい数値というものがあります。また、成功や失敗があります。
- どの数値が、どれくらい動きそうか
- どれくらいポジティブ/ネガティブに動けば、成功/失敗なのか
- 施策が成功/失敗した場合、次のステップとして何を考えているのか
などを理解し、「今の施策や次の施策がどちらの方向に進んでいくか」を把握します。
コードにおける機能の位置付け
コンテクストとストーリーを把握することで、サービス全体におけるその施策の位置付けが明確になります。
サービスにおける施策の位置付けが分かれば、コードにおけるその機能の位置付けも明確になります。これはコードの設計方針に大きく影響します。
高い位置付けの場合
コードにおける位置付けが高いと判断された場合、将来においても変更が容易な、柔軟性の高い設計にする必要があります。
高い位置付けの機能は、今後も触られ続ける可能性が高いです。したがって、少しばかり工数が増えたとしても、将来を見据えた実装を優先する方が、サービスにとってプラスになるということです。場合によっては、関連するコードのリファクタリングまで検討してもよいかもしれません。
低い位置付けの場合
コードにおける位置付けが低いと判断された場合、他への影響を最小化した設計にする必要があります。
例えば、期間限定キャンペーン施策であれば、キャンペーン終了後は容易に元に戻せる形で作ります。確度の低い施策であれば、DBやAPIレスポンスに変更を加えるのは避け、既存のもので代用するか、あるいはハードコードで済ませます。
より高い位置付けのコードに影響することがないよう、できるだけ「そこだけに閉じ込める」気持ちで作ります。
エンジニア側からの提案
時には、仕様通りに実装することが難しい場合もあります。
また、実装自体は可能だとしても、既存のコード設計と噛み合わない場合もあります。これをそのまま実装してしまうと、将来的に技術的負債になる可能性があります。
そのような場合は、エンジニア側から仕様の代案を出すことが重要です。
その際に重要となるのが、コンテクストとストーリーの理解です。コンテクストとストーリーを把握することで、仕様の代案を検討する際に、より適切な案を提示することができます。ビジネスサイドとのコミュニケーションも円滑になります。
サービスを継続的に発展させるためには、技術的負債を回避し、コード設計を適切に行うことが重要です。そのためには、エンジニア側からの提案が不可欠です。
結論
効果的なコード設計には、単なる仕様の理解を超えた、施策の深い理解が求められます。
コンテクストやストーリーを理解し、よりよいエンジニアリングを目指しましょう。
ちなみに、「コンテクスト」や「ストーリー」という用語は、私が普段、便宜上使っているだけです。「課題背景」や「仮説」も同様です。あくまで頭の整理に便利なので、適当に名前を付けています。（字面の格好良さもあります。）
もし企画職の方がこれを読んでいて、「用語の使い方が違う」と思ったら、遠慮なくコメントしてください。