経営者が欲しいシステムって?

臨床検査企業では思いっきり仕事ができたのですね。

臨床検査企業では全社的にバラバラだった基幹システムをまとめるという話で入ったのですが、入社してみるとやるはずのプロジェクトがなくなっていました。IT戦略部門担当役員の下、理事という肩書で社内を自由に見学したり、レポートを書いたりしていました。しばらくすると経営トップから声が掛かった。臨床検査企業の問題点を指摘したレポートを読んでくれたのです。「昔ながらの発想で、現場の業務がスムーズに動くシステムを作っても会社は儲からない。どういう業務をやるか考えるのは経営者だから、経営者が欲しいシステムを考えろ」と言われました。

「経営者が欲しいシステム」のアイデアはあったのですか。

総合商社時代の上司から「経営者の知りたいこととは3つしかない」と言われました。
1.今どうなっているのかを知りたい
2.自分の指示したことを本当に実行しているのか確認したい
3.いったい誰が頑張ってくれているのかを知りたい
この3つを実現するシステムは従来の発想では不可能です。いくら考えていてもピンと来なかったので、いろいろ調べました。ある時、情報システム総研の児玉公信さんの論文を発見したのです。「多品種少量システムは金融の分野でも転用できる。企業にとって必要な基幹システムは企業の活動を記録するものである」という内容でした。

臨床検査企業のアーキテクチャの中には「1個流し」「計画実績」が基本にあります。トヨタ生産方式とほぼ同じ形です。「1個流し」とは、1つの仕事を始めから終わりまで1つ1つ完結させて、次の工程に渡す、というものです。余計なモノは作らない、在庫は持たないのが基本です。「計画実績」とは、仕事をやる時は計画通りやりましょう、ということ。計画通りにいかなければ、修正をかけて、もう一度練り直します。非常にシンプルです。仕事はこうだよね、という基本理念があれば、テレビ局の仕事でも商社や営業、物流の現場だろうがどこも同じ。どうやるかは現場の人間が考えればいい。仕事というものは、与える側が計画を立てて、1個ずつ流せばいいだけのこと。あとは業務を知っている人たちが上手くやってくれる。機能と仕事の区別がつきました。

機能と仕事の区別を具体的に説明してください。

例えば、給与計算システムは最終的には数字をはじき出すのが仕事です。計算するのは正確性を要する機能であって、仕事ではありません。給与計算の仕事はコンピュータと関係ない。計算はExcelや電卓などでもできるわけで、迅速・正確であればパソコンでやらなくてもいいのです。根本的には仕事の流し方は変わらない。「業界によらない企業に共通する課題」が見えてきました。要するに経営者の知りたい3つのことを明らかにすればいいのです。

クライアントとはどのような方法で議論を進めているのですか。

基本思想、基本構造を固める議論は、まず「あなたの会社はどういう仕事をしていますか」というところから始まります。会社の基本構造を明らかにします。会社が何を売っているかは関係ありません。経営者が気にかけているのは、お客さんから注文を受けて、約束したことをちゃんと実行して最終的に満足してもらって、お金をもらえるのか、ということ。一番上に商流という階層があり、次に資源、物流、金流の階層があり、すべての階層の下に、実行という階層があります。例えば注文を受けて納品して、お金をもらうという商流を実現するために、部品を調達して工場で物を作り、完成した物を運びます。どこの業界でも当てはまるシンプルな形です。このような会社の基本構造の話をして、後は個別的に不必要な階層を取り除いていきます。

競争相手との一番の違いは何ですか。

経営者の視点を持って会社全体のシステムを作っている、という点です。会社のシステムを作るときは全体で考えましょう、というエンタープライズアーキテクチャ(EA)の話をしています。EAはピラミッド構造で上から、政策・業務体系(BA)、データ体系(DA)、適用処理体系(AA)、技術体系(TA)となっています。EAでシステムを考えましょう、という話になっても、一般的なコンサルはBAしかやりません。DAとAAを一緒にやる人はいるのですが、普通はBAからTAに投げる。それぞれをつなげて全部をきちっとできる人はほとんどいません。

なぜ全部つなげて考えないのですか。

これまではそういう習慣が業界にはありませんでした。一般的には、BAは上流のビジネスコンサルがやる、TAは開発者がする、DAやAAは開発者がついでに考えることが多いです。EAの階層を縦に「ぐちゃっ」と作っている。物流システム、製造システムなど、業務ごとに縦に切り分けているのが一般的で、上から下へつなげて動くアーキテクチャとして設計できるのは我々のグループだけです。

どんなことをしてみたいですか?

基幹システムを導入したけどうまく機能しない、という声をよく聞きます。我々の言う基幹システムとは企業の活動を記録するもので、企業の様々な業務を助けるシステムではありません。業務システムAと業務システムBがつながっていないため、人間がつなげているのが現状です。だから手間がかかるのです。業務単位で作っているので、うまくいかない。業務ごと切り分けをしたほうがいい、という別の観点の分断化です。物を売る専門家、作る専門家とした方が効率はいいのですが、だからと言って、本来お客様の注文が横に流れているのを縦にぶった切ってはいけません。

全体構造で一つの企業を動かしたい。静岡で一社動き出しています。モデルケースになると嬉しいです。昔のシステムづくりは要求仕様を確定させないと、お金をもらえないと思っていたところがあります。確定させないと、自分たちの仕事ができないと思っているのです。だけど、本質的にはシステムの要求は、確定した瞬間に古くなる。これを解決するには、どんどん作っては壊しを繰り返すのが必要となります。会社として仕事の成熟度がどんどん上がっていくと、システムが人に教えるようになります。「形式知」が会社の知識となり、形式化されると素人でも同じ仕事ができるようになるのです。会社全体として成立する構造で考えることが重要です。構造の中で人が動けるシステムを作ればいいだけです。