スクラムマスターって何をする人？ への答え - SCRUM MASTER THE BOOK
SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ
- 作者:Zuzana Sochova
- 発売日: 2020/09/09
- メディア: 単行本（ソフトカバー）
『SCRUM MASTER THE BOOK』を読んだ。
この本は、長年多くのスクラムマスターを悩ませてきた2つの問題を解決してくれる。
スクラムを推進する多くのチームが、「専任のスクラムマスターは必要なのか」という問いを会社や上司から投げかけられて、悩んでいることだろう。 その理由のひとつに、エンジニアやデザイナー、マネージャといった馴染み深い役割ほど、スクラムマスターがなにをすべき人なのか浸透していない、ということがあるだろう。
答えは、この本を読めば良い。
本書は、「スクラムマスター」に焦点をあてた本だ。世のスクラムマスターに対して #スクラムマスター道 という教えを説き、導いてくれる。 スクラムマスターはこれを読めば、自分が明日から何をすべきか、明確な指針を得ることができるだろう。
スクラムマスターの根深い悩みのもう一つが、自分の今後のキャリアについて。
ぼくは、チームのスクラムマスターという役割から少し目線を拡げて、現在は会社全体のスクラムマスターの支援や、アジャイル的な考えかたの浸透に取り組んでいる。
この本にもそうしたスクラムマスターの段階的な成長、#スクラムマスター道 についての教えが書かれている。
自分は5年後どうなっていたいかに悩みながら、チームのスクラムマスターに取り組んでいる人にも1つの視野を提供してくれるだろう。
スクラムの多くの文献に触れ、プラクティスを学んだスクラムマスターが最後に学ぶべき「スクラムマスターとしての心構え」としての #スクラムマスター道 に入門しよう。
技術文書の執筆にめちゃくちゃ便利なtextlint
現在、少し長い技術文書を執筆する機会があって、ここ半月ほど毎週末にまとまった文章を書いている。
ここまで長い文書をまとめて書くのは、大学の卒業論文以来かもしれない。
書くにあたって、だいたいのエンジニアがそうするであろう振る舞いとして、『理科系の作文技術』を再読した。
あとは校正の手間をできるだけ省くために、リアルタイムでおかしい文章に気づけるようにtextlintを使ってみた。これも初体験。
特に、日本語の技術文書を添削してくれる textlint-rule-preset-ja-technical-writing が死ぬほど便利だ。
デフォルト設定からちょっとだけアレンジした。
{
"filters": {},
"rules": {
"preset-ja-spacing": true,
"preset-ja-technical-writing": {
"max-ten": {
max: 4
},
"ja-no-mixed-period":false
},
"spellcheck-tech-word": true
}
}
max-ten は一文中の読点の数が設定を超えたら怒ってくれる。デフォルト値は3だが、ちょっと制限がきつすぎるなと感じたので4にした。
ja-no-mixed-period は句点が無いと怒ってくれるのだが、見出しのように句点を打ちたくない箇所で大量に怒られるので、これはfalseにした。
ぼくがよく怒られるのは次の2つ。
「助詞の連続使用」とくに"が"、"に" あたりでしょっちゅう怒られる。
「〜だと思います」と書いてしまう。技術文書は主張をはっきりさせるべきなので、曖昧な表現は使うべきではない。ぼくはしょっちゅ「かもしれない」「思います」と書いて怒られる。怒られまくる。ぼくが普段いか に曖昧な文章を書いているのかということをつきつけられる毎日である。
あと、意味の重複する言葉もけっこう怒られる。「することができる」は「できる」と書け、とよく言われる。
これらは気をつけていても油断すると書いてしまうので、書いた瞬間に怒ってくれるtextlint最高である。
ちなみにこのblogは原稿を書かねばならない現実逃避によって書かれている。この分量を本来書くべき原稿に書いていたら進捗を得られていたのだが...。
オンライン登壇のノウハウゲット - スクラムフェス大阪で話してきました
スクラムフェス大阪というイベントに参加してきました。
プロポーザルを採択いただき、登壇する予定だったのですが、昨今の情勢を踏まえてオンライン開催に切り替わり、人生初のオンライン登壇にチャレンジしました。 今回の発表資料はこちらです。
登壇内容自体は、今年の頭にDevelopers Summit2020でお話したものとほとんど同じだったので、新しくプレゼンを作り直す必要が無い、と言う余力をせっかくなのでオンライン開催ならではの工夫に使おうと思いました。
通常の話者が壇上に立ち、聴衆が並んで座ってそれを聞く、と言うスタイルに比べて、オンライン開催はもう少しスピーカーと聴衆の距離が感覚的に近いと感じています。具体的にはチャットなどのコミュニケーションによってダイレクトに話者に意見を述べることもできますし、手元のマイクをONにするだけで、全員が同じ条件でスピーカーに話しかけることも可能なわけです。
なので、セッション中に引用している資料のURLをリアルタイムにチャットに流したり、チャットでの質問や感想をできるだけその場で拾って講演に組み込んだりすることで、インタラクティブな要素の強い内容を目指しました。
そのためには一点壁がありました。講演資料をKeynoteで作成しており、発表者メモなども仕込んでいたので、どうしてもスライドの投影をKeynoteのプレゼンテーション再生でやりたいのですが、PCに複数ディスプレイを接続しても、ディスプレイが全てプレゼンテーション再生に全画面持っていかれてしまって、チャットを読んだり書いたりできない...。
苦肉の策として、PCを二台並べて、スライド再生用とチャット用と使い分けることにしました。
チャット見ながらkeynote を使おうとするとこうなる pic.twitter.com/TlOFv8wkX9
— だいくしー (@daiksy) June 27, 2020
今後さらにオンラインプレゼンテーションの機会は増えるはずですので、プレゼンテーションツールを実装している各社はこの辺りの対応をお願いしたいです...。
とはいえ、試み自体はうまく行って、リアルタイムコミュニケーション登壇は成功したんじゃないかなーと思います。
聴いてくださったみなさん、ありがとうございました。
大規模なプロジェクトでのアジャイル - More Effective Agileの読書メモ
コンウェイの法則
- 大規模プロジェクトで複数のアジャイルチームを構成するには、その分割点がコンウェイの法則にしたがっているべきである
- アーキテクチャが不充分だと、結局は大規模なシステム全体に精通しないといけなくなり意味がない。
- アジャイルの隆盛と、マイクロサービス化の潮流のタイミングが似ているのは偶然ではない
- チームを分割したためにコミュニケーションコストがオーバーヘッドになるくらいなら、諦めてチームを統合したほうがよい。設計に関する技術的な判断と、チーム組織に対するマネジメントな判断とのトレードオフ
コミュニケーション
- 小さなチームと異なり、全ての情報が口頭伝達でもうまく行く、という期待を捨てなければならない。より多くの作業を文書化しなければならない
- スクラム・オブ・スクラムミーティングにはスクラムマスターよりもプロダクトオーナーを出席させる方が良いだろう
More Effective Agile ~“ソフトウェアリーダー"になるための28の道標
- 作者:Steve McConnell
- 発売日: 2020/06/11
- メディア: 単行本
オンラインのCSPO研修を受講しました
6月8日から11日までの4日間。オンライン(Zoom)で開催されたCSPO(認定スクラムプロダクトオーナー)研修を受講しました。
なんで受けたの？
昨年、自分の所属しているチームでPOの交代という大きなイベントがありました。
自分はチームのディレクターとして新しいPOを迎え入れることを考える必要がありました(ぼくは実はPOではない)。今手掛けているプロダクトにおける、POの役割というのはとても幅広く、いかにして新しいPOの負荷を下げて支援するか、ということを考えた結果、新しくPOチームを作ってPOを支援する体制を作ることを決めました。
POチームを運用する中で、当然様々な課題が発生するわけですが、POの目線に立って書かれた良い書籍などになかなか巡り合えず、学習にとても苦労しました。そこで、いっちょCSPOを受けてPOを支援するための学習をするか、と思い至ったのです。そのうちPO本人にも受けてもらいたいな、とは思っています。
どうだった？
実は最初に申し込んだのは世の中がこうなる前だったので、元々東京の研修会場で受講する予定でした。その後、情勢が変わり、何度か延期されたあとでオンライン研修に切り替わりました。
以前受講したCopeさんのCSM研修の印象がとても強かったので、正直オンラインでの研修に不安はあったのですが、スタッフさんのご尽力と神アレンジによってオンラインでも大変素晴らしい経験ができました。
オンライン開催だったので、終わった後にお酒を飲みにいく、などの流れになりませんから、明日の予習とか１日のメモをまとめたりだとか、集中して学習できた、という気がします。一方で、他の受講者とのコミュニケーションが少ないので、議論に発展する部分が少ないなーという寂しさもありました。ただ、最終日に急遽参加者が集まるdiscordサーバーが立ち上がったので、この後時間を見つけて議論ができると良いなと思っています。
4日間とても良い学習ができました。
夕会, Discord, ワーキングアグリーメント - フルリモートワークになって以降チームに取り入れたもの
チーム全員フルリモートワークになって間も無く2ヶ月になろうとしている。 この傾向そのものは今後段階的に弱まっていくだろうが、リモートワークの取り組みは以前よりも促進されていくのだろう。
元々自分のチームは新しい取り組みに前向きなチームで、いろいろなチャレンジをこれまでにもやってきたが、この2ヶ月はさらにハイペースで様々なチャレンジを行ってきた。この2ヶ月を振り返って、その取り組みを書いておこうと思う。
夕会を新しく導入
チームではこれまで、昼の休み時間明けにデイリースクラムを担う昼会をやっていたが、これに就業時間直前の30分の夕会を取り入れた。 任意参加で、雑談をするための会。毎日時間になるとSlackにチャンネルにGoogle MeetのURLが流れてくる。
オフィスワークがゼロになり、これまでオフィスに集っているメンバー同士の雑談がなくなったことを補うのが目的。 ただ、これまでにも同様の試みは何度もしているが、雑談という意味ではあまりうまくいかない。最初はみんな物珍しさもあって盛り上がるのだが、1, 2週間もすると取り立てて話題もなくなり、無言で誰かの打鍵音を聞き続ける30分間になる。当然だ。毎日決まった時間に「さぁ雑談をしなさい」と言われて毎日雑談できる人などいるわけがない。
しかしこれで別にいいと思う。夕会が終わったから今日の仕事を終えよう、という1日のメリハリになるし、いつもは静かでも日によっては雑談が盛り上がる日もある。 夕会の最後に、そこに集まったメンバーで「今日もお疲れさま」の一言があるだけでこの会は意味があると思っている。
Discordを導入
チームではSlackを使ってチャットコミュニケーションをしている。声のやりとりをしたいときはSlack Callなどを使っていたが、これをDiscordにした。 Discordは、誰がどのRoomで会話をしているかが一望できる。誰かが画面共有してペアプロをしているな、というのもチャットの外からわかるので、ちょっと覗きにいくか、という振る舞いも可能だ。 つまり、オフィスにいた頃の、あっちの方で誰かが何かをやっているから様子をみにいこう、というような行動を擬似的に再現できる。
最初は全員参加ということで始めたのだが、当然ボイスチャットに邪魔されずに集中したい、という人もいるので以下のルールとした。
- Discordへのジョインは「今なら声をかけてくれても大丈夫」という表明。なのでDiscordに接続している人には突然声をかけても良い
- ペアプロやペアオペレーションをDiscordでやると、外から興味ある人がやってきたりしてお得
ワーキングアグリーメントを導入
リモートワークはオフィスワーク以上にメンバー個人に大きな裁量が与えられる。別に仕事中に少し手を離して洗濯物を取り込んだり、夕飯の仕込みをしたって構わないわけだ。チームとしては、スプリントゴールを達成すれば途中のプロセスは別に問わないわけだが、そうはいってもチームとしての体裁を保つためには強制力を伴う取り組みは必要だ。お昼ご飯を食べた直後に食休みをしたい、と思っても、昼会の時間がくればそれには参加してもらわないと困る。ただし、昼会の開催時間がチームメンバーの多くにとって好ましくないのであれば、変更したりしても良い。
こういったルールを明文化し、チームの合意を明確にするためにワーキングアグリーメントを作った。Scrapboxに、参加必須の定例会のスケジュールやチームのレビューフローなど、これまで暗黙のルールとなっていたものを明文化する。それはスプリントのふりかえりのタイミングで毎回見直される。
リモートワークになって、チームとしてはそれを乗りこなすための様々な工夫をやっていきたい。だが、勢いよくいろいろなチャレンジを導入するのはいいが、中にはそれを好ましくないと思う人だっている。そういった賛否の声をきちんと集約し、議論の上でチームで合意するためにワーキングアグリーメントがとても大事だと思ったので導入した。
導入のきっかけは前述のDiscordだ。ぼくが独断で導入して全員参加を呼びかけたが、参加必須であることは好ましくないという意見をもらったため改めてワーキングアグリーメントとして明文化して議論の上運用ルールを調整してチームの合意とした。
こんな感じでこの2ヶ月はいろいろな試行錯誤をしながらこの状況を過ごしている。
