クリスマスなリア充すら羨む幸せを手に入れるため、新規事業に携わるエンジニアが持つべき12つの心構え

『LITALICO Advent Calendar 2016』最終日の記事です。

株式会社LITALICOでエンジニアを中心に何でもやります@kamesenninです。
クリスマス公開に向けて、クリスマスイブに1人で記事の推敲をしました＠スタバ
二度と12月24日、12月25日の担当はやりません。

どうぞよろしくおねがいします。

はじめに

私は2012年にLITALICOへエンジニアとして入社し
リアルビジネス〜ネットビジネスまで、細かく分けて8つ新規事業に携わってきました。

• 発達障害領域のwebコミュニティ（クローズ）
• プログラミングを中心としたものづくり塾
• 発達障害領域のコミュニケーションサポートアプリ（クローズ）
• メンタルコントロールを目的としたアプリ（クローズ）
• うつ症状の予防・回復 再発防止をサポートするSNS
• 幼児育児領域のwebメディア
• 発達障害領域のwebポータルサイト
• 幼児育児領域のアプリ

基本的に新規事業立ち上げの際には
「いろんな業界の最前線で活躍されてきた方」が弊社に転職し、私の上長となり
未熟で非戦力な私を、温かい目で見守って頂きながら、何とかやってきました。

ただ結果、エンジニアとしては
リアルビジネス〜ネットビジネスまで
多様な業界の方々と事業立ち上げをやってきた経験
を積めて、恐らくその経験は珍しく
「そこで得たエッセンスを世の中に伝えるのは価値になる」のでは
と思い掲題のようなテーマにしました。

具体的には

「エンジニアがこう動いた時って、事業がぐっと前に動き、関わるメンバーが幸せそうで、皆も成長したなあ」
「エンジニアがこう動いた時って何だかチームの雰囲気もプロダクトの成長もイマイチだったなあ」

と感じた点を思いつく限り

• アンチパターン（悪例）
• デザインパターン（好例）
• まとめ

という観点で
「インターネット事業の立ち上げ」を想定してまとめました。

それでは張り切ってどうぞ。

1. まずは「メンバーからの信頼獲得」と「すべきこと（KPI達成）をしきること」から。その後にいくらでも好き勝手したらいい

アンチパターン（悪例）

• ex. 働く時間帯や予算の決算へのハードルが高くて面倒くさいなあ。もっと自由にやらせてくれ
• ex. なんでこんな定期的に進捗共有せないかんのだ。ちゃんと進んでいるのに
• ex. すべきことは分かるけど、ちょっとやりたいことあるから、半日くらい使っちゃおう
• ex. いつもスケジュール通りに開発が進むと思うなよ
• ex. 多少バグはあって当たり前だろ

デザインパターン（好例）

• ex. 時間を守る。間に合わないこともあるが、それ自体は仕方ない。分かり次第すぐに状況を伝えることで、スケジュールへの信頼感が高まる
• ex. 進捗を、中途半端でもいいから、言われずともこちらから定期的に見せることで、進捗への信頼感は高まる
• ex. 細かな想定外のバグは仕方ないし起きうるが（非エンジニアの人もここは寛容に）、動かねば成り立たないバグは0にする。皆に見せる時には「どこは確実で、どこにはバグがあり得るか」を伝えることで、相手は安心してテストが行え、結果信頼感は下がらない。
• ex. あなたがしたいことよりもKPIの達成に必要なことを最優先させることで、誰も文句の言いようがない自由な時間が手に入る

まとめ

• 結局、事業が収益化していないと何も始まらない。それが大前提である認識を持つこと。
• 新規事業は投資の部門であり、お金を稼ぐまでは、技術的向上云々よりも、事業の成長にコミットメントするのが社会に誠実な行動
• 上記が上手く回っていない = みんな不安でいるのに。自由な時間や機会を求めるのは新規事業に関わる人材としては不適切
• よって、早く事業的結果を出し、その中で信頼を積み重ねて「自由にやっても大丈夫そうだね」と如何に早く皆に思われる環境を作るかが重要で、そうなってから、ようやくいろいろ自由に出来る時間が始まる
• そして、その自由度は我々の実力に比例する（技術力 × ビジネススキル）

2. どの組織にもあてはまる絶対的な開発プロセスやルールは存在しない。過去の経験や流行りに固執をしないこと

アンチパターン（悪例）

• ex. 今時はアジャイルでtrelloでゴリゴリいくでしょ
• ex. 非エンジニアもgithubくらいすぐ使えるようになってよ！全部githubでいこう
• ex. いやもうやっぱとりあえずスクラム開発でしょ

デザインパターン（好例）

• ex. 開発スタイルは、時にはウォーターフォールが良いだろう。時にはアジャイルが良いだろう。
• ex. PJ管理は、時にはtrelloが良いだろう。時にはredmineが良いだろう。時にはspreadsheetが良いだろう。時にはgithubが良いだろう
• ex. ドキュメント管理は、時にはgoogledriveで十分だろう、時にはconfluenceが良いだろう、時にはgithubが良いだろう

まとめ

• 過去のあり方や今の流行りに乗っかっても、結局使うのは人で、道具に人が合わせに行くのは効率が悪く、余計な所でストレスが貯まり、うまく回らなくなる場合が多い
• メンバー全体のITリテラシー、能力、思考性、プロダクトの必要な管理範囲によって、進め方を柔軟に変える方が上手く回ることが多かった
• 変数に応じて、最適なプロセスを設計できるのが良いチームであり、プロセス設計の知識を一番持っているのエンジニアである場合が多いので、そこの設計にもコミットメントすることで、皆幸せになれるプロセスが生まれる可能性が高い
• 沢山決めすぎるよりも最小限のプロセスから始め、後は定期的にチームでKPTでもしたら良い。そこでルールを調整すれば大体大丈夫

3. 自社プロダクトや設計の悪口はLTやブログのネタにとっておくこと。過去のアウトプットはだめに見えて当たり前

アンチパターン（悪例）

• ex. なんだよこの設計、データ取りづらすぎるでしょ。
• ex. id入れるカラムをvarcharにしてんじゃねえよ
• ex. なんでこのメソッド2,000行もあるねん。めんどくさっ
• ex. なんのために存在するページなの？何のために置いたボタンなの？
• ex. だれこのページ設計考えたの？要らないでしょ？頭悪すぎない？

デザインパターン（好例）

• ex. 「この部分を、こんな風に良くしたら、これだけの工数削減や、サービス改善に繋がった」って建設的な発言と発信は、必ずみなを幸せにする
• ex. 面白すぎる設計やコードは、LTやブログでアンチパターンとして紹介、こうあるべきだを世の中に発信することで、社会全体のプロダクトの質が上がって、組織の枠を越えてみんな幸せ
• ex. 今そこにある要らなそうなデザインやシステムって、実は今後のサービス改善のプロセスに生かせないか？って考えると意外に生かせる場合が多い。だから今の不満ではなく、未来の可能性に視点を当ててみて。
• ex. とはいえユーザー体験を著しく阻害して、すぐに対応出来るなら消した方がいいけど

まとめ

• 批判した対象の先には、それを作った人がいて、知らぬ間に傷ついている人はいて、気づけばチームの士気が下がっている場合が多い。かつ傷ついている人はそれをわざわざ口には出さない（出せない）
• 我々は成長しているはず。ならば振り返ったものがだめに見えて当たり前。むしろ昨日のものがだめに見えなかったら反省して
• よって「自身の成長」と「過去への文句」は基本的に比例する
• いろんな企業のエンジニアと話すが、すごいプロダクトほどコードやDBが酷いって話を聞く頻度が高い
• だからって適当にコードを書いたり、プロダクトに向き合ったりするのはNG

4. 理想的な形とプロセスをイメージ出来るエンジニアが、妥協点を探せる姿はとてもカッコいい

アンチパターン（悪例）

• ex. そのシステムを作るには普通こんだけ時間かかりますから
• ex. そのスケジュール感だと、中途半端な設計やシステム構造になって美しくないからヤダ。時間を伸ばすべき。
• ex. 経営陣やビジネスサイドはエンジニアのことを理解していない、何を考えているのか全く分からんから、自分たちに決めさせるべき
• ex. このシステムを作るには、この設計がベストで、そのプロセスはこれがベストだから、何が何でもその通りにすすめるべき

デザインパターン（好例）

• ex. エンジニア出身でもない限り彼らは技術のことを理解しづらいから、彼らとちゃんと議論をしよう。エンジニアから経営の状態を把握し、事業全体で今最も優先すべきことを理解すること
• ex. すると新規技術の導入ではなく、慣れたRuby on Railsでやるのが経営的にベストである場合は結構あって、それが見えたら、それを選択すべきである（短期的には事業が成り立たないと、給料も支払われないし、会社も成り立たないし、結果好きな開発も勉強も出来なくなるから）
• ex. システムの設計やコードの状態が中途半端に終わる場合があるかもしれないが、時間軸と最低限の動作軸の基準を満たせば、リリースを優先すべき場合も結構ある。リファクタリングの方針、最低限整えておくべき所の基準を作るのは難しいが、その基準と向き合い精度を上げがなら進める絶妙なバランス感はすごく美しい
• ex. とはいえ中長期的な会社、事業の成長を考えると、新しい技術へのチャレンジをはじめとして、事業的にはベストじゃない時間の使い方も必要になるから、それは別の機会に作ろう。CTOがいるなら、お願いしといたら、多分なんとかしてくれる。

まとめ

• 「短期的な事業の最速成長に必要な技術」と「エンジニアの成長」は多くの場合相関しないことを認識すること
• ただ、「中長期的な事業の成長」には「エンジニアの成長」が必要で、そこに投資する経営判断は必須だが、それは一定事業が立ち上がって、中長期的な戦略を考えるタイミングでようやく。だって事業がないと会社が成り立たないことを認識する音
• この絶妙なバランスをエンジニア側もビジネス側も理解すること。その理解がないと無駄なブツかりやコミュニケーションが生まれる

5. まずはちゃんと作らなくても出来る方法から。最速で出してユーザーに聞いてみよう。大体みんな作りすぎている

アンチパターン（悪例）

• ex. 工数むっちゃかかるけど、効果はかるために優先度高く頑張って作ろう
• ex. でも結果全然効果でないっすね…
• ex. 効果、出てるっちゃ出てるか…だからOK！（でも本質的な価値出しているのはこの僅か一部で全部やらなくても良かったね…）

デザインパターン（好例）

• ex. 「良改善か悪改善かのABテストはできるだけ少ない工数ですべき」って前提をまず理解すること
• ex. しっかり作るのは、その開発が良い方向に向かうと仮説の精度を可能な限り高めてからやるのが最も費用対効果が良い進め方。そのためには最小限でテストするには何が出来るかを、エンジニアが広い視点とクリエイティブな発想を持って関わることで生まれる
• ex. htmlベタうちだって、データベースもなくてもいい場合も結構あるし、sketch × prottだけでテスト出来る場合も往々にしてある

まとめ

• 頑張って作ってABテストするんだけど、実際そんな頑張らなくてもテスト出来たよねってパターンはこの1週間を振りかえると必ずといっていいほど1つ以上はある。
• 出して使ってもらわないとその正しさなんて分からない。自分が作ったシステムがどれだけ美しい設計とコードで出来ていてもユーザーに不必要ならそれは不必要で、消さなければならない場合がほとんど。それはスゴクカナシイ…
• 「3営業日がんばって作りきって検証するよりも、0.5営業日でさくっと出して検証をする」ってそのスピード感の積み重ねが、他社の追随を許さない競合優位性になる
• 明確な効果が見えたら、ちゃんと設計して、じっくり作る。

6. KPIとその進捗って今この瞬間言える？言えないなら一旦開発の手を止めて理解して

アンチパターン（悪例）

• ex. 進捗なんとなく進んでいそうだね（遠い目
• ex. KPIなんだっけ?えっと…大体こんな感じだったかな…
• ex. ちょっとこの辺かえたら使いやすくなりそうだから作ってみよう。今のこの機能使いづらいし美しくないから変えよう（って何となくの雰囲気で優先度決まってる感じ

デザインパターン（好例）

• ex. 今その瞬間、「KPI」と「その進捗」言えない場合は開発をSTOP。すぐに確認、あるいは決めて、現状の把握をして、すべきことと意思決定の基準を整理すべき

まとめ

• KPIを設定して、每日確認する、これが出来る人は思っている以上に少ない。でもこれをするだけで一気に事業はスムーズに進む。本当に。まっすぐ1つの事に向かう意識がないと組織はブレる。
• 今その開発やタスクはKPIにどの程度影響があるのか、を網羅的に判断できる人ってエンジニア以外にあんまりいない（たまにいるけど）から、エンジニアがKPIと進捗を理解しておくことが、たまにわずかな違いを生んで長期的には大きく事業の成長角度を変える
• 多くの場合、一番プロダクト改善の手段を知っているのがエンジニア。よって、数値への意識やヤバさも一番持っておくことで、より早い改善が見込める可能性が上がる

7. エンジニアが事業全体を把握し、プロダクト開発を推進していない時、その事業の成長スピードは落ちてリスクは積み重なっている

アンチパターン（悪例）

• ex. 特に優先度高い開発いま降りてきていないね。うん。どうしようか。
• ex. 誰か全体像をきっと描いてくれるから、それを待っていよう
• ex. エンジニア以外の動き？営業やマーケやCSが何やっているか知らないなあ

デザインパターン（好例）

• ex. 一番手段（工数、費用対効果）を知っているのはエンジニア。自分がプロダクトを成長させるのだという責任感を持ち、短期・中長期的な成長プランを自ら描き、推進するのが、プロダクトの成長観点で最速（プロダクト開発の推進方法はいろいろあるけど弊社のCTOの記事はすごく分かりやすい）
• ex. ガンガンプロダクトが変わって、オペレーションが整備されていない初めは、プロダクトの状態で他の役割の人の動きもベストな意思決定基準もどんどん変わる。マーケの投資や営業の売り方などで当初の前提と違ってきている場合が起きる可能性はかなり高いので、プロダクト以外への影響を網羅的に考えられる人は必ず一人は必要でそれはエンジニアであるべき

まとめ

• 事故ったり、モメゴトが起きるときは、プロダクトの現状と皆の認識がすりあっていない場合がかなり多かった
• 営業も、マーケティングも、Bizdevも結局はプロダクトありきでいろいろ決まる場合が多い。その辺までキャッチアップしにいける人がプロダクトに関わるエンジニアのトップだと、事故も少なくって、いろいろうまく回ると思う（オペレーションが整っている所は無視してok。だけど新規事業でオペレーションがクオーターの範囲を越えて落ち着くという現象はめったに起きない）

8. 大きくも小さくも、全ての機能で日本一を目指す

アンチパターン（悪例）

• ex. フォームは多分一般的にこんな感じで、こんなもんの数値が出れば一般的で良さそうだ
• ex. このページはまぁ大体このくらいなら他社に見劣りはしないよね

デザインパターン（好例）

• ex. 日本一のCVRを持つフォームを作ろうぜ！
• ex. 日本一のCTRを出すリスティングを作ろうぜ！
• ex. 日本一使いやるいヘッダーにしてやろうぜ！

まとめ

• 日本一って目指すと本当に簡単に達成してしまう。3ヶ月向き合えばかなりの所までいけるってくらい意外とハードルが低くって、その姿勢はプロダクトのクオリティをあげて、自身のスキルを大幅に上げる
• もちろん時間との兼ね合いもあるけど、基本まずは日本一を目指す。限られた時間での達成に頭を使うべし
• 時間の制約で実際に本当になれるのは少ない。でもその視点を持っている事がとても重要

9. 誰よりも沢山プロダクトを触って、競合のPMやエンジニア以上にそのサービスに詳しくなってやるって気概と行動が、センスをぐっと高める

アンチパターン（悪例）

• ex. 世の中のサービス？知らん。あんまり。自分はゲームアプリを使うくらい
• ex. まぁいちおう一通り触っているけど。うーん。違いは分からないねえ
• ex. あのサービスの画像ファイルの取り扱い方？そんな所まで知らないよ

デザインパターン（好例）

• ex. 世の中の一流を沢山知ろう。なぜ良いか、どこが良いかまで考えるべし。
• ex. 言語何？、このmarginって何px？（material cue便利）、サーバー何？
• ex. 画像どうやって読み込ませている？タップした後の挙動は？何をどこまでキャッシュさせてる？
• ex. なぜここはこうなってる？先月とくらべて、どこが見た目とシステム上で変わっている？
• そこまで踏み込んで他社のサービスを知るべきで、深く細かい積み重ねが蓄積された結果、自分だからこそのユニークアイディアにつながって、良い悪いの判断の精度がどんどん高まる

まとめ

• 私もアプリ200個くらいは常に入っていて、削除追加を每日繰り返して使っています。
• 未婚のメンズですが、ルナルナ、妊娠カレンダー、ninaru、ラルーン、mary、mamarmi、子育てハック、等など一ユーザーとして使い倒して、技術的なアレを使って探りを入れまくってる
• ユーザーインタビューだけでは見えないユーザーの生活習慣やついサービスを使ってしまうキモなどがスゴく良く見えてくる。そこから出た施策ってヒット率がとても高いという認識

10. プロダクト開発が今すべきことじゃない場合もある。みんなの業務プロセスにも時には目を向けて

アンチパターン（悪例）

• ex. とりあえずガンガンプロダクト開発行こうぜ！！
• ex. みんなどんな仕事してるんだろ、
• ex. 効率悪いことばっかみんなやってるように見えるけど頑張って…

デザインパターン（好例）

• ex. スプレッドシートの表計算で困ってる人は沢山いる。1時間を1分にできる事も往々にして有る
• ex. よくわからない業務をしている人もたくさんいる。たまには会話してキャッチアップして、自動化して、やり方をインプットしてあげて
• ex. SQL（select、where、join、limit、order by、count）やexcel関数（countif、sumif、vlookup、unique、average）や最低限出来るようにすると良い。BigQueryなど使って土台だけ作ってあげたらハードルはぐっと低くなる

まとめ

• 基本的にはプロダクト開発第一だけど、時にはプロセスの効率化が事業全体の推進力を強くすることを大いに知った
• 新規事業で最も大事なのは「事業が最も早く成長して、ユーザーに適切な価値が届くこと」で、その重要な事に向けて、今ボトルネックになっているのがプロダクトの進化なのか、あるいはどこかの業務なのか、それは分からない
• 広い視点で事業全体を見て、自分が今すべきことは？って考えるエンジニアが増えたらみんな超ハッピー

11. 最低限の法務リテラシーと一般的な倫理観（とその変化）を持っておいた方が良い

アンチパターン（悪例）

• ex. 法律は法務がやってるからokでしょ（雑
• ex. 一回定まっているから、後は僕らは気にしなくてもokでしょ
• ex. 法的にはokだから、後は何しても大丈夫そうだよね、ガンガン攻めていこう

デザインパターン（好例）

• ex. 法的にブラックなのはもちろん、グレーな範囲まで把握しておくべき。更に世の中一般の感覚として倫理的にはNGなのかどうかまで感覚を持っておくべき
• ex. サーバーの状態をはじめとして、裏側のことまで皆は把握できない場合がほとんど。エンジニアが法的、倫理的にグレーやブラックな範囲を把握しないと漏れる。という認識をまず持つべき
• ex. たとえば、利用規約やプライバシーポリシーや個人情報の取り扱いの方針に関する文言はもちろん読んでおくこと

まとめ

• 何度も言うが、進化が早くてオペレーションが整いきらない新規事業では、たとえどれだけ法律に詳しい人がコミットメントしていようと、テクノロジーにくわしい人がコミットメントしないと漏れる。それはエンジニア以外には大体の場合が難しい
• もしデータベース周りで漏れていた場合、それは後で、大きなコストを払う必要も出てくる
• 事業の種類によってキャッチアップする法的観点は違うから、業界に繋がりが多い偉い人を使って外部のサービスに運営者に繋いでもらってキャッチアップする（しかない…のかな…

12. みんなのことを思いやって仕事をすること

アンチパターン（悪例）

• ex. 非エンジニアの人との会話ってめんどくさい
• ex. タスク管理も出来なくて、なんなんだろう
• ex. 優先度も付けずに、やたらめったら依頼ばっかしやがって
• ex. みんな効率悪いやりかたばっかしてなんなんだろう
• ex. 技術的な言葉知らなすぎじゃね、まともな会話にもできないし、つらいわ〜

デザインパターン（好例）

• ex. エンジニアは「業務遂行」の世界では多くの他者よりも優秀になってしまう自覚を持つこと
• ex. なので、相手を詰めて話させるのではなく、相手の意図をこちらが言葉にして「こういうこと？」と汲み取る努力をした方が絶対に良い。結果早い。

まとめ

• 働く人も幸せにして、社会も幸せにできるエンジニアが最強

まとめ

技術の学習コストも大幅に下がって、誰でもエンジニアの世界に踏み込めるようになった時代
グローバル化でハイスペックで非高賃金な労働力と競う必要が出てきた時代
などなど、これからの時代、エンジニアのキャリアもまた変わってくると思います。

いろんなキャリアの形が、いろんな所で描かれていますが、結局
社員、関係者、顧客、社会に誠実である。ひろーく周りを見て、思いやりの気持ちをもって仕事ができる
ことが、その人のキャリアの可能性を大きく拡げ、チームを良くして、プロダクトの細部に神をやどらせ、ユーザーを幸せにするんじゃないでしょうか。

私が上記で偉そうに書いた12つの心構えも
結局は「誠実さ」に集約されそうだなと思いました。

最後に

「1つでも社会・業界の発展に貢献出来る情報を発信できれば」
という想いで弊社エンジニア一同初アドベントカレンダーにチャレンジしてきました。

結果全25記事を通して、非常に多くの方に、記事を読んで頂くことが出来て嬉しい限りです…。

非常に多様で優秀なエンジニアで溢れていますので
まだ全部読まれていない方は（99.9%がそうでしょう）
過去の記事も是非ご覧になってください

『LITALICO Advent Calendar 2016』(๑•̀ㅂ•́)و✧