みなさんおはようございます。こんにちは、こんばんは。
オイシックス・ラ・大地EC事業本部CX室開発セクションでAndroid開発をしております。@hiraokです。
去る10-31(金)に浅草橋ヒューリックホールにてEOF2019なるPM,EM,FMの祭典が行われました。
以前から開発者としてのキャリアに不安を感じていたのでマネージャーってなんぞや？どんなことしてるの？
とかいろいろあったので参加してきました。
EOF2019
オープニング・セッション
オープニングでは広木大地[株式会社レクター]氏、湯前慶大[株式会社アカツキ]氏、大庭直人[Quipper Limited]氏
のお三方が会話形式でいろいろお話されてました。
湯前氏が今回は変わったことを試したいということでいきなり周りの方との自己紹介タイムが始まりました。
私がご挨拶した方はお二方おられまして、両人ともWeb開発をなさっている方でした。
周りに聞き耳を立ててみると開発者の方が結構な数おられまして、やはりみんな不安..いや興味があるんだなという印象を受けました。
正しいものを正しくともにつくる
www.slideshare.net
最初はカイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまでの著者市谷聡啓氏のセッションです。
このセッションは、市谷氏の新規事業プロダクトでの経験に基づく内容で構成されており、 ターゲットとしては新規でなにかやるひとがなにやっていいかわからないけどこうやればいいんじゃないかという内容であると解釈しました。
そしてなにより市谷氏には悩みがあり、プロフィールページを作成したけどほとんど人が訪問してくれないという心境を語っておられました。 こちらで紹介することで市谷氏の悩みが一つ減ることを切に願います。 ichitani.com
段階的な選択を
不確実性コーンの経過を段階によって選択肢を絞り込んでいくことがよいそうです。 最初の段階ではなにが正しいのかさっぱりわからない状況なので正しいものがなにかを探す旅に出かけます。（ジャーニーですね） 目的選択の段階であれば繰り返しコンセプトを絞り込んでいきます。その中であれこれ試してわからないことがわかってくるようになります。 割愛しますが、あとは資料にあるとおり段階を踏むことで不確実な要素が減っていくという運びになります。
プロダクトの限界
プロダクトはチームで作っていきましょう。そうですね。確かに。 しかし、プロダクトオーナー周りだけで仮説なりなんなり考えてというのはあかんというのが市谷氏の実体験に基づくアドバイスです。 資料にも記載がありますが、より選択肢を増やすことが重要です。プロダクトの限界をプロダクトオーナーの限界にしないようにしましょうということです。 しかしながら、ステークホルダーが増えすぎると多様性が広がりスライド16にもありますが、カオスな状態になります。
チームで
カオスな減少を防ぐために仮説と検証に重きをおいて、チームで繰り返し行い、実体を掴んで選択肢を逐一掴んでいく方法が良いらしいです。
機動性
多様性はわかった。選択肢は多いほうがよい。チームでやろう。では次にどうしていくかということです。 チームの多様性を機動性でもって掛け算していく方法がよいということですが、機動性とは 迅速に動ける仕組み、多様性をよりよくコントロールしていく（利用していく）ために必要な方法であると私は解釈しました。
市谷氏はそうした機動性を高める具体的な方法を下記のような方法で取り組んでいこうと提示しました。
- 重奏的仮説検証
- ジャーニー・スタイル
- フォーメーションパターン
- 適者生存型アーキテクチャ
それぞれ段階があり、それに応じた戦略ということでしょうか。
具体的な内容については資料を参照したほうがわかりやすいので割愛させていただきます。
まとめとしてチームを回していくために必要な要素は3つ
- わからないものをわかるようにするには選択肢を増やして仮説検証で絞っていくのが最適
- チームの多様性を指向する。（どんな人だろうと多様性として許容するのがよいわけではなく、軸を一本通さないとむちゃくちゃになるので注意
- 多様性に最大限適応するために機動性を高める → きめられたことをやるんではなく、重奏化したり、ジャーニーというタイムボックスをつくるとか
最後に市谷氏はこの開発スタイルをこう締めくくり本セッションの結としました。
リーン・ジャーニー・スタイルと。
感想
市谷氏はカイゼン・ジャーニーという書籍の中でも冒険にでていました。 ネタバレですが、とある人に「なにをなさっている方なのですか」と問われたことがカイゼンのきっかけだったそうです。 セッションを通じて感じましたが、オリジナルを見つけ出すという労力は計り知れないものであるという印象を受けました。 市谷氏が見つけ出した答えは、ジャーニー・スタイルは冒険の中で燃やした情熱の結果なのかもしれません。
大規模開発からスタートアップまで
※公式の資料は見当たりませんでした。
楽天株式会社に所属する河村真氏の前半、後半絹川達也氏、で分けられたセッションでした。
前半は楽天市場の担当の河村氏のお話。
河村氏は前職はソニーらしく経歴つよい方でした。
大規模開発の場合
楽天市場の課題
- 技術的負債
- リファクタより成長を優先する
リファクタする余裕がない
人依存
- ベンチャーでよくある人依存。だれそれさんしかしらないなど。
プロセス解決の方法
- 会社にプロセスを理解している人をいれちゃう
- 強制的に苦しみながらやる。パワープレイ
- コモディティ化→ツールとか気持ちよく使えるレベルまでにする。相当な技術力、マネージメントが必要で単独では困難
プロセスを導入する意義
プロセスのありなしでは結構な違いがある。 プロセスあり→ 初めてジョインした人でもすんなり仕事に入っていける プロセスなし→ 周りの仕事がどう回っているのかわからない。誰がなにやっているか3人ぐらいにたらい回しにされ、本質にたどり着けない。つらい
解決方法
簡潔にまとめると早期解決、早期対策に越したことはないということを力いっぱい説明されてました。
適切な時期でのリファクタリング、プロセススケールする仕組みを導入しなければならず、
プロジェクト・サービスが大きくなってしまってからでは大変になるばかりで、いいところを残しつつ慎重にやらなければいけないとのこと。
それもあって、スタートアップ系にはスピードでは負けてしまうということです。
人
河村氏も転職してまだ浅いということもあり、最初は戸惑うこともあったようです。 楽天という会社は職人気質な感じで、いい意味でアメーバらしいです。（非常に大雑把に切り取りました） しかし、課題として新しい人は困ってしまう環境で不幸なびっくり体験が多いらしいです。 最初の1年が勝負で1年ぐらいはひっそりとして1年ぐらいでやっと波に乗ってくるとのことでした。
最後に
プロセスは地道に作るしかならず、自分たちで気づいて積極的に作っていく必要があるとのことです。 体験しないとプロセスというのはわからず、マネージャーが上からガイドラインをつくるなりなんなりで アクションを引き継いでいかなければならないとのこと。 プロセスは体験した人と一緒に働くか、自分で経験しないとわからないです。→同感 最後に河村氏は、技術的負債は一掃しますということを強くおっしゃっておりました。
スタートアップ系開発の場合
絹川氏はECインキュベーション開発部のGM（GeneralManager）の方です。
セッションターゲットとしては下記を想定しているとのことです。
- 複数小規模サービスチームのマネジメントで苦しんだ人
- マネジメントで複数チームを管理することになった人
- チームを初めて持つ人
方針を決める
チームが求めるものは、ケアするのは個なのか共通なのか。なんにせよ方針を決めることが大事だということです。 絹川氏は個別化と共通化という２つの概念によりケアする方針を定めたそうです。
共通化
絹川氏は一旦すべてのチームのリードマネジメントの方にトラブルの話、リリース頻度の話、プロセスどうなっているのかヒアリングしたようです。 そこで絹川氏は一つの仮説にたどり着いたようです。全てのチームは一定の成熟モデルを踏襲するということです。 そこでチームの成熟度を図るためのプロセスを取り入れたようです。
個別化
絹川氏はひとりひとりを理解していない自分に絶望したようです。 立場が変わることで今までワイワイやっていたメンバーがいきなりよそよそしくなるという現象を目の当たりにした方は少なくないでしょう。 絹川氏もそのような立場で悩み苦しんだようです。肩書が増えても変わらない付き合いって惚れますよね。THEチームって感じがしますね。
取り組み
絹川氏は一人ひとり現場のメンバーと1on1をしたそうです。（すごい体力..）
やはり人間同士、直接の対話が必要であると理解したようです。
その他にもやることは全てやったという感じで、ボトムアップで意見を吸い上げたり、委員会制度など様々。
委員会制度というのはバラバラなチームから一つの共通のテーマを掲げてチーム関係なくそのテーマについて話合うというものらしいです。
kaizenグループという制度もあるそうです。これはグループ会社のサービスにジョインして、入ったチームのプロセスが良くなかったら報告してもらうという内容らしいです。
このように、現場からの課題を積極的にエスカレーションしていく取り組みなんかもやられているようです。
直接言葉を届けること、みんなで決めたことだからそれでいいんだという理解を持つことが大事とのことです。
価値観
人の価値観は多様です。ひとそれぞれによって温度差があります。
あの人はこういってるけどなんかやる気でない、なんでこれやってるんだっけ、なにしてるのかわからないなど。
絹川氏はそうした価値観の温度差を無理やり会話することで乗り越えてきたようです。
価値観を提示し、説得し、エスカレし、不満を聞いてまた戻るという具合です。
変わったこと
絹川氏のたゆまぬ努力、これぞ賜物といったようで、部目標は前期より好調、
退職者・異動者減少、部署イベントの満足度向上という韻を踏む要領で改善に向かったらしいです。
心がけていること
相手を知ることが大事で、どんどんインプットしていこうということです。
また、組織のビジョンを決めることだったり、自分はこう考えているんだけどどう思う？ということを相手に提示したり、それを相手にも提示してもらうように促すことも大事らしいです。
そしてなにより、組織マネージメントというのはベストエフォートだと。抱え込むことで自分がだめになってしまっては元も子もありません。
多様な価値観を認めることで見えてくる世界もあるようです。
まとめ
2つの事例で共通するポイントを抑えましょうということをおっしゃっておりました。
- プロセスはサービス・プロジェクトが大きくなる前にやるべきだということ。
- 期待値のギャップは対話することでお互いの共通認識を作っていきましょうということ。
- 結果が出るまで同じことを続けろということ。（取り組みの成果はある日突然やってくる）
お二方ともマネジメントは本当に難しいということをおっしゃっており、 特に日本人は不確実な事象に対して苦手意識が強い方が多いらしいです。
最後にこういったイベントを通してノウハウを共有しあうことで全員のためになればいいねという締めでくくられました。
感想
河村氏の人間性に惹かれました。歯に衣着せぬ物言いといいますか、楽天に入社してまだ1年と少しなのに非常に切り込んだ方でした。 もう切り込み隊長ですね。切り込んじゃてます。その印象が大きいです。 絹川氏は本当に地道な活動をしている印象を受けました。なんとかしてやろうという情熱が満ち溢れています。
なんとなくチームを構成することから脱却する
湯前慶大 [株式会社アカツキ]氏のセッションです。
いいチーム構成とはなにか。一概には言えません。 湯前氏が考えるいいチーム構成とはチームも個人も学習していってよくなることのようです。
チームはトレード・オフの関係です。 デメリットは？メリットは？という天秤の中で成り立っています。
課題
資料を見ていただければわかりますが、湯前氏には課題がありました。 チームを分断するか統合するか。。
拠点が違うゲーム開発プロジェクトの開発プロセスついて疑問を感じていたようです。 分断するにも統合するにもメリット、デメリットが存在します。
対策
それぞれの拠点にエリアPOを立てました。 ユーザーストーリーに関してはPOと連携し、どう実現するかについては各拠点に任せたようです。
問題
ソーシャルゲーム開発は特徴がいくつかあり、それらの問題に応じて考えなければならない観点がいくつかでてきたようです。 運用、開発、採用などなど、各拠点で線引を行わなければならなかったようです。
対策
一旦観点を整理したようです。図解思考法という方式で今ある課題を図に起こします。 運用はどちらの拠点が経験があるか、この要件は運用に関係ある？ない？など。
問題
しかしここでもまた発生しうる問題として分断されたコミュニケーションというものがありました。 どちらがどの案件を担当するのか？という内容を話していく上でコミュニケーションコストが非常に高いということです。
対策
機能パートでチームの仕事を分けたようです。 あとは双方のコミュニケーションでカバーです。 いいチームのために課題を明らかにする。課題がごちゃったら図で示して上げて整理して理解することが大事らしいです。
他社事例
こちらは資料を見ていただいたほうがわかりやすいです。
まとめ
図解はhowであり、何が今課題なのか。何かで表現することが大事。 いいチームとは他の会社からいろいろいわれても考慮してやり続けることだ！ということです。
感想
課題に対してまず何が問題になっているのか整理する。とてもロジカルです。 整理した上でどんな方法が良いかをまず実践することで次のアクションを見つけ出しているので 無駄がないように感じました。実際すべての行動に意味があるように思います。 改善するために他社の事例を聞いたりして動いているあたりコミュニケーションも意識も相当高いと思いました。勉強になります。
メルカリ・メルペイのエンジニアリング組織の変化 〜Engineering Managerの視点から〜
前半、後藤秀宣 [株式会社メルカリ]氏、後半、石川直樹 [株式会社メルペイ]氏のセッションです。
最初はメルカリEM（Backendチーム）後藤氏です。
conway's low（コンウェイの法則）
コンウェイの法則。聞いたことがありません。 システム設計は、組織構造を反映したものになる
後藤氏はこの1年の変遷を上記のように例えました。
スライドでも図があるようにそれぞれ取り組んできた内容によってシステムの構成が変わってきたようです。 そんな法則に立ち向かったお話でした。
後半は石川氏のセッション。
石川氏はiOSエンジニアでメルペイの海外拠点からメルペイジャパンにこられたようです。
メルペイのEMの役割
メルペイのEMの役割は資料のとおりなのですが、補足するとなんでも屋らしいです。（Ask The Speaker（登壇者に質問できる時間）でききました） メルカリはEMは特に評価に上がりも下がりもないらしく、コード書けなくて評価決める時胃がキリキリして苦労が多いけどやるしかない。代わりがいれば引き継げるけどらしいです。 でもそのやりがいは大きく、今では楽しいらしいです。
一年を振り返って
ヒト・事業・自身の役割の3つの軸で説明されてました。 どの軸も変化と振り返ったときの改善や課題があった一年だったそうです。（資料参照）
目指す人物像
大きく3つあるようです。 - All For One - HRT(Humility, Respect, Trust) - MO (Margin, Opportunity)
それぞれの詳細は資料が詳しいです。
感想
いまや大規模サービス。知らない人がいないほどのサービス、あのメル社も山あり谷ありの変遷をたどってきたようです。 やはり一筋縄ではいかない開発プロセス。人の入れ替わりで受け継がれない知見、問題。 その中でも、後藤氏からこの1年、これからもコンウェイの法則に打ち勝つんだという強い意志を感じました。 石川氏は直接お話したということもあり、とても物腰が柔らかく話聞いてくれそうだなーという勝手な印象を持ちました。 エンジニアリングマネージャーってどんな職業か想像もつかなかったのですが、石川氏の詳細な資料のおかげでとてもイメージが 湧いてきました。よかったです。
持続可能なエンジニア組織 〜エンジニア0人から40人規模の組織になるまでの道のり〜
平岡洋祐 [株式会社ディー・エヌ・エー]氏のセッションです。
エンジニアを0人から40人に増やした実経験からどんな問題を解決してきたかという内容です。
組織の歴史
株式会社ディー・エヌ・エーの会社組織は変遷は下記をたどってきたようです。 - 黎明期 - 成長期 - 成熟期
黎明期
黎明期の課題はとにかく人がいない。とにかく人がいない。 何をしたか。マイナビとかのイベントや、ふらっと来た人と話したりとにかく人をとるためにやることを惜しまなかった様子 人材エージェントの人と関係を構築したり、エージェントさんに押しかけて書類選考を一緒にしたりしたそうです。（広辞苑ぐらいの書類選考見る） 他には入社した人の話をエージェントさんを通して応募者の方へしてもらうなど。 さて、人員の確保はできました。エージェントの方と長期的な採用がコミットできるので少し落ち着きました。
成長期
案件が増える増える。ステークホルダー増える増える。扱うタイトルが増える増える。人員増える.. 課題も山積み。人の入れ替わりによる品質の劣化、採用人材のキャッチアップ遅れ、マネージャー負荷..etc アクションとしてオンボーディングの一貫でマークダウン化された資料を読んでもらったり、採用基準をリニューアルしたりして 採用担当者のリスクを減らしたらしいです。 また、アサイン戦略として研修を終えて間もないメンバーを難易度の高い案件にアサインしていたので、 きっぱりやめて安定した案件にアサインして耐えられそうになったら難易度の高い案件に振りなおしたりしたようです。
成熟期
シニアメンバーがやる気をなくしたらしいです。 そこで事業領域の拡張をしてゲームの繋がりを持つために女子高生が考えたキャラクターを使うとかゲームの可能性を広げていきつつ 技術的チャレンジを促進させることを大事にしていったようです。
まとめ
黎明期はパワープレイで人集めて、成長期は課題がボコボコ増えてくるので アクセル踏みつつ頑張って、成熟期はイケてないようなことが減ってくるので 同じようなことをしていると緩やかに死んでいくので新しいことしましょうとのことです。
感想
チームをよく観察しているなと、この一言で片付けていいかなと心配になるぐらい観察している印象でした。 若手からシニア、チームの意見をしっかりヒアリングし、やってみて、改善し、繰り返してまた観察と、 非常に泥臭い（褒め言葉です）。でも結果はでかいみたいな感じで尊敬しました。 この時点で私がマネージメントに興味があると言ったことがおこがましいとさえ感じてきました。
レガシーコードからの脱却
吉羽龍太郎氏 [株式会社アトラクタ]のセッションです。
誰もが一冊はもっているであろう技術書の著者です。 持ってない人は帰りに10冊買いましょうというジョークからはじまりました。
みなさんレガシーコードって何がレガシーコードなのでしょうか。私もレガシーコードはこれだ！とは言えません。
いろんな有名なレガシー本がありますが、それらで定義されているレガシーコードの定義は様々です。
このセッションでいうレガシーコードとは保守・または拡張が難しいコードという定義で進められます。
使われるソフトウェアは変更が必要になります。 しかし、変更を予め予測することは不可能です。なので変更できるようにしておくことが大事です。 つまり、変更できない→レガシーコードとなります
面白いデータがあります。 リリース後のバグ修正はとてつもない時間がかかります。 資料にもありますが、開発者の時間の半分以上が過去にやった仕事の手直しらしいです。 なので最初からバグ作らないのが大事です。ということです。
保有コストをいかに下げるかが大事で、いままで最後にやっていたテストを最初にやるとか、 保有コストを下げたかったら開発のやり方に着目したほうがよいみたいです。
変更可能なコードにする→開発プロセスに着目するがポイントです。
開発プロセス
資料にはきれいなウォーターフォールの写真が写されていますが、実際のウォーターフォールはこんなに綺麗ではありません。このジョークは最高でした。 ウォーターフォール開発は、開発に入る段階ですでに遅れており、結合テスト、受け入れテストと最終的にこんなの頼んだ記憶ない(笑ってしまった...)と。 ではどうするか、アジャイルしようねということです。 スクラム・XP..etcでもアジャイルは万能ではありません。失敗します。 開発プロセスには重要な要素が3つありどれが欠けても成果はでないそうです。（資料参照） テクニカルなものにお金や時間を使わないと成果はでません。
レガシーコードを作らないようにするには
ドカンとつくるんじゃくて小さく小さく作るのがよく、継続的に統合、お互いに協力..etcと9つのベストプラクティスを紹介されておりました（資料参照）
やり方より目的、理由、誰のためか
資料のWhatとHowを分離するという項目にもありますが、それぞれプロダクトオーナー、顧客、開発者と見ているロールが違うので それぞれのコンテクストを共有することがとても大事らしいです。それを表したものがユーザーストーリーらしいです。
小さいバッチで作る
タイムボックスとスコープボックスという２つの概念が登場します（資料参照） これら２つの概念に共通することは短い期間の中で小さい嘘をつくことです。 ウォーターフォールは長い期間の嘘を最初についてしまうということです。 長い期間の嘘を最初についてしまうとその嘘は最後にはとんでもないことになっているかもしれませんね。恐ろしい。
タイムボックスで仕事をするということはQCDS(Quality,Cost,Delivery, Service)のバランスを柔軟に考えることができる、必要があるということです。 吉羽さんはおっしゃっておりました。品質をいじったら負けだということです。 もしバランスに悩んだときは、とにかくスコープを減らせ！だそうです。 実際のプロダクトで64%の機能は不要らしいです。 レガシーコードが出来上がる要因としてスコープ達成の圧力があります。期間内にこれをやらないといけないというスコープ圧力です。（とてもうなずく）
ケイデンス、リソース効率、プロセス効率
期間長くなるとリソース効率化しやすい、一人の人にまとめて頼んだほうがいいみたいなものはリスクが顕在化していくようです。 モブプロとかはプロセス効率改善の究極の一手らしいです。 大事なのはキーボード叩いた数ではなく、お客様に評価してもらったかどうか。お金儲かったかどうか、そのためには完成しないと意味がないとバッサリおっしゃっておりました。
ソフトウェアの評価
ソフトウェアの評価は顧客への効果・価値です。 小さいバッチであればフィードバックのサイクルを作りやすく軌道修正がすぐできます。 フィードバックのサイクル作るというのがどういうことかというと、顧客への価値・効果をより洗練することができます。 詳細は資料にも載っていますが、やり方はいろいろあります。
CLEANコード
CLEANコードの定義については資料を見ていただければわかります。
恐らくみなさんご存知であろう - 凝縮性 - 疎結合 - カプセル化 - 断定的 の頭文字をなぞったものです。詳しい詳細は資料にあります。
これらはテストのしやすさと密接な関係があるようです。 つまり、テストが書きにくいコードは設計が良くないということになります。 名前ははっきりした概念であるべきで、だめなコードの典型としてなんとかdata、 commonなんちゃら、なんとかUtil、人間クラスとか絶対やめたほうがよいですとおっしゃっておりました（笑ってしまった） 継続的に変化に対応できるサービスにするために開発チームでスキルを高めていくことを惜しんではいけないそうです。 チームの能力改善の余地があるならばやるべきで、できないとずっと忙しいままパフォーマンスがずっと低いままになってしまいます。
まとめ
品質を一定に保って開発する！間に合わなそうならスコープ減らせ！としきりにおっしゃっておりました。（たしかに）
感想
耳が痛い。この一言につきます。吉羽氏は、こんな感じがいいんじゃないかなではなく、こうだ！って道筋を明確に提示してくれている感が あるので現実と理想のギャップに耳が痛くなるという感じでした。でも実際そうなんです。実際おっしゃるとおりなんです。 それしか言えません。こんなイケてる開発者になりたいです。
CTO着任の一年
松本勇気 [合同会社DMM.com]氏のセッションです。
松本氏は1年前にDMMになったばかりでその振り返りというお話です。
DMMという会社はなんでもやっており、松本氏も何やっている会社なのか問われたら答えられないそうです。 びっくりしたのが今消防車作ってるらしいです。
CTOとしてのミッション
松本氏がCTOに着任した時のミッションとしてDMMをテックカンパニーにするということです。 テックカンパニーとはどういう会社か？私もはじめどんなものなのかわからなかったですが、しっくりきました。
テックカンパニーとは
資料にも詳しく書いてあるのですが、テックカンパニーとは技術、ソフトウェア化で改善をしていくというものらしいです。 とてもさっくり言ってしまうと会社全体をエンジニアリングしていくということ。データドリブンで事業の状況をモデル化し、分析し、イテレーティブな改善をしていくことだとおしゃっておりました。
課題
松本氏が入社してからのDMMは課題が大きく2つあったそうです。（資料参照） DMMは営業力とビジネス力で成長してきたという背景もあり、長らく事業、開発を別会社運用になっていたり、部署間のコミュニケーションが不足していたり 定性的な事業判断の慣習などでデータドリブンでなかったりしたそうです。
勘所
組織改革に重要な要素として4つあるということです。（資料参照） 仲間を信頼するため、状況、目的を理解するためのヒアリング 文化の土台をつくっていくパッケージ化。文化は恣意的には生まれず、一定の方向性を示してあげなければ自然に育っていかないそうです。 ある程度信頼性を担保したオープンな情報提供、共有の透明化。 実現コストが小さいけど事業インパクトがでかい成功体験を積み重ねる小さな成功
まとめ
4つの要素の先にあるものは、自律的で迅速な課題解決ができ、組織として血が通っている状態といえるそうです。
感想
DMMをテックカンパニーにするというミッションはとてつもない労力だとおもいます。すごい他人事感が半端ではない感想なのですが それだけの能力を買われて松本氏はCTOという立場になったのだと思いました。 セッション自体もとてもわかりやすいもので、たとえば〜、や、つまり〜みたいな具体と抽象の行き来が半端ではなかったです。 あとは、勝手な印象で申し訳ないのですが、やはりいろいろとヒアリングして、きめて、やって、改善してってとにかく泥臭く回しまくってる感じが しました。とても熱かったです。 テックカンパニーにすることで、より効率的に意思決定することやその他にも様々な利点があるとは思いますが、その中でもモチベーションを失わない ための施策しっかりうっているところに好印象を受けました。やはり良い環境、文化が大事なのだと。
総括
総括として、どのセッションにも共通していることはみなさん熱量が高い・情熱的ということでした。
みなさん会社の規模はそれぞれ違いますが、なにかを変えようという使命感。ミッション達成への執着心は共通してもっておられました。（マネージャーだからという言葉で片付けられない）
あとはコミュニケーションが非常に重要だということです。
登壇者の方は今ある現状・目的を明確にするため全力で関係者とヒアリングしたりして、チームの成長を常に観察し、モデル化し、適応して、失敗して、いろいろ試行錯誤してやっと改善できたなという感じでとにかくすごい動いています。なので失敗は大いに成功なのだということを感じました。
また、開発プロセスについては課題は千差万別。会社、プロダクト、チームどの単位でも様々。その中で重要なのはないところから作り上げるということです。
DMMの松本氏もパッケージ化という部分で触れておりましたが文化を生むための土台をつくらなければいけないとおっしゃっておりました。
楽天の河村氏もプロセスは自分たちで気づいて積極的に作っていく必要があるとおっしゃっておりました。
共通する行動指針を自分たちのコンテクストで明確にしておくことが非常に大事なのではないかという感想で筆を置きたいと思います。
最後まで読んでいただいた方もすっ飛ばした方もありがとうございました。
※セッション中に高速でメモしたり聴いたりしたので、違う部分や誤植、疑問点等ありましたらお答えできる範囲でお答えしたいと思っております。
