Kaizen Platform で CTO をしている渡部です。 当社ではどんなことを考えながらエンジニアリングに向き合っているか、どういう仲間と一緒にチームを作りたいのか、というのを今日はお話しさせていただきます。
ちなみに今日は左の上の奥歯を抜いてきたのでとてもつらいです。慰めるためにはてブもらえると痛みも和らぎます。
エンジニアリングの進化の歴史を俯瞰してみる
まず、認識しておきたい構造として、上図中央の「ミゾ」です。
- 開発者はビジネスのことなんてわからないからどうせ何を言っても無駄だ
- 開発がわかってないやつに開発のことをわかってもらうことなんて無理だ
といった会話を聞いたことはないでしょうか? 実社会と開発の世界がある意味異なる言語で生活していて、同じ日本語なのにお互いの言葉が伝わらない、みたいなことが起きてしまいます。 これこそが「ミゾ」の正体です。開発の歴史はこの「ミゾ」を超えてエンジニアリングの成果を実社会に届けようとしてきた歴史なのだと思っています。ちなみに、インターネット業界のソフトウェア開発だけではなく、どの産業における開発もこういった歴史の変遷をたどって来ていると思っています。
まずはこの歴史の変遷を 4 つのフェーズに分けて解説していきます。
フェーズ1 : 開発黎明期
ちょうど私が 2010 年くらいに GREE に在籍していた時がこのフェーズだったかなと思っています。開発のプロセスや体制がまだ整備されておらず、一騎当千のエンジニアが魔法のように活躍していく、そんな古き良き時代だったと思います。 技術的な制約も多く、そういう制約を乗り越えて既存のシステム化されていない仕組みをシステム化していくことでスケールと低コスト化を実現していく、そのことだけでも十分な事業的な差別化要因になっていたフェーズです。
こういったフェーズでは「大規模トラフィックへの対応」「LAMPによる開発」みたいな形で要素技術に脚光が当たっていました。今の Fintech とかにちょっと似ているなとか思っています。
フェーズ2: 開発整備期
Kaizen Platform が創業時から切り開いてきたのがこのフェーズです。(私はまだ入社していません) 「オープンソースのように開発する」という形で、Slack や CircleCI 等の SaaS を積極的に導入しつつモダンな開発体制が整備されていきました。今となっては当たり前のようにこういう体制を導入している企業も多いですが、このフェーズによる開発体制の整備が効率的で進化の早いプロダクト開発 (フェーズ3) の礎になっていきました。
しかし、フェーズ 1~2 までの間ではまだ開発の世界からのアウトプットであるプロダクトは開発サイドの思いを中心に作られていた時期でした。
フェーズ3: プロダクト期
今から 4~5 年前くらいからこのフェーズに入ってきたような気がします。「プロダクトが大事だ！」と声高に叫ばれ始めたと記憶しています。(実際私もそう言ってたはずです) 開発単体ではなくプロダクトに注目が集まる事によって、プロダクトマネージャーや UX デザイナ等のエンジニア以外の複数の職能の重要性が認識されてきて、エンジニアの組織内の重要性は相対的に下がってくる時期でもあります。(エンジニアの重要性が下がったわけではなく、他の職能の重要性も上がってきているということです)
上図を見ていただくと、「プロダクト」は実社会の方にだいぶ近づいてきていて、ちょうど「ミゾ」の上くらいにあります。だいぶ近づいては来たのですが、これでもまだ「プロダクトアウト」と言われる状態を脱しきれていません。
説明するのが難しいのですが、「プロダクト」というものがアプリのアイコンや名前みたいなシンボルとほぼ同じ対象物を指している感覚に近いです。
これは、これまでなかった概念を世の中に浸透させていくときに有効なアプローチだったのだと思っています。「フリマアプリ」という概念がなかった時代に「メルカリ」というアプリ(概念)を打ち出して行くことでそういった概念を世の中に広めていったような感じです。(中の人ではないので、適当なこと言ってたらすいません)
しかし、「プロダクト期」の成熟に伴って「プロダクト」の概念が指し示すものが大きくなるにしたがって以下のような弊害も発生してきました。
- 「プロダクト」という全体主義的なアプローチの中で、ものづくりに関わる個人が実感として感じられる貢献度がわかりづらくなり、個人のものづくりの成果 (やりがい) が感じづらくなる
- 「作ればウケるはず」という過去の成功体験にとらわれて、大きく考えて大きく作る事によって失敗確率が高まり、より成果 (やりがい) を感じづらくなる
フェーズ4: UX 期
市場が成熟してくると「プロダクト期」に必要だった「新しい概念を広める」というところから更に進化が必要になります。Airbnb は新しい概念でしたが、今となっては当たり前のように受け入れられてきていると思います。
この場合、ユーザーは「Airbnbを使いたい」とおもってサイトを訪れるわけではなく、「今日快適に過ごせる宿はないかな? できればリーズナブルに」と思ってサイトを訪れます。つまり、「プロダクト」を求めているわけではなく「体験」を求めているわけです。
ものづくりも「プロダクト」ではなく、この「ユーザー体験」に寄り添っていく事になります。
余談ですが、私はこの Airbnb のユーザー体験が好きです。検索というとても自然なインターフェースで宿を探すことができます。システム提供側の都合に合わせてユーザーに操作させるわけではなく、ユーザーの自然な体験に寄り添っていると思っています。 しかし、これを実現するのは中々大変です。登録されている物件の情報をインデックス化し、いつでも検索できるようにしなければなりませんし、そのユーザーのその検索キーワードに一番あった検索の結果を返すために様々なサブシステムがユーザーの見えないところで連携して動いている必要があります。
また、「ユーザー体験」はまさに実社会の中にあり、それを反映するものなので、以下のような副作用が生まれます
- 改善したい「ユーザー体験」に集中することで、個人のものづくり実感が湧きやすい
- その「ユーザー体験」が実社会とのつながりを感じやすいので、さらなるモチベーション向上につながる
Kaizen Platform の取り組み
プロダクト期からの脱皮
Kaizen Platform も、プロダクト期の中でのプロダクトの成熟の中で苦しんできました。大きく考えて大きく失敗する、ということをやってきてしまいました。今まさにそこから脱皮して行こうとしています。その為の取り組みをご紹介します。
大きく考えて小さく作る。正しく失敗する
当社の ryopekoが Rails Developers Meetup 2018 で「正しく失敗しつつ進むプロダクト開発」という話をしてきました にも書いているとおり
- 小さく作ってすぐに出す
- フィードバックを受けて改善する
- 試しやすく捨てやすく統合しやすく設計して開発スピードを上げる
ということを意識してものづくりををしています。
このときに意識すべきことは、考えるのはあくまで大きく、ということです。 小さく考えて小さく作ると、千本ノック状態になるのですが、その結果特に何も前進していないという事が起きがちです。なので、こういう未来に持っていきたいと言うのはあくまで大きく考えつつも、仮説検証のサイクルを上げていくために小さく作っていくということが重要なのです。
UX (実社会) にフォーカスする
Kaizen Platform はクラウドソーシングのプラットフォームです。なので常にそこには「仕事を頼む人」と「仕事をする人」がいます。この方々の実際の利用状況を考え、時には実際にお話を伺いに行って、我々が解決すべき課題は何なのかと言うのを必ず考えています。ラップトップの中でだけ完結する世界ではありません。
そこで得た知見を、「ユーザー体験」という形でどの様に実装できるのか、難しいお題ですがそれを常に考えながら、作り手の独りよがりにならないように肝に銘じながらものづくりをしています。
さらなる進化のための取り組み
機能とユースケースの分離
Airbnb の例を先程挙げさせていただきましたが、検索という「ユーザー体験」を支える「機能」は様々な物があります。
- 機能の進化
- ユースケース毎の体験の進化
MVC のような構成を取っていると、この2つの進化が同期しなくていはいけない事が多く、開発時にフラストレーションを抱えることがあります。これは、機能とユースケースが結合しているためです。
開発のサイクルで考えると、ユースケースは早い開発サイクルで継続的に改善していきたいですが、機能はじっくりとした開発が求められることが多いです。この 2 つを分離することで、それぞれの正当な進化を実現できます。
Platform Core の蓄積
作ってきた機能が適切な抽象度をもつと、様々なユースケースにおいて利用可能になります。例えば、通知のようなシステム基盤を思い浮かべていただくと想像しやすいと思います。 こうすることで、Kaizen Platform の Core 機能として開発の成果物を蓄積しやすくなり、それはプラットフォームの幅を広げていくことになります。
質の高い UX を作り上げる技術と経験の蓄積
「ユーザー体験」を作り上げるためには、機能の拡充に加えて、フロントエンドのエンジニアリングも非常に重要になってきます。Kaizen Platform ではあえて標準のフロントエンド技術などを決めることなく、フロントエンドエンジニア陣の自主的な技術チャレンジを信頼して任せています。結果として、React や Angular が混在していますが、不思議と開発はカオスになっていません。 フロントエンドはモノリシックになって肥大化しがちで、新しい技術を試しづらくなりますが、小さく作って分割していくことと、エンジニアの受取性による技術の蓄積によって質の高い「ユーザー体験」を作れる能力獲得を継続的に行っています。
Kaizen Platform のエンジニアとして求められるもの
求められるもの
Kaizen Platform のエンジニアに求めたいもの、それは以下になります
- 「エンジニアリングを通じて実社会に価値を届けたい」と思っていただくこと
- チームを愛し、それを実現できる技術を仲間と共に積み上げていくこと
- 恐れや諦めを持たずに、未来に対して常に前向きに努力すること
※ UX を実際に作るエンジニアのみを求めているわけではありませんし、この 3 点を心に留めてチームに貢献してくれるエンジニアであれば、得意な分野は問いません
今まさに Kaizen Platform は「フェーズ4: UX期」に足を踏み入れようとしています。これは当然私一人後からでもできませんし、皆さん一人の力でもできないと思います。チームとともに苦しみながら笑いあって一緒にみんなでレベルアップしていきたいなと思います。
それは皆様自身の成長と市場価値につながると信じています
繰り返しになりますが、「フェーズ4: UX期」に到達して初めて今後の市場においてもエンジニアとしての価値を証明できると思っています。というのも、このエンジニアリングの進化は産業の成熟によって自然と要求されるようになってくる変化です。どの産業や分野でも必ずこの変化はやってきます。
具体例を示します。ガソリン自動車を作る産業分野には現在「スーパーエンジニア」と呼ばれる人はいないんじゃないかと思います。おそらく最後のガソリン自動車業界のスターは、ポルシェなんじゃないでしょうか。でも優秀なエンジニアはたくさんいて良質な車とその体験を作っています。
現在の社会を見てみると、様々なサービスや開発Kitが無料もしくは安価に提供されるようになってきています。そんな中で企業が既製品ではなくカスタムメイドのソフトウェアを作る理由とはなんでしょうか? それはまさに「ユーザー体験」を作り出し、その優位性によって成熟した産業の中で勝ち残っていく為です。
つまり、この領域に達しないチームや開発者は生き残っていけない、と考えています。
一時的に産業の発展が未成熟な分野は残りますが、その分野が成熟していくのは時間の問題です。そういった分野で頑張るのもとても楽しいと思いますが、今後どんどん成熟していくエンジニアリングを取り巻く環境の中でも陳腐化しない市場価値を、Kaizen Platform で最高のチームを作り上げる中で皆様自身も獲得していただいて、この業界の未来のエンジニアリングを引っ張ってくれるようになったら素敵だなと考えております。
