FC2ブログ

makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「Developers Summit 2019 Summer」に行ってきました

2019/7/2(火) 「Developers Summit 2019 Summer」に行ってきました。

公式サイト
https://event.shoeisha.jp/devsumi/20190702

2月のデブサミに続き、なんとか仕事に都合をつけて夏サミも参加なのです。




以下、聴講メモ。(自分の復習用にダラダラ書いただけ・・・)

愛されるプロダクトをつくるエンジニア組織とは――「テクノロジー」「開発プロセス」との緊密な関係


【A-1】 10:15 ~ 11:00 及川 卓也[Tably]
セッション:https://event.shoeisha.jp/devsumi/20190702/session/2065/
Togetter:https://togetter.com/li/1372189

愛されるプロダクト


テクノロジー、開発プロセス、エンジニア組織が連携される先に愛されるプロダクトがある
リーン開発で、MVP(Minimum Viable Product)は製品の価値を凝縮したミニマムな体験できるものを指す。
愛されるプロダクト、という観点ではMLP(Minimum Lovable Product )という言葉も出てきた。

所有 → 利用 → 体験


音楽業界はレコード → カセットテープ → CDという、フォーマットが変わるイノベーションが起きた。
次に、AppleがキラーハードウェアとしてiPodを出したことで、一気に携帯音楽プレーヤーが普及した。
次に、所有してなくてもいい、契約していれば聞き放題というサービス(iTune)が出た。
フォーマット → 携帯 → 体験 という時代変化があった。
所有 → 利用 → 体験 という価値の変化があった。
背景
・シェアリング需要の高まり
・コネクテッドが当たり前に
・富の概念の変化

持つことに価値がなくなってきている。
所有よりも利用や体験というサービス化の波がきている

マネタイズ


1990年代後半に普及しライフラインになったWebの影響が大きい。
つぎにスマホがWebのトレンドを受け継ぎ広めていった
我々はWebに対して「購入しないといけない」という考えはほとんどない。お金を払わないと使えない、とは考えていない。
お金を払わないと中が見えない、ということはない。
パッケージ開発の頃は、マネタイズという言葉はまったく使わなかった。なぜなら、売ったらすぐ収益になったから。
Webは違う。ユーザは集められる。じゃあどうやったら収益化するか?
サブスクリプション、アプリ内課金は、すべて使い続けてもらってはじめて収益化できるし収益が継続する。
これがサービスを考えないといけない背景。使われ続けなければならない。好きで使い続けてもらう。
選択肢がたくさんある中、使い続けてもらうためには愛されていなければならない。
スマホが出たときは、アプリを作ればユーザに使ってもらえると思っていた。それが幻想だと気づいた。
長期に使い続けてもらうのがいかに大変か・・・。ユーザはどんどん離脱していく。

AARRRモデル



出展: Webマーケティングメディア ferretニュース【テンプレート付】AARRRとは〜サービスを成長させるための基本戦略

いかに離脱を防いで収益化に繋げるか。
「Retention:継続利用」から「Referral:紹介」へ行ってもらわなければならない。
それには愛されることが重要。

開発プロセス


開発プロセスはどうあるべきか。
不確かなものを確かにする必要がある。
生き方も価値観も、ぜんぜん違う。性別や年齢でグルーピングできない時代。
ひとつの正解を見つけて作り、売っていくことがいかに難しいか・・・
最初から正解を見つけることは不可能。じゃあ、どうすればいいか?
→ 仮説検証を素早くすることにより正解にたどり着いていくことが大事。

・Lean
・Agile
・DevOps

Lean


仮説、検証の考え方はLean。
アイデアがあり起業することがほとんど。でも成功になるまでに資金が枯渇してしまうのがスタートアップ。
資金が枯渇するまでに証拠を集めないといけない。
モノを作らないでも、検証できるならしましょう。ヒアリングやペーパープロトタイプとか。

Agile


仮説検証でMVPが出てこれば、アジャイルで改善していく。
アジャイルはWFより仮説検証に圧倒的に向いている。
WFは逆戻りしないこと前提。設計が上位で、実装が誰でもできる、というのは違う。
作ってだめなら設計をやりなおす、という考えはあって当然。
制御された環境下で実装して検証してもう一回戻すサイクルがアジャイル。

DevOps


リリースしたあともDevOpsという考え方がある。
昔は工場出荷すれば一段落だった。工場出荷までがハードワークだったけど、そこで一段落。
マイクロソフトでは、工場出荷の後の保守は別体制だった。
Googleに入社して、それが全く違った。リリースしてからが始まりの部分がある。
Webサービスなので、リアルタイムで使われてる状況がわかる。
仮説検証と運用が一体化して正解にたどりついていく。
ユーザの利用状況を把握することが必要となる。
理想は、開発運用者が利用者の状況を把握すること。
でも、ヒヤリングさせてください、となっても中間事業者までしかとどかず、エンドユーザまで届かない。
ユーザの利用状況の把握を含めてDEVとOPSを一体化する必要がある。

フレームワーク


Lean
Agile
DevOps

これらを使うことがベストプラクティスかな。
でも流行り出すと、日本人は真面目なのでフレームワークに必死になる。
ただし、魔法の杖や銀の弾丸では無い。

ウォーターフォール全盛のマイクロソフトでも良い製品はリリースできている。
型でなく、魂が大事。そうしないと型が型で終わってしまう。

プロダクトマネージャ


ソフトウェア開発に必要な職種のうち、プロダクトマネージャって職種が重要な職種。
プロダクトは事業とほぼ等しい。
トータルなユーザ体験、カスタマーサクセス、当然サポートも入ってくる。
狭義のプロダクトでなく、営業やサポートやマーケティングなど組織横断的なチームが必要。
これらを率いていく人がプロダクトマネージャ。
CEOと違って人事権があるわけではない。
意思とビジョンを持って率いていく必要がある。
MiniCEOとも呼ばれる。
糊のような存在で、すべてのものを拾い上げる。

プロダクトマネージャとエンジニアの役割分担


プロダクトマネージャは、何を作るか、Whatを決定する人。WhyとWhenも決める。
エンジニアは、どうやってのHowを決める。
必要以上にどうやって作るか、をプロダクトマネージャは考えないほうがいい。エッジが効いたものがでてこなくなる。
プロダクトマネージャとエンジニアには、緊張感のある関係が両者に必要。

人事的な職種構成




職種は別にする。
プロダクトマネージャとエンジニアの組織は分ける。
エンジニアリングマネージャという職種がある。

1.プロダクトマネージャ
2.エンジニアリング
  2-1.エンジニアリングマネージャ
  2-2.エンジニア
  
昇進はその職種のみの間で行う。
別の職種に行くには異動する。

職種を明確にするのが、ジョブ型雇用。
日本はメンバーシップ雇用。職種を明確しない。終身雇用な年功序列とともに採用される。

エンジニアリングマネージャ


エンジニアリングマネージャは成長し続けるエンジニア組織を構築するのに責任を持つ。
個人より組織のことを考える
長期的な視座に立つ。
自分の技術的な貢献よりも、組織の成長に貢献することが求められる。

TechLead (TL)




エンジニアはキャリア変更しない限り、マネジメントにつかない。
でも、職位が上になるとチームの成長にあなたも手伝ってください、となる。マネージャを補佐する。
TLの中には一部、マネージャになってもいいよ、というケースが例外で存在する。
マネージャもTL的な資質が求められる。
マネージャはマネジメントだけでなくリーダシップが求められる。
技術がわからないと技術者を評価・育成できない。表裏一体。

組織構造


組織構造は2パターンある。
 1.職能組織
 2.事業主体組織

どちらにしても実態はマトリクス型。
職能組織は各職能から人が出てチームができる。

某ゲーム会社の組織構造の例




職能ごとにエンジニアリングマネージャとしての部長と、サブマネージャがいる。
サブマネージャがキーマンで、炎上している箇所に投入される。マネジメントもやるけど手をゴリゴリ動かす。

ジョブスクリプション作成のすすめ




職務規約書を作ったほうがいい。自明と思わずに作る。自分の役割を表明する。

すべてのエンジニアは、少なくともすべての職種(QAとか運用とか)を少しは経験しておかないといけない。
そうすることで相手の目線から考えられるようになる。

スクラップ&ビルド


事業サイドは仮説検証を早く回せることが嬉しい。
→ スプラック&ビルド

組織サイドは集合離散
→ できるだけ集まり立ち上げて、移っていくことも可能であるようにする。成長する組織として、人材流動性に対策する。

壊すことを厭わない。すぐに復旧できるシステムにすることが大事。
→ クラウド、マネージド活用、コードによる記述(属人性の排除)

ドキュメントは読まれないことがある。なのでコードに詰め込んでいく。

大事なのは、身の丈に合わない開発をして引き取れなくなる、ということを避ける。
自社で運用できることを前提にして考えることが大事。

柔軟性と規律


組織全体の規律が必要。
マイクロソフトでも、好きにつくっていいよね、の中にも制約が必要。
言語とかツールの共通化と統一も必要。

柔軟性と規律の両方が必要。
組織がテクノロジーを使いこなせるか、何をできるか、を考えないといけない。

プロダクトマネージャの認知を高める活動


最近、プロダクトマネージャの認知が高まってきた。
→ 調整役で終わってないか?


事業側が作った雑な企画と、開発チームの間に入って、疲弊してしまうのがよくある。
板挟みでなく対等な関係にすることが大事。
プロダクトマネージャが企画を温めるだけでなく、全員がユーザに何を価値を与えるかを考えてほしい。


コードの向こうにユーザを見る




「自分の書いてるコードの価値がどこにつながるのかを考えてみてほしい」

プロダクト愛


なんで愛されないといけないか、というと、使ってくれるとエンジニアは嬉しいから。
テクノロジーで社会を変えて、体験を喜びとして、もっといいものをつくりたい、というパッションが足りない。
自分が作ったものが使ってもらって、凄い嬉しかった。
プロダクト志向という考え方自体がプロダクトを育てていく。


今後の生き方についてサラリーマンエンジニアが人生半ばにして考えてみた


【A-2】  11:15 ~ 12:00 上野 淳[ディライトワークス]
セッション:https://event.shoeisha.jp/devsumi/20190702/session/2066/
Togetter:https://togetter.com/li/1372207

このセッションの結論: 環境に流されるエンジニアになってはいけない

今日のテーマ
・棚卸し
・決心
・実行

組織を作っていくための知見


組織を作るのはマネジメントの仕事じゃないか、というイメージがあるが、そうじゃないと思っている。
組織を作るのは我々で、エンジニア一人ひとりの役割。

ゲーム業界


ゲーム端末が高性能化し、開発規模も拡大している。モバイルゲームも例外ではない。
開発チームが巨大化していて、自社のFate/Grand Orderの開発チームで100人以上いる。
役割が細分化し、専門職が増えている。

ノウハウの共有や獲得をチームや社内だけで完結させるのは無理がある。
→ 外に転がっているノウハウを拾いに行く。ネットで読むというよりも、外に出ていく。
→ そこに集まってる人がどんな関心を気にしているのかを知ることが大事。

開発期間が長期化している。開発フェーズは3フェーズある。
  1.広げる
  2.進める
  3.畳む

畳む、が一番大変。夢を広げても、ゲームにはオチをつけないといけない。
3つのフェーズそれぞれに必要な技術や心持ちは、体験しないとわからない部分がある。
→ 昔は、体験できた。
→ 今は、同じことを3回経験しようとすると、リリース1回に3年かかるので、10年くらいかかってしまう・・・
→ 10年かけてノウハウを確立するのは遅い。役立つノウハウを体験だけから得るのは難しい。
→ 外に転がっている体験談を聞きに行く。
ネット読めば分かった気になるけど、外に聞きに行って、自分なりの疑問をその人に質問して、自分の疑問に対して回答をもらうのが重要。

ゲームエンジンの寡占化が進んでいる。
Unityとかのゲームエンジンは、目的を果たすための動力源なだけ。
いいエンジンを使ったからといっていいゲームができるわけではない。
でも、ゲームエンジンを使って、それで浮いた時間でゲームを創ることができる。
ゲーム開発は試行錯誤が必要なので、時間が必要。
その時間を捻出するためにゲームエンジンを選択する。

棚卸し


自分のやりたいことを棚卸ししてみようと思った。
今47才で、60才定年とすると残り13年で、育成を3年やるとして、残り10年。
ゲーム1本に3年かかるとすると、あと3本しか作れない。
→ このままでいいのか、と考えた

このまま60才まで働くのを前提として考えていいのか、と思った。
→ 「まま60問題(mama-60-problem)」と名前を付けてみた。

35歳定年節の次はこれじゃないか、と思っている。
今の状態が今後も安定して継続すると信じて疑わない状態。

やりたいこととやれること、もう一度考えてみよう。
 ・職業を選ぶ時の、やりたいこととやれること
 ・仕事をする上での、やりたいこととやれること
この2つは違うかなと思っている。
職業を選ぶときは、やれることを基本で考えないと、夢だけで追いかけると終わってしまう。
なので、やれることで職業を選ぶ。
職業を選んだあとは、やりたいことを軸に考えればいいんじゃないか。
ただし、やれないことも努力することが前提。

決心


ゲームプログラマーとして今後も生きていく、という選択をした。これが半年前の出来事。
決心したことは、変わることを恐れるのではなく、変わらないことを恐れよう

まずやってみるを軸に考えよう、と決心した。
このままじゃない60才までの人生、とは何か?
前提を覆そう。
→ 前提って?
→ 環境を変えるという決断をした。セガを離れる。退路を断って自分を試す。

決心してもいろんな障害がある。まず経験が邪魔をする。
ミスしたら再発防止を迫られる。なので一度失敗したことは再度したくないのでいろいろ考える。
でも、環境が変わると、これまで失敗したことが逆にうまくいくこともある。
なので経験が邪魔をする。

不安が邪魔をする。
→ じゃあどうすればいいの?
→ 不安でいいんです、と思った

不安を感じたことでどう立ち振る舞うか、で大きく変わる。
不安から目をそらすのは、せっかく不安を感じたことを台無しにする。
不安は自分が変わるきっかけ。
不安を感じたならそれは進化の予兆。
不確実な未来に目を向けている証拠。

覚悟を決めて人生を進もう。
→ 覚悟ってなんだ?
→ 失敗しても、自分のせいにして受け入れる状態が整った状態だと思っている。

実行


選択が間違っているかどうかはわからない。
間違っていたかどうかは今後の自分の行動で決まる。
正解になるように動けばいいかな、と思っている。

無意識的選択には気づきにくい。これが怖い。
自分で選択した意識がないので、時間が過ぎてしまってタイムオーバーになる。
今のエンジニア人生は、本当にあなたが選択したものですか?というのを問いかけたほうがいい。
環境も含めて自分で構築していますか?
自分ができることを今ちゃんとできているかを常に考えていく。
考えなくてもどんどん時間は過ぎていってしまう。

不安でもいいんです。
心理的安全性というのがよく言われるが、チャレンジするには失敗しても大丈夫だ、というのが大事。
でも、そういう環境があっても本人が一歩踏み出さないとなんのチャレンジも起きない。
最後は個人がやるかどうか。

何事も経験してみるのが一番よい。
経験は時間が経つと美化される。
経験が、時が経って通用しなくなることもある。
根拠がない自信となっても、自分にとって強いものとなる

自分に揺さぶりをかけて想定外の解にたどり着く。それこそが成長なのでは。
必要なのはちょっとした勢い。失敗しても、てへぺろ、でなんとかなることも多い。

まとめ


環境に流されるエンジニアになってはいけない。
建築家のように、どこに何を立てるのかを自分で決める。
最高の建築物を設計して作っていく職業がエンジニア。

環境を創るエンジニアになろう。
環境もエンジニアリングの対象。

LifeOps(自分エンジニアリング)もやりましょう。

結局、環境を変えて自分はどうなった?
というのを13年後のデブサミ2032でお伝えできれば、と思っている(笑

「ただ純粋に、面白いゲームを創ろう」という会社の理念に共感してやっていく

実践 Engineering Manager ~理想のエンジニアチームを目指して~


【C-3】 12:15 ~ 13:00 酒井 篤[ミクシィ]
セッション:https://event.shoeisha.jp/devsumi/20190702/session/2085/
Togetter:https://togetter.com/li/1372221


ランチセッションです。サンドイッチ美味しかった \(^o^)/


1.はじめに


長く在籍していたのでエンジニアリングマネージャを引き受けたが、ドメイン知識が豊富だと新しいメンバーが気軽に聞いてくれてコミュニケーションできたのが良かった
今はSREチームに所属していて、18人のマネジメントをしている。

エンジニアリングマネージャが目指すもの
 ・複数のエンジニアの生産性を最大化する
 ・事業の目標を大幅に超える成果を創出する

ストレスを抱えないようにしよう、と思って決まり事をマネージャになって決めた。
 ・忠実に目標を達成しよう。達成に必要なことを1つずつやってく
 ・わからないことはオープンに伝える。
 ・できるだけ自分が決裁可能な予算を確保する。(ここが難易度高いけど強く意識した)
 ・楽しむために、少しでもコードを書く。
 ・キャリアとして充実させる

マネージャをやってると組織最適のために行動する。
マネジメントという汎用的な技術を学んで、給料も上げようと思う。
これをやったら給料が上がるのか、を常に考える。

2.理想のチーム


理想さえあれば、やるべきことや優先度が見えてくる。

2つのキーワード
 1.ボトムアップ
 2.学習する

ボトムアップ
・エンジニアやチームの意見の重要性をマネージャやPOや経営者などが全員が理解していることが重要。
 → なんとなくそういう空気にするの難しいので、意識的に空気とか場を作っている

・様々な課題はエンジニアの責任によって解決されるべきとエンジニア自身が考えていることが重要。
 → 誰かが勝手に解決してくれるものではない。自分で行動していくような必要性が大事。
 → どうしたらエンジニアが行動できるようになるかをマネージャが考えていくこと大事。

・「大きな声」に傾きすぎないためのコミュニケーションができているか
 → あの人が言ってるからしょうがない、みたいな思考停止はよくない。
 → 何か言われたとしても、自分の頭で考えられるようにコミュニケーション方法を確立しておくことが大事。

ボトムアップの効果
・チーム内の意見や行動の自由度が上がっていってリスクに寛容な空気が生まれる
・トップダウンよりも責任が生まれて、自分が言ったんだからやる、という適切な緊張感が生まれる

学習
開発プロセスに対する学習とか、成長のために何を選択すべきか、というのが重要

様々な視点による振り返りが重要
  ・目標に対する進捗とか定期的に振り返ること重要
  ・チームの振り返りの時間が確保されているかをマネージャが気にして場を作る

他人やチームの失敗、意見の対立を冷静に受け入れることができる空気があるかが大事
どう立ち回るかのルールを決めて、こーなったときはこう対処しよう、と決めておくと、対立してもうまくできるし、好奇心や気づきが訪れる
チームが熱くなりすぎると、いろんなこと見落としてしまうんだな、とか気づいた

学習の効果
  ・失敗が糧になってチャレンジが増える
  ・リスクに対して寛容になる
  ・ふりかえりの改善アクションによりチームが成長していると感じるし、クリアしたときの充実感を感じる

ボトムアップと学習は、相互に必要な要素
心理的安全かつ責任の大きいLearning Zoneが重要

ボトムアップと学習、片方だけやってるとどうなるか
  ・学習してるけどボトムアップできず、意見がトップダウンで降りてくるだけだと、保守的なチームになる
  ・学習できてなくてボトムアップばっかやってると、個人が好き勝手やっていって対立が起きて纏まりがないチームになる

3.エンジニアリングマネージャの役割



理想のチームを作るために
  ・障害となる事象の発生を予防する
  ・障害にいち早く気づけるようにする
  ・障害があれば、率先して排除しにいく

エンジニアがイライラらすることをマネージャが取り除く

マネージャがやれること
  ・チーム運営に関わる最低限のルールつくり
  ・具体的でアクション可能な目標を作る
  ・ふりかえりの場を作る

チーム運営にかかわる最低限のルールを作る
 ・メンバーを抑制するものではない
 ・メンバーを守るルールを作る


 ・改善の時間にどのくらいの時間を使っていいのかの方針を決める
 ・会議で議論の発散したときの対処の仕方を決める

 → 抑制するというより、メンバーを守るルールを決める。

具体的でアクション可能なチームと個人のルールを作る
  ・トップダウンの目標でなく自分たちで考える
  ・OKRのフレームワークを使う
  ・個人の目標も自分で決めて、マネージャの求めるものとの差を埋めていくことで、自分の存在意義を感じやすくなる

定期的でオープンなふりかえりの場を作る
  ・失敗と成功のどちらも賞賛する場を定期的にもつ
  ・短期的なふりかえりを多く持つ
  ・失敗した時は具体的な改善プランを出す

4.フレームワークを用いた経験主義マネジメント


・フレームワークを用いると、「形から入って、いいのか?」とか言われるけど、形から入ると楽
・フレームワークを身に着けたらどこでも使える
・フレームワークは最初へたでも、くりかえし経験することでフレームワーク自体の使い方もうまくなる
・「振り返り」のワークフローが用意されているフレームワークを採用する

OKR
 ・事業目標に対して何をすべきか自分たちの頭で考える
 ・自分の能力の重要性を感じやすくなる
 ・客観的な指標で活動を振り返りやすくなる

17人の間で、無かった会話が生まれた
お互いが何を考えているか、どこに貢献したいか、発言に対する信頼性が生まれた
それだけで価値あったかな、と思う

1on1
 ・2週間ごとに30分ずつお全てのメンバーとやる
 ・日々の行動とか、キャリアとか、内省的な振り返りの場
 ・自分から、個人に対して良かったことを必ず1つ伝える
 ・進捗を阻害する要素を取り除く方法を一緒に考える

スクラム開発
 ・スプリントレトロスペクティブがとても重要
 ・短期間のふりかえりで失敗の規模を小さく保つ
 ・着実な改善が期待できる

振り返りのマンネリ化問題
 ・複数の振り返り方式を用意して視点をかえることで刺激になる
   ・KPT方式
   ・Airbnbの本の「象、死んだ魚、嘔吐」 ・・・ キツつい言葉で書いてあるので、刺激がすごくあった




何度でもローンチせよー読書感想「エアビーアンドビー ストーリー」(リー・ギャラガー) より抜粋:

象、死んだ魚、嘔吐
 ・「象」は口に出さないけれど全員が知っている真実
 ・「死んだ魚」は早くごめんなさいをしたほうがいい悩みのタネ
 ・「嘔吐」は断罪されずに胸の内を話すこと。つまり「ぶっちゃけ」

社内を振り返ってほしい。こんなに長時間働いたら生産性落ちるしかねえよという「象」を放置していないか。
上司のパワハラという「死んだ魚」が異臭を放ったまま見て見ぬ振りはしていないか。
「ぶっちゃけ」できずに、苦しみを抱えさせている人がいないか。
エアビーはこのキーワードを大切に出来たけど、日本では一つも口にできない企業もありそうだ。
ローンチしたい、我々も。


フレームワークは3つ
 ・1on1,
 ・スクラム開発
 ・ORK

5.チーム独自の学習・ボトムアップ文化


振り返りの中から自分たちで学習して、ちょっとずつやっていった結果、できた文化がある

ユーザーストーリーマッピング
 ・大きな新機能の開発をするときは必ず実施する
 ・ユーザのことを考えて、抽象的な要求をどう解釈するかを、エンジニアが一緒に解釈するプロセスを踏むようにしてる
 ・要求に対して俯瞰的に視野を持てるので、行動しやすくなる

ぱっとタスクが横並びになるので、エンジニアが個人で交渉しやすくなる
→ いろんな行動が勝手に起きてくる。エンジニア自身が気づいて勝手に行動するのを促進する。

輪番制のリリースマネジメント
・リリースマネジメントをプロジェクトマネージャがやるのではなく、エンジニアが交代でやる
・QAの進行や調整などをエンジニア自身がやる
・自分の開発活動の影響範囲を認識し、リリースに関する問題の改善を行う

非エンジニアの人がやるといろんな混乱があった。なので、エンジニア自身がやる

バックログ準備会
 ・スプリント中に1回はやる
 ・CSやプロモーションも集まって、さまざまな課題を出し合う
 ・エンジニアも参加して、エンジニア視点からも発言、提案する
   ・エンジニアだからこそ提案できるものがある
   ・プランナーがヒヤリングするのではなく、エンジニア自身が自分から持ち込む
   ・技術的負債を感じているのはエンジニアなので、みんなに説明して対応する時間をオープンに話あって、時間をもらう

プロジェクトチーム制度
・エンジニアがリーダーとなり、実施したい改善などを一式おまかせする
・リサーチとか目標つくるとか施策の実施とか全部おまかせ
・マネジメントの領域をぜんぶ外して全部おまかせする
・各メンバーのリーダーシップを促進する

6.まとめ


明日からマネージャになるあなたへ
 ・マネージャになる人は、多くの不安を持っている。というのも、周りにマネージャがあんまりいない。
 ・エンジニアチームはボトムアップで常に学習を行うことが理想。
 ・フレームワークを使って楽しましょう。フレームワークが形どおりだったとしても、そんなに問題ないかなと思ってる。

大事なこと
 ・汎用的なルールを作って、ルールのもとで考える
 ・常に優先度を考えて行動

あなたのチームはボトムアップで動いていますか?
学習できていますか?

組織にテストを書く文化を根付かせる戦略と戦術


【B-4】 13:15 ~ 14:00 和田 卓人[タワーズ・クエスト]
セッション:https://event.shoeisha.jp/devsumi/20190702/session/2077/
Togetter:https://togetter.com/li/1372231



「テストが無いコードはレガシーコードだ」 by レガシーコード改善ガイド

2つの"ならわし"

1.テストを書く時間はない
・ワインバーグさんの因果ループ図で、矢印の根元と先が白抜きの〇は、逆の作用をするという意味
・ストレスが増えるとテストは減る
・テストが減ると、動いているか分からないから、ストレスが増える
・ストレスが増えると、更にテストが減る。すると更にストレスが増える
→ 死の無限ループ・・・

因果ループを打破していかないといけない
ケントベックはノードの場所を入れ替えて、自動テストを入れた
テストファーストにして自動化する
自動テストを入れて、現状が把握できると、ストレスが減る
→ 現状の把握の度合いが増えると、自動テストの投資が増える
→ するとストレスが減る
トリックは、テスト自動化と早めのテスト

「テストを書く時間がないのではなく、テストを書かないから時間がなくなるのです」 by James Grenning

2.動くコードに触れるな
動くコードに触れなけば安全かというと、そうではない
今日は周りがどんどん変わるので、パラメータが多くなっている
コードだけ凍結しても、周りがどんどん変わるので、動かなくなる。先が無い・・・
→ 様々なセーフティーネットを貼って、自信を持ってリリースし、すぐ巻き戻せるようにする
なんかおかしいなら、即安全な状態にまで巻き戻せるセーフティーネット
その1つの重要なファクターが自動テスト

文化を変えていく
文化の醸成は年単位の事業になる。3~5年かかる。

銀の弾丸は無い
・状況は現場でぜんぜん違うので、泥臭い戦いが必要
・導入を目的にしてはならない

イマココから始める
目覚めてしまった人は夢を描く。ToBeを描く。でも、現状の時点からToBeまでが遠すぎる・・・
人は自分の速度でしか成長できない
去年の自分たちより明らかによくなっている、を積み重ねることが大事
人を動かす言葉「まわりはもうみんなやっていますよ」が日本人は刺さりすぎるので劇薬なので容量用法を守ること

数の面から理論武装する
ユニットテストとか自動化テストを導入すると、対策コストが安い前工程で不具合を見つけられる
テスト駆動開発の導入効果として、TDD導入してないときの欠陥密度を1にすると、マイクロソフトは欠陥密度が91%減った
MS Visual Studioは、マイクロソフトが本気をみせてテストコードを書いて、立て直した。

エリクソンのTDD導入効果の論文が独特なのは、アンケートとったこと。
テストを早期に書くことは、早く考えることになる。早めに気づく。

TDDは開発工数を減らす、というアンケート回答が50%あった。
→ 実際は実装工数は増えているのに、半分の人が、開発工数は減ると答えた。
→ コーディングの時間が16%増えてるに開発工数が50%も減ってると感じるのは、どこかが減ってるから。
→ 実は、デバッグの時間が減っている。

TDDを初めて、自分自身、デバッガーは使わなくなった。

テストは品質を上げない
・テストを書くだけでは、良くならない。品質が分かるだけ。
・体重計に乗るだけでは痩せないのと同じ。



2つの道しるべ
1.レガシーコード改善ガイド
 ・レガシコードのジレンマ
  コードを変更するためにはテストを整備する必要があるけど、そのテストを書くためには、コードを変えなければならない・・・

レガシーコード改善ガイドはstackoverflow.comの非言及率1位の本

2.レガシーソフトウェア開発ガイド
 ・選択肢の1つ「ビッグ・リライト」は、モダンな言語とアーキテクチャで書き直す。
  → ハイリスク・ハイリターン。成功確率は低い、魅力的だけどアブナイ。

 ・「リファクタリング」と「ビッグ・リライト」の中間の道が必要
  → リアーキテクティング

リアーキテクティングは、中規模に切り出して刷新していく、の繰り返し。
大きい泥団子を、責務を全うする単位に切り離す。
ミドルリスク・ミドルリターン。
泥団子を「本丸とよく言う。本丸を切り崩す。

どこかにテストを書いていくか
トリアージが必要。何が一番やばいですか?という質問をする。
よくあるのが、決済とかお金まわり。

バグ修正から手掛けるのもオススメ。
というのも、不具合はまんべんなく発生するのでは、不具合は局所化しているから。
→ 不具合が発生した箇所の近くは、また不具合が発生する可能性が高いので、投資対効果が高い。

「傷んだ箇所」と「手が届く果実」
どこから手を付けるかは、難易度、リスク、価値、の3軸で考える。 by レガシーソフトウェア改善ガイド

・傷んだ箇所モデル ・・・価値が高いところからテスト自動化していく
・手が届く果実モデル ・・・ リスクも難度も低いところから自動化していく

テストのトリアージ
「リーン開発の現場」では
 ・リスク
 ・手動テストのコスト
 ・自動化コスト
を踏まえてトリアージすべき、と書いている。

テストケースを一覧にまとめ、それぞれに「リスク、手動テストのコスト、自動化コスト」を見積る
→ リスクが最も高くて、手動テストのコストが高くて、自動化コストが低いテストケースが第1優先

こだわるな
・テスト駆動、テストファースト、テスト実行速度、テスト網羅性などにこだわるな
・勝つために手段は択ばない

こだわるポイントがある
 ・再現、繰り返し可能
 ・独立している
他はそれからでいい

設計の可動域を確保する
実装のテストを書かないこと
→ 実装に近いテストを書くと、現状追認のテストになってしまう。
→ 実装から遠いテストを書いて改善の幅を広げて丸っと改善したい

ユニットテストよりも荒い範囲をカバーするテストを書く
→ E2Eくらい間合いの遠いテストを使いこなす

テスト自動化ピラミッドとアンチパターン
GUIのテストは少なく、自動化されたUnitTestが分厚いのが理想。
でも、レガシーシステムはピラミッドの土台を作るの難しいので、ピラミッドの真ん中や上から攻めることもある。
そこからやるのは実はアンチパターンだけど、改善の足掛かりにするのはあり。

コンポーネントテストやユニットテストの定義は?とか言い出す
→ 迷いが生じる・・・
→ 定義なんていいんだよ!小中大でいい。
→ 自分たちにとってのスモールとは、というように自分たちで考えて3サイズを決めていきましょう
→ そうするとめんどくさいことから解放される

背中を見せる
・サンプルとデモが大事
・ゼロからやるのは難しい。とういのも、ゼロからテストを書いてやる人が少ないから。
 → 真似してもらう土台を作る
・テストのある生活を体験してもらう

Social Change starts with YOU
自分が書けるようにならなければ、誰も書けるようにならない
→ 毎日テストコードを書く。Write Code Every Day

アジャイル組織の作り方教えます


【C-5】 14:15 ~ 15:00 片岡 俊行[ゆめみ]
セッション:https://event.shoeisha.jp/devsumi/20190702/session/2087/
Togetter:https://togetter.com/li/1372244



今200名いて、スケールするために1000人にしないといけない
→ アジリティが成り立たなくなってくる
→ 組織が4階層になって硬直化していく

組織構造をどう再設計するか?
→ 「今日からアジャイル組織になります」と宣言した

「組織がカオスである」という観点よりも「組織がカオスの中に既に入っている」ことが重要
カオスとは外部環境が予測出来ない状態
→ 混沌のなかで秩序を保ちながら適応することが重要

being agile > doing agile

原則を守っていくのが重要
魚群とか鳥の群れとかのように、すべてが自律して動いていくことが理想

3つの型
 1.自律
 2.分散
 3.協調

アジャイル組織
・アジャイル組織とは、秩序を保つことによって、予測できない環境でも組織が自己設計される
・自己設計される、が特徴。

大前提として、企業のビジネス要求に従った組織設計であるべき

ゆめみの歴史
・大障害を機に、マネジメントの役割分散へ
 → 高品質とアジリティを両立させるマネジメントがすごく大変だった
 → 組織の設計の問題を受けて変えた。役割分散だけでなく権限分散をした

3つのハマりポイント
 1.階層型組織
 2.フラット型組織
 3.権限移譲

1.階層型組織
・それ自体がわるいわけではない
・責務を階層的に分解することで、上位の目的を分散していくことが重要
・コミュニケーションの複雑性を取り除く
・責務分解に階層化はとても重要

2.階層のフラット化
・「フラット型組織」というもの自体は存在しない
・階層がなるべく少ないという意味でのフラット型組織は、コミュニケーションが一部に集中してしまう
 → 暫定的な措置でしかない

3.権限移譲
・責務分解された組織で、権限構造を入れ子構造にすることが多い
・問題になるのが、階層が多くなると、現場を理解しない人が承認しないといけなかったりすること。
・大きく権限を任せたとしても、責任者が単一障害点になる
 → 入れ子構造における権限移譲の難しさがある

・完全権限移譲したとしても、
 ・任せる側は、相手に距離を置いてしまうと、口出しが難しくなる
  → ここぞのフィードバックがしにくくなる
 ・任された側は、失敗のペナルティがある場合、プレッシャーが大きくなる

権限移譲の難しさ
権限移譲した上で、任された側から報告してもらいながら、任せた側が意見をがフィードバックしていく場合、任せた側が「あくまで意見です」と助言をしても、受け取り側がどう受け取るかが重要。
権限が与えられたとしても、権威は別に存在する。
権限と権威を合わせて権力と呼ぶ。
権限を委譲しても権威は移譲できないので、任された側は「やっぱり任せた側の意見は聞かないといけないのかな」とかなってしまう

組織構造を変える時に、難しさがいろいろある
どうやっていったか

自立 分散 協調

1.自律
外から見たとき、その人が外部支援なしにコントロールできてる状態

逆コンウェイの機動作戦
チーム・組織のコミュニケーション制約を解消して、最適なプロダクトのアーキテクチャに繋げるための実践方法

自分用メモ: コンウェイの法則と逆コンウェイの法則から組織構造を考える

Self-Controlの定義
我々は相手をコントロールできない
我々は我々しかコントロールできない

→ 「相手」を「我々」と捉える

自律だからといって、組織として適応的であるとは限らない。
カオスの環境の中でカオスに合わせて最適に振舞えているかは別の話。
より適応的になるための意思決定組織が、ティール組織

助言プロセス
・誰もがどのような意思決定を行うできる。
・ただし、意思決定の前に、深く影響がある全ての関係者やその分野の専門家から助言を求める必要がある。

「トップダウン」と「コンセンサス」のいいとこどりをしたものが助言プロセスで、優れた意思決定プロセス。
「ゆめみ」のすべての意思プロセスは助言プロセスで成り立っている。

プロリク
プロポーザルを作成したらレビュー依頼をする (Proposal Review Request)

1.すべての意思決定をプロリクで実施
2.否決されることはない
3.全メンバーが代表取締役権限を持つ

Slackチャンネルで、プロポーザル内容を全員にレビューしてもらう
→ 会社自体がアジャイルに沿って変化していく

2.分散
自律であるためには分散していかないといけない
上位の目的を達成するために階層的に責務分散する
責務を遂行するための単位をチームと呼ぶ

どう分散するかということ、役割を分散する

・コミッター ・・・ スコープに対しての遂行責任を負う。プロリクできる。
・コントリビューター ・・・ コミッターの自律を支援する。コミット権限はない。


会社の組織を責務分解している。
チームの定義記述はwikiで管理してる。
会社のすべての責務をチームに分解する。

一般組織の例
権限移譲の難しさは、部長は任せた以上、あまり口出しできない
→ 距離感の問題がある
→ その解決策が、二重連結ピン(ダブルリンキング)

二重連結ピン(ダブルリンキング)
親チームと子チーム、それぞれにコミッターとコントリビューターがいる
制約条件は、
・親チームのコミッターは子チームのコミッターになれない。逆も然り。

権限構造の比較
一般組織は入れ子構造で、部長や課長が単一障害点になる。
権限分散すると、コミッターが冗長化されている。距離感で密に連携しやすい。

チームの人数は上限7名。それ以上になるとチームを分解する。

チームにプロジェクトを依頼する。
依頼先は、チーム。
チームがどういうメンバーで構成するかは自律的にしてる。

Spotify Scaling Agile
参考:Spotifyモデルの勉強をしてみる
Spotifyは原理的なスクラムを嫌っている。

Squad(分隊)が複数あつまってTribeを構成する。
縦軸のSquad優先だけど、横軸のチャプターがあって、チャプターリードがいる。

→ Spotifyモデルは難しいという結論になり、より柔軟な組織設計に


3.協調
・プロリクのレビューも協調の1つ
・コントリビューターに後方支援してもらう
・チームが増えると方向性がずれてくるので、全体最適を担う「リードチーム」というのを設けた
・チームを一人の人と見立てて、フラクタル構造を作り出す。

リードチームがプロジェクトを後方支援する
デザインリードチーム、テックリードチーム etc

デザインコンセプト
方法論も大事だが考え方も大事
・art
・design
・enginering

自分たちで自分たちを設計できるようにする

適応的≠自立+分散+協調

まとめ
・責務の階層化は必須
・助言プロセス(プロリク)最強
・権威の無効化はできないのでダブルリンキングのような制約つくる
・チームの自己設計のルール化が肝
・緩やかなチーム所属
・完全自律には支援が必要 コントリビュータみたいな
・協調のフラクタル構造がスケールには大事
・自律と適応的は異なる
・単独適応的を行えるようにするのが今後の課題

あらゆるものをカイゼンせよ


【A-9】 17:25 ~ 18:25

セッション:https://event.shoeisha.jp/devsumi/20190702/session/2073/
Togetter:https://togetter.com/li/1372309

小田中 育生[ナビタイムジャパン]


新しい経路が見つかりました~プロダクトがカイゼンし続けるために~ from NavitimeJapan


カイゼンを阻むもの
・多くのユーザーがいると、優先順位が相反する
・あふれるバックログに最初に向き合う
 → ここを整理して見通しをよくする。ルールを設けて定期的に棚卸しする。
 でも、自分が書いたストーリーを目の前にすると、必要に見えてきちゃって中々消せない・・・
 → チームとして仕組みとして削除するルールを定めた

デグレを起こさない環境を作る
→ リグレッションテスト

複雑なコードを解きほぐす
→ カイゼンデーを設けて、内部改善に集中する日を設ける。改善のストーリーの優先順位が上がらないチームでは有効

カイゼンには二律背反が伴う
→ インセプションデッキを作成してチームで共通認識を形成する
→ 捨てるものを決める時にインセプションデッキが道しるべとなる

ユーザーの、どの声を聞くべきかわからず、カイゼンが空まわり
→ 狩野モデルを使い、インセプションデッキと照合して3つのどれを優先するか決める

ユーザーの声は、声を上げてくれる人の要望や不満しか拾えない
→ ユーザーログから拾うようにした。全ユーザーの行動から課題を抽出できる

目線と温度感を揃える
→ ユーザーストーリーマッピングを作成する。ペルソナを作ってストーリーを作ってマッピングする。
→ ストーリーを事業者に書いてもらうことで当事者意識を持ってもらう

新井 剛[ヴァル研究所・エナジャイル]




価値観ババ抜きチームビルディング
・いなくなっても回るようにするのがスクラムマスター
・2019/7/8 アジャイルリーダーシップサミット 2019

市谷 聡啓[ギルドワークス・エナジャイル


プロダクトオーナー2.0 from toshihiro ichitani


アジャイル開発は2度失敗する
→ 2回心が折れてもいいように残機3持っておく

開発チームとPOの間に生まれる境界線で2回目の失敗をする

開発の準備が整っていないと、スプリントの空振りが起こる。

開発チームからPO側への越境が必要。POの役割をチームで補完する。

プロダクトオーナー代行と仮説検証

感想


今年はアジャイルと組織論に関するセッションが多かったですね~
いろいろヒントを得ることができました。

ブログは自分の復習用で、ダラダラ書き起こしただけですが、スライドやTogetterと合わせてまた読み直してみようと思います。

関係者の皆様ありがとーございました。

「エンジニアのためのコーチング入門」に参加しました

2019/6/11(火) 「エンジニアのためのコーチング入門」に参加してきました。

connpass
https://coaching.connpass.com/event/130496/

Togetter
https://togetter.com/li/1366335

このイベント、40人枠に120人くらい申し込みがあったようで、コーチング大人気。
私が申し込んだ時は補欠10番目くらいだったのですが、当日17時過ぎに補欠から繰り上がり、ギリギリ参加できました。
私も仕事でアジャイルコーチとかやってるので、ちょうどピンポイントなテーマのイベントということで興味深々です。

以下、書き殴りメモと感想。

エンジニアのためのコーチング入門導入 / 安西 剛




今日のテーマの1つが、「1 on 1」のコーチング。その導入スライドです。
私がアジャイルコーチとしてプロジェクトに入るときは1:Nのコーチングになるんですが、今日の中心は「1 on 1」。
個人にフォーカスしたコーチングの経験はほどんど無かったので、非常に興味深いテーマだ。

人と話すことが苦手な人の方が、コーチングは上手くなる / 三橋 新




勇気


・「嫌われる勇気」が大事ということに気づいた。
・すべての人の期待に応えることはできない。
・仕事とは、貢献すること。
・自分の強みを知るには人に聞くこと。
・「あなたは、何屋ですか?」という問いに対して
  ・少しできることを削ぎ落す
  ・りんごの芯くらいになった好きで得意なことを自分で愛する
・「全ての人の期待に応えたい」から、「2%の人に最高の感動(価値)を届けよう」という考えにシフトした。
 ・マツダの「2%戦略」を参考に。
 ・「最大公約数を狙うのではなく、2%のファンに強く共感してもらえる突き抜けた車を妥協せず作る」
 ・何でも屋を卒業し、「三橋 新 = 社内コーチ」にシフトした
勇気を持って、やれることを削ぎ落とし、好きで得意で人のためになることにフォーカスしたら、誰でも、何者かになれる
 

あなたの人生の目的は何ですか?


・自分の人生の目的を見つけるワークショップ
  ・街中にある、何十万人の目に触れる広告塔に何でも書けるとしたら、何を書きますか?
   ・広告塔でどんなイメージやインパクトを与えたいか?
   ・どんなイメージが出てきましたか?
     → イメージから入っていくと言語化できる。
   ・三橋さんが広告塔に書くとしたら、
     ・「あなたの目、死んでいませんか?」
     ・「自ら意思決定し生きる社会を創る、森でありたい」

・「~でありたい」という文章にイメージで、比喩を入れると良い。
  ・在り方は、雰囲気に出ていく。質感が出てくる。
  ・森のように、来る人を受け入れ、そよ風を感じながら気づけるコーチでありたい。

コーヒーブレイク


・「コミュニケーションとは、上手に話さないといけないものである」という囚われはありませんか?
・コーチングとは、相手を主体とした協働作業。
  ・聞くだけじゃなく、一緒に手段を出し合うこともある
  ・新しいものがそこから生まれることがある

・コーチングのポイント3点
  1.好奇心
  2.問い
  3.おうむ返し

・「百聞は一見に如かず」ということで、実際に参加者さん一人と三橋さんで実演してみる。
  ・三橋さんがコーチ役で、参加者の一人に「問い」をいくつか投げかける
    ・仕事は充実してますか?
    ・充実度は何点ですか?
    ・充実度10点はどんな状態ですか?
    ・2点から3点に上げるには、どんなことをやればいいですか?
  
  ・おうむ返し
    ・「~~なんですね」
    ・コーチの問いに対して自分が回答したことが、コーチからおうむ返しでそのまま返ってくるので、本当にそう思ってるんだ、と自分で気づける

コーチングで一番大事なこと


・コーチングで一番大事なこと
 1.Being ・・・  どうあるか。何をするか、ではない。
 2.相手の可能性を信じる

ピグマリオン効果
 ・教師の期待によって学習者の成績が向上すること。
 ・人間は期待された通りに成果を出す傾向がある。

・「可能性を信じるって?」というのを実感するワークショップ
  ・写真を見て感じた事を、以下の観点でそれぞれペアで言葉にしてみる。
    ・A: この人はとてもイマイチだな〜。。
    ・B: この人は可能性に溢れている!

  ・写真1 ・・・ コーヒー飲みつつスマホ見ながら面接を受けている写真
  ・写真2 ・・・ ドライヤーの強風を激しく顔に当てて髪を靡かせながら悩んでる写真

   → 見る観点を変えると自分の関わりが変わる、という気づきを実感するワークショップでした。

・まとめ
 1.嫌われる勇気
  ・2%にフォーカスし削ぎ落とすことで、何者かになれる
 2.自分の人生の目的を生きることで、他人の人生から解放される
 3.コーチングで1番大事なことは、相手の可能性を信じて関わるBeing

エンジニアリング組織の1on1におけるコーチングスキルの活かし方 / 谷内 真裕




今日話すこと


 1.自己探求
 2.向き合い方
 3.場づくり
 4.スキル

 → 3と4はdoingの話

1.自己探求


・1on1のセッション中に意図せずにやってしまいそうな例 ・・・ 8つの内、1つぐらいは心当たりあるのでは
・相手への問いは自分にブーメランで返ってくることが多い
・自己探求できてないと上手くできない
・内なる声と戦っていく必要がある
・「1on1」は相手を変えなきゃいけない、というのに囚われてしまう。自由な発想を妨げてしまう。
 → じゃあ、どうすればいいか?
 → 解: 自己管理
・コーチたるもの、自己管理できていないといけない
・自分の声を横に置いて、相手に焦点を当てる

・自己管理
  → 自分の性格・考え方の偏りを知ろう。
  → そこが始まり。恐れ、自信のなさ、自分にはまだ無理だ、とか。自分の中にあるものを認識する。
  → そうすると自分の声に気づける。鍛えられてくる。
  → 注意を何に向ければいいか分かってくる。相手に焦点が当たってくる。

・どうやって自己探求したらいいか?
  ・自己探求のリソースをいくつか紹介

・ストレングスファインダー ・・・ 自分の強みを知るのにおすすめ
さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0
トム・ラス
日本経済新聞出版社
売り上げランキング: 44


・ 「9つの性格」という本の、エニアグラム ・・・ 自分の性格や思考のクセを知る


・スタンフォード大学の超人気講座 実力を100%発揮する方法 ・・・ 内にある妨害者を知る。Webのテストもある


・セキュアベース・リーダーシップ
  ・成長を促す素養。成長にはリスクを取る必要がある。
セキュアベース・リーダーシップ ――〈思いやり〉と〈挑戦〉で限界を超えさせる
ジョージ・コーリーザー スーザン・ゴールズワージー ダンカン・クーム
プレジデント社
売り上げランキング: 109,235


【初心者向け】ジャーナリングを簡単に習慣付けられる7つのシンプルなテンプレート
  ・ひたすら、自分が何を考えているかを書く
  ・書くスピードも気にする

・自己探求
・囚われに気づこう
  → 怖い、と思ってていい。自分の声を横に置いて、相手に集中する。

2.向き合い方


・1on1に対する向き合い方について。
・1on1で暗黙的な何かを感じることはありませんか? ・・・ 7個の例
  ・例えば、暗黙的な「コントロール」は、「ネクストアクション必須」というのをもたらす。
  → ネクストアクションを毎回出さないといけない、というのはツライ・・・。宿題に毎回なってしまう。
  → 話を聞いてほしいだけのこともある。

・うそ・ごまかし・恐れは、隠しているつもりでも伝わってしまう
・自分が与える影響を認識しょう
・完璧な人間である必要は無い
・それぞれの個性を活かす

・大好きな言葉: 人はもともと想像力と才知に溢れ、欠けるところのない存在である
  ・その人が持ってるリソースを使っていれば、その人が望むものがやってくる。叶えられる。
  ・いつも思い出すようにしているが、長いので、呪文を考えた。
   →  (相手のすべての)信じる

・信じる
 → 偏見とかを横に置いて話を聞くことに集中しよう
 → 相手に好奇心を持って問いかけよう
 → 相手の成長を100%信じて励ますと相手に変化が起きてくる

・相手を信じるほど、意外と自分も変わってくる
・先に自分が相手を信じる
  ・「相手を変えることはできない」と言われるほど、相手を変えることは難しい
  ・自分から変わっていこう

3.場作り


・1on1の悩みの大半は、場づくりをしていないことから生じる
・自分なりの1on1をデザインする
・コーチングに入る前に、導入セッションで1on1をデザインする
  ・お互いを知る時間を作ったりとか。これがすごく大事。
  ・コーチングでこーゆうことやろうね、とかを相手と握る。

・導入セッションで1on1をデザインする
 → 1 on 1の目的を相手と合意する
 → 二人の関係性や約束を合意する
 → 約束を決める。30分くらい使ったっていい。
 → そうすると、1on1の意義を相手も理解してくれる
   ・何を話してもいいんだ、と安心してくれる。
   ・1on1の定義を話す時間ではない。

・場づくりのリソース
  ・目的
  ・話すこと
  ・約束 (誰にも言わないんで、話してください。墓場まで持っていきます。とよく言う)



・導入セッションしよう
  ・いつ定義を変更してもよい

4.スキル


・家の壁にコーチングのスキルを書きだした付箋を貼ってる。
 → 「今日は核心というスキルを使って生活しよう」とか自分でやっている。(やばい奴に見えるかもw)
・スキルはいっぱいある

・すべては傾聴から始まる
・傾聴は、練習が最も大事

・10分でできる傾聴の練習
  ・話をする人と聞く人に分かれて、3分話す。
  ・聞く人にルールを決める。
     ・一言も発しない
     ・短い相槌だけうつ
     ・たまに要約
     ・エディタを見続ける
   → 聞く人がそれらをやってみて、話し手がどう感じるかを互いに話し合う。


・傾聴できているか自分で確認するチェックポイントが2つある
  1.意識の焦点はどこに当たっているか?
  2.いまの自分が相手に与える影響は何か?

1.意識の焦点はどこに当たっているか?
 ・例
   ・自分の内なる声
   ・自分の身体感覚
   ・相手の声
   ・相手の状態
   ・その場のすべて
 → どこに焦点があたっているか?

2.いまの自分が相手に与える影響は何か?
 ・例
   ・傾聴の度合い
   ・自分の表情
   ・自分の振舞い

傾聴の度合いを自分で確認する方法がある
・レベル1: 内的傾聴 ・・・ 自分に集中してて周りが聞こえない。自分の内面と対話してる。
・レベル2: 集中的傾聴 ・・・ 相手に集中してて周りに聞こえない
・レベル3: 全方位的傾聴 ・・・ 周囲に集中。感覚的に察知する

・レベル3は、会議室入ったら場がめっちゃ冷えてる時とか、飯食ってるのに会話が弾まねーな、とか、周りうるさくて話聞こえないとか、場の雰囲気を感じる。
・コーチングするときはこれらを組み合わせる
・3つの度合いに優劣はない
・レベル1は、相手の人は自分の声をずっと聴いてほしい。
・自分はレベル2以上を保つ。
・レベル3はアドバンスト。相手の感じを傾聴する。話を聞くのではなく、場を傾聴する
 → 「あ、困ってるな」とか、「あ、うれしそうだな」とか。

・難しいけど、練習すると分かってくることがある
 1.話題に関する知識や詳細な理解は不要
  ・傾聴し続けると、相手が自分で考えを見つけて、話を聞いてるだけで自己解決する
  ・相手の力ですべて解決する。アドバイスとかしなくていい。
  ・相手の持っている力を助ける

 2.沈黙に耐えられないのは注意が自分に向くから。
 3.自分の声が聞こえたら相手に注意を向けなおす
   → レベル1になってるから、レベル2に上げよう、と頑張る。

 4.相手が発するエネルギーの強弱はとても重要
   → 「おや、なんか違うな」を感じる

・練習しよう。
・コーディングや設計も練習すれば上手くなる。それと同じ

まとめ


  ・自己探求
  ・先に自分が信じる
  ・導入セッションで場づくり
  ・傾聴の練習をする

エンジニアリングマネージャー育成におけるコーチング / 安西 剛




・エンジニアリングマネージャーとしての成長って何?
・エンジニアリングマネージャーに必要な要素は?
 → 「やり方」と「あり方」に分けられる

・マネージャになると「あり方」も大切になる
・あり方が他人に影響を与えることになる

・ポイントは、オーセンティックであるか?
・オーセンティックとは、自分らしさを貫いているか

・VUCAの時代というのは、明確な答えが無く、変化が激しい時代。
 → 強いリーダーシップだけでは通用しない
 → 変化が激しいのにで自分で答えを出すしかない
  ・上に立つほど、答えがどれかわからなくなる
 → 自分に矢印を向ける必要がある

・オーセンティックであるための3つのポイント

1.自己認識力を高める (セルフアウェアネス)
 ・成果や外だけでなく自分とも向き合う。 (自分が分かる)
 ・フィードバックを受け入れる。 (他己認識と自己認識のギャップを埋める)

2.弱さを認める (ヴァルネラビリティ)
 ・できない、わからない、弱い、を自分で認めているか。
 ・これがマネージャはなかなかできない。
 ・そんな自分をありのまま認めているか? (セルフコンパッション)
 ・強がってるな、というのは自分以外はみんな分かってしまう。

3.弱みや恥を他人に話す (さらけ出す)
 ・できないこと、わからないこと、弱いことを、他人に話せているか?

・強いリーダーでいるより、オーセンティックであるほうが勇気が必要。
  ・自分の弱さを口に出すとかの勇気

・オーセンティックでいることにより
  ・学び続けることができる (例:年下から学べるか)
  ・一貫性を持つことができる
  ・覚悟を持つことができる
→ 結果的にリーダーというものに近づいていく

・人によってオーセンティックはまったく違う
 → 答えは存在しない
・べき論、リーダー像の思い込みを外し、探求し続ける必要がある
・人間として成長し続ける

・エンジニアリングマネージャー育成コーチングの重要なチェックポイント1
  ・オーセンティックであるか?

・エンジニアリングマネージャー育成コーチングの重要なチェックポイント2
  ・フィードバックをする

・日本人、フランス人、オーストラリア人の、3者の1on1で、オーストラリア人のが一番良かった
  ・オーストラリア人の1on1は、全部の時間を相手に使っていた
  ・最近どう?とか
   → 次も頑張ろう、という気持ちにさせてくれる

・言葉とかスキルじゃなくて、在り方。
・強がっちゃうと、わからない、と言えなくなる。
 → 相手に不信感がたまる。

・「俺もわからないから一緒に考えよう」とできるといい。
 → 勇気を出して言おう。言ってみたら、すごいいい雰囲気でTRYが出た。
・すごい簡単なことなんだけど、オーセンティックであることはすごく勇気がいる

質疑応答


Q.
「エンジニアリングマネージャの成長」とは?
何を持って「成長」なのか。

A.
答えは無い。
自分を変え続けられるか、が大事。
「Unlearn」という学びほぐし。学んだことを捨てよう。
捨てることは痛い。ツライ。
今までを捨てて新しく学べるか。
素直に学べるかどうかが、エンジニアリングマネージャに重要かな、と思う。



Q.
リーダーだと成果とかコミットメントが求められる。
成長を待ってられないシーンがあるのでは。
せっかちな自分とのバランスの良いとり方があれば教えてほしい。

A.
状況によってフェーズが違う。
立ち上げたばかりのチームに、本人たちから問いが出るのを待ったことがあったが、失敗だった。
立ち上げ当初は、ひっぱって形を作ることが大事。
それがあって、じゃあどう改善するか、が話せる。
なのでチームとか事業とか、フェーズによってチームの動かし方を変える
「エラスティックリーダーシップ」という本を先に読んでおけばよかった、と思った。
コーチングだけじゃなく、場合によってはティーチングやフィードバックもする。使い分ける。

エラスティックリーダーシップ ―自己組織化チームの育て方
Roy Osherove
オライリージャパン
売り上げランキング: 246,589




A.
エンジニア以外にもコーチングは需要はあるか?

Q.
無理に提供しようとは思わない。
無理強いしない。



Q.
コーチングやティーチング、どう使い分けるか?

A.
ドキュメントに既に載ってることとか、既知の手続きとか、そういう場合はティーチングで教えちゃう。
解が無さそうなら、ティーチングでなくコーチングかな。
ティーチングは明らかに答えがわかっていて深く本人が考える必要ない場合に使う。
コーチングは、深く考えることによって本人の成長があるか、が指針となる。



Q.
導入セッションは毎回やったほうがいい?
毎週15分の1on1をやってるけど、時間が短いので場づくりやるのが難しい。

A.
1回目の15分だけ導入セッションをやる。
2回目以降はやらない。
変えたいときにまた導入セッションやる。



Q.
100%相手を信じる、というのがあったが、100%信じれない場合にどうすればいいか?

A.
信じられない自分と向き合う。
自分を探求していく
コーチは、「上手くいかない場合はすべて自責である」と言われている。
相手について考えている時間が多いほど、いい解が浮かぶ。
相手を突き詰めていくと、相手が変わることがある。



Q.
コーチングが始まったきっかけは?

A.
僕がやりたいから。 by 三橋さん
どういう経緯でやりはじめたかわからない。 by 谷内さん



Q.
言葉尻が強い、とか、使い分ける?

A.
相手が向き合うべきことをコーチが気づいたら、ストレートに伝えちゃう
10秒くらい相手が無言になるような本質をつけることがある
そこで内省が始まる



Q.
オーセンティックが大事とのことだが、弱さを曝け出すというのは周りの見え方もあるのでは。
弱いコーチと思われる心配がある。

A.
オーセンティックリーダーシップという本がある。



弱さをすべて出していい、というわけではない。
人間としての在り方をアップデートし続けるうえで出すことが必要。
弱さを出すタイミングもある。
はじめまして、のタイミングで「できません」から入るとマイナスから始まってしまうので、プラスに変えるのが大変。
中長期的にはありのままで、徐々に弱さを出していく
信頼関係を築くプロセスで自分を出していく
弱みだけじゃなく、できることも出せばいい



Q.
コーチングって相手のことをずっと考えてる。
自分らしさがどこに出てくるか?

A.
コーチングって生き方かなと思ってる。
「ハッピーかい?」と言いながらハッピーターンを渡すこととかやってる(笑
そういうちゃめっけも自分の特徴かなと思ってる。



Q.
弱さを認めるだけだと成長が止まってしまう
変えていくマインドセットとかあるか

A.
自分を受け入れることがすごいハードル高い。
それを探求し続ける
そのうえで何をするかというと、いろんなことを受け入れていく
成功体験だけでなく失敗体験を受け入れて前に進んでいく。

感想


とても濃い中身の詰まったイベントでした。
コーチングの在り方とスキルの両輪がバランスよく入ってて、自分の在り方をいろいろ考えさせられましたね。
コーチングの実践的なイベントもやる予定だそうで、そっちも楽しみです。
イベント関係者の皆様、ありがとーございました。

PS.
個人的にアジャイルコーチング読書会というイベントにも定期的に参加してるんですが、そっちも皆様いかがっすか~?

アジャイルコーチング
Rachel Davies Liz Sedley
オーム社
売り上げランキング: 88,495


「JJUG CCC 2019 Spring」に参加しました

2019/5/18(土) 「JJUG CCC 2019 Spring」に参加してきました。

公式サイト
http://www.java-users.jp/ccc2019spring/#/

Togetter
https://togetter.com/li/1356737

今年もこの季節がやってきました。今回も1000人以上の参加ということで、相変わらず凄い熱気。
個人的にも、半年ごとの恒例参加イベントになってます。
仕事でも普段Java使ってるし、とっても楽しく有意義。

最初のセッションは10時からということで、10分前くらいに西新宿の会場に到着~
20190518_01.jpg

この日は朝から清々しい五月晴れ。品川の自宅を自転車で出発し、サイクリングを兼ねて向かいました。


この季節のサイクリングは実に気持ちいいですな~。

以下、参加したセッション。

Java11時代のHTTP(S)アクセス再入門


セッション紹介: http://www.java-users.jp/ccc2019spring/#/sessions/f05a7f3e-6fef-4366-9116-39f1cb62a57c
Introduction httpClient on Java11 / Java11時代のHTTPアクセス再入門 from tamtam180


Java11で正式APIとなったHttpClientの使い方を紹介するセッションです。
そういや、JavaでHTTP通信のクライアントコードってほとんど書いたことないなぁ・・・
バックエンドにSpring Frameworkを使ってるけど、フロントエンドはAngularやSpring MVCでRESTをちょと使うくらいなので。
けっこー自然にコード書けそうで、使いやすそうだなと思いました。




大企業運営の法人向けサービスにおけるOpenJDK移行事例


セッション紹介: http://www.java-users.jp/ccc2019spring/#/sessions/420aaed4-ae0e-436d-9711-bb5211d4dbb8


JDKのマイグレーションに関する知見がたくさんのセッション。
こーゆう現場の生の経験満載の知見に基づくセッションは強いですなぁ。
そういや仕事で作ったちょっとしたJavaのツール、最近Java 8からOpenJDK11にちょうど移行したトコけど検証ちゃんとやってないなぁと戦慄・・・
Javaのサポートポリシーも大きく変わって理解が曖昧になってる部分も多いんで、帰宅してブログ書く前に、OpenJDKのライフサイクルとかディストリビューションとかいろいろググったりしていい勉強になりました。
こーゆうキッカケからのお勉強がいい副産物になるのです。





毎度、素晴らしいグラレコですな~

開発リーダー1年目。メンバーのスキルアップのためにやっていること。


セッション紹介: http://www.java-users.jp/ccc2019spring/#/sessions/94c0bea5-44d4-45a7-861d-9e8539ee7eea
20190518_g2b.jpg

業務時間中の輪読、羨ましい・・・
スクラムやってるとのことですが、スクラムの柱の1つに「透明性」ってありますよね。
輪読会やるとなると、透明性の観点からプロダクトオーナーにもその事実が周知になるわけですが、プロダクトオーナーと開発チームに受託開発的な受発注関係がある場合、輪読会やるって説明が少し大変だったりする場合もあるのかな、と思います。
というのも、「輪読会なんかに時間を割くくらいなら、その時間も開発に充ててよ!」とか言い出すプロダクトオーナーもいるんじゃないかな、と。
そーいった利害関係の超えての調整労力もマネージャーに求められたりするだろなー、と思ったりして、またいろいろ考えさせられる・・・





あ、Java読書会の輪読もいかがっすか~


Cloud Native時代の開発環境とアプリケーション基盤


セッション紹介: http://www.java-users.jp/ccc2019spring/#/sessions/4606dbaa-1191-43e1-b923-ac6882880d11


ランチセッション。レッドハットさん、お弁当ありがとうございます~


お弁当を食べつつ、セッションを聴講。
Eclipse CheというブラウザベースのEclipse IDEの紹介です。
Eclipse Cheって今回のセッションで初めて知りました。ブラウザでここまでできるのは凄いですね。
環境を統一できたり、ワークスペースを共有できたりと、ふつーのデスクトップアプリ版のEclipseに無い機能が興味深い。
そういやPostgreSQLのpgAdminも、最近ってブラウザベースになってますよね。操作性もそれほど悪くないし。
ブラウザでコーディングなんて、って思っちゃいそうですが、一度試してみる価値はありそう。




お昼休み


恒例のLT大会。無料コーヒーを戴きつつ、楽しいヒトトキを過ごします。
20190518_02.jpg

15時くらいにある長めの休憩タイムにも2回目のLT大会が催されましたが、そっちも聴講参加。
@yusuke さんのLT、安定の面白さ(笑




先行開発!Javaでクリーンアーキテクチャ -- ゼロから始める新規開発


セッション紹介: http://www.java-users.jp/ccc2019spring/#/sessions/4ce63414-6e92-4612-91e1-9b84e772cc81


こちらのセッション、スライドだけでなく解説記事まであります。素晴らしい。
https://nrslib.com/clean-architecture-with-java/

ちょうど「Clean Architecture 読書会」に参加してて本読んでるところなので、タイムリーなセッションでした。


今回の講演は背景にDDD色が強く出てて、クリーンアーキテクチャをDDDと合わせて捉えるという点が新鮮でした。
スライドで紹介されてる内容、もう一度よく復習したい。
Javaのインタフェース駆使してDIPとかで設計したことあんまりなくて、なかなか難しい・・・







テストエンジニアが教える JUnitを書き始める前に考えるべきテスト


セッション紹介: http://www.java-users.jp/ccc2019spring/#/sessions/0f7a8cf8-4862-477f-81bf-6dc3d47eb450


私も自社でソフトウェアテストの講師やったりするので、知識の再整理にとても役立つ内容でした。
menti.com というサービスを使って参加者とインタラクティブに進めるスタイルは斬新。
これはウチの教育でも使えるかもしれないなー
テスト設計についてチームで会話して認識齟齬を実感するワークショップとかも面白い。
いろいろ参考に出来そうなネタが入ってて、気づきも多く、とても勉強になりました。







1400万ユーザーのWebサービスを15年運用して考える、Javaである理由


セッション紹介: http://www.java-users.jp/ccc2019spring/#/sessions/755b3eda-f8db-408c-93d5-35faca8d089d


タイトルには「15年運用」とありますが、講演者は社会人もJava歴も3年目という若手の女性エンジニアさん。
この講演のためにいろいろ調べたり纏めたりされたのだと思いますが、素晴らしいチャレンジ。
自分が3年目でこんなチャレンジできただろうか?と自問してしまいます・・・
自分が新人エンジニアとして入社したのはもう十数年前になりますが、当時はJava全盛で、お堅い巨大SIerということもありJava以外の言語という選択肢があまりなかった時代でした。
今の時代、Java以外の言語もあたりまえに普及してて、タイトルにある「Javaである理由」というのを改めて考えてみるのも確かに必要かも。
個人的にはJavaが一番好きなので、このままJavaで行きたいと思うのでした。







JJUG会長と一緒に考えたSpring Boot x JavaScript x IntelliJ x アジャイルというモダンな新人研修を今まさにやっている話


セッション紹介: http://www.java-users.jp/ccc2019spring/#/sessions/0d49f105-e79f-44a5-8ad8-1404556df1a2



個人的に、今回のJJUG CCCで一番聞きたいと思ってたセッション。
というのも私も自社の新人研修講師を担当してて、Spring Framework + JavaScript(Angular) + アジャイル開発、というネタでちょうど今、教えている最中なのです。
期間は5月中旬~6月末までの1か月半です。
ということで、今回のセッションネタと超近く、しかもリアルタイム。
どうしたら新人たちにとって有意義な研修となるだろうか、というのを日々、自問自答しつつ進めています。

あと多田さんもおっしゃってましたが、先進的な教育を整備するのにお金や工数をかけても、その研修カリキュラムを買ってくれる顧客がいないと商売として成り立たないわけで・・・
いろいろ同じ悩みをかかえつつ考えを整理することができて、とても参考になりました。
私は研修講師が専任業務ではなくエンジニア業の方がメインですが、人に教えるという過程は自分にとっても凄い勉強になる。








マイクロサービス:4つの分割アプローチの比較


セッション紹介: http://www.java-users.jp/ccc2019spring/#/sessions/f559d9cd-2495-4327-b2ba-7f89a3115a85
マイクロサービス 4つの分割アプローチ from 増田 亨


DDDの大御所、増田さん。
今日はDDDではなくマイクロサービスという観点でのセッションでしたが、やはり随所にDDDが登場してますね。
DDD本もIDDD本も両方読んでるけど、エヴァンス流とバーノン流、という2つの流派があるなんて、知りませんでした・・・
外部キーによる参照整合性制約のリアルタイム性を捨てる話とか、1つのトランザクションを更に分解する切り口とか、マイクロサービスという思想に沿った設計観点の話は非常に興味深い。

スライドに自己紹介のページが1枚もないのも凄い(笑
自己紹介に時間を割くくらいなら講演の中身に時間を割きたい、という熱い思いなのか、45分すべてを聴衆のために投入すべく自己アピールなんてゼロにする圧倒的スタイルw




まとめ


今回も素晴らしいイベントでした。講演者のみなさん、コミュニティ関係者、運営スタッフさんに感謝。
自分が知らない知識や思想だけでなく、エンジニアとしての姿勢だったり、熱い思いだったり、いろいろ気づかせてくれるイベントで、しかもなにより、参加してて楽しい。
勉強するために参加するというより、今日1日お祭りとして楽しもう、と感じさせてくれるイベントです。
懇親会のお寿司やお酒も惹かれますが、飲酒(自転車)運転になってしまうので懇親会不参加なのが悔やまれる。

秋のJJUG CCCもぜひ参加したいと思うのでした。
次のページ

-->