プロダクトオーナーの考えるべきところ
プロダクトオーナー(PO)の考えるべきところ、もしくは「はまりがちな罠」について、いくつかのトピックを思いつくまま書き出してみました。悩めるPOさんの手助けになれば幸いです。
- 序盤戦、中盤戦、終盤戦の戦略
- 一番美味しいアイデアがでる可能性に備えるために
- 引き継ぎにはコストがかかるので人を追加すると遅くなる
- システムは利用者の数に従って情報が増えるので、リリース後が最も大変な時期になる
- システムはハーモニーなので、継ぎ足して別の人を追加すると繋がらない
あ、よければアギレルゴの認定スクラムプロダクトオーナー研修もご検討ください。著名な講師が通訳付きで教えてくれます。
1. 序盤戦、中盤戦、終盤戦の戦略
「序盤で基礎を作って、作るスピードが上がってきたら、重要なところを作り、最後はウリになるものを作りこんでリリースする。」一見、良さそうに見える戦略ですが、これは結構危うい計画になりがちです。ユーザーから見れば、ある程度理解したタイミングで、本当に欲しいものが提示される、というのは購買行動につながりやすいのですが、作り手側の戦略としてはうまくいきにくいのです。なぜかというと、序盤の基礎のところで、本当のウリは意識しておかないと、後付けでつけようとしてもうまく作れない、ということが起こるからです。
プロダクトオーナーとしては、顧客に対しても、開発者に対しても、同じようなストーリー戦略になってしまいがち、というのはわかるんですが、まず、作り手と顧客は別物であるという理解が重要です。作り手には完全情報を提示し、顧客には順を追ってストーリーを提示するように心がけましょう。開発者をびっくりさせても儲かりません。
これは『ユーザーストーリーマッピング』に出てくる画像ですが、横方向がユーザーの使う順序、縦がリリースの順序になっています。これがユーザーストーリーマッピングというもので、プロダクトの全体像を表します。ユーザーの使い方と、構築の仕方をリンクさせて一枚絵にしているところが重要なポイントです。
まず序盤戦の内部リリースでは、技術的にちゃんと動くものができることを確認し、中盤戦でその機能を改善し、終盤戦はリリースのために必要となる、運用面やセキュリティなど、細かなところを調整します。この終盤戦は意外とやることが多く、プロダクトオーナーから見ると「思ったほどスピードが出ない」と考える要因になりがちですが、(技術に詳しくないプロダクトオーナーの場合に特に)中盤のスピードを重視してしまって、終盤のタスクが膨大になってしまっている例をよく見ます。もっと開発者と話し合って、作り手の視点を学ぶ必要があるかもしれません。
現在では、競争がないソフトウェアというのはほとんどないので、同じリソースを投入するならば、賢く使う必要があるかと思います。やるべきことを見える化して、序盤は動くこと、中盤は役に立つこと、後半は問題が出ないことを確認する必要があるかなと思います。「自信をもってリリース可能か？」は作っている開発者にしか判断できません。一方で開発者も経験不足でわからないことも多いので、とにかく出して社会勉強するしかないケースも多々あります。
プロダクトオーナーはまずなによりも、全体戦略を開発者たちに示しておくべきです。そのうえで抜け漏れがないようにプロダクトバックログを整備し続けます。コンセプトだけでなく、周到な構築計画と、柔軟な対応、生き残るためには、すべてが必要になります。
2. 一番美味しいアイデアがでる可能性に備えるために
1番でちゃんと全体像をみて戦略を立てることをお勧めしておきながら、逆のことを言うようですが、実際に一番売れるアイデアが出てくるのは、顧客にフィードバックをもらってからであることは間違いないです。一番賢くなっているのは、時系列的には最後だからです。おそらく、今日思いついたアイデアよりも最良のものを明日思いつきます。ですので、私たちは常に変化に適応できるようにしたい。
そのためには、プロダクトバックログをクリアに運用する必要があります。その新しいアイデアを実現するためには何をあきらめなければいけないか。これがはっきりしていれば、常に新しいアイデアを最優先で実行するためのコストが分かります。一方で、新しいが大したことがないアイデアを優先するあまり、1番で出てきた後半戦をないがしろにして、リリースされるソフトウェアの品質を下げてしまうことになると、障害とクレームに苦しんで全然前に進めなくなるプロダクトが生まれてしまいます。実際、そういうプロジェクトをいくつも見てきました。(私はそういうの作ったことないけど)
早く動けるようにするためには、現状をちゃんと整理して、コードもきれいにしておく必要があります。
『ユーザーストーリーマッピング』より
3. 引き継ぎにはコストがかかるので人を追加すると遅くなる
これはブルックスの法則として有名な話ですが、人員の追加は、その人が活動できるようになるまでに時間がかかり、また、それを教えるためにチーム全体のスピードも一時的に落ちます。ですから、プロジェクトの終盤で人を追加するとか、遅いと思ったのでテコ入れのために人を増やす、というのは、実はもっと完成を遅くしてしまいます。
1.新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる。
2.人員の投下は、チーム内のコミュニケーションコストを増大させる。
3.タスクの分解可能性には限界がある。
人員の追加に意味がない、というつもりはありません。そこには教育コストがかかる、ということを認識して進める必要がある、ということです。チームが最も賢くなった後半であれば、最も上手に教育できることも間違いないと思います。そのコストを上手に配分していく必要があるでしょう。
以前、引継ぎについて、10年以上悩んだ結果、気が付いたことは「手順は引き継げるが、スキルは引き継げない」です。スキルを引き継ぐためには、作業の背景にある判断基準を学ぶ必要があり、すべてをドキュメント化することは難しい領域です。これは一緒に作業をすることで、長い時間をかけて引き継いでいくしかないかな、と思います。
4. システムは利用者の数に従って情報が増えるので、リリース後が最も大変な時期になる
従来、システムを作るというのは、完成してリリースに向けて作る、という印象だと思いますが、実際に最もユーザーが使うのはリリース後になります。長年プロダクト開発の分野で仕事をしましたが、一番情報量が増えるのは、実はリリース後なのです。ですので、使ってもらいながら、「もっと使ってもらうためには何が必要か」という情報を得ることがビジネス上とても重要なのです。
従来型のプロジェクトだと、リリースしたら人を減らす戦略をとってしまいがちだと思いますが、その結果、ほとんどの業務ソフトウェアが、利用者が使い始めた後に「全然なおせない」という状況に陥ります。これでは役に立ちません。しかも業務はかわっていくのに、ソフトウェアが追いつけないなんて、どこが「ソフト」なんでしょうか。
プロダクトの課金体系がライセンス販売にせよ、サブスクリプション契約にせよ、継続的に支払いを増やしていただくことが、ビジネスにとって有利であることは間違いありません。ですので、実際に使っていただいたお客様の意見を聞いて、もっと使い続けてもらうための施策をうつべきです。本気で使ってくれているお客様のクレームには一切のリップサービスがありません。ですので、こちらも本気で対応をして、信頼を積み上げることが、次の契約につながる、と考えてみましょう。
繰り返しになりますが、本当に大変なのは、リリース後なのです。継続的に問題を解決しない業者を信頼する顧客はいません。
5. システムはハーモニーなので、継ぎ足して別の人を追加すると繋がらない
クラウドベースのオープンシステムが一般的になり、うまく他者を利用することで素早く安くリリースできるようになりました。一方で、顧客から見れば、サービスしているのはあなた(の会社)です。これは運用にとってみれば非常に難しい問題を起こしがちです。「こんな問題が起きてるんですが」「いやうちが作って部分についてはお答えできません」これでは顧客に信頼されません。システム間が接続され、自分が作っていない部分が増えれば増えるほど(つまり効率が高まるほどに)、こうしたクレームがどんどん増える傾向にあります。
では、このクラウド時代に我々はどうするべきなんでしょうか。重要なのは、顧客の代わりになってちゃんと調べるエンジニアを育てておくことです。できることならば、顧客が困る前に、その問題が起きないように作りこみます。これは一朝一夕ではできません。連携するシステムが多くなればなるほど、学ぶべきことが増えていきます。そして、時間がかかります。米国Microsoftの河野通宗さんが、このように語ってくれました。
クラウドって、いろんなサービスの大きな集合体なので、自分のところを（ダウンさせずに）動かし続けるしかないんです。ほかのサービスが一時的にダウンしても、当たり前に動かします。ネットワークが切れたり、毎日どこかが壊れるんです。そういう中でも毎日動かしつづけるためには、テレメトリの運用、あとは、そういうのをあらかじめ全部考えた上での運用方法の確立というのは、絶対に必要です。
ある時点でなにかがちゃんと動いていても、次の週にはもう前提が変わっているんです。なので、完璧というのは世の中に存在しない。どうやってシステムを動かし続けるかには、答えはないんですけど、その中でやり続けることが、すごく楽しい。たぶんご理解していただけると思います。
内製化でエンジニアを育てる価値は、まさにここにあると思います。逆に、どれだけ詳しく見えても、ベンダーのエンジニアはその対象領域の教育しか受けられません。ですので、あなたの問題を解決できるのは、あなたと苦楽を共にしているエンジニアだけなのです。3番の引き継ぎのところでも書きましたが、急には育ちません。
業界には詳しいふりをする人がたくさんいて、困っていると甘い声ですり寄ってきますが、だいたい契約後に幻滅することになります。そんなに都合の良い話はないのだ...というのを学習するタイミングがプロダクトリリース直前だと、もう取り返しがつきません。
プロダクトオーナーは収益性の最後の砦として、ちゃんと責任を取っていくべきロールです。あなたの後ろに人はいないので、ちゃんと判断をしていく必要があります。判断を間違えば、プロダクトの収益性が低下し、チーム全体が危機に陥ります。永続的なものなど何もありませんが、プロダクトオーナーの見識と、戦略が成功のカギになることは間違いないところです。オープンに相談しながら、一つ一つプロダクト仮説を検証して、顧客からの信頼を積み上げましょう。
おわりに
いかがだったでしょうか。プロダクトオーナーの考えるべきところについて、少しケースを挙げてみました。全体の戦略については、繰り返しになりますが、こちらの本をお勧めしたいです。
技術プラクティスや戦術については、監修でお手伝いした本がもうすぐ出ます。チーム戦術から運用までカバーしているので、プロダクトオーナー(PO)にとっても良いガイドブックになると思います。
プロダクトについてはだいたい、馬田さんのスライドを見とけばいい気がします。
技術的負債 - 問題発見までの時間とリスクをビジネス側に説明する
常松さんの新著、アジャイルプラクティスガイドブックに、監修としてお手伝いさせていただきました。
本書には11本のコラムが掲載されているのですが、うち一本を私の方で書かせていただきました。技術プラクティスの説明のために技術的負債という用語を使う方は多いと思いますが、デプロイの自動化がどのようにメリットがあるのかを説明してみた、というコラムになります。
許可をいただき、こちらのブログにも掲載させていただくことになりました。校正中の原稿ですので最終稿は少し変わるかもしれませんが、ご賞味いただければ幸いです。
本原稿については、特別に角征典さん、大金慧さんのレビューをいただきました。ありがとうございました。もともと伝えたいことがだいぶ散漫だったのですが、多少読めるものになったとすれば、お二人のおかげです。
技術的負債 - 問題発見までの時間とリスクをビジネス側に説明する
技術プラクティスに関わるコストについて話していると、「開発者たちは認識しているが、ビジネス側に説明しにくい」という意見を聞くことがあります。まさにそういうケースで発明された用語が「技術的負債」です。経営者や財務担当者にとって、負債は必要な時にはとるべきリスクであり、一方で溜めてしまえば会社を危機にさらすものだと理解されています。この負債をメタファーとして使って、エンジニアが抱えている課題を説明しようとしました。例えば、「問題の発見までの時間がかかっている」ことは、現時点ではリスクにすぎませんが、緊急の障害が発生した場合には、そのビジネスを危機にさらすことになります。当面は問題ないように見えるかもしれないが、実は大きなリスクがあるということをビジネス側の人にも共有しておき、リスクを減らすための投資として技術プラクティスを調べたり、適用するコストをとることの共通理解を作りたい。アジャイル開発を作り上げてきた先達も、エンジニアでありながら、相手に伝わるようなうまい説明を編み出し、かかわっているビジネスの成功を目指してきました。
しかし、ただ「技術的負債があるから返済したい」と言っても、ビジネス側の人には伝わりません。具体的なエピソードにかみ砕いて伝える必要があります。一つの例として、問題が見つかってから、直すまでにかかる時間について、いくつかのケースを通じて考えてみます。
1.リリース前の手動テストに頼っている
初期にプロトタイプとして作ったアプリケーションが、よい評価を受けて本番に成長していく過程では、自動テストは後回しにしておき、自分で動かして確認た上で他の人に渡す、というケースがよくあります。自動テストができることよりも、新しい機能を早く客に見せたいと判断するケースはこれに当たります。リリースした後に問題が発見され、数週間前に作った部分のどこかにあるであろう原因を調べる必要が出てきます。報告者の勘違いで問題がない可能性も考慮に入れるべきですし、かなり広い範囲の推測を頭に描きながら、問題の理解に頭を使うことになります。これはストレスも高い作業です。そして、対応をリリースすると、さらにその変更によって同じような問題を埋め込んでしまうことすらありえます。サービスが正常に動いている状態に戻すには、リリース前の状態に戻す必要があります。もし、このタイミングでリリースしないといけない機能がある場合、かなり難しい判断を迫られることになります。
2. テストを自動化して、毎日ビルドとテストを行っている (デイリービルド)
以前は毎日ビルドを行うことをデイリービルド、夜間に行えばナイトリービルド、などと呼んでいました。ビルドを自動化して毎日自動的にチェックするようにすれば、翌日には問題が発見されることになります。ただし、テストケースの範囲内だけですが。少なくとも、ビルドできない、などの致命的な問題は発見できます。昨日行った作業のどこかに問題があったということはわかるため、まず一旦そのコミットを取り消して前日の「動いていた」状態に戻すことができます。一日分の作業を一時的に戻すだけなので、それほど大きなインパクトはない可能性があります。その上で、その後に行ったコミットを確認して、怪しいところを探り出していきます。
3.コミットをフックして、自動的にテストが走る（継続的インテグレーション）
コードの修正をメインブランチにプッシュすると、自動でテストが走るようにしておくことを、継続的インテグレーションといいます。開発者たちにとっては、作業完了ごとにさまざまなフィードバックが得られるようになります。それまでに「動いていたコード」と「パスしていたテスト」のいずれかが、「先ほどの作業」で動かなくなったということがわかります。原因を探すために検討すべき範囲は非常に狭くなります。製品を作り込んだ１０分後に問題が発見されたなら、まずはその１０分間にした作業を疑うだけでよいですし、その部分を一旦捨てることは容易でしょう。
アジャイル開発では「既知の不具合はない」状態を維持することを目指します。それは既知の問題に関するテストを自動化しておいて、人間はそれ以外の部分をちゃんと探索するようにしよう、ということです。「ゼロバグトレランス（Zero Bug Tolerance）」ともいいます。もちろん我々は全知全能ではないので未知の問題は発見できないわけですが、この状態をなるべく高い頻度で確認できる状況を作り、維持することで「次に問題が見つかったとき」の反応速度が向上し、障害対応時の心理的負荷が下がります。そして「今は深刻ではないが、いずれ大きな問題になるかもしれない懸念」について、早い段階で検討することができるようになります。心の余裕を持ちながら、検討を忘れない慎重さが生まれてきます。品質の悪いコードを抱えているチームほど、次に発生する問題に対する余力は少なくなり、しばしば明確に存在している問題にすら対応できません。
「それは理解しているものの、ビジネス側から継続的インテグレーションやテスト作成のための時間を許可してもらえない状況だ」という相談を受けたことがあります。こうしたときに「技術的負債」のアイデアを活用して、ビジネス側にもわかるように説明することができるかもしれません。以下のように説明してみるのはいかがでしょうか。
バグが少なく、問題点の修正が早いということは「アジリティ」すなわち「近い将来のビジネスの変化についていくためのスピード」を向上させることにつながります。技術プラクティスを自分たちの選択肢として使えるようにしていくことは、ビジネス価値を高めることにつながります。まだそうなっていないのは、これまで対応のコストをかけてこなかったからかもしれません。その部分を「技術的負債」として考えることで、未来への投資となることがわかります。もちろん、いきなり大きな時間をかけてシステム全体をカバーする自動テストを書くなんてできませんし、まずは目の前にある1 つの変更点から、自動テストを足がかりにしていきます。
具体例を使って説明することで、ビジネス側の人にもリスクを伝えることができます。技術的負債を解消することには、ビジネス的に価値があります。「なぜそんなこともわからないんだ！」口にしてしまう前に、一歩一歩説明する勇気を持ってみましょう。深刻な問題が起きてしまう前に、こうしたことを話す勇気を持っておきたいものです。今日からでも遅くはないはずです。
次の第３章では、こうしたビジネス環境を作るための具体的な方法として、継続的インテグレーションと継続的デリバリーについて説明します。
ド素人がポッドキャスト編集に Hindenburg PRO (ヒンデンバーグ/ヒンデンブルク) を使ったらやりたいことが楽にできた
ポッドキャスト(PodCast)の音声編集、なんか時間を無限に溶かしそうで、手を出していなかったんですが、以前出演した furoshiki_fm で、岩瀬さん (@iwashi86) がすごい頑張ってfukabori.fmを編集してる、という話に感化されたいっしーさん(@oturu333)が、最近、編集頑張り始めたそうで。ただ、Mac付属の無料の GarageBand だと編集の手間がたくさんかかるという話になり、ちょっと周辺をググって「Podcastのおすすめソフト」の記事をリサーチしたところ、サブスクの一部とか(Adobe Audition)、無料とか、デスクトップ音楽用の定番ソフト(Cubase)、メーカー自身がレビューしているもの(Cyberlink)といったものがのっているレビュー記事のなかで、共通して参照されているソフトに「Hindenburg Journalist PRO」(現在の製品名は Journalistが外れて単に Hindenburg PROらしい)というのが見つかり。特に理由もなく推されることもないことを考えると、これはもしかしていいソフトかもね。と思って調べました。
なお、元の音声素材はZencastrで録音した、話者ごとに独立した音声mp3ファイルです。
まず、Hindenburg PRO のビデオが勉強になった
日本語の記事が全然見つからず(ツェッペリン社の飛行船ヒンデンブルグ号の事故については学べた)、しかし英語の操作チュートリアルを見たら、なんかやりたいことができそう、ってことになりました。このビデオのこの辺です。英語のみですが、画面見とけばだいたいの操作が分かるかなと思います。Podcastホスティング会社が作っているみたいです。（そこでホスティングしている人は90日間無料クーポンがあるみたいです。ビデオの最後に出てきます。）
08:52 - How to import files into Hindenburg 10:34 - How to edit your audio files
youtu.be
基本操作はこっちのビデオもわかりやすいかも
やりたかったこと１ : 簡単なインポート
これはmp3ファイルをドラッグしてトラックに置くだけでした。途中で作業フォルダを変えると依存ファイルを探すのにちょっと戸惑うかもしれません。最初から場所決めるほうがいいかも。作業結果は Hindenburg のプロジェクトファイルに出力できるので、元のmp3ファイルと、出力結果の mp3ファイルは同じフォルダに出すようにして、Dropboxでバックアップ取るようにしてます。
やりたかったこと2 : 音量の標準化
トラックごとに収録音量が違ったりすると、バランスさせたいわけですが、これが一発でした。[Tools]-[Auto Level]。ちなみにこれだけ PRO版のみの機能でした。
試用版が1か月使えるのですが、試用中は[Manage My Acount]でPRO/Liteの切り替えが可能です。
PRO版は月額1479円で使えるのですが、Lite版は買い切り11431円のみらしいので、私はLiteを使うことはないかなーと思います。
やりたかったこと3 : 特定トラックのノイズ除去
特定のトラックで一時的にノイズが乗ってしまっているとき(マイクに触ったとか)、はその部分だけ選択して下げることができます。これが直感的で惚れたところです。（実際はちょっと使ってみると、オブジェクトの触り方にコツがあって、ちょっと慣れかなと思いますが、「下げたいところを下げる」という直感的なUIがよかったです。）
Windows版ではマウスの縦ホイールと横ホイールにも対応しているので、30分くらい作業したらかなり手になじんできました。CTRL-ZのUNDOもちゃんと効くので安心感があります。
同様にトラック全体の音を下げることもできるので、ミュージックと音量バランスを取りたいときも簡単でした。
やりたかったこと4 : 発言の衝突をずらす
収録中に、同時に話してしまって衝突するケースが起こりますが、これ、ちょっとずらしてあげると会話としてスムーズになったりします。これはマウスでドラッグしてずらせます。ただ、一トラックだけずらしてしまうと全部後ろがずれてしまいますので、まず全体で空白時間を作って(3トラック分をずらして空白を作る)、そして個別のトラックをずらします。
この例だと、収録時は完全に声が被ってしまっていたのですが、ずらすことで、いい感じに受け答えしたかのような流れを捏造できました。これはマジで使えます。聞きやすくなります。あと自分の変なリアクションとか、気持ち悪いとこ、いい感じに消せます。精神衛生上、非常によいですね、これ。
やりたかったこと5 : BGMをいい感じに繰り返す
音楽を勝手に繰り返す機能はないのですが、簡単にコピー＆ペーストができるので、あまり苦になりませんでした。あ、繰り返し機能探したらあるのかもしれませんが、chatGPTに聞いたらないって言われたので調べてません。(やり方を知ってる人がいたら教えてください。)
それどころか、話の盛り上がっているところでBGMをうまく繰り返したり、ちょうどBGMが切れるところで話に集中してもらったり、という工夫ができました。トークの最後にちゃんとBGMが終わるようにしたりできます。
初見、1時間ちょっとで40分くらいの番組をいい感じにできた。
ということで、初見でド素人の私が実時間の1.5倍くらいでいい感じにPodcastを編集できたので、これは便利だなーと思いました。講演録画のちょっとしたノイズ除去や失言の除去とかにも使えるのかも。
ほかのツールは使ったことがないので、いやこっちの方がいいよ、とかあればぜひ教えてほしいです。今回初めて編集した、ずぶの素人なもので...。
あと、Hindenburg PRO のもっと上手な使い方とかも、知ってたら教えてほしいです！
ここで編集したfuroshiki_fmは明日配信
編集した furoshiki_fm の番組は明日配信だそうです。お楽しみに―。
furoshiki.fm • A podcast on Spotify for Podcasters
(追記) 私が編集したPodcastが配信されましたー
スクラムフェス福岡で品川トラックをやってみた話です！
Women in Agile Tokyo 2023 ご参加ありがとうございました。
以前ブログで告知させていただいたこちらのカンファレンスを無事終えることができました。皆様ご参加ありがとうございました。
OST (Open Space Technology) 形式が初めてだった参加者の方も多かったにもかかわらず、とても上手に乗りこなして、楽しく価値のあるディスカッションをされていたように見えました。本当に良かったです。RSGTでもすっかり定番になったOSTですが、Women in Agile Tokyo では、約一時間の枠を4つとって、しっかりとした時間を使うことができたのも、よかったんじゃないかと思います。
すでにいくつかの素晴らしい報告を書いていただいています。ぜひ読んでみてください。Twitter の WIAJ ハッシュタグにも多く上がってくると思います。
基調講演瀬谷ルミ子さんのご紹介にかえてした話
基調講演の前のご紹介はなるべく簡単に済ませるようにしているのですが、今回はWomen in Agileの文脈とこのセッションをつなげる必要がありまして、やや長くお話してしまいました。下の分は準備にあたって書いたものです。まったく逸脱してしゃべっているのですが、参加されてない方へのご参考ということで、置いておきます。
Women in Agile の活動を始めたのは2021年の9月頃で、1年と4か月ほどになります。目に見える男女差別がない日本の、しかもIT業界で、どうして場所によっては、女性がまるでいないプロジェクトが発生するのか？なぜ、アジャイルコミュニティは比較的女性がやりやすそうなのか？なぜ、女性のSNSにだけ、気持ち悪いレスがついてしまうのか？もしかしたら無茶苦茶時間がかかることなのかもしれないけど、一つ一つ違和感を言葉にして、変えるためのアクションをとれないだろうか。変えられないにしても、心を病んでしまう人を減らせないだろうか。そんな思いでカンファレンスを始めることになりました。
2021年の9月には、もう一つ大きな事件がありました。アフガニスタンの米軍撤退です。瀬谷ルミ子さんとREALsの皆さんは、すぐさま活動を始められ、タリバン政権下で学業を禁じられ、命の危険にさらされた数多くの女性と男性を救ってこられました。途方もない努力だと思います。力を尽くしても救えない人たちも数多くいるでしょうし、根本的に政治を変えることも、きっと今はむつかしい。私たちはそれでも活動する瀬谷さんたちの道程や、ノウハウ、マインドセット、ガッツから学ぶものがたくさんあると感じました。今回、第一回のこのカンファレンスで瀬谷さんにお願いしたのは、そんな思いです。それぞれにきっと学び取るものがたくさんあると思います。ぜひOSTで議論しましょう。
あと、アドリブで以下の話をちょっと話しました。
日本の各業界がなぜ男女比がおかしいのか、っていう話を成田さんがしていて、学校での男女比是正の取り組みを30年ほど前に強制的にやったアメリカで、結果的にいま、40~50代以下のアカデミアの男女比に反映されてる論はなるほどと思った。人種マイノリティ対策も同じか。https://t.co/pAI9tAkSLf
— Yasunobu Kawaguchi (@kawaguti) February 16, 2023
とにかく初回はバットを短く持って振りぬいた！
今回のカンファレンスは 2019年の Agile Leadership Summit でのやり方を踏襲しました。エンタープライズアジャイル勉強会さんの軒をお借りしたのも同じです。またもや、こころよくご支援いただき、共同開催の形で一緒に作り上げていただいて感謝しております。また、多くの協賛コミュニティの皆さんにも名乗りを上げていただきました。サイトに掲載しておりますので、ぜひご覧くださいませ。
OST形式についても、1月のRSGTで「実はあれがはじめてのOSTだったんです」というお話もいくつか伺いまして、とてもうれしい思いでした。そこで出会った方々が今も何人も、コミュニティのコアにいらっしゃるので、きっと今回の Women in Agile Tokyo も、何人もの方の未来の扉を開けることになるんだろうなと、勝手に確信しております。
Home | Agile Leadership Summit 2019
一人一人丁寧に支援することで、未来が大きく変わる
基調講演で瀬谷さんからも話があったように、一人を救えば、その人がまた新しいことを学び、その人がまたほかの人を救って、新しい未来が開けていくものです。活動は常に一人から始まるものなので、その救う一人、その数が重要ではないかもしれません。今回のカンファレンスでも、「数を追うことはやめよう」と言ってきました。幸い、数が重要なスポンサーさんも今回はいませんし、スタッフや関係者の皆様にも、暖かくご理解いただいたように思います。全然人が来なくてもやるし、もしかすると、それでも来た数少ない人たちが、今後の活動の核になっていくのではないか？と思うところもありました。おそらく重要なのは熱意で、その人が現在持っているステータスや、学歴、スキル、影響力は、まずは横に置いて考えてよいだろうと思いました。
“何とかしようとしたが、スキルがないので無力感に苛まれている人。この地域を何とかしたいがスキルがない人。スキルがあれば鬼に金棒。自分たちを変えるのは自分だ、という意思がだいじ” #WIAJ https://t.co/3ckpJbSkRW
— Yasunobu Kawaguchi (@kawaguti) February 18, 2023
今回残念ながら体調不良などで参加を断念された方もいらっしゃいますし、様々なご都合で参加できなくなった方にも、お声をかけていただきました。本当にありがとうございます。今回取り組む課題は、30年以上、変わってこなかった部分もあります。ちょっとやそっとで根本解決するものではないと思いますが、それでもみんなでやれることを見つけてやっていくことで、30年必要なことが20年になったり、ちょっとだけ誰かが楽になったり、何かに気が付いて、違うことを始める人がいるかもしれません。決して焦らず、しっかりと場をつなげていければと思います。皆様ご参加、ご支援ありがとうございました。
Women in Agile 原因のわからない問題こそ難しい問題
このブログはスクラムギャザリング＆スクラムフェス Advent Calendar 2022 の12月16日のエントリです。ちょっと日付が変わってからの公開になってしまいましたが、UTCで考えれば全然セーフでした。気にしすぎました。
2月17日にWomen in Agile Japan 初めてのカンファレンスをやります。なんとかWebサイトを開設しまして、チケットの販売も開始いたしました。これからコミュニティへの声掛けもしていきますので、なにとぞご支援のほどをお願いいたします。
Women in Agile のいつもの活動についてはジェーンこと知花さんがふりかえってくれているのでこちらをぜひご覧ください。月に2-3回は勉強会や対話会、研修などを行ってきました。
IT業界での就業に関するジェンダーギャップの存在
さて、私たちWiAが解決したいと考えている問題はIT業界におけるジェンダーギャップ(男女間格差)です。Indeed社が3月の世界女性デーに合わせて、IT業界でのジェンダーギャップについて調査結果を報告してくれています。
詳細な傾向は記事を参照いただければと思いますが、ポイントだな、と思ったところはこちらです。
他の職種と比べてIT技術関連職の方が、育児と両立しやすいと思うかをたずねたところ、48.8%が「子供・子育てを理由にした休暇を申請しやすい」、46.0%が「子供・子育てを理由にした勤務時間の調整がしやすい」、41.5%が「産休・育休などの長期休暇から戻ってきても復職しやすい」「未就学児がいる場合、業務上適切な配慮をしてもらいやすい」と感じていることがわかりました。また、これらの考えには男女間でそれほど大きな差はみられませんでした。
IT業界で技術職で働いていると、お客さん回りが中心になる営業職や、医師や接客業など業務を行う現場が固定される職種に比べれば、リモートワークもしやすいことが多そうだし、時間の融通もききやすい傾向があるのかなと、なんとなく想像はできます。
1990年代ですと、理系学部、特に工学部に進学したい女子学生に対して「ほとんど女子はいない」「女子トイレがない」といった助言を先生からもらった、なんて逸話もあるほど、進学に関する男女差は大きかったかと思います。当時はまだ情報系学部が少なかったというのもあるかもしれません。ですが、最近は特にそうした話も聞かれなくなりましたし、情報系学部で女性がほとんどいない、という話を聞いたことはない気がします。
しかし一方で、この調査にもある通り、
● チームや部署の男女比について男性が6割以上（女性が4割以下）と回答した人が全体の73.2%にのぼる。11.3%が男女同割合、10.8%が女性の方が多いと回答。
という問題があります。女性が少なく、多くのチームでマイノリティの境遇にいることがわかります。
ジェンダーによって隔たれている、見える壁はすでになさそう
ではマイノリティである女性は不利益な待遇を受けているのでしょうか。プロジェクトマネージャーの団体であるPMI日本支部さんの方で、2014年から女性部会の活動が行われています。こちらで男性、女性双方に、アンケート調査をして、結果を公表いただいています。ありがとうございます！
こちらの調査で、少なくともプロジェクトマネージャーに関する職種につかれている方々の間では、ほとんど男女の間に昇進や評価の差はなく、目立った問題はなさそうだ、ということ見て取れます。そこにはっきりとした壁や問題はなさそうにみえます。差別的な待遇があるから、担い手がすくない、というわけではなさそうです。
これは裏返すと、なかなかむつかしい問題であるとも考えられます。課題が明らかであれば、それを解決すれば前に進むわけですが、この調査の通り、はっきりとした問題はなさそうです。
もしかすると女性の数が少ないこと自体、つまりマイノリティのむつかしさが多く存在するのかもしません。もしくはこの調査には出てこないような、小さな問題が、どこかに隠れているのかもしれません。小さな問題(バグ)が、社会全体に隠れているとするとなかなか厄介です。スクラムマスターのように一つ一つ障害を明らかにして、人々に対応を促していく必要があるのかもしれません。
変化には時間がかかる。ボトムアップの継続的な変化が必要
さて、まだまだ女性がマイノリティである日本の会社が少しずつ変わっていくには、どうしたらいいんでしょうか。先日、RSGTでもご登壇いただいているロッシェル・カップさんが対談されていて、企業のダイバーシティへの取り組みが進まない理由について話されていました。
ドゥルーズ「ダイバーシティ&インクルージョン（多様性と包摂、D&I）施策でも『取締役会に女性を入れよう』という人がいます。女性がいさえすれば『ダイバーシティを実現している』と。でもそれだけでは不十分です」
「例えば今、社内にいる妊娠中の女性が取締役会で影響力を発揮する立場になるまでには十数年かかります。それまで現場レベルで施策を打ち続けることが必要なのです。育児休業をとった女性が復帰したときに、育休前と同じ職場・同じ仕事でキャリアを積める環境を整えたり、子どもの世話をしやすい働き方を実現したりする。様々な視点から女性のキャリアにとって何が必要かを考えるべきです」
トップのイニシアチブだけでなく、ボトムアップで、継続的に活動していくことが必要ということです。このあたりは、Fearless Change で語られている変化のプロセスと共通するご意見かなと思います。
必要なのは「考えすぎじゃない？やってみれば？」って言ってくれる身近な人かもしれない
マイノリティの境遇にあるということは、何かをするときに多くの「前例のない何か」を進めなければならないハメに陥りがちです。前例にないような何かを進めるとき、最大の敵になるのが、実は、自分の不安な心(杞憂)だった、なんてことがよくあります。読者の方にも「あきらめてしまったけど、よく考えてみると、なぜあのとき自分の不安にまけてしまったんだろう」ってあとでふりかえった経験をお持ちの方も多いのではないかと思います。
もしかして、私たちの周りの人も、多くの人はそうなんじゃないでしょうか。実は今日、Women in Agileで雑談をしていて気が付いたことがあります。
これは私個人の経験になりますが、コミュニティ活動をしていると、そこで知り合った人たち、利害関係のない知り合いのみなさんに勇気づけられた経験がなんども思い浮かぶんです。考えてみれば、これって、とても不思議な体験です。偶然知り合ったけど、おそらくそのたった一つの偶然がなければ、赤の他人であったであろう人たちなのに、普段接している家族や同僚以上に、心強い後押しをもらえた経験が何度もあるんです。これはどういうことなんでしょうか。
もしかすると、その「因果関係の薄さ」こそが、私がコミュニティ活動や、他の人たちが知り合う活動を遠巻きに後押ししている原動力かもしれない、と気づきました。
不確実性の高い時代に必要なのは、「えー、そうかなぁ。考えすぎじゃない？やってみれば？」って言ってくれる身近な人かもしれない。同調圧力とかじゃなくて、一人だと耳を傾けてしまう暗闇の声を払しょくしてくれる、ただの人。ある意味、他人事だからこそできる論理的な返し。
— Yasunobu Kawaguchi (@kawaguti) December 16, 2022
「因果関係が薄い」からこそ、強い後押しをもらえることがあるし、そして、そんな「因果関係が薄い」人と出会えるなんてまさに奇跡じゃないですか。みなさんが、そうした奇跡のような出会いを引き寄せる後押しを、コミュニティは果たしていて、私は、そういう奇跡が多くの皆さんにいくつも起きることを、支援したいのかもしれません。
WiA の活動や、2月17日のカンファレンスで、ぜひそうした仲間(=奇跡的に出会った元"赤の他人")を、見つけ出していただければと思います。友達100人なんて目指す必要はないと思います。「カンファレンスで偶然、隣に座った」という、その小さな縁が、もしかしたら、あなたの10年後の未来を大きく変えるかもしれません。そんな可能性に思いを馳せると、とても素敵な機会に思えてくるんじゃないでしょうか。少なくとも私には、そんな風に見えています。
社会が変わるには時間がかかるし、とても多くの努力と偶然が必要いなると思います。でも、どうせ変わるなら、自分が引き寄せた偶然で、自分が少しでもハッピーな方向に変わっていってくれたらな、と思います。ぜひ、あなたのためだけではなく、みんなのために、一つの「あなたをハッピーにするかもしれない偶然」を探しに来ていただければなと、そんなことを思いました。少なくとも、一人が少しハッピーになれば、世界全体は、ちょっとハッピーになるわけですから。
RSGT2023の基調講演はWiAの支援者であるLyssa Adkinsさん
RSGT2023では、Women in Agile の世界的な活動を後押ししている Lyssa Adkins さんが基調講演してくれる予定です。彼女の著書である Coaching Agie Teams の翻訳も進んでいるので、楽しみ。アジャイルにコーチングを持ち込んだ第一人者で、毎回カンファレンスで満室になっていて、なかなか参加できないLyssaさんのセッションを日本で通訳付きで提供できるの最高です。オンラインでも配信予定ですので、ぜひご検討ください。Discordでわいわいしましょう！また期間中、個別にアジャイルコーチに相談できるCoaches' Clinic も開催されます。
Women in Agile にある Lyssaさんのポッドキャストシリーズを見つけました。
WiA Tokyo 基調講演は紛争解決・復興支援の第一人者瀬谷ルミ子さん
2月17日 の Women in Agile Tokyo カンファレンスの基調講演は、瀬谷ルミ子さんにお願いすることになりました。私にとっては、楽天テクノロジーカンファレンス2012、アジャイルリーダーシップサミット2019に続いてのご縁となりますが、毎回示唆に富むお話をいただいていて、特に前回のアジャイルリーダーシップサミットでいただいた、紛争地の復興支援における女性の役割のお話が、今回の活動のきっかけのひとつになっています。
なぜ女性が参画することで上がるかというと、女性は社会が不安定になったり、戦争になったりしたときに、あらゆるしわ寄せを受け被害に遭いやすい。そのため被害者の視点で「社会の変革のために何が必要か」、そして子どもとの結びつきという観点から「この和平プロセスは本当に次世代を安全に導くものなのか」と考えられるからです。ただ、実際に女性が世界の和平プロセスに参加したのは過去19年間でたったの9％。しかも、その参加が単なるお飾り、数合わせ、男性や他者の傀儡（かいらい）のような形だと「逆に成功率が下がる」といった調査結果も出ています。
そのため、瀬谷さんが理事長を務められているREALsでは、復興支援の枠組みの中に、現地の女性が入るように支援を試みているそうです。もちろん部族長や軍閥の幹部などは男性が中心なので、さまざまな手段を駆使して、一歩一歩、地域と、女性の支援を行っている話を聞けるのではないかと思います。ぜひ、私たち一人一人の活動との共通点を見出していただいて、明日への一歩のヒントをつかんでいただければと願っています。
アンチハラスメントポリシーへの逸脱に対する対応方針をまとめました
この記事は、スクラムギャザリング＆スクラムフェス Advent Calendar 2022 - Adventarの二日目の記事です。サッカーワールドカップでスペインに逆転勝利して今日は休みにしようと皆さんが盛り上がっているときに誰が読んでくれるのか不安ではありますが、記念に公開いたします。サッカーにちなんでハッカー文化の話も出てきます。
アドベントカレンダーなのに業務連絡っぽくなってしまって恐縮なのですが、最近ハラスメントポリシーへの対応についてみんなの思いを文章化する作業をやってましたので紹介させてくださーい。
ポリシー作ったのはいいんだけど、ポリシーの運用って実は地道に大変な作業だったりします
ルールは作っただけでは何も効力を発揮しなくて、関係者全員が理解して、遵守に向けて動くという多数の行為があって効果を発揮する。プロセス全体を見ると相当なハイコストだと思う。
— Yasunobu Kawaguchi (@kawaguti) December 1, 2022
なので、アジャイルの文化はルールも含めてコストを考えながらやるというのが定石かなーと思います。技術プラクティスであれば、Ruby on Rails が有名にしたCoC(設定より規約)とか、誰かアーキテクトが作る基準より、可読性の高いコードとテストを継続的にメンテナンスしてリファクタリングを繰り返して、次の変更(=ビジネス機会)に堪えるものにしておこうとか、そういう話をやるわけです。チームのプラクティスであれば、フォーカス(集中)を作るために、スプリントとかプロダクトバックログに集約して、作ってフィードバックを受けて、レトロスペクティブでプロセスを見直しましょうとか、やるわけです。なるべく楽に本質に向けて進めるようにしたいというハッカーの三大美徳(怠惰/無精・短気・傲慢)だったり、人々が一緒に何かをするときにはHRT(謙遜・尊敬・信頼)をベースにしよう、という考え方にそって、どうやって運営していくかという話に共通しているかなと思います。
そしてどんな高邁な理想がポリシーに具現化していても、運用というやつがあるわけです。実際にそのポリシーが効力を発揮して、役に立っていなければ、TDDの考え方をよくお分かりの方であれば、テストに失敗するわけです。まず失敗させることも重要だし、それに対応して常にグリーン(正常)を確認する作業が一番重要で、それがなければ改善しても価値がない(コストだけがかかる)。なので、アタックしていただくことは重要だし、それに対して我々は適切な運用を生み出していけるわけだと思うんです。
ということで、今回作りました声明は以下です(前置きが長くてすみませんでした)。
アンチハラスメントポリシーの逸脱に対する対応方針をまとめました
スクラムフェスやスクラムギャザリング東京ではということで、ハラスメント行為への関心を高め、関連する行為が行われないようにしたいとの思いで、オープニングトークでアンチハラスメントポリシーについてのお話をさせていただいております。
その中で、11月に行われたスクラムフェス札幌にて、ハラスメント行為の被害を受けている、というご報告をいただきまして、その対応を札幌実行委員の方で行いました。具体的には報告の方から詳しくご事情を聴き、また、どうしたらよいかを話し合うということをしています。また今回については直接ハラスメント行為の当事者(加害者側)の方にもコンタクトして、お話をさせていただきました。加害者側の方にハラスメントの認識はないと思われるので、本件は被害者側がそうとらえている、という事実をお伝えすることがまず解決や再発防止への一歩目になるのではないかと考えております。
こうした対応については、できる範囲で行っていきますので、ハラスメント行為を受けていると感じた方については、ぜひ実行委員に個別にご報告いただければ幸いです。
一方で、「実行委員から謝罪すべきだ」というご要望もいただきましたので、その点についての対応について話し合い、実行委員としての見解を明らかにしたのがこの文章です。
https://scrumgatheringtokyo.org/statement_for_our_action_to_anti-harrasment_policy_20221201.pdf
スクラムフェス札幌スタッフ、および、各地スクラムフェスとスクラムギャザリングの実行委員の方に回送し、ご意見をいただきながら文面を推敲して現在の形になりました。(詳細のケース内容については個人情報保護の観点から札幌スタッフのみにとどめています。)
謝罪については、基本的にお断りすることにしました。私が理解する限りで、以下ような意見があり、こうした結論に至っています。
- 実行委員およびスタッフに運用上の過失があったとは認めがたいこと。
- 「ともかく代表者が謝る」という行為ではアンチハラスメントの目標が達成できるとは思えないこと。
- (この点は単に実行委員の文化的背景に過ぎないので皆さんに同意を求めるものではないですが、) スクラムの重要な文化は、自己組織化・自己管理だと考えているので、それに照らしても、代表者等の謝罪、というのは適切な処置とは思えない。むしろ一般的には問題をうやむやにする行為に近いのではないだろうか、という気がかり。
今回のハラスメント行為のご報告について、一同、心を痛めております。また必要と考えられる対応も、実行委員の負担を考えながら、できる範囲で行ったつもりです。
報告者のプライバシー保護の観点から、個別の事象は公開しませんが、ポリシー運用に関する一般的な対応については議論を行い、各実行委員の代表者の方の同意をおおむねいただきました。
今後の健全なカンファレンスや議論の運営に向けて、皆様のご協力を何卒よろしくお願いいたします。
XP祭り2022 出版者様からいただいた見本誌・献本リスト
XP祭りでは毎年、出版者様より見本誌をいただき、これからアジャイルを始めたり、これから業界で活躍される若手の皆様に役立つ本をご紹介しております。こちらで本年ご協賛いただいた本のリストを掲示いたします。ご協賛誠にありがとうございます。
マイナビ出版さま
オライリー・ジャパンさま
日経BPさま
SBクリエイティブさま
翔泳社さま
以下の本は、5冊いただきました。
以下の本は、5冊いただきました。
オーム社さま
以下の本は、2冊いただきました。
以下の本は、2冊いただきました。
以下の本は、2冊いただきました。
以下の本は、2冊いただきました。
以下の本は、2冊いただきました。
以下の本は、2冊いただきました。
丸善出版さま
技術同人誌著者さま
こちらはコミュニティで出版された同人誌を二冊いただきました。
以上、大変ありがとうございます。こちらでご紹介の上、当日はこちらのリストを掲示しまして、会期終了時に、希望する参加者の方にプレゼントさせていただきます。
