3月にDavid Bernstein さんの 認定スクラムデベロッパー研修を行います

 アギレルゴコンサルティングでは、Scrum Alliance 認定 の スクラム研修を数多く行ってきました。私たちが実際に海外で知り合った選りすぐりの講師陣にお願いしています。

次は、「レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス」の著者、David Bernsteinさんによる認定スクラムデベロッパー研修です。

勢い余ってやや宣伝っぽいのですが、ちょっと主催者の想いを聞いてください。

スクラムの基礎から健全なコードをメンテし続ける技術まで学ぶ

5日間をかけて、スクラムの基礎もカバーしながら、ペアプログラミングリファクタリングを行いながら、チームとともに長生きするコードを生み出すための技術をしっかりと身につけるカリキュラムになっています。

開発技術を学ぶ機会の少ない日本

スクラムはやってみたけど、継続してプロダクトのリリースができていない。最初は良かったけどコードベースが大きくなって遅くなってきた。

おそらく課題は開発技術にあります。スクラムをやったとしても、開発技術を学ぶことができていなければ、高速にゴミをす生み出してしまいかねません。開発チームは継続してソースコードをメンテナンスできるように、技を磨き、アーキテクチャを手直ししていく必要があります。

実際に長く日本のソフトウェア業界にいる人間からみると、ソフトウェア開発技術自体を学ぶ機会が少ないと感じます。プロジェクトマネジメントや、製品企画については学ぶ機会がだいぶ増えてきたのですが、一方で足元の開発技術は、ツールの紹介ばかりで、本質を学ぶ機会があまりありません。昨年、アジャイル開発に携わる大小いくつかの北米の企業を訪問してきましたが、どの企業も技術や、技術の伝承、学ぶ時間をとることを重視していました。

熟練の技術者であり、技術者指導者としても熟練の講師

講師のDavidさんは、「レガシーコードからの脱却」の著者であり、長年IBMなどで実際にメンテナンスできなくなってしまったソフトウェアから脱却するための技術者指導に携わって来られました。1万人以上を指導してきたそうです。

 

技術者不足が深刻になってきた

IT部門やシステムインテグレーターさんで、実は一番多い問題が「しっかりとソフトウェアをメンテナンスし続けられる技術者がいない」であろうかと思います。数が少ない、ではなく「いない」という会社さんも多いのではないかと思います。しっかりと教育機会を作る必要があります。私見ですが、日本のソフトウェア開発の問題の一つは、上級者へのしっかりとした教育機会がほとんどないことだと思います。

北米の企業であれば、社内に80年代のデータベースシステムやOSの発明者がいたり、世界的なオープンソースプロジェクトの創始者やメンテナが闊歩しているのは珍しくないと聞きます。皆さんの環境はどうでしょうか?

技術力を持ったリーダーが必要な時代

Microsoft に行かれた牛尾剛さんから聞いて驚いたのは、いま北米・欧州の企業では、マネジメント層も多くがソフトウェア開発の本質を理解している、ということです。「はげちゃびんがいない」という刺激的な言葉を使っていますが、実際に牛尾さん自身も自分がはげちゃびんであると感じて渡米したそうです。私たち日本人は、もっともっと技術力を高める投資を、やっていく必要があるのだと強く感じました。


Agile Japan 2019 応援メッセージ 未編集版

kawaguti.hateblo.jp

技術は常に新しくなり、私たちは継続的に学び続ける

私が知る限り、ソフトウェアの世界は常に新しい技術が生まれている世界で、これはこの先も変わらないのでしょう。継続的に学ぶ必要があり、学んでいると、学ぶのが幾分やりやすいという特性があります。

新しいものを学ぶことに慣れてくると、学ぶ困難が減っていき、より楽しめるようになります。新しいことを学んでいるなら活発な精神でいられますが、筋肉と同じように、脳も使わなければその力は衰えます。年を取ると、ソフトウェアを書くのは外国語を学ぶようなものです。神経活動を刺激し、心をシャープで機敏に保ちます。
しかし、ソフトウェア開発者というものは、仕事としてソフトウェアの生産が期待されているせいで、継続的に学ぶことが難しくなることがあります。その結果、しばしば業務時間外にも勉強しなければなりません。

達人たちは、学ぶことにも積極的で、持続的で、うまいと感じます。

kawaguti.hateblo.jp

達人から直接指導を受けるチャンス

ペアプロ中にハマって、先生に見てもらうんですけど、15秒くらい眺めてから、次に来る回答が神回答で。

前回の研修では多く参加者の方から非常に高い評価を頂きました。実は私もちょっとびっくりしました。この人本物だなと。本物の達人から直接指導を受ける、数少ないこの機会を、ぜひ活かしてください。

ww.jp.agilergo.com

f:id:wayaguchi:20200131002337p:plain

 

カンファレンスの雰囲気作りについて

RSGT2020今年もつつがなく開催できました。お陰さまですごく楽しかったという声を多くお聞きしてほっとしてます。スタッフのみなさんおつかれさまでした。スピーカーの皆さんも高いプレッシャーの中、出来る限りのものをぶつけていただいて、本当に感謝していますし、すごいなーと思います。尊敬します。

 

すごく雰囲気が良かったというご評価をいただくことが多くて、大変ありがたく感じております。雰囲気作りについて、ちょっと思ったことをFacebookに書いたら長くなったのでブログに転記しました。


カンファレンス会場の雰囲気なんて参加者の人たちが作ってるものなので実行委員はなにもしてません。なるべく会話を邪魔しないで済むように空間を考えたり、大きく声を出して指示しなくても自然と必要な場所に流れるのがベスト。そのために例えば受付では変な人が入ってこないようにリスクを摘み取ってたり、場を壊してしまいそうなリスクをどんどん排除してる。

企画側のエゴで盛り上げたいとは思ってません。基調講演は実行委員で決めさせてもらってるけど、純粋に自分たちが聞きたい話を呼んでるだけで。去年うまくいってそうなことは基本そのまま。検査と適応の繰り返し。出来るだけ手抜きする。他の誰かに呪いを押し付けるくらいなら、やらない。無理しない。だれかが無理するようにもしたくない。

「自分が関わる以上もっと貢献してよくしなければ」とか思ってる人がいるとしたら、そんなんいいから、ちゃんと朝きて、元気に帰ってもらうことが大事。事故なく怪我なく終われば楽しい。今年風邪ひいたら来年頑張って。

ハコの大きさを無理せず、チケットが売れてるなら資金的には気にしなくていいので(入手困難ごめんなさい)、必要なところはお金で解決する。でもアウトソースすると必要な情報揃える事に忙殺されるので、必要なとこだけ継続的にお付き合いしたい。去年と大体同じです。わかりました。で発注したい。

これをやったらいいと思う!そうだね!誰がやる?いないね。じゃあやめとこう。で結構いろんなことを廃案にしてます。やれるならやったらいいし、うまくいったら続けていきたいけど、無理しない。正しい無理などない。

実行委員もボランティアも2/3以上の人が熟練なので、いつもの感じで自律的に対応できる。たぶん参加者もスポンサーさんもそう。そこに画期的な新企画なんていらないのでやらない。基本去年と同じ。ご飯があって椅子と机があって仲間がいれば楽しい。話し合えれば学びが最大化する。また来年も来ようと思う。同僚も連れてきたいと思う。知り合いにも紹介しよう。楽しくて、やりたいことができて、学びがある。ディズニーランドみたいなもの。キャストとゲストがいるだけ。そこに一方的にサービスされるお客さんはいないんです。

ということでうまくいっているとしたら偶然なので、もっとこうしたい、みたいなご提案はありがたいですけど、やるとなると現状維持を優先したいです。収容人数を倍にしろ1000人いけるとか言われても、場所探しからファイナンスから動線からスタッフ配置から諸々、やったことないことが増えれば増えるだけ、チームや場が不安定になるのは、スクラム から学んでることじゃないですか。

規模を大きくするにしても30%くらいまでにしたいのは、常に2/3は去年と同じにしたいから。同じような会場、トラック構成、スポンサー規模、飲み食い、参加者やスタッフ。「30%は人工的な数字」って言われたけど、割と根拠あると思ってます。2/3を経験者にする。Succeeding with Agile に書いてあったように、文化は多数決なので。

初めての時って興奮して新しいものを足したくなるんですけど、Less is more で、ROI高くしないと、自分が楽しめないと思うんですよね。スタッフが一番楽しみたくてやってるのに滅私奉公だと続かない。スタッフが続かないと引継ぎ負荷が上がってROIが下がる。

スクラムも知られてなくて、チケットも売れなかった時代を経験してる人たちがいなくなると、またちょっと変わっていくのかもしてないけど、今はなるべく現状維持で、来る人の認知負荷が低い状態を維持したいです。馴染みの銭湯が毎回模様替えしてたら居心地悪いので(なんのこっちゃ)。

パックマンルールでぼっち対策

昨年初参加した、Agile Testing Days のぼっち対策のポスターが秀逸だと思いました。

パックマンルールを常に心がけよう。

Keep the Pac-Man rule, always in mind!

f:id:wayaguchi:20200109063059j:image

初参加の人や初対面の人が話の輪に入りやすくなるよう、必ず入り口を開けておきましょう、パックマンの口があいているように。

究極の対策でもなんでもないんですけど、このちょっとした心がけを普及させれば、「入れてあげるようにしよう」「入っていいのかも」という気持ちが少しだけ高まる気がします。

パクりたい。

「難しい人を受け入れるのは同時に一人まで」ルール

考え方が違うとか、感覚が違うとか、うまく付き合うのがちょっと難しい相手っていうのがたまにあって、別にずっとそうなわけではないんだけど、今はちょっと大変な相手。かといって距離を置くのも適切じゃないようなケースで悩むわけですが、あるときから、「難しい人を受け入れるのは同時に一人まで」ルールで考えるようになりました。

f:id:wayaguchi:20191219195329p:plain

きっと、少し時間あれば打ち解けられるんだろうけど、複数人がその状態だとこっちが疲れてしまうし、そもそも時間をかけられなくなってしまうので。なんかきついなーと思ってふと見回すと複数人を相手していたりするので、ちょっとタイミングをずらしたり、片方は一旦距離をおいたりできないか考えてみる。

一人というのはパラメータで、人によっては3人かもしれないし、10人100人といけるかもしれません。そこはやりながら許容量を見定めていけばいいと思います。タイミングも細かくできると思いますので、切り替えの早い人は実質無制限に行けるのかもしれない。(マルチコアとクロックアップで性能向上するCPUみたい。)

 

ただ、クソッタレさんはお断りです。 

あなたの職場のイヤな奴

あなたの職場のイヤな奴

 

 

RSGT2020 非日本語ネイティブ向けのGlobalチケットを発売することにしました。

海外の方や日本在住の日本語ネイティブでない方から、

「数分で完売?クレイジーだね。」

「日本に行こうと思うんだけど、チケットが完売してる。なんか買う方法ない?」

「日本は遠いけど行ってみたい」

というお問い合わせをいただくようになりました。

 

日本人向けのチケットも十分に用意できない中で、と感じる方もいらっしゃると思いますが、今回、少数ですが英語話者向けのチケットを用意することにしました。発売は来週月曜日16日正午です。

rsgt2020.eventbrite.com

Regional Scrum Gatgering Tokyo を東京近郊に住む日本人だけの閉じた場所にしたくないという思いがあります。キーノートは毎回英語圏の方をお呼びしてますし、トラックも一つは英語で聴けるようにしています。数年前は私の同僚のNon Japanese nativeも何人も来てました。ボランティアの方にも英語に抵抗がない方をお願いしています。実行委員は海外カンファレンスに積極的に参加してる勢ですし、冠スポンサーは米国の非営利団体のScrum Allianceです。アジアからもヨーロッパからも北米からも国内からもあらゆる国や地域の方々が参加しやすいカンファレンスにしたいと思っています。

miholovesq.hatenablog.com

 

お近くに非日本語ネイティブの方で、カンファレンスにご興味ある方がいらっしゃいましたら、ぜひこのチケットのことを教えてあげてください。

日本語ネイティブの皆様は、申し訳ありませんが趣旨をご理解いただき、Global Ticketをご購入されないよう、お願いいたします。*1

 

*1:そんな方はいらっしゃらないと信じてますが、「ルールを破りに行くチャレンジ」は、社会的正義を背景にやるべきと思います。

何十年分の人生経験と対峙する

なんらかの概念を人に教えたり、やりたくなってもらおうとしたときに、それまでのその人の何十年分の人生経験と対峙することになるので、それをたかだか数時間や数ヶ月でなんとかするのはそもそも成功率の高くない賭けなんじゃないかと思うことがあります。

たとえば言語。言葉通じない人に楽しさを教えるのはすごく難しそう。極端な例ですが。基本的に人はバラバラ。でもたまに全然違う環境にいても同じようなことに共感することがあって。言語や環境や性別や年齢を超えてなぜか話があったりする不思議。パターンの根底にはそんな考え方があるみたいです。

なので、きっと共犯者も見つかります。

f:id:wayaguchi:20191208000447j:image

僕だけがいない街(4) (角川コミックス・エース)

 

実はこれは井庭崇さんのパターンランゲージのワークショップで学んだことなのですが、たぶん多くのアジャイルコミュニティやパターンコミュニティの人が共通の根底として持っている理解のような気がします。素朴理論。

Fearless Changeには、組織を超えても共感してくれる人の大事さが「Shoulder to Cry On : 相談できる同志(39)」として書かれています。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

 

 

 

お客さんがプロダクトオーナーになるべきなのか?

プロダクトオーナーが忙しい、プロダクトバックログ書いてくれないって話をよく聞くんですけど、そのあと話を聞いていくと実はプロダクトオーナーは同じ会社じゃないんです、お客さんなんですっていうパターンがちょくちょくあります。

プロダクトオーナーがやる仕事は結構あります。

  • ビジョンを持ち、いつ誰に何を届けるかを考え、プロダクトバックログに落とし込む
  • なるべくROIを高められるようにプロダクトバックログを優先順位付けする。
  • 直近の数スプリント分は準備完了(チームが着手可能)にする
  • チームと定期的に話し合ってバックログを見直す(リファインメント)
  • すべてのステークホルダーと話す
  • 予算を取る
  • バックログの内容についてチームからの質問を受けつけ、明確化する
  • チームが完成としたバックログ項目の成果物(出荷判断可能なプロダクトインクリメント)の受け入れ判断をする
  • 受け入れた成果物をリリースすべきときにリリースする

プロダクトオーナーは一人、もしくは複数人でやる場合にもチーフを置き、最終決定責任を明確にします。

で、これって顧客側でカバーできるんでしょうか?日本でウォーターフォールが多いのは、顧客側が曖昧な要件と厳しい予算/納期を要求し、それを受注側がカバーする構造のために、事前に受注側で様々なリスクヘッジが発生することに起因する気がしています。顧客側が十分な要件や仕様を提示するケースは極めて少ないのではないでしょうか。

スクラムがうまく行かないのはお客さん(PO)が仕様をくれないから」だとすると、デスマーチになるウォーターフォールとだいたい同じような問題を抱えてしまうように思います。

組織を跨ぐのがベストではないとしても、なにかうまくやる方法はないのでしょうか?

共犯者モデル

一つの考え方は、共犯者モデルと呼んでいるものです。顧客側と開発側にプロダクトオーナーを置いて、緊密に連携する。お互いに背中を預けて、説明していく。会社を跨いでしまうとそこ(会社間)で交渉してしまいがちなんだけど、それは全体の価値を考えればムダ。POはあらゆるステークホルダーと話す必要があるので、ペア/チームを組んで360°をカバーします。

f:id:wayaguchi:20191206131429p:plain

顧客側がカバーしやすいこと

  • ビジョンを持ち、いつ誰に何を届けるかを考え、プロダクトバックログに落とし込む
  • なるべくROIを高められるようにプロダクトバックログを優先順位付けする。
  • すべてのステークホルダーと話す
  • 予算を取る
  • チームが完成としたバックログ項目の成果物(出荷判断可能なプロダクトインクリメント)の受け入れ判断をする。
  • 受け入れた成果物をリリースすべきときにリリースする

受注側がカバーしやすいこと

  • 直近の数スプリント分は準備完了(チームが着手可能)にする
  • すべてのステークホルダーと話す
  • チームと定期的に話し合ってバックログを見直す(リファインメント)
  • バックログの内容についてチームからの質問を受けつけ、明確化する

もちろんこれは協調してカバーしましょうというだけの話です。役割分担ではありません。開発チームが最も高いROIを利用者に届けられるように、ベストをつくします。

 

以上、2009年くらいに思いついた話でした。

togetter.com

 

信頼に基づく

共犯者が裏切ったら終わり、というところですので、信頼が大事です。

 

このエントリもRSGT2020のアドベントカレンダーに向けて投稿してみます。

adventar.org