エンジニアはなぜ「細かいこと」を気にするか？

noteの機能に、条件を満たしたらバッジが貰える「バッジ機能」というものがあります。中でも「毎週連続投稿バッジ」というのがあり、僕にとっても週に1回は記事を投稿しようというささやかなモチベーションにつながっています。

多くの人は、このバッジを見ても「毎週投稿したらバッジが貰えるんだな」としか思わないかもしれません。しかし、エンジニア的な視点で見ると、つい気になってしまうことがあります。

今回は、「毎週連続投稿バッジ」を例に、機能を実装するエンジニアの気持ちを体験してみましょう。その中で、「業務を自動化する」とか「機能を実装する」ということの裏側には無数の「選択」が存在することを紹介します。「エンジニアの仕事だから関係ない」と思うかもしれません。しかし、プログラミング的思考は広く役に立ちますし、NoCodeツールの普及で誰もが機能を実装することができる時代が来ているとも言えます。あなたにも無関係な話ではないはずです。

「毎週連続」の定義とは？

さて、あなたはnoteの「毎週連続投稿バッジ」の実装を担当するエンジニアだとします。このとき真っ先にプロダクトオーナーに質問して明らかにしなければならない点はどこでしょうか？

それは、「毎週連続」という言葉の定義です。

日常生活では、たとえば「このサボテンには"毎週"水をあげてね」と言われても、「なんとなく7日間くらい間を空けて水やりすればいいんだな」というフワッとした理解で足ります。

一方、プログラムを書いてコンピュータに命令する場合は、そうはいきません。コンピュータは、曖昧さが嫌いで、厳密に、詳細に、具体的に処理を記述しなければ思った通りに動かないからです。

たとえば、次のようなタイミングでnoteの記事を投稿した人（Aさん）がいたとします。

この人は、「毎週連続投稿」が継続しているといえるでしょうか？

これは「毎週連続」という言葉の定義に依ります。パッと思いつく「毎週連続」の定義は、次の2通りです。

定義1は、「"投稿がある週"が連続している」というものです。日々はカレンダーのように「週」に分割されていて、各週毎に「投稿があったかどうか？」の判定が行われます。Aさんの場合、1週目は月曜日に投稿し、2週目は日曜日に投稿しているので、「投稿がある週」が2週間連続しています。つまり、「毎週連続投稿」が継続しているという判定になります。

定義2は、「投稿の間隔が7日間以下である」というものです。前回の投稿から1週間以上空いていたら、「毎週連続投稿」はその時点でリセットされます。Aさんの場合、1回目の投稿から2回目の投稿まで、13日間空いています。つまり、「毎週連続投稿」は継続できなかったという判定になります。

このように、「毎週連続」という言葉の定義によって、同じ投稿タイミングでも「毎週連続投稿」のバッジが貰えるかどうかが変わってしまいます。

エンジニアはなぜ「定義」を気にするか？

「毎週連続」についての定義を定義1と定義2のどちらにするかによって、「毎週連続投稿」の判定プログラムの内容も当然大きく変わってきます。定義1の場合は「先週中に投稿したか」が重要なのに対して、定義2の場合は「前回の投稿日から何日経っているか」を考慮する点に違いがあるからです。

さらにいえば、どちらを選んだとしても、まだプログラムを書くための厳密な定義とは言えません。

たとえば定義1の「"投稿がある週"が連続している」を選んでも、「週」の定義が曖昧です。上の図では、「週」は「月曜始まり」でした。もしこれが「日曜始まり」だとしたらどうでしょう？

このように、「日曜〜土曜」の1週間が丸々空いてしまっているので、一転して「毎週連続投稿」は継続できていないという判定になってしまいます。

もし「投稿の間隔が7日間以下である」という定義2の方を選んでも、「投稿の間隔」というのは日付ベースなのか、時刻ベースなのかを決める必要があります。

僕も含めエンジニアと仕事の話をするとき、多くのエンジニアはとかく「定義」に関する質問をたくさんしてきます。「"特定ブランドに興味があるユーザー"とは、具体的にどういう行動をしているユーザーですか？」、「"よく購入されている商品"とは、どの期間にどのくらい買われている商品のことですか？」といった具合です。

こうした質問は、もちろん嫌がらせでしているわけではありません。エンジニアとして機能を実装する上で、「定義が曖昧である」ということは、「間違ったものを作ってしまう」ことと隣り合わせだからです。他の人には取るに足りない些細なことに思える違いであっても、それを実装する作業に大きな違いが出てしまうということも多々あります。

ちなみに、「Aさんの投稿タイミング」のような判定ロジックの穴を突く厄介なケース（事例）のことを、エッジケースとかコーナーケースなどと呼びます。定義を明確にし、どこまでのケースを機能として想定するかについて合意を取っておくことで、一度開発した機能を一から作り直すリスクを軽減することができます。

「定義」を決めるための3つの判断軸

実際に、「毎週連続」の定義を「"投稿がある週"が連続している」（定義1）と「投稿の間隔が7日間以下である」（定義2）のいずれにするかを考えてみましょう。それを決めるための判断軸は、主に3つあります。

誰にとってもわかりやすい判断軸は、「ユーザーにとってどちらが良いか？」というものです。定義1の「"投稿がある週"が連続している」というのは、もしかしたら多くのユーザーが「毎週」という言葉に抱く感覚に近く、より直感的かもしれません。一方、定義2の「投稿の間隔が7日間以下である」を選んだ方が、週始まりの曜日を気にする必要がなく、フェアで納得感のある説明がしやすいでしょう。

さらに、とりわけエンジニアが気にする判断軸があります。1つは、「実装コストはどちらが低いか」というものです。実装コストを決める要素にもいくつかありますが、主には複雑なロジックであるほど実装コストが高くなります。定義1では「週」という概念を考慮する必要がありますが、定義2では前回投稿日からの経過日数だけを計算すればいいので、直感的には定義2の方が実装コストは低そうです。

もう1つの判断軸は「どちらの方が変化に強いか」というものです。「変化」もまた多くの種類がありますが、よく考慮されるのは「仕様変更」です。たいていの機能は、一度作って終わりではなく細かい修正や機能追加などの仕様変更が都度行われます。いずれ来る仕様変更を見越して、より有利な定義を選んでおくということも重要になります。たとえば、「毎週連続」の後に、「毎月連続」や「毎日連続」など異なるタイムスパンが追加されるとします。定義1を採用していた場合は、「週」と同じような考慮を「月」や「日」でもする必要があり、追加の実装が多くなりそうです。定義2の方は、「前回投稿日から7日間経っているか」という処理を「前回投稿日から30日間/1日間経っているか」という風に日数だけ変えれば楽に対応できそうです。

このように、単純に「どっちの機能がいいのか」だけではなく、実装観点で見たコストも含めて判断することが、事業上有利な選択につながります。特に、変化の激しい現代では「いかに変化に対応しやすい状態を維持するか」が重要になってきています。

「コンピュータに対するデザイン」

ここまで説明したような、機能にまつわる言葉の「定義」を厳密に決めていく作業は、「設計」と呼ばれる大きなプロセスの中に位置付けられます。

同じく「設計」という意味を持つ「デザイン」は、多くの場合「人間に対するデザイン」という意味を込めて使われます。

一方、主にエンジニアが担当するような「設計」の中には、「コンピュータに対するデザイン」が多く含まれます。言葉の「定義」の話であれば、人間が日常会話で話すような曖昧な言葉を、コンピュータにもわかるような厳密なプログラミング言語まで落とし込むために必要なプロセス、ということになります。「毎週連続投稿していたら」という言葉よりも、「投稿の間隔が7日間以下なら」という言葉の方が、より具体的でコンピュータフレンドリーであるというわけです。

ある機能の仕様に関する選択だけではなく、「エンジニアリング」のプロセスの中ではコンピュータを意図通りに動かすための技術的な選択が無数に求められます。どんなIaaSやどんなプログラミング言語を使うのか、データベースにどうデータを保存するのか、どんな画面でユーザーに機能を提供するか。こうした選択の全てにおいて、多かれ少なかれ「この選択は変化に強いか」を考え続けなければいけません。

今回の例は開発エンジニアの目線で書きましたが、別に「マーケティングツールを使って条件に合致する顧客だけにLINEを送りたい」とか「Zapierを使って採用業務を効率化したい」といったケースを考えると、エンジニア以外の職種にもこうした「コンピュータに対するデザイン」に関する選択は求められます。特に現代では、「人間ではなくコンピュータにどう価値ある仕事をさせるか？」が誰にとっても自分の成果の多寡を決める重要なファクターになっています。

こうしたSaaSの普及によって、一部の職場の働き方は大きく変わりました。その反面、「人間ではなくコンピュータにどう価値ある仕事をさせるか？」ということが個人や会社が生み出す成果を大きく分けるようになってきています。

エンジニアが仕事上で「細かいこと」を気にしているように見えるのは、コンピュータという存在が「細かいこと」まで決めて命令してあげないとちゃんと動いてくれないからです。人間からすると「細かすぎ」に見えるかもしれませんが、実はデジタル社会で広く求められるある種の「コンピュータフレンドリー」な態度といえるかもしれません。