2023年 6月 19日

第6回巨大システムを成功させる

巨大システムとは「政治」なのである

技術閑話

ogochan

書いた本人が言うのは何ですが、今回のエントリは長いです。薄めの新書版のビジネス書くらいの分量があります。分割することも考えたのですが面倒臭いのでそのまま上げます。覚悟して読んで下さい。

このブログは会社の広報のためのものですから、あまり政治的なことやセンシティブなことを書くつもりはありませんが、ここ最近「巨大なシステム」の構築で失敗する例を多く見掛けるようになりました。

私個人としては昔の仕事、特に前職での仕事をドヤることはあまり好きではないのですが、私には「巨大システム」を開発して成功させ今も多くの人に使われているという経験があります。

ORCA Project：日本医師会ORCA管理機構

その経験からすると、昨今の失敗事例を見ると「そりゃ失敗するよね」と思ってしまいます。

そこで、「なぜ失敗するのか」「どうしたら成功に近付けることができるのか」といったことを少し書いてみたいと思います。まぁ、この通りにやれば絶対に成功するというわけではないですし、そういったことがあるのが「巨大システム」なんですけど。

と同時に、件のプロジェクトのプロジェクト管理については誰も記録をしていません。特定の優れたプロジェクトマネージャがいて成功したシステムではない(私も違う)ので、ドヤる人がいないせいもあると思います。技術要素については私の個人ブログに15年くらい前に書いたものがあるので、技術的にどうであったかはそちらを見てもらえば良いでしょう。

このエントリはそういったプロジェクトの内部にいた一エンジニアとして書いています。ここではプロジェクト管理の一部しか言及しませんが、プロジェクト管理という視点での記録としても書いておきたいと思います。20年(以上)前のプロジェクトではありますが、このような「巨大システム」の問題は技術そのものではなく「人間」に依るところが大きいので、単なる昔話以上には意味はあるでしょう。

「巨大システム」とは

まずは言葉の定義をしておきます。特に「巨大システム」のような主観の大きく入った言葉を定義を説明なしに使うと、何のための話をしているかわけがわからなくなってしまいますからね。

「システム」とは

「システム」についてはいろんな定義があると思いますが、この辺のものを表現する言葉をまとめて以下のように区別しておきます。

アプリケーション: システムを構成するソフトウェアです。開発するのはプログラマです。
(狭義の)システム: いわゆるコンピュータシステムです。(関係あれば)ハードウェアやインフラを含めます。開発にはシステムエンジニアが登場します
(広義の)システム: 「(狭義の)システム」を動かす人間を含めてのシステムです。つまり、体制とか運用といったものを含めます。開発にはコンサルタントにあたるロールが必要です

私がシステムエンジニアとしての新人だった頃は、(広義の)システムを設計できるようになりなさいとか言われたものです。広義のシステムに関連する技術となると、どっちかと言えば文系に属する知識が要求されます。それゆえ、「別に理工系でなくてもシステムエンジニアは出来る」みたいな言葉は、ある意味真理だったように思います。むしろ、政治とかマネージメントと言った、あまり技術者が得意としない方向のスキルが要求されることが多いわけですから。他方、この言葉が一人歩きしてしまって、SI業界にはCS(Computer Science)軽視みたいな空気が出来てしまったりといったこともあったように思います。

永年こういった世界にいて思ったのは、結局のところ

一流になるには両方が出来ないとダメ

みたいな、ごく当たり前のことを言われているだけだったりします。

「大規模システム」とは

まずは「巨大システム」の話をする前に、「大規模システム」について考えます。

いろいろな定義があると思いますが、私の肌感覚、あるいは業界の空気感に近い説明を考えると、

異なる役割りの技術者が参加する

というのが、一番しっくり来るのではないかと思います。

もちろんここで「異なる役割」というのは結構主観的なもので、何人も技術者が参加していれば、それぞれ異なる仕事をしているのは当たり前ですし、逆に一人で開発していてもいろんな役割を担うものはどうなのかとか、そういった話はあると思います。

ただここではそういった細かい厳密な話ではなくて、もっと誰の目にもわかりやすい「異なる役割」という話です。

例えば、ある程度以上の規模のシステムになると、「システム」を動かすためのサーバが必要になります。既存のサーバにソフトウェアを入れるだけで動かせるのであればいいのですが、ある程度の規模を超えるとサーバを専業でいじる技術者が必要になります。データベースもある程度の規模になると、DBのチューニングや並列化といったことを担当する技術者が必要になります。そういったことが増えると、ネットワークやサーバの使い回しに関する技術者が必要になります。

また、今時ですとアプリケーションを開発する時でも、画面遷移を設計する人と画面の見掛けを作る人は別になったりしますし、画面そのものの動作とビジネスロジックは別だったりします。あるいはスマホのアプリを作りましょうということになると、別途スマホにもシステムの開発が発生します。要員の替えの効かない仕事の数と言っても良いかも知れません。

というように、細かいことを言わなくても役割りの異なる人々が参加することになります。小さなシステムであれば、そういったことも含めて一人でやったりするわけですし、そういったことをアシストしてくれるフレームワークやツールも増えているので、昔の目線では「大規模」と思っていたものが結構一人でも作れたりすることもあるのですが、それでもある程度の規模を超えてしまえば、異なる役割りの技術者が参加して作ることになってしまいます。

他方、どれだけソフトウェアの規模が大きくても、全員が同じテーマで開発している場合は、「大規模システム」ではないかも知れません。

たとえば、「単一の言語の言語処理系」であれば、「巨大なアプリケーション」になるかも知れませんが、やっていることは基本的には「言語処理系の開発」に過ぎません。要員のスキルの多少はあっても、結局みんな同じ仕事をし、誰かが手が空けば他の忙しそうな人の代わりになることもできます。

これが「言語システム」となると、「ライブラリの開発」「ドキュメントの作成」のような、異なる役割の技術者が必要になります。また、LLVMやGCCのような「言語処理系インフラ」となると、もっと異なる役割の技術者が必要になりますから、「大規模システム」と言えると思います。つまり、「巨大アプリケーション」であることと、「大規模システム」であることは、必ずしもイコールではないことは留意しておいて下さい。「比較的小さなアプリケーション」であっても「大規模システム」になってしまうこともありますし、逆もあるわけです。

もっと簡単な定義を持って来るなら、

工程管理が必要になったら

とも言えるかも知れません。

もちろん一人開発であっても工程管理をしても良いですし、あった方が見通しが良くなったりもするでしょう。とは言え、一人あるいは「車でマックに行ける人数」での開発であれば、特に工程管理なんてことをしなくても、そんなに大きな問題は起きませんし、工程管理のオーバーヘッド(管理工数だけではなく「合わせる」ということで余分な工数が発生しますね)もなく開発ができます。

ところが、ある程度の規模を超えると

足並みを揃える

ことが必要になり、工程管理なしには開発はできなくなってしまいます。開発者が揃って同じものを開発している時であれば、ある程度規模が大きくても工程管理なしに構築して行くことは可能ですが、中間成果物がそれぞれあって、それぞれの作業がそれぞれに依存しているというようなことになれば、工程管理なしに開発はできません。

このような状態が予見されるシステムは「大規模システム」として考えた方が良いでしょう。もちろん「大規模システム」と言ってもその中で大小あるわけですが、カテゴリとしての大規模システムはこの辺だということです。

ただし、ここでの「システム」はあくまでも狭義のシステムであることを留意して下さい。

「巨大システム」とは

「巨大システム」と言った時のシステムは広義のシステムです。後で詳しく述べますが、ここは大事な鍵です。

表題の「巨大システム」は

多数の利害関係者が絡むシステム

です。つまり、システムはもはやコンピュータやその周辺の運用といったことを超えて、

政治

となったシステムです。国家プロジェクト的なものは、だいたいここに含まれると思って良いです。何しろ国家プロジェクトとなると、国民全てが利害関係者になってしまうわけですから。

冒頭に挙げた、私がかつて開発に従事したORCA Projectはまさにこれでした。いろんな利害関係者が存在し、それぞれがそれぞれのポジションを主張する。「開発会議」は単なる仕様の打ち合せではなく、その仕様がどういった人達にどう影響を与えるか。ある仕様を実装するには、どんな人達を納得させるか... まさにこれは「政治」と言うしかありません。打ち合せの3/4くらいは「政治」の話でしたね。個々の機能仕様の話は、ある意味「ついで」だったりしたくらいです。

それが単に政治だけの問題であれば、他人事で済ませることも出来るでしょう。政治的無関心という態度も取れるかも知れません。しかし、これはまた同時にシステムの実現についての問題でもあるわけです。「政治」の成り行きによっては仕様が大きく変わる、あるいはプロジェクトそのものが大きく変わる。「俺はシステムエンジニアなんで」という態度を取ることはできないわけです。

実はシステムが「巨大システム」になってしまうのは、ソフトウェアの規模のせいでも、「大規模システム」であるからでもありません。つまり、「狭義のシステム」の大きさに依りません。狭義のシステムの規模よりも、

影響範囲の大きさ

が問題になるわけです。そして、影響範囲が大きいと、狭義のシステムそのものの難しさを超えて、広義のシステムの難しさが出て来るわけです。

「巨大システム」のアンチパターン

「巨大システム」と呼んでいるものが何であるかをはっきりさせた上で、まずはそういったシステムがどういった理由で失敗して行くかを挙げて行きたいと思います。なお、特定のシステムを貶めたり批判したりする意図はないですし、それによる批判に対するために細かく調べるのが面倒なので、自明なものと最初に書いたプロジェクトのことをを除けば「そんな感じ」みたいなゆるっとした話にしておきます。より具体的な話が必要であれば、コンサル契約をお願いしますｗ

解決については次章に書きますので、ここではアンチパターンを挙げるだけにしておきます。

利害調整不足

「巨大」ってほどでなくても、ある程度以上の規模のシステムが失敗する原因の最大のものはこれだと言って良いと思います。かつて名著と呼ばれた「動かないコンピュータ」に挙げられたシステム構築の失敗事例の代表的なものとして挙げられています。

ただ、一般的なシステムと比べて「巨大システム」となると、さらに利害関係が複雑になります。

一番厄介なのは、商業的な利害の調整です。極端な話、あるシステムが稼動することで、あるビジネスが無効化してしまう場合、当然ながらそのビジネスをやっている人達は抵抗勢力になります(たとえばレジ袋有料義務化のせいでレジ袋の会社が潰れたりしましたね)。仮にそのビジネスの無効化がゴールの一つであったにしても、いやそうであるがゆえに、利害調整不足は致命傷となりかねません。

そしてこの問題は政治問題化しやすい問題です。と言うか、まさにこれが日本の政治と言っても良いでしょう。しかし、そうなってしまえば、なおのこと利害調整は拗れます。なぜなら、「政治問題化したことによる新たな利害関係」が生まれたりするからです。当初の問題が解決していても、「元々反対だったから」というような意味不明の理由で抵抗が続いたりすることもあります。また、直接目の前にあるシステムとは関係ない「党派心」で物事が変わったりします。

あまり大きくないシステムを、あまり大きくない組織で導入する場合には、「鶴の一声」とか「ワンマン」みたいなもので押し切ることも可能です。しかし、国家規模になったシステムの場合、この手法を使うことはほぼ不可能ですし、より問題を複雑化させてしまう... と言うよりも、死亡フラグをいくつも立てることになります。何ならその「一声」を発した人の政治生命まで危うくなったりもします。

無用な複雑さの持ち込み

「巨大システム」であることと「大規模システム」であることは、必ずしも一致しないということは既に述べた通りですが、現実には巨大システムは大規模システムであることが多い、と言うより普通です。

大規模システムも元々そういった大きく複雑なものを作りたくて始めるわけではありません。必要な機能仕様を並べて行った結果として、大規模になってしまうわけです。「会計システム」の基本なんて、伝票を整理して集計するだけで、その気で作れば一人で一週間、つまり7人日もあれば出来てしまったりするわけですが、いろんな「あると便利」な機能や「準必須」な機能をつけて行くと、だんだん複雑巨大になって行きます。

しばしば「Excelでお手軽システム」みたいなものがあります。最初はお手軽で便利に出来ていても、複数の人が同時に操作したらどうなるか、大勢の人全部に全てを見せて良いか、変更する時の権限やフローはどうなるか... ということを詰めて行くと、案外に大きなシステムになってしまいます。私の「7人日で作った会計システム」も、一人で全権持ってやる分には良かったのですが、私以外の人に操作させることを考え始めたらいろいろ複雑なことになって来ました。これはまぁまたそのうちgitに置きますが(ローカルブランチにしかない)。

これが巨大でないシステムであれば、そういった「本来目的としていない機能」をバサバサ切るのがシステムエンジニアの腕の見せどころであり、そうやって過剰に複雑なシステムになることを避けるのは大事なことです。ですが、「巨大システム」となるとそれも容易ではなくなります。

「マイナンバー」のシステムも、元々はそんなに複雑奇怪なシステムではなくて、ごく初期にあった複雑さは、国家レベルの利便性と安全性のためには必須のものでしかありませんでしたし、割と妥当なところであったように思います。

しかし、「マイナンバーカード」なんてものに汎用性を持たせるということになった時点で、システムは急激に複雑怪奇なものになってしまいます。そして悪いことに、そこで発生してしまった問題のために、当初の目的であった「マイナンバーカード」の普及に逆に足を引っぱることになってしまい、挙句の果てにはマイナンバーそのものをやめろという世論まで起きています。

これがまさにこの節の表題である「無用な複雑さの持ち込み」です。

既に書いたように、システムなんてものは放っておいても複雑になって行くものです。それをいかにしてそうならないように持って行くかが、システムエンジニアの腕の見せどころです。ところが、「巨大システム」は巨大であるがゆえに、複雑さを増す方向の圧力は強く、またそれを黙らせるのは難しいものとなります。黙らせるのは「政治」ですから。

いきなり完成させる無茶

国家的プロジェクトの場合カットオーバーは明確です。法律や年度で決まってしまっているわけです。最近では複数年度に跨がるプロジェクトも可能になっていますが、何にせよ「完成させるべき日」は決まっています。予定が崩れれば政治問題です。

システム開発なので、いわゆる「納期」が設定されていて、それに向かって開発をするのは当たり前なのですが、巨大システムの場合はなぜかその日程がとてもきちんと決められていて、「この日から完全スタート」という形になっているものが少なくありません。

カットオーバーがきっちり決まっているので、「不測の事態」が起きても遅延が許されません。確かにあまりそういったことは好ましくないのではありますが、複雑なシステムでは不測の事態を完全に回避するのは困難です。

それ程大きくないシステムで既に何かが運用されている場合であれば、しばらくは「並行稼動」という工程を経て、それでデバッグしつつデータ移行しつつ、安全を確認してから正式稼動という方法を採ることが多いのですが、なぜか影響範囲の大きな「巨大システム」はその工程がなくていきなり本番稼動となります。

もちろんそれなりの体制で作られているシステムですし、不安定な状態で並行稼動するというような余分な工数の発生するようなことはしたくない気持ちはわかります。とは言え結局使うのは人間ですから、いきなり本番運用の負荷をかけて動かせるかと言えば、なかなかそう簡単には行きません。そこで大きな失敗をすれば、システムそのものの信用がなくなり、それを回復することは容易ではありません。狭義のシステムがいくら正しく動いていても、「窓口の人がまごまごしてしまった」ということのせいで、システムの信用が下がるのは当然と言えば当然なのですが、開発サイドにとっては理不尽です。

もちろんどんな開発体制であれ、人間の作るシステムですから当然に間違いは存在します。同じように、どんな運用体制であれ、人間の使うシステムですから当然に慣れるまでに時間がかかります。システムが複雑であれば、なおさらのことです。そこに「垂直立ち上げ」を求めるのは、不可能だと思うくらいが丁度いいでしょう。

さらに、一度完成ということになり検収を受けてまうと、不具合が発見されてもなかなか直されないという問題もあります。これも「完成」をあまりに重く考え過ぎている弊害だとも言えます。

コントロールの不手際

システムに不具合は付き物です。

これはいわゆるバグの類をゼロには出来ないというCS上の真理の他に、

利害関係者の多さに起因する仕様上の問題
規模の大きなシステムに付き物の負荷の問題
利用者オペレータ等の不慣れによる問題

などが存在し、結果的にこれらは利用者目線では「システムの不具合」として認識されます。これがある意味不可避なことであることは、システム屋には共通認識としてあると思います。

他方、システムに不具合は付き物というのはあくまでもシステム屋の認識の話に過ぎず、世間一般では

システムは正しく動いて当たり前

という認識があります。それゆえ、今ではチケット販売のシステムが高々過負荷による障害であっても、ニュースのネタになったりするわけです。過負荷で止まっている時などは「待ってりゃ直るじゃん」とシステム屋は思っていても、「特に対処せずに経過を見守る方針」みたいな手のつけようがないかのような報道がされてしまうのは、とても残念です。

また、正しく動いているシステムであったにしても、「何となく良くない」ということは結構あります。たとえば、

何となく個人情報が漏れているのではないか
正しいとされる動作が何か普通の感覚と乖離している
異常系がなんか変
使いにくい

などなど、一々挙げたらキリがないと思います。

システムの不具合は誰が見ても不具合ですから、「とにかく頑張れ」と言う他なく、実際しばらく運用していればだいだい治まって行くものですが、「不具合でなくておかしい」というのは要するに仕様のことなので、ものによっては永久に直されません。それどころか、「慣れ」とか「利害関係」が絡んで来てしまうと、正解が何であるかもわからなくなります。あるべき姿に直したら「前と違って使いにくい」とか言われるのは、技術者あるあるでしょう。

これらの問題が起きた場合、不具合であれば火急すみやかに修正をしてしまうということになるのですが、場合によってはそれが出来ないこともあります。ましてや後に挙げたような仕様上の問題であれば直したくても直せないものになっているかも知れません。そうなると、言い方は悪いですが

文句を言う奴を黙らせる

ということが必要になります。特に「直しようがない」ものに関してはこれ以外の解決はありません。ところが、ここで失敗してしまうと新たな問題となってしまいます。

ここまで読むと、これは「利用者」のことだと思ってしまうかも知れませんが、「巨大システム」となると利害関係者が多く、プロジェクト内部にはその利害関係者の代表がいたりしますから、そういった人達への対応も時として問題の火種、あるいは問題そのものになることもあります。

いずれにしても「コントロール」に失敗すると起きてしまう問題です。「文句を言う奴を黙らせる」と言っても、無理やり口をつぐませてしまえば石が叫びます。石に叫ばれてしまったらコントロールの失敗です。

「巨大システム」成功のポイント

前章ではいくつかのアンチパターンを挙げましたが、それを踏まえてどうすれば良いかの例を挙げて行きます。もちろんここに挙げたことが全てではありませんし、文字通りのケースバイケースなことですので、より具体的な事例についての具体的な対応については別途コンサル契約と言うことで。

以下は順不同です。どれが優先度が高いどれが効果が高いというようなものではありません。

小さく産んで大きく育てる

「巨大システム」をいきなり巨大システムとして作るのは、あまり得策とは言えません。

もちろん「巨大システム」が作られる土壌について考えると、あまりに小さく作っても意味がないものもあります。とは言え、いきなりホームランを狙うような振りをして三振もしょうがありません。

ヒットを重ねて点にする

というアプローチを考えます。

試作の重要性

どのようなものであれ、システムと名のつくものをいきなり作って運用することは出来ません。

たとえば「豪華客船を作りたい」と思って、それを自分達が作った経験が全くないのであれば、まずは「丸木舟」から作ってみる必要があります。丸木舟を作る技術がなければ、豪華客船を作ることは最初から不可能です。そして、そこからスケールアップして行けば、単純に大きさの問題だけではない問題にも気がつくことが出来ます。自前で構築するというのはこういったステップを踏む必要があります。

自分達の手で豪華客船を作りたいのであれば、この「丸木舟」を作るステップも自分達の手で行う必要があります。そうでなければ、「ものづくり」の技術は身につきません。自分達が作ったと言うためであれば、このステップを欠くことはできません。

ただし、世の中のたいていのシステム(巨大である必要はない)は、自分で作る必要性はあまりありません。そこは

餅は餅屋

ということにした方が良いことが多いです。

自分達が作ることが目的でなければ買うだけの金を集めて来れば良いわけです。しかしそれであっても未経験で運用が出来たりはしないわけなので、最低でも「練習船」を入手して練習する必要があります。もちろん運用を外部委託してしまうという手はありますが、ある程度は自分達も経験しておかないと、問題が発生した時の対処が困難になるかも知れません。

いきなり豪華客船を買う金が準備できれば客船を買ってしまえばいいじゃないかと思いがちです。その方が「練習船」を買う金を使わずに済みますから効率良いですよね。でももし「練習船」を運用する程度の能力すら自分達にない(身につかない)とわかれば、最初から豪華客船を買ってしまっていれば、大きなムダになります。ですから、まずは「練習船」でその辺の見通しを立ててみる必要があります。仮にそこで見通した立たなくて諦めても、ムダになるのは練習船の分だけです。後で述べますが、「撤退」をする時でもサンクコストが小さい方が意思決定はしやすいものです。

ですから、なるべく損失の少ないところで先行きの見通した立てられる程度の「お試し」をやってみる必要があります。どんなに国家的な規模のプロジェクトであっても、いきなり大きな金を注ぎ込んで作るのは、あまり得策ではありません。どんな形であれ「パイロットプロジェクト」をしなければなりません。それは、巨大システムを構築した経験のある開発者に依頼を出す場合でもです。後でも述べますが、巨大システムの成功は、運とか出会いといった、一見非科学的な要素も絡みます。そういった不確定要素をなるべく排除するためにも、試作はやった方が良いと言えます。

ちなみにORCA Projectの場合、最初はごく安い費用で、デモ用アプリケーションを開発しました。「安い」と言ってもそれなりの規模ではありますが、予定したプロジェクト規模から言えば、ごく少額です。デモで使うものですから仕様もごく小さく、「内科単科で入院なし」というものでした。また、システムの全てを実装したわけでもありません。一番目にすることが多いであろう画面をいくつか実装してデモをしただけだったと思います。

試作による既成事実化

巨大システムは政治でもあるので、様々な形で政治的な圧力がかかります。

利害関係者は必ずしもIT技術に長じているわけではありませんから、「正当ではあるが技術的困難」な要求が出て来たり、「技術的には容易であるが実装すると軋轢が発生する」ような要求が出て来たりします。この辺はシステム開発に従事した経験のある人にとっては「あるある」ネタですが、システムがデカくなればなる程、理不尽の強度は高くなります。こういった要求は、システムの姿が全く見えてない時には多いのですが、姿が見えると一時的にはなくなります。まぁしばらくすると

期待したものとは違う

とか言い出す人が出て来るわけですが、何もない時よりはずっと話はしやすくなります。昔はこのような開発を「プロトタイピング」とか言ったものですが、近頃はあまり聞きませんね。まぁ昔よりもコードを作ることへのハードルが下がったせいでしょうが、巨大システムにとっては有効だと言えます。

システム開発者にとって一番辛いのは、そういった議論の果てに「やっぱりやめよう」となってしまうことですね。拗れ果てて厄介の塊になってしまっているプロジェクトでなければ、技術者誰しもシステムに愛着はありますし、営業にとっては売り上げの都合があります。技術者でなくてもシステム開発を推進して来た人達にとっては、プロジェクトの中止は「厄介ごと」が起きてない限りは避けたいところです。

とは言え、政治ですから、風向き一つで中止になることはままあります。ORCA Projectはまさにこの「政治(政権交代)」によって吹き飛びそうになりました。

これを避けるためも既成事実が存在しているのは都合が良いです。雑な言い方をすれば

やったもん勝ち

になるわけです。

「もの」が存在していれば、抽象的な存在でしかなかったプロジェクトに具体的な「形」を存在させることができます。また、そういったものが存在していれば、「出来っこない」的な声をある程度は潰すことができます。想像力豊かな人に見せれば、その「未来」を想像してもらえるかも知れません。「もの」が存在するというのは、何もなくて説明するよりもずっと効果があるものです。試作でデモをするというのは、そういった効果もあるわけです。

また 「もの」の存在は固定観念を与えるということでもあります。これは自由な発想を妨げるという弊害もありますが、あまりにフリーダムな要求を減らすという効果があります。利害関係者が多いと議論が発散しやすくなって、それゆえにプロジェクトが崩壊しかねないのですが、固定観念を与えることでこのリスクを低減させることができます。

マイルストーンの提示と実現

前節で述べたように、試作品の存在は一つのマイルストーンの提示となりえます。

この存在により発散しがちな議論はある程度の落ちつきを持つことができますが、それと共により具体的な要求が増えて来ます。やはり人間は「存在」を見てしまうと、いろいろ考えが及ぶようになるようです。

具体的な要求が出て来ると、それが実現されることを期待します。つまり「いつになったらこの仕様は採り込まれますか？」という声が上がるようになります。

こうなるとプロジェクトは新たな局面を迎えます。つまり、これから先は

開発方針に従い、採用する要求の整理と実現

に向かうわけです。

当初予定の開発方針には当然従うわけで、それに従ったプロジェクト運営がされるというのは当然のことです。何しろ現時点では試作をリリースしただけだということは忘れてはいけません。とは言え、上がって来た要求にも応えて行く必要があります。これらを無視すると、利害調整が拗れる元になりますし、それ以前に期待には応えて行くことは大事です。

ごく軽微だったり実装が容易で影響範囲も小さいものはすぐ実現してしまっても構いませんが、そうでないものに関しては「どんな仕様を」「いつ実現するか」ということを提示して行く必要があります。つまり、

すぐには出来ないけどそのうち出来るから待っててね

ということを提示する必要があるわけです。もちろん、実現できないこと、実現するべきでないことも、その理由とセットで提示して行く必要があります。

そのためには当然のこととして、そういった「要求」を収集し整理する必要があります。

これをうまく回せるようになると、より練られた仕様になることは当然として、そういった「議論」に参加できたということで、参加した人達は自動的に「システムの賛同者」になってくれます。自分の要求した仕様が含まれたシステムを嫌いになる人は、およそいませんからね。ですから、一番の課題であった利害関係の調整が、ある程度自動的に出来てしまうということになります。

また、すぐには実現できないことや実現するべきでないことを明確化することで、無用な期待を持たせることもなくなりますし、それを通じてより詳しい説明をして行くことも出来ます。つまり、説明の機会が増えるわけです。これらのことも、システムを成功に導く元になりえます。

巨大システムとなると、要求される仕様の中には利害の矛盾を孕むものもありえます。このような場合はいかに実装が容易であっても実装されるべきではありません。おそらくはここにも「政治」が絡むことが予想されますから、技術者サイドとしては「政治マター」として投げ出しておくべきです。

技術で殴る

何度も書いていますが、「巨大システム」は技術よりも政治の問題の方が大きかったりします。ですから、技術者にとってはあまり得意でない政治についてのスキルが要求されたり、それに合った立ち回りをすることになったりします。

しかし幸いなことに、そういった政治問題の一部は技術的に解決できることがあります。

システムを構築する時、何であっても大切なことは

無用な複雑さを避ける

ことです。これはコードとか技術とかに限らず、利害調整とか業務フローと言った人間の複雑さも含まれます。政治的な問題にしてしまうと拗れてしまう問題であっても、それを技術の問題にしてしまえば単に技術的難しさになるだけです。そうすれば、複雑さを下げることになります。

また、技術者にとって政治は苦手なことですが、技術は自分の土俵です。自分の土俵の方が「勝ち」やすいことは明白ですね。また、多くの場合複雑さを下げることに貢献します。

「政治問題」は「技術問題」に転換できるものがある

一言で「政治問題」と言っても、その中にはいろいろな種類のものがあります。たとえば、

実際に利害が発生する問題
金額(投資金額)についての問題
手順手続きの都合で人が動いたり利害が発生してしまう問題

等です。

これらのうち、実際に利害が発生するものについては、政治問題であることは不可避です。と言うか、これを何とかするのが政治なのであって、そこに技術者が介入してはいけません。いくら「こちらの方が良い」と思っても勝手にそれを実現することは出来ませんし、調整役以外にそのことを伝えてもいけません。積極的に政治の問題にしてもらって、政治で解決する方が間違いがなく安全です。それが政治の仕事です。

金額の問題は、あるいは技術で解決できるかも知れません。A案とB案があって、A案は良いけど高い、B案は逆みたいな、そんな問題です。お金の動き方が変われば、政治問題ですからね。そして、この時点での本音としては、おそらくはA案にしたいけど金がないと。

これはある意味簡単で、A案を安くするかB案を良くするかです。どっちを取るかはケースバイケースでしょうが、どっちにしても技術的な介入の余地があります。A案で行きたければコストダウンを考えれば良いし、B案で行きたければ仕様を良くすれば良い。これは技術の問題です。単純な値引きや機能アップで解決できそうになくても、何かツールを持って来るとか、購入するとか。あるいは中間的なC案を持って来てもいい。

問題が完全にこういった領域に来てしまえば、政治が介入する余地は減ります。ORCA Projectの時にはCOBOLのランタイムライブラリに多分な政治的問題があったのですが、「オープンソースの処理系を開発してしまう」という画期的な方法で解決をしてしまいました。それまでランタイムライブラリをどうしたら無償に近い形で提供してもらえるか、ある意味政治問題になっていたのですが、オープンソースの処理系を作ったためにその問題はなくなりました。

もっともこれは実も蓋もない解決もあって、それは

A案を採って値切る

という営業的な解決です。乱暴な解決ですが、問題の複雑さで苦しめられるよりはマシかも知れません。

複数の利害関係者が組織である場合、何かをしようとする時の手続きや手順が、それぞれの組織で異なるということはよくあります。これには様々なパターンがあるので一々挙げることは出来ませんが、そういったことが「ある」ということは説明なしでもわかると思います。そういった手続き上の問題は、組織と個人の時には「郷に入りては郷に従う」ということで解決してしまうわけですが、組織同士となると問題が厄介になります。つまり、あることを組織同士でやる時に、甲組織の手順でやるのか乙組織の手順でやるのか、そもそもどっちが甲でどっちが乙だよ... みたいな話です。これは利害の調整ですから、もっぱら政治の問題です。それぞれに言い分やポリシーがあることなので、簡単には解決がつかないこともあります。

しかし問題によっては、これも技術で解決することが可能なこともあります。

たとえば、そういった「手続き」に関する部分については「第三者に委託する」という解決があるかも知れません。つまり、甲組織の手続き手順があり乙組織の手続き手順がある場合、第三者にそれを委託してしまえば、甲組織も乙組織も手続き手順については介入しなくて済みます。ですから、「どちらで行くか」という議論はしなくて済みます。これは完全に「第三者」である必要はなく、「巨大システムのプロジェクト」の産物として、そういった機関を作ってしまっても良いわけです。

ORCA Projectの時にはネットワーク化という課題があって、当初は「既存のローカル(医師会)の構築したVPNを相互接続する」という話がありました。既に安定稼動しているところにとっては、その方が都合が良いわけです。ところが、これを実際に相互接続しようとすると「どっちの組織に合わせるか」という問題がありました。まさに政治の問題です。

ですが、これは技術的に解決を図りました。それはその当時まだあまり普及のしていなかったIPv6を使うという解決です。そうすれば、どっちがどっちという問題を避けて通ることが可能になります。ネットワークはIPv6でつなぐと決めてしまえば、後は「いかにしてIPv6網に接続するか」という技術の問題となります。政治問題を技術で殴って解決した好例だと思います。もっとも、このネットワークが使われ続けているかどうかは、私は知りません。当初は相互につないで何とかしたいという話があったということです。

余分なことをつけ加えれば、地方医師会同士は必ずしも仲が良いわけではありませんし、地方医師会と日本医師会は独立の組織ですし、必ずしも仲が良いわけではありません。そして、勢力図は常に変化しています(選挙中の噂話を聞くと、まるで戦国シミュレーションゲームです)。そこで「VPNの相互接続」に固執していたら、とても厄介な政治問題になっていただろうと思います。

技術の選択

言うまでもないことですが、システムを構成するアプリケーションは当然のことながら既存の技術スタックの上に構築されます。

これはアプリケーションフレームワークやデータベースシステムのような目に見える(？)スタックもあれば、UMLとかアジャイル開発と言った文化的なスタックもあります。そういった土台抜きにシステムは構成できません。

「巨大システム」を構築する時にこれらをどう選択しどう選択しないかというのは、システムを成功させる上で無視することはできません。

先端技術の将来予測の難しさ

技術者の性として、技術スタックは先端のもの流行りのものを使いたいものです。

それはその方が面白いとか転職の時良いとかという「自分の都合」だけではなく、最新の情報にアクセスしやすかったり、他の先端技術との相性が良かったりという「開発の都合」からも言えることです。

他方、マネージャクラスとなると、技術スタックはあまり先端のものではなくて、多少古くても評価の定まったものを使いたいと考えます。

それはその方が安定しているし、技術的にも確立しているし、世間にもナレッジが蓄積しているという「開発の都合」もありますし、ある程度流行った実績のあるものであれば技術者を集めやすいとか、技術者の単価もこなれて来ているということもあります。

どっちがどうと言えるわけでもなく、またこれらは完全に背反するということでもありません。また、「この先どれくらい使えるか」ということについても、新しいからどう古いからどうということもありません。この世界の技術は日進月歩と言われますが、定番化してしまったものはいつまでも使われる傾向にあります。

システム構築の時に期待することは、システムの寿命よりも技術スタックの寿命の方が長いことです。これが逆だと、システム改修を途中で行うことになってしまいます。「しまいます」ならまだマシな方で、往々にして「しなきゃいけないけどそのまま」なシステムは少なくありません。いわゆるレガシー化という奴ですね。

システムが陳腐化しなくてもどんどん技術スタックが改訂されてしまって、新規バージョンに追従するのが大変になってしまったりすることはしばしばあります。開発期間が長いと(巨大システムは往々にしてそうなる)、開発の途中で何度もバージョンアップされたり、定番だと思っていた機能が廃止されたりといったことが起こることもあります。開発に1年かかれば、Rubyならメジャーバージョンアップは1回あり、Node.jsなら2回ある。Ubuntuは大小合わせると2回ある。どのバージョンアップであっても、内容の違いがわかるためにはそれなりの工数が必要です。

これらを科学的に予測する手法は、今のところないものだと思っておいて良いです。「なんとなくその傾向がある」みたいなものはいくつか言われていますが、それらの多くは単なる経験則に過ぎませんし、番狂わせみたいなこともしばしばあります。

ごく一般論として、「バージョン番号の進みが激しいものは注意せよ」みたいなのがありますが、最近の基幹部分を担う言語処理系やフレームワークは「いつバージョン番号を進めるか」がルール化されていて、どんなに中身が変化してもある時期が来れば番号が進んでしまうということになっているので、バージョン番号の変化は目安になってくれません。そして、バージョン番号が大きく違っても中身が大きく変わってないということがあったり、その逆があったりします。また、大きく違ったにしても、自分達にとって影響が大きいかと言えば、それは必ずしもそうでもありません。

科学的な手法がないとなると、要するに「勘」でやるしかないわけですが、あくまでも「勘」でしかありません。そういったわけで、技術スタック特に先端技術に関しては、「将来どうなるか」を予測することは困難です。それに対する対処法も様々になります。

ただ言えることは、徒に先端技術を追えば技術にふり回されることになりかねないし、それはプロジェクトにとっては余分なコストになってしまうということ。枯れた技術を使えば安定している代わりにレガシー化の危機もついて回るということ。それぞれにあるリスクを覚悟して行かないといけないし、それは誰かが何とかしてくれるわけでもないということです。

先端技術に裏切られない工夫

先端技術は往々にして裏切って来ます。

その要因も結果も様々です。

思いがけず流行ってしまって、開発者が要求に応え切れなくなった
開発者自身に何か理由があって、開発をやめた(or スローダウンした)
他の似たプロジェクトにマージされた
世間が飽きて見向きしなくなった
世間での必要性が低下した

などなど、手法でもフレームワークでも、いろんな理由で消えてしまう技術があります。技術的新陳代謝は社会にとっては好都合なのですが、システムを開発する側にとっては害しかありません。いや、これが「死ぬ」のではなくて「改良された結果自分が古くなっている」というのであれば、対処の仕方もあるし前向きな変化として甘受するべきと言うのも一理あるのですが、死なれてしまってはどうしようもありません。

比較的小さいプロジェクトであれば、何なら最初からやり直しということも不可能ではないかも知れません。そうであれば、やりたいようにやればいいだけで、どうこう言う必要はないでしょう。

巨大システムで国家的プロジェクトとなると、さすがにそんなわけには行きません。やり直そうにも「政治」が邪魔をして来ます。

そんなわけで、先端技術を採用した場合、裏切られない方法、裏切りに対処する有効な方法はないものだと思っています。つまり、

諦める

しかない。大きなシステムほど、先端技術からは距離を置くしかありません。

ただし、一つだけ逃げる方法があります。それは、採用した技術の未来を他人の手に委ねないということです。つまり、先端技術を採用したら、どこかでforkしてしまって「自分達のもの」にしてしまうということです。手法であれば特に大きな問題なく出来るでしょうし、フレームワークはオープンソースなものであれば原理的に可能です。

もちろんこうしてしまえば、全ての責任が自分達にかかってしまいます。また、油断しているとガラパゴス化してしまいます。また、それを避けようとすれば多大なる工数がかかります。なので、ここにそれだけのコストをかけてもペイするような技術でない限りは、こういった手法は取るべきではないでしょう。しかし、それに見合うだけのメリットが得られるのであれば、こういった手法もあるのだということは覚えておいて良いですし、それがオープンソースのパワーだとも言えます。

ORCA Projectの場合は、GUIツールキットや後にCOBOLの処理系の周辺でこの手法を使っています。COBOLの処理系については元々このプロジェクトで作ったものがGnu COBOLとして公開されていたのですが、諸事情で公開されているものとここで使っているものとは別物になってしまいました。これらのことも結果的にそうなってしまったことですし、案外工数のかかることでもなかった(自分達にとって必要な部分だけメンテを続ければ良い)ので、特に大きな問題にはならずに済みました。また、プロジェクトの規模が大きいですから、こういった方面にマンパワーを割くこともできたわけです。

枯れた技術をレガシー技術にしない工夫

先端技術を採用しづらいということになると、枯れた技術を使うことになります。そうなると、今度の敵はレガシー化です。

IT技術は日進月歩なのですが、ある程度使われた技術では、意外なほどのレガシー化して消えてなくなる技術はないものです。むしろ、今現在新しそうな技術だと思われているものが、結構始まりは古かったりします。たとえば、

名前	初版
Linux	1991年
Python	1991年
Ruby	1995年
Java	1995年
Node.js	2009年
React	2013年
jQuery	2006年
UNIX	1969年
COBOL	1959年

適当にいろいろ選んでみたのですが、新しそうに見えるものであっても、案外に古くに初版が出ていることがわかると思います。表の中のUNIXやCOBOLはネタに過ぎませんけど、これらであっても今も使われていることを思えば、定番化してしまえば案外に廃れないものです。jQueryなんて死んだ死んだと言われながらも、今でも新版が出て来ますし、COBOLに至っては百万回死んだはずなんですがまだ現役です。

そうしてみると、ここでの答えは明かだと思います。要するに

定番化したものを使え

ということに尽きると言えます。そして、一度定番化してしまったものは、古いと陰口叩かれようと、それ自体がレガシー化してしまうということもあまりありません。

そうなると、レガシー化と戦うべきはベースとなる技術と言うよりは、今作っているシステムそのものです。

システムのレガシー化を避ける方法については、多くの書籍で言及されていることですから、ここで敢えて挙げるようなことをしません。システムというスコープであれば、そちらの方を見てもらえば良いでしょう。

「巨大システム」というスコープで言うならば、そういったシステムのレガシー化」を避けるための方策を用意しておく必要があるということです。具体的には、

予算の確保
人材の確保
責任者の確保

ということです。これらを欠いてしまえば、システムは急速にレガシー化して行きます。「巨大システム」を立案する場合、そのシステムのライフタイムの間は、これらを確保することを考えておかないといけないということです。

システムを「使ってもらう」という観点

最近問題となる「巨大システム」は、直接的であれ間接的であれオープンであるものが多くあります。

世間のITスキルは昔よりはかなり進みましたし、利用者自身もより直接的に操作したい、あるいは運用する側も要員をなるべく少なくしたい... まぁ理由は様々ですが、オープンに使われることが増えました。もちろん全てが完全にオープンになっているわけではありませんが、利用者が直接操作できる部分は増えて来ています。

そうなると、従来の「巨大システム」とはまた違ったことを考える必要があります。

多くの場合、オープンなシステムは使うことが強制されていないことが多いので、まずは「使いたい」という気持ちを起こさせる必要があります。その気持ちを起こさせないシステムは結局利用者が伸びずに使われないということになります。これは単にシステムが使われないというだけではなく、そのシステムが担うサービスに対するアクセスを阻害することになりかねないので、「使いたい」という気持ちを起こさせるシステムが必要になります。

逆に、あまり使いたいと思わないようなシステムに対して使用を強制すると、「反対勢力」が勃興します。今のマイナンバーカードのシステムは、まさにこの問題を起こしています。

「使用強制」は政治的な問題であることが多く、それゆえ実際はどうであるかとは全く関係なく、「高圧的」と感じられるものです。これをどう進めて行くかというのは、全く政治的な話な話なので技術サイドで出来ることはありません。

ただ、いずれの場合であっても、使いたいという気持ちを起こさせるシステムにする、そういった設計にするということは大切なことです。そして、この方向でのシステムの仕様は、SI的なインハウスシステムの設計よりも、ウェブサービス的なシステム設計のセンスが求められることが多いものです。オープンに使われるシステムというのは、本来そういった性質を持ったものです。

極めて現実的な話をすれば、日本においてはいわゆる「ITベンダー」が人気ウェブサービスを稼動させている例はありません。日本でそこそこ使われているシステムを思い浮かべて、それを誰が作り誰が運用しているか調べてみれば、これは自明です。「大手ITベンダー」はまさに大手で、万に及ぶ開発者を抱えているわけですから、そういったことに(片手間的であっても)手を出そうという動きが皆無であったとは考えにくいわけで、それを考えれば要するに

力量がない

と思って間違いはありません。

オープンな(ウェブ)システムを作るには、いわゆるビジネスロジックの専門家の他に、UI/UXの設計者は必須であり、また使ってもらうためのデザインにするための工夫、また多くの人達にリーチさせるためのプロモーションが必要です。これらを揃えてやっとスタートラインです。

他方、いわゆる「巨大システム」を構築する時、この辺に力を入れたという話を聞きません。人手で大量にデータを入力する必要があるシステムであれば、「いかにして入力間違いを減らすか」というUI/UX上での工夫は必須だと思われますが、果してそこに十分手当をされているシステムがどれくらいあるでしょうか？

そう考えると、いかにインハウスシステムの構築経験が豊富なベンダーと言えども、オープンなシステムの構築経験のあるベンダーと組んでシステムを構築する必要があると言えます。

運用体制の大切さ

システム全般にそうですが、システムは広義のシステムであれ狭義のシステムであれ、作ってしまったらおしまいというようなものではありません。アプリケーションとして、あるいはシステムとして完成した後には、

運用
メンテナンス
普及
サポート
改良

といったような作業が続きます。これらがないシステムは、遠からず滅びます。そして、必要となるコストは、ライフタイムの長さにもよりますが、開発にかかったコストよりも大きくなるという覚悟が必要です。作るのに1億かかったシステムは運用等にも1億はかかる。それくらいに思っておくくらいがちょうど良いです。

これらは比較的小規模なシステムでも当然と言えるのですが、「巨大システム」となると小規模なシステムとはまた違った方向で大変になります。

狭義のシステムの完成を広義のシステムの完成に持って行くためには、いろいろな作業が必要になります。

体制やルールの変更
人的配置の変更
対象者への教育

これらについてもう少し細かく書いておきます。

体制やルールの変更

狭義のシステムが広義のシステムとして稼動するためには、それなりの体制になる必要がありますし、ルールの変更が必要になります。

システムの導入は基本的にはソフトランディングが求められるものですが、古い体制やルールのままであればシステム導入によるメリットは限定的なものになりがちです。ですから、いつかどこかで古い体制やルールは改訂されなければなりません。それをいつにするかは政治の問題ですが、そういった改訂による軋轢を避けたいということで放置しているわけには行きません。

このことについては、システムのプロジェクトが始まった時から考えておく必要があります。そして、メリットデメリットについては出来る限り数値化しておいて、実際にメリットの方が大きいという見通しが立たないのであれば、中止という選択になる覚悟が必要となります。

メリットの方が大だという客観的なデータが揃えば、体制やルールの変更を敢行します。もちろんデメリットを受ける人達(組織)があってそれが不可避なのであれば、それに対する補償の類もプロジェクト周辺予算として考えておく必要があります。この辺は道路の建設の時の「立ち退き費用」とかと同じものと言えます。「身を切る改革」と称して理不尽を押しつけてしまえば、後々の禍根になったり抵抗勢力になります。「マイナンバー保険証」の問題は、まさにこの辺の対応に手を抜いた結果だと言わざるをえません。つまり、

体制やルールの変更は必須だが、それによってデメリットが受ける人があれば補償が必要

ということです。

体制やルールの変更は基本的にはソフトランディングが求められるものですが、それを求めるあまり旧体制を温存するのは、あまり良い方策とは言えません。古い体制を維持することは、それ自体手間がかかることですし、新体制の枷になりがちです。

システム屋であれば後方互換性の維持はメリットが大であると共にデメリットもあることはわかると思います。そして、

後方互換性はいつまでも維持できない

ということもわかると思います。このことは広義のシステムであっても同じです。影響を受ける人が多いシステムほど後方互換性は大事なんですが、その維持には限界があって、いつか後方互換性の維持はやめなければならない、つまり新体制への移行をしなければなりません。その時のショックは小さくありません。ISDNやADSL、FOMAの廃止のことを思えば想像つくと思います。

ですから、体制やルールの変更が必要なものについては、補償とロードマップの提示が必須であり、仮にそれをやっても容易ではないという覚悟が必要です。そして、これは容易ではないのに不可避なことです。

不可避であるがゆえに、ここで必要となる作業や工数は全てプロジェクト関連費用として積算する必要があります。また、日程の上でも考慮する必要があります。

要員の訓練

狭義のシステムを作っても、広義のシステムとして稼動しなければ動いてないのと同じです。開発者は狭義のシステムが完成してしまえば仕事が終わりだと思いがちですが、広義のシステムとして稼動させるには、ここからが大変になります。

これはクローズドなシステムであれば、単なる要員の訓練ということになりますが、オープンなシステムの場合はエンドユーザに慣れてもらうというのも「訓練」のうちです。そして、その大前提としてエンドユーザに使ってもらえるようにするということも必要になります。つまり、システムについてのPRや宣伝が必要だということです。オープンなシステムに必要なことについては既に述べたとおりです。

あまり規模の大きくないクローズドなシステムの場合は、要員の訓練もそれ程大変ではありません。しかし、国家プロジェクト規模になると、専用要員であっても様々なプロフィールの人がいます。もちろんそれ用の要員として確保された人達ですから、IT技術の最低線はクリアしているでしょう。そういった意味でスキルの程度はあまり問題ではありません。とは言え、何か問題が発生した時の対処とか反応は、各人の個性によるところが大きいですから、それがシステムの運用に影響を与えないようにする必要があります。

いくらそれ用の要員だとしても、大量のデータを精度を保ちつつ正確に入力することを要求することはできません。普通の人であっても、1000件くらいが限界であり、オペレータやデータの特性によっては10件でも厳しいかも知れません。

いくらルールがあろうと、「おかしなデータ」に対する対し方には個性が出ます。「判別不可能な文字は確認すること」というルールがあっても、無理して読んでしまう人もいれば、すぐに誰かに聞く人もいます。そして、そこに「思い込み」が入る人もいればそうでない人もいます。これは人間が介在する限り不可避です。

巨大なシステムになると、オペレータ要員も大勢いて、それぞれが個性特性を持っているわけです。そして、それがシステムの運用に影響を与える可能性を排除するのは容易ではありません。

システムを正しく運用するためには、こういった要員の特性を考慮しつつ、足並みを揃えるための工夫をしなければなりません。理想的には、要員の個性に依存しないシステムにすることですが、それは現実的ではないと考えなければなりません。であれば、個性云々に影響を受けても大丈夫なような体制が必要になります。具体的には、間違いやすいデータやセンシティブな情報を入力する時には複数人で協力するような体制にするとかというようなことです。また、間違いが発覚した時には、いつでも正しいデータに直すことが可能であるような運用にすることも考える必要があります。

システム周辺のサポート体制

オープンなシステムでは当然のこととして、クローズドなシステムであっても、利用者のサポートは考えなければなりません。いくらしっかりしたマニュアルを作ったところでそれが全部読まれるわけではありませんし、それが期待通りに伝わるわけでもありません。いくらタテマエとして「それはマニュアルに書いてあります」ということであっても、必要とあらばサポートしないわけには行きません。

この辺はある程度以上の規模のシステムでは常識と思われているので、あまり言うべきことはないかも知れません。

オープンなシステムになると、公設サポート以外のサポートも重要になって来るかも知れません。つまり、「在野の詳しい人(野良サポート)」です。規模と内容によっては、この存在を軽視できません。また、この人達をうまくコントロールすることが、普及や発展の鍵になるとさえ言えます。

何でもそうですが、現代ではいわゆる「クチコミ」が大事になりました。身近な人に聞く身近な人に教えられるということが公式な情報よりも重視されることが少なくありません。と同時に「インフルエンサー」の存在も軽視できません。いわゆる専門家が語るよりも、「みのもんたがテレビで言ってた」ことの方が信じられてしまうというのは、インフルエンサーのネガティブな側面ではありますが、軽視してはならないことです。

と同時に、これらの「野良情報」はデマの温床ともなりがちです。悪意の有無とは関係なく、間違った情報が流布してしまうというのも、クチコミやインフルエンサーの存在に依るところが大です。つまり、こういったものの存在は諸刃の剣であり、コントロールが必要なものだということです。

オープンなサポートを円滑に進める手段の一つとして、コミュニティを作るということがあります。相互扶助の組織を作って、サポートが必要そうなことがあれば、まずはそこで相談というような形式です。

コミュニティそのものは、Twitterでもメーリングリストでも何でも構いません。利用者のプロフィールに合ったものがあればそれで良いわけです。管理さえできれば、チャネルは多い方が都合良いです。

コミュニティは情報のチャネルとして活用することもできます。つまり、公式のサポート情報はそこに流すというわけです。そうすれば、デマの温床となりがちのクチコミやインフルエンサーも、ある程度のコントロールが出来るようになります。

そして、オープンなシステムのコミュニティはオープンに開設されるべきです。つまり、システムの利用者であれば誰でも勝手に作ることができる必要があります。コミュニティは往々にして人間関係のうず巻く世界になりがちなので、人間関係の良し悪しがシステムの良し悪しと同じとなってしまいかねません。システムの胴元にとって必要なのは、システムの普及と正しい理解の促進です。そのための組織の運営のせいでシステムが悪く言われてしまっては意味がありません。

とは言え、人間関係の好悪なんてものはどこにでもあるものですから、組織の集合離散は自由にしておいた方が良いです。「嫌なら分かれる」「それでも公式からサポートしてもらえる」という環境を作ることは、コミュニティ活動を円滑に行うために必要なことです。なので、どのコミュニティであれ、一定の要件(これも文書化されるべきです)を満たせば、同じレベルの公式サポートが得られる体制が必要です。何であっても、

利用者を差別しない

ことが大切です。どうしても差別が必要な場合は、それなりの対応を用意しておかなければなりません。それでもあまりしない方が結果的には低コストとなるでしょう。

システムの利用に特別なハードウェアや設備等が必要な場合は、それらに対する手当が必要です。

たとえば「ナショナルクレジットカード」というものを作って、公的な支払いの他公的情報との紐付けが必要な支払い(たとえば医療費とか)に使うというシステムを始めるとします。そうすると、保険診療を行う全ての医療機関が、このカードに対応する必要が発生します。

そうすると、運用開始までに、

カードリーダの準備
医療事務システムとカードリーダとの連携の検討
オーソリーのための回線

が全ての医療機関で必要になります。それに付随して

カードリーダの入手
医療事務システムとの接続が必要ならそのハードウェア
オーソリーのための回線工事
必要なら窓口の追加(往々にしてスループットは落ちます)
カード紛失の時の対応要員
必要ならこれらのための家具や什器

などなどが必要となります。これらが十分手当できないとスムーズな運用ができません。

これらのうち、人の手当に関するものは、あるいは「自己責任でよろしく」と逃げることも出来るかも知れません。しかし、ハードウェアや設備については入手や工事手配をスムーズに出来る体制を予め用意しておく必要があります。これらもシステムを円滑にスタートさせるのに必要なサポートです。極端な話、「Amazonポチ」で全部揃う、何なら補助金申請もセットみたいな体制が欲しいところです。

入れる設備が特殊であれば、それ用の業者を用意しなければならないかも知れません。これらの育成もシステムの稼動には必要なものとなります。つまり、「業者」は食えないと困りますし、低スキルでも困ります。

ORCA Projectの場合、積極的に納入業者の育成等を行いました。また、費用のモデルケース等を提示して、「オープンソースだから無料だろ」という声に対抗しました。そして、多くのインフルエンサーによって「それくらい当然かかるよ」「自分でやるのも良いけど餅は餅屋だよ」という空気を醸成することで、ある程度の品質を維持しつつ普及させることができました。「タダの医療事務システムを作ったから勝手に使って」では、このような成功はなかったと思います。と同時に、自助努力で解決できる人に対しては、そのための情報を公開して行きました。時々MLが炎上したり妙な主張をする人が出たりもしましたが、あの規模のシステムとしては上々だったと言えます。

取り残された人を不満分子にしない

巨大システムの場合、常に「取り残し」の問題があります。

必要とする人全てにユーティリティを届けたいのは山々ですが、使えるリソースには限りがありますし、利害が背反して相容れないこともあります。システムをどれだけ良くしても、どうしても取り残しは発生してしまいますし、これは不可避です。

ここで政治では「誰一人取り残さない」のような綺麗事を言いがちですが、それは不可能だという前提に立った方が正直ですし、下手な努力をしてシステムを歪めたり余分な工数をかけるよりも建設的です。むしろ、取り残しは不可避であるという前提で、その対策を考える方が合理的です。

大事なことは、

取り残された人に理不尽を与えない
取り残された人に損をさせない
取り残された人を忘れない

ことで、取り残された人々を不満分子として「敵」にしてしまわないことです。理想的には、システムから取り残された人々であっても、システムが運用されることによるメリットを与えられるようにすることです。

これについての処方箋はケースバイケースですから「詳しくはコンサル契約」ということになるので割愛します。その代わりORCA Projectでの具体例を一つ挙げておきます。

ORCA Projectの大きなタスクの一つとして、「無料の医療事務システム」の構築がありました。と言うか、プロジェクトの名前を知っている人の多くは、むしろこの無料の医療事務システムのプロジェクトだと思っているのではないでしょうか。まぁその辺の認識はさておき、そういったものを作っていました。

既にチラチラ述べているように、ソフトウェアが無料だからと言って無料でシステムが運用できるわけではありません。とは言え、既存のシステムよりははるかに廉価で高機能のシステムを手にすることができます。このことは、直接そのシステムを使った人にとってのメリットだけではなく、既存システムを使い続ける人達にとっても「医療事務システムの相場が下がる」「データ交換がオープンになる」という形でのメリットがありました。

様々な理由で、ORCA Projectの成果物が直接使えない医療機関がありました。それらはある意味「取り残し」です。でもそういった医療機関にとっても、全体の相場が安くなったことや、データ形式がオープンになったことによるメリットが享受できました。

私は全てのフェーズを見ていたわけではありませんが、当初は大量にいた「不満分子」もいつの間にか見ることが激減したので、それぞれの形に合っての解決がされたものだろうと思います。もちろん「使わない」という選択をした人も大勢いると思いますが、その人達にも間接的には役に立っているでしょう。

運も実力のうち

ここまでいろいろ書いておいて、最後に本当に実も蓋もないことを言います。

「巨大システム」はある意味人知を超えたシステムです。システムがある程度の複雑さを超えると、いわゆる「複雑系」となり非線形なふるまいを示すことは工学科学の世界ではよく知られたことです。単純な要素の組み合わせがある程度のレベルを超えると、予測不可能な動きをしてしまう。そういったchaosがこの世界にもあります。要するに

なわけです。

もちろんそうならないような努力をしてシステム構築するわけですが、巨大システムではシステム内部の複雑さだけではなくて、社会の複雑さや時代の変化の影響も受けますから、システム内部の複雑さを抑え込んだところで、複雑さの限界を超えなくなるわけではありません。また仮にそれに成功してしまっても、それは社会の変化との乖離があるということでもありますから、結果的に「動かないコンピュータ」になってしまう危険性があります。

そういったわけで、巨大システム構築の正否はプロジェクト参加者の努力を超えたところにあります。つまり、簡単に言えば、

いくら頑張っても失敗する時は失敗する

ということです。つまり、正否には「運」の要素があるということです。

とは言え、巨大システムはだいたい大規模システムであり、注ぎ込まれるリソースは小さくはありません。また、正否の影響範囲も小さくありません。ですから、「運がなかったです。ごめんなさい」では済まされません。でも、「済まされない」からと言って確実に避ける方法もありません。

ではどうするかという話になってこれもケースバイケースなのですが、そもそも論としてそのような「巨大システム」が果して必要であるかどうかということは、プロジェクト立案時によく検討する必要がありますし、試作段階でもよく検討する必要があります。ですから、巨大システムの構築は極力避けるというのは、巨大システム構築で失敗しないための第一歩だと考えるべきです。

それでも巨大システムが必要だということになったなら、システム構築の時に

plan B

を考えておく必要があります。つまり、失敗したらどうするかということを、システム構築の前提としておくということです。

日本人はこのplan Bを考えることが非常に苦手で、かつ妙な言霊信仰を持っていて、plan Bについて考えようとすると、「失敗させる気か」と言い出す人達が必ず出て来ます。あげくに、失敗が明らかになっても当初計画に固執してしまい、「動かないコンピュータ」になってしまった後でも「成功裏に完了」みたいなレポートを出してしまいがちです。

そこで敢えて言いますが、この章のタイトルのように「運も実力のうち」です。そして、いくら頑張っても失敗する時には失敗します。そればかりか、失敗するべきものは失敗した方が良いのです。目先のプロジェクトに固執して無理やり成功を強弁しても、「偉大な金字塔」となるだけです。ちなみに「金字塔」とは本来ピラミッドという意味で、ピラミッドは「お墓」ですからね。

なので、システムが「巨大」と言うべき規模になってしまったなら、plan Bのことは絶対に考えておかねばなりません。

plan Bそのものは、必ずしもyet another 巨大システムである必要はありません。巨大システムが失敗する原因は時として些細なものであることもあります。ですから、「つまづきの石」になりそうな部分を巧みに回避するための小さな逃げ道を随所に用意しておくことが効果的なこともあります。

もちろんこれが常に有効である保証はありません。そういった保証がないのが巨大システムです。過信はできません。とは言え、利害調整の時あるいは意思決定のタイミングで「んーー」と思うようなことがあれば、そこは往々にして「つまづきの石」である可能性は大ですから、そこに「こんなこともあろうかと」を用意しておくことは、ある程度の予防効果はありますし対策になるかも知れません。それでなくても、自分のポジションを守る効果くらいはあるでしょう。

何にせよ、「運」はコントロールできません。でも運の影響を低減させることは、あるいはコントロール可能かも知れません。そして、運がない時にはいくら頑張っても失敗します。失敗したらどうするかについては、常に考えておく必要があります。断じて言っておきますが、

plan Bについて考えることは失敗の原因にはならない

のです。そして、plan Bを採ることは必ずしも撤退ではありません。何ならplan Bの方が良い結果になるかも知れません。

また、「ダメだったらplan B」というのは、肩の力を抜く効果もあります。その方がplan Aを成功に導けるかも知れません。

ORCA Projectの場合、大きなplan Bはありませんでした。ただ、私の担当したパートについては、かなりのplan Bを用意してありました。それは、結局のところ「失敗してもリカバリ出来るようにしたい」という考えからです。たとえば、試作で作ったデモシステムは、データベースにはOracleを使っていましたし、COBOLの処理系はプロプラのものでした。もちろんその裏でミドルウェアは作っていましたしそれが前提でのシステム開発だったのですが、デモシステム公開に間に合わせられるかどうか自信がなかったのでそうしてもらいました。心配通りミドルウェアは片鱗も間に合いませんでしたが、無事デモは成功しました。そのデモの成功が以後の転みとなったことは言うまでもありません。巨大システムは技術よりも政治という面があって、政治的な問題が解決してしまえば後はどうとでもなるということもあったと言えます。

とは言え、まがりなりにも成功したのは、「運が良かった」と思います。

おわりに

いろいろ書きましたが、多分に偏った視点であることは否定しません。また、何しろ20年以上前のことを元にしていますから正確に書けたわけではありませんし、仮にそれが出来たとしても現代にそのまま通用するわけでもないでしょうし、特定のケースに対して有効であるという保証はありません。

とは言え、ここで書いたことは「巨大システム」にとっては基本的なことでありあたり前のことです。しかし経験がないと案外に気がつかなかったり、気がついていても軽視していたりすることが多々あります。現実の失敗例を見ても、ここで挙げたようなことが欠如していたなと思うことが結構あります。

この拙文が何かの役に立てば良いなと思います。説明が足りない部分は意図的なものでもあるので、コンサル契約よろしくお願いします。

こういったことを考えると、ORCA Projectがまがりなりにも成功したのは、当時の日本医師会執行部の人達が、とても上手に「政治」を行ってくれたからだと思います。我々技術陣の誰かが偉かったわけでも、何人かいたPMが偉かったわけでもなく、政治的決断を逃げずに行った医師会執行部が一番偉かったのだと。

PS. ORCA Projectにはなぜ「電子カルテ」が存在していないか

書くのを忘れていて重要なことなので、追記しておきます。このエントリはORCA Projectの昔話のためのエントリではないので、補遺という形で追記しておきます。

ORCA Projectには「公式電子カルテ」が存在していません。それゆえ、デジタル庁主導で「厚労省電子カルテ」なるものが作られそうになっています。

医療DX推進本部（第２回）

このことについて非常に忸怩たる思いがあるわけですが、ある意味これもフラグだなと思っています。

元々、「公式電子カルテ」を作らなかった理由はいくつかあります。

「医科」というカテゴリでまとめるのは非常に困難
UI/UXについての要求が多様になる
当時はそこまでの需要がなかったし、医師が心から成功したと思える事例は少なかった
満足行くものを作るには技術的難度が高過ぎる
そんなわけで、どう考えても工数が現実的でなくなる

というような理由です。要するに、本文で書いた

無用な複雑さを持ち込む

ことになってしまうことになるためです。

それゆえ、無理なことは無理と諦めて、必要でありかつ存在すると効果が大であった医療事務システムと連携するためのAPIだけを規定し、電子カルテは好きなものを持って来れるように多様性に配慮したわけです。また、保険請求主体の高々病歴管理レベルのことであれば、医療事務システムで十分対応可能です。

何度も書いていますが、このような多様性への配慮は巨大システムにとってはいろいろな意味で必然です。これは本文を読み返してもらえば良いと思います。

また、今の目線でこれらの問題を見れば、「現代の技術なら」と思うことは少なくないと思います。UI/UXの問題等も人工知能を使えばどうだろうかという話もあるでしょう。当時でも音声入力を応用するような議論は存在していました。

今して思えば、当時ここに手をつけなかったことで、

未来は未来に託す

ことが出来ただろうと思います。社会システムとなってしまう巨大システムは、何も今すぐ「完成」する必要はなく、時代に合わせて利便性を提供できていれば良いわけです。この世界、技術は日進月歩ですしAIの世界に至っては朝の最新情報が夕方には旧聞になってしまうくらいの勢いがあります。そういった「余地」を残しておくことも、このようなシステムを作る時に必要だろうと言えます。