7-8年前から紹介しているんですが、Post-Itの本家3Mが作っているiPhone App に Post It Plus というのがあります。
壁に貼った付箋を写真取ると電子化してくれるもので、秀逸なところは、付箋のサイズを自動認識して仮想的なボードに展開し、PowerPointなどに変換でき、パワポの中には個別の付箋のサイズの移動や拡大縮小ができる(オブジェクトとして貼られる)という神アプリです。
今年になって、PlusがとれてAndroidとMacをサポートしていることを見つけました。
3Mさんは昨年からGlobal Scrum Gathering にもブース出すようになったりして、社内でも風向きが変わった感じでしょうかね。グッジョブ！
この記事はRSGT2020アドベントカレンダーのために書きました。
Regional Scrum Gathering Tokyo Advent Calendar 2019 - Adventaradventar.org
週末に奥さんに誘われて細野晴臣さんの50周年記念のショーを見に行ったんですが、おん年72歳の細野さんが若者と戯れる空間がそこにありました。(以下敬称略) 高橋幸宏はもとより宮澤りえと水原希子を従えて昭和風味のお茶の間ドラマを展開し、踊りながら歩きまわり、星野源とコーヒーを適当に入れ、ビデオ出演の坂本龍一とYMOを生演奏し、全員で昭和な教室コントをやった後にジョイマンを踊るという、細野さんやスタッフの好きなことだけを詰め込んだ一夜限りの謎の幸せ空間でした。みんな細野さん大好きなんですね。
細野さんはまあだいたいなんでも楽器弾けそうだし、実際昨年のアルバムは全パート自撮りしたとも聞いたんですけど、舞台やコンサートは決してでしゃばらず、みんなで楽しくやる感じが素敵だなと思いました。アンコールもなし。(たぶん最後のジョイマンは相当体力的にキツかったんじゃないかと勝手に思いました。)
今日は、細野晴臣さんのイベント『イエローマジックショー3』に出演させていただきました！
— Little Glee Monster (@LittleGleeMonst) December 1, 2019
細野さん、音楽活動50周年おめでとうございます！！https://t.co/Hk0ohlbm1R#イエローマジックショー #ナナナナ～#ありがとうオリゴ糖 pic.twitter.com/e7Eb8SU4Jw
細野さんの公演を見ながら勝手にシンパシーを感じていたのが、決して無理しないRSGTのモットーみたいなもの。近年のRSGTにおきましては会場のキャパも座席数も需要に追いついてない感じで、チケットが取れない方には大変心苦しい限りですが、見えない誰かに無理無茶を押し付けてしまわないことが、ウォーターフォールに比べてのアジャイルの決意みたいなものだと思うんです。スタッフの皆さんにおかれましては、すぐにアンドンのコードを引いて欲しいと思っています。担当者がギブアップするまで続けるチキンレースはやりたくない。
「できないかもしれないけどやる」が若きベンチャースピリット、「できることをやる」が伝統的なエスタブリッシュメントのスピリットだとすると、「できるけどやらない」がアジャイルのスピリットなのかな、って改めて思いました。
というわけで、今回は久しぶりに会場が変わる大ジャンプですが、決して無理せず、いつもどおりが実現できたら嬉しいな、と思っています。初の会場はいろいろと不都合なこともあると思います。粗相も多かろうと推測しますが、みんなで作る空間ですし、みんなでいい感じにできればいいなと思っています。果たして何人が大崎に行ってしまうことでしょう。場所は御茶ノ水です。
漫才師のナイツが幕間に音声出演していて、漫才形式で会場諸注意や、休憩や終了をアナウンスしていたのが素敵でした。パクれるものならパクりたいです。Omoiyari.fm の人とかやってくれないかな。(無茶振りしてた)
数千人も入るような大きなホール久しぶりでした。
みんなが納得する答えが議論の結果としては出ないとしても、作業の先にはあったりするんです。なので、ちゃんと手を動かしてちょっと作ってみるのが大事。
先週、紙の申請書を用意する件がありまして、一枚目を書いたら色々ご指摘をいただいて、二枚目を書き直す結果になったんですが、結局一枚目も使うことになって、そういうのも一枚目を出したことによるコミュニケーションの結果だったりして、「申請書って実務者にとってはコミュニケーションツールなのだ」という思いを新たにしました。逆に書き方を教えてくれる人がいないときの入力フォームの絶望たるや....。
もう来週月曜(12/2)なんですが、出たばかりの A Scrum Book: The Spirit of the Game(通称スクラムパターン本)の発起人である Jim Coplien さんから直々にスクラムパターン本の話を聞く会をやります。いちおう本も確保していますので、欲しい人には有償ですがお分け出来そうです。領収書は出せませんが...。
A Scrum Book: The Spirit of the Game
本のパターンの一部や更に新しいパターンはこちらのサイトに出てくるのだと思います。
よかったら来てください。
こっちのスケールの話はウィーンで聞いたけど気づきが多かったです。こちらは水曜日。
仕事はもとより、カンファレンスやコミュニティをやってて心掛けていることの一つを思いだしましたので書いておきます。
「またやろっかな」って思ってもらいたい
です。来年もまた集まってもらえるように、今週のミーティングや作業に行こうかなと思ってもらえるように、誰もやりたくない仕事を絞り込んだり、新しいやり方を考えたり、やりたそうな人にお任せしたり、結果をちゃんと出すことを優先したり、後ろに引っ張らないとか、諦めるとか、できないことをさっさと謝るとか。
その上で今回で終わりにしてもよくて、やめる選択肢もまた、やってる人が持つほうが健康的だな、と思うんです。
写真はpmconfのスタッフのみなさん
実践アジャイルテストの続編である、More Agile Testing の第一章が、アジャイルテストの歴史を端的に書いてていいな、と思ったのでその部分だけ訳してみました。
私たちは、それぞれ、エクストリームプログラミング（XP）チームの中のソロのテスターとして「アジャイル」なキャリアをスタートしました。 当時、XPに関する出版物のどれも、チームにテスターがいることについて言及していませんでした。 プログラマーと顧客の2つの役割がありました。 顧客がすべての受入テストを指定し、プログラマーがそれらを自動化することで、これで完了です。 XPカンファレンスに行くときはいつも、自分たちをテスターと認識しているだけの、ソロの参加者でした。でも、テスターには多くの付加価値があることがわかっていました。 私たちは実験し、XPのパイオニアたちとテストについて話し合い、お互いにアイデアを交換しました。それぞれのチームの他のメンバーとも話し合いました。
アジャイル開発は進化し、それに伴って、アジャイルテストも進化しました。 チームは、単体レベル以上のテスト自動化のためのテストライブラリとフレームワークの開発を開始しました。 アジャイルテストの本を書く頃には、多くのアジャイル実践者が、エリザベス・ヘンドリクソンやマイケル・ボルトンなどの経験豊富なテスターの貢献を認めていました。 ブライアン・マリックやジョシュア・ケリエフスキーなどの実務家は、開発を導くために具体例とストーリーテストを使用するというアイデアを開拓してきました。
ウォード・カニンガムは、具体例を定義することを手助けするFit（結合テストのフレームワーク）を作成し、ダン・ノースはビヘイビア駆動開発（BDD）を導入し（North, 2006）その後の人気ツールへの道を開きました。アジャイルチームは、探索的テストの価値を理解しはじめていました。 アジャイルチームでのテストは、ブライアン・マリックのアジャイルテストの四象限（Marick, 2003）で示されているように、機能だけでなく多くの種類のテストを採用しました。
もちろん、アジャイルテストの成功を妨げる課題がまだありました。 私たちテスターは、プログラマーが使う統合開発環境（IDE）に単体テストが組み込まれているように、あらゆる支援を熱望していたのです。同じような手軽さを、テスターがテストを定義するときにも欲しかった。ジョージ・ディンウィディーがいう「Power of Three」または「Three Amigos」を適用することには大きな利点があります（Dinwiddie, 2010）。顧客・プログラマー・テスターは、機能がどのように振る舞うべきかについての質問があればいつでも協力します。 しかし、設計・ユーザビリティ・データ・その他の品質属性など、顧客の要件には多くの側面があり、それらを把握することは依然として困難であることがわかりました。 本書では、それらの課題の一部を扱います。
いくつかの手法の実践者たちはこれまで、アジャイルテストの実践における溝を埋めてきました。 私たちは幸運なことに、さまざまな異なるコンテキストでのアジャイルテストで成功した、他の実務家たちのストーリーを共有することができます。
重要なアイデアの1つは、すでに私たちの日常的な思考の一部になっています。アジャイルチームでのテストとは、フェーズではなく、活動です。 この概念をエリザベス・ヘンドリクソン（Hendrickson, 2006）から学び、本の全体を通して、テストとはソフトウェア開発中にすべての分野で考慮する必要があるものだということを強調しています。
アジャイルでテストするためのより優れたテクニックを継続的に学び、スキルセットの深さと幅の両方を備えたゼネラリスト・スペシャリスト(訳注: 幅広い複数の領域に専門性をもつ人)がいると、チームがテストにまつわる困難に取り組むのに役立つことを発見しました。 実践者たちは、さまざまな分野のチームメンバーが協力して、お互いの専門分野を「ちょうど十分に」学ぶのに役立つプラクティスとパターンを作成しました。
アジャイルアライアンス機能テストツール（AA-FTT）グループのメンバーなどの実務家は、テストのためのより優れたツールへの道を主導してきました。今日では、テストコードの作成は本番コードの作成と同等のものです。どういったフレームワーク、テストライブラリ、ドライバーがチームのニーズに適しているかを特定するためのより優れた方法を学びました。
ビジネスアナリストは、顧客の要件を発見するための専門スキルをアジャイル開発に取り入れます。テストとビジネス分析は、チームが適切なビジネス価値を提供するのに役立つ補完的なスキルをもたらします。同様に、ユーザーエクスペリエンス（UX）の専門家は、新しい機能が設計されたときに顧客の意見を得る、シンプルで優れた方法を示します。DevOpsの実践者は、開発・運用・テストのスキルを組み合わせて、デリバリーやデプロイなど、新しい次元で品質を向上させ、リリースサイクルを短縮してリスクと顧客への影響を軽減します。
数年前に比べ、探索的テストの価値を理解しているアジャイルチームにたくさん出会うようになりました。私たちの一冊目の本では探索的テストを扱っていますが、そうしたチームがもっと様々なやり方で探索的テストのパワーを活用できるであろうことは明らかです。 幸運なことに本書では、アジャイルな文脈で探索的テストを実践している人々が専門知識を共有してくれています。
私たちは、テスト計画とコラボレーションに関する新しく、創造的なアプローチにも出会ってきました。今日のチームは、品質を可視化する、より多くの方法を見つけています。アジャイルテストの四象限やテスト自動化ピラミッドは、より多くの次元を表すように適応・拡張されています。
今日、より多くのチームが、ますます拡大するデバイスとプラットフォームで、モバイルアプリと組み込みソフトウェアのテストに直面しています。 データを保存・管理・分析・検索・可視化する、新しいテクノロジーを備えた大規模で複雑なデータセットは、新しいカテゴリであるビッグデータとなりました。テストも引き続き進化しなければなりません。
アジャイル開発は、同じ場所にいる小さなチームのために生まれました。 現在、一部の小規模なアジャイル企業だけでなく、大企業の分散チームでも利用が始まっています。大企業の組織全体でソフトウェアソリューションを使用している場合、テストは重厚な組織の制約など、さまざまな障害に直面します。 同時に、組織は、高速フィードバックループと検証による学習を備えた反復的なリリースを使用して、最小実行可能製品（MVP）を開発する新しい方法を見つけています。
一冊目の本を書いた2008年に、本番環境でテストを行っていた企業はほんの一部だったため、その技術を知ることができたのは後になってからでした。今日、ログファイルのエラーを監視しながら、少ない割合の本番ユーザーに更新プログラムをリリースすることや、本番ユーザーから迅速なフィードバックを得る手法は、適切なコンテキストで行う限り、有効かつ必要な戦略です。
これらの変化とイノベーションによって、私たちや他の実践者たちが学んだことを共有するようになりました。 アジャイルは絶えず改善されています。みなさんの多くはアジャイルの採用に数年かかるかもしれません。学習するにつれてプロセスを変えるかもしれません。現在直面しているテスト関連の問題は、以前のアジャイル移行の際とは大きく異なる可能性があります。この本で共有された経験が、プロダクトの品質を可視化し、プロセスを検査・適応する際に、試すべき実験のアイデアを提供してくれることを願っています。
アジャイルソフトウェア開発の進化に伴い、ペースを維持するためにアジャイルテストを継続的に検査・適応しています。この章では、アジャイルテストの変遷を概観しました。
アジャイルチームは、ビジネス分析・ユーザーエクスペリエンスデザイン・DevOpsなど他の分野の実践者たちの手法が、チームが顧客の望む品質を構築する能力を伸ばしてくれることを、ますます認識するようになっています。
アジャイルテストは、急速に変化するテクノロジーとアジャイル開発の新しいコンテキストに対応する必要があります。この本を通してこれらのアイデアを探求します。
プロダクトマネージャーカンファレンスでキーノートを話してたMarty Caganさんがおすすめしていた本。Amazonのリンクが上手く貼れないのでKobo貼っときます。
![1兆ドルコーチシリコンバレーのレジェンド ビル・キャンベルの成功の教え【電子書籍】[ エリック・シュミット ]](https://thumbnail.image.rakuten.co.jp/@0_mall/rakutenkobo-ebooks/cabinet/1159/2000007891159.jpg?_ex=128x128 "1兆ドルコーチシリコンバレーのレジェンド ビル・キャンベルの成功の教え【電子書籍】[ エリック・シュミット ]")
1兆ドルコーチシリコンバレーのレジェンド ビル・キャンベルの成功の教え【電子書籍】[ エリック・シュミット ]
シリコンバレーの伝説のコーチ、故ビル・キャンベル氏について、Googleの元会長兼CEOのエリック・シュミットらが書いた本です。あとがきにこの本が書かれた経緯が書かれています。これを見るだけで、読むべきだと思う人も多いかもしれないですね。
エリック・シュミット、セルゲイ・ブリン、ラリー・ペイジ、スンダー・ピチャイ、ティム・クック、ビル・ゲイツ、ジェフ・ベゾス、マーク・ザッカーバーグ、シェリル・サンドバーグ、ジョン・ドーア、マーク・アンドリーセン....。
これらの人々を育て、そして何より彼らに愛された人物がビル・キャンベルなのだ。
本書はその追悼式の席で、「コーチの教えをシェアしなければすべてが失われてしまう」という危機感を持った人々によって執筆された。スティーブ・ジョブズと並び、コーチと最も親しく仕事をしてきたエリック・シュミットらグーグルの三人である。
彼らは『How Google Works 私たちの働き方とマネジメント』(日経ビジネス人文庫)を書いたチームでもあり、その意味で本書はその続編として読むこともできる。
以下一部、抜書きします。参考になれば幸いです。まあ、どこもやばいんですけど。
チームのマネジメントについて。
チームがやっていることを君たちは理解しているのか？メンバーになにかうまくいっていないことがある場合は、どうやって方向転換して起動に戻れるかを示すべきだ。「すべての部下をわが子と思え」とビルは言った。「軌道修正して向上できるように、手を貸してやるんだ」
イノベーションについても話した。チームにはイノベーションに取り組む余地があるのか？イノベーションと業務遂行の本質的な対立関係にどう折り合いをつけているのか？どちらか一方ではだめだ。バランスを取ることがカギだ。
目標について。
重要なのは短期目標の達成ではない。オペレーショナル・エクセレンスが少しでも欠けた状態を許さない文化を醸成することだ。株主のためだけでなく、チームや顧客のためにも、結果を出すのが経営陣の仕事だ。
インテュイットのCEOとして有名だった人みたいですね。コーチでは一切お金を取らなかったということです。
ビルはインテュイットのCEO時代、エンジニアリング部門の幹部と毎週金曜にランチミーティングを行い、彼らが何に取り組んでいるか、何が彼らを阻んでいるかについて、ピザを食べながら２時間ほど話し合った。
ビルはテック系ではなかったが、技術オタクたちから話を聞き出すのがうまかった。経営幹部は、たとえエンジニアリング担当でなくとも、エンジニアと話ができなくてはならない。オタクたちはCEOが毎週関心を払ってくれていることを知っていた。ビルはそうやって、彼らに本領を発揮させたのだ。
会議の話も面白いです。
彼は民主主義を好まなかった。(ビルが来る前のインテュイットではミーティングで採決していたが、ビルはそれをやめさせた。)
代わりに好んだのが、「即興コメディ」で使われるような手法だ。即興コメディでは芝居が終わってしまわないように、キャスト全員が入れ代わり立ち代わり舞台に立ち、力を合わせてできるだけ長く芝居を続けなくてはならない。
ビルはそうした「アンサンブル」の状態を好み、駆け引きのない環境が保たれるよう、つねに気を配っていた。経営トップがすべての決定を下すようでは、その正反対の環境になってしまう。なぜなら部下は自分のアイデアをマネジャーに認めさせることに終止する体。そうした環境では、最適解ではなく、最高権力者へのロビイングに長けた者、言い換えれば政治が勝利を収める。
具体的にはそんなに把握できてないのですが、会議には秘密がありそうです。
Twitterのボードメンバーの話も。
ディック・コストロがツイッターのCEOに就任したとき、取締役会のメンバーは彼のほか数人のベンチャーキャピタリストと創業メンバーだけだった。ディックはビルの助けを借りてそれを変え、事業運営の実務に精通した人たちを取締役会に迎え入れた。ビルは、頼りにできる実務家がいたほうがいいと勧めたのだ。
ビルは悪い取締役についても具体的なイメージを持っていた。
「それは、ただふらっと来て、自分が一番賢いと見せようとして喋りすぎるやつだ。」
解雇を伝えるときにも、素晴らしいアドバイスをベン・ホロウィッツ(!!)にしているようです。
ビルはある時、会社をやめていく幹部のことでベン・ホロウィッツに言った。
「ベン、君は彼に仕事を続けさせることはできないが、自尊心を保たせることは間違いなくできる」
以上、なんというか、今年は岩田さんもすごかったけどこれもすごいなぁ。と思いました。
あ、pmconfでの私の発表資料はこちらです。
