FJCT Tech blog

富士通クラウドテクノロジーズ公式エンジニアブログです

富士通クラウドテクノロジーズ

FJCT/Tech blog

【システム開発戦略編 その2】 スクラムでアジャイルな開発を実現しよう

ネットワークサービス部の田上(id:rtagami)です。

最近あまり買い物をしておらず、ブログのネタが尽きてしまいました。 次回のブログのネタに出来るように何か買い物をしたいと思います。

今回は、わたしたちが採用しているスクラムというソフトウェア開発プロセスについてご紹介します。 なんとなくスクラムというものを聞いたことはあるけど、結局どのようなものかわかっていない、 という方のために、基礎的な情報をまとめていきます。

前回は【システム開発戦略編 その1】 ドメインドリブンでクリーンなアーキテクチャを意識した開発 - FJCT Tech blog でした。

tech.fjct.fujitsu.com

アジャイルとは

まずは、スクラムについて触れる前にアジャイルのことを知る必要があります。 アジャイルのことを調べていると真っ先に出てくるのが アジャイルソフトウェア開発宣言 (以下4つの価値)と アジャイル宣言の背後にある原則 (以下12の原則)です。 アジャイルについて語る際には、これらを読んできちんと理解している必要がありますので、 一度も読んだことがないという方はまず一度お読みになることをおすすめします。

どちらも非常に短い(4つの価値が200文字程度、12の原則が500文字程度の)ドキュメントですので、すぐに読めてしまいます。 しかし、非常に凝縮度の高いドキュメントなので、注意深く読まないと文章の意図を理解できない可能性があります。 アジャイルソフトウェア開発宣言 アジャイル宣言の背後にある原則 というようなキーワードでWebを検索すると、 4つの価値と12の原則をどのように解釈したら良いかのヒントが得られるでしょう。 ステークホルダー向けの説明は、独立行政法人情報処理推進機構(IPA)が作成した アジャイルソフトウェア開発宣言の読みとき方 をベースにすると良いでしょう。

アジャイルスクラムの関係性

アジャイルのことが何となくわかったところで、スクラムアジャイルの相互の関係性についても知っておきましょう。

Mindset Values Principles Practices

(Ahmed Sidky (Keynote) 14ページ)

アジャイルマインドセットであり、4つの価値で説明され、12の原則で定義されます。 そして、アジャイルは無限のプラクティスによって具現化され、そのうちひとつがスクラムであると書かれています。 つまりスクラムは、アジャイルというマインドセットを実現するためのフレームワークと位置付けられています。

前の図でスクラムの隣にXPが描かれていたことからもわかるように、 スクラムとXPはアジャイルを具現化するプラクティスとして近しい関係にあります。

Agile and Lean

(Kanban and Scrum)

アジャイルスクラム・XPなどの既出のキーワード以外にも様々な概念が出てきていますが、 アジャイルを中心にスクラムとXPは強い結び付きがあるという理解ができれば問題ありません。

スクラムとは

スクラムとは、ソフトウェア開発のフレームワークであり、 スクラムガイド というドキュメントが公式のガイドブックとされています。 スクラムガイドも、4つの価値や12の原則と同じく(それらよりはボリュームがありますが) 17ページからなる簡素な文書ですので、読んだことがない方は一度お読みになることをおすすめします。

また、以下のような図も頻出しますのでご紹介します。

The Scrum Framework At a Glance

The Scrum Framework At a Glance

この絵を見ながらスクラムガイドを読むと、より理解が深まるでしょう。

同じく、ステークホルダー向けの説明の際には、独立行政法人情報処理推進機構(IPA)が作成した アジャイル開発の進め方 をベースにすると良いでしょう。

ところで、前節最後の図の左上に「日本の製造業」やら「トヨタ生産方式」やらといった、 一見ソフトウェア開発とは関係無さそうなキーワードが並んでいます。 これは、1986年に野中郁次郎さんと竹内弘高さんが発表された The New New Product Development Game という論文の存在が関係しています(このお二人はSECIモデルを発表したことでも有名です)。

スクラムガイド(2020年版)の14ページ目に「スクラムガイドの歴史」という節があり、ここに

Ken Schwaber と Jeff Sutherland が、1995 年の OOPSLA カンファレンスにおいてスクラムを共同発表した。

と記載されています。 その発表内容は The Scrum Development Process で確認できますが、発表の中で

We call the approach the SCRUM methodology (see Takeuchi and Nonaka, 1986)

と、野中郁次郎さんと竹内弘高さんの論文が参照されているのです。 このことから、お二人は「スクラムの祖父」と呼ばれることもあります。 スクラムの源流は日本の製造業にあると言って差し支えないのではないでしょうか。

スクラムの実践

さて、簡素な文書であるスクラムガイド(2020年版)ですが、4ページ目に

軽量級フレームワーク

と書かれていたり、

スクラムフレームワークは意図的に不完全

と書かれていたりすることからもわかるように、スクラムガイドは一周二周したところで、 「で、結局どうすればいいの」 というレベルの抽象度でしか書かれていません。 実際にスクラムを実践する上で抑えておくべきポイントなどは、書籍を読むことで一定のレベルに達することが出来ます。 金色やら銀色やらピンク色やらの書籍をよく見かけますが、プラクティスという意味では直近で緑色の本も出たようです。

スクラムとXPは強い結び付きがあると前述しましたが、スクラムを実践するチームでは スクラム以外のアジャイルのプラクティスも取り入れていることが多くあります。 さまざまなプラクティスを一覧したものとしてよく引き合いに出されるのが地下鉄の路線図です。

Subway Map to Agile Practices

(https://2016.agilejapan.jp/image/AgileJapan2016-pre-0-0-MetroMap.pdf 1ページ目)

この路線図に出てくるプラクティスはいずれもアジャイルと相性の良いものであり、 スクラム以外のアジャイルのプラクティスを取り入れることで、 スクラムをより有効に活用できるようになるでしょう。

個別のプラクティスについても、インターネット上の記事や書籍にさまざまな情報がありますので、 気になったプラクティスを実践してみると良いでしょう。

スクラムの実践 発展編

ここまでは、独力でスクラムを実践する際の取っ掛かりになる情報をご紹介してきました。 しかし、独力での実践では行き詰まりを感じる、という状況がそのうち訪れるはずです (訪れなかったら、それはそれで状況を再評価する必要があるでしょう)。

わたしたちがスクラムを採用した際も、 何となく上手く行っているように感じるけど本当にこれで良いのだろうか、 と悩んでいた時期がありました。

そのような状況を打破するためにできることをいくつかご紹介します。

研修を受ける

スクラムをより深く理解するために取れる手っ取り早い手段は、研修を受講することです。 プロダクトオーナー・スクラムマスター・開発者のそれぞれに対応する研修がありますので、 まずは自分のロールに対応する研修を受講した上で、他のロールの研修を受講するか、 より上位の研修を受講するかを検討するのが良いでしょう。

スクラム関連の研修(少なくとも基礎レベルのもの)は認定証を手に入れる事を目的として受講するものではない、 と考えるのが適切でしょう。 スクラムをまだ実践していない人がスクラムの実践をジャンプスタートさせるための場、 あるいはスクラムを既に実践している人が知識の棚卸をして疑問や悩みを相談する場として捉えると、 有意義に研修を受講できるのではないでしょうか。

日本(あるいは日本語)で受講可能なスクラム関連の研修は多くあります。 特定の講師の研修をどうしても受けたい、という希望がない限りは、どの研修を選んでも後悔することはないでしょう。

わたし(id:rtagami)の場合は、スクラムの採用初期に認定スクラムマスター研修を受講しました。 スクラムの実践を始めた直後で理想と現実のギャップをどう扱ったら良いか悩んでいた時期でしたが、 講師に直接質問し、チーム活動にそのまま活かせるアドバイスをもらえ、 非常に有意義だったことを記憶しています。

コミュニティに参加する

とはいえ、研修を受けたら直ちに課題が解決する(実践できるようになる)かというと、そういう訳でもありません。 スクラムを実践すればするほど、課題や悩みは増えていく一方ではないでしょうか。 スクラムガイドにも

スクラムは実践する人たちの集合知で構築されている。

と記載されている通り、実践する人が集まって知識を共有することで、次のステップに進めるのです。

会社の中にアジャイルコミュニティがある、 あるいは会社全体にアジャイルが浸透していて実践者が周りにゴロゴロいる、 という環境の場合には、社内の集合知にアクセスすることで課題や悩みを解決できます。

そうでない場合は、あるいはそうであっても、社外のコミュニティに参加する事は極めて高い価値があります。 自分とは全く異なる環境にいる実践者の意見には常に新しい発見があることでしょうし、 何より自分と同じ思いをもった仲間がいるという事に気づくことができるでしょう。

日本にはいくつものスクラムに関連するコミュニティがあります。 コミュニティのスタイルも様々で、 高い頻度・少ない人数・オンラインのような特徴を持つコミュニティもあれば、 少ない頻度・多い人数・オンサイトのような特徴を持つコミュニティもあります。 自分にマッチするコミュニティを見つけることで、高いレベルの実践に役立つヒントを得ることが出来るでしょう。

わたし(id:rtagami)の場合は、スクラム系のカンファレンスに顔を出すようにしています。 自分とは違う組織で働いている人や自分とは違うロールで働いている人と交流することで、 より広い視野でスクラムを捉えることができるようになったと感じています。

コーチを雇う

単一チームであれば、個人の努力でスクラムを導入するのも不可能ではありません。 しかし、複数のチームあるいは部署や組織に対してスクラムを定着させるのは孤軍奮闘では難しい場合もあります。 そのような場合には、アジャイルコーチなどと呼ばれるプロフェッショナルの力を借りる事を検討しても良いのではないでしょうか。 そのような方々は、コミュニティのイベントなどでもお会いできることが多く、 (実際に依頼するかどうかは別問題として)相談に乗ってくれることでしょう。

まとめ

今回はスクラムについてご紹介しました。

スクラム(あるいはアジャイル)はどのような場合にも最適であるとは言えません。 場合によっては、他の手法を使って開発するのが適切である場合もあります。

しかし、変動性・不確実性・複雑性・曖昧性(VUCAといわれるもの)の高い現代において、 スクラムを適用することでプロダクトの価値を高められる状況は拡大する一方です。 アジャイルスクラムの本質を理解して正しく実践することにより、 顧客のアウトカム最大化を実現するプロダクトを作れるからです。

次回は、わたしたちのアプリケーションアーキテクチャの一部であるモジュラモノリスについてご紹介します。 お楽しみに。

連載バックナンバー