TechとPoemeの間

Qiita に書かないエンジニア業の話

喜び・情熱・大義 - Regional Scrum Gathering Tokyo 2018 に参加した

Regional Scrum Gathering Tokyo 2018 に参加してきた.

f:id:mura-_-mi:20180113152936j:plain

昨年から会社のお金で行かせてもらえているのだけれども,去年は色々とわけがあって1日目のみの参加だった.今年は,初日の説明から3日目の Closing Keynote までもれなく参加できた.嬉しい.

聴いたトークを順々に振り返る.

Build a Workplace People Love – Just add Joy (Rich Sheridan)

書籍『Joy, Inc.』の著者による基調講演

f:id:mura-_-mi:20180113153453j:plain

この本読んだこと無かったんだけど,メンローベイビーズの取り組みを聞いたときにはあまりに想像の向こう側を行き過ぎていて,即売会で書籍を購入し,それから行き帰りの電車とかでめっちゃ読んでいる.トークの内容は,ほとんど書籍の内容を実際の写真などを交えての紹介でした.

f:id:mura-_-mi:20180113182317j:plain

即売会はサイン会付きでした! 本当は僕の最良の読書時間である風呂の時間にガンガン読んでいきたいのだが,Rich 本人だけでなく,翻訳者5人全員のサインまで入った書籍は,流石に水没のリスクには晒せず…

Cultural context is everything (Matteo Carella)

f:id:mura-_-mi:20180113153926j:plain

Agile の取り組みは,どのようなドメインかだけでなく,そのチームの文化や文脈に依存するから,具体的なやり方だけを真似してもうまくいかないよ,という話.事例紹介は,その背後にある原則や価値観を知るためでしかないよ,というのは本当にそうだなと思う.
で,文化は "Intangible" つまり形にはならないから触れられないけれども,"Ritual" つまり儀式としてその文化の一員になる手筈を整えることで,少し Tangible になるよ,という話は面白かった.

サーバント・リーダーシップを掘り下げて考えましょう (Rochelle Kopp)

日本の会社の生産性を上げるための経営コンサルタントをしているロッチェルさんは,今年の活動のテーマをサーバント・リーダーシップに置くとのこと.

f:id:mura-_-mi:20180113154720j:plain

チームを主役にするサーバントリーダーこそ,コーチングのスキルって大事なんだろうなぁ,とか思った.

6 Years Of Teaching Certified Scrum Developers: Re-spec, Re-design & Re-entry (Terry Yin)

Odd-e での認定スクラム開発者研修 (CSD) のトレーナーである Terry によるセッション

f:id:mura-_-mi:20180113155026j:plain

CSD 研修では,前の回の研修で参加者が取り組んだプロダクトに,新たに機能を追加する開発をするんだって!(すごい
ソフトウェア開発は「知識を」「創出し」「保存する」という3つが大事,ということを5日間かけて教えるのが CSD の研修とのこと.この3つの重要性は考えてみれば当然ではあるのだけど,端的に言えている言葉だなぁ.どういう人が CSD 研修に参加しているのか,ちょっと気になった.

Walking Scrum History with Patterns (Kiro Harada)

あんまり原田さんの良い写真が無かった…

f:id:mura-_-mi:20180113171517j:plain

スクラムがどのように生まれたかという話を,パターンランゲージという観点から振り返るという話.ScrumPLoP 知らなかった

www.scrumplop.org

Embrace Collaboration and Fun of Coding (Michimune Kohno)

アメリカの開発チームに参加することで感じた文化の変化,アジャイルへの転換などの話.

f:id:mura-_-mi:20180113173450j:plain

お仕事がとても楽しそうなお話ぶりで素敵だった.いちいち刺さる言葉ばかりだったけれども,写真にある「Agile 開発とはバックログと共に生きることと見つけたり」は,素晴らしい言葉だなと思った.バックログがなくなったときはプロダクトの終わりだし,バックログが積み上がっているということは,プロダクトはまだ成長する可能性があるということ.これから積極的に使っていきたい.

Scrumが難しいのは幻想 -情熱の再定義- (kyon_mm)

とても楽しみにしていた id:kyon_mm さんの発表

f:id:mura-_-mi:20180113173959j:plain

(スクラム | アジャイル) をやるには情熱が必要,という,人のメンタルに頼っている状態を良しとしない,それを突き詰めたら「情熱はシステムと同じ」という結論に至った,という話.1時間スプリント,今の自分が出来るとはまったく思えないけど,なんか割りと簡単にできるように思えちゃうようなお話ぶりだったのが不思議だった.

全くレベルは違うと思うけれど,「システム開発開発プロセスの策定も,フロー単位とリソースの最適配置の問題という意味では同じ」ということを考えていた自分にとっては,進んでいく方向は間違ってないんだなぁと思うことが出来た.

スクラムチームとして、妨害リスト(Impediments List) を運用して見えてきた課題解決方法 (Narichika Kajiwara)

eureka の梶原さんによる,Impediments List の話

f:id:mura-_-mi:20180113174336j:plain

妨害リストはスクラムガイドにも出てこないし,運用事例もあまり聞いたことがなかったので,とても貴重なお話でした.
「レトロスペクティブをシングルループ学習と捉えて,妨害リストはダブルループ学習と捉える」とか,「チーム外も含めた透明性の担保が大事」とか,「やってみるとうまくいきそう!」という話が満載でした.

モヤモヤ女子大生がプロダクトオーナーになったら!

Odd-e Japan の実施したインターンで3ヶ月のプロダクト開発をした中で,プロダクトオーナー (P.O.) ロールを担った5人の女子大生の物語.

f:id:mura-_-mi:20180113174901j:plain

スクラムマスターのロールを努めた知花さんの力量の賜物でもあるのかもしれないけど, P.O. を努めた女子大生は誰もプログラミングなどのバックグラウンドを持たず,その中でこれだけ出来たよ,という事例はもっと色んな場所で広まってほしい.

実感駆動でものづくり ー 協調学習過程としてのスクラム。欲しいものを、どうやって知るか。 (パネルディスカッション)

企業内での新規事業立ち上げを行う中でのカネと (社内) 政治の問題にどう立ち向かうかという話題.

f:id:mura-_-mi:20180113180238j:plain

黒田さん (id:i2key) の「資金調達のタイミングもアジャイルにならなければいけない」という話が非常に興味深かった.あとは「グレーゾーン わざわざ聞くから 黒になる」最高の標語w

山崎さんいわく,コクヨには2つの標語があるそうな.これもとても良かった.

  • ギブギブギブテ (Give と Take の比率は圧倒的に Give が多くないといけないということ)
  • 角を立てずに波風立てる

Open Space Technorogy : 「UI の無いプロダクトのスプリントレビューをどうやるか」

Open Space Technorogy は,ちょっと勇気を出してテーマを出してみた.広告配信システムを作っている中で,UI より先に入札配信システムを作っていたりしたので,その時の悩みをぶつけてみることに.

f:id:mura-_-mi:20180113180947j:plain

f:id:mura-_-mi:20180113180828j:plain

喋りながらだったからあまりイーゼルパッドには書けてないのだけど…

思った以上に人が来てくれて,30分ワイワイと議論できました.最初数人だったから自己紹介回してたけど,あれよあれよと人が増えたから途中で中断せざるを得なかったw
API を作っている人とか,スプリントレビューにどのステークホルダーを呼ぶのかを気をつければ良さそうだよね,みたいな話とかしていた中,

f:id:mura-_-mi:20180113181235j:plain

原田さんが「551 メソッドを使えばいいんだよ」と一言.

www.youtube.com

プロダクトバックログに「あるとき/ないとき」を書けば,そのプロダクトバックログの価値がわかる.そうすれば,UI がなくても何を作ってどれくらい価値が生まれたかがわかる.
なんだ!端的でめっちゃわかりやすい!とかなってました.

あなたの中に世界がある / You are the World (Akiko Iwakiri)

翔泳社の岩切さんによるクロージングキーノート.

f:id:mura-_-mi:20180113181454j:plain

f:id:mura-_-mi:20180113181640j:plain

大義は自分の中にある,それを (仕事を通じて) 満たすことできっと自分や世界が変わる. 今風に言うと最高にエモくて,3日間を締めくくるのに最高のセッションでした.Agile2017 のクロージングキーノート "Banish Your Inner Critic 2.0" もめっちゃエモかったんですけど,やっぱりこういうの狙うんですかね.

www.agilealliance.org

自分の大義を付箋に書く,というアクティビティがあったのですが,私はこう書きました.

f:id:mura-_-mi:20180113181502j:plain

なんというか,最近,今後のこととか,周りのこととか,いろいろ考えますけど,その悩みとか迷いとか思い切りを反芻すると,割とすんなりと出てくる言葉でした.今年はちょっと "大義" を意識してみよう.


ということで,3日間本当に楽しかったです!長い間準備を頑張ってくださった実行委員会とスピーカーの皆さまに感謝!
来年またお会いしましょう!

「フロー効率」をチームの常識にする - 『This is Lean』の内容をチームメンバーにレクチャーした話

フロー効率性と「This is Lean」

あくまで自分の観測範囲での話ではあるのですが,2017年,ソフトウェアやITシステムの開発プロセス関連に興味がある人たちの間でホットだったキーワードのひとつが「リソース効率性とフロー効率性」だったと思います.

私自身,それまで「リソース効率性とフロー効率性」という概念は知らなかったのですが,9月にあった XP 祭り2017 での発表を拝見してから,自分の中では一気に火がつきました. 具体的に「リソース効率性とフロー効率性とは何か」という話は,その時の発表者である id:i2key さんの発表資料やブログのほうが詳しいと思うので,興味のある方はご覧いただければと思います.

i2key.hateblo.jp

www.slideshare.net

簡単に言うと,「効率良く仕事をする」と言っても2つの方向性があり,それが「リソース効率性 (Resource Efficiency)」と「フロー効率性 (Flow Efficiency)」です.
「リソース効率性」とは,「プロセスを構成するリソース (ソフトウェア開発プロセスなら人,病院なら医師や医療機器) 稼働率を高くする」というアプローチで,一方で「フロー効率性」とは「プロセスを流れる価値の単位 (ソフトウェア開発なら開発機能や不具合,病院なら患者) がプロセス内で価値の付加されない待ち時間をなくしてリードタイムを短くする」というアプローチです.

この「リソース効率性とフロー効率性」という概念を明瞭に解説しているのが,i2key さんの登壇資料にもある『This is Lean: Resolving the Efficiency Paradox』という書籍です.

This is Lean: Resolving the Efficiency Paradox (English Edition)

This is Lean: Resolving the Efficiency Paradox (English Edition)

この書籍は,以下のような構成になっています.

  • まず,前半にリソース効率性とフロー効率性について解説
  • 次に「リーン」という言葉の生い立ちについて解説した
  • リソース効率性とフロー効率性のバランスをどう取るかの戦略の観点から「リーン」という言葉の正しい意味を明らかにする

壮大なネタバレ: リーンとは

世間には 「リーン」という言葉を冠した書籍がたくさんありますが,簡潔に「リーンとは何か」を書いている書籍はほとんど無かったように思います.

  • 「リーンな UX 開発は小規模な仮説検証を行う」
  • 「リーンなソフトウェア開発では品質を作り込み,ムリ・ムダ・ムラを徹底的に排除する」
  • 「リーンな製造業では在庫を持たない」

このような「リーンな組織はこういう行動をする」という具体的な手法はそれぞれの書籍に書いてあるし,リーンという言葉を知っている人だったら聞いたことがある人も多いと思います.しかし「リーンとは何か?」という問いに,上に挙げた3つのリーンな組織の具体的な手法を説明することの出来るような答えを用意できる人は多くないのではないでしょうか.

This is Lean という書籍の壮大なネタバレになってしまいますが,本書の中の解説では,Lean とは以下の2つの特徴を持つ,ビジネス戦略を実行するための実行戦略です.

  1. リソース効率性とフロー効率性のどちらも最高にある状態を目指すこと
  2. 最初にフロー効率性を高め,その後リソース効率性を高めるという順にアプローチすること

リーンはどのようなビジネス戦略を実現するか (例えば,低価格で利用できる航空便を展開するとか,高価格で至れり尽くせりのコーチングがついてくるスポーツジムを展開するとか,従来より燃費がよくリーズナブルな価格の乗用車を生産するとか) を規定するものではありません.ビジネス戦略によってリーンな実行戦略を実践する具体的な手法は異なるので,例えばリーンな乗用車生産プロセス (TOYOTA Production System とされるもの) の具体的手法のみをソフトウェア開発で模倣しようとすると,期待したとおりの効果を引き出せないことも多いでしょう.その結果として「リーンは車を作るためのもので,ソフトウェア開発には向かない」と結論付けられてしまう問題点も,This is Lean の中では指摘されています.

リソース効率性とフロー効率性のどちらも高い状態 (書籍の中では「Perfect State」と呼ばれ,その中でもそれぞれ100%な効率の状態は「The Star」と呼ばれています) を目指すのはスッと理解できそうですが,なぜリソース効率性でなくフロー効率性を最初に高めるという順になるのか,というのは書籍の前半に解説された2つの効率性の性質や,書籍のサブタイトルにもある「効率性のパラドクス」が大いに関係しているので,詳細が気になる方はぜひ書籍をご一読いただくことをおすすめします.

「This is Lean」レクチャー

で,この書籍の内容に痛く感激した自分は,2日間 (各1時間) をかけて,その内容をチームメンバーにレクチャーしてみました.

f:id:mura-_-mi:20180103191928j:plain

レクチャーを通じて「リソース効率」と「フロー効率」という言葉をチーム内での一種の「常識」としてしまうことを狙いとしました.例えばスプリントごとのレトロスペクティブでチームの改善をするときに方向性がブレなくなったり,プロダクトバックログを書き起こす際の粒度が大きくなることを防ぐことができるのではないかという意図です. *1 まだ明らかな効果が出ているというわけではありませんが,そこそこ良い方向に向かっているのではないかという実感はあります.

また,この書籍を自分が読んでいるときにも感じていたし,チームメンバーも気づいていたのですが,プロセスのフロー効率向上を阻害する要因として書籍の中で取り上げられている「リトルの法則」 「制約理論」「ばらつきへの対処」は,システムやマイクロサービス構成を考えるときにも有用な考え方です.2回のレクチャーを通じて,「開発プロセスを整備することも,システムを作ることも,フロー単位とプロセスを構成するリソースの最適配置を考える問題という意味では同じ」という考えをチームメンバーの間で共有できただけでもやってよかったのかなと思っています.


ということで,この記事を読んで興味が湧いた方はぜひ This is Lean を読んでみていただければ良いのではないかと思います!

*1:私のチームでは,スクラムマスター不在ですが,それ以外の役割やスクラムイベント,生成物はスクラムに則ってシステム開発をしています

Good/Bad と 事実/気持ち から始める「ふりかえり」の手引き

これはなに

世の中の3人~8人程度のソフトウェア / システム開発チームの多くは,俗に言う「アジャイルな開発手法」のプラクティスを実践し,1週間から1ヶ月に1度といった定期的なタイムボックスを設けてチームの開発プロセスや成果物などを対象とした「ふりかえり」をしていると思います。 そして,日本の多くの現場では,「KPT」と呼ばれる Keep (続けること) / Problem (問題になっていること) / Try (次のタイムボックスで新しく試みること) を挙げる方法による振り返りをしているのではないかと思います.
私が開発リードを務めているチームでは,KPT とは違ったフレームワークで週に1度のふりかえりを行っていて,割とうまくいっていると思っているので,それを紹介しようと思います.

KPT は「チーム」のふりかえりには向かない

最近個人的に思っているのは,KPT はチームのふりかえりには,適していないとまでは言わずとも,あまり向いていないのではないかということです.
よくある KPT の進め方は,K / P / T のそれぞれ,つまり「チームが続けるべきこと」「問題になっていること」「次のタイムボックスで試みること」を付箋に書いたり,その内容を順番に発言したりして発表していくかと思います.これをチームの振り返りのフレームワークとして用いると,いくつか不都合なことがあるのではないかと考えています.

透明性を担保するフェーズが無い

アジャイル開発フレームワークの一つであるスクラムは,「検査 (Inspection)」「適応 (Adaption)」「透明性 (Transparency)」 を3つの柱としています.透明性を担保した上で,それまでのチームの生産性や成果物などを検査し,変化や問題に対して適応していく,ということですね.
学習や改善のループを表す 「PDCA」という言葉の「Check」も,改善のループの中で行ったアクションに効果があったのか,計画通りに行動ができているのかを確認するというフェーズです.
これらの考え方に共通しているのは、全ての改善活動は,まず現状の把握から始まる,ということです。

「K/P/T をチームメンバーが思いのままに挙げる」というアクティビティからふりかえりを始めてしまうと,直近のタイムボックスにてチームに起きた事実を振り返るタイミングが無いのが問題だと思っています. 「前回の KPT で出た Try やアクションを振り返ることから始める」というチームもあるかと思いますが,そもそも透明性を担保するべきなのは ふりかえり で出た事項だけでなく,チームの日々の仕事で起こったこと全体ではないでしょうか.

チームのアクションは個人が決めるのではなくチームが決めるべき

「次のタイムボックスに何を続けるか」「次のタイムボックスに何を試してみるか」の主語は,当然ながら「チーム」であるべきです. *1 しかし、チームが主語になる Keep / Problem / Try をチームメンバー各々が挙げるというアクティビティには、いくつか欠点があります。
例えば、あるメンバーにとってやってみたいと思う Keep や Try という具体的なアクションが挙がっても、それが本当にチームで取り組むべきアクションであるかどうかは別なこともあるでしょう。チームで実際に何に取り組むかを決める上で、一度チームメンバーが挙げた項目を否定しなければいけないというのは、ふりかえりに参加するチームメンバーにとっての心理的安全を阻害する要因にもなってしまう可能性があるでしょう。
それに、そもそも対処したい問題に関する視座が揃っていないでアクションの話をしてもファシリテーションコストがかかってしまうのも、限られたふりかえりの時間を無駄にしてしまう要因となってしまいます。

透明性の担保から始める「Good/Bad」と「事実/気持ち」

では私のチームではどうやっているかというと,横軸に「Good/Bad」,縦軸に「事実/気持ち」という2軸でマトリクスを書いて,そこにチームメンバー各自が思いついたことを付箋に書いて貼っていく,というアクティビティから初めています.*2

f:id:mura-_-mi:20171231144820j:plain

上半分の「事実」パートには、そのタイムボックスで起きた事実を書き出します。写真の右上なら「良い事実」や「前向きな事実」を書くことになるので、例えば、「xxx のユーザーストーリーマッピングがうまく行った」とか「平均のレイテンシーが 2 ミリ秒を切った」「差し込みでの作業対応が減った」といったことでしょうか。
下半分の「気持ち」パートには、ネガティブなものだと「不安」とか「愚痴」「辛い」といったもの、ポジティブなものだと「心地よい」とか「皆に知ってほしい」「楽しい」といったような話を書いていきます。例えば左下の象限は「良くない気持ち」「後ろ向きな気持ち」を書く場なので、他のチームはなんで柔軟に対応してくれないのか…」とか「XXX とのシステム接続がうまく行くか不安」といった内容を書いたりします。

自分の挙げる項目がこの4象限のどこに当てはまるのかはメンバー各自の裁量に任せています。

f:id:mura-_-mi:20171231160523j:plain

チームメンバーから付箋が出きったら、順番に付箋の内容を読み上げながら翌タイムボックスで実践するアクションを参加者で検討していくように話を進めていきます。
Good な項目で、翌タイムボックスでの仕事の生産性を上げる施策として取り組めないか、Bad な項目は根本な原因を考えたり、それに対するチームとしての取り組みができないかを考えます。

4象限のどこから始めてどういう順に会話を進めていくかはファシリテーションの裁量だと思うのですが、自分はいつも「Good な事実」から始めて「Bad な事実」「Bad な気持ち」「Good な気持ち」という風に、反時計回りに進めるようにしています。良い事実を確認することでふりかえりの雰囲気を明るくし、後ろ向きな事実や気持ちに向き合いつつ、最後には前向きな気持ちをチームで共有することでポジティブな雰囲気を作ってスプリントを終えるようにしたい、というのが狙いです。

何が良いか

この形でふりかえりをやるようになって3スプリントくらいになるのですが、以下に述べるような良い点があると思って続けています。

事実を洗い出した上でチームで取り組むことを議論させるように持っていきやすい

チームメンバーに書き出してもらうのは、「良い事実」とか「良くない気持ち」といった 現状の確認 であり、具体的なアクションではありません。そのため、前述したような、最初にアクションから考えてしまうことによるファシリテーションコストのムダも減らせます。
また、事実を並べた上でチームで議論してアクションを決定するという流れを作ることで、「チームで決めたこと」という納得感を作った上で翌タイムボックスで改善活動に取り組むという流れを作りやすいのも良いところです。

「気持ち」という欄でチーム内の共感を生みやすい

最初は「Good / Bad」という1つの軸のみで事実を振り返るというかたちで振り返りを進めていたのですが、「クリック率にフォーカス出来るのが楽しい」「xxx をリファクタしておきたい」「テストデータをもう少し拡充させたい」といった、事実とは少々違った話題が多く出るようになり、その中にこそチームの改善のヒントがあるだろう、ということで後から導入したのが「事実と気持ち」という軸でした。
それまでの振り返りでも「気持ち」にまつわる付箋は各参加者が書き出していたのですが、明示的に欄として設けることで、その流れを促進することが出来るようになり、ふりかえりの内容が一段と濃いものになったように思っています。
なにより、ふりかえりの中で「気持ち」を表明することを促すことで、他のチームメンバーもその気持ちに対する共感を表すこともでき、結果としてチームビルディングにも良い影響があるのが良いところです。 ときには愚痴っぽい話がメインになってしまうこともあるかと思いますが、最終的に前向きに改善に臨むためのアクションを議論するようにファシリテーションをするようにさえすれば、ふりかえりの主目的である改善活動をしつつ、チームワークの醸成にも一役買っているのかな、と思っています。

KPT でやっていけないわけじゃない

KPT にしろ、今回紹介した「Good/Bad と 事実/気持ち」にしろ、議論を行う上でのフレームワークファシリテーションを行う上での道具でしかないし、結局はファシリテータに高いファシリテーション能力があったり、チームが充分に自律し自己組織化していれば、どんな形式でふりかえりを行ってもチームや日々の仕事を改善していくことは出来ると思います。
ではフレームワークは何のためにあるかといえば、やらなくてよいことをやらずに済ませるようにすることでムダを省いたり、ファシリテーションスキルが高くない中でもある程度のパフォーマンスを出せるようにするためなのだと思います。
もし普段 KPT でふりかえりを行っていて、どこか上手く行っていないような気がするという場合は、今回紹介した進め方でふりかえりを試してみても良いのではないでしょうか。

じゃぁ KPT ってどういうときに有効なの?

記事の特性上、「KPTってイケてない」と思われてしまうような方もいらっしゃるのではないかな、という危惧が無いわけではないのですが、KPT 自体が悪いわけでもありません。
KPT が向いているのは、個人のコーチングやメンタリングをする文脈ではないでしょうか。なぜなら、トレーナーやメンティーが、自省を踏まえて自分の裁量で各種アクションを決めれば良いからです。トレーニーやメンティーが自分の Keep するべきことや Problem になっていることや Try することを自分なりに考えた上でトレーナーやメンターとの 1 on 1 のミーティングに臨んだり、1 on 1 の中で KPT の各項目を埋めていったりするのは非常に有効だと思います。

*1:個人の Keep や Problem や Try を考えることや、それをチームに共有したり、宣言した上で取り組むことをコミットするのは当然大事ですが、チームの振り返りで行うべきことは、チームが主語になるべきです。

*2:この記事を書きながら、「Good/Bad」と言うより「Positive/Negative」の方がわかりやすいのかなぁ、とか思ったりしています

XP祭り2017 に行ってきた #xpjug

行ってきた.個人的に2週連続のカンファレンス参加.
聴講したセッションについて.

XP祭り2017

基調対談: ワークスタイル改革を実践する2人が働き方の本質を語る

まずは,サイボウズの青野さんとソニックガーデンの倉貫さんの働き方改革についての話. ウォーターフォールの何が辛いか,それぞれの会社のアジャイル文化の話,DevOps 化,有給や昇給や経費の管理,キャリアに対する考え方などの幅広い話題について.アジャイルの考え方は,本当の「働き方改革」とすごい親和性があるなぁという,非常に面白い話だった.
ひたすら Twitter で実況していたのだけど,一番個人的に面白いなと思ったのは,ソニックガーデンの「YWT」の話.

実況ツイートで拾えていない部分もあるので補足を.
キャリア面談として定期的に話す内容を YWT というフレームワークに沿って挙げているということなんだけど,
そこで「これは自分に向いていないことがわかった」とか「すごいしょぼいとわかった」みたいな話を人事考課のような文脈で出してしまうと絶対マイナス評定になるんだけど,
でもソニックガーデンでは個人の人事評価もないので,そこを正直に話せるし,ベテランになると「じゃぁ自分はこれを頑張る」というのをしっかり持てるので良い,という話で非常に興味深かった.

DevOps 時代のプロジェクトマネジメントを考えよう

www.slideshare.net

登壇する内容で「壮大な三部作」という構成を作れるってすごいですよね.
大きい SI の企業の中でピラミッド型チームをフラットなチームにする途中の段階として,ピラミッドの最下層に球拾いを出来るリーダーシップを設けるっていうのは斬新というか,良い過渡期の設け方だなと思った.
色んな要素で「大構築時代」と「DevOps時代」を対比している点は非常に整理されていて腑に落ちるセッションでした.

全ては Fearless Change から学んだ,開発組織の変革を支えた実践的アプローチ

speakerdeck.com

初めて @kakakakakku さんこと よっしー さんのセッションを聴講したのですが,25分という短い時間にこれでもかと詰め込んだ内容で,本当にエネルギーの溢れる方でした.
「達人」のサポートを得ることでチームのポテンシャルというか能力を限界突破させるというアプローチはとても効率良いな,と思ったし,せっかく幅広い達人を抱える会社なのだから活用できるようにならないとな,と思った.

xUTP から学ぶ記述性の高いユニットテスト

speakerdeck.com

Agile2017 @ Orlando でもお見かけした高橋陽太郎さんのセッション. given-when-then などの構造を紹介しながら,メンテナビリティの高いテストコードを書く技術について.
個人的には,一番最初のスライドに出てきた,メンテナンスコストと享受するメリットのグラフが良かったですね.
ScalaTest のこういう事例とかセオリーを誰か出してくれないかなぁ.

シンプルデザインについて

『Real World HTTP』の著者である渋川よしきさんの公演は,XP の 1st edition で原則の中にあった「シンプルデザイン」について.
スライド見当たらないようですが.
シンプルデザインは,ユーザーや開発者や出資者などのそれぞれの視点で,同じデザインでもシンプルかどうかは違うので,そのトレードオフをしっかり選択することや,シンプルなデザインを表すパターン・ランゲージを考えている,という話.
パターンというと GoFデザインパターンをみんな真っ先に思い浮かべるけれど,パタン・ランゲージはそれを組み合わせて会話をしなければいけないので,そういう意味では逆演算をたくさん紹介している『リファクタリング』のカタログのほうがパタン・ランゲージとしては完成度が高い,という渋川さんの考えが非常に興味深かった.

リソース効率性とフロー効率性について

www.slideshare.net

個人的には今回のベストトークでした.ここまでプロダクト開発の「効率」って突き詰めて整理できるんだ,という目からうろこ.
持てるリソースの稼働率を 100% に近づけるリソース効率性と,機能や価値が提供されるまでのリードタイムを最短にするフロー効率性はトレードオフではなく,どちらも両立できること,その状態に持っていくためにはまずフローの効率性を高めてからリソースの効率性を高めましょう,という話.
詳細は触れられていなかったけど,高橋さんがフロー効率性を担保しようとしたつもりがリソース効率性を高めようとしてしまったという話が非常に興味深かった.そのために,リソース効率性を高めなければならなくなるような制約 (例えばタイトな納期とか) をいかに,交渉だけでなく技術的なアプローチも使いながらコントロールするかが大事.

チームをワークさせるために最も大事なコミュニケーション意識していますか?

www.slideshare.net

職場のプロダクト外活動でなにかとお世話になっている吉田浩一さんのセッション.
普段から組織内コミュニケーションとかリーダーシップとかについてはめちゃめちゃよく話しているんですけど,そのときによく話題に上がる問題意識とかに溢れたトークでした.
特に「自分がいなくなっても回るような自立 / 自律的なチームを目指す」という点は,自分もよく意識していますが,このスライドにあったような権限委譲の段階みたいなのを強く意識するのは大事ですよね. 

おまけ & まとめ

初参加ということで,協賛出版社からの見本書籍をいただきました.ありがとうございます!
来年はぜひとも,小さい枠でも登壇したいな!

Scala関西Summit 2017 に行ってきた

気がついたら全然写真撮ってなかったんだけど,Scala関西Summit 2017 に行ってきた.
東京のフツーの Scala エンジニアだったら ScalaMatsuri があるからわざわざ関西まで行くこともないんじゃない?というのは自分も思ってるのだけど,
今年の2月にあった ScalaMatsuri の頃,僕は Java エンジニアだったし,今回の Scala関西Summit のタイムテーブルを見たら自分の中でホットな話題も多かったので,思い切って行ってみた.結構行ってよかったと思っている.

印象に残ったセッションについて書いておく.

Non-Functional Programming in Scala (@takezoen さん)

www.slideshare.net

竹添さんによる,「Functional じゃない感じで敷居を低くする Scala の使い方」についてのセッション.
Scala は手続き的な書き方もファンクショナルな書き方もできるがゆえに,チームが成熟するにつれて,プロダクトのコードはだんだん複雑になっていって新規メンバーにとってハードルの高いものになっちゃうよね,という話は本当にそうだなぁ,という感想.
ただ, var や while を許す,というのは個人的には関数型なのかどうかよりも前にコーディングが良くないんじゃないかなと思っていて,そういうのはちゃんとコードレビューで潰すべきなんじゃないかなぁ,という気も.
もちろん,そこも含めてチームの成熟度とかだと思いますけどね.

実践 ScalaでDDD (@crossroad0201 さん)

speakerdeck.com

Scala で DDD なプロダクトを実装するには?という話.
case class の copy メソッドをラップしてエンティティの属性を変更する操作に名前をつけたり,
アプリケーションサービスの処理で EitherTryOption を返す処理をメソッド内で def で定義して for { ... } yield { ... } で並べて書くことでユースケース仕様書ぽく書いたり,
エンティティが特定の条件下でのみ特定の振る舞いをすることを Role Object という implicit class で表現したりとか,
Scala の機能を DDD を実践するためにどう使うかというのがイチイチ絶妙でかっこよかった.いろいろ参考にして自分も実践してみたい.

Reladomo in Scala (@itohiro73 さん / @seratch さん)

www.slideshare.net

ゴールドマン・サックスが昨年 OSS 公開した Reladomo という Java の O/R Mapper を Scala で利用するためのライブラリを開発したよ,という話.
MicrosoftVSCode を,トークセッションの最中に github で public に公開した時のように,トークの最後に瀬良さんが push することで公開となりました.

github.com

自分的には JJUG CCC などでの Reladomo の紹介を見て良いなぁ使いたいなぁと思っていて,仕事でちょうどウェブ UI アプリケーションを新規に作るので O/R どうしようと考えていたところなので,積極的に検討したいなと思った.
ただ,現状の reladomo-scala の機能ではエンティティを case class で生成して target 下の src_managed に吐き出しているので,独自にドメインロジックを表す API を書いたりという拡張ができないようで,ここは implicit class とかで生やすっきゃないのかなあ?とか色々考えている.

スライドの中や,公開されたサンプルコードの中で NewPerson というクラスが出てきて,これなんだろうなと思ったけど,DB 上の Auto Increment な id を付与する前の id を持たないインスタンス用のクラスだよ,というのを懇親会で瀬良さんに解説していただいた.セッションでは端折られている説明だったので助かった.
瀬良さんが開発している Skinny-ORM ではレコードの insert をする際に case class を Dao 的な API に渡すという方法がなくて, createWithAttributes('attribute -> value, 'attribute -> value, ...) という書き方がメインなんだけど,これも同様の理由で id のない状態のエンティティを扱うときに case class を新規に作るとしたら id = null とするのか?というのに対する答えなんだそうで.
Skinny-ORM だとエンティティ定義は case class を直接書かなきゃいけないけど, Reladomo の場合は XML ファイルを書いてコンパイルに通すと case class が生成されるという形なので, Person クラスの他に NewPerson を生成することが出来る,という話でした.

Property Based Testing でドメインロジックをテストする (@gakuzzzz さん)

Property Based Testing でドメインロジックをテストする

Property Based Tesは,なんとなくウェブ上での解説記事を読んで,その効能があんまりイメージできなくて真剣に考えたことが無かったけど,上手く使うと良さそうだなと思えたセッションでした.
最後に質疑応答で伺ってみたけれど, whenever(...) で生成されたフィクスチャをテスト実行のタイミングで絞ろうとすると whenever 条件の中に実装と同じことを書いてしまってトートロジーなテストになっちゃわないかな,というのは思ったので,上手く使い方を考えたいなと思った.その中で,がくぞさんのおっしゃっていた「普遍的な条件を見つけることにこだわらない (特定条件にしぼってテストする)」「視点を変えて満たすべき性質を見つけ出す」というのは非常に参考になった.

懇親会

#mm_beer #scala_ks #kirin 懇親会ー!

ぼっちでの参加だったのだけど勇気を持って懇親会に参加したら,色んな人とお話できて非常に有意義だった.
すごいプライベートな話だけど,大学の同級生がいたのはびっくりした.いかんせん文系しかない大学で,特に自分たちのいた商学部は,会計士になるか,商社とか金融機関でキャリアを積む人が多いので.
自分の印象に残ったセッションのスピーカーの方とちょっと踏み込んだところまで話せたりするし,こういう機会は尻込んじゃいけないな,と改めて思った次第.

あと,会場のさくらインターネット株式会社様のオフィスがめちゃめちゃオシャレだった!びっくり.

翌日: 大阪食い倒れ

翌日は新幹線までちょっと時間があり,せっかく大阪に来たので,たこ焼きと串かつ.大阪駅からすぐそこだし,ちょっと混んでいても回転が早い!! もちろん美味しい!おすすめです.

retty.me

retty.me

エンジニアの一番の基礎体力はタイピングスピードだという話

転職して8ヶ月ほどになるかと思うが,今年も新卒のメンターになる運びとなった.
今年も新卒のメンタリングをして改めて思うのは, エンジニアにとっていくつかある基礎体力のうち,一番最初に伸ばせるのに誰も本気で取り組まないのがタイピングスピードだということ だ.

日本のスポーツや武道の世界に「心技体」という言葉がある.競技を行う上で,精神力 (心),技術, 体力の3つが大事になるという話だが,このうち入門者に一番最初に求められるのは「体」だと思う.
技術を磨くには圧倒的な鍛錬の時間が必要だが,この鍛錬を積むためには体力がなければいけない.*1

かつて,横浜ベイスターズ石井琢朗という選手がいた.彼が引退するにあたって,とあるプロ野球 OB によって書かれた 『66番だった』という記事が個人的には非常に印象的だ. ameblo.jp 石井琢朗はもともと投手として横浜大洋ホエールズに入団したのだが,後にシーズンオフの秋に野手転向が決まると,そこから朝も夕方も夜間も特打,特守と嵐のような練習量で,翌年の終わりには三塁手の定位置を獲得していた,という話.

翻ってエンジニアはどうかというと,やはり誰かのコードを読んで,自分でコードを書くことが一番の練習であり実戦である.同じ1時間*2で,100 行しかコードを書けない人間と,500行書ける人間では,間違いなく後者の方が圧倒的に成長する.

こういう話をすると,「でも500行に渡って中身のないコードを書くことに意味があるのか」とイチャモンをつける気持ちも芽生えるが,ここで言いたいのは500行の中身ではなく,どれだけのサイクルでどれだけの量のフィードバックサイクルを回せるかという話である.タイピングスピートがあるエンジニアは,自分のアウトプットに対するフィードバックを受けた後,それをすぐに解決することが出来る.すると次のフィードバックがやってくるから,また次の成長機会がやってくる.
そう考えると,たとえクソコードでも,間違いなく1時間に500行書けるエンジニアの方が成長するに決まっている.

キーボードという入力デバイスを用いて何かを書く作業の行う上での究極の理想は,「思考が寸分の遅れもなくエディタ上に実現すること」だ.そうすれば自分の書いたコードをコンパイラに食わせること,テストコードに通すこと,環境にデプロイすることまでのオーバーヘッドとなる時間も無くなる.将来,音声入力の精度が高くなれば僕は音声入力を使うだろうし,脳波を探知して入力してくれるデバイスがあれば間違いなくそれを使うだろう.*3

そのためだったらキーボード上でホームポジションから指を離さない指運だって鍛錬すべきだし,少しでもホームポジションから手のひらを動かさずにタイプ出来る英字キーボードを好むべきだし,「思考の速さで編集する」ことを目的に,自らの使うツールの効率的な使い方に鍛錬するべきだと思う.

ちなみに,宗派戦争に巻き込まれるのはごめんだから深くは書かないが,自分のこれまでのエンジニアとしてのキャリアで効果があったのは,Vim のコマンドにある程度精通したことだと思う.一通りのヤンクの操作とテキストオブジェクトを使いこなすことで,間違いなく生産性は 2.5 倍以上は上昇したと思う.

*1:心と体はどちらが先か,という問題は話題になりがちだ.こういうときに話題になる心というのは,英語で言う “attitude” というか,何を優先ごとと考えるかというメンタリティのようなものと,圧倒的な劣勢でも折れない強さのようなものの2つがあるように思える.前者は「体」を育てるのと並行してメンターが意識して躾けなければならないが,後者は「体」と「技」が身についた上での実践の中で身につくもののように思える

*2:同じ言語環境,同じ題材だとして

*3:勿論,リーズナブルな値段で手に入るところまでコモディティ化すれば,だけど

Git / GitHub 初級者をメンタリングするときに考えていること

Git や GitHub を全く触ったことがない人や,使ったことはあるけど複数人でのチーム開発で読みやすさやレビューしやすさを意識した運用をしたことがないエンジニアや,エンジニアの卵のメンターになることが多いので,自分なりのポリシーをメモ程度に列挙してみる.
もちろん,プロジェクトでポリシーが決まっていればそれに従うべきだが,自分が今いるチームや,これまで所属してきた組織では「なんとなく」でしか決まってないので,そんなチームでメンタリングするときは,「どんな現場に行ってもある程度はしっかりできる素地」みたいなのを意識している.
半分くらい http://qiita.com/meganemura/items/8a034e2065b299135c87 の焼き直しになってしまっているけど,気にしない.

ポリシーに「必須度」を付けているが,おおよそ以下のような感じ.メンタリングする時は,まず必須度 A が出来るように,少し口うるさくでも言う.本人が,自ずと他のエンジニアとのコラボレーションを気にかけるようになったら,B や C の内容をヒントとして与えていくイメージ.

  • 必須度 A : 必ず守る
  • 必須度 B : 難しいケースもあるけど,守れるなら守る
  • 必須度C : やってあると嬉しい

コミットメッセージのフォーマット 編

1行目は,行った変更のサマリーを 100 文字以内で書く.(必須度: A)

100 文字というのはおおよそだけど, GitHub 上で 120 文字?あたりで折り返されちゃうみたいなので,長くならないように意識している.
PR 画面のコミット一覧で見栄えがすればよれでよし.

2行目は空行,3行目以降に必要であれば詳細を書く (必須度: C)

2行目空行は異論ないと思う.
ちゃんとしたプロジェクトだと,3行目以降に書くことのフォーマットが決まってたりすると思うけど,ここはメンバーの善意に任せている感じです.
でも,個人的には,例えば不具合の改修で,修正した場所と,実際に起きた不具合の根本原因の箇所が遠い場合などは,後からコミットログを読んだときにどういう問題に対処する修正なのかが分かるように,意図を説明するようにメッセージを書いたりしています.

内容のないコミットメッセージを書かない (必須度: A)

「コンフリクトを解消」とか「修正」とかっていうコミットログをやめましょう,という話です.初歩的だけど,技術ではなく姿勢の問題なので,1行の変更でも,何が問題で,何が間違っていたので修正したかを説明するようにします.
コードレビュー後の「指摘事項修正」も,レビューを受けてどういう問題を直したのか,というのが分かるようにしたいですね.

コンフリクトの解消に関しては,「それを言うのは初心者には酷じゃ…??」と思う方が多いと思います.自分もそう思ってて,他のエンジニアの作業と大きくバッティングするようなタスクを渡さないとか,大きすぎて長く時間のかかるようなタスクはそもそも振らない,というメンターの問題だと考えています.メンティーの状況に応じて, rebase を教えるチャンス,とも捉えることも出来ると思います.

句点やピリオドは使わず,英語なら命令形,日本語なら「xx した」と書く (必須度: A)

自分のコミットログを見返すと,守ってないケースもあるけど…
英語のコミットログだと,「主語を使わず現在形の動詞から始める」「ピリオドで終わらない」というのがよくある規約です.英語の場合はこれを守るのですが,
日本語の場合だと,やはり主語は使わず,「xxx をした」で終えるようにしています.これは「xx する」でも「xx しました」でも良いと思いますが,プロジェクト内で統一されているべきですね.

ソースコード生成のコマンドがある場合はコミットメッセージに含める (必須度: C)

これはできればで良いのですが,例えば Railsbundle install ...rails generate scaffold ... は,可能であればコミットログに含められると,後からそのコマンド自体にも問題は無かったのかなども振り返ることができます.

コミットの作り方

自動生成や Initial Commit 以外で巨大コミットを作らない (必須度: A)

どれくらい,という指標はないのだけど,「ついでに xx も直していっしょにこのコミットに入れました!」みたいなことをやっているのを見つけたときは,早めに指摘をするようにしています.

どのコミットタイミングでも,ビルドやテストはすべて通るようにする (必須度: B)

可能であれば,ですが.

アプリケーションやシステムの挙動を変えるコミットと,挙動を変えないコミットを分ける (必須度: B)

リファクタや不要な変数や文の削除などは,それだけでコミットを作るようにします.レビューの対象になる主変更はそれだけでコミットをするようにすると,レビューがし易いですね.
例えば,新しい API の追加をする際に,既存のコードやテストコードをリファクタして拡張性を担保して,新しい API を追加するという手順を取る場合,リファクタのコミットと API の追加のコミットを別にします.
このように作業するように心がけると,未使用変数の削除などのコミットは眺めるのに2秒もかけないで済むし,最初のリファクタに問題点はないのかの観点でもレビューされやすいし,追加した API が妥当かのレビューに注力し易いです.

新しく追加した class や API に対するテストは,同じコミットにする (必須度: B)

例えば 「xxx クラスを追加した」というコミットの後に 「xxx クラスのテストを追加した」というコミットをつけるのではなく,この2つは一つのコミットにすべきです.
ひとつのコミット内容を見たときに,追加した API やクラスと,その使い方を示したり正しさを保証しているコードは一緒になっているべきだと考えるからです.

ブランチ / PR 運用

PR は小さく.

これは,「どれくらい」というのが言えないので必須度が付けられないのですが,やはりなるべく1つの PR は小さくある方がレビューしやすいです.
利用している言語によっても違うのですが,普段の自分は Scala プロジェクトで 300 行を超える変更が生じると頭を下げながらレビュー依頼を出し,700 行を超える PR はほとんど作っていない…はず…
Java だとボイラープレートが多いので,1,000 行超えるケースもあるかな,という感じです.

マージ先ブランチ上に rebase してから PR のレビュー依頼を出す (必須度: B)

大きい修正をするときにはどうしても競合は起きがちですが,先にあった「意味のないコミットログを作らない」という観点からも,更新されたマージ先のブランチに rebase したものをレビューに出すようにします.
先にも振れましたが,メンティーに仕事を振るときのメンターの気の遣いどころでもあります.


人によっても違うと思うし,書き忘れているところもあると思いますが,僕は上記のような感じでやっています.
皆さんはどうですか?