天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます

『「考える」考えかた』著者によるお話&実践ワークショップに参加してきた

11/25(水) に表題のイベントに参加してきたので、参加レポートを書きます。 

devlove.doorkeeper.jp

資料

概要

「考える」考えかたの著者である、渡部 啓太さん(@sobarecord)が作った、「考える」考えかたのステップを追体験することで、各々の「考える」を考えてみよう、というイベントでした。

参加経緯

スクフェス札幌の江端さんのKeynoteを聞いて、自分がこれまで如何に考えることをしたつもりになっていたかを痛感しました。
これまでの仕事上の意思決定は、殆どが単なる感覚に過ぎず、沢山の失敗を無意味に積み上げていたことに気が付きました。
上手に考えられるとは何かを考えていた所、今回のイベントの存在を偶然知り、参加することにしました。

オープニング

渡部さんがなぜ「考える」を考えようと思ったのかの経緯と、渡部さんの「考える」考えかたの話をしていただきました。
渡部さんのお話を伺うのは初めてでしたが、「考える」を考えようと思った経緯が江端さんのCSM研修だという話を聞いて、一気に親近感を感じましたw

ワーク①~考えるとは何かを考える~

自分にとって考えることの定義は、

  • 解くべき課題を設定すること
  • 課題を解決するためのアプローチを決めること

だという結論になりました。
が、渡部さんが定義していた「発散と収束」という定義や「脳みその血行促進すること」といったユニークな意見まで、参加者皆さんが考える「考える」がたくさん聞けて、自分の定義以外の「考える」を意識して考えることをしてみようと思いました。

ワーク②~「考える」に点数をつける~

意識さえすれば、自分が定義した「考える」という行為はできますが、「考える」ことを考えたことがなかったし、考えているふりをして感覚で動いていただけの場面がこれまで多かったので、50点位としました。
参加者皆さん全体的に点数は低めで、「考える」ことに悩んでいる様子が伺えました。

ワーク③~いい感じに考えられた時はどんなときか考える~

過去を振り返った所、

  • 当事者意識が働いた
  • 前提を捨てられた
  • 自身の思い込み&感情を捨てられた
  • 論理的に整理できた

が揃った時、いい感じに考えられた(=考えた結果の行動に対して良いフィードバックが返ってきた)と結論が出ました。
参加者皆さんの意見も参考になる意見が多くて、「前向きに思考できていた時」や「リラックスしていた時」や「やらないことが明確になった時」など、多数の意見が出ていました。

ワーク④~成功要因を「型」にしてみよう~

これまでのワークと比べて2ランク位難度が上がった気がしました。一応、

  • なんでこの問題を解決したいんだっけ?を最低5回は考える
  • 自分が絶対正しいと思っていることを書き出して俯瞰的に見る

等を挙げましたが、今一つしっくりと来ませんでした...
「考える」ことに限らず型を作ることの難易度は高いと思うので、今すぐに完成形を作るのではなく、こういったイベントや日々のふりかえりを通して、少しずつ自分なりの型が作っていければ、と思いました。
参加者皆さんも型を作る難しさを実感されていましたが、各々が現時点で考える型を言語化できていて、多種多様な型を共有することができており、有意義な時間を過ごせているように見えました。

イベント後

イベント後は、今回のイベント内容を問わず渡部さんを交えて色々な話をする時間を設けていただきました。
渡部さんは非常に話しやすい方で、皆さんからも様々な話が飛び出し、イベントと同じ位有意義な時間でした。
特に、チームで考えるこちについてお話が聞けたのは大変参考になりました。
どうもありがとうございました。

感想

スクフェス札幌以降、個人で悶々と「考える」ことについて考えていましたが、皆さんの「考える」がたくさん聞けて学びが多かったです。
また、一人で考えていた時よりも、皆さんに自分の考えをシェアする前提で考えていた時(=今回のイベントでワークをしていた時)の方が、自身の中で納得感を持って考えることができたのも良かったです。

尊敬する先輩エンジニアとペアプロして気がついたこと

今日は、自分が尊敬している、凄い成果を出されている先輩エンジニアの方と一緒にペアプログラミングする機会がありました。
めちゃくちゃ学びがあったので、忘れない内に文章に残しておきます。

 

 

TODOリストを作り頻繁にアップデートする

最初に、何ができればゴールかを整理したTODOリストを作成し、どんどんチェックをつけていきます。
TODOリストの粒度は細かく、完了条件が明確で分かりやすいです。
そのため、TODOリストは次々に更新されていき、仕事にリズムを生んでいました。
また、コードに改良の余地が見つかったものの手を止めたくない時やプログラミングしていて気になることが出てきた時も、TODOリストに即座に移動させていました。
目の前のTODOだけに集中する状態を常に維持させることで、パフォーマンスにムラがありませんでした。

休憩する

鬼のようなスピードで実装したいことを言語化してコードを書くのですが、一定時間経つと、ぱっと休憩を取ります。
そのため、パフォーマンスが落ちる気配がなく、何時間経っても鬼のようなスピードでコーディングをし続けます。

タイムボックスを作り、守る

休憩にしても調査にしても実装方針の検討にしても、常に時間を決めてタイマーで測ります。
タイマーが鳴るまでは作業に没頭するのですが、タイマーが鳴るとすぐに作業を中止し、次の仕事に移ります。

様々な制約を無視して理想の状態は何か思考する

納期までに達成可能かや影響範囲の大きさ等、全ての制約を無視して思考していました。
思考したことはタイムボックスを決めた上で必ず実験し、理想の状態が何か確認した上で現実解を見つける、というステップを踏んでいました。

テストを頻繁に回し、プログラムをコントロールする

テストを書き、コードを1行でもいじるとすぐにテストを回します。
修正→修正によってプログラムがどうなるのか言語化→テストを回してすぐに確かめる→修正...のサイクルを回していて、プログラムを完全にコントロールしていました。

書いたコードが自然言語に近い形で読める

書いていったコードがほぼ自然言語に近いコードなので、抜群に読みやすいです。
コメントも一切なく、読んでいて楽しいコードでした。

理解をすぐに言語化する

理解した内容を全て言語化するので、コードを書く前に今から何が起こるのかが毎回分かります。(コードを見て、ああこういう風に書くんだ、みたいな驚きが一度もない)
また、言語化された言葉は一つの解釈しかしようがないもので、理解にあやふやさが一切ありませんでした。

常人にも再現できるコーディングをする

何人か凄い成果を出されている方のプログラミングを見たことがあったのですが、自分が見た殆どの人は、頭でコードを組み立て、紙に少し整理した後に凄まじい勢いで実装をしている印象でした。
その姿には圧倒されて感動も覚えるのですが、全く真似できる気はしない雲の上の存在という印象でした...
しかし、今日一緒にペアプロした先輩のコーディングは全て真似しようと思えばできるもので、再現性がありました。
勿論努力は必要ですが、トレーニングで身につくものばかりなので、どうすれば先輩のようになれるのかの道筋が見えた気がします。

 

感想

また一緒にペアプロしたいなーと思いました。次にペアプロをする時は少しでも追い付けているように、努力を続けます。
最近は仕事でプログラミングが全然できていないこともあったのか、充実感を感じる幸せな時間を過ごせた金曜日でした!

整理

自分が悩んでいることの整理を改めてしたく、今悩んでいることと、悩みが生まれるまでのコンテキストを書いていきます。
なので、今日はかなり自分用のメモになります。

スタート

自分が配属されたチームは、属人性が極めて高いという問題を抱えていました。
組織風土的に、部署異動や人の入れ替えが比較的活発に行われるのですが、自分のチームについてはある方(以下Aさん)が常に在籍しており、Aさんなしではとてもチームが回らない、という状態が続いていました。*1
原因は多数あると言われていたのですが、主な原因として挙げられているのは、以下3つです。

  1. 高い専門性を求められる業務領域

  2. 改修&理解が難しい仕様やソースコード

  3. 新規参入者が中々定着しない

自分がチームに参入した当初は、1→2→3の順に問題意識が持たれていました。
3は若手の頑張りすぎ*2
2はAさんなら一瞬で改修できる(Aさん以外だと改修が全然できない)
ということがあり、やっぱり業務領域が難しすぎるのが属人性を促進しているよね、というロジックでした。
しかし、そんなチームに最初の転機が訪れます。

転機1 ~Aさんの異動~

社内で別チームが立ち上がり、Aさんは高いスキルを買われて、別チームへの異動が決まります。
Aさんが全部やった結果属人性が解消されない側面もあるから異動することはマイナスばかりじゃないだろう、プロダクトも安定稼働しているし...ということでした。
Aさんの代わりに、業務領域に対して知見があるシニアなメンバーが投入され、チームは再出発することになりますが、ここで第二の転機が訪れます。

転機2 ~障害が多発しチーム解体~

Aさんがいなくなった直後、既存バグが急に顕在化し、障害が多発します。
プロダクトがずっと安定稼働していたため、障害対応の経験がないメンバーたち(もちろん自分も)は混乱状態に陥ります。
追い討ちをかけるように、障害対応について社内外から厳しいプレッシャーを受け、動いていた案件開発と並行する形でバグ修正のスケジュールが埋め込まれ、メンバーは次第に疲弊していきます。
自分も精神的にきつくなり、最悪の形になる前にアラートを上げようと、上司の方に体調の異変が出始めていることを相談したのですが、相談した次の週に自分以外のチームメンバーがいきなり休職&退職し、体調がどうこう言ってられない状況になります。(自然消滅的な形でチームは解体)
取り残された自分は、チームが再組成されるまでの間、プロダクトを何とか存続させるべく必死に仕事をしました。
力不足で何度もダメかと思いましたが、同期を中心とした多数の励ましと運もあり、何とか乗り切ることができ、新規チームメンバーの追加にも目途がつきました。

社内の変化

自分たちのチームメンバーが離脱した頃、丁度自分たちのチームに限らず部署全体でメンバーの離脱が相次ぎました。
また、Aさんが異動後にプロダクトの開発スピードが大きく落ち込んだり、バグの修正に膨大な量の影響範囲調査が必要になったりして、最初に書いた問題意識が徐々に変化してきました。(新規参入者が中々定着しないことや、改修&理解が難しい仕様やソースコードに問題意識が置かれ始めました)

新しいチームメンバーを迎えるにあたって

新しいチームメンバーを迎えるにあたって、二度とメンバーに辛い想いをさせたくないと思った自分は、3つの決意をします。

  • 社内外からのプレッシャーを吸収するインターフェースとなり、チームメンバーには複雑な業務領域のキャッチアップに集中してもらうこと(不満を言われたら自分が受け止めて謝罪した上で、チームメンバーの努力を伝えること)
  • 絶対にチームメンバーを責めないこと
  • 自分の知識やスキルを惜しみなく伝え、チームの成長をサポートすること

ただし、これまでチームの一メンバーの立場でしか仕事をしたことがない自分にとっては、相当辛い環境になることが想定されたので、年度一杯までは耐えるけど、それ以降は自分を最優先にする(きつかったら転職でも休職でも好きなようにする)ことを条件につけました。

新チーム組成後~組成後2ヶ月

上記で決めたプレッシャーを吸収するインターフェイスとしての役割が想像の100倍きつかったですが、組成された新チームのメンバーが伸び伸びと働いているように見えて、(フラットに意見を言い合える, 知識の伝播が進む, 改善活動を率先して進める...)充実感がありました。
一部の人からは自分がプレッシャーを吸収していることに気が付いていただき、感謝のお言葉もいただけ、嬉しかったです。
ただ悩みもたくさんあり、特に以下の点は気になっていました。

  • チームメンバーが何をしているか分からないことが多く、チームの状況が不透明
  • チームメンバーから無責任な発言がちょいちょい出る
  • 上司から、自分が過保護になっているせいでチームの成長を阻害していると言われる

組成後3ヶ月~組成後4ヶ月

自分の力不足で、どうしても厳しいスケジュールで進めないといけない案件が出てきてしまい、いきなり苦境に立たされました...
しかし、チーム全員が一体となって開発を進め、TDDを初めて取り入れたりWIP制限など多数のチャレンジもできて、見事に期限内にリリースできました!
チーム内のふりかえりでもポジティブな意見がたくさん出て、順調にチームが成熟しているように感じました。

組成後4ヶ月~組成後半年(今)

順調そうに見えたのが一転、中々成果が出ないスプリントが続きます。
SBLが終わらずベロシティ0のスプリントが続いたり、個人行動(PBLやSBLにない仕事を率先してこなす...)が目立ち出すなど、不穏な症状が出始めます。
直近も中々悪い状態から抜け出せず、プロダクトに対して責任を持っていない態度をはっきりと表明されてしまうことがあり、自分の決意が悪い方向にチームを導いてしまっているんじゃないかと思い出しています。

この辺りからコミュニティ参加し出して、何かしらのヒントが掴めないか試行錯誤するようになりました。
沢山ヒントはもらえているのですが、実践することが中々できず、歯痒い毎日を送っています。。

*1:Aさんは社内でも一目置かれている絵に描いたような優秀な方で、自分にいつも圧倒的な力の差を見せてくれる方でした

*2:弊社若手は責任感がめちゃくちゃ強い。また、仕事のプライオリティが高く、成果を出すためにバリバリ残業します!みたいな体育会気質の人が多い

バランス感

"バランス感"について、自分の考えを整理してみます。

 

バランス感とは?

この記事において"バランス感"という言葉は以下の定義とします。
複数の解が存在する状況で複数の解を調整して、最適解を探し出す力

 

バランス感を養いたい理由

一言でいうと、成果をあげるために正しい判断をしたいからです。
ソフトウェア開発をしていると、何かを判断する必要があるタイミングが無数に出てきます。
簡単に判断できることは殆どないのに判断を誤ると大事故になる場面も多く、判断する瞬間はいつも胃が痛みます。。
どうしたら上手に判断できるのかということを整理していく上で、"バランス感"という概念に辿り着いたのですが、抽象度が高い概念で、具体的にはどうすれば養えるのかを考えるようになりました。

バランス感を養うためには

自分がやってきたことで、バランス感を養うことに貢献した手応えがあったことをシェアします。

判断に悩んだ時のことを記録に残して振り返る

どういう判断をどういう根拠でしたのか?何が判断を難しくさせていたのか?などを記録しておき、フィードバックが得られたタイミングで、自分が誤っていた部分を探します。
そうすると、自分が足りない知識や疎かにしがちな視点が見えるので、地道に課題を潰していくと、次第に最適解に辿り着くために必要な知識や視点が見えるようになってきました。

広い視点で意見を集める(考える)

なるべく広い視点で意見を集める(考える)ことを意識した結果、バランス感が養れてきた気がしました。
例) 技術者の視点, 営業の視点, PMの視点, お客様の視点, お客様のお客様の視点...

具体的に言うと、多数の意見を聞いた上で、腑に落ちた意見/腑に落ちなかった意見を集めます。
その後、腑に落ちた(落ちなかった)のはどういう根拠があったのか(足りなかったのか)?を考えて、意見を統合していきます。
そうすると、次第に意見の共通部分や論点が見えてきて、判断する上で外してはいけない点が見えてきます。

なお、コミュニティ活動への参加は、視点が確実に広がるのでお勧めです!
会社にはその会社の文化がどうしてもあるので視点が偏りがちですが、コミュニティには多種多様な経歴の持ち主の方々が集まっているため、普段は聞けない貴重な意見をたくさん聞くことができます。

フィードバックをなるべく早くもらうことを意識する

アジャイル開発の考え方と似ている所ですが、仮説がずれているかをなるべく早く検証できるとバランス感が養われやすいよね、という話です。
正しいバランス感はコンテキストによって変わるので、その時々に応じたバランス感を身に着けるために、なるべく早くフィードバックをもらえるような判断をすることが大事なのかな、と思っています。

1on1でやって効果があったことなかったこと(1on1してもらう側視点)

1on1してもらう側の視点で、1on1でやってみて良かったこと悪かったことを書いてみます。

 

はじめに

対象読者

1on1実施者(特に1on1してもらう側)

記事を書こうと思ったきっかけ

  • 1on1をしてもらう側(一般的には部下)のナレッジと比較して、1on1をする側(一般的には上司)視点のナレッジが少ない
  • 自身が1on1してもらう側の視点で、中々うまくいかずに苦労した経験がある

自身の1on1歴

3年間、隔週で30分の1on1をしてもらっています。*1
また、1~2年程度年次が下の方に対して、不定期に1on1をしてます。

やって効果があったこと

1on1で上司が何を求めているのか聞く

以下のイベントに参加して、1on1のプロの方々からいただいたアドバイスを実践してみた所、絶大な効果がありました。
career-update-org.connpass.com1on1の実施側としても、わざわざ時間を取る時点で何かしらの期待があるはずなので、その期待に沿った内容を話せると、1on1する側も前向きに参加してくれて、結果的に話が進みやすいのかな、と感じました。
※上記イベントを主催している1on1のコミュニティは、尾澤さんをはじめとした1on1の熟練者の方々が主催しているので、1on1で悩んだら是非参加してみるといいと思います!

自己紹介する

自己開示をすることで信頼関係を構築することで、以降の1on1をスムーズに進行できるのではないかと考えて、自己紹介しました。
自己開示することで信頼関係が構築できるという発想は、ジョハリの窓の考え方を参考にしています。
ジョハリの窓についてはググると色々記事が出てくると思いますが、自分が参考にしてた論文を一つ紹介

日体大リポジトリ


お互いの自己紹介は既に実施済みで、一緒に仕事をしてから1ヶ月程度の期間も経っていたので、盛り上がらないのではないかという不安を抱えていましたが、大いに盛り上がり、一気に信頼関係を築けた感覚がありました。

やったけど効果がなかったこと

次回までの宿題を作る

1on1を通してPDCAサイクルを回すことで、自身の成長に繋げようと考えていたのですが、あまり効果を感じられませんでした。
自分なりに考えた、上手くいかなかった理由は以下の2つです。

  • 2週間に1回という頻度では、宿題を設定した1on1~次回の1on1の間が長すぎるため、設定した宿題の意義が薄れたり、もっと優先度の高い課題が自分の中で見つかったりする。
  • 宿題に義務感を感じてしまい、宿題をこなすことに意識を向けがちになってしまう。(宿題をこなすことで何を達成したいのかやなぜ宿題を設定したのかを見失いがちだった)

1on1をする人からなるべく話を聞こうとする

1on1してもらう人の年次が上のため、少しでも上の人の経験やスキルを吸収しようと、なるべく話を聞こうとしていましたが、自分の感覚としては効果を実感できませんでした。
貴重な話が聞けて良かった一方、1on1を通して自身が見えていないことをフィードバックしてもらう機会が失われたのは、勿体なく感じました。

前回の1on1~のふりかえりをする

これは1on1に限らずふりかえり全般の課題ですが、過去の話に重きが置かれがちで、肝心の未来の行動に対する話があまりできませんでした。
前回の1on1~のふりかえりをするのは定番ネタで、悪いことでは全然ないですが、未来の行動に対する話に重きを置くようにアジェンダを汲んでタイムキープできると、より実りある1on1ができると思います。

*1:1on1の実施者は自分&自分の仕事を直接見てくれている上司(年次が6~7年程度上

ブログをはじめたきっかけ

このブログをなぜ始めたのかを書きます。

 

 

直接的なきっかけ

 

aki-m.hatenadiary.com

 

の記事に書いた通り、「スクラムガイド2020を読み解いてみよう」の回に参加したかったからです。
今回のイベントは参加メンバーが超豪華で、自分が知らない視点, 自分ができない考え方, 自分にない価値観...沢山の学びがあることを確信し、イベントの存在を知った瞬間に参加を決めました。
しかしイベントの存在を知ったのが遅く、枠は殆ど満席…
余っている枠を見た結果、自分の立場で参加できそうなのは、Twitterで実況することかブログを書く枠のどちらかしかないという結論になりました。
ブログは立ち上げる所からのスタートなので、ハードルはTwitter実況の方が低そうでしたが、会の間は全神経を皆が話している内容に傾けたかったので、思い切ってブログを立ち上げてまとめる事にしました。(参加メンバー的に高いレベルの議論が予想されたので、Twitterいじりながら片手間で聞ける自信はなかったですw)

 

間接的なきっかけ

オキザリスチームの存在

オキザリスチームとは?という方は以下の記事を是非! 

 

スクフェス札幌やスクフェス三河の講演でオキザリスの話を聞いたり行動を見たのですが、成長のスピードや出している成果のレベルがとにかく凄い。。
その源泉として、自分と比べ物にならない量のアウトプットがあることを知り、自分も学びを加速してアウトプットしたいな…と感じながらここ最近は過ごしていました。
オキザリスの人たちの成長速度にはまだまだ追い付けないと思いますが、ブログを立ち上げることで、少しでもオキザリスに近づけるのではないかと思いました。

コミュニティに貢献したい

最近の自分は各種コミュニティの方々から勇気をもらい、成長を後押ししてもらっていると感じています。
一方で、自分はコミュニティに対して何か貢献できているのかと言うと、今一つ実感が持てないというのが正直な所です。
そのため、貢献度を上げる方法がないか模索していました。
今回ブログを立ち上げることで、イベントの内容が文章という形で半永久的に残せたり、コミュニティを広げる手助けができるのでは、と思いました。

「スクラムガイド2020を読み解いてみよう」の会に参加してきた

ふりかえり実践会主催の、
retrospective.connpass.com
ブログ書くよ枠で参加してきたので、参加レポートを書きます。
※どうしても参加したかったのでブログ開設しました


 

イベント概要

名前の通り、スクラムガイド2020で改訂された部分を皆で話してみよう、という会です。
日本で唯一のレビューアだった江端さんも参加されるとのこともあり、一日で84人集まるイベントになりました。

 
スクラムガイド2020はこちら

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

 

イベントで出た話

前半戦 : 改訂後のスクラムガイドで気になった所をディスカッション

真のリーダーとは

スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。

スクラムガイド2020のP8にありますが、真のリーダーとは一体何か?という話を議論して、以下の話が出ました。*1

  • 怪しいSM(雑用だけやる/何もしないことが仕事だと考える)が多発したから、チームの結果に責任を持っていることを強調したかった
  • 幅広い層(特に経営者)に刺さるようにしたかった
  • 当初あったサーバントリーダーという定義だと、支援の要素が強い。支援だけで1人分の価値を出していることを証明するのは難しいので、サーバントリーダーという言葉を廃止したのではないか

また、スクラムマスター=リーダーとすると、リーダーという単語が役割を想起させて、チームメンバーがリーダーシップを発揮しにくくなるので、そもそもリーダーという単語を消した方がいいのでは?という話も出ました。

自己組織化->自己管理

理想とすべきスクラムチームが語られる時のキーワードだった自己組織化という単語が自己管理に代わったことについて各々が感じたことを議論しました。

  • 自己組織化という言葉が一般的でないので、分かりやすくしただけでは?
  • Self-organization が organization (会社でgiven) と敵対する聞こえ方になっている
  • チームが自己組織化するには、チームメンバーが自己管理できている必要があるので、まずは自己管理できていることから目指そう、というメッセージ性を感じた。
  • チームの話から個人の話への転換が強すぎる
  • 自己管理だと自分のことしか見えてないように聞こえる...
  • 大規模スクラムの文脈で、チームは組織に対して働きかける事も必要だから、チームで閉じた組織になっちゃだめだと訴えたかった
  • 自己管理する対象が、開発者だけではなくてスクラムチーム全体に広がったのが良かった
  • 個人はスクラムチームのために滅私奉公せよという誤解が周囲であったので、まず個人を蔑ろにしないようにという意味ではよかった
  • 自己組織を開発チームとスクラムチームのネストに掛けないで、自己管理を個人とチームに掛かるようにした
  • 自己組織化は自己管理を含むと思うので、範囲が限定されたように見える
  • 「自己組織化よりも自己管理」の書き方がアジャイルマニフェストっぽい。右を重視することにしたけど左も大事って伝えたかったのでは

等々の意見が上がりました。
分かりやすい言葉に変更されたってだけな気が個人的にはしてましたが、沢山の解釈や意見が聞けて楽しかったです。
特に、チーム全体が良くなるためにまずは個人が良くなるっていう考え方は面白い解釈で、新たな発見でした。

プロダクトゴール

スクラムガイド2020版で新たに追加されたプロダクトゴールという言葉について、皆さんの解釈を出し合いました。

  • お客様をいつまでにどうしたいKPIとかがプロダクトゴールに当たる
  • 「プロダクトゴール=リリース」のイメージを持った
  • 今まであったスプリントゴールはスプリントバックログをサマリしたものでしかなかったので、プロダクトが生み出す価値に意識を向けさせたくて生み出された言葉
  • スクラムガイド2020のアップデートセッションではプロダクトゴールをまともに説明している人はないかったようなので、あまり理解している人は少なそう(実装した人がセッションしていなかっただけかもしれない)
  • スクラムチームが近視眼的動きをしがちな点に問題意識が置かれて生み出された言葉
  • スクラム無計画だという誤解を防ぐための記載
  • 対外向けの説明責任の一つとしての単語
  • プロダクトとスプリントに対照性を持たせたくて生み出された言葉(ただし、プロダクトバックログはプロダクトゴールから生み出されてもスプリントバックログはスプリントゴールから生み出されることは殆どないので、対照性を持たせることに失敗してる)
POがPO以外に委任

2017年度版と比べて、POがPO以外の人に作業を委任していいことが分かりやすくなったのが良かったね、という話をしました。*2
また、プロダクトバックログ関係のことはPOが全部やらないといけない、みたいな思い込みが現場では根強いので、いい変更ではないかという話もありました。

その他
  • スプリントバックログの定義が分かりやすくなった
  • 「スプリントゴールはスプリントの唯一の目的である」という表現が強く感じた。(現場で唯一の目的じゃなくなった時、説明に困りそうだと感じた)
  • 全体的にすっきりした
  • 大分ビジネス寄りになった
  • 「計画」という言葉が誤ったイメージ(ガントチャートを描く)を持たせそう

などの話も出ていました。

後半戦 : 江端さんから聞くスクラムガイド2020の裏話

後半1時間は、江端さんからレビュー時の様子について沢山のお話を伺いました。

レビュー当日の雰囲気

Exper licenseを持ったトレーナーのみが招集されてオンラインで開催。
冒頭ではNDA的なものが厳格に締結された。*3
参加者は皆アクティブで、発言も多くチャットの流れも速かったそうです。

レビューのやり方

スクラムガイドの各項目ごとにグループを作り、グループ内でディスカッション。グループは定期的に移動していたようです。
Miroやスプレッドシートなどのツールを使って議論を整理し、最終的にスクラムガイドに変更を反映する方法でレビューを進めていました。(実際の様子を示した画像も見せてもらいました)

2020年度版を発行するにあたって掲げられたコンセプト

以下のようなコンセプトが一例として掲げられていたとのことです。 

  • IT業界でなく幅広い業界に適用可能なものとする
  • アーリーアダプターしか分からないような表現はやめる
  • あくまでもガイドなのでパーフェクト性厳密性は求めない
  • ビジネス要素を強くする
  • SOLIDなガイドにする。ある程度の誤解を招くのは割り切る
レビューに携わって良かったこと

KenとJeffから、スクラムとはこうあるべきだという熱意を感じられたことや、聞いたことのない文献や学術的な知識を提供してもらえた点では、参加して良かったと江端さんは話していました。

レビューに携わって大変だったこと

レビュー参加に当たっては勿論苦労話もありました。特に、

  • 23:00~7:00に会議が開催
  • 意見を出すと200~300人から袋叩きにされる。

は大変そうでした...

レビューに携わった江端さんの想い

1. ROIを意識できるプロダクトオーナーが日本でもっと増えて欲しい
2. スクラムの実施者(特にPO)は正しい責任感を持ってほしい
3. 日本と世界で差が広がってきていることに危機感がある
4. スクラムガイドの活用法

の4つについて、江端さんの想いを語って下さいました。 

 

1. ROIを意識できるプロダクトオーナーが日本でもっと増えて欲しい

経済を回していくようなイノベーティブなPOが日本では少ない。
日本のみならずアジア圏全体の課題でもあるため、今回のレビューでもPOの記述にROIに関する記述の追加を提案したが、却下された。*4

2. スクラムの実施者(特にPO)は正しい責任感を持ってほしい

プロダクトが炎上した時にどうにかしてリカバリーするのではなく、炎上しないことを目指すチームになって欲しい。
結果を出すんだという覚悟を持ってほしい。(スクラムだから遅延しても仕方ないよね、という空気を感じることがある)

3. 日本と世界で差が広がってきていることに危機感がある

スクラムが世界でも日本でも広がりを見せている一方、日本と世界では出す成果に明らかに差が生まれてきている。
先日開催されたスクフェス札幌(https://www.scrumfestsapporo.org/)をはじめ、最近日本でのコミュニティ参加を江端さんが増やしているのはこのためである。
日本人が悪いとかいう話ではなく、江端さんをはじめとするスクラムを普及させる人たちが、もっと上手く伝えていかないといけない、と思っている。

4. スクラムガイドの活用法

スクラムガイドはあくまでもガイドブックであり、ルールブックではない。
スクラムガイドを完全なものとして捉えるのは危険で、「スクラムガイドに書いてあるから~すべきだ」と考えてはいけない。常にどうすれば最も成果を出せるのかを考えてほしい。
ガイドなのだから、あくまでも指針として活用すべきで、ガイドに書かれていないこと(例えばスクラム以外の学問など)も積極的に取り入れていく姿勢を持って欲しい。

ガイドとのイメージとしては、観光のガイドブックをイメージすると分かりやすい。観光のガイドブックには、「観光の指針を決めるために、~するのがお薦めだよ」と書いてあるだけで、ガイドブック通りに観光することは有り得ないはず。
観光ガイドとスクラムガイドでガイドという言葉が持つイメージが変わってしまっているのは、おそらく皆がスクラムに熱中し過ぎているからだと思う。上手く伝えられるように、ガイドの発行者として努力を続けたい。

なお、ルールブック感が強くなっているのは否めない。ルールブック感を弱めようとすると、回りくどい表現が多くなりページ数が膨大になるので仕方ないと思っている。それに、観光ガイドにだって「~には注意!」みたいな言及はあるはず。
また、全く別の視点で、スクラムガイドの各章はトレーナーの一部しかレビューしていないので、レビューしたトレーナーの構成によって、記載粒度にばらつきが出ている(一部章についてはルールブック感が強くなっている)という事情もある。

今後スクラムはどうなっていくのか

今回の改訂で大分ビジネス寄りにシフトしたので、XPをはじめとしたスクラム以外のアジャイルとは距離が広がりそう。(江端さん個人としては仲良くして欲しいという希望はある)
また、スクラム実施者は未来よりも過去に比重を置きがちであるという課題が世界的にも認知されつつあるので、今後未来への意識を強くさせるような記述が増えていくかもしれない。

延長戦 : アフタートーク

レビューという言葉が持つ意味についての議論や、スクラムガイドをカルチャライズ/ローカライズできないかという議論、形と型の話(形無し→形作り→型作り→型持ち→型使い→型破り→形作り...)など、様々なトークが繰り広げられていました。
本編の話で大分ボリュームが大きくなってしまったので今回は割愛しますー

感想

自分が今回の会を通して一番得たかった、「プロダクトや組織を良くしたり仕事を楽にするために皆が何を大切にしているか」という観点で多数の発見があり、参加できて本当に良かったです。

ブログには書いてはいけないと言われましたが、リアルな裏話を幾つか聞けたのも良かったですw

楽しい会で学びも多かったので、今後開催されるふりかえり実践会のイベントにも参加してみようと思います!

*1:スクラムガイド2017版では、「スクラムマスターは、スクラムチームのサーバントリーダーである」と定義されていました

*2:2017年版では「上記の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある」と記載されていたのに対して、2020年度版では「上記の作業は、プロダクトオーナーが行うこともできるが、他の人に委任することもできる」に記載が変更されている

*3:具体的には、宗教的な表現に関する注意, 外部に公開していいことダメなこと, 常に互いへのリスペクトを態度で示すこと...

*4:「ROI意識していない人はPOに選定される訳がないのにお前は何を言っているんだ」と顔を真っ赤にして批判を食らったり、ROI意識できない人と働いているなんて可哀想すぎると同情を貰ってしまった...