ono 株式会社ふくおかフィナンシャルグループ様にて、3回にわたりアジャイル開発の社内勉強会を開催しました。
今回は勉強会を企画したご担当者さまをお迎えし、勉強会後に見えてきた組織やメンバーの変化や手ごたえについてふりかえりました。
株式会社ふくおかフィナンシャルグループ様について
株式会社ふくおかフィナンシャルグループは九州を拠点とする総合金融グループです。
今年、地方銀行グループとして初めて、経済産業省と東京証券取引所などが発表する『デジタルトランスフォーメーション銘柄（DX銘柄）2022』に選定されました。国内初となるデジタルバンク「みんなの銀行」への取り組みや、お客さまのに寄り添う「実証実験プロセス」の導入等が高い評価を受けています。
◆話し手
株式会社ふくおかフィナンシャルグループ
松崎 一孝 さま
社内スクラムマスター
行内のToC、ToB向け2つのチームでスクラムマスターを担当。
また組織としてアジャイルに取り組んでいけるように、組織に対する働きかけやアジャイル推進なども担当している。
石躍 大地 さま
ToB向けプロダクトの新人プロダクトオーナー。2022年5月から参加。
現在取り組んでいるプロダクトが大きいため、プロダクトオーナー3人体制で分担中。
株式会社レッドジャーニー
市谷 聡啓 Toshihiro Ichitani
株式会社レッドジャーニー 代表 / 元政府CIO補佐官 / DevLOVE オーガナイザー
サービスや事業についてのアイデア段階の構想から、コンセプトを練り上げていく仮説検証とアジャイル開発の運営について経験が厚い。プログラマーからキャリアをスタートし、SIerでのプロジェクトマネジメント、大規模インターネットサービスのプロデューサー、アジャイル開発の実践を経て、自身の会社を立ち上げる。それぞれの局面から得られた実践知で、ソフトウェアの共創に辿り着くべく越境し続けている。
訳書に「リーン開発の現場」、著書に「組織を芯からアジャイルにする」「デジタルトランスフォーメーション・ジャーニー」「カイゼン・ジャーニー」「正しいものを正しくつくる」「チーム・ジャーニー」「いちばんやさしいアジャイル開発の教本」がある。
中村 洋 Yoh Nakamura
株式会社レッドジャーニー
CSP-SM(認定プロフェッショナルスクラムマスター)
CSPO(認定プロダクトオーナー)
様々な規模のSIerや事業会社でのアジャイル開発に取り組み、今に至る。現在まで主に事業会社を中心に40の組織、80のチームの支援をしてきた。
「ええと思うなら、やったらよろしいやん」を口癖に、チームや組織が自分たちで”今よりいい感じになっていく”ように支援している。
【発表資料】 「いい感じのチーム」へのジャーニー、チームの状況に合ったいろいろなタイプのスクラムマスターの見つけ方、アジャイルコーチが見てきた組織の壁とその越え方、など多数。
目次
勉強会の内容
DAY１：上手く進んでいるプロダクト開発やチーム・組織について学ぼう
代表の市谷によるセッション 『仮説検証とアジャイル開発の両輪 なぜ仮説検証とアジャイル開発がいるの？』
DAY２：PdM（プロダクトマネジメント）、PdMO（プロダクトマネジメントオフィス）について知ろう
代表の市谷によるセッション 『プロダクトマネージャーはアジャイル開発で何を担うのか？』
DAY３：DAY１、DAY２ を受けての質疑応答
Frame1：リファインメントが長くて疲れます
Frame2：リリースした機能の検証・結果確認をどうやって管理していますか？
Frame3：スクラムで開発しているプロダクト、毎回のスプリントが上手くいかない
Frame4：レトロスペクティブで良かったことが挙がらない
Frame5：ふりかえりを同じ型でやると不安になるけど、どうする？
社内勉強会を終えて
今回の社内勉強会、いかがでしたか？
レッドジャーニー中村（以下、中村）：今回の社内勉強会をやってみた印象や、ご参加いただいたみなさまの様子などはいかがでしたか？
ふくおかフィナンシャルグループ 松崎さま（以下、敬称略）：今回、「自分自身もチームや周りの人にも、いろいろ知ってもらったり、気づきを得られたらいいな」と思い勉強会を開催しました。そういった意味では、話を聞いてやる気になった人もいたし、参加したプロダクトオーナーもだいぶ刺激や勉強になったと思います。参加した後に飲みに行って「ああだよね、こうだよね」と熱い思いを発言する人もいたので、やってみて良かったと思います。
中村：「まわりを巻き込みたい」というきっかけがあった中で、巻き込める人も何人か出たなといった感じですね。石躍さんはいかがですか？
ふくおかフィナンシャルグループ 石躍さま（以下、敬称略）：私もすごく刺激を受けました。私は市谷さんの『アジャイル教本』を読んでいたのですが、話を聞いてると自分の中でモヤモヤしていることを言語化してくれているような感じがして。
すごく刺激を受けたので、またいろいろと本を読み始めたり、CSPO（認定スクラムプロダクトオーナー）のセミナーや資格を取る講習会も受けに行く予定です。あとは「社内の他部署でも似たような悩みを持っている人がいたんだ」ということがすごく発見になりました。
中村：アジャイルの教本を読んでもまだモヤモヤしていたところが、社内勉強会で市谷さんのセミナーを聞いたりディスカッションしている中で晴れていったという感じですね。また社内に他にも仲間がいることが分かったというのもいいですね！市谷さんはいかがでしたか？
レッドジャーニー市谷（以下、市谷）：今回はプロダクト開発の基本的な話を忠実にしていったので、何かしら得ていただくものはあったのかなと思います。みなさんは、いわゆるSoR(Systems of Record：記録のシステム)と、SoE(Systema of Engagement：繋がりのシステム)という分け方でいうと、SoR側ではなくエンドユーザーから見えるプロダクトづくりをされているのですか？
松崎：はい。わりとそちらの方が多いです。
中村：そうですね。勉強会に参加された方たちも、灰色の世界で仕事しているというよりは「ユーザーにとって良い価値を届けたい！」といったお話しをされている方が多い印象がありました。
市谷：そうですよね。ですからプロダクト作りやプロダクトマネジメントは、まだまだこれから獲得していくような領域なんだなと想像するのですが、みなさんはそういうことに関心が高かったり、組織として取り組まなければなという機運は高いのでしょうか？
松崎：その機運は高いと思うのですが、なにせ今まで積み重ねてきたものが少なく、始めて数ヶ月といったわりと経験が浅いメンバーが特にビジネス側に多いので。開発側には中途入社で入ってきたメンバーもいるのですが、ビジネスを考える側はずっと銀行で育ってきた人が多いんですよね。
中村：これは私のイメージですが、やはり銀行とか金融というと堅い印象があるじゃないですか。だからこういう話をすると「うちの業界では…」とか「うちのところでは…」と、無理な理由がどんどん出てくるのかなぁと思っていたんです。実際よくある話ですし。だけどあのときは比較的「前に進むためにはどうやったらいいか」とか「他の現場ではどうやっているか」、「知見を取り入れたい」といった前向きな話しが多かった。先ほどの市谷さんの話のように“やっていくぞ感“があって、ちょっと驚きました。
松崎：あまりそういった発言は聞かないですが、参加しようというマインドがある人には受け入れ感がありますよね。業界的な言動が出そうなのは、むしろ参加しなかった人たちかもしれないな。
目指したい理想と現実のギャップはどう埋める？
中村：PdM（プロダクトマネージャー）やPdMO（プロダクトマネジメントオフィス）の話も多かったですが、他に印象に残っている話などありますか？
市谷：そうですね。3回の勉強会をやったからといって、すぐにプロダクトマネジメントやアジャイルなプロダクトづくりができるかというと、そんなに簡単なものではないと思うのですが、その上で「どういったところがみなさんの立ち向かうところになるのかな？課題って何だろうな？」ということを改めて聞いてみたいなと思います。
松崎：やはり感じるのは「できるだけ小さなコスト、リスクをかけない仮説検証をしていきましょう」ということだ思います。そして「なぜか大きく約束をしてしまう」というのが課題かなと思います。わかってはいるけれど経営層向けに「こういうことをやります！」と大きめの約束をバッチリしてくる。そして実際に取り組むときに「これ約束してきたから、やるしかないよ」みたいな話になって…。
市谷：そういう”オーバーコミットメント気味の話”って、どうして起きるんでしょうね？
松崎：どうしてでしょうね。私は役員向けの説明をしたことがないんですが…難しいんですかね？
中村：そのあたり、石躍さんはプロダクトオーナーとして思うところなどありますか？
石躍：それは松崎さんのおっしゃる通りです。「お客さんの検証をしてから考えたり作ったりしましょう」という話をするのですが、「もうこれは作ることが決まってるから」といった感じで。勉強会をした上で「理想と現実にはギャップがあるんだな。そこを一歩一歩どうやって埋めていったらいいんだろう」と強く感じています。「仮説検証アジャイルは目指したいけれど、現実は違うな」ということを課題に思いました。
中村：目指したいこととの距離やギャップ、幅の高さを感じたということですよね。これはどう埋めていったらいいんでしょうね？
市谷：全体の構想のようなものはそれなりの構想感が求められるのだと思うので、今のようなお話はあると思います。そういう全体の中で最初に取り組むのは、こういったMVP（Minimum Viable Product:必要最小限の価値を提供できるプロダクト)ですよという”話の立て付け”がつくれるかどうかだと思うんですよね。
やはりそれなりのものをつくろうと思えば、それ相応の時間と予算が必要なわけで。それがガラクタでしたとなったときに「コストはこれだけかかりました、これで終わりです」といったことが許容できるかというと、それはなかなかじゃないですか。だからその「許容できる範囲でやっていきましょう」という話は、わりと合理的だとは思うんです。ある意味その方が経済合理性がある感じもするので、そういう合意形成の仕方なんじゃないかな。
中村：市谷さんが前に話していた「1人で始めるところからやってみる」というのもいいのかもしれませんね。1人でできる範囲の仮説検証ってありますよね。「上に許可を取ってインタビューします」というものではなく、「自分の知っている人にインタビューしてみたらこんな反応なんですよね」くらいのところから始めるというのもありかなと思います。
石躍：以前に比べたらそのギャップもかなり埋まってきたと思うこともあります。私がこの部署に来た4年前は、検証もせずに「やると決まっているから、やっていた」という感じでした。でも最近は「ちゃんと検証しよう！」ということになっていますし、上層部とのディスカッションの中でも「これって本当にやる価値があるんですか？」という質問が出ることもある。そのあたりの意識はだんだんと醸成されてきていて、着実に進んでいる気はしています。
松崎：そうですね。いま新人POたちが関わっているのが経営層肝いりの主要なプロダクトなんです。だから気になるのかなという気もしています。そうではないところでは、わりと小さく始めて検証して「これいけるじゃん！」となって、実験した後に商用化していくというプロダクトもいくつか出てきています。ものによりけりな感じはしますね。
中村：経営層の関心によっては「やるんや！」といった話になったり、そうでないところはわりと自分たちでやれたりということですね。
松崎：はい。経営層が明確に株主に「これをやります」と言ったプロダクトは、やるしかないんだろうな…。でもきっと約束しているのは大枠だけで、細かいことまでは話していないと思うので、中身を検証して必要なものに変えていくといったことを上手くやれるようになると良いのかもしれないですね。
中村：大企業の中で”経営層が勝手に約束しちゃうパターン”はどうしたらいいんですかね。
市谷：うーん。まあ、そういう仕事もありますよね（笑）全部が全部そういう仕事だと大変ですけど、そうやって違う取り組み方を徐々に見せていくことも必要なんだと思うんですよね。
松崎：だからある程度は経営層やステークホルダー向けの需要を満たした上で、じゃあそこからどうやっていくのかという感じですかね。まずは自分たちが取り組んでいることに対しての価値を認めてもらって成果を出した上で、「自分たちはもっとこういうことに取り組んでいきます！」ということを上層部に広げていくのがいいのかな。
中村：そうですね。いまでも小さくできているところもあるということなので、アジャイルの型や仮説検証の型、その成果や学びのようなものを言語化して、お二人が現場に伝えることで「こういうやり方もできるんだ」と上層部にちょっとずつわかってもらえるといいのかなと思いました。
松崎：数年前だったら完全に”ベンダーに100％丸投げ”する状態だったので、「自分たちの肝いりのプロダクトを自分たちでつくっていこう！」ということになっているだけでも、だいぶ進歩はしている気はします。
市谷：松崎さんや石躍さんが全社的にどんどん発言していけるように、ポジションを上げて偉くなっていかないとですね（笑）。
松崎：（笑） 実は先日、うちの本部長がスクラムマスターのトレーニングを受けたんです。私の勝手なイメージですが、銀行の部長がそういうものを取りに行くって、だいぶ画期的なことだなと思って。私が「受けに行ってくれませんか？」とすすめたら「行きます」といってくれたんです。
中村：へー！すごい。石躍さんはご存じでしたか？
石躍：まさに松崎さんがおすすめしているところを後ろで聞いていたんですけど、恐る恐るながら「じゃあ…行ってみる。」といった感じでした。部長も知ろうとしてくれている方で、「スクラムってなんだろう？アジャイルってなんだろう？」と興味を持たれていたので、ちょうどよかったんだなと思いました。
アジャイルな取り組みを、縦に広げるための”次の一手”
中村：地道な広がりが出ている感じですね。私たちが支援しているとき、開発チームからプロダクトさらにマーケッターとかCSといった横の広がりは当たり前にあるのですが、開発チーム、プロダクト、事業部、組織といった縦のラインは難しいんですよね。上に広げていけるとガラッと世界が変わりそうですよね。松崎さんや石躍さんが偉くなるとそういう世界に行けるのかな。市谷さんは縦の広がりへの次の一手として、おすすめのものはありますか？
市谷：やはり上に広げていく方法としては、事業側の人たちを巻き込んでいくような動きがいいと思います。いまみなさんはどういった部署にいるんでしたっけ？
松崎：ビジネス開発部（取材当時）とDX推進部（取材当時）です。石躍がいるビジネス開発部は新規事業をつくる部署で、ビジネス企画を考える人もいますし開発する人もいます。DX推進部は全社的にDXの取り組みをアジャイルに限らず全社戦略として考える部署です。いまメインとして動いているのはその2つの部署ですね。
市谷：それはすでに事業部門も巻き込んでいるということですか？
松崎：そうですね。その中に事業部門の人もいるといった感じです。ただ他にもたくさん部署があるので、全部が巻き込めているわけではありませんが。
中村：上に広げていく方法として、私は2つほどあるなと思います。1つは「実際に使うユーザーとの接点をどれだけもてるか」ということです。自分たちの中だけで話していると堂々巡りになり、力関係もあってなかなか進まなかったりする。でも実際のリアルなユーザーが「こんなふうにいっていて、こんな反応を見せている」と知ることは、人が動く原動力の1つだと思うんです。だからその距離を縮めることができるかが1つの方向かなと思います。実際にユーザーに会うとインパクト強いんですよね。そういうことはやっておられますか？
石躍：インタビューは2か月で80社くらい行っていて、直接話を聞きに行こうという動きをしています。
中村：おー！すごい。そこでの手ごたえはありますか？「分からないことが分かってきたぜ！」とか。
石躍：ありはするのですが、それをどう活かすかなんですよね。やはりまだリサーチが得意ではないので、聞きたいことを聞いてしまう状況がけっこうあります。そこをどうにかしなければと思い、取り組もうとはしています。
中村：仮説検証の左の輪っかは何となく回っているけど、質の良い回し方になっているかというとちょっと…という感じですかね。でもいい取り組みだと思います。
もう1つは、私と市谷さんが現場や組織を支援するときによくやる方法なのですが「組織自体をイテレーティブ（反復的）にやる」ということです。2週間に1回ぐらいスクラムっぽいイテレーションでやって、経営やマネージャークラスも一緒になってスクラムイベントのように仕立ててやることは多いですね。
チームの中での共通の言語ってなんだろう
中村：では、ここからはお二人の疑問や質問を伺いたいと思います。プロダクトづくりやプロダクトマネジメント、アジャイルなど、どういった観点でも大丈夫です。石躍さん、いかがですか？
石躍：お話を聞いて”越境”ということを意識するようになり、これからは歩み寄るようなこともしてみようと思いました。そこで試してみたのが、アウトプットではなくアウトカムを目指すために、各ストーリーに検証項目という目標をつけることです。「この機能をつくったことでお客さまにどのような価値を提供することができたか」を確認する取り組みを継続しようと思っています。
また「POから開発者に歩み寄ること」も大事だと考えたのですが、具体的にどうすればよいのかわからなくなってしまって。とりあえず、いまがむしゃらにやっているのは「開発者ってどんなことでつまづくんだろう？」と、ソフトウェアテストの勉強をしています。他にどんなことをすれば「このPOは理解があるな」と思ってもらえるのででしょうか？
市谷：それは石躍さんのスタンスとして非常に重要なことだと思うんですよね。「開発チームにとって何が制約で、何が困るポイントか」ということを知っておくことは、チームとしてともにやっていく上で重要なこと。だから彼らがどういう仕事をしているのかを知ろうとすることは、とてもいいことだと思います。
結局、話をするための共通の言語、語彙、言葉といったものがないと話もできないので、できるだけ言葉を持つことはいいことだと思います。それがテストなのかプロマネなのか、プログラム言語に関することなのか。それはどれでもある意味「言葉の獲得」になるので、「プロダクトづくりで一番ホットなテーマって何だろうな？」というところから調べてもいいんじゃないかなと思います。
ただ一方で、ここが言いたかったことなんですが、歩み寄る姿勢はいいのですがチームって対等の関係だと思うんですよね。そういう意味でいくと、知ろうとするスタンスは持ちつつも一方でチームの中での共通の言語ってなんだろうなというのはあって。一方的に石躍さんがすごく苦労して開発チームのお世話や手を焼いてやろうというのは、長期的に見るとそういうことではないよね、と思うんですよ。
プロジェクトチームの共通言語は間違いなくユーザーなんですよね。だから「プロダクトを使う人が誰で、どんなふうに使っていてあるいは使えてなくて、どこがうれしくてどこに問題があるか」といったことを、どれくらいチーム全員が知っているか。POだけではなく開発チームのみんなもそれを知っているからこそ「フロントをどう作るべきか、どんな機能があるべきか」といった話が、ちゃんと自分たちで判断できるようになる。つまりお互いでユーザーのことをもっと理解し合おう、その理解の度合いの格差はできるだけ双方で合わせたり深めたりしていきたいことかなと思います。
中村：私もいまお話を聞いていて、まず石躍さんはとてもいいプロダクトオーナーだなと思いました。「わからんからやってぇや」といった感じのプロダクトオーナーもいる中で「何が困るんだっけ？」と理解しようするのはとてもいい姿勢だと思います。
開発者の信頼を得るためには、例えばプロダクト部も一緒にモブプロ（モブプログラミング）入ってみることですね。そんなにむっちゃ書けないけども、次これ書いてと言われたら自分で書いてみて、「あ、こんなふうに画面が変わるんや」といったりして、そういうことを一緒にやってみたら理解も深まるのかなと思うんですよね。
一方、何のためにやるかというと「良いプロダクトを作るため、ユーザーが喜ぶため」だから、センターにはユーザーだったりプロダクトがあるべき。そこが変にお互い仲良しこよしになりすぎると、それって落ちてしまうと思います。「これってユーザーは喜ぶんだっけ？」とか、「この仕様はないでしょ、このコードはないでしょ」といった話をちゃんと伝えないと、いいプロダクトにならないしユーザーも喜ばない。「いいものをつくるために、お互いプロとして責任を果たそうぜ」といった土台となる信頼関係があった上で緊張関係があって、プロとしてやるというのがいいなと思うので、そのあたりが伝わるといいですね。
石躍：確かにPOとしての本分やメインの役割は忘れずにやらないと、そちらばかりに意識を割いてしまって（メインが）おろそかになることが一番よくないですもんね。
中村：スクラムガイドにも書いてあるように、プロダクトオーナーは自分も含めたチームのつくったプロダクトの価値を最大化することが仕事であり責任ですからね。
松崎：そういった意味では、さっきのテスト（を勉強すること）はちょっと行き過ぎているのかな（笑）。「開発者を理解するためにテスト学びます」ではなく、「良いプロダクトにするためにテストを学びます」という感じが、プロダクトオーナーっぽいかな。
中村：そうそう。「ユーザーは何を気にするのか」という意味でユーザーテストを学ぶといったことは、とてもいいアプローチかもしれません。そういう意味では一緒にユーザーインタビューに行ってみるのもいいかもしれませんね。
石躍：以前からインタビューにはデザイナー1人と開発メンバー1人も参加してもらうようにしているので、それは続けようと思っています。
悩めるプロダクトオーナーにかける言葉とは？
松崎：現在、新人プロダクトオーナーが3人いるのですが、その人たちにどういうアプローチを取ればいいのか、どういうことを伝えていけばいいのかなと考えています。お二人は新人プロダクトオーナーにどのように接していますか？
市谷：どこまで許容されるかによって取り組み方は違うと思いますが、一巡することが大事だと思っています。POがやるべきことをできるだけ早く、1年に一巡とかではなく、3か月ぐらいで一巡させるくらいのつもりで体験させるような状況を作ってあげたい。それはもうサンドボックスみたいなもので、べつに成功しようがしなかろうが関係なく、そういうシチュエーションの中でやっていくという経験を1回通してみるということはやってもらいたいと思いますね。
中村：よく見かける”小さくまとまっちゃうPO”は、上の方がいったことをバックログ化してプロダクトバックログにして、それを開発チームとコネコネ仕様をつめて、できたものをスプリントレビューという名のよくわからないお披露目の場で見せて終わり、みたいな人。こういったことをやっていると、そこに小さくまとまっちゃう。
プロダクトロードマップをつくるとき、ロードマップの手前にはプロダクトのビジョンやありたい姿などがある。そのためにユーザーインタビューをしたり仮説検証して、つくって出して、ユーザーフィードバックどうだった、じゃあロードマップをどうやって行くか、あわよくばお金儲けはどうするかというところまでを、3か月や6ヶ月で一巡できるとだいぶ強くなると思います。結果的に儲からなくてもよくて、回すことが大事。「プロダクトオーナーはバックログアイテム作成機ちゃうぞ」ということがわかればいいと思いますね。
市谷：手順的な観点でいろんなものを知るとか身につけるといったことは、瞬間瞬間、場面場面でやるんですけど、それに焦点を当ててしまうと”手順型PO”になってしまう。やはりそれでは次に進めないので、多少ラフでも経験を通してやってみて、そこから「どうしたらよかったのか、何が原則的に大事なのか」を学び直すようななことをやっていった方が、かえって早いんじゃないかなと思うんですよね。
何が手順的に正解なのか”正解を求める人”になってしまうと、見ようによってはむしろ遠回りになってしまう気がします。正解なんかどこにもないなかで、自分で見つけていかなければならないし、そういうことを経験のなかで知っていってもらうようなことができるといいなと思います。
中村：よく”プロダクトマネージャーはミニCEO”ということがあります。でも私個人的には”プロダクトオーナーはプロダクトの価値を最大化するためにがんばる人”なので、どちらかというとバックログをスプレッドシートで管理するといったことはどうでもよくて。でもそっちに行っちゃうんですよね。
むしろ「自分のお財布でこのプロジェクトを育てるとしたらどうするの？」といったことを早く経験できるといいなと思う。「どんどんやっていこうよ！」と背中を押してあげたり、迷っているなら「バックログの整備ではなく、どうやったらお金儲けられるか話そうよ」といった声掛けがいいかなと思うんですよね。
松崎：確かにいま（POたちは）いろんな人からいろんなことを言われて悩んでるようなので、まさに”自分のお財布”というのは大事だなという気がします。「悩んだ時にはどうしたらいいですか？」と聞かれることがよくあるのですが、「じゃあ自分のお財布を使うならどうなんだい？」という声掛けはいいフレーズだなと思いました。
中村：私はよくいいますね。「その機能を自分のお金で出すとしたら、つくる？」って聞いたら「つくりません！」って（笑）。だったら何か別の方法とろうやって話ですよね。あとは新人3人のプロダクトオーナー相談会というか、プロダクトオーナー同士のコミュニティがあるといいのかなと思います。
いま1つのプロダクトを3人で担当しているとのことなので、わりと仕事の話はしていると思うんですね。それとは別に、「成長するために何をする？」といった話だとか、「プロダクトオーナーって何が大事なんだっけ？」という話を、その3人や、松崎さんや外のアジャイルをよく知っているファシリテーターの元で話すと、視座など何か変わるかもしれないですね。他の現場でもよくやっています。
石躍：松崎さん主導でプロダクトオーナーの集いを開催しているのですが、視座の高い話はできていなかったと思います。「プロダクトバックログはどう分ける？」といったような話をしていたので、もう少し視座を上げて「いまのプロダクトの価値を最大化するためにはどうする？」といった話をしていくと意識が変わるかもしれないと思いました。
中村：市谷さんの本などをみんなで読んで、議論してみるのもいい機会かなと思いますね。
石躍：今度『正しいものを正しくつくる』の輪読会をしようかと思っています。
市谷：おー！ありがとうございます。
松崎：勉強会のあと組織的にもだいぶ変わってきていて、「数か月前は全然わからなかったけど、いまもう1回話を聞いたら、きっともうちょっとわかることが増えてるんだろうね」と話す人もいました。スクラムマスターの講習を受けにいった本部長も「トレーニングは知識が足りなくて全部は消化できなかったけど、もう1回数か月後に受けに行きたい」と話してくれました。
中村：いいですね！ぜひ行ってみたらいいと思います。コーチでも何回も受けに行きますからね。3か月後か、6か月後かは分からないですけど、輪読会が終わったときに市谷さんが呼ばれて行って「いまこんな現場になってるよ」といった話を聞けるのが楽しみです。またいつでも呼んでください。本日はありがとうございました。
市谷聡啓 著 『組織を芯からアジャイルにする』
組織を変えようと藻掻くすべての人へ
DXの名のもと、変革が求められる時代。
組織がその芯に宿すべきは、「アジャイルである」こと。
本書は、ソフトウェア開発におけるアジャイルのエッセンスを、「組織づくり・組織変革」に適用するための指南書です。
ソフトウェア開発の現場で試行錯誤を繰り返しながら培われてきたアジャイルの本質的価値、すなわち「探索」と「適応」のためのすべを、DX推進部署や情報システム部門の方のみならず、非エンジニア/非IT系の職種の方にもわかりやすく解説しています。
アジャイル推進・DX支援を日本のさまざまな企業で手掛けてきた著者による、〈組織アジャイル〉の実践知が詰まった一冊です。
詳しくは特設ページをご覧ください。
shin-agile.link販売ページはこちらです。
redjourney.jp