利用と構築の観点から考えるシステム開発の“選択肢”

ITシステム「使う」と「作る」─開発時に持つべき観点

　今日、一定規模以上の企業においては、情報システムのない業務やサービスは存在しないと言っていいでしょう。当然ですが、今この瞬間も世界中でシステム開発・導入・運用が行なわれていますし、それは1つの企業でも同様です。

　そうした中、CIOはもちろんのこと情報システムを担う担当者は、意識するしないに関わらず常に何らかの選択や決断を行っています。30数年間この世界に携わった経験がある私自身も、様々な選択をしてきましたが、それは簡単ではありませんでした。振り返るとうまくいった選択もありますが、そうでない選択もありました。

　そこで本コラムでは新規に構築するもの、既存を更改するもの、統廃合を行なうものなど様々なパターンで情報システムを開発するにあたって、どういう方針で進めるのか、何に気を付けないといけないのか？「突き詰めればこういうことじゃないか」という考え方のよりどころとなる選択の観点を、3点ずつまとめてみました。皆様の参考になれば幸いです。なお「使う」と「作る」は、ユーザー企業とベンダー企業、または社内のユーザー部門とIT部門をイメージしています。

「使う」側の観点

①競争領域 or 非競争領域

　様々な意思決定の中で、いちばん違いを意識しないといけないのは、要件定義の作り方とスピードではないかと考えます。競争領域に関わるシステムの要件定義は簡単ではありません。こだわって力を入れる必要はありますが、競争力があるかどうかはやってみなければわからないケースがほとんどですからスピードも重視されます。

　一方、非競争領域はこだわる必要がありませんし、使えるものを利用する考え方が重要です。経験上、難しかったのは、かつては競争領域だったが非競争領域になろうとしている業務のシステムです。それまでのようなこだわりを続けると、かける費用や時間が割に合わなくなること（デジタル負債）への対応が足かせになりますから、その見極めとさじ加減が重要です。

②不特定多数ユーザー or 特定ユーザー

　システムを利用するユーザーは大きな要素です。生産性やエンゲージメントの低下を招くような極端なケースはともかく、ユーザーが社員であれば多少使い勝手に問題があっても「慣れて下さい」で事足りますし、研修を実施することもできます。

　一方、そうはいかないのが顧客や一般の消費者向けサービス（システム）です。ATMや券売機のように特定機能だけを提供するサービスはともかく、多くの場合、最初の印象や使い勝手で評価が決まってしまいます。デザイナーの技量に左右される割合が非常に大きくなっています。

　それでも最初から100点は不可能です。ユーザーの操作状況のデータを分析したりABテストのような手法を駆使したりして、クイックにアジャスト＆アップデートしていく必要があります。もちろんユーザーにアンケート調査して満足度を把握することも大事でしょう。

　加えて最近はユーザー＝人とは限らず、IoTも一般的になってきています。この場合も、自社で管理できるモノだけとつながっているシステムと、どんな素性のモノがどれだけつながっているか完全にはわからないシステムでは、考えなければならない要素が異なることにも留意しなければなりません。

③UX/CXの変革 or UX/CXの踏襲

　既存システムを更改する場合、見た目だけではなく、業務を変えるのか変えないのかは大きな要素です。やっかいなのは「既存踏襲」と言うだけで、要件が定義されないケースです。UIは既存システムを見ればわかりますが、業務機能やプロセスはそうではありません。典型的な業務プロセスなどはマニュアルや現場ヒアリングなどで把握できますが、例外処理を含めてきちんと定義しないと運用時のトラブルにつながります。

　業務を変える場合は当然、きちんと要件を定義してシステムを構築します。その場合はユーザーの立場に寄り添った準備が必要です。例えばBPRによる全体最適の結果、業務の一部を別部門に移管するようなケースです。当該部門にとっては未経験の業務が増えるので、物心両面でのサポートが重要になります。

「作る」側の観点

　①技術のモダナイズ or 既存技術の活用

　枯れた技術を使っての実現なのか、新しい技術を適用しての実現なのかは大きな違いです。ITの再構築と神社などの“式年遷宮”との違いは、前者には技術の寿命があるので一定周期でなんらかの技術的な新要素を取り入れる必要があることです。新技術を導入するタイミングや程度の見極めを誤ると、早すぎて使い物にならなかったり、時代遅れでEOLに追われたりします。

　新しい技術を取り入れるときには、作る対象が既存システムの場合、作るために使う技術は最新にする、作る対象が新規システムの場合、使う技術は実績ある得意技の応用、とするのが定石です。作る対象が新規で使う技術も最新にするのはリスクが高いのでお勧めできません。

②アーキテクチャの変革 or 既存アーキテクチャの踏襲

　ビジネス環境の変化に伴い、システムの役割や重要性は変わっていきます。統廃合や分担変更は不可避です。これもタイミングと変更方法の決定は非常に難しく、比較検証できないがゆえに、結果的にベストな選択だったかはわからないということを覚悟のうえで決めることが重要です。

　機能の配置、情報の配置の変更は、変更対象システムの担当者間のコミュニケーションが通常の開発に比べて非常に重要になります。開発はもちろん、移行が特に難しくなることを留意し、できるだけリスクを排除する（すべてを一度にやろうとしない）計画と実行が重要です。

③開発手法の変革 or 既存手法の適用

　典型的なのが、SaaS/パッケージ採用かスクラッチか、アジャイルかウォータフォールかです。よく語られる話なのでここで改めて触れせんが、謳い文句に踊らされて適用すべきではない開発にまで拡げていないか注意が必要です。

　上記の観点の単純な組み合わせだけで何十通りにもなります。組み合わせ次第でプロジェクト計画やプロジェクトマネジメントにおける力点や勘所がまるで違ってきますので、それを意識した検討や計画が必要です。そしてどの企業にもあるシステム開発の規程や実施要領などは、今の時代、必然的に複数のパターンを網羅しなければなりません。ないと思いますが、スクラッチSI時代のルール一本鎗で、すべてを管理評価しようとすると自縄自縛になりかねません。

　今日、企業が構築・運用しているシステムは多岐にわたりますし、SaaSなど外部のサービスも利用しています。CIOや情報システム部門は、自社のIT資産をきちんと棚卸しして、ビジネス戦略と照らし合わせつつ現在進行中のプロジェクトや新規案件を含めてシステム全体を進化させる役割を担います。その際、未来を見据えたロードマップを組み立てながら、適宜、制度やルールも変えていくことも大事な仕事のひとつになります。

　加えてCIOは使う側の観点を意識してことを進めるのはもちろん、作る側の観点で何をどう選択したかも押さえておく必要があります。悪意はないにせよ、作る側には実績ネタや実験台にしようとする魂胆が含まれることがあるためです。それを見抜けないといけません。

　一方で、難しい要素が重なるプロジェクトはまともに進まないのが当たり前です。使う側の観点を重視するあまりに作る側をいじめない寛容さも必要です。使う側作る側双方が、対立ではなく協調してITプロジェクトを進めて真のDXを実現したいものです。

筆者プロフィール