見出し画像

僕らはエンジニア(技術)を理解できるのか?-分かる程に深まる境界線-技術マネージャーのあなたへ

株式会社リゾルバ代表の佐伯(@yonyonsaeki)です。

技術とそれにコミットするエンジニアへのマネージャとしての向き合い方
について自戒とリスペクトを込めて反省文書きます。

技術に限らずとも専門性あるタスクに従事する方に、動いてもらう側のあなたへ。

■はじめに-僕らは知った気になっている-

以下のnoteでも触れましたが、
昨今、多くの製品化された利用型の技術が存在し、また抽象化された技術用語によりそれを語ることのハードルは昨今とても下がっています。

ITに関する議論でしばしば足を取られていた、
技術に関するHowの枝葉議論でなく、
ツールやフレームワークを用いる前提で素早く
目的志向でものづくりに取り組める・会話できる、というのは我々一ビジネスマンであるエンジニアにとっても喜ばしいことだと感じる方は多いのではないでしょうか?

(2020/3/16 寄稿)
"セールスエンジニア"いりませんか?#SaaSLovers

(抜粋)
ユーザ企業様含めBizサイドの方のITリテラシは非常に高くなったと思います。
IoTやAIといった技術のユースケースも言語化され実績も出来、身近なところではAPIといった概念によって、サービス間を連携する発想や会話も容易になってきました。(随分楽をできるようになりました)

仕事柄、年間数十件のユーザ企業やSIerの現場に顔を出しています。

一見、提供サイドである技術側と利用側の距離は縮まったように見えるのですが、この利用側が"知っている、分かっている"という認識
様々な場面においてむしろ相互理解を妨げているような場面に遭遇します。


何より、僕自身キャリアの変遷の結果、まだまだ若手に負けたくない気持ちはあるものの、モノづくり最前線に出て手を動かすことはほぼ無くなりました。

特定の技術にコミットし、現在進行系で臨床に取り組み、成長しようとしている周囲のエンジニア仲間にとって、僕は決して同じレベルで話の通じる相手ではないのだ、
僕という"エンジニア出身マネージャー"は、現役エンジニアにとって気を遣い、伝わるように話さないといけない相手なんだ、
という認識を持つきっかけがありましたので、書き留めておきます。

※前提として、僕は少なくとも自分がシステムエンジニア出身であるというアイデンティティを持っています。自負のある専門分野もあります。だからこそなのか、陥ったお話です。

■ケース:ちょっと難しそうな話もついていけた話

(※技術の正しい説明をするものではないのでDetail無視してください)

とある日のこと
「マイクロサービスで作るならQuarkus使ってみたい」
支援先の若手エンジニアが今後のサービス開発でチャレンジ/活用してみたい技術をチャットで呟きました。

この手の会話はさほど真面目に調査、検討したというより
好奇心的なニュアンスがあり、どちらかというと技術談義(雑談)に華を咲かせたいぐらいのイメージに見えました。

まずは、知らなかったのでググります。当時1年前ぐらいの記事が出てきて、自分の情報感度の低さを疑います。

一旦、読むのは冒頭のここだけにしましょう。専門外の方も読んでみてください。

Red Hatは,GraalVMとOpenJDK HotSpot用に開発されたKubernetesネイティブなJavaフレームワークのQuarkusをリリースした。反応型(reactive)と命令型(imperative)を統合したプログラミングモデルの提供により,JavaをKubernetesとサーバレス環境のリーディングプラットフォームとすることを目指す。
(抜粋: https://www.infoq.com/jp/news/2019/05/redhat-release-quarkus/)


非エンジニアの方でも部分的にキーワードは聞いたことのある用語もあるかと思いますが、つまるところ何だろか?については少し理解が難しい感じがします。
恐らくその"分からない前提"に立てれば、よく話を聞き、相手の言葉で咀嚼し、関心事や今の仕事への課題感など、エンジニアの彼のマネジメントとして価値ある雑談になるでしょう。


僕は、なんとなくこう変換しました。

Quarksは反応型も命令型も扱えるライブラリを統合しているから、
異なる開発パラダイム(扱う技術が違う)のサービスが疎結合にアプリケーションを構成することがあるマイクロサービスアーキテクチャでの開発にも適合しやすいし、アプリケーション実行環境のコンテナ及びオーケストレーションのデファクトOSSであるKubernetesを活用してのデプロイやスケーリングを想定して最適化(軽量化)されてるから、今主流になってるモダンなアプリケーションサービス開発ならもってこいなJavaフレームワークと言いたいんじゃないかな。多分そんな感じの記事なんじゃないかな。

色々勝手に付け加えてますけど、雰囲気です。横文字乱発でフワっフワ。
この書きっぷりで分かって貰えると思いますが、この時点で僕は

"とても分かった気になって気持ちが良い状態"


だったりします。

■相対的な言葉が作られ、理解した気にさせられる

自分なりに解釈できた&満足した理由として
ある程度専門的な前提知識が入っている、という自負があると思います。

・命令型って多分手続き型(昔ながら)でしょう、リアクティブと対比させてる
・リアクティブ周辺用語、Blocパターン,SPA,flutterとか
・Stream的なものをListenして受け取ってUI制御するみたいなやつ
・マイクロサービス(疎結合に統合),サーバレス(Functionで構成),Kubernetes(拡張可能なコンテナコントロール)

(※何度も言いますが間違ってても無視してください)

様々な前提知識やその特徴を抑えていることで、自分なりの解釈ができました。

が、実は僕自身が手を動かした訳ではなく、用語の理解は甘いものです。
一個一個の単語の意味するところはある程度、日々の中で覚える必要があるものの、


サーバーサイドやバックエンドに対比してフロントエンドを理解し
手続き型に対比してリアクティブなプログラミングモデルを理解し
仮想化の一種としてコンテナを、モノリシックと対比してマイクロサービスを、従来の課題に対して新しいものの良さを...

と、あくまで
相対的な意味、ザクッと語る上で十分なレベルでしか用語を捉えておらず、
実践者の意識もプライドもありませんでした。
(それ自体は悪いことではないはずですがそこで止まってしまいました。)

名前のついた領域はコモディティ化した証拠ともいいます。

当たり前ですが、
整理してマップされた知識というのは、相互理解の出発点であって、
コミュニケーションのゴールではない。
深めるプロセスが必要です。


なのに、本来、マネージャとしてメンバーとの相互理解の入り口に立つために得たはずの基本的な知識を、
一種の専門性へのコンプレックスからか、何故か誇示に使ってしまったようです。


■主体者に敬意を払い、積極的な相互理解と支援を


"自分はツボを抑えて大枠を理解している"という感覚は
コンサルワークをうまくこなしていく中で生成されることが多い
麻薬のようなものです。

そして所謂"使う側"の人間として負の影響を与えます

例えば

・リスペクトの欠如
・歩み寄り意識の喪失
・適切な権限移譲の阻害

近年ではSaaS Adminの方や、ニッチシステムの社内SEさん、現場技術に経験のないPMとエンジニア、ディレクターとデザイナ、
経理や総務さんのイレギュラー業務担当者もそうかもしれない、


社内で専門性のあるタスクを担当していたとしても
この無理解とも異なる認識ギャップから、孤独な思いや報われない思いをしている方は多い気がします。

立場も取り組む時間も知識もスキルも違う以上
"複雑なものを複雑なまま理解できない"
つまり本質的に理解が難しいことを受け入れて歩み寄る必要が出てきます。


落ち着いて振り返ってみると、

一体どんな思いや経緯からこの技術に興味がいったのか?
なにか課題意識があって希望を感じたのか?
アイディアがあるのか?
実際評価するにはどんなステップが必要なのか?
キャリアへの危機感からなにか新しいものを習得したい、というメッセージだったのではないか?

若手エンジニアからのメッセージ/シグナルだったかも知れないし
もっと会話を深めるきっかけに使えたはず。

なのに、勝手に自分は同じレベルで話題に入れたと思って満足。

さいごに - 惜しいぞ!自分

最後に、ポジティブになるのが僕の特徴です。
なんとか解釈、会話できるのは日々のキャッチアップと努力の賜物でもあるので、相互理解のスタートに立てるのは大事。

「僕は分からない、だから教えて」型のコミュニケーションも姿勢は良いが度が過ぎると問題があるのも事実。

「専門外のことだけど、トレンドやポイントはアンテナ高くして拾えてるし
大体地頭で理解できたぜ。手を動かすのは任せるよ。」


うっかりそのラインで止まってしまわぬよう、主体者へのリスペクトと
相互理解の入り口に必要な基礎知識の継続的な習得、そして対話、を
マネジメントとして心がけていきたいと思います。


反省文終わり。

----------------------------------------
Twitter: https://twitter.com/yonyonsaeki
Facebook: https://www.facebook.com/yousuke.saeki

もし記事がお役に立ちましたらサポートを頂けると幸いです。 以下のように使わせて頂きます。 家事/育児系記事→小学校のサークル活動等地域の活動やボランティア活動への寄付へ ビジネスナレッジ系記事→執筆活動のリサーチ費用や、協力者様への謝礼に 自己紹介やエッセイ→自分へのご褒美