新プロジェクトを始める前に

以前作ったスライドだが、友人に言われて読み返したら案外いいこと書いてあったのでこちらに写経する。
https://www.slideshare.net/qzuryu/ss-44468259

＊＊＊

以下は、私が「大企業」と「スタートアップ」を渡り歩いて得た、 『スタートアップ』および『新規プロジェクト』をドライブする上での 組織体制やマインドセットの理想型についてまとめた７項目である
# 当然ここで定義する前提がそぐわない業界やその他の exceptional caseは腐る程あるが、ここでは無視する

①柔軟性

ピボットに対する理解
– 全うなピボットはあればあるほど良い
– ただし『ちゃぶ台返し』はやらない（詳細後述）
少数で身軽な人的リソース
– スペシャリストではなく色々なことを広範にこなす人間のみで構成された チーム（理想はチームの全員が仮に誰か独りになったとしても製品化でき るだけの個々の開発能力を持った人間）
プラットフォームを固定しない
– OSやプロセッサ、センサ等のキーコンポーネントのような技術的観点だけ でなく、外注や付き合うキャリアなどをできる限り固めずにプロジェクトを進める

②スピードを重視する

多くのトライアンドエラーをこなし、解決に向けて進むスタンス
 – 別の言葉で言えば「とりあえずやってみる」
仕様書を作る前に実験基板を作り、テストコードを書く
– 仕様書は外部企業とのコミュニケーションを取るためのものであり、内部の承認を得るためのものではない
– とりあえず実験試作が動いたあとで議論を行なえば良い
効果測定があやふやなものに対して時間と金を費やさない
– ウェブの整備、広告、意図が明確でない展示会等への出展、etc.
– そこに費やす時間があったら一行でも多くコードを書き、一件でも多く実証 実験を重ね、ユーザーやその候補や部品メーカーたちとひとりでも多く会話をしろ

③効率を重視する

ディスカッションとブレスト以外の会議はしない
– 報告、共有は普段の会話(in person, in digital問わず)の中でなされるべき
– それが不可能な人数にまでチーム規模を拡大しない
通常の勤務体系の概念を頭から外す
– 優秀なエンジニアは、縛れば年間240日(公務員の勤務日数)きっちり働くが、 縛らなければ365日働く
– オフィスアワー、残業、休出、有休、すべては無いものと考える
– 時給ではなくプロジェクトベースで働く自覚
– リモート、WFH(work from home)を認める。仮にそれでオフィスにひとが集まらなくなったら、そのプロジェクトは既に 死んでいる（むしろ良いバロメータだ）
業務効率化システムの導入はほとんどの場合で効率悪化をもたらす
– みんなが普段使っているツールを使えば良いという単純な解答
– Google App, Evernote, Dropbox, Facebook, etc.

④情報の一元化 

レポーティング経路を極力限定的にする。できれば『必ず全員がレポーティングする人間』をひとり作る
– 情報の分散は大事な時に足下をすくわれる要因になる
– 少なくとも10-20人の組織のうちは可能なはず
– そのレポーティングターゲットのひとはかなり大変だが極めて重要な仕事な ので自覚を持って行なう
定期的に提出させるドキュメントなどで管理しようとするのは管理者の手抜きで あり、トータルではむしろ効率を悪化させている

 ⑤ちゃぶ台返しピボットをしない

ピボットは必要。むしろ重要。しかし『ちゃぶ台返し＝全部リセット』は時間とお金 の無駄を肯定することになる
– 当然それをやっても構わないが、それは、部門を解散し、責任者が責任を 取るときであって、その後、上手くいくかもしれないが、それはもはや別会 社、別プロジェクトである
– しかしだからといって「どうにか妥当っぽいピボットをひねり出す」という姿勢 はまた間違い。その時になって考えている時点で遅過ぎる
健全なピボットが行なえるように①で挙げた柔軟性を真剣にキープする
– 常にオプションをいくつか明確にした上で行動する
– どうせプロジェクトが進み出したら視野狭窄になるのが目に見えている。な ので気にし過ぎるくらいでちょうど良い

⑥化学反応

チームは極力別々のルーツやキャリアを持った人間を集める
– 業界が違う人間が会話するだけでシナジーが生まれる（某スタートアップの 中ではそうやって成長した）
チーム発足後はチーム内での化学反応の醸成に力を注ぐ
– ネットワーキングイベントとか確かに盛り上がるのでついついやってしまうけど、とにかくまず大事なのは内部
ツール選択の自由
– それぞれのメンバーがそれぞれの独自の好みでツールを選択することを推 奨する。そこから生まれる発展性は結果的に組織の資産となる

⑦深く考え、深く作り込むな 

仕様については深く考える必要がある。リリース後の仕様の大転換はほとんど の場合で負けを意味する 
しかし作り込みを深くしてはいけない。それは『ブランド』があるものたちの領分 でありスタートアップには不向き
– 「悠久さを持った市場」「ライバル不在の状況」の場合だけ許される。しかし その手の市場でスタートアップが成功した例など無い
– 考えるのはタダ。でも作り込みには金も時間もかかるんだぜ
作り込みに時間をかけた割に完成度がイマイチで撃沈した例は数知れず
また一方、ローンチ当初は「オイオイ何だコレw」だったのが徐々に市民権を得て 最終的にはデファクトスタンダードまで上り詰めた例も数知れず