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

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

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

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

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

私が所属するチーム、その名も"momoten"。

このセッションでは、このスクラムチームがどのように開発を進めているのかを"できる限り細かく"紹介します！

他所の会社の他所のチームがどんなふうにスクラムを実践しているか、事例や会社の紹介で部分的に切り取って見ることはあっても、細かく観察できる機会はなかなかありません。

そこで今回は、あるスプリントを切り取って、実際の現場で使われているプラクティス、ツールはもちろん、チームの開発の進め方やコミュニケーションの取り方、各イベントの進め方まで、お見せできるギリギリまで詰め込んでお届けします。

あまり知ることができないリアルな情報を持ち帰れるお得なセッションになる予定です！

逆に「もっとこうしたらよくなりそうじゃん！」みたいなフィードバックをもらえたら私もお得でWin -Winです！

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

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

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

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

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

本プレゼンテーションでは、ここ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

フルリモートでスクラムチームに所属し、丁度半年が経とうとしています。

スクラムは既存のチームと異なり、個人やチームの問題点が可視化されるフレームワークであるという言葉通り、様々な困難に直面してきました。

中でも一番の相違点として感じたことはビジネス面や技術面の問題点を浮き上がらせるだけでなく、チーミングの問題点までも浮き上がらせることです。

今回のセッションでは個人の最適化ではなくチームとして、はたまた組織としての全体最適となる先駆けとしてどのようにチームを運営していくか、

そしてそこに持続可能性をどのように見出していくかを所属しているチームに対しての取り組み事例を交えてお話しできればと思います！

よろしくお願いします！

フルリモートに負けるな！チームの一体感を醸成し、同じ目標に向かって爆速前進するために行っている取り組みや想いをお話します。

取り組みの一例：wevoxやmiroを活用した相互理解ワーク、チームメイトを巻き込んだロードマップの作成、ほぼ月のわいわいチームイベント

聞いた人に一歩進む勇気が出る、栄養ドリンクのような発表を目指します！

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

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

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

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

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

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

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

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

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

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

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

20年のアジャイルの体験と、10年の心身のカイゼンの体験の類似性は「有機的成長プロセス」でした。それらの体験を元に『「アジャイル式」健康カイゼンガイド』という書籍を共著で執筆しました。

この本には、アジャイルマニフェストや原則、自身の体験を参考にした健康カイゼンについての価値・原則や継続のポイントなどを記しています。

身体や心の漸進的変容について記した本書ですが、実はその内容は実際のアジャイルチームの意識やスキルアップなどの成長・変化にも応用できます。

本セッションでは、ソフトウェア開発と健康の類似性に言及した後に、健康カイゼンの価値・原則を、チームの成長に応用する利点、

新しい健康概念に学ぶ、チームの成長の捉え方をご紹介します。

もちろん、個人の心身の健康にも役立ちます！

どのような利点があるのかをご紹介します。

こんにちは、世界。
新潟で、テストの街「葛飾」と仲間たちがソフトウェアテストの分析と設計について語ります。

みなさん、ソフトウェアテストはどうしていますか。

まさか、いきなり、猿みたいにテスト実施から始めていないですよね。

テストには、以下の主な活動からなるテストプロセスがあります。

• テスト計画
• テストのモニタリングとコントロール
• テスト分析
• テスト設計
• テスト実装
• テスト実行
• テスト完了

今回は、オンライン区長とテスターおおひらが、テストプロセスで特に好きなテスト分析とテスト設計について、実際にどうやっているかを話します。

ちなみに、
オンライン区長はオンプレパッケージ製品、テスターおおひらは業務系SaaSのテストを普段しています。

二人とも独学で始めて、10年経ちました。

テスト分析・テスト設計は業務に密接に関わるので、外で話すことはありませんでした。

そのため、かなり独自になっているかもしれませんので、あしからず。

もちろん、批評、反論なんでもござれ。

10年ぐらい考えた続けたテスト設計について、
みんなでワイワイディスカッション形式で語りますので、
よろしくお願いします。