使いにくいシステムはなぜ作られるか

35万人月・4,000億円をかけてシステムを再構築した大手都市銀行が頻繁に障害を起こしたり、新型コロナウイルス感染対策の給付金申請で自治体が大混乱に陥いるなど、現代はシステムの不具合が市民生活に大きな影響を与える時代だ。全国民を巻き込む大規模障害だけでなく、一企業・団体の内外で起こるシステム障害や使い勝手の悪さは、市井のいたるところに溢れている。

こういったシステムのトラブルはなぜ発生するのか。開発サイド、プログラマー側に責任があることも多いかもしれないが、それ以上に問題が大きいのは、システムの発注者側に本当の原因があることだ。発注者がシステムの稼働ビジョンをきちんと認識していなかったり、開発者に丸投げしてしまったり、必要な機能の確認を怠ったり、納期や予算を十分に確保していないなど、おそらく複数の問題が絡み合ってシステムのトラブルは発生するものだ。

多くの場合、発注者はプログラミングのプロではない。業務のシステム化が目的であれば、その企業内で業務に精通している人が担当者になるのが一般的だが、新規事業、新規サービスを立ち上げるとなると発注担当者も初めてのことで、素人同然だったりする。デジタルトランスフォーメーション（DX）の本質を理解していない社長から「我が社もとにかくDXに取り組め！」との号令が下って、右往左往することもあるだろう。だが、発注者側、作らせる側がプロジェクトの全貌を理解し、きちんと管理できなければ、まともなシステムは完成しない。本書は、プログラミングのプロではない発注者が心がけるべき、ノウハウや心構えを説く。

本書では失敗するシステムの原因として、次の7つを掲げる。

・ゴールがバラバラ
・システムをITエンジニアに丸投げ
・システムを欲しがるが、業務を変えるつもりはない
・必要な機能がもれている
・現場の声を聞きすぎてコストが膨らむ
・システムを作ってもらうベンダーやソリューションの選択に失敗
・コントロールできない炎上プロジェクトとなる

いずれも身近に体験したり、聞いたことのある事例ではないだろうか。

プロジェクトに関わる人たちの認識、目指すゴールがバラバラというのはよくある話だ。社長が「自分はIT音痴だから」とエンジニアにシステム構築を丸投げし、結局完成しない、あるいは使い物にならないシステムが納品されることはしばしばある。

合理的でビジネス目線のシステム作り方法論

著者の一人・白川氏は20年前、若きシステムエンジニアとして業務をこなしながら「作って終わりではなく、ビジネスとして成果を刈り取るところまで関わりたい」「ユーザーとエンジニアは対立関係ではなく、同志としてプロジェクトに参加したい」といった理想を掲げ、独力で工夫を重ねていたという。

だが、転職した先のケンブリッジ・テクノロジー・パートナーズでは、そういった悩みへの回答が、すべて合理的な方法論として示されていたことに大きなショックを受けた。ケンブリッジ・テクノロジー・パートナーズでは具体的な方法論が理屈で裏付けられ、さらにエンジニアの美意識でもユーザーのわがままでも上司の気まぐれでもなく、「ビジネスを良くするために、どんなシステムを作るべきか」というビジネス目線に裏打ちされていた。

本書はそのケンブリッジ・テクノロジー・パートナーズでの20年間の実績、研鑽をもとにまとめられた。著者は戦略立案や業務改革、人材育成などを手がけ、方法論を著書や講演で伝えてきたが、今回、ようやく「システムを作らせる技術」をまとめることができたという。

Whyから始めよ

著者は、「プロジェクトを成功させるにはWhatではなく、Whyから始めよ」という。Why→How→Whatの順番で考えるというのだ。普通の人はついついWhatを先行させてしまう。「この製品がすごいので導入したい」とか「パソコン上で動いているシステムをクラウド化したい」というのは、What先行の例だ。なぜ導入したいのか、なぜクラウド化したいのか、それによって現状とどう変わり、どのようなメリットが得られるのかというWhyが曖昧なまま多くのプロジェクトはスタートしがちだ。

Whyを先に考えるとはどういうことか。たとえば、「工場ごとにバラバラな業務を標準化／統合し、一つの会社として運営すべきだ」（Why）→「統合後の業務プロセスはこうしたい。ガバナンスはこうあるべき」（How）→「そのためにはこういうシステムを作ろう。こういう機能が必要となる」（What）といった流れで考えることで、このように発想すればストーリーがきちんと見えてくる。これに従ってシステムを作ることで、会社をどうしたいのかという将来構想も明確になるだろう。システム作りに関わる（巻き込まれた）人に対してもビジョンをきちんと示すことで、彼らも自分で考えて行動できるようになるのだ。

本書は400ページ近いボリュームがあり、内容はかなり高度で、開発の進め方、プロジェクトマネジメントについての知識がないと理解するのは大変だろう。外資系コンサルタントの文書にありがちで、横文字や略語が多用されていて、まごつくところも多い。たとえば私はFMというと「ファシリティ・マネジメント」、FSというと「フィジビリティ・スタディ」しか思いつかなかったが、本書ではFMは「ファンクショナリティ・マトリクス」、FSは「ファンクション・スペック」の略で使っていたりして、理解するまでに時間を要した。検索してもほとんど出て来ないので、ケンブリッジ・テクノロジー・パートナーズの用語かもしれない。だが、企業の将来を背負うシステム開発を成功させたいのであれば、エンジニアでなくてもこのレベルを理解する必要があるだろう。本気でシステム開発に取り組みたい人にはオススメの一冊だ。

まだまだあります！ 今月おすすめのビジネスブック

次のビジネスモデル、スマートな働き方、まだ見ぬ最新技術、etc...　今月ぜひとも押さえておきたい「おすすめビジネスブック」をスマートワーク総研がピックアップ！