青空な日々

ITエンジニア関連で興味あることをアウトプットして共有したいブログ

DevLOVEXの感想

はじめに

昨日今日(2019年6月22日(土)～23日(日))とDevLOVE Xに参加してきましたので雑にその感想と、
スピーカーに個人的に質問した物があるのでブログと言う形で放流しておきます。
ほぼ当日のツイートのコピペなので、スピーカーに個人的に質問したとこ(目次の質問ありのトコ)だけ読んでくださいw

DevLOVE Xについてはこちら。

devlove.wixsite.com

参加目的

もともと尊敬する人がたくさん出るのでそれ目的に申し込んだのですが、
参加する1週間前に風邪を引いたり、ちょっとメンタル的に疲れたなーと思っていたので、
元気を貰うぞー!と参加しました。

実際、たくさん元気をもらえたので良かったです。

目次


感想

1日目

1E 及部さん

【勝手に基調講演】アジャイルで目指した坂の上の雲

及部さんのTwitter

聴衆者の10年の話。
自分はITエンジニアになって13年目なのですが、
エンジニアを始めてしんどくなって、
それを見ないようにして、
最近になってまたエンジニアリングと取っ組み合い始めて、楽しくなってきたここ10年。
という感じでした。

理想のチームって?

普段考えていることを言葉にする、口に出すのが大事。
聞かれるとなんとなく答えられるからやっていると思いがちだけど、
改めて文章にししたり、ちゃんと説明しようとするとうまく纏まらない。

坂の上の雲に向けて、
道半ばだけど近づいている感覚があるのがスゴイ。

いや当たり前なんだけど、じゃあ実感あるのか?と言われると悩む人は多いんじゃないだろうか。
自分も含めて。

2E 中村さん

「正しいものを正しくつくる」を探索し続けてきた10年とこれからの10年

中村さんのTwitter

スプリントを回すことに夢中になってしまって、
なぜその価値を届けるのか?が分からなくなってしまう。

現場にいると近視眼的になるのはあるある。
気をつけねば。

OutcomeとOutputの違い。

Outputは開発した機能。
Outcomeはその機能で利用者がどう変わったか?課題が解決したか?幸せになったか?

"物"を作るだけなら当たり前にできる。
その"物"でユーザーが求めている価値を届けられたのか?
(課題は解決したのか?売上は上がったのか?とか…)

事前にも、開発中にも、開発後も、Outcomeをどう測るか?どう確認するのか?を考え続けないといけないんだろうな。
そして想定と違った場合でも、それを受け入れて行動や自分達を即座に変えるのが大事なんだろうな。

Outputだけを評価の対象にしない。
これは当たり前のようだけど、組織の話なのでとても難しいと思う。
Outcomeを測るのが難しいが故にそれを評価にもし辛い。
そして評価しやすいOutputで評価される組織になりがち。

それは一体、誰のための評価なんだろうか。

3B 安西さん

エンジニア、エンジニアリングマネージャーとして成長するために必要なこととは？

安西さんのTwitter

環境によって人は変わる。

チームに対するアプローチはたくさんある。
でも個人に対するアプローチって1on1くらいしかない印象。

個人へのアプローチも重要。
個人の力も重要だよねという話は及部さんのセッションでもあった。

今日話すこと。

やり方、スキルや技術。
あり方、人間性や度量。

コルブの経験学習モデル。
雑にまとめると振り返りと行動を変えるのサイクル。

発達範囲の話。
年齢がいくとより大きくなるのは、
経験や知識によって周りの環境をインプットとしてアウトプットする傾向になるから、なのかなぁ。

自分のことは自分ではよくわからない。
及部さんのセッションでも言葉にしたほうが良いという話があったし、
ジョハリの窓にもそんな話があった気がする。

KPT+感じたことをやったらいいのでは?

feelingだから、KPTF(ケプトフ)かなぁw

オーセンティックであること。
自らの不備や弱さ、無知も含めてありのままでいること、ということかな。
強いリーダー論みたいなものに引っ張られず自然体でいること、みたいな。

確かティール組織にも似たようなことが書いてあった気がする。
(これはホールネス(全体性)という言葉で表現されていたことに似ていると思った)

突然リーダーやマネージャーになると経験が無いからできない、という話があると思うけど、
オーセンティックになることで意外と上手く行くことがあるのかもしれない。
自分も強がるリーダーよりも、頼ってくれるリーダーの方が支援したいと思う。

セッション途中でいつもと違う行動を毎日続ける、という話があった。
これは非常に良いと思ったのでなるべく振り返りをしつつ、
違うことをやるようにしていきたい。

ちなみに今日はDecLOVEに初参加するという、普段と違う行動をしたw

4E 高柳(ガオリュウ)さん 質問あり

ファシリテーションを活かす仕事の仕方～問題はだいたいファシリテーションで解決できる～
スライドとしての資料はなかったので、ツイートから当日の話がわかりそうなものをペタリ。


ちなみにガオリュウさんだと認識しないで参加してましたw
ずっと気になってた方なのでセッション楽しみ。

ファシリテーションスタイルの変化、今は許容というスタイルに。

ファシリテーションはなんとなく場をコントロールするというイメージがあるので、
許容する、つまり自由にするとファシリテーションできていない状態になりそうだけど…。

許容すると自由はまた別なのかもしれない。
これを懇親会で以下のように質問させていただきました。

質問：ガオリュウさんのファシリテーションの変化として、
2015～2019年では「許容」というキーワードが特徴としてお話されていました。
しかし、ファシリテーションの目的がゴールに導くことならば、
「許容」というある種自由に振る舞うのはファシリテートにとって邪魔なのでは?

回答：これはコンテキストによります。
ファシリテートをする際に信頼関係や場ができてなければ邪魔になります。
ファシリテーターと相手、あるいは相手同士が信頼関係になければ許容してもうまくいかないでしょう。
その場合は導いてあげる必要があると思います。

しかし、信頼関係ができている間柄であれば、多様性を重視して許容して合意するのが大事と思っています。
お互いを信頼して言いたいことを行って合意を得られれば非常に納得度が高いですよね?
また信頼していれば様々な意見が出てきてより良いゴールにたどり着けます。

5E 安井(やっとむ)さん

何だかんだ言っても好きなことが役に立ってきた

やっとむさんのTwitter

プランニングポーカー、まさにモブワークだよね。
暗黙知を形式知にする良い習慣だと思う。

ウルティマオンライン!
当時ハマってたMMO好きの話を聞くとスゴイ世界だったのをよく聞く(※)

日本版の販売に関してやっとむさんが手紙出したりしてたのを知ってビックリ!
すごい!

※フィールドにアイテムが点々と落ちてて順番に拾っていったら別のプレイヤーに襲われる
※知らないプレイヤーが開いた転送魔法に入ったら絶海の孤島に放り出される
などw

「チームが機能するとはどういうことか」は非常に良い本だった。
ちょっと長いけど、まだ読んでなくて心理的安全性について興味ある人はお勧め。

伝えるではなく広める。
聞かせたいわけではない。
ブロードキャスト。

Podcastにも通じるものがある気がする。
別に聞かせたくてやってる訳じゃないんだ、
ただ楽しくて、そんな楽しさが存在することを知って欲しいと思っている。

「すべては「好き嫌い」から始まる」

以前Podcastで組織論の話をしたときに出てきた本だと思ったけど、
同じ人の別の本だった。
「「好き嫌い」と経営」という本もあるみたい。
気になってきた。

今日伝えたいこと。
ボードゲームをやろう!

ボドゲはいいぞ!

6E のーどみさん

ミッドライフクライシスに効く　頑張れなかった10年

のーどみさんのTwitter

ミッドライフクライシスについて。
中年期の心理的危機。

後悔や劣等感わかる。
人生の前段階で犯した過ちを正す、または取り戻そうとするも分かる。
それが過ちなのかどうかもわからないけど・・・。

夢に手足を。
良い文章だなぁ。

のーどみさんの話、いい内容だった。
お互いに大丈夫だと言い続けたい。

7A 川口さん

モブプロの聖地 Hunter Industries で学んだこと

川口さんのTwitter

anti fragile。
ガチガチに固まった状態ではなく、
柔らかな靭やかな状態ということかな。

北斗の拳のトキというのは、まぁ分かるw

外の開発現場を見に行く仲間を増えたら良いなぁという話。
良いなーとは思うけど、確かにやってる人は少ないと思う。

ハンターでのモブ。

Aさん、Bさん、Cさん1回目、
Aさん、Bさん、Cさん2回目、
マイクロコミット、
レトロスペクティブ、
休憩10分とか

モブの時間は3分とか5分とかモブが決める。
ちゃんとタイマー使って決めた時間に交代している。
周りだとダラダラ続けちゃうことが多い気がする。

この期間でレトロスペクティブを回しているのがスゴイ。
ハンターの人は"実験"ということをよく言っていたけど、
その間隔でも実験の成果をちゃんと得ているんだろうな。
モブとしても個人としても。

メールを読むのをモブでやるwww
しかも人事異動のメールw
面白いなーw

慎重なコーディング。
慎重に動くコードを実装して価値を構築していく。
少ないコードで大きな価値を提供できる。

これもOutputよりもOutcomeなのかもしれない。

マルチモブでやってて、モブによって3分とか5分とか違う。
あとタイマーを使ってなかったりもする。
それぞれで実験しているらしい。

困ったことがあればモブ間で手伝ったりもする。

2日目

1E 沢渡さん

『仕事ごっこ』をやさしく滅ぼす
あまねさんのTwitter

問題地図シリーズとNAVITIMEのコラボが期待されるw

あまねさん、今回のテーマは仕事ごっこの話だけど、
始まる前のスタッフや会場スポンサーへの拍手、
喋り方、立ち振舞はファシリテートや場作りに対して本当に参考になると思う。

今日のキーメッセージ。
仕事を科学して、仕事ごっこをやさしく滅ぼすのだ!

今日は仕事ごっこというあまねさんの新刊についての話。
そもそも仕事ごっことは?
生まれた当初は合理性があったものの、現在では生産性やモチベの足を引っ張るもの。
たしかに。

なぜその仕組、やり方なのか?ということを考えるのが大事ですよね。
決まったことに従うのが合理的、正しいと思ってしまうことが多いけど、
考える労力を払うのが嫌なだけだったり、それを認めたくないだけなのかも…。

あまねさんの話、面白かった!
今はまだ「仕事ごっこ」に笑っていられるけど、
自分がビジキュアになったりお殿様になったりしないようにしなきゃいけないとも思った。

やはり自分以外の物(他者、他社、異なる世代、コミュニティなど…)に対する敬意や相互理解を忘れてはいけないと思う。

2D 家田さん

Git導入から始まった私のアジャイル
資料見つからず…。

チームや現場で困っているものに的確に改善案を提供できると、やはり上手くいきそう。
Gitの話もそんな感じっぽいなぁ。

ヴァル研究所さん、新人研修の一貫(?)でアジャイルサムライを配るの良いなぁ。
四天王(予算、納期、品質、スコープ)はトレードオフスライダーの話でもあった気がする。

SVNで辛かったのは柔軟に運用できない点でそれをGitなら解決できると思ったんだろうけど、
そのタイミングでレビューを必須化にしたのはどういう理由だったんだろう?
単純にGitの運用フローがそうなっていたから、なのかな。

質疑応答で上記を質問しました
当時のチームの問題意識として品質の話もあり、レビューでそれをカバーするという解決策だったらしい。
またテストコードが書きづらい状態だったので、レビューで品質担保する方向性もあった。
ついテストコードが書きづらい構造に負けて思考停止しちゃうけど、工夫は出来るのは良い知見。

マージの際のレビュー必須にすることで、想定外の効果として新人の教育に役立った。
当たり前の環境だと実感が無いかもだけど、レビュー文化が無いところに導入すると効果か実感できそう。
すでにやっているチームも改めて意識してみると、レビューで得られるものが増やせるかも。

プラクティスの導入もそうだけど、
「XXやめました」も聞きたい話だなぁ。
やめるのは結構勇気がいるので、事例があるとすごく嬉しい。
社内で共有できるのが一番だろうけど、難しいようなら社外でやるのも良いんだろうな。

KPTをやると問題ばっかり出るのでウンザリするというのはよく聞く話だけど、
プラクティス導入や改善するときに問題や課題ばっかあげつらうのもマイナスになる時がありそう。
いいところを上げていってより良くするためには、という文脈も良いんだろうな。

これからやっていきたいこと。
社内向けの現場見学会を継続してやっていきたい。
良いところの共有が目的なのかな。
毎回、神回!という感想が出るらしい。

良い習慣なので規模が大きめの組織は真似すると良さそう。

3A Stefan Nuesperling&Arnab Guptaさん

ニッポンが必要としているアジャイルリーダーシップとは何か？

www.slideshare.net StefanさんのTwitter、ArnabさんのTwitter

エクササイズ。
仕事であなたを幸せにするものはなにか?

楽しい、リリースして使ってもらえる、思い通りに行ったが周囲で出てきた話。

日本で必要なアジャイルリーダーシップの話だけど、
後半はManagement3.0の話。
興味深い。

イノベーションはテクノロジーに限らないって良いなぁ。
マネジメントやリーダーシップに絡めてスゴイ良い話。

環境を変えるのは悪、逃げ、という話がよくあって、
自分も自分に対してそうやって思ってしまうけど、
見方が変わったり気づきがあるから決して悪いものではないはず。

何事も受け入れ方、受け止め方、まさに見方の問題なんだろうな。

モブプロのHunter Indsutriesの人も言ってたけど、
開発しつつ実験していくのは大事なんだよなぁやっぱり。
黙ってても周りが変わるんだ、自分達も変わっていかなきゃいけない。

ムービング・モチベーターのようなイベントでアウトプットすること。
これは及部さんのセッションでも、
思っていることを声に出したほうが良いという話があったように、
実際にアウトプットすると整理されたり、新たな気付きがあったりする。
聴衆者からもそういう感想が出ていた。

ちなみにこんなツイートがあったので、Management3.0が気になったら行ってみましょう!


4A 湯前(ゆのん)さん

キャリア形成に必要なのは、ただ飛び込むという勇気だけだった

ゆのんさんのTwitter

市場価値の話。
先日ゆのんさんにaozorafmに出て頂いたときも、投資対効果の話をされていた。
自分がやったことや買ったもののコストが効果を常に考えていると言っていた事と通じるものがあるなぁ。

ゆのんさんの話が面白くて普通に聞き入ってしまった。

どうやったら声がかかるのか?
(リーダーやVPoEのお誘いなど)

社内(関係者)に自分のやっていることを伝える。
それらがキッカケになってチャンスが生まれている気がする。

マネジメントの魅力をちゃんと伝えるには?

ピープルマネジメントだけではない。
何が楽しいかをちゃんと伝える。
同時に業務内容をちゃんと伝える。

5C 西村さん

チームの未来が見えていますか？

西村さんのTwitter

10年前から同じチームの人?
いないですよね。
じゃあ10年後のチームを想像できますか?

本は最初に目指す姿。

例えばリリース失敗したとき、振り返りでKPT書く?
いや青空の下で良かったこと話そうよ。

レカジーに囚われて上手くいかないチームが、
リリース成功でレゴブロックを一個ずつ積む。
なんか形になってきて嬉しい!

チームをモチベートするのは本に書いてない。

直人さんの資料、キーワードを並べているスライドだけど、
色や文字の大きさで表現しているのがすごく良いなぁ。
単にわかりやすいを超えた何かがある。
形容し難いw

自分の未来は考えことがあっても、チームの未来ってありま考えたことなかった。
確かに10年後、今のチーム(会社)にいないよなぁって思っちゃうけど、
思考実験として考えたとき、
いま改善改善!と叫んでいてもチームがどこに向かっているかは考えていないよなぁと。
すごい刺激になった。

5C 倉貫さん　質問あり

自己組織化されたエンジニアチームを作る習慣 〜プログラマが経営者になって10年の学び 資料なしで喋っていましたが、まとめていただいた方のツイートは以下のとおり。


40分で自分のこれまでとこれからの20年間を話すには時間が足りない!
知見が多すぎる!
だからブログとか本を読んでほしいw

実装工程ってだいたい燃えているじゃないですか?

これは分かる人には分かるし、分からない人には分からなさそうな話かもw
(要件定義や設計に時間がかかる受託開発や請負だと実装以降は燃えやすい…)

自己組織化を目指しては自己組織できない。
だから自己組織化について本も書かない。

自己組織化が目的ではない。
上手くいかないときに不要な要素を取り除いていったとき、
管理をなくすときに自然とセルフマネジメントになっていった、ということか。

相談されたら軽く返すようにしている。
重く返すと身構えてしまうので、軽く返して相談した人のフットワークが軽くなるようにしている。

たしかに相談して人がうーん…って言ったらやっぱ無理かーと思っちゃうよね。

結局は人。
人と人との繋がり。

不思議とシステム開発をやっていくと結構な人数の人がこう言う気がする。

セッション後、個人的にモブプロが好きなので、
リモートで開発されているソニックガーデンさんでは実施しているのか質問してみました。

質問:フルリモートで開発されているソニックガーデンさんでもモブプロってやられてますか?

回答:やってますよ!
もちろんリモートでやってます。
ただし常にモブでやってるわけではなくて、
難しいこととか誰も知らないことをやるときにやっています。
Railsで開発するだけならわかってる人がやっちゃったほうが早いですよね?
なので、効率的に調査や試すためにやってる感じですね。
あとタイマーとかは使わずに結構ラフにやってます。

クロージング　市谷さん

我々はどこまでいっても、ぼっちだ。それでも、ともに。進んでいく。

www.slideshare.net 市谷さんのTwitter

同席とリモートについて。
人々が開発のあり方とは別に、生き方の多様化を選択した、ということ

共に在るために。

上記の2つの話を聞いて、
サピエンス全史であった神話による社会の拡大の話を思い出した。

全員と関わり合いが持てる集落から知らない人が共存する国に拡大した時、
共通の話(神話)が人々を纏める力となった。

じゃあ顔を突き合わせて働いていた我々が、
同席から遠隔でのリモートを選択したとき共有すべき話ってなんだろう?
物理的にその場に居合わせるためではなく、共に在るために何を共有すればいいんだろう?
開発チームは何を共有すれば神話やお金のように絶大な力を発揮するのか、考えてみたい。
(いまのところ答えはない…w)

おわりに

というわけでほぼツイートを貼り付けるというだいぶ雑なわりに長いブログでした。
最初に書いたとおり、質問ありのとこだけ読んでもらえれば良いかなーとw

いろんな方のこれまでの10年を聞きまくった結果、
最初にやりたいことがあって、それが結果としてコミュニティや本や「〇〇の人」のようなラベルになるんだなと実感。

自分もやりたいことはありますが、形に残るように整理してアウトプットしたことがないので、
ちゃんとブログに残してみたいなぁと思います。

これからの10年がどうなるかわかりませんが、
10年後にこの記事を振り返られたら良いですね。
参加目的の通りいろいろ元気をもらえたので、またいろいろやっていこうと思います。