DX時代の情報システム部門のあり方、そして役割とは 第04回 情シス部門が組織のアジャイルを担う

株式会社レッドジャーニー 代表 政府CIO補佐官 DevLOVE オーガナイザー
市谷 聡啓 氏

スクラムをはじめる以前の問題

情報システム部門がDXの取り組みの中で役割を果たしていく鍵は、アジャイル開発、特にスクラムを習得することだと前回述べました。DXのような不確実性が高く、優先度の変更が発生し、確たるスケジュールが引けない領域では、その取り組みを支える運営方法として、スクラムが適しています。情報システム部門がスクラムを用いてDXの運営自体を担えるようになれば、DXを進める上での不足を補完できるようになるわけです。イメージとしては「DXのスクラムマスター」を務めることが、これからの情報システム部門の果たす役割と言えます。

問題は、新たな役割を担えるほど情報システム部門に余裕が無いという現状です。既存の業務、システム保守に手一杯で、新たなスキルを身につけ、新たな取り組みにトライしていく時間が無いというわけです。これまでの企業が大前提においてきた「効率化」とは、余計なことをしなくて済むようにする、やるべきことは最初から明確になるようにする、といった狙いがあります。既存システム周辺の業務について「効率化」を重ね、そこにのみ焦点を当ててきた組織にとって、スクラムのような新たなスキルを身につけることは組織の方針や計画と全く合わないところです。その結果、声高に言われるほどにはスクラムの習得が進んでいかないのです。

この手の状況に際して、筆者は「はじめることをやめる、やめることをはじめる」という指針を打ち出すようにしています。物理的な時間が無いところで、取り組みをどれだけ詰め込もうとしたところで現実的ではありません。スクラムの習得も、1ヶ月2ヶ月で済むようなものではなく、中長期に渡っての取り組みとなります。無理やり詰め込んだところで、結果に繋がりません。ですから、むしろ「新しいことをはじめる」をやめて、今やっていることで「やめられるものをやめる」方を優先するのです。そのためには既存の業務やシステムの棚卸しが必要となります。自分たちの部門が何を仕事として担っているのか、個々別々のタスクについては把握できているものの全体像が見えていない、というのはよくあることです。

この際、「やめるための工夫」が必要になることが多いでしょう。新しいツールを作ったり、外部のサービスを活用したり、運用ルールを決め直したりです。いくつかの工夫のパターンがありますが、まず最初に考えるのは、繰り返しになりますが「やめる」ことです。どうすればやめられるかという工夫を考えること自体に時間を要するものです。あとでその検討は活きることになりますが、今はまず目の前に余白を作り出すことが最優先です。例えば、システムの利用状況を調べてみて、ほとんど使っていない、あるいはわずかに利用されているが別の手段で対処が可能である場合などは、真っ先に「やめる」ことを進めましょう。

組織の中にアジャイルハウスを建てる

「やめることをはじめる」ことで、少しずつですが部門に余力を作ることができるはずです。そこから、スクラムの習得へと乗り出すことになります。スクラムの習得も最短距離で取り組みたいものの、現実的にはこれまでとは違う仕事のスタイルを身につける話ですから、相応の時間を要します。また誰もが一様に、スクラムのスタイルに合うわけではありません。むしろ、「効率化」があらゆる判断基準に染み付いてしまっていると、スクラムのような「一定の期間ごとにやるべきことを見直し、判断を変えて進める」というスタイルは相容れないはずです。こうしたマインドチェンジを果たすために、段階的に取り組みましょう。組織の中に一つの建物を作るイメージを持ちます。

図：組織の中にアジャイルの建物をイメージする

この建物は、基礎から3階まであります。まず基礎の部分は、上に建つ建物を支えるための重要な土台となります。アジャイルの価値観や原則を学ぶための時間を作るようにします。アジャイルは「協働」を基底としており、組織の縦割り化や仕事の個人商店化とは対極にある考え方をとります。アジャイルが背景におく考え方を、まずは一通り目に通し、実際に日常の仕事でどのように体現できるか、チームや部門で話し合うことから始めましょう。

基礎の上の1階は、仕事の状況の「見える化」です。先程述べたように部門の仕事の全体像を見失ってしまっていて、それでも業務を成り立たせるために目の前の仕事にのみ焦点をあわせて取り組んでいる、そのような状況下では同じ部門であっても隣が何をしているかさえ分からなくなっていくでしょう。状況の「見える化」は、協働の前提です。今何をすべきで、誰が何に取り組んでいるのか、この理解がお互いに無ければチーム的に連携して動くということができません。「見える化」のために、まず今チームや部門が抱える仕事を洗い出しましょう。その上でタスクボードやカンバンといった道具で状態の管理をはじめていく、こうした「見える化」の方法がDXのプロジェクト運営でも基本として必要となるところです。

次に2階です。ここからスクラムの取り組みがはじまります。まずは、スケジュールありきの仕事の進め方から、「スプリント」と呼ばれる1週間あるいは2週間の時間の区切りで協働するスタイルへと移行します。取り組みの難易度を上げすぎないように、まずは情報システム部門内で取り組みましょう。1階で見える化したやるべきことを、例えば2週間単位で何を優先して取り組むか、そしてそれらをどうやって分担するかについてを決める機会を設けます。これを「スプリントプランニング」と呼びます。こうした計画作りを経て、実際のタスクの実行があり、2週間後にまた集まって取り組み結果を確認する場を作ります。この場のことを「スプリントレビュー」と言います。まず、こうした時間の区切り（スプリント）を繰り返していく進め方が滞りなくできることを目指しましょう。スプリントプランニングとスプリントレビューで自分たちの仕事を挟み込み、常に取り組んだ結果から次のスプリントの判断を行う、もちろんその際により結果が出せる、より良い仕事ができるよう工夫を講じるようにします。つまり、スプリントを繰り返せば繰り返すほど、自分たちの取り組みがより良くなっていく、そういう状況を作っていくわけです。

最後に3階は「完全なるスクラム」ということで、いよいよDX推進部署や事業部門を巻き込んだスクラムをはじめましょう。取り組むテーマや内容によって、誰がプロダクトオーナー（企画のリード役）を担うのかは様々ですが、DX推進部署や事業部門側が立つ場合が多いはずです。2階をあえて自部門に閉じて進めることを推奨したのは、まずスクラムの運営自体を自分たちだけで回せるようにするためです。その上で、他部門を招き入れて、然るべき役割を果たしてもらう、全体としてのスクラムを成り立たせるという組み立て方が良いでしょう。
次の最終回では、ここまでの内容をふりかえりまとめと致します。

• 第05回 組織にアジャイルを宿していくのは誰か