エンジニアリングとは何か?不確実性との向き合い方


エンジニアリングとはなにか?

長くビジネスをやってきて、年々、ビジネスでソフトウェアエンジニアリングの重要度の高まりを感じるようになってきた。エンジニアリングがビジネスの成否を分けると感じることが増えた。

そこでこの文章では、ソフトウェアエンジニアリングとは何か?そしてエンジニアリングをkiizankiizanの文脈でどう捉えて、何を求めていて、どのように使っているのか?を書いてみます。


要約
・エンジニアリングとはなんだろう?
・エンジニアリングで大事なことと大事にしたいこと
・そのためのチームビルドについて


まずスタートアップという、この世に無いビジネスを作っていこうとする人たちにとって、エンジニアリングは自社の作りたい世界や解決したい課題から逆算して、ビジネスを展開し成長させていくためのものと考えている。

広義な定義ではあるのだけど、スタートアップの経営者としてそこからスタートしたい。

なぜなら、ビジネスや作りたい世界は不確実であり(それが本当に必要かなのか誰にも分からない)、その不確実性を減らすためにエンジニアリングを効率的に駆動させて、実際に必要なのかを検証するために使うからだ。


ビジネスの不確実性

いまkiizankiizanでは、サブスクの洋服レンタルサービス「leeap」のリニューアルを進めている。(UWearとしてリニューアル済み)リニューアルのためにユーザーインタビューをし、ビジネスの課題をあぶり出し、僕らが作りたい世界とユーザー課題を一緒に煮込んで、ビジネスとしてUXとしてどうすべきか?を煎じていった。

この新たなビジネスやUXが、ビジネスとして成立するかどうか?ユーザーに喜んで貰えるかどうか?という不確実性を実証することがエンジニアリングである。



そもそも新規ビジネスを考える際に大事なことは「確実性」でも「整合性」でもない。

それはユーザーは「どのような課題を持っているか」であり、その「課題」を取り除けているか?である。ただ「ユーザーの課題」と「アプローチ」は多様であり、それらに向けて、大きな仮説から順番に試していく。


そこでビジネスの「不確実」が高い状態から低い状態にしていくことが、エンジニアリングのビジネスでの役割である。


ビジネスの不確実性に向き合うときに大事なこと

上述したビジネスの不確実性に対して、エンジニアリングを通じて、どのように効率よく不確実性を減少させられる状態をつくるかになる。


そこで大事なことは上述した仮説である。

仮説は誰かの主観や考えをもとに、「このビジネスはユーザーの課題がこれで、こうすれば解決できる」というモデルのことであり、どんなビジネスも、はじまりは誰かの思い込みから思考はスタートする(こんなものを作ったらユーザーは喜ぶのでは?という思い込み)。


そのため仮説はあくまで主観であり、確かではない。ただし仮説は仮説として言語化されることで、どこまでが主観でどこまでがファクト(のようなもの)なのか、境界線の地図のような役割になる。仮説をもとに検証することで、不確実性を早く検証することに繋がる。



そのためには、実際に新しいビジネスの形がユーザーに受け入れられるか分からないため、早くそれを簡単な方法で検証することが大事である。

ここで仮説が効いてくるので、仮説が的確に立っているかどうか(仮説が立っているか?という言い方をkiizankiizanではよくする)を大事にしている。


説得力のある仮説

仮説の説得力は大事だ。説得力のない仮説だと、メンバーみんなが「せやな!まずはこの仮説から検証せなあかんな(OSAKA LANG)」となりにくい。


仮説の説得力はユーザーインタビューやアンケートなどの客観的な情報も大事だけど、それについて深く考えたかどうかを大事にしている。

曖昧な表現にはなるが、深く考えるというのは自分が考えた仮説に代入可能な重要なストーリーを入れて、自分の仮説の強度を確かめる行為の連続だ。忍耐力と体力が必要とされる。

その強度テストに耐えられた仮説が説得力の高さとなる。



エンジニアリングの不確実性への向き合い方

そのようなビジネスの不確実性を減らすために、大事にしたいことは、いかに早く小さくリリースするかとなる。

作りたい世界やIssueに対し、立った仮説の重要なポイントから順番に、最小の課題の実証を繰り返していく。そして手応えを感じたら(検証に耐えたら)、ビジネスを頑強にするためにソフトウェア・サービスを作り込んでいく。


「仮説を検証するために、いかに早く小さくリリースをするか」と書いたが、機能をデリバリーする際のフローを早くするために、組織の機能デリバリーフローの速さと相関する。

正しくいうならデリバリーフローの速さから逆算した組織アーキテクチャの作り込みが必要で(ソフトウェアのアーキテクチャと組織のアーキテクチャがあれば、組織のアーキテクチャが勝つ)これだけで多くのテキストが必要とされるので、これはまた別の機会で考察したい。


なお、この小さく検証するうえでも、一番の拠り所にすべきは仮説となる。

仮説から逆算して一番大事なことから考える。そして、その一番大事な部分の工数の見積もりと、どのように検証するかの話をしていく。


続いて、その不確実性に向き合うチーム作りについて考えたい。


不確実性に向き合うチーム作り

kiizankiizanはチームメンバーを少数精鋭にしている(していきたい)。

少ない人数で仮説にコミットし、仮説やISSUEについて話し合えるチームづくりを心がけている。


よく言われるAmazonジェフベゾスのピザ1枚理論である。


なぜなら、不確実性に向き合うためには、多くの対話とメンバーの信頼感が必要とされるからだ。

少数のチームメンバーと会話をし、失敗しても失敗を笑い合える空気が大事だ。だからこそチームメンバーのコミュニケーションの不確実性を減らすようにしている(例えば、雑談会、リモートでの雑談の仕組み、上流すりあわせ会とか)

失敗は成功の母であるのを地で行く必要がある。Valueにとりあえずやってみようを入れているのも、それが理由である。


そしてチームメンバーが信頼しあえるように、メンバー同士が自己開示し、弱い部分をオープンにし、相手を認めること、フォローすることを大事にしている。

多様性とか言うと、お題目に聞こえるかもしれないが、心から相手の個性を認めるというのは難しいから(どうしてもそこに目が行ってしまうし、気になる)、安心して仮説検証を回すためには何度も話し合いが必要になる。


本当に強いチームを作ることは難しいが、やはりみんなで難しいお題にチャレンジするためには、それぐらい強いチームでないと戦えないはずである。諦めずに強いチーム作りに努めていきたい。


最後に僕のビジネスの不確実性との向き合い方について。

僕は、できるだけテキストや口頭を通じて、未来の市況や業界を考え、そこで弊社のビジネスの未来のロードマップを言語化するようにしている。もちろん全てを予見して伝えることはできないが、深く考えた仮説を提示しようと思っている。今、何を考えてて、これからどんなことをしたいのかを伝えるだけで技術的な負債が減る可能性は高まり、みんなも不確実性が少しでも減るのではないかと思い、そうしている。


解決すべきこと、達成することを明確にすること。

現状の使えるリソースを明確にすること。

それらの情報にいつでも触れることができること。

を伝えるようにしている。


そしてどんなチームにしたいのかを言語化することが、

未来、チームが不確実性に向き合うために役に立つと思っている。


これから新しいビジネスやサービスにも積極的に取り組みたいと思っている自分としては、強いチーム作りは至上命題として頑張りたい。



井上大輔 

コメント

このブログの人気の投稿

「洋服を通じて、楽しくなる世界を作りたい。楽しくなるための仕掛けづくりは、まだまだできていない。」キーザンキーザン代表インタビュー

「いまは不具合が起こっても、個人に責任が行かない環境が整っている」苦境の経験から学んだ、ミスしやすい環境の構築のこと

「人への興味が起業の理由」kiizankiizanのCEO井上にインタビュー 〜 小学生でのモノを売る体験とアパレルでやりたいこと〜