マーケティングテクノロジーグループの齊藤です。
ディレクタスに入社して約2年、設計を任せていただけるようになって約1年半。
今回は、私が日々設計業務に取り組む中で必須ではないけれど大切だと感じ、心がけていることをご紹介します。

そもそも設計業務って？という方もいらっしゃるかと思いますので、まずはそのご説明から。
 

■設計業務とは

 
例えば「商品Aを購入した人に購入後アンケートメールを配信し、結果を商品やサービスの改善に活かしたい」という構想があったとして、そこから配信を実施するまでの大まかな流れは以下のとおりです。

構想 → 要件定義 → 設計 → 設定 → テスト → リリース作業 → メール配信

上記のうち、ディレクタスで設計業務に分類されるのは「要件定義」と「設計」の工程です。
構想を実現するための決め事を書き出して、考慮漏れや誤りがないことやクライアント様と我々との間で認識に齟齬がないことなどを確認する工程を「要件定義」、要件をもとに具体的なアプローチの方法を考えて設計書に落とし込んでいく工程を「設計」と呼んでいます。

今回は設計業務の中でも、

・抽出から配信までの具体的なフローを考える
・配信対象者のデータや回答データを格納するためのテーブルの構造、項目を設計する
・配信対象者を抽出するためのSQL文を書く
・アンケートフォームから回答データを収集するためのスクリプト文を書く

といった「設計」の工程で心がけていることをご紹介します。

 

■他の人が見てわかりやすいものにすること

 
一度設計したものはリリースしたらそれで終わり…ではありません。
似たような施策の設計を行うときや、後から改修の必要が出てきたときなどに、自分が作った設計書を自分以外の人が見る可能性があるのです。
そのため、目指すゴールに到達できるような設計にするのはもちろんのこと、設計をする際は「他の人が見てわかりやすいものになっているか」という視点も持っておく必要があります。

他の人が見てわかりやすい設計にするための手段は色々ありますが、特に私が意識して実践しているのは「SQL文・スクリプト文の中にコメントを書くこと」です。

コメントというのは、コードの中に書く「実際の処理には影響を及ぼさないメモ」のようなもの。
多用しすぎると逆に読みにくくなってしまうので注意が必要ですが、適切に使用すればコードの可読性を上げることができます。
 
誰かが書いた数百～数千行にわたるコードを解読するのはなかなか骨が折れる作業ですが、「ここからここまでは○○を△△するための処理」などと要所要所にコメントが書かれていれば、コード全体の流れを把握する助けになります。
流れが把握できれば各行の処理内容も理解しやすくなるため、解読にかかる時間を短縮することが可能です。

私自身、コメントが書かれていて助かったと感じる場面は多々あります。
そういった経験から、自分が設計する際はその設計書を初めて見る人の目線に立ってみて、必要だと感じる部分には積極的にコメントで説明を入れるよう心がけています。

―――

以上、私が設計業務に取り組む際に心がけていることをご紹介しました。

「受け取り手にとって分かりやすいものになっているか」を相手の目線に立って考えることは、何かを作ったり発したりするあらゆる場面で大切なことです。
今回は設計に焦点を当てた話になりましたが、設計業務以外の場面でも同様に心がけて過ごしていけたら良いなと思っています。