枯れていない技術の垂直投下

こんにちは。
ココナラでハイパーメディアクリエイター見習いとして働いている首藤と申します。主に新規事業開発を担当しており、いつの間にか開発陣の中でも最古参となっているお局的存在です。

今回は人生初の会社ブログエントリということで、僕が新規プロダクトを作った時や(社内的に)新技術を採用した際に感じたこと、その際に必要となった「覚悟」についてのお話をしたいと思います。
僕自身、技術者としてはう◯こだと思っているのでただの妄言だと思ってテケトーに読んで頂けますよう。

ゆっくりと片足に重心をかけていく外国人の女性インストラクター [モデル:モデルファクトリー]

さて、少しばかり予防線を張らせて頂いたところで本題です。

はじめに(自己紹介)

ココナラはスキルを売り買いできるオンラインマーケットプレイスということで、Web版とモバイルアプリ版を提供しています。僕が入社した当時はまだエンジニアも4名しか居らず、モバイルアプリもいわゆるガワネイティブと言われるWebViewコンポーネントをベースとしたAndroidアプリしかありませんでした。

今ではエンジニアも数倍になり、できることも増え、役割も細分化されて、僕のような「ひろ〜くあさ〜く」的な存在は自然と0 -> 1的なポジションに突っ込まれます。
まぁそれでいいんだと思います。モチはモチ屋が一番ウマいんですから。

そんなことなので、僕はココナラの衛星プロダクトとでも言うべき、「ココナラ法律相談」や「ココナラハンドメイド」、ココナラ出品者プロフィールサイトなど、主に本体と呼ばれるもの以外(社内ツール除く)のプロダクト立ち上げに関わってきました。

立ち上げては少し運用してバトンタッチみたいなイテレーションを回し続けたココナラ人生となります。多分、沢山の人々からのヘイトを稼いでいます。

既存ビジネスの成長に伴うジレンマと新規事業

新規プロダクトを作るということは当然のことながら会社的な文脈から言えば完全なる投資です。いろんな難しい係数を勘案してこれはイケそうだとか経営メンバーが判断したら、さぁ、ものづくりのはじまりです。

こと弊社のような企業が投資する最大で最長のコストは人的資本でしょう(経営のことはよくわからないので多分です)。

企画→デザイン→開発みたいな一連の流れには少しの電力と多大な人力がかかりますが、新規プロダクト開発というのは既存プロダクトの機能改修と比較して、支払うべきコストが当事者の想像の範囲を余裕で超えてきます。これは僕自身の見積もりスキルの無さということにも起因しますが、それを抜きにしてもそれなりの覚悟が必要というのが個人的な感想です。

そんな新規プロダクトづくりに関わっていると、やりたくなってくることがあります。

それは(社内的に)新しい技術の導入です。

既存プロダクトを運用していると、当然のことながら定期的なアップデートをしない限り使用している技術が古くなっていくことになります。

しかし、会社の成長期においては得てして技術のメンテナンスよりもビジネス的な都合の方が優先度は高いものです。

すでに動いているものに対して、パフォーマンスの改善やセキュリティの向上、技術的な新機能の利用のためなどのあまり目に見えない改修はビジネス的な説得力が薄く、大事なのはわかっているけどそれよりもまずはこの機能の実装を、となるのが世の常です。

技術的な正しさの実現とビジネス的な優先度というのは必ずしも時間軸が一致するものではないのです。

ココナラは正直に言うとそんなジレンマをダイレクトに抱えたまま今に至っています。

それを人々は愛憎を込めて「負債」と呼びます。

そして、人の子であればみんなそんな借りを返したいものです。特に日々それらを直接触る技術者であれば尚の事でしょう。更に、こういった負債はある臨界点に達すると技術的な範疇を飛び越えてビジネス的な足かせとなって経営計画に影を落とし始めます。

(技術者も含めて)人々はこの頃やっと気付き始めます。これは全社的な借金なのだと。

しかし、この頃になるとプロダクトは大きくなりすぎているため、当然のことながら作り直すにも容易ではなく、部分的に引き剥がすにも影響範囲が掴みにくいというような状況に陥ります。

そうなると新技術の導入はおろか既存技術のアップデートさえも簡単ではなくなってきます。
それを実行するには技術者自身はもちろんのこと、ビジネスサイドの人間もある一定の覚悟を持たなければなりません。

そんな経験を見聞ではなく実体験として踏んでくると、新規事業開発などのまっさらな環境に放り込まれた時にやりたくなるのが、(社内的に)枯れていない新しい技術の導入です。

「社内的に」と括弧付きで書いているのは、世の中では枯れていたりするけどウチでは使ったことがないので「枯れている」なんて大手を振って言えるほど安定して使うことができないという意味です。

そうなんです。この「新規プロダクト」と「新技術」というのは相性がいいのです。
相性がいい。相性がいいのです。

一見ね。
だってそうでしょう。「新しい×新しい」なんだから相性がいいに決まっている。
この一見すると相性がいいというのがミソです。自他ともに説得力があります。

新技術導入時によくみるシーン

実はここに大きな落とし穴があります。「当然だろ」と思える人は少なくとも僕からしたら優秀な人です。僕は愚かな人間なのでこの穴を見ることはできません。しかも毎回。

負債と向き合うことに疲れている人間にとって、「新しい」という言葉の響きはそれだけで福音です。

新しい企画書、新しいデザイン、新しい開発環境、新しい設計、新しいライブラリ、どれをとっても美しい。そこには自分や他人が作った借金などなく、ただただキラキラしたものを積み上げていくだけです。 みんながみんな、「ぼくのかんがえたさいきょうの〇〇」を思う存分に入れられる場所。それが新規プロダクトというものです。

そして実践するのです。
新しい〇〇を導入します。
フレームワークやライブラリのドキュメントにはSuper easyだのVery simpleだの美辞麗句が並んでおり、サンプルアプリを弄ってみても「これはヤベェ…」の感想しかありません。

だってそのライブラリのリポジトリで公開されているサンプルアプリはスーパーにシンプルでそのアプリにベリーフィットしているから。

そんなこんなである一定の技術検証を終え、いざ本格導入となります。たいてい最初の頃は順調です。ある程度の学習や技術検証を終えているので、その時に踏んだ地雷やコツなどが活かせます。こういう機能を実装予定だからこれとこれの関連を検証しておこうなど、ある程度の予測はできているからです。

しかし、プロダクトは生き物です。成長するに従って必ず反抗期がやってきます。

「Aを解決するためにBという技術を導入したのに、Bを使ってCを実現するためにはどうしたらいいんだ?」

とか、

「これが思うように動かないけど、使い方が間違っているのかライブラリのバグなのかよくわからん??」

とか、そもそもドキュメントにないし、issueあがってるけどまだ返答ない…
というようなシーンにちょくちょくぶち当たることになります。

「考慮漏れ」と一口で言ってしまうこともできましょうが、そんな「考慮」をどのくらい完璧にできる人が居るでしょうか?もちろんどこかには居るでしょう。でも我々にそんなカードはありません。

プロジェクトメンバー間でもこの認識の齟齬というのは発生します。

非技術者含め全員で合意したつもりでいた新技術の導入が、「聞いてたんとちがう」というシーンは必ずやってきます。そして「俺は最初から違うと思ってた」マンが出現しはじめます。これは他人だけでなく、自分の心の中でも起きます。

仕方のないことです。
人間は未知なるものや自分の理解が及ばないことに対峙すると好奇心よりストレスの方が勝るものです。

そうなると、ことその中心に居る人物はやってしまったことに対して「アンダーコントロール」だと言い聞かせ、中心から遠ければ遠いほど、それって本当に必要だったの?という消極的な客観視をするようになります。
説明不足なのでは?とか共有不足なのでは?とか言われそうですが、多分、幾ら丁寧にシェアしたところで限界はあります。にんげんだもの。

そして、こういった状況への目線の違いがプロジェクトに関わる際のテンションの違いというものにも反映されます。どちらが良いとか悪いとかを述べているのではありません。そういう現象を見てきたというだけです。

余談ですが、こういったことは新技術の導入だけでなく新規プロジェクトの展開や新機能の実装、新制度の導入など、「変化」の起こるシーンで多かれ少なかれ発生するようです。

f:id:coconala_Show:20190116161752j:plain

それでも僕は新技術を導入する

このように、(社内的に)枯れていない事物を仕事に投入すると、大なり小なり混乱が生じるというのが僕の実体験です。

自分自身や他の誰かに知見があればればそのようなことにぶち当たる確率は低くなります。しかし、我々はまだまだ知名度があるわけでもなく、会社の規模も大きくなく、技術的に尖っていることをやっているわけでもないので、先導してくれるようなスーパーエリートを抱えるようなことはできません。(社内的に)新しいことをやろうとする時には自らが泥臭くその知恵を獲得するしかありません。それには当然のことながらそれなりのリスクと苦労が伴います。

それでも僕は、次のプロジェクトでも(社内的な)新技術の導入を検討し導入します。

なぜか?

それは「新しい」ものが美しいからではありません。

ビジネス的な優先度と技術的な正しさの足並みをなるべく揃えたいからです。

ビジネスは日々成長します。技術も日々進歩します。ビジネスだけ成長して、技術が進歩しない、ということはありえません。その逆も然りです。ただし、先に述べたように時間軸的にはズレが存在します。

そこが同時ではないのは、ビジネスがあってプロダクトがあり、プロダクトがあってビジネスがある、というような関係だからです。同時並行的にすべてが進捗するということは、多分ないんだろうと思います。

会社の成長期にはビジネス的な都合の方が優先度が高くなるのでそういうズレが大きくなりやすいのだと思います。そしてそのズレを埋める作業をどこかで、何かでする必要があるのです。

あの技術を使えばこんなに苦労することはないのに、なんていうシーンはイヤというほど味わってきました。

そして、その技術を導入しかけたはいいが、結局既存の構成にフィットせずに使用を諦めたということもあります。

だからこそ僕は、地雷を踏むとわかっていながら「新しい×新しい」を実践し続けます。

「新しい×新しい」の実践は「古い×新しい」よりも多くの予想外なストレスを生じさせます。

なぜなら「新しい」の二乗なので不確定要素がその分多く、想像の域を超える問題が次から次に襲ってくることになるからです。それでも「新しい×新しい」を実践し続けるワケは、そこでしか成しえない大きなチャレンジができるからです。

あたまからっぽのほうがゆめつめこめる」メソッドです。

チャレンジをするということは失敗を許容することです。

失敗を前提にしてチャレンジするバカはどこにも居ないですが、成功確率が少なくてもその先に価値を見出だせるからこそ挑戦をするのです。しかし、既存プロダクトでは大きな失敗はできません。なぜならそいつが稼ぎ頭だからです。とてもリスキー。そういう文脈になると新しいプロダクトでのリスクテイクが比較的許容されるのは想像に難くないと思います。

新しいことを始める時に、社内的にも「枯れた」技術を採用するのはとても効率が良いし、正しいことだと思います。行儀が良い。
何も間違っているとは思いませんし、僕の考え方のほうが正しくないでしょう。

しかし、現実問題として、肥大化して機動力の衰えたプロダクトに新技術の導入や大幅なアップデートを施すのには多大なコストがかかります。新しい技術を比較的ローリスクでテストする場所は、新しいプロダクトがなんだかんだでちょうど良いのです。そしてそこで得たノウハウは失敗を含めて大きな財産となります。

僕が新技術を採用する際に必ず考慮することは、今後「社内で枯らすことができるか」と「覚悟を持って付き合えるか」です。

新規プロダクトに関わる人間が少なく、自分しか触れないために属人化を極め、残念ながら朽ちていったプロダクトは正直あります。 技術選定を間違えたと後悔して枕を濡らしたこともあります。
スケジュール遅延などで色々な人に迷惑をかけたことも多々あります。嫁にも散々怒られました。

それでも、覚悟を持って挑戦したことにはそれなりの道理があったと自負しています。

自分本位に進めることは言語道断ですが、ある程度の思いやりと最終的には自分でケツを拭く覚悟があれば、なんだかんだモノはできあがるし、全社的にもその後の選択肢は大きく広がります。

今ココナラは抜本的に全体のシステムの見直しを行い、新たなステージに立とうとしています。

そして今までしてきた新規プロダクトでのチャレンジで得た経験が、色々な場面で活かされようとしています。きっとね。

負債がないプロダクトなんて存在しません。
穴があったら埋めて、前よりも多くの土を盛ってやればいいのです。
そしたら近くに次の穴ができるけどまた埋めりゃいいんです。
商売なんてそんなもんです(てきとう)。

何を言いたいのか意味不明でしょうが、僕と一緒に新規事業に取り組んでくれるUIデザイナーを募集しています。エンジニアも。
( `・∀・´)ノヨロシク www.wantedly.com

www.wantedly.com

www.wantedly.com