日々の気付きと時々、振り返り

しがないセールスエンジニアが日々考えてることをまとめたもの。

ビジネスとテックの境を行き来して思ったこと

前回の記事から内容が前後してしまうが(該当の内容も近日中に書く予定です)今書かなければ書けないという気がしたので、一筆書きで書いてしまおうと思う。

 

私はある見方を取れば、少し特殊な立ち位置におり、具体的には、大学では経済や経営を専攻し、論文を書き、また、事業の立ち上げや、営業、マーケ、簡単な経理の経験もある。が、その後、紆余曲折あり、世界的にも有名なテック企業で、セールスエンジニアを経験し、そして、今はエンジニアとして働いている。何が言いたいかといえば、意外とビジネスとテックを、当事者として、かなりディープに見、仲介し、そして、移動してきた歴史があるのだ。そして、両者には、明瞭に表現し難い、しかし、確実な差異と、時に隔たりがあることを感じた。これについてステレオタイプの範囲を逸脱し、しかも、等身大の言葉で語られた情報は少ないように思う。私の限られた経験からにはなるが、この言語化に努めてみようと思う。

 

両者の姿勢について

当然個人差はあり、また、個人差の範疇に落ちる話もあるのだが、実際に体感することとして、ビジネス側の人は「仕事を取りに行く」ことを良しとし、技術側の人は「仕事にノーということ」を基本姿勢としている印象を受ける。これは、例えば、ビジネス書などを読むと顕著なのではないか。もちろん「ノーという技術」というような本も巷には存在している。しかし、基本は、特に若手は、自ら仕事を取りに行く、そして、営業などを担当していると、その姿勢含めて関係構築に役立つという事実は、やはりあるのではないか。

 

しかし、技術側は基本「ノー」という。基本的に「ノー」というのだ。もはや「ノー」と言ってから考える節すらある。いや、それはいいすぎだが、それくらい基本姿勢が違うのだ。何もここでその是非を議論するつもりはないが、それにしてもこの違いは興味深い。特に技術側は投下リソースが一つ一つ多い(開発に時間がかかる・開発後も保守運用が発生する)ため、担当プロジェクトを精査しなければいけないという背景はある。がしかし、それを超えて、姿勢や、時には、仕事観にまで影響を与えているというのは、第三者としては、シンプルに新鮮であり、二つの潮流をここに見た、という気がする。

 

これがなぜかというと、やはり投資コストの違いに起因すると思う。つまり、ビジネス、あるいは、営業に限定して話せば、提案(するだけ)というのは非常にコストが低い。また、上流は比較的、実作業が少ない。話し、決定すれば、後は任せたというパターンも少なくない。また、提供価値も違う。営業は基本的にコミュニケーションであり、逆に言えば、その納品物(言葉)の修正もコミュニケーションで賄えるということになる。技術側は違う。基本的に実作業(設計・コーディング・動作検証)が発生し、また、基本的には必ず、恒久的に発生する保守・運用コストが存在する。そのため、おいそれと手を出せないのだ。組織によっては違うが、時にはエンジニアにそれほど権力が事実上渡されてないこともあり(おとなしい人も多い)生殺与奪を自ら決められないとなると、怯むのも自然な流れだ。

 

こうした背景があり、姿勢の違い、引いては、行動パターンの違いが生成されるのではないか、ということを思わないわけではない。

 

仕事の性質

ここは多分に主観が入り、読み手によっては不適切な観察だと思われる方もいらっしゃるかもしれない。その場合はこの項目を即刻削除したい。しかし、それにしても求められる価値観が、ビジネスの現場(上層部はまた少し異なる)と技術側では大いに異なる。

 

(私の経験した範囲では)ビジネスはやはり「現実論」「行動」なのだ。逆に、テックは「理想」「解決」である。ビジネスの現場は基本的にあらゆる条件が整わないことも多い。もちろん技術側もそうだ。資金の不足、技術的負債、思うように行動できないことも多いかもしれない。しかし、ビジネスはやはり開発に比べてリードタイムが異なる。テンポが早い。営業提案は週に何回あるかわからない。そうした時に、やはり手駒でなんとかするという営業が好まれるのも分かる。打開策を見出し、前に進める。それが求められている印象を受ける。

 

これはもちろん技術側にも言える。不利な条件の中、enough な線を見極め、そこに落とし込む、プロジェクトマネジメントの技術も貴重な素養だろう。しかし、基本は設計から入る。しかも、無駄のない、堅牢な、そして、強固な設計こそ良いとされている。それはやはり — 個人の感覚の範疇を出ないが —「理想から落とす」そういう印象を拭いきれない。いや、それ以上に「理想を拡張する」という表現の方が近いかもしれない。

 

パッと思いつくアイデア、そこから少し考えて出てくる絵、それをもう一度二度、定義し直して、別の角度から見て、問題を組み替えながら、よりよい(無駄な仕事を発生させずに当初の問題を解決する)ソリューションに近づく、そういう姿勢を備えた人が、少なくとも私の周りには多い印象を受ける。

 

そして、特に最近の私は、それに色濃く影響を受けている。というより、そうした思考をこれまでしてこなかった。ひとまず立ち止まって、果たしてそれは解くに値する問題だろうか、本当にその解き方がいいのだろうか、問題を言い換えたらより抽象的な問題に言い換えられないだろうか、言い換えられるとしたらその最適な解決方法は果たして何になるだろうか、もしリソースが潤沢にあったら?そのリソースを確保する方法は、本当に想像しているほどコストがかかることなのだろうか、全体を通したらよっぽどペイするのではないか。そういうことを考える癖が、まだついていないので、徐々につけるよう意識している最中である。

 

これは -- 様々な人に聞いてみないとわからないが -- 意外と普通の思考回路ではないのではないか。特殊な環境下で -- 例えば、プログラミングコンテストなど、純粋に頭の体操が求められる経験 -- 培われる思考技法の一つなのではないか。まだ答えは出ていないが、私はこれに出会い、目が開く思いがした。また、共に仕事をする人を不幸にしないためにも(消耗戦に巻き込まないためにも)これを修得するメリットを感じている。わからない。わからないが、将来的にこれが果たしてどういうことだったのか、再解釈する機会を設けてみようと思う。

 

ではでは。