エンジニアとビジネスの距離感の難しさ

ばんくし王 @vaaaaanquish

エンジニアとビジネスの距離感の難しさ｜ばんくし @vaaaaanquish #note note.com/vaaaaanquish/n…

赤川 朗 / Forkwell @Akira_Akagawa

“実は"組織課題"と呼ばれる物事の殆どが、この思想と実情のバランスが取れてなかったり、思想がなくて不安定だったりする事にあるんじゃないかなと最近は考えている。” めっちゃ思う。経営とEMで思想が違うと、面接では良かったのに入社したら違ったみたいになりがち。 twitter.com/vaaaaanquish/s…

赤川 朗 / Forkwell @Akira_Akagawa

ある時点で思想がそろっていても、経営もマネージャーも完璧ではなく、その時々で揺れる。株式市場が揺れるように。 その時点での完全なマッチを目指すより、葛藤を相互にすり寄せていける自分でありたい。その時どの立場にいても。

ゆかもち@椎茸 @ykmcx

エンジニアもビジネス力つけるべき、はそうだと思うよ。そして非エンジニアもエンジニアの仕事を理解すべきだと思う。全員マッチョになるしかない。という世界観で生きてます。

ゆかもち@椎茸 @ykmcx

@tsukammo 営利企業なんだから仕方ない。 同様にIT企業なんだから仕方ない、非エンジニアだからとか言い訳は許さない。

ツカモ @tsukammo

@ykmcx IT技術の部分を変にエンジニアの聖域にしたがるのもよくないですね。

べいえりあ🌙🌙🌙 @mr_bay_area

大企業にいた頃はそもそもビジネスの人々と絡まなかったのだけれども、スタートアップ界隈に来て「ビジネスの人々が思った以上にビジネスが分かっていない」という印象を持ち、自分でちゃんと口出せるようにしないとまずいと思い始めたというのはある。 note.com/vaaaaanquish/n…

べいえりあ🌙🌙🌙 @mr_bay_area

ちなみに「ビジネス」がどこまでを指すかよく分かってないのだけれども、「プロダクトがどんなユーザーにどんな価値を提供するか」はエンジニアというかプロダクトに関わる人全員が意識しといた方が良いような気はしている。

べいえりあ🌙🌙🌙 @mr_bay_area

「ユーザーの解像度が低すぎる」「雰囲気で判断するんじゃなくて定量的なエビデンスを作れ」「我々のやるべきことは顧客に言われたものを作ることじゃなく、顧客の問題を解決するものを作ることである」みたいなことを言い過ぎて心が無になったみたいなことはある。

™ @tmaehara

弊社，ソフトウェアエンジニア (IC) のスキルとして Project Proposal を書いて事業関連の数値を目標にすることや Project Roadmap を書いて工数見積もりするのが要求されてるはず． twitter.com/vaaaaanquish/s…

™ @tmaehara

もうちょっと一般には，ソフトウェアエンジニアの職責が「product の ownership をもつこと」で，ownership の中身が proposal/roadmap/execution/etc. という認識．research 寄りの弊チームですらまあまあ重いので，多分 development 寄りのチームだとすごく重いと思う．

odashi @odashi_t

ビジネスと明示的に絡まなくてよいのは分業が達成された大組織のエンジニアの特権みたいなものなので、基本的にはそういうのは望むべくもない気がします。僕が初めて働いたソフトウェア企業（2008年くらい）もエンジニアが電話取ってたし、普通はそっちだと思う。

odashi @odashi_t

ビジネスと明示的に絡まなくてよいのは分業が達成された大組織のエンジニアの特権みたいなものなので、基本的にはそういうのは望むべくもない気がします。僕が初めて働いたソフトウェア企業（2008年くらい）もエンジニアが電話取ってたし、普通はそっちだと思う。

Kazunori Sato @kazunori_279

Googleにはこの苦難を乗り越えるのに長けた希少なエンジニア達がいて（スタンフォードCS出てるのにMBA取ったとか）、社内ではプロダクトマネージャと呼ばれている。 note.com/vaaaaanquish/n…

iwashi / Yoshimasa Iwase @iwashi86

“エンジニアの事業貢献を口にし始た時、誰かがお金の事を考えないと自分たちエンジニアが経済行為の中で不利になる、でもそれってめっちゃコンフォートゾーン出ないといけないからしんどいよなって話。” とてもわかる note.com/vaaaaanquish/n…

kos59125 @kos59125

事業価値を a^b みたいに表したときに営業は a を大きくして技術は b を大きくするみたいに説明してる。 b の影響は a に依存するし、 b にコミットするべき人間に a にコミットしないとみたいに考える（人事評価する）と、それは虚無よね。 note.com/vaaaaanquish/n…

nishiba @m_nishiba

エンジニア出身の私にとっての「ビジネス」とは、何かを考える。いくつか種類があると思っている。 大きく分けると、 ①他の人が作った戦術を理解してエンジニアリングができる。 ②戦術を自ら考えて他の人に理解できるように説明することができる。 の2パターンかなと。 ①と②を混ぜるとややこしい。

nishiba @m_nishiba

①は「理解」ということが大事で、「納得」ではない。納得するかどうかは論点ではなく、理解できるかどうかが大事。

nishiba @m_nishiba

私はもともと①が強く、徐々に②に挑戦していった感じ。②もいきなり挑戦するのではなく、①からの延長線上にある。 ①をするときに、大事なことは「俺だったこうする」「意味がわからない」「面白くない」など、否定しないことだ。 その上で、その戦術を文面を正確に読むことが大事。

nishiba @m_nishiba

意外と正確に読めていないことが多い。数式を読むように正確に読まないといけない。 その次にすることは「なぜそれをする必要があるのか」という理由を自分なりに考える。戦術を全面的に肯定する気持ちでその背景を自分で考え背景を含んで理解しようと取り組む。理由は一つだけではなく、

nishiba @m_nishiba

多くの場合複数ある。考えられるだけ多く考える。時間もしっかりと取るべきだし、考えをちゃんと言語化する。頭の中で考えるだけでなく、しっかりとノートなどに書くことが大事。意外と言語化は難しい（これはまた別の機会に）。

nishiba @m_nishiba

その次にするのは、戦術を考えた人に自分の理解についてどう思うかを質問する。正しい or 間違いの2択ではない。（時間切れ。続きはそのうち）

Satoshi Nakagawa @Psychs

「エンジニアもビジネス的な視点を持って」みたいな話、ぼくが過去にいたUSのテック企業では聞いたことない。ビジネス的な視点を持つのはプロダクトマネージャーの仕事。

べいえりあ🌙🌙🌙 @mr_bay_area

RT、これは大変にその通りだと思うのだけれども、日本には優秀なPdMがほぼいないので、エンジニアがビジネス分からざるを得ないという話な気がした☺️

NT @n_takenaka_

これはめちゃめちゃ面白い論点。自分もプロダクトマネージャーとしては、エンジニアもビジネス的な視点も持ってくれていればそれはそれで共通言語が増えるのでいいことではあるけど、それよりシンプルに専門性が高い人の方が嬉しい。 twitter.com/Psychs/status/…