【 事例をもとにした不具合考察 #２】京都市が基幹系刷新で2度目の失敗
会社変われど、毎年のように大なり小なり、こういうトラブルの解決に呼び出されるので、なんとなく他人事のようには感じません。いや、このトラブルには参加してませんけども。
「人」に責任を求めると、「あっちが悪い」「こっちの方が悪い」みたいな話が聞こえてくるのですが、仮にそれがハッキリしたからと言って、何か１つでも問題そのものを解決できるわけでもありませんので、いい加減、すべてが終わるまでそういう話はしないでほしいのですが…まぁ、あっちもこっちも他責ばかりです。
そんなくだらない責任の擦り付け合いに興じてる暇があるなら、外部から解決する人間を巻き込まないでほしい…と言うのは、わがままな話なのでしょうか。
私は、こうした問題が起きるのは大きく４つの理由があるのだと思います。
①「情報」をまとめ、整理するチームが存在しない
発注者と受注者と言う関係は、プロジェクト発足当初から、やや距離があるんですよね。
発注者は「金と既存リソースを渡せばあとは受注者の方で進めるべきもの」と考えています。最初から「何かわからないことがあれば聞いてくれ」と言う受け身な姿勢で、自分たちが成功させるという強い意志が見受けられません。
受注者は受注者で、エンジニアあがりのリーダーやマネージャーなものだから、どうしてもモノづくり思考のため、「発注者が仕様を出さない」と言って、発注者側の事情や背景を理解する努力に欠ける進め方をしがちです。そのうえ、プロジェクトメンバーのすべてがプロフェッショナルと言うわけでもありませんから、「技術（technology）」知識は多少持っていたとしても、「開発（development）」の進め方に疎い人が多く、結果的に
最終成果物（納品物）
のために必要な取り組みをはき違えて開発をしたり、そんな開発を良しとしてマネジメントしたりすることになるわけです。すると、一つひとつの工程や作業はちゃんとしているはずなのに、一つひとつの中間成果物はちゃんと作っているはずなのに、
・仕様の検討漏れ／仕様の理解誤り
・設計の検討漏れ／設計不備
と言った問題が多発します。
大手ベンダーにしても、チーム内でひな形を作るにしても、ついつい既存の、あるいは従来の様式で進めればいいやと思ってしまうリーダーやマネージャーは多いと思います。その結果、特殊な仕様などがあっても、仕様書や設計書の様式（ひな形）にそもそも書き込む欄がないために、検討することへの発想自体まで失ってしまうのです。
そう言うと「備考欄にでも書けば」と言い出す人が多いのですが、フリーフォーマットの欄に自然言語でずらずらと書かせると、書き手の表現力と読み手の読解力に差が生じた瞬間、バグの温床になることは避けられません。しっかりと考えられない人が指揮を執ると、こうした問題を避けることが難しくなってしまいます。
お互いに同じベクトルを向いて一緒に作り上げていこうと言う姿勢がそもそもないんですね。もしも、本当に大規模なプロジェクトを一緒に成功に導こうと言う姿勢があるのであれば、必要十分な「情報」の共有をするための体制をまずは構築する必要があるでしょう。
いわゆるＰＭＯ（Project Management Office）ですね。
②開発に特化したマネージャーを据えていない
・金勘定にうるさい人
・毎週、進捗を聞くだけの人（問題があっても解決はしてくれない）
・説教や他責ばかりうるさい人
こんなマネージャーや部課長なんてのはごまんといますよね。こういう人がプロジェクトマネージャーについたら、もう諦めるしかありません。エンジンやボディ、足回りが優れていても、ハンドル握った人間が赤ん坊だったら、どんな車だって事故を起こしてしまうのと同じです。
プロジェクトを成功させたい場合、みなさんが１エンジニアだったとしたら、どんなマネージャーが上に就いてくれると嬉しいですか？
・お客と交渉・折衝が巧みな人？
・問題が起きたら、先頭に立ってコントロールしてくれる人？
・決断が早く、責任感があふれる人？
たしかに必要だと思います。
ですが、それだけしか能力が無かったらどうですか？
でもたぶん、そんな個別のスキルよりも、プロジェクト全体の進め方を決める際に、過不足なく、間違っていない進め方を見極める知識と、決定し、指揮してくれるスキルって持っていてほしくないですか？
どんな要件だったらどういうところをリスクとして注意し、設計時点ではどんな情報を元にどんなアーキテクチャを使うべきなのか、明確な根拠があって、時に決断し、時にメンバーと検討しあってくれる、そんなマネージャーであってほしくないですか？
たとえば、この記事にあるプロジェクトでも、
京都市はNEC製メインフレーム上で約30年稼働する基幹系システムのバッチ処理をオープンシステムに刷新するプロジェクトにおいて、
と言っている時点で、まず
・おそらくちゃんとした設計書なんて残ってない
（いつも通りの「ソースが仕様」とか意味不明な理屈で、
ベンダーに丸投げしてくることも想定に加える必要がある）
・おそらくシステム仕様や過去経緯をすべて把握している人はいない
と言うことがすぐに頭をよぎります。実際にはどうなのかわかりません。
ですが、10年も過ぎれば、当時納品された中間成果物（仕様書や設計書）なんて残っていないことの方が多いですし（一般的な公的文書の保管年限は最長10年程度だし）、仮に残っていたとしても、30年間一切手を加えていないと言うわけでもないでしょうから、最新の設計書になっていない可能性もあります。
正しくても、間違っていても、どちらにしても一度は確認するしか、「正しい」ことも「間違っている」こともわからないのです。結局、この懸念を払しょくするには、
①現行ソースを調査し、逆算して設計書／仕様書を作成する
②現行設計書／仕様書が残っていたら、それと比較し差分を抽出する
③差分の一つひとつを、顧客に確認し、最新の設計書に反映する
↓
④そのうえで、次期システムへの要望を差分として盛り込む
と言った手順が必要になってきます。私が知る限り、この手続きを省いたプロジェクトが計画誤差を少なく完遂させた事例はあまりありません。あったとしても、数百～数千万程度の小規模プロジェクトです。
こうした手続きは、多少時間がかかりますが、
・設計書様式（フォーマット）
・対応メンバー
の２つを工夫すれば、負担になるほどの工数にはならないでしょう。特に対応メンバーについては、そのプログラム言語にある程度精通している人でないと難しいでしょう。ドキュメンテーションの能力が多少低くても、設計書様式をフリーフォーマットにせず、比較的シンプルにしておけばリスクは最小限にできるはずです。
③データの流れを整理していない
また、バッチ処理は、画面などのＵＩを必要とする機能に比べ、技術難度や実現難度が高くなる傾向があります（設計者の腕次第ですが）。
「バッチ（batch）」とは直訳すると、「ひと束」「一群」「1回分にまとめる」と言う意味で、ＩＴ用語では、
複数の作業をまとめて、順次行う
と言う意味に用いられます。ゆえにバッチ処理とは「一括処理」とも言います。そのため、バッチ処理で怖いのは
・取り扱うデータ量
・取り扱うデータの複雑さ（データ自身や、順序性、相関性なども含む）
・途中で失敗した時のデータ保全
等です。３番目の課題はちょっと毛色が違う（信頼性品質）ので置いておくとして、１・２番目の問題をきちんと理解しないまま、なんとなくで作っていくと大変な目にあいます。
特に地方自治体など公共系と、あとは…金融系のシステムの中でも、個人情報が深く絡み合うデータ群を取り扱う場合は、とんでもなく難易度が跳ね上がります。
どれもこれも規模が大きすぎるシステムだけに、そうそう数年単位で改修されるということはほぼなく、何十年ものシステムを使いまわしているケースが多いため、ＲＤＢＭＳのアーキテクチャもさほど発展していなかった時代のＤＢ設計となっていることが、根本的な理由なのかもしれません。
一昔前は、ＤＢＡ（Database Administrator）と呼ばれるスペシャリストの需要が高い時代がありました。私が知る中で最もすごかった人は、月単価500万くらいで、常に２～３プロジェクト抱えていました。2000年前後の頃ですかねー。データサイジングの設計なんかもまだまだシビアに行われていた時代です。
ですが、今ではちょっとＳＱＬ書けるようになったら、「データベース知ってます」みたいなエンジニアも多くなりました。でも、
オプティマイザについても理解が浅く
インデックスの種類もロクに知らず
正規化/非正規化のメリデメも理解せず
カーディナリティという言葉も知らず
実行計画や統計情報の読み方もわからない
…そんなのが当たり前になってしまいました（いえ、昔も当たり前でしたけどね。ただ、そういうスペシャリストを別に採用していたから大丈夫だったと言うだけで）。
今では、どんな大型のプロジェクトでもＤＢＡをしっかりと置いている現場と言うのはあまり見かけません。「ＳＱＬちょっと書けます」「テーブル定義書書けます」みたいなエンジニア達だけでシステム設計をしていくんですよね。たぶん、大手ベンダーでも、厚遇してでもＤＢＡを連れてこようなんて会社はもう残っていないんじゃないでしょうか。
そういう現場のトラブル解決に出向いたとき、おもわず「ﾏｼﾞｶｰ」ってポロっと言ってしまったことがあります。
この問題はＤＢだけに限った話ではありません。外部リソースにアクセスする以上、ファイルでもメモリでも同じです。どういう単位で整理され、どういう流れでデータを構築していくのが、プログラム処理上、最もシンプルで、最も効率的となるのか、常に意識しながら作っていく必要が、バッチ処理にはあるのです。
今では作成されることも少なくなりましたが、昔はＤＦＤ（Data Flow Diagram）と呼ばれる設計書なんかも作られていました。概念データの流れを知る上では、今でも有効に機能する設計書の１つだと私は思っています。
④指示系統の乱立
まぁ、どう考えてもヒューマンエラー（人災）なんですけどね。でも、これがよく起こるんです。私が目の前で見たことがあるのは大きく２つ
・基幹システムなどのため、利用する部署が多岐にわたり、
各関係者が好き勝手に要望を言い出して、まとめる人間がいない
・まとめる人間がまとめず、すべて丸投げしてくる
前者の場合も、後者の場合も同じことが言えますが、これについては、発注者（顧客側）にまとめられる権限と責任を与えた人が立っていただかなくてはなりません。「忙しい」等、そんな理由で協力を得られない場合、プロジェクトが頓挫する可能性は、40～50%ほど上昇すると思っていいでしょう。
受注者（開発側）のマネージャーなりリーダーなりにまとめる権限が与えられていれば、受注者でまとめればいいだけのようにも見えますが、通常、発注者（顧客）の関係各部署と直接交渉を行うと言うことはありません。普通は、発注者側にも窓口部署や担当者がいて、そこでまとめ、整理し、受注者側に伝えるはずです。ですが、これが存在していないと収拾がつかなくなるのです。
メールでやり取りするとなると、ToやCcがおかしなことになるし、メール本文が長文になると、なかなか返信が返ってこなくなる。質問票などを書くにしても、現場部署の方々はＩＴリテラシーがそれほどあるわけでもないので、直接会話しないことにはなかなか意図が伝わりにくくなります。
かと言って会議を開こうにも、現場部署が多ければ多いほど、個別に調整すれば、実施される回数は雪だるま式に多くなって、開発どころではなくなります。まとめて集めれば…となると、今度は日程の調整だけで１ヶ月間何も進まない…と言うこともあり得ます。
多くの関係者がかかわる場合は、受注条件（見積条件）に、適切な仕様や質問などに関するとりまとめ責任者を置いていただくようにした方がいいでしょう。
おまけ
基幹系システムが30年も稼働していると言うのも、大した税金の無駄遣いですね。もちろん、そうせざるを得ない事情があるのは重々承知しています。
「税金だからこそ、そう簡単に捨てられない」
「それありきで育ってきた役所員たちの仕事が無くなりかねない」
「複雑怪奇な仕様がこんがらがったスパゲティのようになっていて、
・きちんと把握している人が少ない
・開発を依頼して失敗されるくらいなら、既存を使った方がマシ」
まぁ、特に最後の理由などは、そのＩＴシステムの管理責任者なんかは常々思っていて、「自分の任期中には問題を起こしたくない」と考え、延々と古いままのシステムが残っていってしまうのでしょう。
ですが、実はソフトウェアよりも、問題はハードウェアやＯＳ、ミドルウェアにあります。
ハードにせよ、ＯＳにせよ、ミドルにせよ、それぞれ償却期間と言うものがあります。サポート期間と言えばわかりやすいでしょうか。もうすぐWindows7のサポートが切れますが、これを延長したいとMicrisoftに申し出れば、当然サポート延長費用が発生します。これと同じことが従来のシステムでも起こるのです。
たしか…昔、Windows98/MEのサポートが切れた時、郵便局のATMのOSが、98かMEだったために、何千台？何万台？の総入れ替えは難しいと言う理由で、１年だか２年だかサポート延長を申し出たって話を聞いたような気がします。それだけで何十億、何百億とMicrosoftに支払ったとかなんとか…（ただの噂かもしれませんが）。
ＩＴシステムにもライフサイクルがあり、それを過ぎるとサポート費（一般的には保守費？運用費？）が大きくなりすぎて、作り直した方が安上がりになる損益分岐点と言うものがあります。
そのことを経営戦略上の予算として考えず、何年も何十年も先延ばしにしていると、
・当時の技術要素を持っているエンジニアが今の時代にいない
・長年改修してきた細かい経緯や仕様を知る者がいない
と言った問題も大きく影響し、いざ更改・刷新しようと思った時に手痛いしっぺ返しを食らうことになるのです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。