スタートアップでの経験から読み解く「エンジニアリング組織論への招待 - 第1章 - 」
お久しぶりです。前職を辞めて株式会社GlobeeのCTOになってから約10ヶ月が経ちますが、本当に色々な事がありました。 前職でエンジニアをやっていた時に私が解いていた課題は
など純粋に技術的なものが殆どであり、プライベートでの勉強もそちらに寄っていました。
(↓その時に書いた記事)
しかし現職で解かなければいけない課題は
- より多くの人に使われるサービスにするためにはどうすれば良いのか
- 同じ予算でより開発スピードを上げるためにはどうすれば良いのか
など曖昧なものが多く、私個人の技術力だけで解決することが難しいものばかりです。
ですので最近は純粋な技術力というよりも、エンジニアリングの力をビジネスに効果的に反映させるための力が欲しいと感じています。
そんなこんなで先日「エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング」を読みましたので、ここ10ヶ月の実体験と絡めて感想を書きます。
エンジニアリング = 不確実性の削減
エンジニアリングは日本では工学と訳される。理学が物理学や化学のように自然の原理を説明していく学問であるのに対して、工学はそれらに依拠しながら何か役に立つものを実現していく学問である。
何かを実現するというのは、曖昧な要求を明確な何かに変えることを意味する。すなわち、曖昧さを減らし、具体性・明確さを増やす行為がエンジニアリングと言える。
本書のエンジニアリングに対する定義は私がエンジニアリングに対してずっと抱いていたイメージとかなりの部分で一致していました。
ただ私は、エンジニアリングを「技術を用いて」不確実性を削減するものだと矮小化して捉えていました。 エンジニアリングという行為は不確実性の削減が本質であり、技術的な部分は本来そのための手段の一つに過ぎません。
少し具体的な例を挙げます。 私はGlobeeにジョインした当初、「ビジネスサイドが出したアイデアを最高の品質でできるだけ早く世に出す事」が自分の役割であると考えていました。
そのため、開発に割く時間をできるだけ長くする事を重要視し、自分がビジネスサイドに深く関わる事を嫌う傾向にありました。 しかし、スタートアップではアイデア自体の不確実性が非常に高いため、まず削減すべきはアイデア自体の不確実性です。
スタートアップのエンジニアはある程度の時間をビジネスサイドに割く事で、結果的にプロダクトの質も上がるのではないかと思います。
マイクロマネジメント型の組織は弱い
企業においては、社員全員の力を活用するために、誰かに指示をしてその誰かも他の人に指示をするという指示の連鎖が必要になる。そのため、上位に行けば行くほど指示は曖昧になっていく。
具体的で細かい指示を出さないと動けないマイクロマネジメント型の組織では、指示する側の知的能力がそのまま組織の知的能力になってしまうため、抽象化された自由度のある指示でも動ける自己組織化された組織よりも弱い。
弊社の開発体制は今の所マイクロマネジメント型の組織寄りになってしまっており、ここは課題の一つです。 ここに関しては後日また詳しく書こうと思います。
論理的思考の盲点
論理的思考とはすなわち演繹的思考のことであり、前提であるルールと事象から結論を導く思考方式である。
- ルール：人間は皆死ぬ
- 事象：私は人間である
- 結論：私は死ぬ
これが成り立つためには、以下の2つの前提が必要である。
- ルールと事象を正しく認知できること
- 正しく演繹できること
事実を正しく認知するためには、自分の認知がいつ、どのように歪むのかを知る必要がある。
論理的に考えるためには、自分が非論理的に考えてしまう瞬間を知る事が必要である。論理的思考力と言うのは、「感情的になる瞬間を知り、その影響を少なくできる」能力でもあると言える。
学力テストは通常1人で論理的な思考を用いて行うが、仕事は立場の違う複数人で行うため、コミュニケーションの失敗が論理的思考力を制限してしまう。どんな時に自分は論理的でなくなり、人は論理的でなくなる可能性があるのかという事を知った上で問題解決に臨むのが論理的思考の盲点を知るという考え方である。
スタートアップで働いていると、前職と比べて論理的でなくなる瞬間が多いように思います。
これは
- 長時間労働による肉体的・精神的疲労
- 会社のキャッシュが徐々に減っていく事による焦燥感
などの初期のスタートアップ特有の事情によるものが大きいです。後者に関しては割とどうしようも無いのですが、前者に関しては
- 休む時はしっかり休む
- 定期的に運動を行う
などである程度対処可能な気がします。
www.slideshare.net
また、自分が過去に感情的になってしまったタイミングを思い返すと以下のような共通点がある事に気付きました。
- 議論を終えて早く開発を進めたいと思っている時
- 作業中に声をかけられた時
- 議論が長引いた時(特に夜)
- 自分の意見をすぐに否定された時
この条件に当てはまるような時には、感情的になりやすいので注意するようにしています。また自分が感情的になりやすい瞬間については周囲にも共有しており、例えば作業中にイヤホンをしている時はできるだけ声をかけないようにしてもらっています。
経験主義と仮説思考
仕事では、問題を解くのに必要な情報が目の前にないのであればそれを入手するために行動し、問題を明晰化する必要がある。
情報を入手するために行動を起こしてその経過を観察し、そこから問題解決を行う考え方を経験主義と言い、限定された情報から全体像を想定し、それを確かめる事で少ない情報から問題解決に向かう思考様式を仮説思考と言う。
今現在解くことができない難しい問題は、「何が分かれば分かるのか」を考え、それを確かめる事に変換する。
経験主義は、単純に「やってみなければわからない」という論理ではなく、「知識」=「経験」を行動によって手に入れるということである。そのためには、「行動できる事は何か」と「行動の結果起きた事を観察できるか」という2点が重視される。
トム・デマルコは「観測できないものは制御できない」という名言を残した。これに習うならば、変化を観測できないものは間接的にすらコントロールできないという事になる。
私たちは何か問題に出くわすと、「コントロールできないもの」を操作して「観測できないもの」を改善するという不可能な問題設定を行ってしまいがちである。「コントロールできるもの」を操作し、「観測できること」を通じてその結果を知識にするしかない。
PDCAサイクルは「何が仮説なのか」と「それはどのようにしたら推論できるのか」の2つが揃っている必要がある。
スタートアップでは「やってみなければわからないからとりあえずやってみよう」という論理が強くなりがちですが、ここで忘れてはならないのは
- どういった仮説を検証するためにやるのか
- 行動の結果、仮説が正しかったのかを統計的に検証できるか
の2つです。この2つが揃っていないPDCAサイクルは回しても実際意味が無かったという事が多いです。最初の方は自分もこれを割とやってしまっていて、しかもPDCAサイクルを上手く回せているつもりだったので最悪でした。たまにまぐれで上手くいってしまうのもタチが悪いです。
これはグロースハックのプロセスにも通ずるものがある気がします。 詳しくは下記をご参照ください。
まとめ
とりあえず第1章を読んで考えた事をまとめました。第1章は個人での仕事にも使えるような内容が多いので、是非色々な人に読んで欲しいなと思います。
第2章はメンタリングの話、第3章以降はチームや組織の作り方の話になっていきますので、これに関しても後日記事にできればと思います。
なお、弊社では現在エンジニアを募集中です。この記事を読んでもし興味がおありでしたら是非オフィスに遊びに来て下さい！
