品川アジャイルで使っている配信機材のリスト 2024年5月バージョン

品川アジャイルでは呼ばれたら各スクラムフェスにお邪魔して配信のお手伝いをしているのですが、お手伝いさせていただけることはうれしいものの、どちらかというと、あらゆるカンファレンスの運営の方に「配信することをあきらめてほしくない」と思ってやっています。

 

カンファレンスの配信において注意しているのは、だいたいこんな感じです。

  • 機材に詳しくない人でも運用できる
  • 一日中放っておいても動く安定性
  • 発表者が慣れているZoomと画面共有を使う
  • 発表者PCからHDMI接続する際のトラブルを避ける
  • そのままクラウドに録画録音して録画漏れを避ける (公開するかどうかは選択)
  • 専任のカメラ担当を置かない (活人)
  • 専用の機材を置く机を作らない (活スペース)
  • 会場に映っていない、音が出ないことでオンラインの異常を検知する (ポカヨケ)

通常の配信では、「詳しい人しか使えない機材は使わない」ようにしています。普通に「いま買える民生機材」を使って、「割と誰でもできるように」機材をまとめているつもりです。たまに本気出して徹底的に機材を入れてやってしまうことはありますが、それも多様性の一つにすぎません。

個人的には「配信は大変そうだからやめとこう」というカンファレンスが一つでも減ってくれたらいいな、という願いを持っています。ボク、そんなにたいへん大変じゃないよ、って品川のカエルも言ってます。

前回、ばやしさんの機材説明から時間がたちましたので、ここで機材リストを公開しておきます。
bayashimura.hateblo.jp

 

使っている配信機材のリスト

現時点で使っている機材のリストは以下の通りです。

 

以下、一つずつ説明していきます。購入できるリンクや、設定上の注意なども少し載せています。

 

タブレットスタンド

K&M ( ケーアンドエム ) / 19790 iPad タブレットホルダー

www.k-m.de

K&M (ケーニッヒ&マイヤー)はドイツのメーカーで、マイクスタンドや、そこに着けられる様々なアタッチメントを製造していて、その中にタブレットホルダーがあります。タブレットスタンドをAmazonとかで検索すると、大量のメーカーが出てきますが、継続的に購入することを考えると、ド定番のメーカーを選びたいものです。このホルダーはド定番のマイクスタンドにつけるタイプなので、現地に同タイプのスタンドがあれば借りてしまうこともできます(スタンドごと送るのでまあないんですけど)。

スタンド付きのタイプをサウンドハウスで購入しています。

このマイクスタンドに、小物置き用のテーブルをつけることがあります。電源タップをここに着けておいて、iPadとの距離を短くしたり、ケーブルに荷重がかからないように使っています。マイクや小型スピーカーを置くこともあります。(もともとマイク用だと思う。)

www.k-m.de

サウンドハウスのリンクを貼っておきます。

テーブルのほかにも、譜面台と指揮者用のテーブルアタッチメントなんかもあって、演奏者さんにはなじみ深いメーカーさんなのかもしれません。

 

音声入出力用iPadの構成

メインのiPadは音声入出力を扱います。Zoomはマイクの音が入力されているクライアントのカメラを主カメラとするので、この iPad のカメラ画像が参加者の画面のスピーカービューとして表示されます。ですので、音声入出力ですが、演台の前に置いて、登壇者をこのiPadのカメラで押さえるようにします。

画面側のカメラ(フロントカメラ)を登壇者に向けるようにすると、Center Stage 機能を利用して、登壇者が多少動いたり、複数名でも自動的にカメラに収めることができます。

ただし、会場のスクリーンなどが背景に入ると、そちらに映った人物を追いかけてしまうことがありますので、iPadを向ける方向には注意してください。スポットライトが当たる会場だと、その人型の影を追いかけてしまうこともありました。

youtu.be

iPad 第9世代

Apple 10.2インチ iPad 第9世代 WiFiモデル (2024/5/8 販売終了)

www.itmedia.co.jp

メインで使っているiPadは第9世代のWiFiモデルです。この世代から Center Stageが導入されました。Lightning 端子とアナログのヘッドホン端子を備えています。次項の iRig Pre2 はアナログのヘッドホン端子で接続します。

なお、次の第10世代からUSB-C搭載になり、アナログのヘッドホン端子が廃止されました。USB-Cタイプの iPadを使いたい場合は、後述の iRig Pro Quattro I/Oを利用します。

iPadにはさまざまな機能がつけられます。

  • Zoom アプリ
  • Discord アプリ
  • アナログ音声入出力
  • 広角カメラ + 自動で被写体を追う Center Stage
  • スピーカー
  • HDMI出力
  • バッテリー
  • WiFi経由でのインターネット接続

かつ初心者にもわかりやすいUIを持っているので、運用上はこれ一択かなと思っています。Apple ID の登録が必要なので、運用のために Apple IDを取得しています。10台までは同じApple IDで登録できるようです。新しい iPad を起動したときに、近くに既存のものがあれば、そこから設定をコピーしてセットアップできます。新品を箱から出してすぐ使えないので、そこはご注意を。家でセットアップしてから現場に持ち込みましょう。

 

iRig Pre 2 音声入出力用マイクプリアンプ

IK Multimedia iRig Pre 2 マイクインタフェースwww.ikmultimedia.com

これは、iPadのヘッドホン端子と、マイクのXLR端子をつなぐための機材です。マイクだけでなく、さまざまな機材とつなぐのに使っています。

  • Zoom の音声を、会場のスピーカーに流したい
  • 会場のマイクの音声を、Zoomに送り込みたい
  • 自前のスピーカーを持ち込んで、Zoomからの音声を出力したい
  • 自前のマイクを持ち込んで、Zoomに入力したい

設定と接続は以下の通りです。

  • タブレット/カメラアイコン : (本体についているステレオミニケーブル)-> iPad の ヘッドフォン端子。音声入出力用です。
  • GAINツマミ : マイク入力の音量調節です。Zoom に入る音声の音量を調節します。小さいと録画の音声も小さくなるので、少し大きめくらいがいいと思います。
  • OFF ON 48V : On にします。電源スイッチです。Onにすると正面のLEDが光ります(緑と赤が点灯します)。背面に単三乾電池を入れているのですが、電池が弱くなると黄色いLEDになります。48Vはマイク用のファンタム電源の出力ですが、私たちはコンデンサマイクは使わないので、使いません。
  • ヘッドフォンアイコン : 持ち込んだスピーカーや、会場のミキサー入力に渡します。Zoomの音声が出力されます。
  • Volume ツマミ : スピーカーへの出力音量の調節です。これもスピーカー側で調節できるので、絞りすぎないほうがいいと思います。
  • DIRECT : On にします。ダイレクトモニター機能です。(Off だとマイクの音声が出力されない)

電池運用上の注意 : 単三乾電池は予防的に一日一セット(2個)

背面に単三乾電池を二本入れます。ファンタム電源を使わなくても、本体動作に必要なようです。一日は持ちますが、私たちはカンファレンスの場合は、毎朝、新品の電池を入れるようにしています。

ヘッドフォン出力の注意1 : ステレオミニプラグからの変換

ヘッドフォン出力はステレオミニプラグです。Zoomからはモノラルで出力されるので、モノラルケーブルを使っておくのが安パイだと思います。スピーカーによっては片方からしか音が出ない、というトラブルを避けられます。

会場のスピーカーに渡す場合も、持ち込みのスピーカーの時も、ステレオ標準プラグ(TRSフォン)への変換が必要になることが多いです。

ヘッドフォン出力の注意2 : HDMIと共用しない

音声出力に使っているiPadに、同時にHDMI出力用のAVアダプターを刺すとHDMIに音声が出力されて、iRigからは音声が出なくなることがあるので注意です。

パソコンと違って、iPadのZoomアプリには、出力先のデバイスを選択する機能がないようなので、挿す順番か何かで自動選択されるのかなとみていますが、こういう手順で操作すると、確実に音声がこちらにいく、というような手順を発見できていません。

このため、二台のiPadで、音声入出力用と映像投影用(HDMI)に分けて運用しています。

マイク入力の注意 : 電流が大きいスタジオ機材との接続はアッテネーターを使う

会場のマイクの音声を入力する場合は、会場のミキサーの出力をXLR端子で出してもらうようお願いしています。この端子はかなり一般的なので、おそらく会場の担当さんでもわかると思います。会場のミキサーの出力はマイク出力とは違う電流の特性(強い)なので、アッテネーターという機材をあいだにかませて調整します(かませない場合はゲインを0に設定します)。

アッテネーターは強すぎる電流?電圧?に抵抗を入れて調整します。細かいことはわかりませんが、40dB、600Ω というタイプを使っています。

 

iRig Pro I/O Quattro  (USB-CモデルのiPadを使う場合)

IK Multimedia iRig Pro I/O Quattro 4 IN / 2 OUTのポータブル・オーディオMIDIインターフェース 

www.ikmultimedia.com

iPad の USB-C 端子と、複数台のマイク(XLR端子)をつなぐ機材です。第10世代iPadでは、アナログのヘッドホンジャックがなくなりましたので、USB-C経由でiRigとつなぐ必要があります。その際に、iPad本体への給電をするためには、この機材を使います。この機材は本体にACアダプタで給電でき、それを iPad の USB-C端子にも給電することができます。さらに iRig Pre 2 で必要だった単三乾電池も不要になります。

サウンドハウスでは現在取り扱いがないのですが、AmazonのIK Multimediaストアにはあるようです。

iRig Pro Quattro I/O - 4-input professional field recording interface and mixer より図を拝借します。

接続構成は以下の通りです。iRig Pre2 と基本的には同じことをしようとしています。

  • 12 (ヘッドフォン) -> (モノラルケーブル) -> モニタースピーカーの入力 (ステレオ標準プラグ / XLRマルチ )
  • 23(MIC/INST IN)-1 -> マイク1
  • 23(MIC/INST IN)-2 -> マイク2
  • 18(MIC/LINE IN)-1 -> マイク3
  • 18(MIC/LINE IN)-2 -> マイク4
  • 19(CHARGE 9V DC) -> 電源アダプタ
  • 22(USB HOST) -> (同梱の変換ケーブル) -> iPad USB-C / Lightning

各スイッチの設定は以下の通りです。

  • 2 (MIC) : Off (Onすると内蔵マイクが周辺音を拾うので注意)
  • 4 (MODE) : MONO (Stereoだと23, 18 のマイク端子がニコイチでステレオになるので注意)
  • 8 (DIRECT) : On (Off だとマイクの音声が出力されない)
  • 9 (LOOPBACK) : Off (On するとホストのZoomの出力が返される = ハウリング)
  • 10 (LIMITTER) : On (予防的。Onだとマイク入力のリミッタが効いて音が出なくなることも?)
  • 17 (48V) : Off / Off (SM58マイクはダイナミックなのでファンタム電源不要)
  • 20 (POWER) : On (リセットするときには使うかも)

 

自前のマイクとスピーカーを利用する場合の構成

会場に据え付けのマイクやスピーカーがない場合、もしくはあっても、接続が難しかったり、事前に試せない場合などは、自前でマイクとスピーカーを持ち込んで利用することがあります。30-40人くらいまでの会場であれば、この構成で十分と思います。もっと広い会場だったり、野外であったり、周りが騒がしい開放型の会場の場合は、もう少し大出力のスピーカーを用意する必要があるかもしれません。

Sure SM58 ダイナミックマイク

SHURE ( シュア ) / SM58 ボーカルマイクロホン

www.shure.com

この機材は定番のマイクということで、人間の声を収録しつつ、周辺の雑音をほとんど拾わないので、重要な機材になっています。これとZoomの組み合わせによって、かなり雑音のない音声がとれます。

サウンドハウスのリンクです。スイッチ付き、というのを中心に使ってますが、在庫によりけりです。

 

マイクケーブル XLR オス - メス

CLASSIC PRO ( クラシックプロ ) / MIX030 マイクケーブル 3m XLRキャノン

画像はサウンドハウスから拝借しています。

マイクからiRigに入力する場合は、オス - メスのタイプを選択します。色や長さが選べます。

マイク一本につき、ケーブルが一本必要なので、最近はマイクの箱にケーブルも同梱するようになりました。

 

モニタースピーカー

YAMAHA ( ヤマハ ) / MS101-4 パワードモニタースピーカー

jp.yamaha.com

会場で音声を出したいときはこのスピーカーを使っています。Zoomからの出力は基本的にモノラルなので、1台のみで使えるこのモデルを採用しています。

サウンドハウスのリンクはこちらです。

iRig の ヘッドホンアイコンの端子から、前出のモノラルケーブルを使ってこちらに入力します。

 

iRig Pro I/O Quattro で自前のマイク/スピーカーを使うケース

自前のマイク/スピーカーを使うケースで、複数人が登壇する場合、マイクを2本以上使いたい場合があります。その場合には iRig Pro I/O Quattro を使って以下のような構成になります。

この図では、USB-C接続の第10世代iPadで説明していますが、 iRig Pro I/O Quattro には Lightning への接続ケーブルも同梱されていますので、第9世代iPadでもほぼ同じ構成をとることができます。

iRig Pro I/O Quattro の接続構成や設定についてはすでに説明しましたのでここでは割愛します。

大きなミキサーを使わなくても4本までマイク入力できるのはかなり強力だと思います。

 

映像投影用iPadの構成

これまで説明してきた、音声を扱うiPadとは、別のiPadを利用します。

Zoomの画面出力を、HDMI端子経由で会場のプロジェクタに渡し、投影します。
iPad の電源アダプタからの給電(Lightning端子)をこちら経由でiPadに入れます。

音声を扱う iPad と共用すると、Zoomの音声出力がHDMIに行ってしまうことがあるため、iPadは音声用、映像用と分け、基本2台で運用しています。

従来の構成と大きく違うのは、登壇者は自前のパソコンをHDMIに接続しない、と言うことです。その代わり、WiFiを経由してZoomにアクセスしてもらい、画面共有をしてもらいます。

HDMI出力 - Lightningタイプ - 第9世代iPad

Apple Lightning - Digital AVアダプタ

www.apple.com

HDMI出力端子をもったアダプタです。会場のプロジェクタに出力するためのHDMIケーブルを接続します。

もう一つの穴はLightning端子で、電源アダプタからの電源供給に使います。

ちなみに、このアダプタはよく壊れます。以下のような症状で検知することが多いです。こうした場合は、諦めて新品に交換しています。

  • iPad側でアダプタを認識しなくなります。
  • 壊れる前に、まず給電(充電)ができなくなるという説もあります。iPad の画面内の電池アイコンが緑色に変わらず、配信中にバッテリーが減っていきます。

Apple純正でないHDMIアダプタも利用可能と思います。ただ、機種や相性によって変動するので、品川アジャイルでそろえる機材としては、バリエーションの少ないApple純正品に揃えています。

HDMI出力 - USB-C タイプ - 第10世代iPad ほか用

Apple USB-C Digital AV Multiportアダプタ

www.apple.com

USB-CタイプのiPadや、Macなどを使ってプロジェクタに投影する場合はこちらのタイプのアダプタを使います。講演をよく行う人が会場にいる場合は、お持ちの方もいるかもしれません。アダプタが足りない時など、参加者に助けを求めたことが何度かあります。

プロジェクターの投写のイラスト

発表者ディスプレイを使いたい場合

登壇者が「発表者ディスプレイ」を使いたい場合は、別途セカンドディスプレイや、ダミーのHDMIプラグを用いてセカンドディスプレイがあるように模倣し、その画面を画面共有することで、手元のパソコン画面は第一ディスプレイになり、発表者ディスプレイを表示することができます。これは、MacでもWindowsでも、KeynoteでもPowepointでも同じ対応を取ることが可能です。

ダミープラグについては、Amazonだと類似品がたくさんあると思いますので、少し高いかもしれませんが、実績のあるヨドバシカメラのリンクを置いておきます。

ただ、発表直前で「発表者ディスプレイはどう出すの?」と質問された場合は、対応をお断りする方が賢明かもしれません。

投影される画面が遅れてしまう場合は?

投影される画面は、登壇者が自前のパソコンからZoomに入って、画面共有した画像です。ネットワークの帯域が細い場合は、画面が遅れて更新されるように感じることがあります。

想定外のWiFiルーターにつながっていないか確認しましょう。

利用できるWiFiが細く、すぐにネットワーク構成を変更できない場合は、登壇者に画面の更新が遅れる旨を伝えて、うまく対応してもらいましょう。

 

WiFiルーター : できれば会場からLANを有線で

iPadを使う場合に、WiFiのネットワークが細いと、Zoomの応答性が低下して苦労します。会場によっては物理的なLANを貸してくれることがあるので、20Mbps以上出る場合は、基本的に借りて運用しています。

会場にWiFiがある場合はそちらを使うこともありますが、参加者がWiFiを使う場合には、たびたびWiFiが詰まる(帯域一杯利用される)ことを経験しているので、別回線を探すことにしています。

モバイルルーターを借りることもあります。ただし、会場によってはLTE/5Gの電波が入りにくいところがあるため、事前にチェックするといいでしょう。

www.kashimob.com

会場のWiFiが細く、LANも提供されず、ビルの鉄骨がしっかりしていて LTE/5G のモバイル回線も届きにくい場合は、申し訳ないですが、諦めます!

現場百遍 - 練習と確認が重要です

機材は以上です。ちょっと複雑な機材もありますが、どれも高くても5万円程度のものなので、レンタルではなく、購入でそろえています。逆に言うと家でも練習ができると思いますので、買ってみて、本番前に練習することをお勧めします。本番でも練習が大事です。

当日の設営でも、実際の利用シーンと同様のテストを行っておくのがよいとおもいます。画像については見たらわかるので発見しやすいのですが、音声は原因を探すのがやや困難なので、早めに問題を明らかにしておきます。

  • 会場からマイクで発声して、Zoom側で聞こえるか?
  • 会場からマイクで発声して、会場で聞こえるか?
  • Zoomからマイクで発声して、会場で聞こえるか?

RSGTであった事例だと、当日の電池入れ替え作業の際にiRigのGAINやVOLUMEツマミが下がってしまっていて、Zoomからの発声が会場に伝わらないトラブルがありました。休憩中に発見されたのですが、音声は事象を切り分けるためのテストが、一つ一つ切ってみるとかケーブルを抜いてみるといった探索になるため、時間がかかりますし、その間に配信もできません。その時は、その場での問題解決はあきらめました。

当日は時間がないことが多いですので、どうしても必要なことと、念のための問題解析や対応を、うまく判断して、できうるベストな状態に持っていきたいものです。

品川アジャイルは毎週水曜日の21時くらいから、スクラムフェスのDiscordの「#品川アジャイル」チャンネルで雑談していますので、ぜひ覗いてみてください。

インカムをつけてパソコンを使う人のイラスト(女性会社員)

 

 

AsianPLoPでアレグザンダー建築の盈進学園東野高等学校に訪問した

コロナ後リブート開催のAsianPLoPのエクスカージョンで、埼玉県入間市にある東野高校に行ってきた。米国の建築家であり、パターンランゲージという取り組みで、アジャイルの源流に大きな影響を与えたクリストファー・アレグザンダーが設計したことで、界隈では知らない人がいない場所だ。(ただし界隈はそんなに広くない気もする)

盈進学園東野高等学校は、ただ偶然に外国人の建築家を呼んで校舎を作ってもらったわけではなく、まず先生方が移転にあたって理想的な学舎を考えるという試みが2年あった上で、実現できる建築家を探して『オレゴン大学の実験』に辿り着き、偶然の伝手で、中埜先生が軽い気持ちで誘ってみるところから実現してしまったらしい。中埜先生がアメリカ留学で身につけた楽天的にトライする文化も、先生方の熱意も常務理事さんのビジョンも地域の協力もゼネコンさんの妥協も、全てが組み合わさってそこに結実してた。完璧はないけど、40年近く経ってもいまだに現役生に愛されるキャンパスは半端ない。

それを誇らしく説明してくれた当時を知る先生も素敵だし、そこに注目し続けて縁を紡いだ井庭先生始めパターンコミュニティの人たちも、何より当時の苦労をはにかみながら、でも誇らしく語る中埜先生も素敵だと思った。パターンと原寸設計と模型が繰り返し更新され、アレグザンダーが米国に帰っても作られ続けたし、重要なところは確認しながら進められていた。施主の、といってもオーナーではなく教鞭を取られる先生方の建築家へのリスペクト。それを作ったのはアレグザンダーからのしつこい全員インタビューだった。1986年前後の奇跡をもう一つ知った。

アレグザンダーに確認して追加した武道館のウォールクッションや、木枠から大判のガラスに変わっても守られ続ける意匠、当時に込められた一つ一つの工夫、一つ一つ全部違う教室。建物に込められた情報量がまるで違った。同じものを量産しない。多様性を楽しむ。でも共通性やシンプルさを尊ぶ。エゴレス。

自由で心理的安全性に富んだ現役生の皆さんの反応も素敵だった。珍しいであろう外国人の訪問客に自分から飛び込んでいく、先生の助言とかじゃない反応が、ああこの人たちは普段からこのように信頼されて日々を暮らしているんだな、と感じられた。建物以上にハートに心打たれた訪問でした。

建物はみんなのもので、未来に使っていく人たち自身のものにしなければいけないという、強い理想が、そのために現実との折り合いで理想と違う点が出たとしても、全体としては強く異彩と魅力を放ち、それが決して良い立地とは言えない私立学校の経営を多少以上に「成り立たせている」と感じた。

校舎裏の林は保護者の皆さんが小川復活を試行錯誤しておられた。雨水の調整池を兼ねる中央の人工池に流入させ、池の水の水質改善を目指しているのだそうだ。この人工池は、一度水を抜いて掃除したら大きな鯉が何十匹も出てきたらしい。

 

f:id:wayaguchi:20240303014353j:image

この外門は守衛さんが常駐する場所。通路を抜けるとさらに正門がある。
f:id:wayaguchi:20240303014510j:imagef:id:wayaguchi:20240303014413j:image
f:id:wayaguchi:20240303014444j:image

門を入ってすぐ右が大講堂。卒業式の準備がされていた。
f:id:wayaguchi:20240303014422j:imagef:id:wayaguchi:20240303014438j:image

教室は交差並行。互い違いに並行して二列に並んでいる。中央は中庭で木が植えられている。校長先生がそこを通ると学生たちがキャーキャー言ってた。人気者。もしかしたら、いじられてるのかもだけど、心理的安全性が無茶苦茶高い。
f:id:wayaguchi:20240303014526j:imagef:id:wayaguchi:20240303014533j:image

教室をつなぐ渡り廊下。雨が降り込むので不評な面もあるそう。でも開いていることが重要というのがアレグザンダーの意見。
f:id:wayaguchi:20240303014305j:imagef:id:wayaguchi:20240303014448j:image

窓を通して隣の教室が見える。この景色の中で毎日を過ごすのが羨ましい。
f:id:wayaguchi:20240303014520j:image

教室の床ももちろん木造。
f:id:wayaguchi:20240303014454j:image

教室の後ろにロッカールーム(サンルーム)への入り口がある
f:id:wayaguchi:20240303014314j:image

小割りの窓。現在は大判の窓ガラスに小割りのフレームをつけているが、当初は木のフレームに小割りのガラスを嵌め込んだクラシカルな窓だった。
f:id:wayaguchi:20240303014340j:image

教室のロッカールーム(サンルーム)は窓があって生徒たちが溜まって話ができる小部屋になっている。
f:id:wayaguchi:20240303014432j:image

教室は全て二面採光。両側が窓になっている。6x6=36名定員は当時としては少人数。
f:id:wayaguchi:20240303014513j:image
f:id:wayaguchi:20240303014350j:imagef:id:wayaguchi:20240303014419j:image

池は現在少し淀んでいて、水を引きこんで綺麗にするプロジェクトをPTA主導で行われているということだった。この日(土曜日)も作業されていた。
f:id:wayaguchi:20240303014317j:imagef:id:wayaguchi:20240303014301j:image
f:id:wayaguchi:20240303014441j:image
30x30cmの木材の柱は、奈良の仏閣建築の職人さんに依頼。アレグザンダーは土地の技術で作ることを重んじた。しかし職人さんもこの太さは初めてやったという。縦に裂け目が入っているが構造上は全く問題ないらしい。鉄の杭を入れているが、職人さんは鉄を入れると弱くなるのでやりたくなかったとか
f:id:wayaguchi:20240303014347j:imagef:id:wayaguchi:20240303014504j:imagef:id:wayaguchi:20240303014311j:image

各教室は二階建てで2教室ずつの独立した建物。2階は独立した階段で直接入れる。エンブレムは建物ごとに全て違う
f:id:wayaguchi:20240303014523j:image
f:id:wayaguchi:20240303014406j:imagef:id:wayaguchi:20240303014333j:imagef:id:wayaguchi:20240303014343j:image

図書館の入り口。もともと短大まで作る計画があり、大きめに作られた。蔵書数は二万冊以上。
f:id:wayaguchi:20240303014357j:imagef:id:wayaguchi:20240303014337j:imagef:id:wayaguchi:20240303014542j:image

武道場の小割りの窓はオリジナルの木製フレーム。壁のクッションは、安全上アレグザンダー帰国後に追加。色を合わせている。アレグザンダーに追加についての相談をしたら、使う人たちが手直しすることで建物が完成していくという返事だったそう。
f:id:wayaguchi:20240303014536j:imagef:id:wayaguchi:20240303014327j:image

中庭と教室の間の通路。ちょうどよい幅と置き石。単純な線がなくて、自然と情報量が多い。天気が良くてよかった。

f:id:wayaguchi:20240303014403j:image

食堂(Future Vision Base) から池と校舎を望む。木の枝が自然に張り出している下を歩く。正面右が体育館。

f:id:wayaguchi:20240303014426j:imagef:id:wayaguchi:20240303014400j:imagef:id:wayaguchi:20240303014500j:image

10代の小部屋。10代ではないジェダイマスターたちも吸い込まれてたのでジェダイの小部屋かもしれない。

f:id:wayaguchi:20240303014530j:image
f:id:wayaguchi:20240303014409j:imagef:id:wayaguchi:20240303014321j:image

調整池は雨水を逃す機能のもので中埜先生たちが容量計算したそうだが、アレグザンダーの水と川へのこだわりでもある。先生方は運動場を広く取りたいというが、アレグザンダーは人が自然と集まる憩いの場所にこだわった。
f:id:wayaguchi:20240303014435j:imagef:id:wayaguchi:20240303014330j:image

特徴的な正門。外から入ってくると門から急に風景が広がる。中埜先生によると門の位置は最初に決まったという。理由は「よくわからないがここしかないと、みんなが思った」
f:id:wayaguchi:20240303014416j:image
f:id:wayaguchi:20240303014507j:imagef:id:wayaguchi:20240303014324j:imagef:id:wayaguchi:20240303014539j:imagef:id:wayaguchi:20240303014429j:imagef:id:wayaguchi:20240303014517j:imagef:id:wayaguchi:20240303014308j:image

大講堂の柱は地元川越の黒漆喰。当時は伝統技能が存続の危機になってて、全体を請け負えるなら安くやる、という条件だったらしい。その後、伝統技能も復活したそう。落ち着きがありながらチャーミングな特徴的な意匠はアレグザンダーによる。
f:id:wayaguchi:20240303014457j:image
f:id:wayaguchi:20240303014451j:image

スクラムフェスとRSGTで脱予算経営をやってみている話

このエントリーは、Regional Scrum Gathering Tokyo & Scrum Fest Advent Calendar 2023 の 12月13日の記事として書きました。本日はすでに12月21日です。遅れてすみません。

 

脱予算経営に出会った

2012年にAgile 2012のキーノートで脱予算経営に出会いました。そのあと、当時日本語で訳されていた本を二冊ほど読みました。後から出ている方が読みやすかったです。と思ったらキーノートスピーカーはそちらの本の方でした。当時の理解は、予算を使わない代わりにキャッシュフローの透明化をして、各部門の裁量になるべく任せる、というかんじでした。やろうと思ったらできそうだけど、部署間の信頼がないとできなさそうなのと、大きな会社だと、そんなに役員同士が仲良くないというか、仲はいいのかもしれないけど競争させられてたりするので、普段の会議は割と攻防戦になっちゃうよなーと思ってました。

kawaguti.hateblo.jp

 

2022年にもう一度脱予算経営に出会う

2022年に Joe Justice さんのトレーニングで、テスラ社が脱予算経営を実施している話を聞きまして、当時のセッションがビデオで出ていたので、内容を聞き直して、日本語でセッションをしました。テスラ社は給料が時給制で均一で、リーダーは特に偉いわけではなくそのロールをこなしていて、ただ技術進歩のためにみんな働いて、ストックオプションをもらって後日の資産形成をしている、ということでした。雑な理解ですが、ああ、確かにそうすれば、お互いの削りあいは不要になって、みんなで前を向けるかもね、と思いました。

 

speakerdeck.com

www.youtube.com

 

脱予算経営の12原則を訳した

合わせて、脱予算経営を推進するBBRTという団体が出している12の原則を訳してみました。アジャイルを学んで作ったわけではないのに、すごくアジャイルとの共通性が高いと感じました。現代のマネジメントの「よい原則」というものが変わってきたことをそれぞれが感じて、偶然にして一定していたと言うことかなと思います。Agile 2012 のキーノートになっているくらいなので、そう感じている人が多数いるのでしょうね。

kawaguti.hateblo.jp

 

リーダーシップ原則

  1. 目的 - 大胆で崇高な目的のために人々を巻き込み、奮起させる。短期的な財務目標ではなく
  2. 価値 - 共有された価値観と適切な判断によって経営する。細かいルールや規則ではなく。
  3. 透明性 - 自律的な規制、イノベーション、学習、コントロールのために情報をオープンにする。それを制限しない。
  4. 組織 - 強い帰属意識を育み、責任あるチームを組織する。階級的管理・官僚主義排除する。
  5. 自律性 - 人々を信頼し、自由に行動させる。もしそれを乱用する人がいても(それ以外の)全員を罰することはしない。
  6. 顧客 - 全員の仕事を顧客ニーズと結びつける。利益相反回避する

マネジメントプロセス

  1. リズム - ビジネスリズムやイベントに合わせて、ダイナミックにマネジメントプロセスを組織化する。年次の決算に合わせるだけでなく。
  2. 目標 - 方向性と、野心的・相対的な目標を設定する。固定の、カスケード(上位から分解した)  目標を避ける。
  3. 計画と予想 - 計画や予測を、無駄のない公平なプロセスにする。硬直的で社内政治的なエクササイズではなく。
  4. リソース配賦 - コスト意識を醸成し、必要なリソースを提供する。年次の詳細な予算配分を行わない。
  5. パフォーマンス評価 - 学習と能力開発のために、パフォーマンスを総合的に評価し、ピア(1対1の)フィードバックを行う。計測のみでなく、報酬決定のためだけでなく。
  6. 報酬 - 競争ではなく、ともに成功することに報いる。固定のパフォーマンス契約に対してではなく

 

スクラムフェスとRSGTの運営でやってみた

これをどこかの企業でやってみるのはなかなかハードル高いかなと思っていたのですが、ちょうど私が代表理事をやっている「一般社団法人スクラムギャザリング東京実行委員会」は、全国各地でスクラムフェスが立ち上がってきたのも支援しており、それぞれは独立した実行をしているものの、会計・資金リスクは助け合いたいなーと言うことで進めているので、ここでやってみよう、と考えてきたのですが、ちょうど年度が替わる2023年7月から、やってみることにしました。

 

カンファレンスのキャッシュフロー

カンファレンスの会計はだいたいこんな感じです。

kawaguti.hateblo.jp

これを、私たちが「票読み表」と呼んでいるExcelシートで管理してきました。スポンサー数や参加者数は読めないので、それを予想しながら、準備期間を1-2か月単位で区切って、その中でなるべく収益のバランスを取っていこうという考え方です。ある項目を、売れたらやるし、売れなければやらないと考えてシミュレーションしていきます。

期間収支は、ざっくり書くとこんな感じかなと思います。まだ確定していないお金は、昨年実績を使って仮にアテておきます(昨日の天気)。

  1. 序盤 (セッション確定前)
    収入: 最初から乗ってくれるスポンサー、アーリーバードチケット
    支出: 会場確保、キーノートスピーカー予算
    (最低限の開催にかかる費用をカバーする)
  2. 中盤 (セッション確定後)
    収入: 通常のチケット
    支出: ノベルティ、配信やZoomなどのコスト
    (チケットの売れ行きに合わせて参加者還元を考える)
  3. 終盤 (開催一か月以内くらい)
    収入: 終盤でのチケットやスポンサー
    支出: 会場で使う物品の配信やZoomなどのコスト、お弁当
       付箋などの少額備品類
    (余裕があればできる納期で参加者還元をする)

当初はスポンサーもチケット収入もゼロですが、昨年と同じだとどうか、50%ならどうか、100%ならどうか、などは件数のところを書き換えれば簡単にシミュレーションできるわけです。これで継続的に無理のない運営を考えます。

 

そして今回、これを、月単位での集計にして、全国で行われるスクラムフェスを横に並べて月単位で集計表を作りました。

やったのはこれだけです。

これで、各カンファレンスでの月額収支と、全体での残額が月単位で把握できるようになりました。実際にどのカンファレンスがどのようにお金を使ったのは、各カンファレンスの集計表で明らかです。

 

ポイントは見える化と相互扶助

ポイントはなるべくちゃんと使ってほしいというところなのと、お互いの助け合いを引き出すところです。赤字になれば他のカンファレンスから借りることになりますし、黒字なら他のカンファレンスを助けることになります。

ここで足を引っ張りあうかどうかは、実際はマネジメントの問題ではなく、日々のお互いのコミュニケーションの問題なのだと思います。そして、私達のカンファレンスはボランティアで、給料は出ていませんので、お互いに格差も競争もありません。一年を通してマイナスだといずれ破綻しますが、それも一年くらいなら特に問題ありません。やり方をみんなで考えることができると信じています。

ですので、私は代表理事ではありますが、「こういう経費使っていいですか?」というような問い合わせも承認もしていません。(以前はありましたが基本すべてYesと答えてました。) すべて各地の実行委員の皆さんが自律的に検討していただいています。
私たちは会計の専門家でもないですし、予算を仕切るマネージャーを置いているわけではないですが、全員ボランティアで、使えるお金をうまいこと再分配して、何とか運営できてるかなーというのが今のところの感触です。

実験を始めたばかりなので、今後どうなるかはわかりませんが、良かったら、RSGTで話し合えればと思っております。よろしくお願いいたします。

confengine.com

 

ジェンダー平等を考える Women in Agile。この一年で学んだこと

このエントリーは、Regional Scrum Gathering Tokyo & Scrum Fest Advent Calendar 2023 の 12月6日の記事として書きました。

日本で最初のWomen in Agile カンファレンスをやりました

今年2月に、日本で初めての Women in Agile のカンファレンスを行いました。

kawaguti.hateblo.jp

エンタープライズアジャイル勉強会さんに共催の形をとっていただき、何とかリアル会場で一回目の場が作れたな、というところが嬉しかったです。参加された皆さんのOSTでの闊達な議論が、この場の必要性を強調していたと思います。

まず第一歩は、女性が発表する場所を自分たちで作る

Women in Agile の発起人の Jamie は第一回のAgile Conferenceに参加して、「いつか私も、あの人たちのように登壇したい」と思って、Lyssa Adkins に相談したそうです。女性がはじめて発表しやすいような場所を提案して作ればいい、ということになり、Women in Agile の活動が始まりました。それ以来、さまざままなカンファレンスで、Launching New Voices というセッションを作って、10分枠を複数用意して、初めて国際カンファレンスで発表する女性たちをサポートしてきました。この写真は10月のアムステルダムでのGlobal Scrum Gatheing でのセッションのものですが、この日も3名の新しいグローバススピーカーが生まれました。

Global Scrum Gathering Amsterdam 2023 での Women in Agile セッション

私たちも日本で、まずは Women in Agile Tokyo で公募枠でのセッション提案を受け付けていこうと思います。幸い公募の仕組みは Scrum Gathering や Scrum Fest でいつもつかっていますので、いつも通りのセッションプロポーザルの仕組みを提供できると思います。そしてグローバルへの飛躍もサポートできたらいいですね。

実は世界どこでも苦労している。日本以上に

8月にオンラインで行われた Local Organizer ミーティングに参加しました。そこで日本以外の各国の人たちと、活動や悩みを共有しあったのですが、カンファレンスを始めるのが大変なものなので、なかなか始められないのだ、という意見をいくつか聞きました。一方で、ー私たちは今年、スクラムギャザリングやスクラムフェスの経験や知見、サポートを活かし、エンタープライズアジャイル勉強会の支援も得て、第一回のカンファレンスを成功させることができました。これにあたっては RSGT2023 で来日した Lyssa Adkinsさんの後押しもいただいています。

これはとっても恵まれていることだと認識しました。放っておいても勝手に動き始めるようなムーブメントになっているわけではないですが、少なくとも私たちが動けば動いた分だけ世界は動く。いろんな人が手助けしてくれる。こんな恵まれてるコミュニティは世界でもそんなに多いわけじゃない。私たちは「この指と〜まれ!」の指を上げ続けることが大事。それを押し留めに来るような社会的な力がかからない日本社会、素晴らしい。指を上げる腕力とカロリーをちゃんと培えばいい。言ってみればそれだけの話でした。

Lyssaさんは、人の資質を男性的(Masculine)と女性的(Feminine)に分解した例を出していました。これは男女関わらずどちらの指向性も持っていて、性差ではないと注釈をつけてます。競争的でゴール指向なのが男性的、協調的で関係性指向なのが女性的。「うまくいく」「解決する」というのを活動の目標にすると、「うまくいかないものはやっても仕方ない」と短絡的に答えを出しがちになりますが、それはおそらくここでいう男性的指向に引っ張られてるかなと気付かされました。しかし、私たちの前には人がいて、続いている営みがある。全てが繋がっていて、澱みはあるかもしれないけど、リセットはできない。地道に話しながらよりよい状態を一歩ずつ考えていく取り組みにも意味がある。傷を舐め合ってるわけじゃなくて、ちゃんと観察して、理解をしようとする。現在を壊さずベターを考える。ここでいう女性的指向というのは、コミュニティで私たちがずっと目指してきたこととも符合するような気がします。俺が俺が、ではなく、No Blame(非難しない)。うまくいかない時も、苛立つのではなく、ちゃんと悲しむ。

Lyssa Adkins "The Agilists’ Emerging Superpower and Our Planetary Challenge" (日本語字幕つき) - YouTube

米国のコンピュータ科学系大学での女性比率はむしろ下がってしまった

今年の Agile 2023 カンファレンスでは、Agile Together というセッションが行われました。これは主に、Women in Agile(性別の多様性) と Agile in Color (人種の多様性) の2つの活動を中心に、ダイバーシティ&エクイティを実現していこうという取り組みでした。その中で、興味深い話がありました。米国のコンピュータ系の大学での女性比率の話です。1985年には半々くらいだったそうなのですが、数字は忘れてしまいましたが、近年は大きく女性比率が下がってしまったのだそうです。米国ではBlack Lives Matter などの活動が盛り上がる一方で、ジェンダーの多様性についてはむしろ逆行してしまっている部分もあるそうです。ちょうどカンファレンスが行われていたフロリダ州でも、性の多様性に反対する法案を知事が通していることもニュースになっていました。

注目されないことをやり続ける。信頼を培い、社会を変えていく

2月のWomen in Agile Tokyoでは瀬谷ルミ子さんに基調講演をいただき、アフガニスタンの脱出支援の話をしていただきました。タリバンが実権を握った一昨年の秋は、アフガニスタンからの脱出に関するニュースでもちきりでした。しかし、そのあと、ウクライナ侵攻が起きると、国内外のニュースはそちらが中心になりました。しかし、アフガニスタンの問題がなくなったわけではないのです。瀬谷さんたちは引き続き、クラウドファンディングなどを通じて状況を報告し、支援を集めて脱出支援を継続しています。

私たちも、Women in Agile の活動や、ジェンダーギャップの解消に向けて、注目されてない時期であろうと、無理なく継続的に活動し続ける必要性を認識しました。問題がなくなったわけではないですし、単に慣れただけということになれば、ギャップが社会に受け入れられ、定着してしまうことになります。

瀬谷さんのお話で印象に残ったのが、支援地域でも女性の活動、エンパワーメントに力を入れていること。安定した地域を作るためには、復興プログラムに女性が入ることが重要だそうです。女性の比率が高い方が平和維持・復興プログラムが3倍ほど長持ちするという国連のデータがある、というようなことをおっしゃっていたかと思います。そのために有力者(主にシニア世代の男性)の協力をうまく引き出す重要性を話されてました。

Lyssa Adkins さんの RSGT2023 キーノートにみんなで字幕をつけました

Women in Agileの有志で、Lyssa Adkinsさんの基調講演に字幕を付けました。現代がこれまでと違う、連続的で偏在的で指数関数的な変化の時代を迎えていること、アジャイルがそこに役立つことをわかりやすく教えてくれています。私はもう擦り切れるほど見ているのですが、いろんな方にもお勧めしています。

Lyssa Adkins "The Agilists’ Emerging Superpower and Our Planetary Challenge" (日本語字幕つき) - YouTube

マイノリティ平等を実現するためには、マジョリティの力が必要

第一回のWomen in Agile Tokyo では、40%ほどは男性の方にご参加いただきました。ジェンダーギャップを解消するためには、マイノリティである女性だけでなく、現在のマジョリティである男性の協力や、知識のアップデートが不可欠です。そうしたことに問題意識のある多くの方々に参加いただき、今後私たちができそうなことを議論していければと考えています。

ジェンダーギャップを形成しているのは、誰かの悪意でも偏見でもなく、ちょっとした理解不足やコミュニケーション不足なのではないかと考えています。ひとつひとつの小さな違和感を表明し、そこに働くフォースを考え、緩和や解消に向けた一手を打っていく。まさにスクラムでいつも行っているようなことが、この問題にも対応可能なのではないかと考えています。

目指したいのは、みんなで勝てる社会。アジャイルコミュニティの力を活かして

私たちは長らくアジャイルコミュニティ、スクラムコミュニティで活動をしてきました。ここでは普段ジェンダーギャップを感じることがあまりないのが実情です。アジャイルスクラムは、そこで活動する一人一人とコミュニケーションをとることを重視します。相手を「Javaプログラマー」などの属性で考えることはほとんどありません。スクラムのチームは基本的に片手ほどの人数で構成されます。ですので、全員と密に話ができる。これがおそらく、私たちの属するコミュニティでジェンダーギャップを感じることが少ない理由ではないかという仮説を持っています。そして、Women in Agile の活動は、スクラムコミュニティであればできることを、もう少し広げていく、という面もあるのかなと考えています。コミュニティのみなさまのご支援をぜひいただければと考えています。ぜひ一緒に考えていきましょう。

開催趣意書はこちらです。現在スポンサーを募集しております。ぜひご検討お願いいたします。サイト公開はもう少々お待ちくださいませ。

docs.google.com

職場で周りを巻き込んで参加するRSGT2024

このエントリーは、Regional Scrum Gathering Tokyo & Scrum Fest Advent Calendar 2023 の 12月5日の記事として書きました。

コロナ禍からの回復にともなってオンサイト(現地)参加が人気に

RSGTでは、近年コロナ禍からの回復に伴って、現地でのオンサイト参加のニーズが高まっております。2020年1月のコロナ前最後のカンファレンスでは、チケットが瞬時に売り切れてしまうことが問題になっておりましたが、その後2021年より増床し、席数を増やしているのですが、チケットの入手の困難さが高まってきています。

実行委員会としては、会場の増床を含め、持続的開催のための対策を持続的に検討していく方向ですが、当面できる対策も行っていきたいと考えています。

コロナ後は全セッション配信しています

RSGTでは、2021年のコロナ後初のカンファレンスから、全セッションをオンライン配信し、オンライン登壇も可能にしています。会場も継続的に確保しつつも、第n波や緊急事態宣言などが発生した場合、いつでも自主的にオンラインに切り替えていただけるような体制をとってきました。その結果、2021年は半数以上の方がオンラインを選択され、会場は閑散としていたのは記憶に新しいところです。ほぼすべてのセッションは後日Youtubeに公開され、自由に観ることができます。

https://youtube.com/@scrumtokyo

bayashimura.hateblo.jp

オンラインの「廊下」としてDiscordも盛り上がるようになりました。多くの方が積極的にDiscord上で新しいつながりを作ろうとしたり、新しい試みを楽しもうと努力された結果と思います。ありがとうございます。夜中の3時までDiscordで毎日話すようになったのはこのころからです(早く寝てください)。

オンライン参加はDiscordの活用がカギ!

はじめてオンライン参加される方は、ぜひDiscordのテキストチャンネルもチェックしてください。現地の人も、オンラインの人も多くの人がDiscordチャンネルにアクセスして、登壇者の話に反応しているのを見ていただけると思います。また、Discordにはボイスチャンネルもありますので、セッションがない時間帯などはふらりと参加して、ラジオのように交わされる会話を聞いたり、思い切って声をかけてみていただければと思います。



ギャザリング(実践者の集まり)を楽しむために

徐々にコロナの状況も改善し、企業でもオンサイト参加について問題がない、という判断がされるようになった結果、徐々にオンサイトの人出が増えてきています。「オンサイトで参加したい」「懇親会で新しいつながりを作りたい」「普段なかなか会えない旧知の人と久しぶりに語り合いたい」というニーズはまさに「ギャザリング」の大事な目的ですので、一方的に講演を聞くだけでなく、実務者同士のつながりを生かしていただいていて、場づくりを支援している私たちスタッフとしても非常にうれしく感じています。

Lyssa Adkins "The Agilists’ Emerging Superpower and Our Planetary Challenge" (日本語字幕つき) - YouTube

職場で周りを巻き込んで参加するRSGT2024をやってみていただきたい

また、一昨日以下の情報を公開いたしました。

会社の中で、アジャイルの普及や仲間づくりをされている皆さんにとって、周りを巻き込みながら会議室で一緒に観るなんて機会が作れたらいいな、というご意見をいただいて、この取り組みを始めました。

一つの参考になる例は、XP祭りでの食べログさんの取り組みです。

XP祭りに集まったメンバーで、オンラインでの参加申込をしたのですが、
「せっかくなら現地参加したかった」というメンバーの声があり、
リモート参加と現地参加、両方の良い所を実現できる参加の形がないか、TDD道場破りの参加メンバーで考えました。

tech-blog.tabelog.com

適正な利用範囲についてぜひ議論に参加してください

有償でオンラインチケットを買っていただいているカンファレンスですので、どのあたりまでの同時視聴であればフェアなのか(買った方に不公平感がないのか)、Discordチャンネルの中で議論をしています。ぜひ、議論への参加をお願いいたします。

うちの会社ではこんなことをやってみようと思います!みたいなアイデアや実行宣言も、ぜひDiscordの中でしていただければと考えています。

そうした意見や実施状況をみながら、来年のチケットの販売方法も見直していければいいのかなー、と話しています。まずはフィードバックとか、どれくらいニーズがありそうなのか、データを集められればと思います。ぜひ参加のご表明や実施後のレポートなど、ご協力いただければ幸いです。

Lyssa Adkins "The Agilists’ Emerging Superpower and Our Planetary Challenge" (日本語字幕つき) - YouTube



プロダクトオーナーの考えるべきところ

プロダクトオーナー(PO)の考えるべきところ、もしくは「はまりがちな罠」について、いくつかのトピックを思いつくまま書き出してみました。悩めるPOさんの手助けになれば幸いです。

  1. 序盤戦、中盤戦、終盤戦の戦略
  2. 一番美味しいアイデアがでる可能性に備えるために
  3. 引き継ぎにはコストがかかるので人を追加すると遅くなる
  4. システムは利用者の数に従って情報が増えるので、リリース後が最も大変な時期になる
  5. システムはハーモニーなので、継ぎ足して別の人を追加すると繋がらない

あ、よければアギレルゴの認定スクラムプロダクトオーナー研修もご検討ください。著名な講師が通訳付きで教えてくれます。

1. 序盤戦、中盤戦、終盤戦の戦略

「序盤で基礎を作って、作るスピードが上がってきたら、重要なところを作り、最後はウリになるものを作りこんでリリースする。」一見、良さそうに見える戦略ですが、これは結構危うい計画になりがちです。ユーザーから見れば、ある程度理解したタイミングで、本当に欲しいものが提示される、というのは購買行動につながりやすいのですが、作り手側の戦略としてはうまくいきにくいのです。なぜかというと、序盤の基礎のところで、本当のウリは意識しておかないと、後付けでつけようとしてもうまく作れない、ということが起こるからです。

プロダクトオーナーとしては、顧客に対しても、開発者に対しても、同じようなストーリー戦略になってしまいがち、というのはわかるんですが、まず、作り手と顧客は別物であるという理解が重要です。作り手には完全情報を提示し、顧客には順を追ってストーリーを提示するように心がけましょう。開発者をびっくりさせても儲かりません。

これは『ユーザーストーリーマッピング』に出てくる画像ですが、横方向がユーザーの使う順序、縦がリリースの順序になっています。これがユーザーストーリーマッピングというもので、プロダクトの全体像を表します。ユーザーの使い方と、構築の仕方をリンクさせて一枚絵にしているところが重要なポイントです。

まず序盤戦の内部リリースでは、技術的にちゃんと動くものができることを確認し、中盤戦でその機能を改善し、終盤戦はリリースのために必要となる、運用面やセキュリティなど、細かなところを調整します。この終盤戦は意外とやることが多く、プロダクトオーナーから見ると「思ったほどスピードが出ない」と考える要因になりがちですが、(技術に詳しくないプロダクトオーナーの場合に特に)中盤のスピードを重視してしまって、終盤のタスクが膨大になってしまっている例をよく見ます。もっと開発者と話し合って、作り手の視点を学ぶ必要があるかもしれません。

現在では、競争がないソフトウェアというのはほとんどないので、同じリソースを投入するならば、賢く使う必要があるかと思います。やるべきことを見える化して、序盤は動くこと、中盤は役に立つこと、後半は問題が出ないことを確認する必要があるかなと思います。「自信をもってリリース可能か?」は作っている開発者にしか判断できません。一方で開発者も経験不足でわからないことも多いので、とにかく出して社会勉強するしかないケースも多々あります。

プロダクトオーナーはまずなによりも、全体戦略を開発者たちに示しておくべきです。そのうえで抜け漏れがないようにプロダクトバックログを整備し続けます。コンセプトだけでなく、周到な構築計画と、柔軟な対応、生き残るためには、すべてが必要になります。

speakerdeck.com

2. 一番美味しいアイデアがでる可能性に備えるために

1番でちゃんと全体像をみて戦略を立てることをお勧めしておきながら、逆のことを言うようですが、実際に一番売れるアイデアが出てくるのは、顧客にフィードバックをもらってからであることは間違いないです。一番賢くなっているのは、時系列的には最後だからです。おそらく、今日思いついたアイデアよりも最良のものを明日思いつきます。ですので、私たちは常に変化に適応できるようにしたい。

そのためには、プロダクトバックログをクリアに運用する必要があります。その新しいアイデアを実現するためには何をあきらめなければいけないか。これがはっきりしていれば、常に新しいアイデアを最優先で実行するためのコストが分かります。一方で、新しいが大したことがないアイデアを優先するあまり、1番で出てきた後半戦をないがしろにして、リリースされるソフトウェアの品質を下げてしまうことになると、障害とクレームに苦しんで全然前に進めなくなるプロダクトが生まれてしまいます。実際、そういうプロジェクトをいくつも見てきました。(私はそういうの作ったことないけど)

早く動けるようにするためには、現状をちゃんと整理して、コードもきれいにしておく必要があります。

ユーザーストーリーマッピング』より

3. 引き継ぎにはコストがかかるので人を追加すると遅くなる

これはブルックスの法則として有名な話ですが、人員の追加は、その人が活動できるようになるまでに時間がかかり、また、それを教えるためにチーム全体のスピードも一時的に落ちます。ですから、プロジェクトの終盤で人を追加するとか、遅いと思ったのでテコ入れのために人を増やす、というのは、実はもっと完成を遅くしてしまいます。

1.新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる。
2.人員の投下は、チーム内のコミュニケーションコストを増大させる。
3.タスクの分解可能性には限界がある。

人員の追加に意味がない、というつもりはありません。そこには教育コストがかかる、ということを認識して進める必要がある、ということです。チームが最も賢くなった後半であれば、最も上手に教育できることも間違いないと思います。そのコストを上手に配分していく必要があるでしょう。

以前、引継ぎについて、10年以上悩んだ結果、気が付いたことは「手順は引き継げるが、スキルは引き継げない」です。スキルを引き継ぐためには、作業の背景にある判断基準を学ぶ必要があり、すべてをドキュメント化することは難しい領域です。これは一緒に作業をすることで、長い時間をかけて引き継いでいくしかないかな、と思います。

4. システムは利用者の数に従って情報が増えるので、リリース後が最も大変な時期になる

従来、システムを作るというのは、完成してリリースに向けて作る、という印象だと思いますが、実際に最もユーザーが使うのはリリース後になります。長年プロダクト開発の分野で仕事をしましたが、一番情報量が増えるのは、実はリリース後なのです。ですので、使ってもらいながら、「もっと使ってもらうためには何が必要か」という情報を得ることがビジネス上とても重要なのです。

従来型のプロジェクトだと、リリースしたら人を減らす戦略をとってしまいがちだと思いますが、その結果、ほとんどの業務ソフトウェアが、利用者が使い始めた後に「全然なおせない」という状況に陥ります。これでは役に立ちません。しかも業務はかわっていくのに、ソフトウェアが追いつけないなんて、どこが「ソフト」なんでしょうか。

プロダクトの課金体系がライセンス販売にせよ、サブスクリプション契約にせよ、継続的に支払いを増やしていただくことが、ビジネスにとって有利であることは間違いありません。ですので、実際に使っていただいたお客様の意見を聞いて、もっと使い続けてもらうための施策をうつべきです。本気で使ってくれているお客様のクレームには一切のリップサービスがありません。ですので、こちらも本気で対応をして、信頼を積み上げることが、次の契約につながる、と考えてみましょう。

繰り返しになりますが、本当に大変なのは、リリース後なのです。継続的に問題を解決しない業者を信頼する顧客はいません。

5. システムはハーモニーなので、継ぎ足して別の人を追加すると繋がらない

クラウドベースのオープンシステムが一般的になり、うまく他者を利用することで素早く安くリリースできるようになりました。一方で、顧客から見れば、サービスしているのはあなた(の会社)です。これは運用にとってみれば非常に難しい問題を起こしがちです。「こんな問題が起きてるんですが」「いやうちが作って部分についてはお答えできません」これでは顧客に信頼されません。システム間が接続され、自分が作っていない部分が増えれば増えるほど(つまり効率が高まるほどに)、こうしたクレームがどんどん増える傾向にあります。

では、このクラウド時代に我々はどうするべきなんでしょうか。重要なのは、顧客の代わりになってちゃんと調べるエンジニアを育てておくことです。できることならば、顧客が困る前に、その問題が起きないように作りこみます。これは一朝一夕ではできません。連携するシステムが多くなればなるほど、学ぶべきことが増えていきます。そして、時間がかかります。米国Microsoftの河野通宗さんが、このように語ってくれました。

logmi.jp

クラウドって、いろんなサービスの大きな集合体なので、自分のところを(ダウンさせずに)動かし続けるしかないんです。ほかのサービスが一時的にダウンしても、当たり前に動かします。ネットワークが切れたり、毎日どこかが壊れるんです。そういう中でも毎日動かしつづけるためには、テレメトリの運用、あとは、そういうのをあらかじめ全部考えた上での運用方法の確立というのは、絶対に必要です。

ある時点でなにかがちゃんと動いていても、次の週にはもう前提が変わっているんです。なので、完璧というのは世の中に存在しない。どうやってシステムを動かし続けるかには、答えはないんですけど、その中でやり続けることが、すごく楽しい。たぶんご理解していただけると思います。

内製化でエンジニアを育てる価値は、まさにここにあると思います。逆に、どれだけ詳しく見えても、ベンダーのエンジニアはその対象領域の教育しか受けられません。ですので、あなたの問題を解決できるのは、あなたと苦楽を共にしているエンジニアだけなのです。3番の引き継ぎのところでも書きましたが、急には育ちません。

業界には詳しいふりをする人がたくさんいて、困っていると甘い声ですり寄ってきますが、だいたい契約後に幻滅することになります。そんなに都合の良い話はないのだ...というのを学習するタイミングがプロダクトリリース直前だと、もう取り返しがつきません。

プロダクトオーナーは収益性の最後の砦として、ちゃんと責任を取っていくべきロールです。あなたの後ろに人はいないので、ちゃんと判断をしていく必要があります。判断を間違えば、プロダクトの収益性が低下し、チーム全体が危機に陥ります。永続的なものなど何もありませんが、プロダクトオーナーの見識と、戦略が成功のカギになることは間違いないところです。オープンに相談しながら、一つ一つプロダクト仮説を検証して、顧客からの信頼を積み上げましょう。

おわりに

いかがだったでしょうか。プロダクトオーナーの考えるべきところについて、少しケースを挙げてみました。全体の戦略については、繰り返しになりますが、こちらの本をお勧めしたいです。

技術プラクティスや戦術については、監修でお手伝いした本がもうすぐ出ます。チーム戦術から運用までカバーしているので、プロダクトオーナー(PO)にとっても良いガイドブックになると思います。

プロダクトについてはだいたい、馬田さんのスライドを見とけばいい気がします。

speakerdeck.com

speakerdeck.com

speakerdeck.com

技術的負債 - 問題発見までの時間とリスクをビジネス側に説明する

常松さんの新著、アジャイルラクティスガイドブックに、監修としてお手伝いさせていただきました。

本書には11本のコラムが掲載されているのですが、うち一本を私の方で書かせていただきました。技術プラクティスの説明のために技術的負債という用語を使う方は多いと思いますが、デプロイの自動化がどのようにメリットがあるのかを説明してみた、というコラムになります。

許可をいただき、こちらのブログにも掲載させていただくことになりました。校正中の原稿ですので最終稿は少し変わるかもしれませんが、ご賞味いただければ幸いです。

本原稿については、特別に角征典さん、大金慧さんのレビューをいただきました。ありがとうございました。もともと伝えたいことがだいぶ散漫だったのですが、多少読めるものになったとすれば、お二人のおかげです。

 

技術的負債 - 問題発見までの時間とリスクをビジネス側に説明する

技術プラクティスに関わるコストについて話していると、「開発者たちは認識しているが、ビジネス側に説明しにくい」という意見を聞くことがあります。まさにそういうケースで発明された用語が「技術的負債」です。経営者や財務担当者にとって、負債は必要な時にはとるべきリスクであり、一方で溜めてしまえば会社を危機にさらすものだと理解されています。この負債をメタファーとして使って、エンジニアが抱えている課題を説明しようとしました。例えば、「問題の発見までの時間がかかっている」ことは、現時点ではリスクにすぎませんが、緊急の障害が発生した場合には、そのビジネスを危機にさらすことになります。当面は問題ないように見えるかもしれないが、実は大きなリスクがあるということをビジネス側の人にも共有しておき、リスクを減らすための投資として技術プラクティスを調べたり、適用するコストをとることの共通理解を作りたい。アジャイル開発を作り上げてきた先達も、エンジニアでありながら、相手に伝わるようなうまい説明を編み出し、かかわっているビジネスの成功を目指してきました。

しかし、ただ「技術的負債があるから返済したい」と言っても、ビジネス側の人には伝わりません。具体的なエピソードにかみ砕いて伝える必要があります。一つの例として、問題が見つかってから、直すまでにかかる時間について、いくつかのケースを通じて考えてみます。

1.リリース前の手動テストに頼っている

初期にプロトタイプとして作ったアプリケーションが、よい評価を受けて本番に成長していく過程では、自動テストは後回しにしておき、自分で動かして確認た上で他の人に渡す、というケースがよくあります。自動テストができることよりも、新しい機能を早く客に見せたいと判断するケースはこれに当たります。リリースした後に問題が発見され、数週間前に作った部分のどこかにあるであろう原因を調べる必要が出てきます。報告者の勘違いで問題がない可能性も考慮に入れるべきですし、かなり広い範囲の推測を頭に描きながら、問題の理解に頭を使うことになります。これはストレスも高い作業です。そして、対応をリリースすると、さらにその変更によって同じような問題を埋め込んでしまうことすらありえます。サービスが正常に動いている状態に戻すには、リリース前の状態に戻す必要があります。もし、このタイミングでリリースしないといけない機能がある場合、かなり難しい判断を迫られることになります。

2. テストを自動化して、毎日ビルドとテストを行っている (デイリービルド)

以前は毎日ビルドを行うことをデイリービルド、夜間に行えばナイトリービルド、などと呼んでいました。ビルドを自動化して毎日自動的にチェックするようにすれば、翌日には問題が発見されることになります。ただし、テストケースの範囲内だけですが。少なくとも、ビルドできない、などの致命的な問題は発見できます。昨日行った作業のどこかに問題があったということはわかるため、まず一旦そのコミットを取り消して前日の「動いていた」状態に戻すことができます。一日分の作業を一時的に戻すだけなので、それほど大きなインパクトはない可能性があります。その上で、その後に行ったコミットを確認して、怪しいところを探り出していきます。

3.コミットをフックして、自動的にテストが走る(継続的インテグレーション

コードの修正をメインブランチにプッシュすると、自動でテストが走るようにしておくことを、継続的インテグレーションといいます。開発者たちにとっては、作業完了ごとにさまざまなフィードバックが得られるようになります。それまでに「動いていたコード」と「パスしていたテスト」のいずれかが、「先ほどの作業」で動かなくなったということがわかります。原因を探すために検討すべき範囲は非常に狭くなります。製品を作り込んだ10分後に問題が発見されたなら、まずはその10分間にした作業を疑うだけでよいですし、その部分を一旦捨てることは容易でしょう。


アジャイル開発では「既知の不具合はない」状態を維持することを目指します。それは既知の問題に関するテストを自動化しておいて、人間はそれ以外の部分をちゃんと探索するようにしよう、ということです。「ゼロバグトレランス(Zero Bug Tolerance)」ともいいます。もちろん我々は全知全能ではないので未知の問題は発見できないわけですが、この状態をなるべく高い頻度で確認できる状況を作り、維持することで「次に問題が見つかったとき」の反応速度が向上し、障害対応時の心理的負荷が下がります。そして「今は深刻ではないが、いずれ大きな問題になるかもしれない懸念」について、早い段階で検討することができるようになります。心の余裕を持ちながら、検討を忘れない慎重さが生まれてきます。品質の悪いコードを抱えているチームほど、次に発生する問題に対する余力は少なくなり、しばしば明確に存在している問題にすら対応できません。

「それは理解しているものの、ビジネス側から継続的インテグレーションやテスト作成のための時間を許可してもらえない状況だ」という相談を受けたことがあります。こうしたときに「技術的負債」のアイデアを活用して、ビジネス側にもわかるように説明することができるかもしれません。以下のように説明してみるのはいかがでしょうか。

バグが少なく、問題点の修正が早いということは「アジリティ」すなわち「近い将来のビジネスの変化についていくためのスピード」を向上させることにつながります。技術プラクティスを自分たちの選択肢として使えるようにしていくことは、ビジネス価値を高めることにつながります。まだそうなっていないのは、これまで対応のコストをかけてこなかったからかもしれません。その部分を「技術的負債」として考えることで、未来への投資となることがわかります。もちろん、いきなり大きな時間をかけてシステム全体をカバーする自動テストを書くなんてできませんし、まずは目の前にある1 つの変更点から、自動テストを足がかりにしていきます。

具体例を使って説明することで、ビジネス側の人にもリスクを伝えることができます。技術的負債を解消することには、ビジネス的に価値があります。「なぜそんなこともわからないんだ!」口にしてしまう前に、一歩一歩説明する勇気を持ってみましょう。深刻な問題が起きてしまう前に、こうしたことを話す勇気を持っておきたいものです。今日からでも遅くはないはずです。

次の第3章では、こうしたビジネス環境を作るための具体的な方法として、継続的インテグレーションと継続的デリバリーについて説明します。