ポエム

事業について完全に理解したエンジニアの記事

こんにちは。Tamappeです。

本日は今週ツイッターでバズっていた話題について触れたいと思います。最近のツイッターは結構なんでもバズっている印象です。

トピックスはこちらになります。

「事業」とは

僕は最初「事業のわかる」の事業は会計的な意味合いかと思っていました。先に行っておきますと、会計のことを理解するためには、貸借対照表(バランスシート、BS)と村営計算書(プロフィットロスステートメント、PL)とキャッシュフロー計算書(CF)が読めることが前提になってきます。レベル感で言えば、簿記2級と1級の一部の知識が必要になります。(CFの作り方や意味合いは1級でしか触れられないため。)

僕の意見は、エンジニアもやっぱり簿記2級ぐらいの知識が合ったほうがいいかなと思いますが、これは話しが脱線します。

でもどうやらそういった会計的な話しではなさそうです。どちらかというと組織的な話しみたいですね。

経験則と照らし合わせると、おそらく事業を進めるに当たって4種類のコミット方法があります。

  1. 技術特化で成果を出す
  2. チーム内の改善、UX改善の提案・実装にコミットする
  3. 他部署を巻きこみプロジェクトを推進できる
  4. 経営ビジョンを加味した技術選定、組織編成、戦略決定ができる

そのあとの文章で具体的に何が言いたいのか把握できなかったのですが、テックリード以外の人はこの1から4を順番に担っていくのだとふんわりと書いていました。

エンジニアにはテックリードが求められている?

ワタシ的には普通のエンジニアの役割で考えると、おそらく1と2が担当エリアかなと感じました。他部署を巻き込みプロジェクトを推進できるのはプロマネが担当するイメージで、これを1エンジニアが担当するには荷が重い気がします。

それで4番がテックリードの主な役割になる感じだと思います。

書き手が指す「経営者にとっての事業がわかるエンジニア」とは4を指すエンジニアだそうです。

じゃあ、経営層が「事業をわかってくれる」と見做すのはどこかといえば、ほぼ間違いなく4です。

つまり、この記事で取り上げている経営者の指す「事業がわかるエンジニア」になるためには、エンジニアは皆テックリード並の判断力を持って欲しいということが分かりました。

ということで経営者に評価されたければ、4番まで日々試行錯誤して事業に取り組まなければ評価されにくいだろうということが書かれているように思います。

そこまではある程度、理解できてなるほどなぁと思いつつ、あとは記事の書き手の方の個人的意見が書かれています。ツイッターでは多分、前半の1段落をさらっと読んでバズったのかなと思います。

個人的見解の部分を読んでも内容が頭に入らなかったので。

で、この記事って要はエンジニアは皆テックリード並の判断センスを持って仕事をしてくれって意味合いの話しだったのか結論が全然読めなかったです。

一般的なエンジニアの責務について

ただ、僕の見てきたエンジニアの多くは1と2で精一杯ですね。他部署を巻き込んでいると工数がメチャクチャ膨らみます。また、他部署の進捗も把握していないといけないので現場のエンジニアはイライラするんじゃないかな。

あんまりそういうハイレベルな判断センスを問われる現場では働きたくないなという印象を受けました。ということで、テックリードを目指すエンジニアにとってはメチャクチャ鍛えられる現場なんだろうなと思いながら記事を書くのを終わります。

事業の分かるエンジニアは何をするか

それでは、エンジニアが事業が分かるようになるとどうするのだろうか。つまり、

  1. 技術特化で成果を出す
  2. チーム内の改善、UX改善の提案・実装にコミットする
  3. 他部署を巻きこみプロジェクトを推進できる
  4. 経営ビジョンを加味した技術選定、組織編成、戦略決定ができる

この4つの要素が全て分かるとどうなるか問題である。こんなにフルスタックになるともはやエンジニアはその組織を抜けて自分で「事業」を始めちゃう気がします。なんてったって、自分で全てのリスクをコントロールできるからです。

エンジニアリングのわかる経営者が全然いない


よく会社のエンジニアリングが必要な現場で問題になっていることがある。私が俗にいうエンジニアといえる立場の方々にヒアリングする機会が増えたことで、とあるセリフを頻繁に耳にするようになりました。

「エンジニアリングの話ができる経営者がいないんですよね。本当に現場は困りますよ」です。

これは僕がエンジニアリングの話をできるとかそういうことを言いたいのではなくて、各社のエンジニア層の切実な想いであり1つや2つの組織で聞いた発言ではなく、あらゆる組織で耳にする強烈な痛みであると言いたいんです。

本当に、文字通り、全ての組織でこの発言を聞きました。


 

ちなみに、今僕が働いている会社では上記の事が起こっていないのでそこは安心してます。

それでは、バイバイ。

ABOUT ME
tamappe
都内で働くiOSアプリエンジニアのTamappeです。 当ブログではモバイルアプリの開発手法について紹介しています。メインはiOS、サブでFlutter, Android も対応できます。 執筆・講演のご相談は tamapppe@gmail.com までお問い合わせください。