techスタートアップらしさとは結局なんなのか
この記事はカケハシアドベントカレンダー2021 25日目の記事になります。
株式会社カケハシ 取締役CTOの海老原です。少し前に、一週間ほど休みをとって何もせずゆっくり考える時間が取れたことがありその時にとりとめもなく考えたことをまとめてみようと思います。
・・・
そもそも重要なのは“tech”なのか？
これはある種の言葉の綾に近い話なのかも知れないが、例えば「techスタートアップらしさを強めていく」といったテーマについて議論する際になんとなく違和感があるというか、重要なのは“tech”なのだろうか、という疑問が浮かんでくる。
無論技術や開発の責任者として技術の観点が強くされることは喜ばしい、もっと端的に言えば「やりやすい」ことではあるが、全社をあげてある方向の価値観を強めていこうとした時に皆で共有できる・すべきものはもう少し手前の概念であるように感じる。
それは言葉にするなら、コテコテの「（情報通信）技術」といったものというよりは、ものづくりのマインドやクリエイティビティ、クラフトマンシップ、もっと抽象的に言うと「これまでに無かったものを具現化・実現していくプロセス」（これは要は「工学」というものだと思うが）の尊重というような概念ではないか。そして、そのような概念は必ずしもソフトウェアエンジニアのような開発職に限定されるものでなく、プロダクトドリブンな組織としてはあらゆる職種で共有している必要があるものではないかと考えている。
例えば「techスタートアップらしさ」のような価値観を強めていこうと考えたとして、すぐに考えられることとしてはソフトウェアエンジニアの開発環境を強化するとか開発系の資格の取得を支援するとか制度面での工夫はいくらでもあるし、それらはできることからすぐやるべき類のことでもあるが、一方でそれらの施策を積み重ねればすなわち「～らしさ」につながっていくかというとそういうことでもないと思う。
それらはやる。無論やるが、肝要なのはその背景にある組織としての思想でありそれに基づいて設計・運用されていることである。
前提になるVUCA的な世界観
ではなぜ「～らしさ」のような価値観が重要になってくるのかというと、それは例えば「その方が開発系の職種が働きやすくていいよね」とか「ソフトウェアエンジニアの採用が強化できるから」というようなことではなくて（副次的な効果としてそういうこともあろうとは思うが）、ソフトウェアサービスを開発して提供しその対価を得る、という営みにおいて生き残るための前提のようなものなのではないかと感じている。
巷間よく取り沙汰されるようになっているため、ここでの説明は省略するが、いわゆるVUCA的な世界観があるとして、ソフトウェアサービスの開発と提供はまさにVUCAそのものと言えるのではないか。
そもそもユーザーは本当に自分が何について困っているかについて明晰に言語化することは難しく、困りごとも外部状況によって刻一刻と変わっていく。何かを実現して持っていくと「欲しいものはこれではない、ということは分かった」というのが常だ。ソフトウェア開発の設計手法や実装手段は洗練され、非常に多くの要素技術を組み合わせて実現されることが当たり前になっており、一部に対する変更が全体にどのような影響を及ぼすかを事前に完全に予測し切ることは極めて難しい。
私にとって「～らしさ」とは、つまりそのような事業行動において重要視すべき価値観とは何かということになるだろう。
value、アイデンティティを最重要視する組織であること
VUCAの世界観に基づけば、優秀な誰かが唯一の正解や方針を持っていてその通りにやっていれば正しい場所にたどり着く・結果は予測可能である「わけではない」ということだとして、そのような状況では関係者の間で感じた細かい違和感や方向性への危惧なども含めて、常に認識を合わせて向いている方向を調整して進めていくことが重要だろう。
一方で、「そもそも何のためにやっているのか?」とか「我々は何を本当に大切にしたいのか?」といった根本レベルでの認識合わせに細かい議論のたびに立ち戻るのは工数がかかりすぎるし、コミュニケーション上重要視したいプロトコルのずれのせいで、非本質的な部分でもめるのは時間がもったいない。そうならないように、そもそも我々は何者であり、なぜこのようなことをしているのか? どういう言動を善とするのか? というレベルの認識合わせを強力に結び、前提として共有されている必要がある。
一見“tech”とは直接関係ないようにも思えるし、「valueが大切です」というのは当たり前といえば当たり前の話だが、「～らしさ」を「VUCAな世界における最適な行動様式」と捉え直すと、なお一層その重要性が明確になるように思える。何も確かなことはないからこそ、組織としての内面に確かなものを共有する必要がある。
そしてもう一つ肝要だと考えているのが、この重要性はある種の合理性や損得を超えたところに置かれる必要があるということだ。これは最早、言葉の定義上の問題になってくるが、場面場面での合理性や損得によって出したり引っ込めたりできるようなものをvalueとして設定することには何も意味がないと私は思う。「この価値観を貫くことで短期的には損害が出るかも知れないが、それでも貫く」と思えるものだけがvalueになりえる。
「実行する」主体が「考える」主体でもある
この手の言説で必ず槍玉にあげられるフレデリック・テイラーの「科学的管理法」だが、要はそのアンチを行こうということだ。そのような考え方自体はむしろ昨今珍しくないのだが、一方で我々はテイラーの呪縛から本当に逃れられているだろうかと思うと、全然そんなことは無いようにも思える。我々は、概ねいつも組織の中で行動していく時に、「全てを見渡す偉い人が正解を知っていて、それをベースに計画し、実現化する者達はその計画の遵守を求められる」という観念にまだまだ囚われていないだろうか。
既に述べた通り、ソフトウェア開発というものはVUCAの塊のようなものであって、そのような行動をする中で詳細に対する洞察を持ち合わせていない「全体を見ている者」がたてる計画には、「目安」や「そうあれかしという願い」以上の意味を持たない（無論、必要ないとか重要でないということではない）。そのような指針やざっくりした在りたい状況を踏まえて、それを実現するためには何がどれぐらい必要でどれぐらいかかるということを考える主体は、それを実際に行う主体でなければならない。
そして、我々が「そうですね、そういうの大切ですね」と普段考えているレベルから更にもう一歩踏み込んで、実践に伴う思考の積み重ねによってそもそもの指針や在りたい状況自体の修正に至る可能性も尊重する必要があると考えている。
計画通りに物事を進めることよりも合目的性や意味を重視する
私は昔から「やりきる」という言葉があまり好きではない、というか、この言葉が利用されるケースが大体観念的であまり意味のない根性論をベースにしていると感じることが多い。間違ったことをやりきることはシンプルに間違っている、というと単なるトートロジーになるが、そういう感覚を覚える。そんなことそうそうあるか、とも思えるが、私がこれまで在籍したあらゆる組織で「このまま進めるのが微妙なことは皆薄々分かっているがとにかくこういう計画でやるということが事前に決まっていたことなのでとりあえずやりきる、そのためにハードワークのような犠牲も飲み込む」ということは行われていたと思う。
同じような理由で、「スピード感」という言葉もあまり好きではない。概ね、「自分がこうであって欲しいというスピードで物事が進んでいない」ことに対する情緒的な表明にしかなっていないからだ。
VUCAの世界では、自信満々で始めたことが目も当てられないぐらい壊滅的に間違っていたということも普通にあり得る（そして、スタートアップの行動なんて最早ほとんどがそういうものではないのか）ので、例えば「間違っていたことが分かるところまで」やりきるのは極めて重要な姿勢ではある。
だから、「やりきる」ことが常に精神論的で無意味だということではなくて、「それはどんな不明確であったことを明確にするためにやっているのか」「何が分かったら進めるか止めるかを判断し直すのか」というような目的感や意味がまずあって、それら込みでストップアンドゴーを繰り返す機敏さや、やりきる姿勢が求められるというところまでがセットであるのだろう。
why/whatに全体で納得して進めるための工数をサボらない
valueの重要性の項でも述べた通り、VUCAな世界観に基づくなら例えば全てを見渡す上位層が正しい計画をたて、作る者はその計画通りに物事を行うことさえできればよい、ということにはならない。むしろ、全体として向かいたい方向性や根本的な意思決定を覆しうるようなリスク・不安要素に対する気付きが実践の中で得られたのであれば、どんな些細なことであれ適切にフィードバックされ全体の計画への変更も企図する必要がある。
一方で、非常にしばしば見られる事象として、物事を推進する「スピード感」の名のもとに、本来なら必要であった方向性に対する認識の同期や懸念も含めた意見収集が省略されたあげく、もう後戻りや調整が難しくなった状況でそれらの課題提起が噴出し、結局省略しなかった場合よりもよっぽど事態が難しく紛糾するようなことがある。
全ての細かい議論をキャッチアップして状況を停滞させることはナンセンスだが、時間を定めて前提や関連する人間の想いを吐き出し切る、そして決めたことを前に進めるという風に、前段の重要性を強く認識する必要がある。自身の経験上も、ものづくりの人間のエンゲージメントを最も下げるやり方の一つは「結論ありき」の進め方だと感じている。結論が決まっている議論に懸念の表明や方向性の確認をしても無意味であるし、であれば思考の余地が無い=自身のクリエイティビティが反映される可能性が無いのだから。
結局なんなのか
ここまで長々といろいろ書いてきたのだが、結局のところ何を言っているのかというと、大体いわゆるアジャイルソフトウェア開発の考え方について、自分が特に重要だと考える概念をフルスクラッチでまとめ直しているんだなこれは、ということに途中で気づいた（一部直接関係ないことも書いてある）。私は、アジャイルソフトウェア開発の考え方は、単なるソフトウェア開発技法やプロセスの話ではなく、ソフトウェアサービスを開発する企業の経営思想のレイヤーで捉えるべきものとして考えているので当然といえば当然の結論ではある。
ソフトウェアサービスを開発し、顧客自身も判然としていない課題解決を価値として提供するという不確実な領域において、価値そのもの・実現の進捗の両面の不確実性について漸近的に明確にしていくために必要なしぐさを何と捉えるのかということを、セルフアイデンティティ・思考と実践の一体性・意味の検証の重要性・前提を揃えるコミュニケーションのような観点で説明したということになる。
同時に、このエントリーはオリジナルの考え方はあまり無く、半分程度は今年読んだ中で最も感銘を受けた書籍の一つである「LEADER’S LANGUAGE」の自分なりの理解の要約に近い。エンジニアリングマネジメントに関心がある方に年末年始触れる書籍として強くお勧めして結びとしたい。
・・・
そこそこ重量級の文章になってしまいましたが、最後まで読んでいただきありがとうございます。カケハシでは、このような考えに基づいてものづくりをするための組織を組成していくために日々試行錯誤しています。もし少しでも共感していただけたなら、軽い興味で話を聞いてみたいというのも大歓迎なのでいつでもお声がけください。
カケハシ採用ページ
https://recruit.kakehashi.life/