「自社業務を語れることが価値になる」システム発注側になった非IT技術者がするべきこと

DXによる業務改革が叫ばれて久しい今、「うちの会社のシステムもそろそろ入れ替えなければ」と考えている企業も少なくないでしょう。ただ、システムを発注する側の担当者が、ITに詳しいとは限らないのではないでしょうか。

ITのことはよく分からない。かといってベンダーに「作って」と丸投げするわけにもいきません。ひとくちに「システム」といっても、データベースやネットワークなど、関わる技術は広範囲に及びます。一体どこまで勉強して、どう頼んだらいいのか……？

そこで、昨年『システムを作らせる技術 エンジニアではないあなたへ』を上梓された、ケンブリッジ・テクノロジー・パートナーズ、バイスプレジデントの白川克さんに、「非IT担当者がシステム発注で意識すべきこと」や「システム構築ならではの難しさ」について、話を聞きました。

システム構築の発注側は、難しければプロに聞けばいい

――システムをよく知らない発注側がやりがちなこととして、「ボタン一つくらい簡単に追加できるよね？」と言いだしてエンジニアを困らせる、という話を耳にしたことがあります。そういったケースは実際にあるのでしょうか？

白川さん：過去にはあったかもしれませんが、そういった方はここしばらくお会いしていないです。システム開発に参加されて、「ボタンを追加しようと見積りを取ったら●●万円もかかった」みたいな経験をされた方が増えてきたんでしょうね。

今は「システム開発はささいなことでもお金がかかるらしい」という認識を持たれている方のほうが、ずっと多い印象があります。

――それだけシステムが身近になったということかもしれませんね。ということは、やはりシステムを発注する側も、ある程度ITに詳しくないといけないのでしょうか？

白川さん：もちろん知識は無いよりあったほうがいいです。いろんな事例を知っていることは、発注側の武器にもなりますから。

ただ、詳しいことは正面からプロに聞けばいいんですね。SEやエンジニアなど、システム構築にはITに詳しい人がいっぱいいるわけですし。知らないことは恥ずかしいことではないです。

――知らないよりは知っておいたほうが良いが、専門家並みに詳しくなる必要はない、と。

白川さん：例えば家を建てるとき、「壁の断熱性能を気にしたほうがいい」ということを知らないと、大工さんや工務店と断熱材について話をすることができません。住んでから「思ったより寒いな」と後悔することになるかもしれませんよね。

でも事前に知識があれば、「断熱材は入っていますか？」「どれくらいの性能ですか？」と質問することできます。ただ、だからといって「厚さはどれくらい」とか「あのメーカーとこのメーカーの違い」という内容までは知らなくてもいいじゃないですか。

――そこで「断熱材というものがある」程度の知識があれば十分、ということですね。

白川さん：発注側がITに詳しくなるよりもっと大事なのは「自社の業務をちゃんと語れるようになること」だと思っています。どういうビジネスをやりたいのか、そこでシステムをどう使いたいのか。これをしっかり語れる方って、意外と多くはないんですよ。

システムにより起きた「自社の業務フローがわからない」問題

――自社の業務をちゃんと語れること……。自分の会社の仕事ですし、なんとなく語れそうな気がしてしまいますが。

白川さん：皆さん自分が担当している部分は語れるんです。ただ、全体の流れを把握することは、なかなか難しいんですね。

特に大企業は仕事の多くが分業されています。納品処理ひとつとっても、「納品されたらこういう処理が起きて、あの部署に書類が周り、この部署がそれを受けて請求書を発行する」といった、複雑な業務フローがあるわけです。加えて「もし書類に不備があったらここまで戻ってやり直し」といったエラーケースもある。これを全ての業務について語れるのは、容易なことではありません。

▲「システムを“作らせる”」という言い方が「エラそう」なことについては、同書内でも白川さん自ら言及が。「『システムを作る人』と『作らせる人』はともに1つのプロジェクトに挑む対等なパートナーで、上下関係は一切ない」「『システムを作ってもらう技術』だと、あまりにゴロが悪いから」「『システムをともにつくる技術』だと、ターゲット読者がぼやけるから」（同書より）とのこと

――確かに、大企業では「隣の部署が何をやっているかよくわからない」みたいなケースが多々あるのかもしれません。

白川さん：こういった業務のブラックボックス化が起きてしまっているのは、「今のシステムが良くできすぎている」ことも原因のひとつだと思っています。

私がSEとして働いていた25年ほど前は、システムで全てをカバーできていなかったので、紙で処理をしたり、手作業で運用をしたりする部分もあったんです。実際に手を動かすわけですから、自分以外の社員が行なっている業務も把握できていたんですね。

ところがシステムが発達するにつれ、複雑な業務フローをシステムに内包できるようになった。作業自体も「この画面を表示してボタンを押せばいい」と単純化され、極端に言えば、意味がわからなくても仕事ができるようになった。「役割はわからないが、とりあえずこのボタンを押さないといけないらしいから押している」といったケースもあるかと思います。

――「良くできたシステム」が、仕事をブラックボックス化してしまった、と。

白川さん：そういうことです。そのまま何年も経ち、システムの中身を理解する人がいなくなってしまった企業も少なくありません。

こうして「なんか効率が悪い気がするけど、そもそも何をやっているのかよく知らない。でも、どこに問題があるかわからない」ということが起きてしまうわけです。

――新しく家を建てようとしているのに「今の家のどこに不満があるかよく知らない」「どんな家を建てたいのかよく分からない」と言ってるようなものですね。確かにそれは困ります。

白川さん：ITのことはプロに聞けますが、自社の業務について語れるのはその企業の方々だけです。システム開発においては「自分たちの業務を語れるか」が、一番大事なことだと思います。

――そうなると、これはもはやIT以前の話になりますね。

白川さん：そうですね。「ビジネスのどこに問題を抱えているか」という話にもなってくるので、経営も関わってきます。私どもにご相談いただくお客様も、「うちは販売管理に問題があって……」など、経営課題から当たりを付けて来られることが多いですね。

【ブログ】なぜ「システムを作る技術」ではなく「作らせる技術」についての本が世の中に必要なのかhttps://t.co/6Ew9YMfqRz
本の「はじめに」を転載します。

— 白川克「システムを作らせる技術」読んでね。 (@mshirakawa) July 19, 2021

▲『システムを作らせる技術』の冒頭部はWEBでもチェック可能。書籍では、発注側の目線に立ったシステム開発プロジェクトの段取りだけでなく、白川さん自らが現場で体験した数々の事例が「コラム」として紹介されている

――では、実際に販売管理に課題があるとして、「その業務フローのどこをシステム化するか」も、自社内で判断するべきなのでしょうか？

白川さん：そこは難しいところです。勉強熱心な方だと「この部分にこのソリューションを」と指定されることもありますが、「判断が付かない」と私たちコンサルタントにご依頼されるケースも多いですから。

ただ、その疑問をSEに直接ぶつけると、「うちのソリューションならコレがありますが」と、噛み合わない会話にもなりかねません。SEに声をかける前に、自社内である程度の方針は決めたほうがいいかと思いますね。

システムを作ることは、なぜそんなにも難しいのか？

――それにしても、企業にとって「他の企業に何かを作ってもらう」のは、なにもシステムに限った話ではないですよね。他の発注物と比べて、システムの発注はどこに難しさがあるのでしょうか？

白川さん：まず言えるのは「目に見えないこと」でしょうね。操作画面はあくまで表面上のもので、その裏にはたくさんの処理が走っています。家を建てるときは模型や図面からイメージを膨らませることができますが、システムの場合はなかなか難しいんですね。

イメージと違うものが完成すれば、当然「こんなはずではなかった」という評価になります。こうした行き違いを防ぐために、「システムのプロトタイプを作って体験してもらう」といったプロセスが必要になるわけです。

それともうひとつ、「組織で作る」のも、システム作りならではの難しい点だと思います。

――組織で作る？

白川さん：また家の例えで恐縮ですが、家を建てるとき「リビングはこうしたい」「キッチンはこうしたい」という要望は、せいぜい夫婦で話し合って決めれば済むじゃないですか。

でもシステムを作る場合、関係者が多いんです。全社横断のシステムになればなるほど難しい。営業部門と経理部門で言ってることが違うとか、情報システム部門とビジネス部門でやりたいことが異なるとか、それはそれはいろいろあって……。

ひどいときには、ある程度話が進んだあとにボスみたいな人が出てきて、決まったことが全部ひっくり変える、みたいなことも起こるわけです。

――想像するだけで震えがきます。

白川さん：日本の企業では、状況をクリアにするということを嫌がりますし、責任の所在をあいまいにしがちなこともありますね。

目に見えないあやふやなものを作るというのは本当に難しいのでひとつひとつコンセンサスを積み上げていくしかありません。システム構築がうまくいかない要因の大半は、これらをマネージしきれていない発注者の責任というのもあると思っています。

――最初はうまくコンセンサスをとってスタートしたのに、後半になって失速するパターンというのもあるでしょうか？

白川さん：プロジェクトを進めるうちに、手段と目的を混同してしまうケースは多いですね。厳しいスケジュールや予算のなかで、一生懸命にタスクをこなすうち「とにかく稼働させなくては」と、稼働することが目的になってしまうんですね。

――本来の目的は「業務を改善させる」はずだったわけですよね。

白川さん：その通りです。稼働自体が目的になってしまうと、業務改善が正しく行われません。なかにはシステムが入れ替わったことを現場が認識せず、「使いにくくなった」とクレームが入ったこともありました。

――「ボタンを押せばできたのに、ボタンがなくなった。どうしてだ」みたいなことですか。

白川さん：そうですね。この場合はボタンを押さなくても業務が進むよう改善したのに、そのことが伝わっていないわけです。当然、作業効率も上がりません。「新システムが稼働して良かったね」で終わらせると、こうしたことが起こりえます。

手段を目的化させないためにも、プロジェクト終了時は「稼働して良かった」で終わるのではなく、「本当に業務は改善されたのか」をきちんと振り返ることが必要ですね。

お互いの思いを口にできる「プロフェッショナルの関係」を目指す

――失敗の要因で気になったんですが、「ベンダーが頼んだ通りに作ってくれない」といったこともあるのでしょうか？

白川さん：もちろん、残念ではありますがあり得ます。ベンダー選びは慎重に行うべきで、妥当な提案をしているのか、スキルは十分に足りているかなどを見極めなくてはなりません。ただ、発注側がシステムに精通していないと、その判断はやはり難しいかもしれませんね。

――こういう時のために、白川さんのようなコンサルタントがいるわけですから……。コンサルタントにお願いすること以外に、ベンダーの力量を見極めるコツはありますか？

白川さん：そのベンダーに、過去に手がけたクライアントを紹介してもらう、という方法があります。「実際に御社のシステムを導入した企業の感想を聞きたい」とお願いするわけです。この時点で「教えられない」と断られたら、危険信号でしょうね。

――なかなか思い切った依頼ですが……。でも紹介してもらえたとして、相手は感想を教えてくれるものですか？

白川さん：同業他社でも、結構教えてくれるものですよ。ベンダーがいない場だと、ぶっちゃけ話をしてくれることも多いですし（笑）。恐らく、難しいプロジェクトに挑戦する仲間同士、みたいな感情があると思うんですよね。「あなたがたもこれから大変でしょうから」と。

そもそも情シスの方々の中には、ユーザー会などのコミュニティに参加して、横のつながりを大事にされている方も多くいらっしゃいます。システム開発にお金をかけられないのであれば、足を使って情報収集をされるのも、ひとつの手段だと思います。

――やはり「作ってもらう」という受け身の姿勢ではなく、積極的に動いたほうがいいわけですね。

白川さん：そうですね。これは普段の仕事の中で感じることなんですが、ほとんどのお客様が「聞いてみる」「言ってみる」という基本的なことに、ためらいを感じているように思うんです。

例えば、冒頭におっしゃっていた「ボタンを1つ追加したい」という話ですが、最近は簡単に追加できるシステムも増えているんですよ。

――え！　ボタン1つの追加でも、すごくお金がかかるはずでは……？

白川さん：以前は作り込みが必要でしたが、最近はノーコードの発達もあり、設定だけで済むこともあるんです。テクノロジー自体も変わってきているんですね。

なのでまずは、やりたいことを言語化した上で、ベンダー側に思いを伝えてもらえたらと思います。そうすれば、案外すんなり実現できるかもしれませんし、逆に「難しい」と言われたら社内に持ち帰って検討すればいいんですから。

――「思い切って聞いてみる」に心理的なハードルを感じる人も多いかもしれませんが、聞いてみないとわからないなら、聞かないと損ですよね。

白川さん：発注側が質問をためらってしまうのは、もしかするとエンジニア側と良い関係が築けていないからなのかもしれませんね。「どうせ無理だろう」「迷惑かもしれない」「ばかだと思われるのでは」と思うと、なかなか言い出せないないでしょう。

ですが、そうしたウェットな思いは、システム構築には必要ないものだと思っています。やりたいことは口にする。できることもあるし、無理なこともある。事実のみを淡々とキャッチボールをしたほうが、お互い気持ちよく仕事ができるはずです。

発注側としては、まずはフラットに「こういう機能がほしいんです。無理なら諦めます」と言える関係づくりを意識してみてはいかがでしょうか。余計な気を使わず、お互いの役割に専念できる。それこそが、プロフェッショナル同士の関係なのではと思います。

文＝井上マサキ／図版とイラスト＝藤田倫央／編集＝伊藤 駿（ノオト）