「フロー効率」をチームの常識にする - 『This is Lean』の内容をチームメンバーにレクチャーした話
フロー効率性と「This is Lean」
あくまで自分の観測範囲での話ではあるのですが，2017年，ソフトウェアやITシステムの開発プロセス関連に興味がある人たちの間でホットだったキーワードのひとつが「リソース効率性とフロー効率性」だったと思います．
私自身，それまで「リソース効率性とフロー効率性」という概念は知らなかったのですが，9月にあった XP 祭り2017 での発表を拝見してから，自分の中では一気に火がつきました． 具体的に「リソース効率性とフロー効率性とは何か」という話は，その時の発表者である id:i2key さんの発表資料やブログのほうが詳しいと思うので，興味のある方はご覧いただければと思います．
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)
- 作者: Niklas Modig,Pär Åhlström
- 出版社/メーカー: Rheologica Publishing
- 発売日: 2014/04/27
- メディア: Kindle版
- この商品を含むブログを見る
この書籍は，以下のような構成になっています．
- まず，前半にリソース効率性とフロー効率性について解説
- 次に「リーン」という言葉の生い立ちについて解説した
- リソース効率性とフロー効率性のバランスをどう取るかの戦略の観点から「リーン」という言葉の正しい意味を明らかにする
壮大なネタバレ: リーンとは
世間には 「リーン」という言葉を冠した書籍がたくさんありますが，簡潔に「リーンとは何か」を書いている書籍はほとんど無かったように思います．
- 「リーンな UX 開発は小規模な仮説検証を行う」
- 「リーンなソフトウェア開発では品質を作り込み，ムリ・ムダ・ムラを徹底的に排除する」
- 「リーンな製造業では在庫を持たない」
このような「リーンな組織はこういう行動をする」という具体的な手法はそれぞれの書籍に書いてあるし，リーンという言葉を知っている人だったら聞いたことがある人も多いと思います．しかし「リーンとは何か？」という問いに，上に挙げた3つのリーンな組織の具体的な手法を説明することの出来るような答えを用意できる人は多くないのではないでしょうか．
This is Lean という書籍の壮大なネタバレになってしまいますが，本書の中の解説では，Lean とは以下の2つの特徴を持つ，ビジネス戦略を実行するための実行戦略です．
- リソース効率性とフロー効率性のどちらも最高にある状態を目指すこと
- 最初にフロー効率性を高め，その後リソース効率性を高めるという順にアプローチすること
リーンはどのようなビジネス戦略を実現するか (例えば，低価格で利用できる航空便を展開するとか，高価格で至れり尽くせりのコーチングがついてくるスポーツジムを展開するとか，従来より燃費がよくリーズナブルな価格の乗用車を生産するとか) を規定するものではありません．ビジネス戦略によってリーンな実行戦略を実践する具体的な手法は異なるので，例えばリーンな乗用車生産プロセス (TOYOTA Production System とされるもの) の具体的手法のみをソフトウェア開発で模倣しようとすると，期待したとおりの効果を引き出せないことも多いでしょう．その結果として「リーンは車を作るためのもので，ソフトウェア開発には向かない」と結論付けられてしまう問題点も，This is Lean の中では指摘されています．
リソース効率性とフロー効率性のどちらも高い状態 (書籍の中では「Perfect State」と呼ばれ，その中でもそれぞれ100%な効率の状態は「The Star」と呼ばれています) を目指すのはスッと理解できそうですが，なぜリソース効率性でなくフロー効率性を最初に高めるという順になるのか，というのは書籍の前半に解説された2つの効率性の性質や，書籍のサブタイトルにもある「効率性のパラドクス」が大いに関係しているので，詳細が気になる方はぜひ書籍をご一読いただくことをおすすめします．
「This is Lean」レクチャー
で，この書籍の内容に痛く感激した自分は，2日間 (各1時間) をかけて，その内容をチームメンバーにレクチャーしてみました．
レクチャーを通じて「リソース効率」と「フロー効率」という言葉をチーム内での一種の「常識」としてしまうことを狙いとしました．例えばスプリントごとのレトロスペクティブでチームの改善をするときに方向性がブレなくなったり，プロダクトバックログを書き起こす際の粒度が大きくなることを防ぐことができるのではないかという意図です． *1 まだ明らかな効果が出ているというわけではありませんが，そこそこ良い方向に向かっているのではないかという実感はあります．
また，この書籍を自分が読んでいるときにも感じていたし，チームメンバーも気づいていたのですが，プロセスのフロー効率向上を阻害する要因として書籍の中で取り上げられている「リトルの法則」 「制約理論」「ばらつきへの対処」は，システムやマイクロサービス構成を考えるときにも有用な考え方です．2回のレクチャーを通じて，「開発プロセスを整備することも，システムを作ることも，フロー単位とプロセスを構成するリソースの最適配置を考える問題という意味では同じ」という考えをチームメンバーの間で共有できただけでもやってよかったのかなと思っています．
ということで，この記事を読んで興味が湧いた方はぜひ This is Lean を読んでみていただければ良いのではないかと思います！
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
上半分の「事実」パートには、そのタイムボックスで起きた事実を書き出します。写真の右上なら「良い事実」や「前向きな事実」を書くことになるので、例えば、「xxx のユーザーストーリーマッピングがうまく行った」とか「平均のレイテンシーが 2 ミリ秒を切った」「差し込みでの作業対応が減った」といったことでしょうか。
下半分の「気持ち」パートには、ネガティブなものだと「不安」とか「愚痴」「辛い」といったもの、ポジティブなものだと「心地よい」とか「皆に知ってほしい」「楽しい」といったような話を書いていきます。例えば左下の象限は「良くない気持ち」「後ろ向きな気持ち」を書く場なので、他のチームはなんで柔軟に対応してくれないのか…」とか「XXX とのシステム接続がうまく行くか不安」といった内容を書いたりします。
自分の挙げる項目がこの4象限のどこに当てはまるのかはメンバー各自の裁量に任せています。
チームメンバーから付箋が出きったら、順番に付箋の内容を読み上げながら翌タイムボックスで実践するアクションを参加者で検討していくように話を進めていきます。
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 の各項目を埋めていったりするのは非常に有効だと思います。
XP祭り2017 に行ってきた #xpjug
行ってきた．個人的に2週連続のカンファレンス参加．
聴講したセッションについて．
基調対談: ワークスタイル改革を実践する2人が働き方の本質を語る
まずは，サイボウズの青野さんとソニックガーデンの倉貫さんの働き方改革についての話．
ウォーターフォールの何が辛いか，それぞれの会社のアジャイル文化の話，DevOps 化，有給や昇給や経費の管理，キャリアに対する考え方などの幅広い話題について．アジャイルの考え方は，本当の「働き方改革」とすごい親和性があるなぁという，非常に面白い話だった．
ひたすら Twitter で実況していたのだけど，一番個人的に面白いなと思ったのは，ソニックガーデンの「YWT」の話．
倉貫「YWT やったこと，わかったこと，次にやることを面談する．#xpjug #xp祭り
— むらみん (@Mura_Mi) 2017年9月16日
倉貫「YWT を続けるとみんなか従業員が考えるようになる．社会人になるまでは進路相談という形で自分の人生を考える節目があったが，社会人はその進路相談がなくなる．ソニックガーデンでは YWT を進路相談と呼んでいる」#xpjug #xp祭り
— むらみん (@Mura_Mi) 2017年9月16日
倉貫「YWT を続けると，若いことベテランで内容が変わってくる．若い子のYはきらきらしたこと．ベテランは「自分には向いてないとわかった」みたいな話になる．でも普通の会社で，できなかったとを話したらダメ．#xpjug #xp祭り
— むらみん (@Mura_Mi) 2017年9月16日
YWT進路相談の続き
— むらみん (@Mura_Mi) 2017年9月16日
倉貫「ベテランは，できないことをわかったと言えるし，それを理解した上で，自分の得意なところに強くコミットするようになる．歳とったら弱みを見せる，全部やらない」#xpjug #xp祭り
実況ツイートで拾えていない部分もあるので補足を．
キャリア面談として定期的に話す内容を YWT というフレームワークに沿って挙げているということなんだけど，
そこで「これは自分に向いていないことがわかった」とか「すごいしょぼいとわかった」みたいな話を人事考課のような文脈で出してしまうと絶対マイナス評定になるんだけど，
でもソニックガーデンでは個人の人事評価もないので，そこを正直に話せるし，ベテランになると「じゃぁ自分はこれを頑張る」というのをしっかり持てるので良い，という話で非常に興味深かった．
DevOps 時代のプロジェクトマネジメントを考えよう
登壇する内容で「壮大な三部作」という構成を作れるってすごいですよね．
大きい SI の企業の中でピラミッド型チームをフラットなチームにする途中の段階として，ピラミッドの最下層に球拾いを出来るリーダーシップを設けるっていうのは斬新というか，良い過渡期の設け方だなと思った．
色んな要素で「大構築時代」と「DevOps時代」を対比している点は非常に整理されていて腑に落ちるセッションでした．
全ては Fearless Change から学んだ，開発組織の変革を支えた実践的アプローチ
初めて @kakakakakku さんこと よっしー さんのセッションを聴講したのですが，25分という短い時間にこれでもかと詰め込んだ内容で，本当にエネルギーの溢れる方でした．
「達人」のサポートを得ることでチームのポテンシャルというか能力を限界突破させるというアプローチはとても効率良いな，と思ったし，せっかく幅広い達人を抱える会社なのだから活用できるようにならないとな，と思った．
xUTP から学ぶ記述性の高いユニットテスト
Agile2017 @ Orlando でもお見かけした高橋陽太郎さんのセッション．
given-when-then などの構造を紹介しながら，メンテナビリティの高いテストコードを書く技術について．
個人的には，一番最初のスライドに出てきた，メンテナンスコストと享受するメリットのグラフが良かったですね．
ScalaTest のこういう事例とかセオリーを誰か出してくれないかなぁ.
シンプルデザインについて
『Real World HTTP』の著者である渋川よしきさんの公演は，XP の 1st edition で原則の中にあった「シンプルデザイン」について．
スライド見当たらないようですが．
シンプルデザインは，ユーザーや開発者や出資者などのそれぞれの視点で，同じデザインでもシンプルかどうかは違うので，そのトレードオフをしっかり選択することや，シンプルなデザインを表すパターン・ランゲージを考えている，という話．
パターンというと GoF のデザインパターンをみんな真っ先に思い浮かべるけれど，パタン・ランゲージはそれを組み合わせて会話をしなければいけないので，そういう意味では逆演算をたくさん紹介している『リファクタリング』のカタログのほうがパタン・ランゲージとしては完成度が高い，という渋川さんの考えが非常に興味深かった．
リソース効率性とフロー効率性について
www.slideshare.net
個人的には今回のベストトークでした．ここまでプロダクト開発の「効率」って突き詰めて整理できるんだ，という目からうろこ．
持てるリソースの稼働率を 100％ に近づけるリソース効率性と，機能や価値が提供されるまでのリードタイムを最短にするフロー効率性はトレードオフではなく，どちらも両立できること，その状態に持っていくためにはまずフローの効率性を高めてからリソースの効率性を高めましょう，という話．
詳細は触れられていなかったけど，高橋さんがフロー効率性を担保しようとしたつもりがリソース効率性を高めようとしてしまったという話が非常に興味深かった．そのために，リソース効率性を高めなければならなくなるような制約 (例えばタイトな納期とか) をいかに，交渉だけでなく技術的なアプローチも使いながらコントロールするかが大事．
チームをワークさせるために最も大事なコミュニケーション意識していますか？
www.slideshare.net
職場のプロダクト外活動でなにかとお世話になっている吉田浩一さんのセッション．
普段から組織内コミュニケーションとかリーダーシップとかについてはめちゃめちゃよく話しているんですけど，そのときによく話題に上がる問題意識とかに溢れたトークでした．
特に「自分がいなくなっても回るような自立 / 自律的なチームを目指す」という点は，自分もよく意識していますが，このスライドにあったような権限委譲の段階みたいなのを強く意識するのは大事ですよね．
おまけ & まとめ
感謝！ #xpjug #xp祭り pic.twitter.com/JGb4HXS7JT
— むらみん (@Mura_Mi) 2017年9月16日
初参加ということで，協賛出版社からの見本書籍をいただきました．ありがとうございます！
来年はぜひとも，小さい枠でも登壇したいな！
Scala関西Summit 2017 に行ってきた
来たでー。 #scala_ks pic.twitter.com/bjbtHD0hKc
— むらみん (@Mura_Mi) 2017年9月9日
気がついたら全然写真撮ってなかったんだけど，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 さん)
Scala で DDD なプロダクトを実装するには？という話．
case class の copy メソッドをラップしてエンティティの属性を変更する操作に名前をつけたり，
アプリケーションサービスの処理で Either や Try や Option を返す処理をメソッド内で def で定義して for { ... } yield { ... } で並べて書くことでユースケース仕様書ぽく書いたり，
エンティティが特定の条件下でのみ特定の振る舞いをすることを Role Object という implicit class で表現したりとか，
Scala の機能を DDD を実践するためにどう使うかというのがイチイチ絶妙でかっこよかった．いろいろ参考にして自分も実践してみたい．
Reladomo in Scala (@itohiro73 さん / @seratch さん)
www.slideshare.net
ゴールドマン・サックスが昨年 OSS 公開した Reladomo という Java の O/R Mapper を Scala で利用するためのライブラリを開発したよ，という話．
Microsoft が VSCode を，トークセッションの最中に github で public に公開した時のように，トークの最後に瀬良さんが push することで公開となりました．
自分的には 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 条件の中に実装と同じことを書いてしまってトートロジーなテストになっちゃわないかな，というのは思ったので，上手く使い方を考えたいなと思った．その中で，がくぞさんのおっしゃっていた「普遍的な条件を見つけることにこだわらない (特定条件にしぼってテストする)」「視点を変えて満たすべき性質を見つけ出す」というのは非常に参考になった．
最初のセッションで「null 書くとがくぞさんに消される」というパワーある言葉を聞いてたから怖い人かと思ったけど，すごい朗らかな方だった #scala_ks #scala_ks_main
— むらみん (@Mura_Mi) September 9, 2017
懇親会
#mm_beer #scala_ks #kirin 懇親会ー！
ぼっちでの参加だったのだけど勇気を持って懇親会に参加したら，色んな人とお話できて非常に有意義だった．
すごいプライベートな話だけど，大学の同級生がいたのはびっくりした．いかんせん文系しかない大学で，特に自分たちのいた商学部は，会計士になるか，商社とか金融機関でキャリアを積む人が多いので．
自分の印象に残ったセッションのスピーカーの方とちょっと踏み込んだところまで話せたりするし，こういう機会は尻込んじゃいけないな，と改めて思った次第．
あと，会場のさくらインターネット株式会社様のオフィスがめちゃめちゃオシャレだった！びっくり．
翌日: 大阪食い倒れ
翌日は新幹線までちょっと時間があり，せっかく大阪に来たので，たこ焼きと串かつ．大阪駅からすぐそこだし，ちょっと混んでいても回転が早い!! もちろん美味しい！おすすめです．
エンジニアの一番の基礎体力はタイピングスピードだという話
転職して8ヶ月ほどになるかと思うが，今年も新卒のメンターになる運びとなった．
今年も新卒のメンタリングをして改めて思うのは， エンジニアにとっていくつかある基礎体力のうち，一番最初に伸ばせるのに誰も本気で取り組まないのがタイピングスピードだということ だ．
日本のスポーツや武道の世界に「心技体」という言葉がある．競技を行う上で，精神力 (心)，技術, 体力の3つが大事になるという話だが，このうち入門者に一番最初に求められるのは「体」だと思う．
技術を磨くには圧倒的な鍛錬の時間が必要だが，この鍛錬を積むためには体力がなければいけない．*1
かつて，横浜ベイスターズに石井琢朗という選手がいた．彼が引退するにあたって，とあるプロ野球 OB によって書かれた 『66番だった』という記事が個人的には非常に印象的だ． ameblo.jp 石井琢朗はもともと投手として横浜大洋ホエールズに入団したのだが，後にシーズンオフの秋に野手転向が決まると，そこから朝も夕方も夜間も特打，特守と嵐のような練習量で，翌年の終わりには三塁手の定位置を獲得していた，という話．
翻ってエンジニアはどうかというと，やはり誰かのコードを読んで，自分でコードを書くことが一番の練習であり実戦である．同じ1時間*2で，100 行しかコードを書けない人間と，500行書ける人間では，間違いなく後者の方が圧倒的に成長する．
こういう話をすると，「でも500行に渡って中身のないコードを書くことに意味があるのか」とイチャモンをつける気持ちも芽生えるが，ここで言いたいのは500行の中身ではなく，どれだけのサイクルでどれだけの量のフィードバックサイクルを回せるかという話である．タイピングスピートがあるエンジニアは，自分のアウトプットに対するフィードバックを受けた後，それをすぐに解決することが出来る．すると次のフィードバックがやってくるから，また次の成長機会がやってくる．
そう考えると，たとえクソコードでも，間違いなく1時間に500行書けるエンジニアの方が成長するに決まっている．
キーボードという入力デバイスを用いて何かを書く作業の行う上での究極の理想は，「思考が寸分の遅れもなくエディタ上に実現すること」だ．そうすれば自分の書いたコードをコンパイラに食わせること，テストコードに通すこと，環境にデプロイすることまでのオーバーヘッドとなる時間も無くなる．将来，音声入力の精度が高くなれば僕は音声入力を使うだろうし，脳波を探知して入力してくれるデバイスがあれば間違いなくそれを使うだろう．*3
そのためだったらキーボード上でホームポジションから指を離さない指運だって鍛錬すべきだし，少しでもホームポジションから手のひらを動かさずにタイプ出来る英字キーボードを好むべきだし，「思考の速さで編集する」ことを目的に，自らの使うツールの効率的な使い方に鍛錬するべきだと思う．
ちなみに，宗派戦争に巻き込まれるのはごめんだから深くは書かないが，自分のこれまでのエンジニアとしてのキャリアで効果があったのは，Vim のコマンドにある程度精通したことだと思う．一通りのヤンクの操作とテキストオブジェクトを使いこなすことで，間違いなく生産性は 2.5 倍以上は上昇したと思う．
- 作者: ＤｒｅｗＮｅｉｌ,新丈径
- 出版社/メーカー: KADOKAWA / アスキー・メディアワークス
- 発売日: 2014/01/28
- メディア: Kindle版
- この商品を含むブログ (4件) を見る
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)
これはできればで良いのですが，例えば Rails の bundle 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 したものをレビューに出すようにします．
先にも振れましたが，メンティーに仕事を振るときのメンターの気の遣いどころでもあります．
人によっても違うと思うし，書き忘れているところもあると思いますが，僕は上記のような感じでやっています．
皆さんはどうですか？
ラップトップで何でもやる時代に手書きマインドマップの話をしたい
新しい職場に転職して 3 ヶ月経ったが，仕事をする上で明らかに使うことが増えたのが手書きマインドマップだ． 今日は，なぜ手書きマインドマップを使うケースが増えて，僕がどう使っているかについて書こうと思う．
なぜ最近になって手書きマインドマップを使うようになったのか
エンジニアに Macbook が，ビジネスに Thinkpad や Let's Note が支給される会社に転職したのが一番の理由だと思う．
前職のオフィスは据え置き PC が配置されており，会議や打ち合わせは誰かの PC にリモートで繋いでアジェンダや資料を大画面で一緒に読み合わせたり，資料の印刷をしていたのだが，今の職場では誰もが会議室や講堂にラップトップを持ち込む．
しかし，やってみて気づいたのは，少し自分に関係ないトピックになるとすぐに内職したくなってしまうのは自分だけではないことだった．特にエンジニアだと，会議が始まる前に書いていたコードが気になってしまうのは仕方が無い側面もある．
逆に話す立場からすれば，本当にこの人は話を聞いているんだろうかと疑う気持ちが芽生えてしまうことも無いわけではない．現に，自分は転職活動をしている中でいろんな企業の面接官がラップトップをカタカタやっていたのが結構気になっていたし，間違いなく自分の話に興味があるであろう採用面接というシーンですらそういう風に感じる人がいるということは，ラップトップを開いていないということが話を聞いている姿勢を表すのに一番効果的なのかなと思うようになった． (議事を取るときだけはしっかり断りを入れてラップトップを開いてメモを採るようにしている)
とにかく話し手聞き手どちらにとってもラップトップがあることで会議の生産性はきっと下がってしまうと感じて，極力手書きで会議に参加しようと思い始めて，その際に便利だったのがマインドマップだった．
また，考え事をするのに PC にメモを書いているだけだと気が散ってしまうので，ラップトップを閉じて考える時間を確保するための手段であったことも理由としてあげることが出来る．前職ではメールだけだったのが，新しい職場に移って Chatwork や Slack まで飛んで来るようになって，ラップトップを閉じるときには閉じるという習性が身についたのだと思う．
手書きマインドマップの良いところ
自分なりにマインドマップの気に入っているところを挙げると，以下の3つが大きいと思う．
順序のない非構造データ
前職のときまでは，こういうブレーンストーミングをするときには箇条書きでひたすら書いていくことが多かったのだけれど，それと比較してマインドマップが良いのは，項目と項目のネットワークによる構造データでありつつ，順序性が無い点だと思う．
一直線に話が進んでゆく文章や，一方向に項目を並べていく箇条書きでは，当然ながら重要なものが最初に来るべきである．それと対比して，思いつきというものは重要な順に出てくるとは限らないし，人に文章やプレゼンで説明するときには順序を変えるだけでストンと腑に落ちるケースが多い．だから，思いついたことをひたすら書くフェーズの後に，順序などの構成を考えるという作業にマインドマップは効率が良い．
書くことで気持ちが落ち着く
文字に落とすことなく，気持ちや頭のなかで整理できないまま不安や不明点を抱えていると，それ自体の不安が雪だるま式に大きくなってくることがある．それをきちんと紙の上に落とすことで，どこからどこまでが不安だったのかの境界線が，少しだけ客観的に分かるような気がする．
自分がこういう手段を取るようになったのは，ファーストリテイリングの柳井さんの本にあった「若かった頃に，夜中仕事で不安になったら逃げないで不安に思っていることを紙に書く．そうすると"なんだ，こんなちっぽけなことで悩んでいるのか" という気分になる」という旨の記述を読んでからだった．
「そんな簡単な方法で…」と読んだときには疑ったものだったが，いざやってみるとうまくいくから不思議である．
やり方に制限がない
アナログなツールであるからこそ，やり方に制限がない．マインドマップの Mac アプリケーションや Windows アプリケーションも数多くあるし，自分も使ったことがあるが，自分の気持ちや思いつきのままに好きな構造，好きな文字の大きさでぱぱっと書けるのは思考を妨げないので，個人的には手書きが良いんじゃないかなぁと思っている．
むらみん流手書きマインドマップ
マインドマップの使い方など，市販の書籍やネット上を漁ればいくらでも出てくるのだが，ここでは，今回のブログ記事を書くときに使ったマインドマップを題材に，自分なりのやり方を3つ挙げる．
始点は少し左側に置く
右利きの場合，右から左に線を引くより左から右に線を引く方が間違いなくナチュラルだし，何も制限がなければ線は左から右に書きたくなる．自分の場合，中心にスタートを置いてマインドマップを書き始めても，左半分は本当に真っ白になってしまう．
物の本に当たると，マインドマップは中心から始まって広がってゆくのが大事とかいう説もあるが，きれいに書くのが目的ではないので個人的にはどうでも良い．
ゴールを決めて，遠いところからも始める
この記事を書くに当たってのマインドマップはそれほど明確で難しいゴールがあったわけではないが，例えば「現状煩雑なサーバーの運用を簡単にするにはどうしたらよいか」とか「チームが上手く回っていない気がするのはなぜか」みたいな，ちょっと複雑だったり難しいトピックとなると，ゴールありきではあるものの，導きたい結論は一旦抜きにして現状認識から始めたり，逆にゴールを噛み砕いたりを繰り返して，お互いがつながるポイントを探したりする．そうすると，「一つの武器で2つの問題点が解決する」みたいな状況が見つかったりする．
色ペンを必殺技にする
今回のマインドマップでは「ブログの構成を決めて文字起こしに着手する」というゴールがあったので，書きたいトピックをひたすら書き出した後，順序を決める段階になって色ペンを持って話すべき順番を色付けしていった． 基本的に思いついた順に上から書き出しているのだが，振られた数字を見れば，必ずしも思いついた順に数字が振られているわけではないことがわかると思う．
さいごに
自分は前職の上司にマインドマップを教えてもらったときに，すぐに本屋でトニー・ブザンの本を買って読んだのだけれど，当時は「モワッとしたことしか書いてないなぁ」くらいの感想しか持たなかったけれども， 各個人なりのやり方があるのが前提として，とはいえ使い方の手本や型を学ぶという意味では発案者が書いたもの以上は無買ったのかなぁと思うので，そんな本を紹介してこのブログの結びとしようかと思います．
