お客様とスクラム開発！導入事例と導入のポイント
こんにちは。ソリューション開発部 認定スクラムマスターの飯出(いいで)です。
先日、ソリューション開発部におけるスクラムへの取り組みを紹介しましたが、今回はスクラム開発の実例を紹介します。スクラム開発とは何か。につきましては、下記の記事をご覧ください。
https://devlog.arksystems.co.jp/2016/08/27/1075/私たちのチームはデジタルマーケティング事業を手掛けるお客様先に常駐し、事業遂行に必要となる運用支援、基幹システムの追加開発ならびに保守を行っています。お客様とは2007年より今日まで9年間、長く良いお付き合いをさせていただいています。
以前は、追加開発や保守対応を弊社内にて実施していましたが、開発チーム全員がスクラムチームの一員としてお客様先に常駐するスタイルに進化しました。今回はスクラム開発導入のそのポイントについて、開発事例として紹介します。
登場人物
まず、スクラム開発の導入を一緒に進めた方たちを簡単に紹介します。
情報システム部門の担当者
お客様のなかでシステムの開発、運用保守を一手に引き受けている方です。私たちと一緒に仕様を考えたり、お客様業務部門と私たちの橋渡し役をしています。
スクラム開発を始めてからは、チーフ・プロダクトオーナーになってもらいました。
業務部門から選ばれた担当者
システムに対する業務部門の意見を集約して、どのようにシステムを変えたら良いか取りまとめている方です。元々は業務部門におけるリーダーの1人でしたが、数年前に要望などの意見を集約するポジションに就きました。業務部門のリーダーたちと頻繁に会話を交わして、システムをどのように改善したら良いか一生懸命考えていました。
スクラム開発を始めてからは、プロダクトオーナーの1人となりました。
業務部門のリーダーたち
私たちが作ったシステムを利用する人の中で、各業務チームのリーダーとして活躍している人たちです。毎日システムを使って事業を進めています。システムの使い勝手について、一番理解している人です。
スクラム開発を始めたのち、プロダクトオーナーチームに入ってもらいました。
私たち
お客様システムの開発や運用保守を引き受けている開発者のチームです。
マイナスからのスタート
このお客さまでのこれまでのシステム開発では、ウォーターフォール型開発を採用していました。ただ、「仕様をきっちり決めて開発を順次進めていく」ウォーターフォールという開発プロセスをきちんと実践できておらず、仕様は決まらず、優先度も決めず新たな仕様が増え、また変更され、ただリリース予定日が近づく毎日でした。あるあるの丸投げ開発スタイルですね。
情報システム部門の担当者と私たちは、リリース予定日が近づいても仕様の追加や変更が発生するこの状況を打開できずに、正直うんざりしていました。そこで、「状況に応じて変更の発生を前提としている」スクラム開発をやってみたらどうか？と思い立ったのです。
この時点で見えていた問題点は、次のとおりです。この問題点をスクラム開発によってカイゼンしようと考えていました。
仕様の合意プロセスに時間が掛かりすぎる
追加したい仕様ならびに改善点の検討を業務部門から選ばれた担当者が1人でやっていました。その後、この担当者が業務部門のリーダーたちと内容の合意を取るのですが、毎々業務部門のリーダーたちが現場に持ち帰った後に検討会を開く形となり、組織の大きさの割に合意までの時間が掛かり過ぎていました。
検討の時点で技術者にあまり相談しない
業務部門では変更の規模やシステムの都合まで検討は難しいはずです。このことにより業務部門ですり合わせてきた内容とミスマッチが発生し、実現までに仕様検討の手戻りが発生して時間が掛かってしまっていました。かつ業務部門から選ばれた担当者の稼働がとても高く、検討する時間も取れていなかったと思います。
また、このような状態で「この日までに実現できないと困る。」と言われても、技術者からすれば「難しい」と返答することが多くなってしまっていました。
お客様の意思確認
そのような中、私が認定スクラムマスターを取得したきっかけは、お客様情報システム部門長のヒトコト（しかも酒宴）でした。しかし、この方はプロジェクト・オーナーにあたります。実際に業務を遂行しているのは、また別の方です。
スクラム開発を成功させるには、現場への浸透が必要です。そして、情報システム部門の担当者は過去にスクラム開発の導入に失敗したことにより及び腰でした（他者に「必要ない。」と断言されたことに対するトラウマ）。自信を無くしていた訳です。
「いつやるの？今でしょ！」
カリスマ予備校講師・林修先生の有名な言葉ですが、ここでは業務部門のリーダーのひとりが言ったヒトコトです。今までの開発における問題点をベースに、これからの開発をどのように進めていくかというテーマについて数度にわたって話し合いました。
最初は変化を嫌う傾向を感じたり、「よくわからない。」のひと言で片づけられてしまうこともありましたが、ある時この言葉がでたのです。業務部門によるシステム部門への丸投げ体質を問題視していたかどうかは定かではありませんが、新しいモノを取り入れよう、何かをカイゼンしようというマインドはとても重要でした。
この言葉を業務部門から引き出せたことがスクラム開発を始めることへの第一歩であったと、今でも感じています。
体制の構築
まずはスクラム開発向けの体制を考えました。スクラムのお作法に則った体制、そしてロール（役割）は下図のような感じですね。各ロールの詳細については、ここでは割愛します。
「プロダクトオーナーチームを作る」という提案
「プロダクトオーナーが1人であることが重要」「複数人のプロダクトオーナーが存在すると失敗する」などといった記載を見かけることもありますが、今回はあえて複数人の方にプロダクトオーナーとなってもらいましょう。
私たちが担当するお客様の業務はそれぞれドメインが決められていて、かつシステムも業務ドメインにかなり近い形で構築されています。各業務のスペシャリスト、すなわち業務部門のリーダーたちがプロダクトオーナーになった方が、さまざまな成果を最大限に引き出せると考えたわけです。
対策もします。複数人のプロダクトオーナーが存在することにより個々のプロダクトオーナーが製品全体に責任を持たなくなるというデメリットも想定できますが、チーフ・プロダクトオーナーを任命することによってプロダクトオーナー間の連携を強化しています。
チーフ・プロダクトオーナーの役割はとても重要です。個々のプロダクトオーナーから提案されるプロダクトバックログアイテムの優先度調整や、業務には強いがシステムに強くないプロダクトオーナーのフォローなど、積極的にチーフ・プロダクトオーナーとしての役割をこなしてもらいましょう。
チーフ・プロダクトオーナーは…スクラム開発を一番理解している情報システム部門の担当者にお願いします。
プロダクトオーナーが主導する勉強会の開催
スクラム開発を始めるにあたり、開発プロセスとは何か？から始めたスクラム教育。業務部門出身のプロダクトオーナーからしたら「スクラム、何それ？」な訳です。業務に関してはスペシャリストですが、もちろん開発プロセスといった言葉すら知りません。
勉強会の主担当はチーフ・プロダクトオーナーです。横文字の多い用語に対して業務部門の方々に解りやすいよう説明する様は「さすが！」の一言です。クイズ形式で質問を出したりもしています。良い質問や回答があった場合にはお菓子をあげる（投げる）こともしていました。（認定スクラムトレーナーである James O. Coplien氏 の真似ですね。）
スクラムマスターである私も副担当として常に勉強会に参加していましたが、ほぼ指摘や修正をすることなく、首尾よく進んでいきました。このように、情報システム部門の担当者（チーフ・プロダクトオーナー）が自ら楽しくスクラム開発を説明することによって、浸透しやすくなるのかも知れません。
きっと、私たちのように外部から支援する立場より日頃から一緒に業務をしている方が説明することによって、敷居が低くなるのでしょう。
プロダクトオーナーの成長
複数回にわたって開催した勉強会を経て今日までスクラム開発を続けていますが、「マイナスからのスタート」で挙げた問題点が改善され、プロダクトオーナーの成長をとても感じることができます。数をあげればキリが無いですが、代表的なものをいくつか紹介しましょう。
- 担当者を分散し、普段業務を担当している人によって仕様を発案できるようになりました。よって仕様の検討が早く、かつスムーズに行われるようになりました
- 仕様を発案したプロダクトオーナーによる受け入れの実施。スプリントレビューでのデモによって成果物への理解度が深まる。かつ、発案への責任を負うことによって丸投げしない体質になりました
- スプリント緊急停止を頻発せずにプロダクトオーナーが我慢するようになりました。本当に今、何が必要か考えている証拠ですね
- 発注者と受注者の関係を超えたチーム形成。プロダクトオーナーとチーム（開発者）の会話が目に見えて増えています。良かったことを素直に褒めることによって、モチベーションも上がっています
- 仕様トラブルに立ち向かう姿勢がとても良いと思います。チーム（開発者）の提案を受け入れ、「いいからやれ。」のような雰囲気を感じなくなりました
- なんと、チーフ・プロダクトオーナーが認定スクラムマスターになりました！（じゃあ私がスクラムマスターをやらなくてもいいじゃん。とも思いますが、スクラムチーム内の利害関係を考えると自身がやるべきではない。と立場と状況を理解されています。）
おわりに…
スクラム開発の導入において、今回のポイントはこの2点です。
- 体制を構築する際にプロダクトオーナーとなる人の状況と背景をよく理解しましょう。スクラムマスターの立場として改善の支援をするということは、問題を持つ、感じている人の立場を理解することが重要です
- 勉強会を必ず開催しましょう。スクラム開発の導入によって何を改善するか、どのように改善するかをスクラム開発を理解しているプロダクトオーナーに語ってもらいましょう。お客様にスクラム開発を理解している人がいない場合は、理解してもらうところから始めましょう
最後に、私たちのお客様でもあるチーフ・プロダクトオーナーからコメントをいただきましたので、紹介します。
この度、Scrumでやってみようという風に思い立ち、さらに実際にやってみるというところまで来れたのは、アークシステム様の皆様の力強いご支援があったればこそと実感しております。
ご一緒した当初は、古来より伝わるいわゆるウォーターフォールモデルに倣っておりましたが、作っていただきたいはずの側の私たちも1年先を見通すことは難しく、半年先ですら見通せず、「なぜだか水が下から上に流れる様」に、結局のところ変更や手戻りといったご苦労を掛けながらなんとかこなしてきたという実感でした。
Scrumに一緒に取り組んでからは、2週間というスプリントでモノづくりを進めていくこととなり、プロダクトオーナーの側も「常にモノづくりに熱く向き合っていないと回らなくなる」という状況に追いこまれるようになりました。（いや、いままで熱く向き合っていなかった、というわけでは決してないのですが・・・変わってしまうんです。思い付いてしまうんです。あるいは、進んでみないと本当に先のことがわからないんです。。。）
今では、一緒にやっているビジネス側のプロダクトオーナー役のメンバー達も、根気よく「速く細かい」サイクルに必死についていっているようです。以前に比べれば、自ら頭から湯気を出し、必死に考えて計画ミーティングに臨んでいる様が伝わってくるようになりました。数年前ではこんなには見られなかった光景です。本当です。
何度か計画ミーティング第2部を見学させていただき（本当はプロダクトオーナーは参加してはいけないんですが）、実装チームの皆様が愛と勇気を友達に、誇りを持って見積もりいただいているのがビシビシと伝わってきたり、スプリント計画通りにいったりいかなかったりする様を取り繕うことなく披露して頂ける様子に触れ、プロダクトオーナー側の皆も奮起されたり、信頼が増したりしているのだと思います。
Scrumをやってみると開発にまつわる問題点が次から次へと炙り出されます。この勢いに圧倒されて、ものすごく凹んだりすることもあります。課題に立ち向かい、感情を隠すことなくボロボロに負けてしまうようなこともあります。こ、これがScrumの「改善と適用」・・・っ！と圧倒されますが、なんとかメンバー同士で挑戦し、正気を維持している毎日であります。
このように、Scrumチーム内ではアークシステム様のおかげでだいぶScrumの教えが身に染みてきたころと思います。おもしろいことに、古来より伝わるウォーターフォールモデルも、大事なところはScrumと変わらないのでは？と考えるようになってきています。（そもそも私はそのウォーターフォールモデルというやつで、開発できてたのかい？うまくいってなかったのを、開発プロセスのせいにしていないかったかい？）
最近、私が特に感じる次の課題は、Scrumチームとチーム外のステークホルダーとの間にあるミスマッチです。プロジェクトの不確実性に対して徹底して現実的なスタンスをとるScrumと、なかなかそうはいかないステークホルダーとの間に立つむずかしさです。そういえばこれもまた、開発プロセスの違いによるものではないのだなぁと実感しています。
この狭間に落ちている私の力不足で、アークシステムの皆様にはまたご苦労をおかけしていることと思いますが、なんとか懲りずに引き続きご支援いただけますと幸いにございます。
スクラム開発を始めたいと思っている方がいらっしゃいましたら、参考にしていただけますと幸いです。スクラム開発に興味のある方、新たな開発チームを構築したいと考えている方はこちらまで お問い合わせ ください。
