福岡・札幌・東京メンバーで未経験のアーキテクチャに挑戦　アジャイル推進で得た “実践する仲間”と“横のつながり”

取り組み2 「実践する仲間をつくる」

担当者：次に、もう少しチーム寄りの取り組みとして「実践する仲間をつくる」ということをやっています。弊社の開発者は、開発を専門にしているグループ会社に所属していることが多く、だいたいここに示している7拠点が関わっています。

初めにアジャイルのチームを立ち上げた時は、福山のメンバーと一緒にやっていたのですが、他の拠点でも「チャレンジしたい」ということで、私は山形と東京と福岡の拠点と一緒にチャレンジしていました。

コロナ前から始めていたので、福岡に行った次の週には山形に足を運ぶ、みたいな時もあって、けっこう日本中をウロウロしていました。今日は、福岡トラックなので、福岡チームの話をしたいと思います。

福岡のチームは、自社事業の運営に関わるシステムを開発していて、メンバーのPO、スクラムマスター、デベロッパーはグループ会社に所属していたので、本体の会社とグループ会社というような垣根はなかったのですが、デベロッパーが福岡と札幌にいて、POと関係者は東京に所属しているという、日本を横断したような体制になっていました。その体制で、クラウドとかアジャイルとか、経験のないアーキテクチャに初挑戦するという背景がありました。

こういったタイムラインで初期リリースから経験を経ていて、「せっかく自社内でチャレンジするんだから」と、事業部門はすごく理解があったのですが、キックオフの前にデベロッパーがなかなか揃わないというところがありました。

社内では、経験の厚い開発者は兼任でいろいろなプロジェクトに関わっていたり、優先度の高い急を要するプロジェクトに引っ張られていったり、話を進めている中でもメンバーが入れ替わるということがありました。

そんな中、やっと揃ったメンバーが札幌と福岡のメンバーなのですが、そのメンバーが全員福岡へ集まって、チームビルディングしました。プロダクトオーナーも1週間とか2週間とか福岡に泊まって、開発陣と一緒にやるということから始めました。

やっぱりいろいろ勉強しなければいけないところがあったので、学習のオーバーヘッドがすごくて、そんな中でも「何かを出さなきゃいけない」というプレッシャーをチームは感じていて、はじめはすごく疲弊していました。

そんな大変な状況の中、コロナが途中で始まって、その影響で福岡と東京と札幌でリモート開発をするという環境になりました。そんな中でも、3ヶ月かけて初期リリースをするという、たくさんの初めてに向き合って適応していったチームです。

チームのマインドやパフォーマンスが積極的に変化した

初期リリースの後に経営層へ報告をしたのですが、その中に福岡チームの変化が書かれていました。ほぼ原文ですが、もともとデベロッパーに作業指示するような構造があったらしいんですね。POが指示したり、スクラムマスターが指示していたみたいなのですが、指示構造なく、要件からDevが関わるように変化したりだとか、始まった頃はデベロッパーが受け身だったのですが、主体性が向上し、積極的に変化していったという話が書かれていました。

このチームのメンバーは、全員それまで既存型のウォーターフォール開発しかやったことがなかったのですが、実際チーム開発を経験してみて「顧客の評価をダイレクトに受け取ることができる」だとか「分業制にならず関わることのできる範囲が広い」だとか「ドキュメント作成が目的にならなくて、前のプロジェクトに比べて働きやすい」という声が挙がっていました。

このチームの発表をきっかけに、現在の状況をプロダクトオーナーに聞きにいったところ「今でもマインドの変化やパフォーマンスの変化が継続的に見られていて、とてもいいチームだ」と言っていました。

こんなにも聞いたままのことが目の前に起こっていくのかということを、本当に不思議だと語ってくれました。現場の変化の空気を個人的にもすごく感じていて、これからも変われる可能性がありそうだなと感じています。今日のスクラムフェスにも、ここの開発チームから2人の開発者が参加してくれています。

初めてチームに入る時に工夫していること

このように福岡とか山形とか、いろいろなチームに入ってきたのですが、初めてのチームに入る時に、私が工夫していることがたくさんあります。

これだけで1つのセッションができる内容なのですが、一番気をつけていたのが、最後に書いている「プロダクトオーナーとスクラムマスターとこまめに話をする」です。

開発者は複数人いるのですが、プロダクトオーナーとスクラムマスターは初めてのことに対して1人で立ち向かわなきゃいけないので、常に話を聞いたり、相談したりしていました。

現場が変わる兆しがちょっとずつ出てきてはいるものの、プロダクトオーナーやスクラムマスターから話を聞いていると、チームの外から「投資の割に成果物が少ないのではないか」と不安視されていたり「アジャイルは労働時間が長くなる」という噂が立っていたり「リリースに間に合わないことが開発者の生産性の悪さのせいになっていたりする」というような話が漏れ聞こえるということがありました。

ほかにも「新しくやりたい」というチームに「なんでやりたいの？」と聞いたら「要件を柔軟に変えつつ、すべての機能開発を納期厳守することを期待されたり、要件が決まらなくても急な要件をいつでも受け入れてくれるやり方なんでしょ？」という期待があったり「アジャイルだと品質が悪くなるけど、大丈夫なのか」という認識があって、チームが変わる可能性があるけれども、その外からの力がすごくかかっているという気づきがありました。

アジャイルに対する正しい教育の必要性と品質ガバナンスの現状を全社推進のメンバーに共有

そこで現場の課題として、全社推進のメンバーに共有したことがこの2つです。アジャイルに対する正しい教育の必要性ですね。私たちの会社の成り立ちとして、受注産業で成り立ってきたというところで、受注体質が残っているというところがありました。

それゆえに、ビジネス部門と開発部門間の期待値ギャップがあるのではないかと思います。開発が製造のような立ち位置になってしまうというところですね。早く安く作れるという誤解も一部あって、間違った解釈が浸透していくことが大きなリスクでした。

もう1つは品質ガバナンスの面です。これまではウォーターフォールで、ISOの規定に則ったゲートガバナンスを適用していたのですが、それが適用しづらいという状況だったので、この2つが優先的に解決すべきことなのではないかと共有しました。

この共有が、開発部門のみならず、事業部門や管理部門への研修の実施につながっていたり、コーチを外から呼んだりなどの品質の取り組みにつながっています。

取り組み3 「個別チームだけではない、横のつながりをつくる」

このように、個々の開発チームにはポテンシャルがあるということが徐々にわかってきたのですが、なにぶん拠点も多いし、拠点の中でチームができあがったとしても、ほんの一角のチームなので孤立しがちなのではないかなと思って「個別チームだけではない、横のつながりをつくる」活動もしています。

それが「DXサミット」と呼ばれる、「Teams」でオープンに配信する社内勉強会です。この中では基礎的な内容だったり、社内の経験者の発表だったり、マネジメント層を巻き込んだパネルディスカッションもやってみました。

ここのサミットでは、他のテーマもいろいろ話されているのですが、アジャイルテーマでは、260人参加してくれた会もあって、私たちの事業部以外からの反応もありました。

この右側の写真が初めて私がやったカンファレンスですが、「突撃！　隣のアジャイル」というタイトルでいろいろな現場に話してみました。自分から発信すれば、組織を飛び越えて仲間が見つかるということがわかりました。

個別チーム内の暗黙知を形式知化していく取り組み

そのほかにも、ガイドラインだけではなくて、チームに散らばったプラクティスを集めています。推進のグループが始まった当時は「アジャイルガイドライン」という標準化的な背景があるガイドラインを作成していたのですが、弊社は新規開発から既存プロダクト開発、体制もチームの特徴もさまざまで、なかなか使うのが難しかった側面もあったり、初期のチームにはちょっと難しすぎたりというところがありました。

コーチのアセスメントを受けた時に「これはまだガイドラインじゃなくてプラクティスだね」と言われたという背景もあって、実践中の人たちを集めて、週次でプラクティス共有を実施しています。

この中では、デイリースクラムのちょっとした工夫レベルでもOKで、全社推進のメンバーにも任意で参加してもらっていて、現場を知ってもらっています。これは、個別チーム内の暗黙知を形式知化していく取り組みかなと思っています。

個人的にすごくしんどかったこと

まとめです。今日は、組織の動き、個人としての動き、どういったものをしてきたかをお話ししました。

組織としては、真のアジャイルを根付かせるため、社内を横断したアプローチ中です。その中で個人としては、さまざまな現場のチームの内外のメンバーの声を聞きながら活動して、組織の中で横のつながりを作る工夫もしてきました。言い換えると、トップダウンの動きとボトムアップの動きを連携しながらやってきたというところかなと思っています。

うまくいっているように聞こえるところもあると思うのですが、個人的にはすごくしんどいところもたくさんありました。今までプレイヤーとして動いていたので、プロダクトとチームへの関わり方がすごく難しかったです。

チームにどう関わっていけばいいのか、プロダクトオーナー、スクラムマスターとどう信頼関係を作っていけばいいのかが難しかったですし、会社の文化的に指示コントロールしてしまったり、御用聞きになってしまうマインドとの向き合い方をどうすればいいのかというのもありました。また、決定権限のない体制や業務理解が少ない状態を、いかに解消するかという側面もありました。

2つ目が幅広い知識の必要性です。私はバックグラウンド的に、開発をガッツリやってきたのではないので、スクラムだけでは片手落ちかなと感じるところがありました。現場によってはJavaだったりPHPだったりRailsだったり、さまざまな技術スタックの現場があるので、技術的プラクティスの経験の少ない自分がそこに入っていくのがけっこう難しくて、現場のアーキテクトに助けてもらったり、クラウドの専門部隊に助けてもらったりしながら進めていきました。

最後に書いているのが、私がものすごく困ったところなのですが、スクラムを始める時には、稟議や契約や見積もりや品質に関する質問が大半なんですね。

というのも、今までウォーターフォールでやってきたので、そこと照らし合わせるとどういうふうに変わるのかというのを、みなさんすごく気にされていて。契約から開発、運用までいろいろな質問が飛んでくるところに、対応していくのが大変だったなと思います。

他部門とさらに連携してビジネスのためのアジャイルの渦をもっと大きくしていきたい

このように大変なことはたくさんあるのですが、推進の中で感じていることとして、大きく複雑な会社ではあるのですが、少しずつでも変化は起こるなと感じています。こちらからギブして、信頼残高を増やしたことで、仲間が少しずつできてきたなと思いますし、社内の推進者と社外の推進者は両輪だなと感じています。

2つ目は組織の背景と文化に向き合う大切さですね。進めていく中で、これまでの仕事のやり方や、会社の文化の影響を感じることがものすごくありました。ただそれが悪いというわけではなくて、これまで成功したからこそ、そういう文化があるので、既存の文化をリスペクトしつつ向き合わなければいけないなと思いました。

3つ目は、個人的な面ですが、UXデザインの要素は活かせると思っています。現場や他のメンバーを観察するタイミングだったり、インタビュー、ファシリテーションの能力が活かせるなと感じましたし、組織やチームに向き合うことは大きなプロダクトのようなものだと感じています。

さまざまな部門が、違う立場で変化に向き合おうとする兆しが起こっているのですが、まだまだ現場、開発のところだけに留まっている現場もあるので、これからも事業を成功に導くために、ビジネスのためのアジャイルをやっていきたいなと思っていますし、既存の決まりとうまく共存できていないところもまだあるので、他部門とさらなる連携を進めていきたいと思っています。

せっかく社内の理解者や実践者が増えてきたので、この渦をもっと大きくしていきたいなと思っています。