近年、業務プロセスの改善や製品・サービスの向上のためにDX化への関心が高まっています。
とはいえ、デジタル技術の活用は突然できるようになるものではなく、導入に苦しんでいる経営層の方も多いのではないでしょうか。
そこで今回は、e-Taxなどのシステム開発に携わった嘉悦大学の高橋教授に、DX化に向けて必要なことをインタビューしました！
取材にご協力頂いた方
嘉悦大学 経営経済学部 教授
高橋 洋一（たかはし よういち）
1955年、東京都に生まれる。東京大学理学部数学科・経済学部経済学科卒業。博士(政策研究)。1980年、大蔵省入省。理財局資金企画室長、プリンストン大学客員研究員、内閣府参事官(経済財政諮問会議特命室)、総務大臣補佐官などを歴任し、郵政民営化、政策金融改革を企画立案。その後、2006年から内閣参事官（官邸・総理補佐官補）。2008年退官。金融庁顧問等を経て、現在、嘉悦大学教授、内閣官房参与。
主な著書に、財投改革の経済学（東洋経済新報社）、さらば財務省（講談社） 、新・国債の真実(あさ出版）などがある。
YOUTUBE 高橋洋一チャンネル
効率的にDX化を進めたいならプログラミングの知識が必須になる
佐藤：まず初めに、経営層が自社のDX化を進める際には何が必要になるのでしょうか？
高橋教授：極論を言ってしまえば、経営者自身がプログラミングをできるようになることです。自分でプログラムを書けない人が上に立つと、部下に指示を出すことすらできません。無理に指示を出そうとすれば、「こんな感じでお願いします」という抽象的なものになってしまう。これでは実際にプログラムを書く側は大変なだけで、DX化を進めるなど夢のまた夢です。本来、トップが自分で全部プログラミングできるけれど、忙しいから部下に任せる、というのが正しい形なんです。
とはいえ、現状では経営者自身がプログラム言語を理解して、使いこなせるというケースは非常に少ないと思います。プログラムなどの特殊言語を習得するには2年ほどはかかりますから、その間にもDX化を進めておきたい、ということならプログラムがわかる人を腹心として傍に置きましょう。
佐藤：その際もやはり、プログラミングができることは最低条件になるのですね。
高橋教授：その通りです。そして、プロジェクトマネージャーを決める時には必ず能力主義で取り立ててください。常務や専務にプログラミングができる人がいればそれで構いませんが、プログラムというのはひとつの言語です。英語の仕事が入った時に英語がわからない人が担当してもどうしようもないのと同じで、プログラムがわからない人にプロジェクトマネージャーを任せても何もできません。平社員でも良いので、どんどん抜擢しましょう。
その上で、プロジェクトマネージャーの判断で動かせるお金、そして権限もしっかり与えることが大切です。自社内だけではプロジェクトを回せるだけの人手が足りない、といった場合は社外に頼んだり、能力のある人を社外から選んでくることも視野に入れなければいけませんからね。
プログラム言語でやり取りすれば業務スピードは格段にアップする
佐藤：なるほど。それは、高橋先生がe-Taxなどのシステム開発に携わる中での経験から導き出されたことなのでしょうか？
高橋教授：そうですね。私自身が手掛けた大きなシステムとしては、主に3つ挙げられます。金融機関で使われているALM(アセット・ライアビリティ・マネジメント・システム)、国税庁のe-Tax、それに郵政民営化の時のシステム開発です。全てに共通していえるのは、私がこれらのプロジェクトを指揮していた時は、プロジェクト内でのやり取りをプログラム言語で行っていたということです。
佐藤：プログラム言語でやり取り、とは？
高橋教授：簡単にいえば、部下への指示も部下からの連絡も、全てプログラム言語を使って行うということです。プログラム言語がわからない人に向けた言い回しや、注釈などは一切つけずにです。先ほど英語を例に挙げましたが、英語の会議でいちいち通訳を通していたら時間がかかって仕方ありませんよね。同じように、プログラムも言語なので通訳なしでダイレクトにやり取りした方が誤解が生まれないし、素早くコミュニケーションが取れるんですよ。
まずプロジェクトマネージャーである私がシステム全体を見渡してみて、「ここはこうできるんじゃないか」とプログラム言語を使って指示を出す。するとSE（システムエンジニア）の人が「できますね」と言ってくれるので、そのやり取りをひたすら積み重ねていく。結果、ものすごく短期間で仕事が終わります。SEの人からしても、私が指示するのはプログラムに基づいて考えられる実現可能な範囲の内容だから、無理難題は一切含まれません。
トップはプログラミングができる人間に全て任せてしまって、現場の実務者とはプログラム言語でやり取りをする。そうすれば、いろいろなことがあっという間に終わりますよ。そのためにも、トップが少しでもプログラムに対して理解がある方がプロジェクトはスムーズに進みます。
佐藤：確かに、英語と同じと考えれば同じ言語で話した方がやり取りはずっと楽になりますね。
高橋教授：いくつか実例を紹介しましょう。先ほどお話ししたALM(アセット・ライアビリティ・マネジメント・システム)は、主に金融機関で使われているシステムです。一般的には何十億円という単位がかかるプログラムなんですが、私が開発した時にかかった費用は数千万円でした。プロジェクトの人員はプログラミングができる人間だけにして、やり取りも全てプログラム言語だけで成立するような仕組みにした結果、工程数が大幅に削減され効率化ができたんです。
全面的にシステムの構築をした国税庁のe-Taxは、20年ほど前ですが当時の総理や大臣から声がかかって取り組むことになりました。総理も大臣もプログラミングは全くできない人だったんですが、私がプログラミングが得意だとご存知で、プロジェクトのリーダーに抜擢してくれたんです。権限も与えられていたので、国税庁の長官に頼んで外部から精鋭を集めてもらいました。周りはプログラム言語でコミュニケーションが成立する相手ばかりなので、後の話は簡単です。
郵政民営化の時は、当時の首相に「郵政民営化に関して、システムが間に合わないから実行できないと言われたが本当か」と問われたんですよ。そこで私が概要を見て、「いや、できますよ」と答えたらそのまま任される流れになりました。システムやSEの人数を見てチームを割り振り、時間を短縮できる部分を見定めた上で、工程数から完成までの期間を計算して「いつまでにできます」と。郵政に関してはもう稼働していたので、システムベンダー（情報システムの構築や運用を請け負う事業者）のような話なんですが、郵政の幹部はほとんどプロジェクトに入れていません。周りをプログラム言語がわかる人間だけで固めたことで、進行スピードは格段に上がり、仕事で生じるほとんどの相談は私とシステムベンダーのSEとの会話だけで解決するといった状況にしていました。しかも、システム内部の構造も非常にシンプルですっきりしたものになり、障害などのトラブルも少なくなりましたね。あまりにもスムーズにプロジェクトが完了したので、周りの人たちからは「何だかわからないうちに全て終わっていた」と言われました。
プログラムはできる限りシンプルにした方がトラブルに強くなる
佐藤：実際のプロジェクトのお話を伺うと、やはりプログラム言語の理解力が仕事の効率を大きく左右することを痛感します。システムエラーのお話も出ましたが、昨今ではシステム障害によるトラブルなどがたびたびニュースになっています。強固なシステムを構築するためにはどうすれば良いのでしょうか？
高橋教授：最も効果的な対策は、システムをできる限りシンプルにすることです。20年前に私が作ったe-Taxが良い例ですが、大きなトラブルが起きたという話は一度も耳にしていません。私の作ったシステムが障害に強いのは、疑問の余地がないほどシンプルに作っているからです。
某銀行が、なぜ数年の間に大規模なシステム障害を何度も何度も起こしているかといえば、既存のシステムを活かそうとして無理をしたことが大きな要因になっています。本来、ああいったシステムは利便性よりも安定性が重要ですが、既存のシステムを活用しようとすると無理が生じてしまう。単純なロジックの方が間違いが起こらないし、既存のシステムを一度全部捨てて、全てを統合したものを新しく組み立てた方が安定性の高いシステムが構築できるんです。
障害を起こしにくい堅固なシステムを作りたいなら、こういう決断ができる人、能力のある人をプロジェクトマネージャーに据えるしかありません。
優秀なプロジェクトマネージャーを引き立てられるかが鍵
佐藤：すると、システムの精度を上げるためにも、経営者自身がプロジェクトマネージャーを見定められるような目を養っておくことが求められますね。
高橋教授：DX化を意識するなら、就職時の資格要件などでも構わないので、経歴に開発経験があるかはチェックしておいた方が良いでしょうね。自分の組織内にプログラミングなどの特殊言語ができる人間が何人いるのか把握していないと、プロジェクトマネージャーに抜擢するどころではありません。加えて、プロジェクトマネージャーには仕事を割り振る能力と、プロジェクト内の仕事は全て1人でこなせるくらいの能力は必要です。
プロジェクトというのは基本的にチームで進めるものですし、仕事を分担した方が確実に早く終わります。なので、「これはあの人の得意分野だな」「こういう指示をすれば簡単にできるな」とチーム全体を見て、適切な仕事をわかりやすく割り振る力は必ず求められます。
ただ忘れてはいけないのは、最悪、プロジェクトメンバーが全員辞めてもプロジェクトマネージャー1人で仕事ができる、くらいにはしておかないと後々困るということです。誰かに仕事を頼んで少しでも自分の負担を減らそう、と考えるのではなく、人に頼んで上手くできなかった時は自分で被る。それくらいの能力がないと部下に対して明確な指示は出せないので、プロジェクトマネージャーは務まりません。
佐藤：そういった能力主義での抜擢は勇気が必要かもしれませんが、プロジェクトをスピーディに進め、少ない費用でDX化を達成するには欠かせない考え方といえそうですね。
高橋教授：DX化は基本的に仕事の流れ、やり方を変えるということですから、経営者ならどうやってやり方を変えるのか、は指示できるかもしれません。ただ、繰り返しますがもっとブレイクダウンしてプログラム化していかないと、最終的には何がなんだかわからなくなってしまいます。それこそ、私は文系の官僚の話にはあまり耳を傾けません。「何か良いアイデアがあるなら、プログラムを書いて持ってきてくれ」と言ってしまう。その方が圧倒的に時間が節約できますからね。
佐藤：貴重なお話、ありがとうございます。最後に読者である経営層の方へ向けて、メッセージをお願いできますか？
高橋教授：プログラム言語でやり取りをしていても、文法などを間違えることはもちろん起こり得ます。ですが、たとえ文法に多少のミスがあったとしても、一定の知識がある人が見れば「こういうことをやりたいんだな」とすぐにわかる。これはプログラム言語がわからない人に対して噛み砕いて説明するより、ずっと誤解なく、短時間で意図が伝わるやり方です。
私などは人に仕事を頼む時、曖昧性が出ないようにプログラム言語で指示を書いて渡しています。そうすればやりたいことが非常に明確になって、疑問の余地が残りません。たまにプログラミングができる人とできない人との間で通訳しようとする人もいますが、正直なところ、仲介なしの方がコミュニケーションは格段にスムーズにできます。
だからこそ、私が郵政民営化の時に総理からプロジェクトを任されたように、全てプロジェクトマネージャーの責任と判断で仕切れる仕組みを作ることがDX化に向けた最短の道のりとなるでしょう。ぜひ自社内の逸材を発掘し、能力を発揮できる場を与えてみてください。
DX化を進めるなら、プロジェクトマネージャーの存在が全体の成否を左右することは必ず覚えておかなければいけません。また、プログラム言語で意思疎通できる環境を整えれば、業務のスピードアップや費用削減も期待できます。
経営者自身がプログラミングを学ぶことで、DX化をさらに加速させることが可能になるでしょう。経営層として自社のメンバーの能力をしっかり把握し、適材適所で活かせるように努めたいですね。
（対談／佐藤 直人）
