怠慢プログラマーの備忘録

怠慢でナマケモノなプログラマーの備忘録です。

「事業がわかるエンジニア」を深堀りする

www.timakin.com

今ホットな当話題に関して、個人的にすごく抽象的で一見上記記事内で言う「経営層」と「エンジニア」のそれぞれの領域を曖昧にしてしまう内容にも見ることができる気がしたので、ちょっと書いておきます。

そしてこの記事も個人的なものなので、これに対する見解はそれぞれ異なっていいものだと思ってます。

「事業がわかる」エンジニアとは

記事内で、

技術特化で成果を出す

チーム内の改善、UX改善の提案・実装にコミットする

他部署を巻きこみプロジェクトを推進できる

経営ビジョンを加味した技術選定、組織編成、戦略決定ができる

とあります。その中で経営層が「事業がわかる」と評価する「経営ビジョンを加味した技術選定、組織編成、戦略決定ができる」に若干のミスリード?行きすぎる点があるように感じます。

なぜなら「経営ビジョンを加味した技術選定、組織編成、戦略決定ができる」と言う課題や最終的な意思決定を達成すべきなのはエンジニアやプログラマーではなく経営層であるからです。

「事業がわかるエンジニア」がみな「経営ビジョンを加味した技術選定、組織編成、戦略決定」をしてよいとするのであれば事態の収拾がつかないことになりかねません。

その「事業がわかるエンジニア」を善としてみながそれを目指し、遂行し始めたら組織構造のレイヤーにかかわらず皆が組織編成に口を出し、戦略決定事項に異議を発言し、最終的には「この会社はエンジニアの意見を尊重してくれない」などの理由でその組織を去っていくこともあります。

つまりここで言う「事業がわかるエンジニア」とは「経営層(マネジメント層)」であるべきと考えます。

(仮にここで言う「事業のわかるエンジニア」が「経営ビジョンを加味した技術選定、組織編成、戦略決定」を行っていたとして、またその上層や別に事業の意思決定をするポジションの人間が他にいたとしたらその人たちは何をするのでしょうか?と私は疑問に思います。)

ではエンジニアやプログラマーは事業に対してどのような姿勢でコミットすべきか?と言う疑問に関しては、「経営ビジョンを加味した技術選定、組織編成、戦略決定のそれぞれの選択肢やその選択肢のバックグラウンドを経営層に正しく伝えることができるか」と言う視点で留めておくべきだと思います。

事業の遂行には多くの様々なシーンで意思決定を行う必要があるかと思います。その度にその事業の責任者や経営層、スタートアップなどでは社長が行っているかと思いますが、かなりの心身的な責任・負担がのしかかります。

その責任・負担を達成・解決するのはその負担を背負っている人物あるいはレイヤーでしか行えないものだと認識しています。

ただその事業遂行の中でエンジニアリング観点での意思決定が必要なシーンに「エンジニアが経営層に選択肢をそれぞれ提示する」必要があるかと思います。

その上で経営層あるいはマネジメント層が経営ビジョンと照らし合わせて最適な意思決定を行っていくべきだと思います。

つまりここではエンジニア・プログラマーは「事業がわかるエンジニア」ではなく「事業に沿った選択肢を考慮できるエンジニア」であるべきかと思います。

そして本当の意味で「事業がわかるエンジニア」は「エンジニアリングがわかる経営者・事業責任者」である必要があるかとも思います。

おわり

この記事を書いた理由は、該当記事の認識を間違って「じゃあ経営・マネジメントレベルの意思決定にも積極的に口を出した方が喜ばれるんだ!」とエンジニアが誤認してしまったり「うちのエンジニアたちは経営者視点・当事者意識が薄い」みたいな責任転嫁とも取れるようなことを感じてしまう経営者が増えないといいなぁ、と言う思いで書いてみました。

またエンジニアリングとビジネスのそれぞれの責任とそれを負うべきポジションの人達が、変に責任の押し付け合いや責任転嫁からくる不満を持たないで欲しいので、うまく役割分担して欲しいなぁと思ってます。

【Golang x Stripe】STPEphemeralKeyのDecode問題にハマった話(備忘録)->解決済

【2020/07/28 更新】RowJSONについて

key.RowJSONの型が[]byteとなっています。

どうやら[]byteJSONにされた時点Base64エンコードされた文字列になっているようなので返却値の型を[]byteにしているとBase64の文字列が返却されていました。

続きを読む

【Android】Kotlin Coroutines

Coroutinesとは

プログラミングの構造の一種。サブルーチンがエントリーからリターンまでを一つの処理単位とするのに対し、コルーチンはいったん処理を中断した後、続きから処理を再開できる。接頭辞 co は協調を意味するが、複数のコルーチンが中断・継続により協調動作を行うことによる。 サブルーチンと異なり、状態管理を意識せずに行えるため、協調的処理、イテレータ、無限リスト、パイプなど、継続状況を持つプログラムが容易に記述できる。 by Wikidedia

ちなみにコルーチンという言葉が最初に出てきたのがコンウェイの法則で有名なあのメルヴィンさんの論文らしい...

続きを読む

転職しました🎉

前置き

※本記事はあくまで個人的な備忘録的な意味合いが強く、何かしらの宣伝目的や意志の主張・強調するものではありません。またもちろんのこと特定の人物や組織を揶揄する意味も持ちません、あくまでも個人的なその当時の気持ちや考えていたことを書き記したものです。
よってここに書かれていることは全て個人的な見解であり、所属する・所属していた組織等の公式な見解ではございません。

続きを読む

【iOS】prev/nextのviewを表示させるHorizontalScroll(FlowLayout)[備忘録]

HorizontalScroll

上記画像のような両端(prev/next)の要素(view)が見えてる状態で、かつAndroidのsnapHelperが効いている(スクロールする際に1番表示領域の大きい要素を中央へスクロールされる)ようなHorizontalScrollの実装方法です。

本来両端の要素を表示しない場合は padding enabledを使用すれば実現できますが、両端のprev/nextのviewを表示しながらの場合はpadding enabledでは実現できません。

続きを読む

【Android】BottomNavigationの選択を自前で管理する

material.io

developer.android.com

AndroidStudioからプロジェクトを作成するときに"Bottom Navigation Activity"を選択すると、上記のBottomNavigationが作成された状態でプロジェクトが作成されます。

続きを読む

個人事業1年経過&本業退職します(無職予備軍になります)

2020年4月1日でめでたく個人事業主として開業してから1年が経過しました。

また、2017年より勤めていた本業の新潟の株式会社クーネルワークと言う会社を5月末で退職することになりました。

続きを読む

【Android】RecyclerViewでHorizontalScrollを実現する[備忘録]

掲題の通りRecyclerViewでHorizontalScrollを実現します。

RecyclerViewHolder.kt

import android.view.View
import androidx.recyclerview.widget.RecyclerView

class RecyclerViewHolder(view: View): RecyclerView.ViewHolder(view) {
    // layoutファイルのUIコンポーネント
}
続きを読む

Firestoreの特定のCollectionをCloudFunctionsで監視してPushNotificationを送信する[備忘録]

チャットアプリなどでFirestoreの特定のCollectionが変更された際に対象ユーザーにPushNotificationを送信するといったシーンの実装方法の備忘録です。

Firebase

CloudMessagingがPushNotificationを送信する際に必要になるfcmTokenはFirestoreに保存しておきます。 アプリ側でfcmTokenを取得する際のコードは下記になります。

続きを読む

【Swift】FirestoreのSnapshotListenerをObservableにした場合のListenerのDetach

firebase.google.com

上記の公式ドキュメントを参考にクエリによる条件一致に該当するスナップショットのリスナーをObservableにした場合、以下のような実装になります。

続きを読む