第4回：「スピード」と「アジリティ」その②

みなさんこんにちは。システムエグゼの相田です。

さて、第四回目は、前回の「スピード」と「アジリティ」の続きです。

前回は「xTech」や「デジタルトランスフォーメーション（DX）」といった新たな 領域向けの IT 開発には「アジリティ（機敏さ）」が必要であり、従来型の開発における「スピード」とは異なる考え方が必要になる、というお話をしました。

そして、アジリティを実現するためのアイディアの一つが「アジャイル開発」です。

今回は、アジャイル開発の採用を含め、IT 開発でアジリティを実現するために組織は何をしなければいけないのか、というお話です。

「チャレンジ」のための「新しい IT ガバナンス」

xTech も DX も、ビジネスの視点で見れば「これまでとは違う新しいビジネスを始めよう」というメッセージが込められたキーワードです。

新しいビジネスを始めるためにはアジリティが重要です。同じビジネスアイディアを思いつく人や企業は結構いて、先んじて開始しないとビジネス的に負けてしまうかもしれませんし、逆に先んじられて負けそうな場合は素早く撤退して、また別のアイディアを試さなければなりません。新規ビジネスが「成功」する確率は残念ながら高く無いので、機敏に、柔軟に、そして数多くチャレンジする必要があります。

このようなチャレンジのための IT 開発では、どうしても既存の IT ガバナンスを変更する必要があります。

ここで言う IT ガバナンスとは、IT システムに対する予算計画の立て方や予算管理のルール、契約や調達に関するポリシー、或いは弊社のような SI ベンダに対する評価手法など、様々な「社内の仕組み」の事です。現在多くの国内企業の IT ガバナンスは、社内で使用する基幹システムや業務システム開発用に整備されています。それは「予定通り確実に完成する事」に重きをおいたIT ガバナンスであり、ビジネス的なチャレンジには向いていません。

ちょっと想像してみて下さい。

「計画して素早く着手して、既にコストが発生していますが、一ヶ月で状況変わった のでやっぱり開発やめます」

と上司の方に言えるでしょうか？もし言えない状況にあるのであれば、それは従来型の IT ガバナンスの元で開発を行っているという事です。（その枠内だったら、私もとても言えません）

既存の IT ガバナンスを変更する必要はありませんが、ビジネス的なアジリティが必要な「チャレンジ」向けの「新しい IT ガバナンス」を用意する必要があります。

IT ガバナンス＋アジャイル開発＝アジリティ

アジャイル開発によりアジリティを実現するためには、以下のような IT ガバナンスが必要になります。

① 原則内製

アジリティを実現する最大のポイントは、お客様自身が直接・素早く・柔軟にビジネス判断を行う必要がある、という点です。ベンダがこのような判断を行う事は不可能です。コンサルさんだって無理です。

従って請負契約でベンダに委託するのは無理です。弊社のような SI ベンダにとっては非常に辛い事ですが・・・原理的に無理です。

ですので、もし弊社にご相談いただけるのであれば、準委任契約などで弊社のスペシャリストを「お客様の内製プロジェクト」に送り込み、お客様の意思決定と弊社のノウハウの元で開発を行う「共創」を目指すのが望ましい形です。

② 鉄の三角形（Scope, Time and Cost）における Time and Cost を固定

プロジェクトマネジメントにおいて「鉄の三角形」と呼ばれるものが、「実現範囲（Scope）」「期間（Time）」「費用（Cost）」です。

従来型の開発では、普通は「実現範囲（Scope）」を固定して、それに合わせて「期間（Time）」「費用（Cost）」を調整します。この調整が、いわゆる「見積もり」ですね。

しかしアジリティを実現するためには「期間（Time）」「費用（Cost）」を固定しなければなりません。ビジネス上の競争は待った無しであり、投資出来るコストには限りがあります。チャレンジを行う上で、この制約を外す事は出来ません。

そして従来とは逆に「実現範囲（Scope）」を調整する必要があります。

ある意味ではアジャイル開発は、「実現範囲（Scope）」を素早く・柔軟に調整するための開発モデルなのです。

多くの組織にとってここが一番難しいポイントでしょう！まるで「期間と費用決めて、その範囲でやれる所までやります」と言っているように聞こえますからね・・・

でも良く考えてみて下さい。「期間（Time）」「費用（Cost）」は固定せざるを得ません。そうしないとビジネス上のチャレンジが成立しないからです。であれば「実現範囲（Scope）」を調整する以外に方法はありません。

そして「その期間と費用の中でシステムが実現しなかったらどうするんだ！」という質問に対する回答は明らかです。 「それは成立しないビジネスだと言う事なので、その事実が判明した瞬間に開発を 中止しチャレンジから撤退して下さい」

という事です。もしそうなら早めに結論出ないと駄目ですよね・・・

③アジャイル開発プロセスを採用

アジャイル開発とは、このように決められた期間と費用の中で開発量（Ccope）を最大化するための方法論です。 「イテレーション」という短期間の開発サイクルが定義されているのは、（なるべく短い）サイクルで開発状況を確認し、ビジネスの実現可能性を評価し、素早く・柔軟に方針変更や開発の中止を判断するためです。

アジャイル開発は「システムの完成」を目指すものではなく「ビジネスの実現」を目指す開発モデルなのです。

なお「アジャイル開発プロセス」には様々な種類があり、組織や人材、開発対象に合わせて組み合わせたり、変更したり、併用したりする必要があります。

今はコンテキスト中心アプローチとして Scrum を、コンテンツ中心アプローチの手法（FDD, XP, TDD, BDD, DDD 等）と組み合わせてプロセス設計するのが一般的なようです。（ちなみに弊社では入門編として ICONIX 或いは UCDD をオススメする事が多いです）

④クラウドサービス

アジリティを求めてアジャイル開発を採用しても、開発用のハードウェアを調達したりプログラム開発用の製品を調達したりするのは、無駄が多く時間がかかってしまいます。場合によってはすぐ使うのやめるわけですし。

なので、アジャイル開発の場合は迷わずクラウドサービスを選択です。PaaS／SaaS／サーバレスといった「すぐ使えて、使用期間分だけ料金を払う」基盤 で開発を行うべきです。

クラウドは長期運用するとオンプレミスよりも高額になる事が多いのですが、 アジリティを優先する場合はクラウドサービス一択です。

⑤バイモーダル IT

①～④ を実践するための予算計画の立て方や予算管理のルール、契約や調達に関するポリシーなどはきちんと文書化し、必要に応じてカイゼンします。これが「アジャイル用の IT ガバナンス」です。

繰り返しになりますが、既存の IT ガバナンスが悪いわけではありません。ただし、これまでとは違うビジネス領域には「別の流儀」で望む必要があります。そのための IT ガバナンスを整備する事で、将来に向けた xTech／DX へのチャレンジが可能になります。

このような「二種類の流儀を持つ」事を意味するのが、最近流行（？）の「バイモーダル IT」という言葉です。

まあ、個人的には「たった二種類に分けるのは大雑把すぎるのでは？」と思っていたりしますが・・・

「カイゼン」という「もう一つのアジャイル」

「じゃあ既存の現場にアジャイルを適用してもメリット無いの？」という声もあろうかと思います。

この質問に対する回答は、実は（これまた）ちょっと難しくてですね・・・

実は「アジャイル」と総称されるアイディアの中には、ここまで説明した「アジリティ」ではなく、従来の「スピード」に対するものもあります。

それがトヨタ生産方式に起源を持つ「リーンソフトウェア開発（LSD）」です。 いわゆる「カイゼン」を積み重ねて開発生産性を向上させるのが LSD であり、 従来型の基幹システムや業務システム開発の改善には、こちらの方が向いています。

実は弊社では、10年以上前から通常のウォーターフォール型開発に LSD のプロセス やプラクティスを取り込んでいます。これはこれで非常に大きな成果を出しているのですが、この話はまた別の機会に。

というわけで。

「アジリティ」を実現する IT ガバナンスの構築は、弊社にとっても大きな課題です。 新たな IT ガバナンスを構築するため、新組織の立ち上げを含めた組織再編、契約・調達・法務におけるポリシー策定、そして何より社内スペシャリストへの教育や訓練など様々なアプローチを行っている最中です。

今まさに苦労しているので、その反動で前回と今回は書きすぎてしまいました・・・

次回はまた少し肩の力を抜きたいと思います。

それでは、また第五回（あれば）でお会いしましょう。