- 与えられた条件で最高のパフォーマンスをだすために
- 予算 権限など
- どのようにチームを巻き込むか
- 巻き込むための俯瞰図
- 巻き込むための未来予想図
- その時に組織を超えた関わりあいをどのようにするか
与えられた条件で最高のパフォーマンスをだすために
- メンバ 予算 人選 プロダクト
- (伊勢) 与えられた環境下でしゃかりきやる 小脇にPCを抱えて客先に行かないといけない ベストを尽くさざるをえない
- 与えられた環境ではなく、途中から自分から提案するようになる というかしないといけない
- 会社のなかより顧客にどう思われるかを重要視する それに対して疑問はなかった
- その頃はベンチャー
- (よしおか) 1984にマスターを取ったけど、ここにいる人たちの多くは生まれていない時代
- 世界はソフトウェアでできている
- 日本ではハードウェア偏重なところで、ソフトウェアの重要性が理解されていない感がある
- ハードウェアベンダにいたけどそういう会社はほとんどなくなってしまった
- 会場にSIはほとんどいない
- webの業界で、自分の条件を選んでいるということはとても良いこと
- 世界はソフトウェアでできている
- (森藤) 選べるということはとてもよいこと
- どういうふうに自分の戦略を立てるか
- (よしおか) 戦略は考えていない
- 新卒で入った会社で自分のDNAが決まる
- でも、ずっと同じ会社にいれるわけではないので、転職も含めてアンテナを貼っていく必要がある
- (及川) 上司から言われたことは、「リーダーは、与えられた条件下で最大のパフォーマンスを出すことが重要」
- デック→マイクロソフト(NT)
- ハードがない、人がいない、といったところで条件がよくなるわけではない
- 前職はGoogleにいたけども、マリッサ・メイヤーが「いかにイノベーティブでありつづけるか」ということで、「創造性は制約を好む」制約が創造を生む。Chromebookみたいなのを作ろうってなったときに、今のノートブックはインターネットに最適化されておらず、コールドスタートから10秒でGmailを使えるようにするには、ミリセカンドレベルでイノベーティブな工夫を繰り返すことで生まれる
- 制約条件が厳しければ厳しいほどイノベーションが生まれる 10倍にするためにはそもそものやり方を変えないといけない
- 普通のやり方ではダメ
- じゃあどうするかっていうところを考えると、リーダーとしての成長にもなるのではないか
- デック→マイクロソフト(NT)
(森藤) こういうことをやったら20％ではなく10倍にできるっていうものがあれば
- (伊勢) 人は社内初/世界初というワードに惹かれる
- 命令されたからではなく、自発的にできるようなチームメイキングをすると良い
- 大きな旗を振って、みんなで進めていく
- (及川) 誰かに言われたのではなく、一緒にやりたい、と思えるようにする
- 相手にそれを言わせるようにすることが重要
- これやれよ！って命令されたらやる気をなくす
- もしかしたらよりよい違うやり方があるのではないか
- GoogleIMEを作っていた時、かなりの確率で実は違うやり方でもっと良いものが出来たりする
- 新しいやり方を見つける可能性を潰すかもしれない
- 自分の口で言わせることによって、自発性を生む
- いろいろな意見を採用してみると、10倍のヒントになりうる
- (よしおか) チームでやるのが大前提っぽいけど、昔の会社はクローズドなプロジェクトが多かった
- 今では社外のひとたち OSSなどとコラボレーションすることが当たり前になってきている
- やっぱり標準化の場所だと会社ごとの利害があって対立することがあるけども、最終的なゴールとしては共通の文字コードがあると絶対便利になるよねっていう理想だけは崩さないようにして、利害関係を調整するしかない
- 理想で共感を得て、技術であげていくことに収斂していく
- 日本からの提案は競争力がなかった
- 世界標準で作ったのがよい経験でした
チームを巻き込む
- 後輩指導
どうやって引っ張るか
(森藤)モチベーションは重要だけど、なんの実績もない人が「世界一」っていっても「何いってんだこいつ」ってなる
- 飲み会？技術的なフォロー？
- 技術的にどういうふうな感じになろうと思ったか
- イエスマンでなかったかもしれない
- (よしおか) 日本ではモチベーションが根性論になりがち
- 個人として技術力があることが重要
- チームとしては、全員がゴールを共有していることが重要
- そのためにはコミュニケーションを濃密にすることが重要
- そのための手法として、毎朝10分朝礼する(スクラム) こんなに簡単なこと、当たり前なことを共有していなかったなと気づく
- 上手なマネージャーは本能的に雑談してる
- (及川) チームのディレクションは良いと思っている
- MVPみたいなの
- 何作るか、が共有されていないとプロジェクトが長くなると機能削除、機能追加が見えなくなってしまう
- Google ChromeはSpeed/Security/Stability
- ボットがチェックして、その条件に満たないものは機能追加出来ない
- 世界観が達成できるならアジャイルでもウォーターフォールでも構わない
- (森藤) 総論賛成各論反対みたいなのが力になるけど、そういうのを揃えるときはどうしたらいいのか
- (及川) 人間はその人を信頼できるかどうかっていうのは非常に重要
- 実績や信頼がないとテーマを出しても意味が無い
- Linkedinは日本では不評だけど、海外ではすっごいきらびやかなプロフィールが出てくる
- 民主主義ではどうにもならないといいつつ、全員で考えるという矛盾を解決するために、上手なファシリテーターが必要なので、思い切り話し合っていく必要性がある
- 伝説的なプログラマーがいないときは、自分が何をやってきたのかをベースに、全員で合議するのも重要
- (伊勢) インフラ系のしごとが多かったので二人とは違うかも
- 世界観の共有があんまり感じたことない
- デイリーミーティングはいっさいやらない
- ゆるい制約と完全な自由を与えると、レポートを受けたら何か考える、コミット出来なかった場合はどうするかこちらで考える
- 結構リスキーなやり方なので、出来なかった時のバックアッププランは、自分で考えたり、みんなで考えるなど、まちまち
- バックアッププランを想定した状態で丸投げし、自由にやってもらう
- (よしおか) チームメンバーのひとりひとりが大リーガー級レベルじゃないと回らない手法
- チームのメンバーが素人だと困る
- その前提じゃないと↑の方法は回らない
- その人に合わせたものを割り振っていけばいい
- 全ての人に同じものを提供してはいけない
- 相手から言ってくるぶんにはいいけど、こちらから何かを言うことはない
- 本当にやばいときは例外
- 非常事態じゃないときは、相手から言ってくるときは
- (及川) 笑いながら怒る
- 情報共有をギリギリにやるのが非常によくない
- 何度も同じミスしたら言う
- 言わない人の責任ではなく、全員の責任
- (よしおか) カジュアルに報告できない空気が生まれて、自分でリカバリーしようとしてどうしようもなくなる
- 詰められるのは嫌なので、詰めるマネージャーは傷口を広げる
- 詰め詰めでいくと、上に報告しづらい空気が生まれる
- (森藤) コミュニケーション
- (よしおか) ひたすら話すしかなくって正解はない
- 何をやったときにうまくいくかっていう事例がいくつか欲しい
- (及川) 人間関係の話
- 話しづらいときは、自分から言っちゃうのもアリかもしれない
- 仕事のうえでプロとして付き合えない理由はないとおもう
- (よしおか) 雰囲気悪くないですか？って聞けるのって結構勇気がいる
- 上司同僚とのウマが合わないのは退職事由たりうる
- ひとつの方法論としては、社内異動がアリ
- ここのプロジェクトでは自分のパフォーマンスが出ない
- あんまり頑張らなくていいんじゃないか
- (及川) 人材流動性と文化は重要
- 話してみて分かり合ってっていう
- 「こいつとはもう無理」ってレベルになったら辞めたらいい
- うまくいかない構造がダメであって、対立軸が生まれるとよくない 誰が敵なのか確認する
- 客と営業とエンジニアとでチームにしないといけない
- (伊勢) IT業界は人材流動性が高いので、「いやならやめる」が効く
- そうじゃない会社の人たちはどうしたらいいの？
- (よしおか) やっぱり技術力つけないと転職できない
- 一番重要なのは技術力
- 自分をマネジメントできるスキルをつけないといけない
- (伊勢) うまくいかない場合の対処法はケースバイケース
- (及川) 海外ではcounter argumentが重要
- でも日本ではポジションが上のひとが重要だったりするので、質問を変えたりして、意見を出してもらう空気をする必要
- ファシリテーションが重要
- でも日本ではポジションが上のひとが重要だったりするので、質問を変えたりして、意見を出してもらう空気をする必要
- (よしおか) web系だと当たり前な蛸猫とかCIとか
- それを大学の授業でやるのが画期的で、使い方とかは教えずに、成果物のみを評価するやりかたになっている
- 作ることを重要視して、アプリケーションを作っていくやりかた
- ヒントを与えて放置すること 技術力を与えるためには自分でどうにかするしかなくて、先輩や上司ができるのはヒントを与えること
- それを大学の授業でやるのが画期的で、使い方とかは教えずに、成果物のみを評価するやりかたになっている
- (森藤) 放置してほしい後輩/コーチングしてほしい後輩
- 皆が皆おなじモチベーションにはない
- どういうふうに振る舞うと望ましいのか
- (及川) 次はこういうことをしたから昇進する
- 社内での評価システムを作るのはいいと思われる モチベーションアップにつながるから
- 評価システムとロールモデルがいると、モチベーションが上がる
- (よしおか) アメとムチを与える？
- (伊勢) モチベーションを与えることは無理でも、モチベーションを邪魔しないことはできる
それほど熱意のないひとをどうコーチするのか
- (森藤) 仕事を仕事と思わない人ばかりではない やらされているのではなく主体的に学ぶようになるとチーム力が上がる
- (伊勢) 外のコミュニティに出て、超おもしろそうな顔をしてればいいんじゃないのかな
- 周りにそういう人が増えると、楽しそうにやっていくと、みんなも楽しそうになる
- (よしおか) パッションは人に与えられるものではない
- ゼロからモチベーションを持つのは無理
- (及川) 東京はエンジニアが母数が多く、勉強会に行く人も勉強熱心
- 土日でプログラミングするのが変人あつかい
- そういう人を入れないような採用をするとか、そういう人にあった仕事を与えるとか
- (森藤) モチベーションのある人はいいとして、モチベーションのない人はどうしたらいいんだろうか
- (及川) 全然モチベーションがない人は、プログラマと呼ばないで欲しい感が
- (よしおか) web系で自社プロダクトだと同じ方向にむきやすい
- (及川) 日本はプログラマの地位が低い
刺激を得るためのコミュニティ活動
- (よしおか) 技術者なので技術力の絶対値が重要 社内だと分からないので、外に行けば自分が通用するかしないかわかるから大切
- こういう勉強会に行くひとはそもそもちゃんとわかっている
- 仲間を見つけて研鑽できるのはとても重要
- (及川) 外にいることがベンチマーク
- 人間はアウトプットが大事
- 質問しようと思っていると、受け身なのよりも経験値が高いし、聞いてる話も入りやすい
- コミュニティや勉強会にコミットしていくと良い
- (森藤) 外にいると、自分の持っているリソースが格段に増える
- デメリットを考えるとろくなことないので、ストレスは抱えないこと
- ぼっちなのを怖がることはいけない
- どんなに嫌なことがあっても死ぬことはない
- (よしおか) CSを学んだ優秀な学生をいっぱい取らないといけないのに、土日の勉強会にさえ会社の承認が必要な会社はとっとと辞めたほうがいい
- (伊勢) 登壇者として参加して、会社が許可出してくれないなら仮面をかぶって偽名で出たらいい
- (よしおか) 会社名を出して出て欲しい ただし、アニメとか漫画のやつは著作権に反するのでやめて
- 会社の宣伝になるので、ガンガン言って欲しい
- 会社が認めない場合は、辞めて欲しいし潰れて欲しい
- (アクセス) つべやドライブ Qiitaにアクセス出来ない会社は潰れて欲しい
