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

DevOps


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

フレームワーク


Lean
Agile
DevOps

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

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

プロダクトマネージャ


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

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


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

人事的な職種構成




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

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

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

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


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

TechLead （TL）




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

組織構造


組織構造は２パターンある。
　１．職能組織
　２．事業主体組織

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

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




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

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




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

すべてのエンジニアは、少なくともすべての職種（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フェーズある。
　　１．広げる
　　２．進める
　　３．畳む

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

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

棚卸し


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

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

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

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

決心


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

まずやってみるを軸に考えよう、と決心した。
このままじゃない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^)／


１．はじめに


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

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

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

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

２．理想のチーム


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

２つのキーワード
　１．ボトムアップ
　２．学習する

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

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

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

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

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

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

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

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

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

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

３．エンジニアリングマネージャの役割



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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

Airbnb Story 大胆なアイデアを生み、困難を乗り越え、超人気サービスをつくる方法
Airbnb Story 大胆なアイデアを生み、困難を乗り越え、超人気サービスをつくる方法
posted with amazlet at 19.07.03
リー・ギャラガー
日経BP
売り上げランキング: 22,633
Amazon.co.jpで詳細を見る



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

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

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


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

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


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

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

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

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

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

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

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

６．まとめ


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

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

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

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


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



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

２つの"ならわし"

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

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

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

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

文化を変えていく
文化の醸成は年単位の事業になる。３～５年かかる。

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

being agile > doing agile

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

３つの型
　１．自律
　２．分散
　３．協調

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

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

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

３つのハマりポイント
　１．階層型組織
　２．フラット型組織
　３．権限移譲

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

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

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

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

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

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

自立　分散　協調

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

リードチームがプロジェクトを後方支援する
デザインリードチーム、テックリードチーム 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


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

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

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

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

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

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

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

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




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

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


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


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

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

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

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

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

感想


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

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

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

-->