ある改善、プラクティスやTryをいつやめるのか。もしくは5000枚のKPTの理由。 #scrumosaka #rsgt2019

先日、 Scrum Fest Osaka 2019というカンファレンスでとある方からこんな質問をうけました。

きょんさんのチームでは、何度かやればうまくいきそうなTryとかプラクティスがあるときに、いつまで挑戦するとか、いつになったらやめるとかそういった基準とかはありますか？

これ聞かれたときに昔の自分だったら「やれなくなるまでは挑戦しつづける」って答えていたとおもうんですよね。でも、今は違うなーと。 僕が答えたのは「やりたい意思がある限り続ける。やりたくないものをやるのは楽しくない。」で、もっと端的にいうと

チームにできるプラクティスは残るし、できないプラクティスは残らない。

というものです。ある種の適者生存というか。プラクティスが正しいから残るのではないというかんじですかね。 ただ、それだと怠惰でルールのないチームは一向に成長しないので、成長するための仕掛けは必要だとはおもいます。 でもそのときに、ただ問題を解決するためにプラクティスをいれることでは定着しないんだろうなーというのが自分の感覚です。 毎日のように徹底された食生活管理と運動を納得してもできないこともあるし。

まだうまくまとめられないんですが、感覚的には「問題を解決する方向と、自分が楽しめる方向が同じ方向をむいている」ってことかなーっておもいます。 で、過去の自分もそうでしたが、「人を問題に寄せる」のはビジネスなんだから当然のようにできるっておもってしまって、いろんなところでヘイトがたまる。。。 いまの基盤チームはそれは時間がかかるのが普通なので、15min毎にとても小さな量のいい事にもわるい事にも触れ続けることで、人を問題に寄せる、問題と一体となるくらいに考えられるような場にしていくことをやるようになりました。それが大量の付箋となっている KPT as ARTなやつです。 Scrum Fest Osaka にておおまかには bleisさんとdico_lequeさんが話してくれました。

KPT as ART

Scrum Fest Osaka 2019 - 感謝のKPT 5000枚 -基盤チームのレトロスペクティブ- | ConfEngine - Conference Platform

KPT as ART になった理由。ふりかえりへのむきあいかた。

わたしからはこれの経緯とか語られなかった部分を。

これも最初からうまくいったかというと、チーム内でいろんな意見もありましたが、わたしはこれがうまくいくと信じていたし、いろんな議論をへて今の形になりました。チーム内であったのは「情報がたくさんあって整理できない」というものでした。これはいわゆるKPTとは情報を整理し、問題や改善案を具象化する行為だと考えていれば当然だとおもいます。でも、私がおもうにそれは長期間存在するチームには無理だということです。おおくの人はかしこいというか、かしこくないので、具象化できる課題はすぐに尽きます。いいかえると、適切な具象化をあまりできません。

人間はあまり賢くないので整理するため具象化するためのKPTというのはすぐに限界をむかえます。これがKPTがうまくいかない根本だと私は考えています。

1週間に1度できないKPTにむかいあうよりも、具象化するための材料となる量を増やしていき、文字通りその情報にかこまれることで、なんとなく自分達の状況が心にうかびあがってくる。そういったスタイルが長期間存続させるチームには最適だと。

ので、ふりかえりででるような情報は整理しながら増やしていくのではなく、好きなときに整理する、どちらかというと、整理できる状況になったら自然とされる、というのがいいのだろうと。エンジニアというのもあって、とかく情報を整理したがる性質からの脱却に時間がかかったメンバーもいましたが、それもふくめてゆっくりと慣れていきました。

これに似たこととして、チームの外から「この付箋を見返すことなんてできないから意味ないでしょ」とかいわれます。これも結局は上と一緒で、KPTとは整理してチームの道標となるべきものであるという考えからだとおもいます。私達はそういうことをこのKPTでやりたいわけじゃないので、別にそういった必要はないという回答になります。

では、基盤チームは自分達が向かうべき場所についてはどのように話しあい、どのようにそれがのこり、どのようにいまかかえている問題がのこるのか。 基本的には会話でなされていて、それがテキストとしてはKPTにのこります。でもその付箋を見返すことはないですね。 チーム内で濃密に会話したときの体験のほうが付箋に貼られるよりずっと記憶にのこり、そして信頼関係を築くためにはずっと大切だと、そう実感しているからです。 そしてまた、私が基盤チームの考えをプレゼンテーションにしていき、みんなの意思がまた1つかたまる。そういったサイクルをこの4年間続けてきた。といったかたちです。

ちょっと長くなってきたので、基盤チームの話はこのへんで。 続きとか、他の話気になるー!って人は、飲みにさそったり、お仕事のご依頼おまちしております。(あ kyon-mm.com

複業でチーム開発のコーチやアーキテクトをはじめました。 kyon-mm.com

2019/1から複業でチーム開発のコーチやアーキテクトをはじめました。(TwitterやFacebookで開業しましたとだけかいていましたのであらためて。) 週2以下の稼動であればおきがるにおといあわせください。

kyon-mm.com

たまに今回の私の状況についてご質問をいただくので、ここでまとめておきます。

#RSGT2019 の歩き方

はじめてRSGT2019に参加する人、もっとたのしみたい人などたくさんいるとおもいます。ということで、RSGT2016 - 2018まで参加してきた身としての歩き方を紹介します。

本エントリは 「Regional Scrum Gathering Tokyo Advent Calendar 2018」（非公式）26日目の記事です。（は？） adventar.org

confengine.com

まず会場近くに宿泊しよう

会場は大崎ブライトコアホールです。平日開催で朝から & 毎日(任意で)飲み会がある ことから会場近くに宿泊することをオススメします。徒歩20min圏内くらいを考えると、大崎や五反田でしょうか。五反田はそこそこホテルがあります。

朝の通勤ラッシュにもまれて体力をうばわれると、RSGTでは体力が保ちません。万全でのぞんでいきましょう。

基調講演はきいて損がない

どんな基調講演でもいいところ、わるいところそれぞれあります。それでも基調講演は価値が高いのです。とにかく聞きましょう。あきたら退室して、スポンサーブースの人に声をかけましょう。

1. なにかしらインパクトがある話をする（なんらかの新規性がある、規模が大きい、トレンドをまとめている、レジェンド的存在）
2. RSGT参加者のうち、おおくの人が聞いているので参加者同士での会話のキッカケにつかえる

ランチでは隣の人に声をかける or さっさと食べてホワイエ（ホール外）でドリンクをのみながら声をかける

おそらく今回もランチはお弁当がでて、(任意で)ホールで食べることになります。この場で声をかけてみましょう。話しかけるの苦手な人は次をまず言えば大丈夫です。

1. 何度か参加したことあるんですか? 私はn回目なんですけど。
2. さっきの基調講演ききました? 私はxxxのトピックいいなっておもいました。どんなところ気になりました?
3. 今日はこのあとどの講演聞くか決めているんですか?
4. Scrumやっていますか?

これでだいたい5minはもちます。話好きな人だったら30minくらいもつんじゃないですかね。

ランチ後の講演はどれか2,3つ聞いて、それ以外はホワイエ（ホール外）でスピーカーをつかまえる or 休憩する

1日ずっとすわって聞いているとそれだけで疲れます。できるだけダラっとする時間をとりましょう。 ホワイエにでたら、（まだ講演していないスピーカーも含めて）なんにんかのスピーカーがだいたいいます。気になるスピーカーがいたら、積極的に声をかけましょう。

1. 次にどのセッション聞くか決めているんですか?
2. (決まっていないといわれたら) 今回の講演をしようとおもったキッカケってなになんですか?
3. (決まっているといわれたら) その講演のどのへんが気になるんですか?

スピーカーは話したがりの人がおおいので、声さえかければ、勝手に話してくれます。楽ですね。

初日のネットワーキングパーティではここまで話した人をつかまえよう or 気になる人に声をかけよう

例年どおりであれば、ホワイエで立食パーティになります。とりあえずドリンクとか軽食とかに並ぶことになるとおもいます。 並んでいるときは隣の人に声をかけてみましょう。また、ここまでで声をかけた人をみつけてみるといいとおもいます。 だいたい聞くことは次で大丈夫です。

1. 今日はどの講演がたのしかったですか?
2. 私はxxxの講演がたのしかったです。yyyなところとか。
3. 明日はどの講演を聞く予定なんですか?
4. RSGTにはなぜ参加したんですか?

2日目もほぼ同様でOK

基本的な流れは一緒なので↑のとおりで大丈夫です。ちがうのは、ネットワーキングパーティがないことくらいでしょうか。 ちょっと食事してから帰りたいなーっていうときには、「今日おわったら一緒にどこかいきませんか?」といってみましょう。そんなんハードルたかい!とおもわれるときには、スピーカーにいってみましょう。そう、かれらは話したがりです。（万が一、断われてもそんなに落ち込まないでね！）

3日目のOSTは聞きたいトピックにまず参加

3日目はOpen Space Technologyといって、最初の30min程度で、参加者が議論したいことを自由にタイムテーブルにいれていき、時間になったら自分達で議論がはじまるスタイルです。もし話したいトピックがあればその場で出しましょう！なければとりあえず雰囲気をみながら参加で大丈夫です。

OSTでの議論は正解や不正解などはなく、その場にいる全員が参加すべきメンバーがあつまっているというリスペクトをまもってすすめるものです。初心者だったとして、自分がいてもいいのかとか、発言が貧困なのではないかとか、悩む必要はありません。

まとめ

RSGT2019の歩き方を紹介しました。ここまで書いといてあれですけど、どのカンファレンスでもこれでいい気がしている。

この記事を書くキッカケをくれた id:ayumi_h ありがとう

とても良記事ばかりで、25日までではなく年末まであったらいいのにな、という気分です。

ayumi-hsz.hatenablog.com

SCRUM BOOT CAMP THE BOOK

スクラム　仕事が４倍速くなる“世界標準”のチーム戦術

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)

アジャイルコーチング

なんちゃってアジャイルから、4年間アジャイル開発していたら15minスプリントになった件 #RSGT2019

概要

• とりあえず次の動画をみてほしい。
• ちまたのアジャイル開発チームはスプリントが1週間だが、私のチームは15minで回している。
• 学生や新卒に1日スプリントを教えている。彼らは5日程度で1日スプリントをマスターする。
• 15minスプリントを含んだプラクティスについてスライドにしてほしい、聞きたいという人は RSGT2019の公募にlikeしてほしい。かりにlikeはなくても、RSGT2019に参加しよう。

セッション confengine.com

チケットはこちらから！11/16から販売だそうで。 Regional Scrum Gathering® Tokyo 2019

www.youtube.com

背景

このチームが今までどんなふうに開発を経てきたのかはだいたい次のスライドにまとまっています。 簡単に言うと、なんちゃってアジャイルをやっていて残業と改善が低いチームだった。そんなチームがちゃんと開発しよう、アジャイルに向き合おうって変わって4年もたった今の話。 開発対象はWebAPI、フレームワーク、ライブラリ、プラットフォームなどいわゆる基盤的なもの。なので、このチームを基盤チームと呼んでいる。そして受託開発です。

• 2015の話 => Scrum,Test,Metrics #sgt2016
• 2016の話 => Scrumありがとう、 そしてさようなら -Scrum 破- #rsgt2017 - Speaker Deck
• 2017の話 => Scrumが難しいのは幻想-情熱の再定義- #RSGT2018 - Speaker Deck
• 2016,2017,2018上半期の話 => 美しく生命力あふれるチーム 〜1時間から始めるアジャイル〜 #CEDEC2018 #CEDEC - Speaker Deck

スプリント期間の変遷

2015年当時の多くの他のチームと同樣にこのチームも例外なく、1週間スプリントが最も短いと考え、2週間スプリントや1週間スプリントを実践していました。 だが、それはPOすくなくとも、チーム内でのフィードバックが遅いと気づきました。 そして、2016年には1日スプリントになりました。

この根底にあるのは、スプリント期間とビジネス的なリリースは必ずしも一致している必要はないということです。もちろん、リリースをあと伸ばしにしていいとかそういう意味ではなく。 自分のチームの仕事は受託開発だったので、もともとスプリント期間とリリース期間は一緒じゃなかったし、国内外の知見を聞いても一致している必要はないと聞いて自信をもってそう踏み切れました。 スプリント計画の内容が達成できているかどうかをPOに確認してもらう期間というだけ。

そうして、2017年にはさらに1時間スプリントになりました。これはこれでなかなか大変で、1日スプリントと同じような質のマネジメントしかできなくて苦しんだりいろいろありました。が、2017年10月にはだいぶ使いこなしていた記憶があります。

そうこうしているうちにいろんな課題を乗り越え、基盤チーム全員で「レッツゴーデベロッパー 平成ジェネレーションズ FINAL」という素晴らしい勉強会への登壇機会をもらいました。これは単純にチーム開発を参加者としてみようというものです。

connpass.com

ここで、基盤チームは30minスプリントを実践してみたのですが、軽々と出来てしまい、チーム内で「30minスプリント余裕すぎるｗｗｗ」という話になり、現場に戻ってしばらくしてから、「よし15minスプリントやってみようぜ」となったのでした。

そして、現在15minスプリントをやっているのですが、大きな問題はなくて非常に開発しやすい状態を保てています。

1日スプリントの頃からそうですが、基盤チームは能動的に時間管理できないので、基本的には学校のチャイムというか、タイマーを使っていて、それによってスプリント期間の開始と終了、スクラムイベントの実施をしています。 これを聞くと、トイレ休憩とかちょっとした休憩はないの？とか思われるかもしれませんが、明示的に休憩の時間もあるので、そこに合わせつつ、まぁ自由にとるという感じです。

RSGT2019

ということで、こういった話、つまり15minスプリントの詳細や、スクラムチームとしての全体像、そしてプラクティスとしてどのように抽出されているのか？などをRegional Scrum Gathering Tokyo 2019 というイベントで話そうと公募を出しています。

講演として聞きたい人、スライドにしてほしい人はlikeをしてください！講演とかいいんだけど、聞いてみたいっていう人はRSGT2019に参加して直接僕を捕まえて聞いてください。Scrumというトピックでギャざりましょう。

セッション confengine.com

チケットはこちらから！11/16から販売だそうで。 Regional Scrum Gathering® Tokyo 2019

念の為言っておくと、私はRSGTの運営でもなんでもないんだけど、みんなとScrumとかチーム開発とかについていろいろ意見交換したいんだけなんだ＞＜ そのための最高の場所がRSGTだと思っている。的な。

参考書籍

スクラム　仕事が４倍速くなる“世界標準”のチーム戦術

SCRUM BOOT CAMP THE BOOK

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

生命の現象

生物系の参考書籍追記

生物模倣――自然界に学ぶイノベーションの現場から

小さき生物たちの大いなる新技術 (ベスト新書)

生物に学ぶイノベーション 進化38億年の超技術 (NHK出版新書)

自然をまねる、世界が変わる: バイオミミクリーが起こすイノベーション

アルゼンチンアリ: 史上最強の侵略的外来種

「それ、何か言っているようで何も言っていないですよね」って思う

何かの解説、会話、ドキュメントでたまに「それ、何か言っているようで何も言っていないですよね」と指摘することがある。

1. 情報量が増えていない
2. 抽象化しすぎて本題からズレている

自分がよく見るのは上の2パターンがある。

1. 情報量が増えていない

具体的にはトートロジーになっている。関係ないことをそれっぽく言っている（文章や会話の隙間をただ埋めているだけ）。

2. 抽象化しすぎて本題からズレている

具体的には対象範囲や主語が大きくなりすぎて、本来のトピックについて具体的な話がない。

1はどうでもいいとして、2が需要がある場合もわかる。 でも、2については全体の中で「一度振り返ってみるとこういう目的なのですよ。そのうえでもとのトピックに戻ると、具体的には〜」みたいな話としてちょっと立ち止まって見る程度の話だと思うんですよね。トピックに戻ってからも延々と抽象的な話をするのは、そもそも元のトピックいらないじゃんっていうね。まぁそういうネタならいいんですけど。

理科系の作文技術（リフロー版） (中公新書)

数学文章作法　基礎編 (ちくま学芸文庫)

数学文章作法 推敲編 (ちくま学芸文庫)

"エンジニアが使うべき便利な windows アプリ一覧" がほしい

誰かが書き始めると、他の人も書いてくれることを祈ってこのエントリを書いている。できるだけ、組織全体で使うツール（チャットツールとか）は選ばないようにした。

エンジニアが使うべき便利な windows アプリ一覧、みたいなのってどっかにまとめないの?

— 徳永広夢 (@tokuhirom) October 2, 2018

RapidEE

www.rapidee.com

Windowsの“環境変数”をGUIで編集できるソフト。各環境変数とその値をツリー形式でわかりやすく表示できるのが特長で、変数や値はツリーの右クリックメニューから追加・削除することが可能。また、値にパスを指定する場合はダイアログを使ってフォルダを選択できるので、編集作業の多くをマウス操作だけで完結でき、編集ミスを起こしにくい。また、無効なパスを赤文字で強調表示する機能を備えているので、入力ミスを一目で見つけることができて便利。過去に指定したパスがソフトのアンインストールなどで無効になった場合にも強調表示されるので、ときどき本ソフトで環境変数を調べれば、無効な値がないか確認できる。そのほか、設定した環境変数をREGファイルとしてバックアップしておくことも可能だ。

cmder

cmder.net

コンソールエミュレータ。最初からフォントがそこそこ設定されているし、便利。

7-zip

sevenzip.osdn.jp

解凍、圧縮アプリケーション。いろんな形式に対応しているのと、パスワードなどもかけられる。エクスプローラ上でのコンテキストメニューとも統合できるので便利。

clibor

www.amunsnet.com

クリップボード履歴管理。数回前にコピーしたテキストをいつでもペーストできるようになる。便利。自分は、Ctrlを2回連続で叩くとペースト対象を選ぶポップアップがでるようにしている。

Chrome, Firefox

www.google.com

www.mozilla.org

Webブラウザ。普段遣いするのはどちらでもいいと思う。WebGUIアプリケーションを開発するなら、結局両方入れることになると思う。

Mate Translate

www.matetranslate.com

翻訳アプリケーション。Chrome, Firefox拡張もあるし、デスクトップアプリケーション、モバイルアプリもある。 Firefox拡張として入れている場合には、英単語を選択すると、日本語翻訳がポップアップされる感じ。

WinMerge

WinMerge 日本語版

ファイル同士やディレクトリ同士を比較して、ファイルのどの行が違うかが見えるようになる。差分がある行をどちらかにコピーすることもできる。他のDIFFツールやマージツールでもいいんですけど、WinMergeが一番楽な気がする。

そしてこれジオシティーズなので、大丈夫なのかが不安です。

Git

git-scm.com

ファイルのバージョン管理ツール。チームで利用するツールなんですけど、Gitは一人でも使えるので、ぜひ入れておいたほうがいい。

Everything

「Everything」高速なファイル検索ソフト - 窓の杜

爆速ファイル名、パス名検索。インクリメンタルサーチに対応しているし便利。

Process Explorer などsysinternals系

technet.microsoft.com

sysinternalsはいろんなツールがありますが、とりあえずProcess Explorerは入れておきたい。タスクマネージャーでは出来ないことができます。（Windows10くらいからリソースマネージャーが高機能になってきているからどんどん不要な場面が増えてきて入るものの） 他には、caps lockをctrlにするツールとかもsysinternalsの1つにあります。

Crystal Disk Info

crystalmark.info

HDDとかSSDの状態のレポーティングツール。できればハードウェア障害は早めに予見したい。

ここで触れていないけど、実質必須になりそうなもの

• テキストエディタ、IDE => 好きなものにしたらいいとおもう。
• チャットツール => 組織に合わせましょう。
• ファイル共有 => 組織に合わせましょう。
• 各種テストツール => もうあげたらキリがない。（これは別立てがいい気がする）

Windows Sysinternals徹底解説　改訂新版 マイクロソフト関連書

Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール Web制作者のための教科書シリーズ

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

「開発現場で役立たせるための設計原則とパターン」をオススメできない理由

「開発現場で役立たせるための設計原則とパターン」は設計をリードするには悪手である

このエントリーは 実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く に対する返答です。 件のエントリーおよびスライドを拝見したときの私の感想は「昔の自分だったらこのようにレクチャーしたであろうけど、いまの私ならこうしない。そして、このようにレクチャーするのは時に問題がある」というものでした。

私は発表を見ていたわけではなかったので、スライドだけを拝見したときにはエントリーとしてまとめるのはどうかと思ったのですが、発表者が丁寧な解説付きの記事をあげてくれていたので、私の考えをまとめるための情報を揃ったと判断した次第です。 そして発表者様のエントリーを読んでも私の感想は変わりませんでした。

まず、件のスライドにおける設計原則の解説自体には問題はなく、サンプルコード付きで解説していることは素晴らしいです。

問題は、設計原則の適用対象が生存期間が短いものになっていることです。これは、ここ20年ではもはや定説とされている「要件はよく変わる」「機能はよく変わる」という問題をそのまま受け継いでいます。つまり、この設計は要件変更に非常に弱い作りです。 ただ、要件変更に弱くてもコストがペイする（ROIが企業としては問題ない）場合もあると思います。私はそのような場面についてはあまり興味はありません。 私が興味があるのは、「変更につよい」とうたう設計とはなにか？という話です。

一応、記事中でも次のような説明があります

「問題によって適切な構造は変わる」

ただ、この文言が出てくるのはずいぶんと後半です。2/3はこれに反したような内容をつらつらと書いています。 仮にこの文言が最も主張したい内容だったとして、つまりそれはどのように実践するのか？についてはまるで解決方法が提示されていません。 これでは「この発表では考慮していませんが、考慮すべき大切なことがあります。（どうやるかは提示しない）」という発表になっています。なんの発表だったんだ。。。

発表の中にでてきた、コメントがどうこうとか、通知がどうこうとかってあきらかに機能の話で、その機能を構造化しても結局変更されるので弱いんですよ。もちろん設計は必要なんですけど、もっと重要な設計が先にあるということです。

まずは普遍的なモノゴトを対象に吟味して設計し、機能の設計はもっと力を抜いて設計したほうが良いです。

よく変更されるような振る舞いについては簡単に書き換えられるようになっているほうが楽だし、そのときに「この機能はこんなに重要だ！」という思い込みによる具象化と抽象化をするのは、いわゆる早すぎる最適化と同じ問題を抱えています。

私のバイアスの話

私はアジャイル開発やメッセージベースオブジェクト指向が好きです。ここの共通テーマは「決定を遅延しながら機能するネットワークを常に作り続ける」ことだと思っています。 そして共通する課題意識が構造というのは人間が計画駆動で生活したいというためのフォースが働いているものであり、私はそれをもっと使いこなす必要があると考えています。（言い過ぎかもしれないけど、構造を決定する必要はほぼないと私は考えている節がある） 少なくともIT業界でアジャイル開発の根本的な概念は広まっていて、要件はよく変わるし、見通せるものではないのだから、常に変化に対応しようとする話があります。 よって、私はこの考え方に反しているとさきの記事を見て思ったのです。（記事の中で「常に考えよう」という姿勢はあるんですけど、対象があまりにも狭いという話です。）

おまけ

では、私は実践できているのか？というと、幾分かは出来ていると考えています。まだ道半ばです。 その道半ばですが、何を考えてソフトウェア開発をしているのか？どのように要件を考えたり、設計をしているのか？というチャレンジの話を今度発表しようと考えています。 公募制なので通るかわかりませんが。公募が通らなかった場合は別の機会に発表しようと思いますので、聞きたい人はお気軽にコメントなりTwitterなり教えてください。

confengine.com

関連書籍

生命の現象

生物模倣――自然界に学ぶイノベーションの現場から