提案力という技術力について
こんにちは。Team DELTA代表の丹です。
直近で、複数の事業部の方（非エンジニア）から、「エンジニアの観点から話してほしい」という依頼を受けることがいくつかあったのですが、毎回同じことを話しているなと感じたので一度ドキュメント化しておこうと思ったので、せっかくなのでnoteに書いてみようと思います。
「技術的なこと」とは？
一般に、私が何かの場に呼ばれる場合には、「技術的なことはわからないので」「エンジニアの観点から」何か話してほしいということが多いです。
まあ事実私はエンジニアではあるのでそれは正しいのですが、私も結局のところただのプログラミングとアーキテクトができるビジネスマンでしかない以上、何か特殊な観点を持っているとかいうことは特にないわけです。
もちろん、関数型プログラミングやNoSQL、クラウドネイティブなアーキテクチャについては世間的な平均よりは詳しいですが、そういったお呼ばれをする場合に「NoSQLデータベースのキー設計について相談したい」というアジェンダがあることはほぼありません。
多くの場合、「技術的なことはわからないので」という枕詞から相談が始まりますが、相談の内訳としては聞いてみれば別に「技術的な」ものではない。
では何的なものなのでしょうか？
集合知の活用
聞いてみると、ほとんどの場合「技術的なこと」自体ではなく、「ものづくりに対してのBizDevの関わり方」、ひいては「エンジニアとのコミュニケーション」がアジェンダであることが多いと感じます。
しかし、別にものづくりというものはソフトウェアエンジニアリングという分野ができる前からあったものですし、「作り手」と「発注者」という関係でいればコミュニケーションなんて特に悩む必要はないのではないかという向きもあります。
作っているものがお茶碗だった場合は、陶芸職人と普通に対話して、「もうちょっと表面をざらざらにしたい」と言えばいいだけの話です。
そこに対して職人は職人で、「材質の問題でそれはできない。～～にすればできる」と返せばいいだけ。
それがなぜ（ソフトウェア）エンジニアに対しては難しい（と感じられてしまう）のか？
それはソフトウェアが十分に複雑かつブラックボックスな存在だからでしょう。
発注者と職人がパッと共有できる語彙や見えているものが十分に異なってしまうようになった時点で、従来のものづくりのようなコミュニケーションをとることは困難になります。
これは言い換えれば、発注者と職人が持っている知識が違うということです。
この知識というのは、別に勉強してきたものが異なるというわけではなく、発注者自身がエンジニアとしての勉強を十分にしてきたとしても、そのプロジェクトにおける「知っていること」が違うということをさします。
職人も、発注者も知っていることが異なる。
ソフトウェアエンジニアリング及びその周辺の現場では、この「集合知」をどのように活用していくかが重要になってくるわけです。
集合知を活用するためにはその間を埋めるコミュニケーションが重要になってくる。
そういった問題意識から出発している以上、ではお互いに見えていないものとは何なのか？そして、もしお互いに見えているものがあるとしたら、それは何か？をもう少し深掘りしていく必要が出てきます。
スケボーを作る
その前に、集合知は何のために必要なのか？ということを考えてみます。
予算が十分にあれば集合知は不要です。ビジネスサイドが思い描いたフルサイズの要件を、フルサイズの工数でゆっくり実現すればいいからです。
ただし実際には、私たちスタートアップには予算がそこまでありません。スピード感も重要です。そんな中では、「車のビジョンからスケボーを作る」ことが必要になってきます。
フルサイズの要求としては車を作りたい。というビジョンがあったところで、技術的にはそれを作るのに大量の予算が必要だ、ということが見えたとします。
そこからは、予算にミートさせるためには、その技術的な制約、すなわち安全性の確保が大変だとか、軽量化が大変だとかそういったものを一つ一つクリアする「技術サイドのアプローチ」も必要でしょう。
とともに、逆に「ドアや椅子は実際には不要」といったかたちでの「要件サイドのアプローチ」を行うこともできるでしょう。
これらはそれぞれでパラレルに行うこともできるのですが、実際には「どういった車を作れば顧客の目的を充足できるか」という要件サイドの知識と、「どういった車であればどれぐらい大変か」という技術サイドの知識を行ったり来たりする必要があります。
その目的と手段の往還によってはじめて「車のビジョンからスケボーを作る」という営みが可能になります。
ソフトウェア開発の現場においては、このような目的と手段の往還という動きを行うためには、ビジネスサイドと技術サイドの集合知を活用する必要があるが、複雑性が十分にあるためにそれが他産業に比べて難しいということがここからいえるかと思います。
ヴィジオネール（幻視者）
目的と手段と簡単に分割してしまいましたが、現実にはそう簡単に両者を分けることはできません。
私は建築の用語からヴィジオネール（幻視者）と呼んでいますが、実際に今までにないビジネスやプロダクトを思い付くのは、その場に無いもののまぼろしを見ることができる人です。
で、そのまぼろしがうまいこと抽象化された何かなら別にいいのですが、実際には思い付く「ビジョン」とはそれ自体が完成形の姿をまとったものであって、デジタルネイティブな私たちにとってはそれはもう完成したアプリケーションのUIや体験のイメージになります。
例えば、「食べ物を配達してくれるアプリ」という抽象化されたビジョンを最初から持っている人は稀で、「メニューを選んで、配達ボタンを押すと自動的に従業員に通知が飛んで、決済が走って云々、、、」という、より具体的なアプリケーションのビジョンが最初は浮かぶものではないかと思います。
ものづくりの現場において必要な作業は、これを一度抽象化し、どこまでが具体的に必要なのか？を切り分けていくというものになりますが、とにかく最初のオーダーとしては逆に非常に具体的なものになることが多いのではと思います。
そうなったときに、ヴィジオネール本人は専門知として、「どこが捨象可能な変数なのか」という知識すら持っていないケースが多いです。つまり、例えばそもそもwebアプリなのかネイティブアプリなのか、が変数足りえるのかすらわからず、思い付きもしない。
理想的には、そのビジョンに対して、専門知を持ったパートナーが対話を重ねていくことで、何が今回のビジョンにとってのスケボーなのか、を解きほぐしていく必要があるわけです。
理学と工学
対話の余地について考えるにあたって、最近私が重要だと思っている概念として「理学と工学」というものがあります。
厳密な意味での理学・工学ではないのですが、イメージとしては「一般的な動作原理の理解」と「その現場での運用の知識」を分けようという趣旨のアイデアです。
例えば、外部キー制約をテーブルにつけると、参照先のテーブルのプライマリキーに無い値をその列に入れることができなくなる、というのは理学の領域です。
それに対して、うちでは購買テーブルに顧客IDを入れる際、顧客テーブルの外部キー制約を効かせているというのは工学の領域です。
語彙と文法と言い換えてもいいかと思います。
所謂「技術力」といった場合に参照されるのは主に前者の理解・知識になりますが、後者については技術力というよりは設計力とか、あるいは単にドメイン知識と言われます。
ソフトウェア開発においては、前者の理解については非エンジニアがエンジニアを超えることはできませんし非効率です。
ただし、後者については単に運用や設計思想を知っているかどうかですし、別にコンピュータ工学の知識が無いと理解できない領域では特にありません。
また、後者は特に（工学と呼んでいるだけあって）合目的性つまりビジネス要件の達成に照らして評価可能な領域です。
したがって、この領域については、言葉を変えればその気になればお互いが会話できる余地のあるDMZ（非武装地帯）といえます。
用心棒の先生
以前CTOの採用について相談された際に、「用心棒の先生みたいにしてしまうと良くないですよね」ということをアドバイスしたことがあります。
つまり、「～～さんがそうおっしゃるなら、そうなんですね」というように、エンジニアからの主張を無批判に受け入れてしまう姿勢は良くないということです。
これは一見するとエンジニアをリスペクトしているようでいて、対話を放棄しているためにアンヘルシーなコミュニケーションになっています。
このコミュニケーションが行われてしまった時点で、集合知は活用されず、エンジニアは独善的な行動をある種許されてしまうことになり、ビジネスサイドはうまくエンジニアにやってほしいことが伝わらない・またはやりたいことは実現できるがコストが大きく動きが遅くなってしまうということが発生します。
なぜなら、ある程度以上の複雑性を持ったデジタル・プロダクトにおいては、やりたいことを実現する手段は複数個存在し、本来であればそれぞれのメリット／デメリットを検討したうえで意思決定をするべきところ、目的たる「要件」についてはビジネスサイドがある程度握ってはいるものの、その手段についてはコミュニケーション不足のままエンジニアが閉じた考えで決めてしまうため、目的と手段の往還関係が成立しなくなるからです。
この図では、「車」とはヴィジオネールによって幻視されたビジョンでしかなく、解像度の高い「目的」とはまだいえませんが、対話が十分に行われないことによって集合知がワークせず、解像度の低いまま必要以上のコストが発生してしまっています。
説明責任
ではどうしたらよいのか。
最も重要なコミュニケーションは、先述の工学的領域において、理学的な技術力に裏打ちされた目的と手段の往還関係を成立させるようなコミュニケーションを行うということです。
そのためにビジネスサイドにおいて重要なのは、「技術的なことはわからないから」と引っ込むこと自体をやめる、ということだと思います。
逆にエンジニアあるいはCTOサイドとしてやるべきことは、「説明責任を果たす」ということだと思っています。
「用心棒の先生」は双方のコミュニケーションに問題のあるToxicな関係だと思っており、「素人は黙っとれ――」というコミュニケーションをとっているエンジニアサイドにも問題があります。
事業に主体的にコミットするよき技術者であれば、報酬を受け取っている以上は当然技術的な判断に対して好みや主義主張を超えてステークホルダーに対して説明する責任を負っています。
逆にビジネスサイドにおいては、それを引き出すための問いかけを、自らの持つポイント・オブ・ヴューから、集合知として投げかける必要があります。
例えば：
・それは既存の画面への機能追加という形で実現できないのか？
・例えば別のSaaSプロバイダーと組みあわせてもいいとしたら、もっと素早くリリースできないのか？
といったコミュニケーションは、（別に無知だと笑われたとしても）発することは可能なはずです。
それに対して、エンジニアは「何をバカなことを」と、（実際に思ったとしても）言わずに、誠実に「なぜそれができないのか」について説明する責任を持っています。
そういった、説明責任を果たせるエンジニアと、逃げずにきちんと要求をフェアに伝えることができるビジネスサイドが協調していく関係を築ければ、素早く必要な価値を顧客に届けられるようになるというのが、現時点での私の結論です。
なぜなら、先述した通り、工学という領域において手段と目的は往還できるはずだし、十分に複雑性を持つシステムにおいてはビジネスサイドだけしか持っていない要件についての知識と、技術サイドしか持っていない理学的な知識とをそれぞれぶつけ合う必要があるからです。
DELTAのエンジニアの提案力
翻って、DELTAのメンバーは、主に「CTO Booster」としての、事業会社のCTOを相手取った技術支援を行う立ち位置にあることが多いです。
私としては、DELTAのメンバーには「提案力」を技術力と並んで要求していきたいと思っています。
「提案力」を求めていくと、「営業をやらされるなら嫌だ」というふうに誤解されてしまうことも多いかと思います。
しかし、提案するという行為は、別に何かを売りつけてノルマを達成するためにするものだけではなく、ある程度以上の責任を持ったポジションに就くのであれば、当然に果たしていくべき「説明責任」をしっかりと根拠付けてステークホルダーに対して果たしていくということと全くの地続きになっています。
そういった意味で、もはやソフトウェアエンジニアにとって提案力とは当然に備えていくべきスキルであり、CTO BoosterをはじめとするDELTAのフィールドはそれをきちんと伸ばしていける環境だと自負しています。
We're Hiring!
DELTAは、このように経営と同じ目線で技術的な意思決定に参画できるフィールドです。
共感してくれる、挑戦したいと思ってくれるエンジニアとぜひ一緒に働きたいと思っています！
正社員（新卒・中途）、業務委託（副業・アルバイト・インターン）など、皆様のご希望にあわせた勤務形態、報酬をご用意できますので、ぜひ一度カジュアルにお話しできますと幸いです。
まずはカジュアル面談の申し込みフォームからご連絡ください。
この記事が気に入ったらサポートをしてみませんか？