この記事はtechtektアドベントカレンダー2021の21日目の記事です🎄
to 同僚たち
エンジニアとして生きていくための裏技術について書くといったな。
あれは嘘だ（1度やってみたかった）
※ 経験が少ないエンジニアでも、いい感じに社会で生きていける処世術みたいなのを書こうかとおもったのですが「結局は運が大事」（人の縁など含む）という、取り止めもない結論になったので、変えることにしました m(_ _)m
# はじめに
こんにちは。
テクノロジー本部 エンジニアリング統括部 サービス開発部でエンジニアをしている kanekoです。
この記事では、この本の内容をかい摘みながら、最近私が思っている持論をつらつらと書いていきたいと思います。
※ この記事は私見が多分に含まれるので、そういったのが苦手な方は遠慮なくブラウザバックでお願いします（笑）
では早速
# 不確実性に向き合う思考
まず、タイトルが面白いと感じました。
今まで読んできたエンジニアリングなどに関する本や記事は、ほとんどが「どう確実にしていくか」を書いている本がほとんどでした。
そうではなく、この本では「不確実性に向き合う」ことを述べています。
不確実性を避けたり、それから逃げるのではなく「立ち向かう」にはどうすれば良いか。
エンジニアリングしていく上で不確実性は避けられないものとして、それとどう向き合うかについて書かれています。
# そもそもエンジニアリング（工学）とは
そもそもエンジニアリング（工学）とはどうゆう意味でしょう。
この本の中では工学の定義について、以下のように書かれています。
工学とは数学と自然科学を基礎とし、ときには自分社会科学の知見を用いて、公共の安全、健康、福祉のために有用な事物や快適な環境を構築することを目的とする学問である。
上記を受けて、この本のなかでは「構築すること = 実現すること」であるとし、ソフトウェアにおける「実現」とエンジニアリングについて以下のように述べていきます。
ソフトウェアは誰かの曖昧な要求からスタートし、それが具体的で明確な何かに変わっていく過程が実現であり、その過程の全てがエンジニアリングという行為
ということになります。
# プロジェクトマネジメントの現場における不確実性
よく、プロジェクトマネジメントでは「不確実性コーン」という図が使われます。
https://blogs.itmedia.co.jp/hideshibamoto/2013/01/post-7a0e.html より引用
工数を見積もるときに良く使う図で、プロジェクトのフェーズによっては納期が想定の最大で4倍から0.25倍までブレることを意味しています。
そして、プロダクトの定義や仕様が具体的になっていくと、ブレ幅が少なることが示されています。
上記の図から、プロダクトはフェーズが進んでいくにつれて不確実性が下がり、具体性が上がっていることがわかるかと思います。
（上記では横軸がTimeになっていますがあしからず）
上記のことから、エンジニアリングの仕事は普段から「不確実性」に向き合う仕事であることがわかるかと思います。
# シャノンの定義：エントロピーと情報の関係
そして、クロード・シャノンという人がこの「不確実性」の量をエントロピーと呼びました。
以下の式で表すことができます。
https://study-z.net/100120916/4 より引用
（熱力学で使用されてた言葉が統計力学や情報理論でも応用して使われている。それぞれ意味合いが微妙に異なるので注意）
情報理論におけるエントロピーを簡単に説明すると、
例えばコインを投げて表が出る確率は1/2（50%）であるため、「コインを投げたら表が出た」という情報の情報量は-log2（1/2）で1ビットとなる。
コイントスの全事象は「表が出る」「裏が出る」の2つで、生起確率はどちらも1/2、情報量は1ビットである。よって、全事象の平均情報量も（1+1）/2で1ビットであり、これがコイントスの情報エントロピーである。
一方、必ず表しか出ないよう細工したコインを投げる場合、表が出る確率は100%、裏が出る確率は0%で、どちらも情報量は0ビットである。エントロピーは（0+0）/2で0ビットとなり、通常のコイントスに比べ事象の不確かさが失われていることがわかる。
出典 e-words.jp
と上記のような説明になります。
（本筋ではないので、詳しく知りたい方は「エントロピー」や「シャノン」で調べてみてください）
実際の現場では、上記のコイントスの情報エントロピーのように1ビットに収まることはありません。
様々なコンテキストがあり、そこから数多の選択肢を辿って決定が行われていることを考えると膨大な情報エントロピーを扱っていると考えられます。
少し話が逸れましたが、さきほどの不確実性コーンの図で言うと
・左にいくほどエントロピーが高く情報量が少なく
・右にいくほどエントロピーが低く情報量が多い
状態だと言えます。
# 情報を生み出すこと
上記のことを踏まえて、本では以下のように述べています。
「不確実性を下げること」はつまり、シャノンの定義に従えば、「情報を生み出すこと」に他なりません。
〜〜 中略 〜〜
エンジニアリングの本質が「不確実性の削減」であることに気づかずにいると、確実でない要求仕様にフラストレーションを抱え、確実でない実現手段にストレスを感じ、確実なものを確実な手段で提供したいというような決してあり得ない理想を思い描いて、苦しい思いをすることになってしまいます。
要求仕様はできる限り明確であるべきだとは思うので、上の引用は少し言い過ぎな部分もあるかもしれません。
しかし、同時に最初から明確な要求仕様は存在し得ないのも確かだと思います。
（最初からソフトウェアにできるほど明確ならエンジニアの仕事も存在しなくなります）
プロダクトを定義するなどの上流工程にいる人は、できる限り情報を明確な状態にして発注する。
その要求仕様を受けた人は、明確でない部分を具体的に落とし込むために双方向でコミュニケーションをとっていく。
お互いの歩み寄りが大切だといえるかもしれません。
# V字モデル抽象度と具体性
（こっから完全に私の私見です）
開発フェーズとテストフェーズの対応を見るときなどに、開発におけるV字モデルが度々用いられます。
https://www.itmedia.co.jp/im/articles/1111/07/news155.html より引用
おおよそですが、サービス開発部で言うと、上から「企画」「デザイナー」「システムエンジニア」の順番で降りてきてエントロピーを消化していると言えると思います。
そして、それぞれポジションの差があれど、「情報を具体的に落とし込む」という意味ではみんなが同じ仕事をしているのでは？
と言うのが私の最近の持論です。
そして、利用とサポートや解析によって得られたユーザーの意見や行動分析などが新たなエントロピーを生み出していき、次の構築が始まるのかもしれません。
# 様々な情報の粒度
企画の人の話しや言葉を聞いていると「情報の粒度」と言う言葉を使う時があります。
「まだ情報の粒度が粗い」「情報の粒度をもっと細かくしよう」
など、上記のことを踏まえなくても自然とエントロピーや情報に近い言葉で話すことがあります。
最初は何bitもある情報をそれぞれの粒度（上記のbitにならうなら情報の単位に相当するのかも）それぞれのポジションで0bitに近づけていくのがエンジニアリングという仕事なのかもしれません。
様々な粒度の情報があって、それぞれの粒度で情報に落とし込むのが得意なひとがいる。
大きい粒度を担当できる人。小さな粒度を担当できる人。
幅広く得意な粒度がある人。
一定の粒度しか消化できないけど、物凄く早く実行する人。
鈴と、小鳥と、それから私、
みんなちがって、みんないい。（かねこ）
と言うことで、最後はみすゞさんになってしまいましたが、そんな視点で開発に携われたらと思う今日この頃でした⭐️
金子 広大 Kodai Kaneko
エンジニアリング統括部 サービス開発部 第2グループ エンジニア
前職は中規模の人材紹介会社。toC向けのアプリケーション開発でiOSとAndroid両方のアプリで企画や開発、運用などに携わる。2019年12月にパーソルキャリアに入社し、マイポテの開発に携わる。
※2021年12月現在の情報です。
