Cybozu Tech Meetup #2 に参加して、チームワークを考えました

2020/06/15 に開催されたCybozu Tech Meetup #2 チームワークあふれるGaroon開発チームに参加しました。

Cybozuさんと言えば社内にアジャイルコーチの組織を作られていて働き方に興味を持っていました。今回の勉強会では開発の具体的な悩みとそれをどうやって乗り越えているのかというお話が聞けました。私もそうですが、日々日々悩みながら開発されている様子が感じられて、それでも向き合って改善されているお話は勇気を感じられます。

勉強会は新しいことを知るだけじゃなく、僕もがんばらなきゃって気持ちになれることもいいですよね。

今回のオンライン勉強会は以下のツールが使われていて、とくにSlidoを使った質問受付のおかげで進行がスムーズに進んでいて良い仕組みだなっと感じました。

• 発表：YouTube Live
• 質問受付：Slido

発表の内容

今回は3名の方が以下のタイトルで発表されました。それぞれの内容の概要と感想をまとめたいと思います。

• チームワークあふれるGaroonチーム
• 他チームと一緒に生産性を高めるGaroonチーム
• ここが変だよGaroonチーム

チームワークあふれるGaroonチーム

• 歴史のあるプロダクト故の技術的負債
• 全社をまきこんだ打ち合わせで問題の正面から向き合う
• そこから始まった改善
  • 改善専門チームのはじまり
  • 改善タスクの消化が増えた
  • 他チームで協力が増えた
• 改善を通した対話で気づいた大切なこと
  • 意見の違いは背景の違い
  • お互いを知ることで生まれる尊敬や感謝

大変な時期を乗り越えてこられたことが伝わる発表でした。僕が1番のポイントだと感じた部分は問題の正面から向き合えたところです。日々ふりかえりで問題と向き合えていても、慣れてしまったり、変えられないと思ってしまって一番大きな問題が扱われないこともあります。今回のお話のようにそういった問題をチーム全員が気づけるようにして、改善が進む行動が取れると良いと思いました。

対話の気づきも良いなと思いました。私も書籍で対話を学び、意見の違いは背景の違いということに気づきました。今回の発表でも同じ気づきをされていてとても共感しました。

他チームと一緒に生産性を高めるGaroonチーム

• 技術的負債はたまっていくが、人数も少なく改善を進められない状況の中で改善
• 改善効果を出しているメンバーを見て、同じ生産性向上チームに参加
• 生産性向上チーム＝チームを横断して開発基盤を整備するチーム
• 自動テストの環境の改善を行った
  • マージごとのテスト時間が1時間から36分に改善
  • 定期実行のテスト時間が6時間から14分に改善

僕は2点良いなと思った部分があります。「他の方の取り組みに賛同して自身も参加した」と「結果が分かりやすく出ている」です。

「他の方の取り組みに賛同して自身も参加した」は大きな変化を起こすきっかけになると感じました。1人では広まらないことも2人3人と集まると大きなムーブメントになります。フォロワーの重要性は日に日に感じており、今回の取り組みも大きな変化を起こすきっかけになっていると思いました。

目に見える結果がでないと改善が無意味に感じて辛くなってきます。そのために、メトリクスをとったりして結果を可視化する必要があると思ってて、今回のお話は「結果が分かりやすく出ている」ので良いなと思いました。
目標を立てるプラクティスSMARTにも計測可能かどうかの基準があります。僕はこのあたりが苦手です。頑張らねば。

ここが変だよGaroonチーム

• 転職されて気づいたCybozuさんの良いところを紹介
• 自立しつつチームワークする
• 分報が活躍
• モブ作業が中心
• 探求時間の確保(改善方法の探求や導入したい技術の検証/開発)

Cybozuさんが大切にされているチームワークが感じられる文化だと感じました。分報だったり、モブだったり、お互いの状況が把握しやすい取り組みをされているのはいいですね。僕も分報の良さに最近気づいたところなので共感です。

転職された方にもチームワークの大切さが浸透していて文化が根付いていると感じました。

まとめ

Cybozu Tech Meetup #2 チームワークあふれるGaroon開発チームに参加しました。メンバーの取り組みに賛同して参加されたり、全社を巻き込んだ打ち合わせを実施して大きな改善に取り組まれたりとチームワークを感じるイベントでした。自分の開発に対しても気づきがあったので取り入れていこうと思います。

運営のみなさま、発表のみなさま、素敵なイベントをありがとうございました！

関連する記事

対話を学ぶのにおすすめの書籍
iucstscui.hatenablog.com

僕も分報の良さに気づいたことをまとめています。
iucstscui.hatenablog.com

組織やチームが成長するヒントを貰えた / Engineering Manager Meetup #8 に参加

2020/06/03 に開催されたEngineering Manager Meetup #8 オンライン開催!!に参加しました。新しいことがたくさん学べてとても深い時間でした！それにしても、オンライン開催が増えて参加できる勉強会が増えました。オフラインや各ローカルで実施する良さもありますが、どこからでも気軽に参加できるオンライン開催は嬉しいです。

4つのLTとOSTの構成でした。ツールはコミュニケーションにdiscord、OSTのテーマ出しと投票にsli .do、発表中のリアクションにcomment screen、OSTで付箋を使えるようにJamboardが用意されていました。オンライン勉強会は発表者にリアクションが伝わりづらいのでcomment screenは良いですね。

これからの「情報」の話をしよう @yaboounさん

• 情報の伝達不足によって開発に問題が起きる
• 情報の流れを設計して改善
• 2つの取り組み
  • 体制者と決裁者の明確化
  • 心理的安全性な文化の醸成

開発をするうえで情報の取り扱いが大切だということは納得です。スクラムでも透明性というキーワードで情報の見える化を大切にしていて、僕も大切にしたいことの1つです。今回のLTで特に参考になったことはtimes(分報)の部分です。timesはすでに取り組んでいて良さを実感している最中です。その中で「メンションが来たら光の速さでレスをする」だったり、「リーダーが率先して書く、雑に書く、業務に関係ないことを書く」はとても良いと思ったので参考させていただきたいと思います。

部下が一生懸命仕事に取り組んでくれるテクニック @kawagoikさん

• 新しい仕事や役割を一生懸命取り組んでもらえると良い面が多い
• 一生懸命仕事をしてもらう3つのポイント
  • 信じても大丈夫だと思ってもらう
  • 自分のためになると思ってもらう
  • 上手くやれそうと思ってもらう

全員が自分の役割に納得して一生懸命になると自己組織化されたチームになれそうですね。今回のLTは相手をよく知ることが大切だと感じました。書籍1兆ドルコーチでも信頼と愛の大切さが語られていて、やっぱり大切なんだと再確認しました。

1on1で「考えること」をどう支援するか @careerupdateさん

• 自ら考えてもらえるように1on1を工夫
• 自分のことを考えたことがない人には考えるハードルを下げて習慣化
• 考え方がわからない人にはアクションに落とし込むまで一緒に整理
• 考えたくない人はその要因に向き合う
• 考える気力がない人は要因を話しながら休息

苦手なことを一緒に整理して進めることは、まさにコーチングの力ですね。NCRWという考え方のように相手の力を信じることが大切だと考えています。コーチングは学んでいきたい領域です。

徹底的にアウトプットを伴う育成をやってみた話 @kojimadev さん

徹底的にアウトプットを伴う育成をやってみた話 from Yusuke Kojima

• アウトプット駆動の育成
• 日々のタスクにアウトプットをセットで組み込む(アウトプットのプロセス化)
• 毎日のアウトプットの施策
  • ペアプロ/モブプロで思考のアウトプット
  • 学んだことを話す、書く
  • 学んだ設計技術を実務で使う
• 毎月のアウトプットの施策
  • 技術記事の投稿

タイトルの通り徹底的なアウトプットでした。仕組みを考えるのもすごいですし、実践が継続できたのもすごいですね。個人的なアウトプット週間はできていますが、チーム全員で取り組む方法も考えようと思いました。良い刺激を受けました。

OST：EM自身の成長や育成をどうしているか

• メンバーに合わせたマネージメントをどう学ぶのか？
  • メンバーにヒアリング
  • 中長期的なキりャリアをベースに支援
  • ストレングスファインダー
  • 学習パターン
  • 成人発達理論
• 自分のマネージメントについて客観的なフィードバックってどうやってもらってます？
  • エンジニアマネージャー同士で情報交換
  • 上司からフィードバックをもらう
  • 社外勉強会で発表してフィードバックをもらう
  • メンバーとの1on1で直接的だけでなく間接的にももらう

OSTはEM自身の成長や育成をどうしているかのテーマに参加しました。知らないことがたくさん学べました。学習パターンや成人発達理論は改めて調べようと思いますし、エンジニアマネージャー同士で情報交換は試してみたいと思いました。

まとめ

Engineering Manager Meetup #8 オンライン開催!!に参加しました。組織やチームを成長させるにはメンバーを知って信頼することが大切だと再認識しました。また、OSTでは色々な方と話しでき、自身の整理にもつながりました。

運営のみなさま、発表のみなさま、素敵なイベントをありがとうございました！

関連する記事

一兆ドルコーチは書評を書いてます
iucstscui.hatenablog.com

NCRWはこちらの勉強会で知りました
iucstscui.hatenablog.com

kakakakakkuさんのブログメンタリングで学んだことをふりかえり

2020/03〜2020/05の3か月間、カックさん(@kakakakakku / id:kakku22)にブログメンタリングしていただきました。ブログメンタリング期間はレベルアップが止まらない日々で、応募して良かったです。ブログメンタリング前後でPV数は倍以上になりましたし、新しい技術にチャレンジするきっかけにもなりました。また最終月は週2でブログを更新できました。そんな良いことづくしのブログメンタリングをふりかえりたいと思います。

ブログメンタリングは何するの？

ブログメンタリングのメンティーになると、カックさんから技術ブログに関して幅広いアドバイスをいただけます。アドバイスは書いたブログのレビューや書き方やブログネタの見つけ方、自身のブログの分析方法などなどです。

詳しくは下記記事を見てみてください。

志望動機

• PV数を伸ばしたい
• 自分の成長に繋がるブログにしたい

僕は2018/08からブログを始めました。そのキッカケもカックさんでした。以下のpodcastやブログ記事を見て「これはもうアウトプットするしかない！」っとなってブログを始めました。

ブログを始めて1年以上経過し、write-blog-every-weekという週1のブログ更新を支え合うslackにも入り、週1更新も習慣になりました。習慣化できたなら1段ステップアップしたいと思った矢先にブログメンタリングの募集があり応募しました。ブログメンタリングは大変そうな印象はあったのですが、レベルアップするためと覚悟を決めて「えい！」っと申し込みました。

ブログメンタリングの結果

課題としていたPV数と成長に繋がるブログの結果を紹介します。

PV数

PV数はブログメンタリングを受け始めた頃と最終週を比較すると倍以上、週間1000PVを超える日もありました！

成長に繋がるブログ

ブログメンタリング期間中は18記事を書き、CircleCIやUnityなど今まで触れてこなかった技術にチャレンジできました。また、Gitを改めて学びなおすことで知らなかったコマンドやオプションを知れました。

以下の記事は自分の勉強にもなりましたし、はてなブックーマークもついて他の方の役にも立てたと思います。

ブログメンタリング期間中の様子

ブログメンタリングは期間前から始まります。まずブログネタ20個の用意をお願いされ、さっそくのストレッチゴールに追い込まれます(笑) その後は僕が書いたブログ記事をレビューしていただいたり、カックさんがブログを公開する度に何を意識して書いたかを教えていただけます。

レビュー以外にもブログネタ一覧や過去ブログから興味がありそうな情報を教えていただいたり、要所要所でカックさんが僕のブログを分析した結果をもとにしたアドバイスをいただけます。これがとても良い気付きになります。また、PV数などのKPIをもとにした週単位のふりかえりや月単位のふりかえり結果からもアドバイスがいただけます。

ブログメンタリングを通しての気付き

ブログメンタリングを通して多くの気づきがありました。ブログに関することだけでなく、人に教えるときに大切なこともカックさんの接し方から学べました。それらをまとめていきます。

わかってないことに気づくとブログネタになる

ブログメンタリング前まで毎週のように困っていたブログネタに困らなくなりました。事前にブログネタを20個出したというのもありますが、レビューだったり、それ以外でも「ここは改めて調べるとネタになりますよ」っと絶えずアドバイスをいただけます。繰り返し繰り返しアドバイスをもらうとブログネタのアンテナ感度があがり、自分でブログネタを見つけやすくなりました。期間中のGit記事はそのヒントをもとに出せた記事です。なんとなく分かっている状態の技術はすべてブログネタになると気付きました。

ブログネタに関しては以下のサイトも参考になります。

見た目にこだわると読みやすいブログになる

ブログの書き方についてたくさんのアドバイスをいただき、過去のブログは書きなおしたいと思えるぐらいレベルが上がりました。人によってアドバイスされることは違うと思いますので気になる方はブログメンタリングにぜひ応募していただければと思います。僕自身が一番意識するようになったのはブログで表現できるリッチなUIを駆使して見やすくすることです。図表をいれたり、埋め込み形式のリンクにしたり、文字ばかりの記事にならないように意識しています。僕は特に書評を書くと文字だけになりがちなので特に気を付けています。

最新の書評はこちらです。

自分の行動から自分のブログを考え直す

ブログのタイトルは悩みますよね。短いと伝わらないし、長いと読み飛ばされる可能性もあります。そうやって悩んでいるとき「自分が検索してクリックするときの基準を考えてみましょう」っとアドバイスを受けました。このアドバイスはタイトルに限ったことではありません。自分の行動を分析すると自分のブログを良くするヒントが見つかりそうです。

そのとき必要なことを伝える

ブログメンタリングは今まさに響くことを選んで伝えてもらっていると常々感じていました。針の穴を通すようなアドバイスです。僕だったら初めにまとめて色々なことを教えてしまっていると思います。そこを我慢して少しずつ伝えてもらったからこそアドバイスを理解できたと思います。伝えすぎないのも教えるときには重要な要素ですね。

本人よりも先に嬉しい状況を見つけてお祝いする

書いた記事がTwitterでリツイートされていたり、はてなブックーマークがついていると先に見つけてお祝いメッセージとともに教えてくれます。これは嬉しいですよね。続けるモチベーションになります。僕も他の人の成功や嬉しいことは一緒に喜んでいきたいです。

やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ

山本五十六さんの名言です。アドバイスだけの口だけでは信頼できずにモチベーションも下がっていきますよね。カックさんはこの名言どおり自ら実践されていました。毎週ブログの更新は当然ですが、ほぼ月曜日に更新されていましたし、5日連続で更新されることもありました。他にもブログの書き方やブログネタに関するアドバイスも実践してこんな感じですと公開して見せてくれます。ブログレビューでは必ず良い点と改善点を教えてくれます。まさにこの名言を体現されています。

まとめ

2020/03〜2020/05の3か月間ブログメンタリングを受けて圧倒的に成長しました。カックさん本当にありがとうございました！ブログメンタリング前は週1更新も苦しんでいたのですが、最終月は週2更新ができて自信につながりました(大変でしたが(笑))。PV数や読者数もまだまだ増える余地はあるとアドバイスを頂いているので今までのアドバイスをもとに自らストレッチゴールを定めてさらに1段ステップアップしたいと思います。これからもブログを通してより良いエンジニアになれるよう日々成長です！

ブログメンタリングはTwitterで募集がありますので興味のある方はカックさん(@kakakakakku / id:kakku22)をフォローしておくと良いと思います。

関連記事

write-blog-every-week

Visual Studio Code＋Draw.io IntegrationでUMLなどの作図を便利にする

Visual Studio Code(VS Code) にDraw.ioの拡張が追加されたと聞いて使ってみました。

marketplace.visualstudio.com

UMLだったり、説明資料だったり、図を書くときにぴったりな機能です。普段からVS Codeを使っていれば環境構築も1分ぐらいで終わるので使ってみてはどうでしょうか。

Draw.ioとは

Draw.ioはUMLやフロー図など様々な作図ができるツールです。オンライン上やデスクトップアプリケーションとして使えます。今回、VS Codeでも使えるようになりました。
www.diagrams.net

操作画面

操作画面は以下のとおりです。VS Code 上でストレスなく作図できます。おどろきです！

インストール方法

VS CodeのExtensionsでdraw.ioを検索するとDraw.io Integrationが見つかりますのでインストールするだけです。簡単！

使い方

編集のはじめかた

drawioかdrawio.svgの拡張子をつけたファイルを作成、編集すると作図画面が表示されます。

シェイプ(図形)の追加

作図で使用するシェイプを追加できます。More Shapes...を選択すると選択画面が表示されるので欲しいシェイプにチェックを入れてApplyで追加できます。

図をXMLで編集する

図を見ながらXMLで編集できます。チュートリアルには書いてあったのですが少し詰まりましたので手順をまとめておきます。

1.VS Codeを2画面にする
VS Codeの「View→Editor Layout」から「Split 〇〇」を選択します。(〇〇はDownでもLeftでもお好きな分割で良いです)

2.XMLファイルとして開きなおす
右上の「・・・」から「Reopen With...」を選択し、「Text Editor」を選択するとXMLファイルとして開かれます。

すると以下のように作図タブとXMLタブが同時に編集できます。

XMLを修正するとリアルタイムで図が修正されていきます。検索しながら編集したり、同じような修正を何か所も行う場合はXMLで修正したほうが便利ですね。

まとめ

VS CodeでDraw.ioの拡張を試してみました。VS Codeを使っていれば簡単に作図環境が構築できるので便利です。.drawio.pngファイルの編集機能のリリースも予定されていますので、さらに便利になりそうです。(本記事執筆時のDraw.io Integrationのバージョンは0.5.2です)

LeSSのルールとヒントが学べる「大規模スクラム Large-Scale Scrum(LeSS)」 の本を読んだ

参考：Overview - Large Scale Scrum (LeSS)

スクラムをスケールさせる方法を知るため大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法を読みました。

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

アジャイルをスケールさせるフレームワークはいくつかあってLeSSはその内のひとつです。他にはScaled Agile Framework、Scrum@Scale、Nexusあたりが有名だと思います。

LeSSはスクラムを出来るだけそのまま大規模にしたフレームワークです。5秒でLeSSを説明するなら「スクラムの開発チームが複数になってそれ以外はスクラムのまま」です。なのでプロダクトバックログは全体で一つです。スプリントバックログは開発チームごとにあります。ルールは簡単ですが、実践するには難しそうに感じますよね*1。だからこそ、基本のスクラムがうまくまわっていないと失敗しやすくなると思います。*2

本書は各章ごとに1チームのスクラム(通常のスクラム)、LeSS(2〜8チームのスクラム)、LeSS Huge(それ以上のスクラム)の説明があり、LeSSだけでなく1チームのスクラムについても多くのヒントがまとめられています。

目次

1 LeSS でもっと多く
2 LeSS
第I部 LeSS の構造

• 3 導入
• 4 顧客価値による組織化
• 5 マネジメント
• 6 スクラムマスター

第II部 LeSS のプロダクト

• 7 プロダクト
• 8 プロダクトオーナー
• 9 プロダクトバックログ
• 10 DONEの定義

第III部 LeSS スプリント

• 11 プロダクトバックログリファインメント
• 12 スプリントプランニング
• 13 調整と統合
• 14 レビューとレトロスペクティブ

第IV部 More or LeSS

• 15 次は何をすべきか?

付録A LeSSのルール
付録B ガイド

スクラムとLeSSの大きな違いは体制

スクラムは、1人のプロダクトオーナー(PO)、3～9人の開発チーム、スクラムマスター(SM)で開発をします。LeSSは1人のPO、2～8の開発チーム、1～3の開発チームに対して1人のSMで開発します。LeSS Hugeは人数が多いためいくつかのエリアに分けます。そのエリアは要求エリアと呼ばれ、4～8の開発チームとエリアプロダクトオーナー(APO)で構成されます。1人のPO、複数の要求エリア、1～3の開発チームに対して1人のSMで開発します。POは全体のプロダクトに責任を持ち、APOは各要求エリアに責任を持つことで負荷を分散しています。

LeSSのチーム体制のイメージ

LeSS Hugeのチーム体制のイメージ

イベントはほぼスクラムのまま

LeSSはスクラムと同等のイベントを実施します。大人数になるため実施方法が変わるイベントもありますが目的は変わりません。たとえば、スプリントプランニング1はPO＋各チームの代表者(or全員)＋SMで各チームが何を作るか決定します。スプリントプランニング2は各チームに分かれてどう作るかを決定します。

LeSSになって追加されるイベントはオーバーオールプロダクトバックログリファインメントとオーバーオールレトロスペクティブです。プロダクトバックログリファインメントやレトロスペクティブは各チームや複数チームで実施しますが、オーバーオール〇〇は全チーム参加で開催されます。

スクラムと同じく、理解は容易、習得は困難

スクラムのベース知識があればLeSSのルールを理解することはたやすいですが、導入や運用していくことはスクラム以上に難しいと感じました。本書はLeSSのルールだけでなく導入や運用を成功させるヒントが学べます。そして、そのヒントはLeSSだけでなく、通常のスクラムにも当てはまる内容だと感じました。

1 LeSS でもっと多く

1 「LeSS でもっと多く」はなぜLeSSでつくるのかを知れます。僕は以下の一文でスクラムやLeSSの良さを再認識させられました。

スクラムは必要最低限のプロセスしか定義されてないため、初期段階では不完全な状態で開発を始め、継続的に学習しスクラムフレームワークの枠内でプロセスを改善していくことになります。

過去に受けた認定スクラムマスターの研修でも「スクラムは問題を見つけるためのフレームワークで、何も解決しない。」と教わりました。スクラムやLeSSを導入するとすぐに課題が見つかると思いますが、それは正しい状態でそこから学習、改善していくフレームワークだと言えます。

4 顧客価値による組織化

4 「顧客価値による組織化」はコンポーネントチームとフィーチャーチームについて学べます。コンポーネントチームはフロントエンドとサーバサイドのように技術で分けたチームで、フィーチャーチームは機能に必要なスキルを集めたチームです。LeSSは顧客中心の原則があり、フィーチャーチームを目指していきます。スクラムも同じくフィーチャーチームを目指しています。

機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。
※スクラムガイドより開発チームの特徴を抜粋

フィーチャーチームは以下のメリットとデメリットがあると書かれています。
メリット

• 明確な機能の所有権・・・顧客中心の機能にチームが責任を持てます
• 遅延を引き起こす依存関係がない・・・複数コンポーネントの影響があっても別チームの開発待ちになりません
• 顧客の言葉で話す開発組織・・・誰のために作っているか理解し、より目的のある開発ができます

デメリット

• システムのより多くの部分を学ぶ必要がある・・・複数コンポーネントの知識が必要です
• 乱雑なコード/設計に繋がる可能性がある・・・コンポーネントへの責任が薄れ、コード/設計は劣化する可能性があります
• 作業の分割方法に影響する・・・コンポーネント単位の作業分割を機能単位の分割に変える必要があります

僕の過去の経験上はコンポーネント単位でチームやタスクを分けていることが多いです。デメリットとして書かれている「多くの知識が必要」がネックになり作業効率を考えてコンポーネント単位に分かれがちだと思います。コンポーネントチームからフィーチャーチームへの移行はモブプロやペアプロが1つの改善手段だと思います。本書ではフィーチャーチームの導入マップを使った導入方法も紹介されています。

参考：Feature Teams - Large Scale Scrum (LeSS)

8 プロダクトオーナー

8 「プロダクトオーナー」はPOとしての原則と運用のヒントが学べます。POはスクラムでも難しいですが、LeSSになるとさらに難しくなるでしょう。LeSSを使って成功するプロダクトを作るにはPOの理解と行動が大切で、本項目はそれが学べます。本項目で特に参考になった内容はPOがやってはいけないことです。以下のタスクは行わず、チームに任せようと書かれています。

• 依存関係の調整やチーム間の調整
• チームの仕事の予想と計画
• 見積り
• 各メンバー一人ひとりまでの情報の伝達

チーム間の調整はPOの立場的にやってしまいがちだと思いますが、これをチームに任せられる状態になれば強い組織だと思います。SMがPOをフォローしてPOの負担を減らしていかないと開発がまわりません。POの立場になる人は開発以外の社内作業も多いイメージですので、過負荷にならないようにSMやチームにタスクを任せながら、意思決定のための時間を増やしたいですね。

13 調整と統合

13 「調整と統合」は自己組織化された調整と統合を複数チームで行うヒントが学べます。LeSSではチーム同士の調整はチームに任せられています。そのためにも自己組織化されていることが求められます。本項目では15のガイドが紹介されていてどれも共感できる内容でした。

• ただ話す
• 調整しやすい環境
• コードでのコミュニケーション
• 継続的にインテグレーションする
• コミュニティ
• クラスチームミーティング
• 複数チームの設計ワークショップ
• 現在のアーキテクチャワークショップ
• コンポーネントメンター
• オープンスペース
• トラベラー
• 偵察
• スクラムオブスクラムズをしない方がいいかも
• リーディングチーム
• テクニックを混ぜ合わせる

すぐできて効果が高そうな項目は「ただ話す」です。他のチームことが分からなくて、そこから話が進まない場面がありますよね。解決は簡単で分からないなら聞けばよいというヒントです。チームが違うと自分たちで壁を作ってしまって、相談するにもハードルが高くなりがちです。そのハードルを低くしてチーム間の調整が楽にできれば解決できる問題は多いと思いました。

まとめ

スクラムをスケールさせる方法を知るため大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法を読みました。読む前に抱いていた印象よりも通常のスクラムどおりでした。LeSSのルールだけでなく、進めるためのヒントがまとまった書籍なので、LeSSを導入する際にはおすすめの一冊です。

*1:軽量、理解が容易、習得は困難

*2:スクラムやアジャイルに関わらず大規模な開発は難しい

リポジトリの一部だけcheckoutするGitコマンド：sparse-checkout

大きなリポジトリを扱うときにリポジトリの一部だけcloneしたい時があります。そんなときに使えるコマンドがgit sparse-checkoutです。Partial Cloneとgit sparse-checkoutコマンドを使うとリポジトリの一部ディレクトリだけcheckoutできます。

Partial Clone機能を使うと不要なオブジェクトを除外してダウンロードできるので、大きなリポジトリもサイズを抑えて素早くcloneできます。
git-scm.com

Partial Cloneしたリポジトリに対してgit sparse-checkoutを使って必要なファイルだけcheckoutします。Git 2.26でgit sparse-checkoutにaddが追加され使いやすくなっています。
git-scm.com

今回の検証に使ったgit version は 2.26.2 です。

2020/08/29 追記

git 2.27以降は同じ手順が使えないので注意です。
iucstscui.hatenablog.com

概要

リポジトリの一部だけcheckoutするにはPartial Cloneで最小限のデータをcloneし、sparse-checkoutで必要な部分だけcheckoutします。

使い方

Partial Cloneで最小限のデータをcloneする

Partial Cloneはcloneコマンドのオプションを使って実現します。
git clone --filter=blob:none --no-checkout <リポジトリ名> <ディレクトリ名>

--filter=blob:noneオプションはblobオブジェクト*1のダウンロードを除外します。--no-checkoutはclone完了後のcheckoutを行いません。これによりファイルをダウンロードせずにcloneできるためサイズが抑えられます。

以下は同じリポジトリに対してオプションを変えてcloneした場合のサイズの違いです。--filter=blob:none --no-checkoutを使った場合にサイズが節約されていることがわかります。

git clone https://github.com/git/git.git
→185 MB
git clone --no-checkout https://github.com/git/git.git
→144 MB
git clone --filter=blob:none --no-checkout https://github.com/git/git.git
→65 MB

sparse-checkoutで必要なディレクトリだけチェックアウト

--filter=blob:none --no-checkoutを使ってcloneした場合、ディレクトリ内は空の状態です。sparse-checkoutコマンドで必要なディレクトリをcheckoutします。

1. sparseCheckoutを有効にする

git sparse-checkout init --coneコマンドでsparseCheckoutを有効にします。

ルートディレクトリのファイルが展開され、サブモジュールが初期化された状態になります。ディレクトリ関連はcheckoutされません。

2. パターンを指定してディレクトリをcheckoutする

パターンの指定は2種類あります。

git sparse-checkout set <パターン>

指定したパターンに一致したディレクトリがcheckoutされます。例えば、git sparse-checkout set DocumentationでDocumentationディレクトリがcheckoutされます。

git sparse-checkout add <パターン>(Git 2.26 で追加)

指定したパターンが追加され、一致したディレクトリがcheckoutされます。例えば、git sparse-checkout set Documentationのあとgit sparse-checkout set ciとした場合、ワーキングツリーにはciディレクトリだけcheckoutされています。同じ条件でgit sparse-checkout add ciとした場合、ワーキングツリーにはDocumentationとciディレクトリがcheckoutされます。

3. 指定しているパターンを確認する

git sparse-checkout listでsparseCheckoutに設定しているパターンが確認できます。

4. sparseCheckoutを無効にする

git sparse-checkout disableでsparseCheckoutが無効になり、リポジトリの全ディレクトリがcheckoutされます。

補足

sparse-checkoutを使っている場合でもコミットやプッシュ、ブランチの切り替えは可能です。

まとめ

一部だけclone(checkout)したい場合に便利なgit sparse-checkoutを調べました。大きなリポジトリを扱う場合に効果があります。過去に紹介した取得するコミット数を減らしてclone するshallow cloneと合わせて知っていると状況に合わせた使い分けができます。
iucstscui.hatenablog.com

参考URL

github.blog
github.blog
github.com

おまけ

読み方(調べるまで分からなかったので)
sparse-checkout：スパース チェックアウト
Partial Clone：パーシャル クローン

*1:blobオブジェクトはファイルの内容が格納されたデータです

パタン・ランゲージは作り手と使い手を近づける / アレグザンダー勉強会 に参加した

2020/05/14に開催されたアレグザンダー勉強会 2020/05に参加しました。アレグザンダーやパタン・ランゲージについては詳しくありませんが、デザインパターンやFealess Changeなどパタンに関する技術に触れてきました。アジャイルとも関連があるアレグザンダーについて知識を深める良い機会だと思い参加しました。

alexander-study.connpass.com

どういった思いで勉強会を立ち上げたのかはkyon_mmさんの記事を参照いただくのが良いです。
note.com

第1回は参加したみなさんでアレグザンダーの理論を使って生き生きとしたコミュニティにしていくにはどうすれば良いのかを話し合いました。講義形式の勉強会ではありませんでしたので体系だったまとめではありませんが、雰囲気を伝えつつ、僕が印象に残ったことをまとめていきます。

勉強会の雰囲気

Discord(コミュニケーションツール)とMural(オンラインホワイトボード)を使って進行していきました。付箋を使いながらどんなコミュニティにしたいのか話をしていき、その途中途中でアレグザンダーの話が盛り上がる、熱量のある会でした。

当日のホワイトボード

印象に残ったこと、感じたこと

パタン・ランゲージは多様性を大切にし、文化をうむ考え方

パタン・ランゲージは何か特定の問題に対応するための解決集のような印象を持っていました。それゆえに「このときはコレ」といった繰り返し起こる良い再現性を言葉にして伝えるためのツールと考えていました。その考えは間違ってはいないけど、足りてなかったと感じています。今はパタンをうむプロセスや、作り手と使い手を近づけることも含めてパタン・ランゲージだと考えています。また、この作り手と使い手の近い状況が生き生きとした環境を生むと考えています。

SECIモデルと重なる部分がありそう

SECIモデルは暗黙知から形式知、形式知から暗黙知を「共同化(暗黙知)」「表出化(形式知)」「連結化(形式知)」「内面化(暗黙知)」という4つのステップで考えるフレームワークです。
anagileway.com

パタン・ランゲージも暗黙知を形式知にし、その形式知同士を組み合わせて一つの知識にするので似ている部分があると感じました。パタン・ランゲージもSECIモデルのように成長していくと考えると新たな気づきがありそうです。

生き生きとしたコミュニティについて考える

勉強会が終わってからも生き生きとしたコミュニティはどういう状態なのか考えていました。個人的な考えとして運営と参加者や、登壇者と参加者など、発信側と受信側が近い状況を保つことは生き生きとしたコミュニティを運営するポイントだと考えています。コミュニティには職種が違ったり、テーマについての知識量が違ったりと色々な方が参加されます。その誰もがコミュニティに貢献出来て、誰もがコミュニティから何かを得られる場にできれば良いなと思います。

まとめ

第1回目のアレグザンダー勉強会に参加しました。今までの僕はパタン・ランゲージについて狭い知識だったことに気づき、今後のパタン・ランゲージを学ぶ楽しみが増えました。パタン・ランゲージとSECIモデルとの共通点も気になるので合わせて調べていきたいと思います。

関連記事

SECIモデルはScrum Fest Osaka 2019で初めて知りました。
iucstscui.hatenablog.com