田舎でスクラムシリーズ16年目

ちんもの勤める会社が突然のアジャイルフィーバーになって1年。

経営陣と組織職が全員アジャイル研修を受け、全社方針にも組織戦略にもアジャイルの推進なるものが組み込まれ、顧客から多くのアジャイル案件がやってくるという状況になった。

果たしてこれは、長らくちんもが夢に見てきた世界なのか、そして会社人生の多くをアジャイルの展開に投じてきたちんもには、いよいよお役御免の時が迫っているのだろうか...。

アジャイル時代にSIerが抱える新しい課題に果敢に切り込むちんもの無謀な挑戦、聞いてやってください！

DevOpsの世界において、テストはどのような位置づけにあるのか？

テスターはどのように適応すればよいか？

DevOpsでは、開発チームと運用チームが一緒に仕事をすることが奨励されています。これにより、製品を提供するために協力する人々のネットワークが広がり、テストの境界が拡大し、テストの性質が進化する機会が生まれます。

開発チームが運用で利用可能なスキル、プラクティス、ツールを理解すると、テストは生産に向けて右肩上がりになる。例えば、本番同様の環境でテストを行うことができるオンデマンドインフラ、顧客指標から得られるA/Bテスト実験からのフィードバック、顧客からのフィードバックを迅速に提供するベータテストグループなどがあります。

DevOpsによって納品ペースが上がると、新機能のテスト戦略にも課題が生じます。開発チームは、リリースを過度に妨げることなく、どのように新機能を調査すればよいのでしょうか。テストの自動化、モニタリングとアラート、迅速な自動デプロイとロールバックなどのツールの賢い利用を含めて、テストアプローチを適応させることができます。

このセッションでは、Katrinaが彼女の著書「A Practical Guide to Testing in DevOps」からいくつかの考えを紹介します。また、DevOpsを紹介し、開発中、本番稼働中、インフラに対するテストのための一般的なDevOpsプラクティスをいくつか紹介し、DevOpsがどのように、そしてなぜテスト戦略を変えるかも説明します。

長期間にわたり、保守・開発を続けていると、メンバーの間にいつの間にか上下関係ができてしまい、うまく行っていたスクラムチームがいまいちな状態になったことはないでしょうか？
私たちにもそのような時期がありました。そのようなチームに突如訪れたメンバー交代、そして入ってきたのは、アジャイルをやったこともなければ、エンジニア経験も浅いメンバーたち。
そのようなメンバーを中心として、チームを再構成する中で、アジャイル開発を体験したメンバーがどのように成長を遂げ、新しい形でチームを作り上げていったのかお話します。

チームを作るのに、何かとらわれのようなものを持っていないでしょうか？
チームとは何か、チームとして達成したいものは何か、私たちは何度も話し合い、自分たちにあった形で変えてきました。
アジャイルどころか、システム開発自体も知らなかったメンバーもいるなかで、スクラムを中心に取り組むこと、諦めることを先入観なしに行うことで、チームの雰囲気も変わり、大きく成長をすることができました。

チームビルディングに悩んでいる方のご参考になればと思います。

何かを学びたいと思った時の方法の一つとして、「読書」があると思います。
集約された賢人の知恵をもらうことが数千円の投資でできる読書は、物事を学ぶのに非常に投資対効果の高い方法であるはずです。

しかし、現実を見てみると、読書が思うようなペースで進められなかったり、読みたかったはずの本なのに読んでいる途中で苦しくなって挫折したり、読んだのに何も行動変容が起きなかったりと、読書を通して自分が思っているような姿になれず、悩まれている方も多くいらっしゃると思います。

本プレゼンテーションでは、ここ1年半で316冊の本を読む過程で自分が行ってきた、試行錯誤の結果(153個の読書方法を実践)の中から50個をピックアップして紹介する(※)ことで、読書の仕方に悩まれている方の一助になることを目指していこうと思います。

※ハイピッチで50個の読書方法を紹介しきるか、参加者の皆さんが気になる読書方法を幾つかピックアップしてゆっくり紹介するかは、当日に参加者の皆さんにアンケートを取って決めたいと考えています。

このセッションは、以前はそれほど気にしていなかったプロダクトそのものや、マネジメント、最近耳にするようになったプロダクトマネジメントについて、徐々に当事者になりつつある方に向けたセッションです。プロダクト作りに注力するチームや、プロダクトオーナーが知識の土台を揃えられ、異なる立場の人との効果的なコミュニケーションに役立ちます。

一言で「あっ (プロダクト|マネジメント|プロダクトマネジメント)ってそういうことだったのかー!」が得られるセッションです。ビジネス側やマネジメント層と区別される人達とも、よりスムーズなコミュニケーションができるようになります。私自身がプロダクト開発にはじめて接するときにはじめに聞きたかったことをお伝えします。

----

「プロダクトオーナーがボトルネックだ」という声をよく聞きます。ところが、私がスクラムを学び始めた10年前から続いています。問題があればみんなが喜んで解決してしまう開発者コミュニティでは、まるでアノマリーのようなテーマです。

しかし、もはやプロダクトの責任はプロダクトオーナーだけのものではなくなりました。プロダクトを明確に意識しなくても仕事として成り立っていましたが、すこしずつプロダクトという言葉があふれつつあります。スクラムでもプロダクトオーナーに加えて、プロダクトバックログ、プロダクトヴィジョン、プロダクトゴールというようにです。

同様にマネジメントという言葉もよく耳にするようになってきました。「マネジメントって何?」と聞くと、「何とかして達成すること」だったり「やりくりすること」という答えが返ってきます。しかし、明日からマネジメントをする人にとってみれば、それらの言葉では動きようがありません。仕事をしている過程で「マネジメントの仕事はしていないけど、やりくりは日常的にしている」という方も多いでしょう。

プロダクトもマネジメントも、明日から「こうすればいいんだ」と思える明確な表現が必要です。

また、近年はプロダクトマネジメントという言葉が良く耳にするようになりました。いろんな方がいろんな説明をされています。先ほどのプロダクトとマネジメントが組み合わさった言葉ですが、それがいったい何を指すのか、ハッキリと理解した感触は得られていないのではないでしょうか。

「開発側」「ビジネス側」という言葉があります。「ここまでは私たちの仕事で、それ以外のことは他の人達の責任」といった境界がよく話題に上がります。こういった境界は、複雑で難しい開発という仕事の中では、一時の心の平穏として役立つこともありますが、障害になることもあります。同じような境界を生み出す言葉に「現場」と「マネジメント」があります。これらの境界は、単に知らなかったり、やったことがないだけだったり、きっかけがなく関心が薄かったりするだけなのかもしれません。

このセッションでは、そもそもプロダクトとは何か、マネジメントとは何か、プロダクトマネジメントとは何かを明らかにすることを通して、これらの境界を溶かし、様々な専門家の力が結集する組織に向けて役立ててもらえたらと思います。

■参考文献
■■プロダクト
『競争の戦略』マイケル・ポーター
『企業戦略論』ジェイ・バーニー
『マーケティング』井上淳子、石田大典
『マーケティング戦略』和田充夫、恩藏直人
『コトラー&ケラーのマーケティング・マネジメント』フィリップ・コトラー、ケビン・ケラー
『コトラーのマーケティング入門』フィリップ・コトラー、ゲイリー・アームストロング、マーク・オプレニック

■■マネジメント
『新訳 科学的管理法』フレデリック・テイラー
『企業・市場・法』ロナルド・コース
『経営行動』ハーバート・サイモン
『オーガニゼーションズ』ハーバート・サイモン、ジェームズ・マーチ
『現代の経営』ピーター・ドラッカー
『マネジメント』ピーター・ドラッカー
『組織の経済学』ポール・ミルグロム、ジョン・ロバーツ
『キャプランとノートンの戦略バランスト・スコアカード』ロバート・キャプラン、デビッド・ノートン 
『マネジメントの世紀』スチュアート・クレイナー
『昇進者の心得』リンダ・ヒル
『組織の罠』クリス・アージリス
『マネジャーの実像』ヘンリー・ミンツバーグ
『戦略サファリ』ヘンリー・ミンツバーグ、ブルース・アルストランド、ジョセフ・ランペル
『世界標準の経営理論』入山章栄

■■プロダクトマネジメント
『プロダクト・マネジャー―開発から販売までの新しい布陣』ゴードン・エバンス
『プロダクトマネジメント―新製品開発のための戦略的マーケティング』グレン・アーバン、ニキルシュ・ドラキア、ジョン・ハウザー
『トヨタ自動車開発主査制度』塩沢茂
『スバル360開発物語』桂木洋二
『クラウン開発物語』桂木洋二
『主査 中村健也』和田明広
『P&Gウェイ』デーヴィス・ダイアー、ロウェナ・オレガリオ、フレデリック・ダルゼル
『製品開発力』藤本隆宏, キム・クラーク
『凄い製品開発』ジム・モーガン、ジェフリー・ライカー
『プロダクトマネジャーの教科書』リンダ・ゴーチェル
『世界で闘うプロダクトマネジャーになるための本』Gayle Laakmann McDowell、Jackie Bavaro
『プロダクトマネジメント』Melissa Perri
『プロダクトマネジメントのすべて』及川卓也、曽根原春樹、小城久美子
プロダクトマネジメントの歴史と進化 by Martin Eriksson 角正典
https://medium.com/waicrew/%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E3%81%AE%E6%AD%B4%E5%8F%B2%E3%81%A8%E9%80%B2%E5%8C%96-e0d444f89615

ここ数年オンラインイベントが当たり前になりましたね。

おかげで香川の田舎からでも各地のイベントに参加できるようになりました。
今まで参加してみたかったあのイベントに参加できるようになった、交通手段や宿泊のことを考えずに気軽に参加できるようになった、私と同じような人は多いのではないでしょうか？

でもなんだか満たされない人はいませんか？
イベントに現地参加していた頃のような、活気や熱気、情熱、ワクワクドキドキ。

そして田舎だろうと、ネットワークさえあればオンラインイベントが開催しやすくなった反面、各地で開催される魅力的なイベントとの差別化、特色を考えることに悩むようになりました。

オンラインが当たり前になった地方コミュニティ活動で、次にやろうとしてること聞いてください！

「どうしてXXXやってるんですか？」
「え？(これ当たり前じゃないの？)」

新しいメンバーと一緒に仕事をする時や自分の取り組みををチーム外で話した時に、こんなやりとりが生まれることがあります。
そして、いざ「当たり前」を説明しようとしても、意外と言語化できてないことに気づきます。

とある仕事の中で無意識のうちにやっていた考え方・行動が、自分の想像以上に興味を引くものだとコメントを貰いました。
それを受けて、自分の取り組みを社内で発表することになり、無意識にやっていた「当たり前」にどんないいことがあるのか・誰でも実践できるものなのかなど言語化を試みました。
その「当たり前」を説明するための言語化に手ごたえを感じつつも、なぜか心のどこかで受け入れられない感覚がありました。

「自分が実践し始めたのはそんな理由だったのか？もっと自分の感情から生まれたものだった気がする......」

自分の中で「当たり前」になる前の何かに重要なヒントを感じつつ、答えが見えないまま時間が過ぎていき、時には自分の行動に自信を持てなくなりました。
それでも諦めず、深掘りと揺さぶりの問いを駆使して「当たり前」と向き合い、試行錯誤する中で見えてきたものについてお話しします。

こんにち、世界！
どうも、ただのテスターです。

みなさんは新しいチームに加入した時どんなことをしますか。

オンボーディングを実施しただけでは、なかなかチームに溶け込むことは難しいですね。

特にテスターは、チームのメンバーに情報共有してもらわないと仕事ができないので、チームメンバーに信頼してもらい、チームメンバーとして溶け込む必要があります。

今回は、中途入社したテスターの私が、スクラムチームへ溶け込むためにした幾つかのことを紹介したいと思います。

素朴理論なので他の人に参考になるかはわかりません。
中年のテスターが新しい会社に転職してどのように振る舞い、溶け込むためにもがいたかの事例を雑に紹介します。

開発すればするほど製品やサービスは複雑で多くなり、依存関係があったり、制約があったり、負債が多く大きすぎたり、様々な対応を行わなければならず開発スピードは落ち、バグも増えていくことになります。

そんな製品開発の組織での QA・テスト の関わりを紹介したいと思います。