誰も知らない業務プロセスと89部署の調整役　大企業の旭化成がアジャイルで直面した現実とは：「アジャパー・シナジー」セミナーレポート（2）

アジャイル開発において「少数精鋭」というのは重要な要素だ。一方、その開発対象が全社となると管理的にもリソース的にも少数では対応しきれないことが出てくる。グループ会社を合わせれば、関係部署が100を超える旭化成はこの課題をどう解決したのか。

» 2025年02月26日 05時00分公開

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　変化し続けるビジネスニーズに素早く対応できる点がアジャイル開発の最も大きなメリットだ。だが、ビジネスや組織の規模が大きくなってくると、そのメリットを得ることが難しくなってくる。総合化学メーカーの旭化成も同じ悩みを抱えていた。

　2024年10月23日に開催されたオンラインイベント「アジャパー・シナジー」にて旭化成の安田航氏は「実録：旭化成の業務プロセス改革をアジャイルで進めたら大変だった件」と題して、旭化成グループ全体での業務プロセス改革にどうアジャイルを適用したのか、その試行錯誤のプロセスを語った。

旭化成グループ全体での業務プロセス改革

旭化成の安田航氏

　旭化成は総合化学メーカーだが、化学品を扱うマテリアル領域の他、住宅領域、ヘルスケア領域の3領域で事業を展開している。事業が違えば文化も違う。そんな中、1年前に旭化成に転職したばかりの安田氏は、全社を通した業務プロセス改革を支える「データ基盤の構築」を任されることになった。

　「プロダクトオーナーとしてプロジェクトを推進することになりましたが、関係者がとにかく多いことに驚きました。プロダクトオーナーとして優先順位が高いと思っても、周りはそう思っていないことも当たり前にありますし、こちらが知らない事情も後からたくさん出てくる状態でした」

　安田氏は前職でもアジャイル開発のプロダクトオーナーを経験していたが、それとは状況があまりに異なっていた。こうした中で同氏はどのように業務プロセス改革を進めたのか。

ターゲットを絞り込んだのに89部署に影響

　旭化成グループ全体の業務プロセス改革により継続的に収益構造を改革する。この全社横断の取り組みは「BT Project」と呼ばれた。それを支えるデータ基盤を構築・展開することになったのだが、全社規模の業務改革を一気に進めるのは難しい。そこで安田氏は、立ち上げフェーズにおいて最初のターゲットをいかに絞り込むかに注力した。

　「年度初めには何かしらの成果を出したいという事情があり、最初の機能は3カ月でリリースすることが決まっていました。そのため、開発するシステムは、3カ月で対応できるレベルに絞り込む必要がありました」

　安田氏は業務プロセスを絞り込むため、縦軸に組織、横軸に業務プロセスを配置し、表形式で整理。その上で対象となる業務プロセスと機能を絞り込んだ。その結果、UI（ユーザーインタフェース）は3画面、トランザクションテーブルが1つ、マスターテーブルが10個程度になった。数字だけ見れば3カ月で十分開発できる範囲に思えるが、関係者が想定以上だった。

　「この業務に関わる組織は89部署、ユーザーは1000人を超えていました。かなりシンプルな業務プロセス1つでも、これだけの部署が関わるとそれぞれ考え方が異なります。そのため、試行錯誤しながら進めなければなりませんでした」

対象を絞り込んでも89部署が関連する

アジャイルで、部署ごとの認識違いを1つずつ解消

　旭化成はシステムを内製開発しているため、開発プロジェクトそのものについては知見があった。ただ、アジャイル開発に慣れていないメンバーも多いのではないかという懸念から、最初の2カ月はウオーターフォールで開発し、その後の1カ月トライアルしながらアジャイルで調整する流れで進めることにした。

最初の2カ月はウオーターフォールで、その後にアジャイル

　「アジャイルはやはり“慣れ”が大きいです。私も転職直後で、本当にアジャイルで回せるかどうか自信があったわけではありません。そこで最初は慣れているウオーターフォール方式を採用しました」

　この進め方にしたのは他の理由もある。要件定義を進める中で、業務プロセスの全体像を知る人が誰もいないことが判明したのだ。普通に考えれば要件が決まらなければ開発は進められない。だが、リリースの予定は決まっている。そのため、業務プロセスが分かっている範囲（開発すべき機能の要件が分かっている範囲）をウオーターフォールで開発、最後にアジャイルで修正する形にした。

　「最初は懸念もありましたが、旭化成ではアジャイルに慣れている人が多く、十分アジャイルで対応できると自信が持てました。とはいえ、89も部署があると事前に要件定義していても認識違いが多く出てきます。それを1つずつなくしていくため、開発した機能ごとにトライアルで運用して認識違いを解消していきました」

　認識違いの例としては項目に入れる値の考え方がある。例えば「投資予算の実績金額」という項目は部署ごとに「承認された予算」「発注した予算」「検収まで進んだ契約の予算」など指している内容が異なっていた。

項目一つ取っても認識違いはある

　どれも間違いではないが、各部署がそれぞれの認識で金額を入力してしまうと、システム的には意味がない（当てにならない）数字が登録されることになる。そのため、こうした認識の差について「〇〇という数値を投資予算の実績と呼ぶことにしましょう」などと定義し、進めていった。

調整を担うチームが“厚い”体制が自然発生

　開発体制についても触れていこう。進め方が一般的でなければ、体制も変則的になる。旭化成のプロジェクトでは、スクラムマスターを含むスクラムチームは2～5人、彼らとユーザーをつなぐポジションとして、4人のプロダクトオーナーチームと、10人のユーザー管理者グループといった体制になった。

　プロダクトオーナーがチームになっているのは、この規模の開発だとプロダクトオーナー1人で全てを決められないためだ。ユーザー管理者グループには、89の部署から“この10人に聞けば大体分かる”というメンバーを集め、プロダクトオーナーと意見交換しながら進める形になった。

　「開発を進めるチームより調整チームの人数が多くなっているので、正しいスクラムではないかもしれません。ただ、大きな組織で業務プロセス改革を進めるとなると、いろいろな人にインタビューする必要が出てきます。そのため、プロダクトオーナーやユーザー管理者グループのような“間に入るチーム”が重要になると考えています」

　変則的な体制ではあるが、結果としてプロダクトオーナーチームやユーザー管理者グループがいても、開発のスピードが落ちることはなく、3カ月で無事、データ基盤の最初のバージョンをリリースできた。

賛成を得られたところから、徐々に改革を進める

　最初のリリースには成功したものの、本番はここからだ。

　限られた範囲でうまくいったら次はグループ全体へと範囲を広げ、効果を最大化させる必要がある。だが、範囲を絞った89という部署であっても認識違いはあった。これがグループ全体となるとさらにギャップが大きくなるはずだ。同じ旭化成グループでも別法人となると調整の難易度が高くなり、さらに海外のグループ会社となるとますます難易度が上がる。

グループ全体に展開

　「グループ全体の業務プロセスを変えることで大きな効果を得るという目標はあるものの、全てに合意をもらってから一気に変えるのは無理があります。そこで、賛成を得られたところから改革を進め、賛成を得られるところを増やしてカバレッジを広げ、最終的に大きな効果につなげる、という進め方にしました」

　ただ、ここでも業務プロセスの全体像を知る人はいない。似た業務プロセスが何パターンもある上「この部署は独自システム」「この部署だけは全社共通システムを使っていない」など事情も違う。最初はパターンがあることすら分からず、各部署で話を聞くたびに「こういうパターンもあるのか」と気付く状況だった。これではどうしても手戻りが出てしまい、全体計画も立てにくかった。

業部ごと、会社ごとに業務プロセスは異なる

　「本来は業務プロセスの『As-Is（今の状態）』と『To-Be（将来あるべき姿）』を最初に定めるものですが、業務プロセスそのものが日々変わる（かもしれない）ということを前提にプロジェクトを進めるべきだと、考え方を変えました。As-Is／To-Beの業務プロセス図をアジャイル的にブラッシュアップしながら進める、ということです」

　「業務プロセスは変わるもの」と考えるとしても、その記録は残しておく必要がある。つまり変更管理だ。そこで安田氏はソースコードの管理で使っていた「GitHub」で、業務プロセス図や用語定義なども管理することにした。マークダウン記法が使えるため、ソースコードと同様に差分管理できることもメリットだった。