takaking22

エンジニアリング

担当サービスの開発／運用の執行責任 ・サービスを安定稼働させること ・サービスの未来を見据えたアーキテクチャの選定 ・エンジニアリング観点での判断

エンジニアリングはどうしてもHow（手段）に行きがちだが、 ・Why（どのような目的で開発／運用するのか） ・What（どうなりたいのか） ・Who（誰が開発／運用するのか） ・When（いつやるのか） を共通認識にすることが重要だと考えた。 多くのチームで、 ・ビジネスと開発というセクショナリズム ・プロダクト要件だけを満たし続けた膨れ上がったシステム ・身の丈にあっていないシステム などの問題が起こっていることが多かったが、まず最初にやることは「やることを減らす」ことが多い。 何をするにしてもただでさえ忙しい状況に加えることは難しいので、やることを減らしてあいた隙間を使って新しい施策を入れていく。 方法はケースバイケースになるが、手っ取り早いのは自動化（特にデプロイやテストはROIが高い）、時には政治（やらなくていいことをやらなくていいようにする）を使って隙間を作った。

チーム（ヒト）

事業目標を達成するチームをつくる／マネジメントする

つくったチームをどうやって残すかを第一に考えた。 企業内スタートアップのアンチパターンとして、 ・その時に手が空いているリソースなどを集めてチームをつくる ・スタートアップしながらチームもビルドしなければいけない ・事業が終了する際はチームを解散する という問題がよく起こっていた。 毎回スタートアップしながらリソースを集めたり1からチームビルドしていくのはムダが多い上に、せっかくいいチームをつくってもプロダクトがダメになったときに解散になってしまってはもったいない。 なので、空いているリソースではなく自分が信頼するメンバーを1から集めて、最初から売り上げを立てるリーンスタートアップチームをつくった。仮に事業方針などでプロダクトが頓挫したとしても、そこまでにチームに溜まった学びや実績によってチームを残す理由がつくれるようにという意図が強い。 これまでの経験を通して、プロダクトが成功するかどうかはやってみないとわからないことはあるが、確実に失敗させることはできるように感じる。スタートラインに立つためにもよいチームをベースにするのが一番である。