PONOS Advent Calendar 2022の6日目の記事です。
昨日は@honeniqさんでした。
はじめに
プログラマとして、エンジニアとしてお仕事を続けさせていただく中で、振り返ってみれば時代とともに使用する言語やフレームワークなども変化してきましたし、開発手法というのも色々なものが提唱されてきたと思います。その一方で、その根底にある "我々が向き合っている問題" という本質にある部分は何も変わっていないとも感じています。そこで今回は その点について、私自身の考えをまとめてみたいと考えました。
本題
不確実性というキーワードは、例えば エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング~ を初めとして様々な書籍で言及されています。その他にも色々な記事で様々な方向からの解釈もみられます。ここでは、そうした情報も踏まえつつ、私自身の考えとして今回書きたい部分にフォーカスさせていただきます。
最終的には上記の書籍や他の記事など、様々な方の観点を見た上で、ご自身の解釈として落とし込んでいただくのがよいのではないかと思います。
私たちに求められるものとは
私が考える答えを書くと、要望をシステムで実現することであり、その全工程で必要となるスキルです。
以上。。。。では面白くないので、なぜそうなのか？ということを書きます。
私たちの仕事
ここでいう "スキル" というのは、仕事を円滑に行うための技術と定義できると思います。では "仕事" とは、どう定義すればよいのでしょうか？
物理学においての定義をWikipediaから抜粋すると、"物体に加わる力ベクトルと、物体の変位ベクトルの内積によって定義される物理量である。" であり、"エネルギーを定義する物理量" とされています。私は現実世界における我々の仕事も、これらとあまり相違ないのではないかと捉えています。つまり、"何かの状態を、別の何かの状態に変化させること" が "仕事" ではないかということです。
そうであるならば、"私たちの仕事は何か？" という問いは、"私たちは何を何に変えているのか？" と言い換えることができますし、逆説的にいえば "私たちがいなければ、何が何に変わらないのか" とも問えます。
その問いに対して、エンジニアという仕事にフォーカスした視点で見てみると、様々な表現ができると思いますが、例えば以下のような答えが適当ではないでしょうか。
- 企画（願望、要望）をシステムに変える
当たり前のことを言ってますね（笑）。
私たちのスキル
ここで行われる仕事、つまり "もたらされる変化" はどのようなものかというと、曖昧なものが具体的に実現される ということです。
エンジニア（プログラマをベースとした）というと、プログラミング言語を操るスキルを持った人 というイメージがまずあると思います。しかし、そうした一般的なイメージとは反して、実際にプログラマーをされている方々は、決してそれが全てではないという体感を少なからずお持ちなのではないでしょうか？
それはまさにその通りで、"スキル" とは、仕事を円滑に行うための技術 であり、"我々の仕事"は、企画（願望、要望）をシステムに変える事 であるのであれば、技術的なスキルは片方の側面でしかないと考えることができます。
これは精神論、趣味趣向の話ではなく、論理的に考えて、そうあることが妥当だと言えないでしょうか？
不確実性とは何か
では、私たちエンジニアに求められるものが 要望をシステムで実現する全工程で必要となるスキル といってみても、それは包括的な視点であり、まだ視界はぼやけた状態です。また、現実の仕事はロール（役割、役職）分担が行われますので、人によって何に注力するべきかも変わります。しかしながら、仕事の目的が同一であれば、ロールがなんであれ 中心の関心ごと というものがあるはずです。
それを考えるためには、私たちの仕事によってもたらされる変化、つまり "曖昧なものが具体的に実現される" という過程で起こっている "変化" は何か？ と問うことだと思います。
それは 不確実性の減少 です。そこで次に、不確実性というものを少し掘り下げたいと思います。
リスクとは
"不確実性" は "リスク" と言い換えられる場合があります。
これらは厳密には異なると解釈することもできますが、その話は横においておいくとして、ここではイコールで語られることもあるため、そこに沿ってリスクの話に触れておきます。
言葉としてのリスクは、"危険" と訳せますから、 "リスクという言葉はマイナスの結果、リターンとはプラスの結果" というイメージを持たれている事がありますが、この文脈ではそうではありませんし、そう捉えるべきではないと思います。
例えば、手元に1000万円あり、全額で何かの株を買ったとします。一年後にそれが100%の確率で倍の2000万円になるとします。
もちろんリスクは全くありません。結果はプラスですし、その結果は確実です。
例えば、手元に1000万円あり、全額で何かの株を買ったとします。一年後にそれが100%の確率で0円の価値になるとします。
この結果はマイナスですが、リスクは全くありません。なぜならもたらされる結果が確実に0ということが決まっており、まったく不確実ではないからです。わかっているなら（確実）買わなければいいだけのことです。全く予定通りとも言えますし、ある意味では危険ではないと言えます。
一方で、50%の確率で倍の2000万円になるけど、50%の確率で0円になる場合はどうでしょうか？
このケースにおいてリスクは最大化されます。なぜなら "最もリターンが不確実だから" です。
つまり、リスクとは振れ幅の大きさ（どれくらい不確実なのか） ということであり、この 振れ幅を減少させることが、私たちが行う仕事の中心の関心ごと だと考える事ができます。
様々な不確実性
ここまでの話だけだとなんだかモヤッとしませんでしょうか？私はします（笑）
私がモヤっとするポイントは、「不確実性って、何についての不確実性のことをいってるんですかね？」 という点です。
レイヤーごとの不確実性
実際に、仕事は様々な不確実性に向き合っていると思います。それは視点を置くレイヤーによって変わります。
- 市場変化という不確実性
- 工数の不確実性
- 仕様の不確実性
- 技術の不確実性
角度ごとの不確実性
具現化のための不確実性の減少という本筋と、リスクヘッジという意味での不確実性の対処を語る場合と、大きく２本から語ることも出来るように思います。
- リスクとしての不確実性=いつ、何が、どうなるかわからない
- 曖昧さとしての不確実性=いつ、何を、どうすればいいかわからない
厄介なことにこれらの要素は相互に影響を与え合っており、どこから見てもプロダクトという同じ全体像を見ています。
そのため、単純に曖昧さを具体化していくという、「不確実性の減少」のみでも語れない部分があると思います。
不確実性と向き合う４つの手段
包括的に我々がやっていることを改めて考えてみると、実は大きく４つに分けられるのではないかと思います。
- 不確実性（リスクや曖昧さ）を減少させる
- 不確実性（リスクや曖昧さ）を分散する
- 不確実性（リスクや曖昧さ）を回避する
- 不確実性（リスクや曖昧さ）を受容する
不確実性（リスクや曖昧さ）を減少させる
詳しくは書籍などを参考にしていただくとして、不確実性が下がるという事が何によってもたらされるかというと、それは情報です。
- AとBを検証することで、どちらが良いのかをはっきりさせる
- 要求をつめていくことで、何がやりたいのかをはっきりさせる
- 市場動向の情報を得る事で、将来どうなるのかの推測精度を上げる
特にプロダクトを具現化するという角度から見た場合、これが私たちの仕事の主軸ではないかと思います。
不確実性（リスクや曖昧さ）を分散する
特にリスクという角度で見た場合、この選択肢を取ることが有効なケースがあります。
- サーバが落ちるかもしれないので、複数台で構成する
不確実性（リスクや曖昧さ）を回避する
例えば、プログラミングという視点から見た場合、次のようなものは回避といえるでしょう。
- YAGNI
システム設計という視点で見るならば、次のようなものがあるかもしれません。
- まだ実績のないサービスなので利用を避ける
不確実性（リスクや曖昧さ）を受け入れる
エンジニアリングで言えば、例えば以下のようなものが該当すると思います。
- アジャイル開発。どうなるかわからないなら、変化することを受け入れる。
- 正常動作が99.99999999%であるため、費用対効果を考えた上で良しとする。
まとめ
言い訳になってしまいますが、できるだけ体系的にまとめたいと思いつつ、書ききれない部分があったなと思います。とはいえ最後に言いたいことをまとめるとすれば、それは比較的簡潔です。
私たちが習得し、活用しているスキルは、プログラミング言語のような技術的なスキルを中心に、非常に多岐に渡りますが、それらは全て手段と言えます。一方で、より原点にある目的に向かって構造を遡っていけば、そこにある要素は限られてきます。
"我々の仕事" を実行しようとした時、目の前の手段から見つめてしまうと、その複雑さゆえに "問題が複雑すぎる" と見えてしまうことがあります。しかし、対峙したものを不確実性であると見た時、そこに対しどのような手段がとり得るのか、減少か、回避か、分散か、受容か、減少であるならばどのような情報を生み出せばよいのか、時にはそうした基本的な視点から見つめ直してみると、混乱せず対処していくことができる事もあると考えています。
今回は以上です。
明日は@e73ryoさんです。