南山大学人間関係研究センターの公開講座に行ったら最高の体験学習が出来た
はじめに
5億年振りにブログを書くぞ。
今年に入ってから、スクラムマスターをやらせてもらったり、ここ最近はエンジニアリングマネージャーのお仕事をしたりしている。そういう役割を任されるうちに、会議のファシリテーターや1on1のメンターをする機会が増え、組織開発って面白いかもと思い始めた。
しかし、自分の力不足を痛感することも多く、会議に参加している人やチームメンバーに対して、コスト（時間）に見合った価値を提供出来ていないのでは？と思っていた。
そんな中、ヘイシャの人事部長からこんな情報をもらった。
3年くらい前に組織開発を学ぼうと思って色々調べていたら、南山大学の人間関係研究センターに辿り着いて、そこの公開講座を受講したのだけどこれがよかった。「集団で成果に向けて行動する時に自分はどんな行動特性を持っているのか」を知れるプログラム。日々のファシリテーションに活きている。
— takumix (@takumixi) August 15, 2018
こりゃ行くしかねぇ！って言うか、課題を感じているのに放置するのとかクソダサいし、チームメンバーに対して無責任だし、飛ばねぇ豚はただの豚じゃんかっこわる！と一念発起し、先週末受講してきたので、今回はそのレポートを書きたいと思う。
ちなみに、組織開発と聞くと仰々しいイメージがあるかもしれませんが、普段の仕事をする上でもとても役に立つ講座だったので、エンジニアの方にもめっちゃオススメです。
南山大学人間関係研究センターとは？
僕は組織開発の専門家ではないので、詳細な説明は公式のHPをご覧いただければと思いますが、ラボラトリー方式（自分や他者、グループを成長させるために行動を試みる場）の体験学習という"プロセスから学ぶ学習方法"の研究と実践を行っている教育研究機関です。
その中で、いくつかの公開講座が行われており、今回僕は「人間関係講座（グループ）」という講座を受けました。
ちなみに、恥ずかしながら僕は受けるまで全然知らなかったのですが、南山大学はこの分野で国内トップクラスの権威があるそうです。
どういう講座なのか？
「人間関係講座（グループ）」という名前の通り、グループの中での人間関係について学んでいく講座になります。もう一つ「人間関係講座（コミュニケーション）」という似たような名前の講座があるのですが、こちらはグループよりももう少し小さい単位（1〜2人程度）での人間関係を学ぶ講座のようです（こちらも今度受けてみたいな〜と思った）。
講座の主な目的（学習目標）として…
- グループの中で他者と関わる自分の特徴に気づく
- コンテント」と「プロセス」とは何かを理解する
- グループの中での人間関係（グループプロセス）に目を向ける重要性に気づく
の3つが挙げられています。
こちらも詳しくは公式の講座案内をご覧ください。
当日の講座内容について
講座は土曜日・日曜日の2日間行われます。具体的には、
- グループを組んで様々な課題に取り組む
- その振り返りをグループで行う
という流れを繰り返しながら、進んでいきます。実習やワークショップばかりではなく、所々小講座という形で理論的の話もしてもらえます。朝から夕方までみっちりやるので、とても濃密です。
学んだこと
メモレベルですが、僕はこんなことを学びました（間違っていたらごめんなさい）。
- グループで何らかの仕事や課題に取り組むと、どうしても課題の内容そのものに夢中になってしまう。
- 課題の内容そのもののことをコンテントと呼ぶ。
- コンテントに夢中になると、他者の気持ちやお互いの関係に目が向けられない。
- 他者の気持ちやお互いの関係のことをプロセスと呼ぶ。
- コンテントは氷山の一角で、プロセスはコンテントの下に潜んでいる。
- プロセスが上手くいかないと、グループのコミュニケーションがうまくいかず、コンテントの結果にも影響する。
- コンテントが上手くいかないと、プロセスのチェックも疎かになり、悪循環に陥るなと思った。
- プロセスにはタスク・プロセスとメンテナンス・プロセスの2種類がある。
- タスク・プロセスはコンテントに直接働きかけるもの。
- 例: 時間管理、目的や手順の明確化、アイディアをまとめるetc
- 比較的観測可能。
- メンテナンス・プロセスはコンテントに間接的に働きかけるもの。
- 例: 雰囲気、関係性、個々人の様子etc
- 目に見えないものが多い。
- タスク・プロセスはコンテントに直接働きかけるもの。
- 「売上は全てを癒す」という言葉は、コンテントが上手く言っているとプロセスに多少問題があっても気にならなくなることなのかなと思った。
- でも本当に全てを癒しているのかは怪しいなとも思った。
- リーダーとリーダーシップは違う
- リーダーシップとは、コンテントを達成するための過程で、影響を与えている人と受けている人の関係性のこと。
- リーダーシップはタスクプロセスの中に位置づけられている。
- リーダーシップにはP機能とM機能がある
- P機能は情報や意見を求めたり、課題を推進したりといったコンテントに直接働きかけるもの。
- M機能は雰囲気を和ませたり、励ましたりといったメンテナンス・プロセスを改善するもの。
- 両方出来る人がいればそれはそれで素晴らしいが、人には得意不得意があるので、グループでリーダーシップの役割分担をするのが良い。
- 分有型リーダーシップという言うらしい。
- サーヴァント型リーダーシップはGoodだが、カントリークラブマネジメントはBad。
- 実際にフィードバックを受けないと、相手の気持ちなんか分からない。
当然ですが、これ以外にもたくさんの学びがありました。
感想
おわった！！控えめに言ってとても楽しかった！！
— いとしょ (@itosho) November 18, 2018
というツイートを終わった直後にしたのですが、本当に最高でした。とにかく実習が多いので、知識が体に取り込まれる感じというか、体で学んでる感覚がありました。
特に僕は振り返りの重要性を改めて感じました。仕事では今もそれなりに振り返りに力を入れていると思っていたけど、どちらかと言うと、タスク・プロセスの改善ばかりやっていたなという反省があり、これからはもっとメンテナンス・プロセスにも目を向けていこうと思いました。そして、そのためには、もっと個人からの個人へのフィードバックをしていかないといけないなぁと痛感。他人の分かった気になってる状況ほど厄介なものはない。
あと、全国津々浦々から様々なバックグラウンドを持った方が集まって来ているので、そういう人たちと触れ合えるのも単純にとても刺激がありました。もっと外に出ていかないと。
ただ、めっちゃ疲れるので、そこだけは予めご注意ください。
でも、とても心地よい疲れだったな。
ちなみに、僕がよく言われたこと
何度もフィードバックを受ける機会があるので、自分の特性を改めて認識したり、発見したりすることも出来ました。初対面の人からも普段よく言われることを言われると、本当そうなんだろうな〜と認めざるを得ない。というわけで、僕がよく言われたことを晒してみます。
- 最後まで諦めない
- 落ち着いている
- ムードメーカー
- 裏のリーダー
- フラットに物事をみてる
耳障りの良い言葉が多いですが、それは初対面という関係性の中で言ってもらったことなので、ある程度忖度してもらっていると思います。長所と短所は表裏一体だと思うし、上記の特性も場合によってはマイナスに作用することもあると思うので、気をつけよう。
おわりに
というわけで、本当にオススメです！最後にお金を話をするのもアレですが、これが1万円ちょっとで受けられるのは本当にお得だなと思いました。人それぞれ感想は違うかもしれませんが、少なくとも受けて損はないと僕は言い切れます。
あと、受ける前にこちらの本を読んでおくと、講座の内容がより理解しやすいと思います（これも上述の人事部長に教えていただいた）。
ちなみに、受けるとこんな修了証をもらえます。
【翻訳版】Docker, Inc is Dead
What's this?
Docker, Inc is Dead の翻訳記事です。
ご本人の許可は取っていますが、僕が英語ペラペラではないため、読み辛いのはもちろん、一生懸命訳してはいますが誤訳・ミスリードなどあるかもしれません。
ですので、100%正確な内容を把握したい方は原文をお読みください。また、ここ間違ってるよ！ニュアンスが違うんじゃない？などありましたらお気軽に（優しく）コメントいただけると幸いです。
Docker, Inc is Dead / Docker社は死んだ
Dockerにとって、2017年は非常に辛い1年だったと言っても過言ではありません。Uberを除いて、より活用され、賞賛され、十分に資金提供を受けたシリコンバレーのスタートアップの中で、Dockerが2017年に行ったような悪手を打ったスタートアップは思い浮かびません。人々は2017年を、ソフトウェアの偉大な一部分であるDockerが悪いビジネスのやり方によって台無しにされ、翌年に終わりを迎えた1年だったと振り返ることでしょう。この記事はDockerがどのようにして良くない方向に進んでしまったか、そして、それを修正しようとする努力があまりにも少なくまた手遅れであった様子を外部から見た回顧録です。
Docker is Good Software / Dockerは良いソフトウェアである
言うまでもなく、Dockerはソフトウェア開発に革命をもたらしました。cgroupsや名前空間、そしてプロセス分離などのLinuxのプリミティブな技術を利用して、それらを単一のツールにまとめたのは素晴らしい功績です。2012年に私は開発環境のポータビリティをより高める方法を見つけようとしていました。Dockerの登場により、開発環境はシンプルでバージョン管理可能なDockerfileになりました。Dockerfileにより PackerやVagrant、そしてVirtualBoxなどのたくさんのインフラツールからDockerに移行しました。DockerのUIは実際かなりよいものです！Dockerはたくさんの応用が出来る良いツールです。Dockerを作った人々は、自分たちが開発したツールをとても誇りに思うべきです。
Docker is a Silicon Valley Darling / Dockerはシリコンバレーの寵児である
Dockerの初期の成功はそれを取り巻く大きなコミュニティを築く会社になることに繋がりました。その初期の成功は資金調達に次ぐ資金調達を促しました。Goldman SachsやGreylock Partners、Sequoia Capital、そして、Insight Venture Partnersのような名立たる投資家がDockerに札束を与えるために列をなしました。現在まで、Dockerは総額2億4,200万ドルから2億5,000万ドル以上の資金を調達しています。
しかし、資金が十分にあり、何が何でも勝とうとしていた2010 年代のスタートアップと同様に、Dockerはいくつかの人事的なミスを犯しました。Dockerは自身の成長にともなって何人かの不快な人を保護しました。これにより私はDocker社のリーダーシップに対して、嫌悪感を感じるようになりました。プロダクトは品質を維持していますが、会社のそのような振る舞いは一切言い訳出来ません。悲しいことに、これはシリコンバレーによくあるケースであり、変えていく必要があります。
Kubernetes Dealt Damage to Docker / Kubernetesの扱いがDockerにダメージを与えた
Kubernetesの登場により、Dockerの運命（悲運）は加速しました。Dockerはオープンソースコミュニティで人気のオーケストレーションツールであるKubernetesの扱いが上手くありませんでした。Dockerが認めたオーケストレーションツールは、自身が持つ（Kubernetesの）競合製品であるDocker Swarmだけでした。この決定はKubernetesが最初にDockerコンテナを好んでいたのにも関わらず下されました。非公式な情報では、Docker Captains は、2017年初頭にKubernetes関連の記事やミートアップ、そして、カンファレンスがDockerによって批判されたことを確認しています。
オースティンでのdockercon17はこの Kubernetes-less を信念にして開催されました。その後、dockercon EU 17では突如DockerはKubernetesに全力を尽くすことを決めました。この突然の変化は、Kubernetesが盛り上がり間もなく優勢になろうというところに参画することを狙ったものでした。これはKubeConとCloudNativeCon North America 2017のスポンサーとブースを持っていたことによって、更に心象を悪化させました。
Moby?
Mobyが発表された4月のdockercon17で、Dockerが何をしているのか誰も理解出来ませんでした。MobyはDockerプロジェクトの新しい上流のものとして説明されています。しかし、Mobyの公開は事前にアナウンスされていませんでした。Solomon Hykesのdockercon17での発表を受けて、GithubでDockerからMobyへのドラスティックな変更が起きたとき、何百万の声が恐怖で叫んだかのようでした。このドラスティックで思慮の浅い考えにより、巨大なリポジトリの名前変更は内部で問題を引き起こし、Githubスタッフによる手動での対応を必要としました。
変更がうまく管理されなかっただけでなく、メッセージも十分に考慮されていませんでした。これは謝罪に繋がり、後に手書きによる変更の説明を求められました。これは既に雲行きが怪しいコンテナ分野とDocker（Moby？）のエコシステムを更に混乱させました。Moby公開の扱いはこの業界で働く人々を困惑させ続けています。これによりDockerブランドが傷つけられた可能性もあります。
The Cold Embrace of Kubernetes / Kubernetesの冷めた受け入れ
Dockerの遅く、気まずい土壇場でのKubernetesの受け入れは、差し迫った崩壊のサインです。Docker Swarmが死んだかどうか尋ねられ時、Solomon Hykesは以下のようにツイートしています。 "DockerはKubernetesとSwarmの両方をファーストクラスの市民として手厚くサポートし、相互作用を与えます。オープンさと選択は全ての人にとって健全なエコシステムをつくりだします。" ここでの問題は、Docker Swarmは完全に出来上がっているわけではないので、そのような状況からは程遠いということです。Docker Swarmのプロダクトチームと一握りのオープンソースのコントリビューターだけではKubernetesのコミュニティに追いつくことが出来ません。DockerのUIと同様にKubernetes UIはかなり優れています。これはコンテナ分野において、Dockerが取るに足りないコンサルティング会社であることを認めているようなものです。
Conclusion / 結論
Dockerの真の問題は一貫したリーダーシップの欠如にあります。組織の中で一人の人物を中心にした戦略的なフォーカスがあったようです。この人物は会社の中核からはかなり遠のきましたが、依然として籍を置いています。会社は再編成を行い、エンタプライズにフォーカスすることになりました。この変化はDockerの投資家にとって理解できるものです（結局会社は信託の責任を負っています）。しかし、この変化は熱狂的な成功によってもたらされたブランドが持つクールな要素を減らすことになります。"偉大な文明は殺されるのではなく、自殺するのだ。"と言われますが、Dockerはまさにそれと同じことをしました。
Bonus: Conspiracy Theory / おまけ：陰謀論
Conspiracy Theory: Docker knows it is over for them. The technical folk decided to roll out Moby drastically and embraced Kubernetes suddenly to make sure their work still lives on. #Docker #DevOps
— Chris Short (@ChrisShort) 2017年12月29日
私はTwitterで2017年というDockerの厄介な時期について持論を展開しました。Dockerは自身の会社の終わりが近いことを知っている可能性があります。組織の変更により、Exit予定（買収による可能性が高い）が明らかになり、会社の技術的な中核チームはいくつかの変更を優先しました。CNCF（訳注：Cloud Native Computing Foundationのこと）に containerd に寄贈し、MobyをDockerの上流にして、Kubernetesを受け入れることで、Dockerの人々が行った良い仕事は不朽のものになります。これにより、Dockerの従業員によってなされた技術的な進歩がライセンスによるロックを心配することなく、 OracleやMicrosoftのような大規模な会社がDockerを買収することが出来るようになります。これはソフトウェアと企業に両方にとって、ベストな世界です。言うまでもなく、2018年はDockerにとって興味深い年になるでしょう。
Eureka English Evening に参加してきました
はじめに
先日、Eureka English Eveningというイベントに行ってきました！ブログ枠で参加させていただいたので、当日の様子を簡単ではありますがレポートさせていただきます。
どういうイベントなの？
詳細は下記のconpassのページをご覧いただければと思いますが、端的に言うと、Eurekaさんが企画している技術英語を学ぶための勉強会で、今回はコードレビューがメインのお題でした。
当日の流れ
Presentation
最初はコードレビューで役に立つ単語やフレーズの紹介をしてもらいました。PR（Pull Request）のコードがOKな時、NGな時などシチュエーション別に説明してもらったので分かりやすかったです。
ただ、実はちょっと遅刻してしまったので、最初のほうは聴けていません…。ごめんなさい。
ごめんなさい。5分くらい遅れます。 #eureka_eee
— いとしょ (@itosho) 2017年8月24日
Practice
続いては実践編ということで、練習問題用のPull Requestをグループに分かれて、それを英語でレビューするというグループワークをやりました！5問ほどあり、書いたことのない言語のコードもあったので、英語以前の問題もあったのですが、とても勉強になりました！
※ちなみに事前に英語力のアンケートをとっており、適切にグループ分けをしてもらっているので安心でした。
Performance
少し休憩を挟んだ後、最後は会話練習ということで、再度グループワークでYES / NOゲームを行いました。 お題が定番の動物からプログラミング言語（Java, PHP, Ruby, Pythonなど）、OS（iOS, Windows, Linux, Androidなど）など多岐に渡り、面白かったです。
感想
英語系の勉強会は初めて参加したのですが、とても愉しく勉強になりました！よくある技術系の勉強会だと実際に参加しなくても、後からスライドをみればある程度事足りることも多いのですが、やはりワークショップ系の勉強会は実際に参加しないと学べないことがたくさんあるので、そういう意味でも参加して良かったです。
ただ、自分の英語力の低さを痛感しました（一緒にグループワークをした方にはご迷惑をお掛けしたかと思います…）。個人的にはOSSにコントリビュートしたり、OSSを公開したりする際に英語力が必須になるので、そういったことがもっと出来るようになりたいという想いが今回参加したモチベーションの一つだったのですが、もっともっと英語を勉強しなくてはと気持ちを新たにすることが出来ました。頑張るぞ〜。
素敵な機会を与えていただいたいEurekaさん、本当にありがとうございました！第2回目があればまた是非参加させていただきたいと思います！
当日の資料
www.slideshare.net
2016年をフリカエル
あけましておめでとうございます。今年もやらしくお願いします。 そういえば、去年の振り返りをしていなかったので今日は勝手に思い出話に花を咲かせたいと思います。
1月
仕事の引き継ぎでめっちゃ忙しかった記憶。確か最終日までデプロイしてましたね。
本当にお世話になりました！
2月
というわけで、6年近くお世話になった会社を辞めて、転職しました。
もうすぐ1年経つので振り返り等はその時書きたいと思いますが、いまのところ愉しく働いています。
あ！あと、ディズニーのミラコスタに初めて行きました。お金貯めてまた行きたい。
3月
正確には2月ですが、うるう日限定のWebサービス PRESENT4229 をリニューアルしました。 2012年に初めてつくって、2016年が2度目の運用だったのですが、予想遥かに越える反応をいただいて、本当につくってよかったなと思いました。引き続き4年後（もう3年後）をお楽しみに。
リニューアルの顛末はこちら。
4月
結婚式の準備でめっちゃ忙しかった。徹夜で動画編集しまくってた。 この頃はIntelliJ製品（RubyMine&PhpStromを愛用している）よりAdobe製品を触っている時間の方が長かったな〜。
5月
30歳になった！
パワプロ2016を買ってもらって未だにマイライフやっています。
6月
結婚式を挙げました。
準備とか色々大変だったけど、やってよかったなーと思います。 YDDしながら夫婦仲良くやっています。
YDDについてはこちら。
7月
結婚式の燃え尽き症候群で全く何もしていない。
8月
伊藤直也さんの一人CTO Nightのレポートがめっちゃバズった。書いてよかった〜（こなみかん）
あとは乃木坂ちゃんのライブに行ったりしてました。
9月
北海道に行ったり、ディズニーシーに行ったり。 東京以外なら札幌に住みたいという思いを強くした。
10月
会社の仲間と Kocoromo というAndroidアプリをつくりました。 （僕はサーバーサイド担当）
プライベートで @tecco_master と新しいアプリ「Kocoromo」をつくりました！よかったら使ってみてください！（iOSな方はしばらくお待ち下さい）https://t.co/sXQu1cexKz
— いとしょ (@itosho) 2016年10月28日
iOSはもうしばらくお待ちください。
そして、Mr.Childrenの武道館公演を観に行ったのですが、まさかの最前列でした。 後世にまで語り継ぎたい一生の思い出。
あと、開発合宿にも行った！
rei19.hatenablog.com （一緒に行った会社の仲間のブログを拝借）
11月
PHPカンファレンスにスタッフとして参加しました。 基調講演の司会をするという「貴重」な機会をいただきました。
来年は発表したい！
12月
箱根の温泉でのんびりして、一年の疲れをとりました。
感想＆今年の抱負
プライベートではやっぱり結婚式が一番の思い出かな〜。正直当日ってあっという間に終わっちゃうんだけど、それまでの準備が何だかんだ楽しかったし、妻との絆も深まったように思う。
エンジニアとしてはその瞬間その瞬間では全然何もやってねー！って感じで結構焦りを感じたり、ダメだな〜なんて思ったりしてたのですが、こう振り返ってみるとまぁまぁ頑張ったような。 でも、やりたいことの半分も出来ていないので、今年はもっともっと頑張りたいな。
というわけで、今年も来年こんな風に振り返り出来るように平和に元気にたのしく暮らしたいです。
私的アイドル楽曲大賞2016
Mステのスーパーライブを観てたら、AKB48に知らないメンバーがいて、びっくりしました。 僕が疎くなったのか、AKB48の凋落が始まっているのかは分かりませんが、それでも今年もたくさんのアイドルと音楽が生まれたので、恒例？の独断と偏見に基づくアイドル楽曲大賞を発表したいと思います。
私的アイドル楽曲大賞2016
時間がないのでTwitterリスペクトで各曲140字以内でまとめたいと思います。
第10位：「エルナト」柚希未結
元妄想キャリブレーションである柚希未結（当時は神堂未祐奈）さんの初オリジナル曲です。僕は神堂未祐奈さんがいた頃の妄想キャリブレーションが一番好きだったので贔屓目があるかもですが、もっと売れてもいいのになぁと思います。
第9位：「かちとばせ！栄光のレインボー」ベボガ！（虹のコンキスタドール黄組）
ベボガ！と言えば、ぺろりん先生が有名だと思いますが、楽曲もなかなかいい。特に落ちサビがエモい。アイドルが好きなプロ野球選手の登場曲に使われたら面白いのになぁ。虹コンもそうだけど、今最も勢いがあるアイドルグループでは？
第8位：「きっかけ」乃木坂46
最初聴いた時、AメロとBメロの歌詞がめっちゃMr.Childrenっぽいなと思ったら、後日桜井和寿さんがカバーしてて、合点がいきました。何かに悩んだり迷ったりした時に聴くとミスチルばりに沁みる一曲。
第7位：「アンバランスアンブレラ」妄想キャリブレーション
我らが妄想キャリブレーションの2ndシングル。正直、メジャーデビュー後のEDM路線は好みじゃないんだけど、この曲は流石ソニーミュージックというクオリティで結構ヘビロテしました。ただ、僕はやっぱり利根川サウンドが好きかな。
第6位：「Summer Wind」℃-ute
僕は鈴木愛理さんが日本でNo.1のアイドルだと思っていて、春のツアーでこの曲を生で観て、改めて鈴木愛理をもっと世の中の人に知って欲しいなと心から思いました。これまで色んなアイドルの解散をみてきたけど、℃-uteの解散はまだ受け入れられないです。
第5位：「サヨナラの理由」乃木坂46
橋本奈々未さんの卒業シングル。イントロから泣ける。作曲は乃木坂御用達の杉山勝彦さんですが「まじでこの人天才だろ」と改めて思い知らされました。ただ、サビのダンスはちょっと変じゃない？
第4位：「僕だけのハッピーエンド」3776
楽曲派御用達の3776さんが4位にランクイン。こういう曲があるからアイドルオタクやめられないよね。アイドルの楽曲に偏見を持っている人ほど聴いて欲しい一曲です。まじでエモい。
第3位：「二人セゾン」欅坂46
曲のクオリティも去ることながら、MVのクオリティがヤバイ、そして、何よりも平手友梨奈さんがヤバイ。ぶっちゃけ欅坂46ってコケるんじゃないかなって最初思ってたんだけど、全然そんなことなかった。ごめんなさい。
第2位：「完全なるアイドル」わーすた
いま一番売れて欲しいアイドル。メンバー全員可愛いし、曲もバラエティー豊かでよい。そして何よりパフォーマンスのクオリティが高い。＠JAM EXPO で観て以来、完全にハマってます。
第1位：「サイレントマジョリティー」欅坂46
アイドル史上最高のデビュー曲。イントロからアウトロまでその全部が最高。何も言うことない。
一言
最近在宅気味なので来年はもう少し現場に行ってみようかしら。
伊藤直也さんの一人CTO Nightに一人で行ってきた
巷で話題？のnaoya さんの一人CTO Nightに行ってきましたので、超雑ですがメモを公開しておきます。
イベント詳細： https://doda.jp/event/seminar/20160830.html
オレオレメモなので多少ニュアンス違うところあるかもです。特に二部のパネルディスカッションの部分はかなり文脈を端折っているので雰囲気知るくらいに読んでもらえれば。
もし大きく間違っていることあったらご指摘くださいm(__)m ちなみにアニメの話はあんまりなかったよ。
では、早速。
第一部【プレゼンテーション】最速で最高のアウトプットを生み出すチーム作りとは？
【プレゼンテーション内容】 CTO・技術顧問を複数社経験した伊藤直也氏が、過去の実際の事例をもとに、最高のアウトプットを生み出すチーム作りを解説します。
- 前提として、、、
- 50〜300人くらいの規模の組織が対象
- CTOのマネジメントというよりはVP of Engineering寄りのマネジメントの話
- マネジメントもいろいろあるけど組織マネジメントとヒューマンマネジメントの話が主
開発組織マネジメントのコツ
- 『イシューからはじめよ』って本がいいよ
- エンジニアはプロセス中心というか手段を提供する仕事
- なので、問題設定とどうやって解くかがごっちゃになりがち
- マネージャーは問題解決ではなく問題発見にフォーカスすべき
- 正しい課題にフォーカスすれば自然と問題は解決するはず
- 開発組織のマネジメントはスポーツチームのマネジメントに近い
- 組織（構造）があるから
- 作者: 安宅和人
- 出版社/メーカー: 英治出版
- 発売日: 2010/11/24
- メディア: 単行本（ソフトカバー）
- 購入: 48人 クリック: 660回
- この商品を含むブログ (142件) を見る
内製開発チーム
- 横串の構造が多い（セールス、プロダクト、エンジニア）
- エンジニアとセールスが直でやりとりする
- 次第にリソースコントロールできなくなる
- そのために間にプロダクトチームをいれる
- セールスの要望が直接届かなくなりエンジニアからエンドユーザーがみえなくなる
- マトリクス型組織にする（チームをつくる）
- ラーニング（知識）が蓄積されるような構造が望ましい
日経新聞での事例
- 外注時代にひとりの人が複数のプロジェクトを兼務
- 個人にラーニング結果がたまっていく
- よかれと思って内製開発をはじめたが状況好転せず
- なぜならチームという枠組みが存在しないから
- どうしたかと言うと、、、
- 兼務を解消
- 1チームに1ミッション
日経電子版 開発内製化の取り組み / nikkei web development 2015 https://speakerdeck.com/yosukesuzuki/nikkei-web-development-2015
Kaizen Platformでの事例
- 枠組みがあるのに実質チームとして機能していない
- 1on1してもミッションは同じなのにひとりでやっているという回答
- 原因はPMとエンジニアが1対1で仕事している
- PMが空いた人からアサイン
- コンテキストスイッチが発生
- 隣の人がきついときヘルプできない
- どうしたかと言うと、、、
- PMが直接アサインするのではなくエンジニアのリーダーに
- チームとして会話する
偶然に期待しない
優先度が上がらないことを進ませたいとき
- リファクタリングを推進したときなど
- そういうときも組織（チーム）構造で変化を起こす
- 一休では技術基盤チームをつくった（直接的な売上にはつながらない）
- 決済プラットフォームとかをつくるのもあり
- ただしころころ構造を変えるとラーニング結果が蓄積されないので注意されたし
組織構造は時間的断片
- フェーズにあわせて横と縦のバランスを組み替える
デザイナー横断組織の変遷 http://techlife.cookpad.com/entry/2016/07/15/092518
組織課題の発見とアプローチ
- 『チームが機能するとはどういうことか』という本からの紹介
- この本、読んだことあって内容知っているのでメモが更に雑ですm(__)m
- 心理的安全性と責任
- 両者が高いと学習するのでその状態に持っていこう
- チームが置かれている状況がどこかによって対応方法が変わる
チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ
- 作者: エイミー・C・エドモンドソン,Amy C. Edmondson,野津智子
- 出版社/メーカー: 英治出版
- 発売日: 2014/05/24
- メディア: 単行本
- この商品を含むブログ (3件) を見る
一休での事例
- レストラン事業部：（乱暴に言うと）ぬるま湯だった
- チームごとのミッションの明確化
- ロードマップの精度を向上させる
- 宿泊事業部：（乱暴に言うと）プロダクトはつくれてるけどちょっと疲弊してた
- チームビルディング
- 技術基盤部の確立
ここまで組織レベルの話
ヒューマンマネジメント
- 『ピープルウェア』の有名なお言葉
- 作者: トムデマルコ；ティモシーリスター
- 出版社/メーカー: 日経BP社
- 発売日: 2014/02/05
- メディア: Kindle版
- この商品を含むブログ (32件) を見る
フレーミングをちゃんとやる
- 認知フレーム（思い込みや信念のこと）
- リフレーミング≒期待値調整
フレーミングのコツ
- ちゃんと説明する
- 「やっておいて！」だけではなく「こういう理由で◯◯にやって欲しいからお願い！」
- 最初にがんばる
- 直接対話する
1on1
- 任天堂の岩田社長が1on1やってた
- 組織の課題発見に繋がる
- リフレーミングできる
- お願いごとは相手のバケツが空になってから
- 事前アンケートを採ってそれを題材に話す
- バウンダリーオブジェクト（間にものをおく）
任天堂の岩田社長が遊びに来たので https://www.1101.com/iwata/
（注意）人の話題は強く意識を持っていかれる
- 誰それさんが辞めたがっているなど
- 人の話題に意識をとられすぎないように
信頼を勝ち取る
リファクタリングのために時間が必要です
- なんで？→まぁいいよと言われるようにする
ビジネスvsエンジニアリングの対立構造に持ち込まない
- これを普段やっているとあとでこまる
アンチパターン
文化改革症候群
- 文化とかビジョンみたな言葉が出てきたら危険
変化にあたって現状否定
- 必要以上に現状を否定しない
- 未来思考で説く
サーヴァント型リーダーシップの罠
- 雑用をいっぱいしてくれる
- でも大きな方向性を示してくれない
- いざというときの意志決定ができない
- Fate/Zero観ろ
123: The Grail Dialogue (Naoya Ito) - Rebuild http://rebuild.fm/123/
エンジニア幸せ向上委員会
https://twitter.com/naoya_ito/status/770537380906274817
力を集約する != みんなが同じことを考える
- みんながみんな同じことを考える組織…宗教？
- 価値観の異なるメンバーを同じゴールに向かわせる
即効性のあるHOW TO
- 壁打ち相手を見つけよう
- 技術プロセスの課題解消（即効性がほしいときに）
第二部【パネルディスカッション】伊藤直也氏のマネジメントお悩み相談室 withソラコム 玉川憲氏
【パネルディスカッション内容】 事前にマネジメントに関して寄せられた「お悩み」に対して、伊藤直也氏がアドバイスを行います。エンジニアの皆さまから寄せられた「お悩み」を伊藤直也氏にぶつけてくれるのは、自身もマネジメントや技術統括の経験を豊富に持つソラコムの玉川憲氏。
メンバーが守備範囲外のことをしてくれない
- 日本っぽい（守備範囲外のことをやると怒られるじゃん）
- 指示待ち人間がいるのは待っているほうが得をするから
- 守備範囲を変えないといけないのでは？
プランナーとうまくいかない
- インフラエンジニアとアプリケーションエンジニア仲悪い問題と似ている
- 昔インフラエンジニアがSLAを守るために重いバッチ処理をkillしたことがあった
- AWSが生まれたのはインフラエンジニアとアプリケーションエンジニアの会話をなくすため（技術で解決パターン）
デザイナーやエンジニアのことを理解してもらうには？
- まずは信頼してもらうこと
- でも難しいかも
- JapanTaxiの川鍋さんみたいに技術のことわからないけどエンジニアリングを大事って言ってくれる人がいると楽
会社（組織）の思考をきりかえるには
- 一休の営業はIT企業だと思っている人が多くない
- 最初はもどかしかった（こんなことも知らないのか！
- でもそういう多様性を受け入れていくことが大切では？
経営陣が人件費を払っているんだからエンジニアは売上が上がる機能開発をしろ！と言ってくる
- CGMの会社だと難しい（ソシャゲなら話は別）
- お前が言うな！と思うけど言っちゃダメ
- 難しい
マネジメント職につく覚悟がつかない
- 調整ばっかりしているのは確かに辛い
- 1on1症候群にならないよう
キャリアを含めた技術力が上の人との1on1
- そもそも技術力がある人が人として上ではない
- 1on1で技術の話はあまりしない
- 道を指し示す必要はない
- 壁打ちでいい
- ソラコムではスタンドアップミーティングを事前にbotでやる
- シェアしたいこと
- 改善したいこと
- 改善してほしいこと
ROIで優先順位をつけられるとリファクタリングとかできない
- 同列に並べちゃいけない
- ロジックで攻めると数字で負けるからよくない
- 信頼感とか寝技に持ち込む（そしてチームつくっちゃう）
採用についての質問
- コンテンツをひっぱって採用できる会社は限られている
- ブログとかメディアやってるのは既に大きなサービスがある企業の付加価値
- Job Descriptionを外資はちゃんと書く
- 日本は3行とか
- 一休でもブログやるとかnaoyaさんを全面に押し出したけどあまりうまくいかず
- 転職エージェントに出しているJob Descriptionを見直した
- 面接官が上から目線はNG（エンジニアに多い）
- 悪い噂はすぐに広まるのでちゃんと説明する
- AWSの社長？はずっと握手してきたw
開発の速度を定量化したい
- 相対的にしかみれない
会社全体の技術力をあげていきたい
- 技術力をあげていきたいというエンジニアは実は少ない
- ドメイン知識が豊富な人もいる
- 新しいことは知らないけどコンピューターサイエンスやアルゴリズムの詳しい人もいる
- ワークライフバランスを大事にしている人もいる
- いろんな人がいるから多様性を大事に
- いまあるカードをどう組み合わせるか
- みんなが勉強マンになる必要はない
- みんながそうなるとモダンだけどやたらと複雑になること多い
- 勉強マンとかは技術基盤にいれたり
- リーダーシップとってる人が勉強してれば勝手に真似してくる（コントロールはできないけど）
1on1の頻度
- 1週間に1回やると話すことがなくなることがあった
- フェーズによる
- 本末転倒にならない頻度でやる
信頼を得るには
- 一休の場合は元々技術顧問だったので。
- 地道に積み重ねるしかない。
ひとこと
Rebuildで聴いたことがある話も多かったけど、今まで細切れで聴いていたこともひとつのプレゼンテーションとして綺麗に整理されていたし、とても参考になりました。 僕は今の会社ではマネージャー職ではないけど、マネジメントという仕事も組織としてよいサービスやプロダクトを人々に提供するための手段の一つだと思うので、どんどん取り入れられるところは取り入れていくぞ！
にしても、やっぱりnaoyaさんの話は分かりやすいなぁ〜。
PHPBLT#4@Mercariで初LTキメた
PHP BLT #4
PHP BLTはメルカリさんが主催しているPHP界隈の勉強会で、前々から参加したいなーと思っていたのだけど、4回目にしてようやく参加することが出来た！とてもよい雰囲気で、勉強になるLTもとても多かったです。 最近はGolangとかElixirみたいなプログラムマッチョが好む言語に目が行きがちだったけど、久しぶりにPHPいいなと思った。
LT
というわけで、タイトルにある通り人生初LTキメてきました。メルカリCTOの柄沢さんの後ということもあり、実はかなり緊張してたんだけど、
PHP BLT #4 に参加しました - 何か着ていればいいよ
上記のまとめブログ（ありがたい）で、
初LTとのことでしたが、そうは思えない安定感で良い話を聞けました。
と書かれていたので、バレなかったようだ！
ちなみにスライドはこちら。エモ要素強めです。
ちなみに、スライドテーマはPHPカラーなんだよ！（言うの忘れてた）
KPT
スクラムっぽく振り返りをしてみよう。
Keep
- 色んな人にいい話と言われた。（どうでも）いい話ではないと信じたい。
- 緊張が表に出なかったっぽい。
Problem
- ペース配分足りなくて、最後駆け足になってしまった。
- オーディエンスとのコール＆レスポンスが足りない。（つまり、アドリブ力がない）
- 海鮮が苦手なのであまり食べ物が食べれなかった。
Try
- いい話だけではなく、もっと技術的な発表が出来るようになりたい。
- ともだちをつくる。
- 好き嫌いをなくす。
今年はより成長するために外部での活動も増やしていきたいと思っているので、みなさんよろしくお願いいたします。
最後に、素敵な場を提供してくれたメルカリさんに多謝！
サイレントマジョリティー
ただの神曲だった。。
欅坂46のデビュー曲である『サイレントマジョリティー』のMVが公開されました。 メチャカリ（mechakari）のCMの段階から良曲の予感がぷんぷんしていましたが、フルはもっと最高だった。
個別の評価としては、
- ドラマチックなイントロ：100点
- クールなAメロ：90点
- 転調しまくりのBメロ：120点
- 語呂の悪さが癖になるサビ：90点
- 歌詞：100点
といったところでしょうか。誰が作曲してるのかなー。
乃木坂46のデビュー曲『ぐるぐるカーテン』もこれまでの48グループとは一線を画する無菌室の閉じ込めれているような完全無欠のアイドル性があって最高だったけど、『サイレントマジョリティー』はアイドルと普通の女の子、大人と子供の間で揺れ動くリアルと矛盾が感じられてまじクール。
その意味では、『制服のマネキン』に近い楽曲だと思うんだけど、そういう楽曲をデビュー曲に当ててくるのが凄い。 個人的には21世紀のアイドル史上最高のデビュー曲だと思います。
どうでもいいけど、メチャカリ（mechakari）とメルカリ（mercari）って似てるよね。