ファーストペンギンを 志す者に伝えたい！ １人目のアジャイル推進者が辿った成功と失敗 Satoshi Harada

自己紹介 Satoshi Harada Twitter : @harada_psj Role : Engineering Manager Career : 1000名規模SIer (Role:SE, PjM) →Trustia (Role:WebApp Engineer, ScrumMaster) →2000名規模SIer (Role:WebApp Engineer, ScrumMaster) →SaaSスタートアップ (Role:EM) 本日のセッションは、 ここでの経験をもとにお話します

https://unsplash.com/photos/_g1WdcKcV3w あなたは１人目のアジャイル推進者です

まず何をすべきか

観察 ● まずは現状をよく観察する ○ 現状の開発プロセスや承認フローをよく理解する ○ 開発のアジリティを損なうようなボトルネックが どこにあるのかを探す ○ 改善に向けた作戦を立てる

トップダウンかボトムアップか ● どちらも必要 ○ 組織ルールなど、上位者からしか変えられないこともあ る。上位者の承認と信頼を得ていればスムーズに進む ○ 上位者からの「アジャイルやるぞ」では自律的なチーム からは遠ざかる ■ 上位者の承認と信頼を取り付けたうえで、あくまで も現場主導でアジャイルの推進は行いたい

観察の次の一手

勉強会 ● いきなり本番でやらない。 野球をやったことがない人がいきなり試合に出たりしないのと同 様、まずはルールとフォームを覚える必要がある。 ルールは座学で、フォームはディスカッションやワークショップ で身につけてもらうのがおすすめ。 ● 勉強会も、上位者の合意を得た上で。しかし、あくまで現場主導 ● 勉強会も繰り返し・漸進的に ○ 1日の勉強会1回よりも、30分の勉強会を 週1回・1年継続してやったほうが良い ● 勉強会で仲間になってくれそうな人を探す ○ 誰とバスに乗るかはとても重要 ○ バスに乗ってくれる人を探す

ルールとフォームを覚えたら実践だ！

チーム開発での実践(1) ● どのようなメンバーでチームを組むか ○ クロスファンクショナルなメンバー ○ フィーチャーチーム とは言っても、なかなか何でもできる メンバーは最初から揃わない。 ● チャレンジ精神 ● 柔軟な発想 ● 越境力

チーム開発での実践(2) ● やってくれるチームだという印象を獲得する ○ 小さくても良いので成功体験を積み上げて、実績を公開する ■ 「自分たちはできるチームなんだ」という自己評価 ■ 「あのチームはやってくれる」という他者評価 両方を、小さくてもよいので手に入れたい。

チーム開発での実践(3) ● いきなり完璧を目指さない ○ WIPや完了の定義など、最初から完璧を目指すには難しい概念 もある ○ まずはスクラムフレームワークに則って、スプリント計画・ 朝会・スプリントレビュー・ふりかえりというイベントのワク から入るのでもよいと思う ■ その中でも改善サイクルを回すふりかえりを特に重視したい ■ なぜそのイベントを行うのかのWhyも併せて考えてもらう

で、実際のところ上手くいったの？

ふりかえり(KPTのKP) ● Keep(上手くいったこと) ○ アジャイル・スクラムの文脈が無かった組織に、アジャイル・スクラムやって いこう！という流れを上位者・メンバーともに持ってもらうことができた ○ 週1回30分の勉強会を約50回開催し、自分の所属組織だけでなく他拠点の組織の メンバーにも参加してもらえた ■ アジャイルソフトウェア開発宣言の4つの価値・12の原則のディスカッション ■ スクラムフレームワーク ■ アジャイルなチームビルディング（エレベータピッチ、インセプションデッキ） ■ アジャイルな見積 ■ タスクかんばん ■ バーンダウンチャート　などなど ● https://www.slideshare.net/satoshiharada3/presentations ○ 受託開発にスクラム適用（小規模3件） ○ 自社SaaSプロダクト開発にふりかえりや規模見積といったプラクティスを導入 ● Problem(上手くいかなかったこと) ○ 受託開発契約の壁（請負契約 / 準委任契約） ○ 組織ルールの壁（エンジニア稼働率 / 兼任 / プロジェクト型のチーム体制） ○ 現状維持バイアスの壁

Problemをもう少し深堀り ● 受託開発契約の壁（請負契約 / 準委任契約） ○ 請負契約×スクラム、悪いことは言わないから止めましょう💀 ○ 準委任契約×スクラムが前提条件 ■ 受託開発の場合は準委任契約になるよう、契約前からアプローチしたい ■ 逆に、請負契約と決まっているのなら、きっちりとWFで固めた方が良い ● 組織ルールの壁（エンジニア稼働率 / 兼任 / プロジェクト型のチーム体制） ○ 組織のルールが自律したチームを阻害していることも多い ■ 稼働率が重視されてチームを跨いだ兼任になっているメンバー ■ プロジェクト期間終了とともに解散となるチーム ● これらは一朝一夕で変えられるものではない ● しかし、これらの制約の中でもアジャイルやスクラムを入れることはできる ● 完璧を目指すよりも、まずは始めよう。そして、新しいスタイルを発信し続けよう ● 現状維持バイアスの壁 ○ 現状を変えたくない人のほうが多いのだと理解しておく ■ 人を変えるのではなくまず自分から変わる・自らが発信する ■ 相手と自分の間にある壁を越境し、自分が相手の側にも立ち、壁にはしごをかけられそう なポイントを探し続ける（ナラティブ・アプローチ）

ふりかえり(KPTのT) ● Try(次への試み) ○ 壁を越境する！！ ■ 受託開発契約の壁 ● 契約の現場に食い込みたい ○ 提案の時点から営業と同行して顧客と会ってみよう！ ■ 組織ルールの壁 ● ボトムアップのアプローチはだけでなく、 トップダウンのアプローチについても知る必要がある ○ マネジメントやリーダーシップについて改めて学ぼう！ ■ 現状維持バイアスの壁 ● 人を知る必要がある ○ 傾聴や共感、心理学を学ぼう！

いざ踏み出そう！ https://unsplash.com/photos/PzAmR_Nt7KM