DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

三河　淳一さん
セントラル・コンピュータ・サービス株式会社

1991年、上智大学大学院理工学研究科物理学専攻修了。同年、日本鉱業株式会社（現新日鉱ホールディングス株式会社）に入社。 半導体製造装置や石油プラントの制御系システム開発を経て、セントラル・コンピュータ・サービス株式会社にてビジネス系システム開発に従事。 システムの受託開発プロジェクトに参画する傍ら、社内開発プロセス標準の策定に取り組んだ。
ここ３年間は常に数本のプロジェクトに上級管理者として参画しているが、「プロジェクト管理の改善には終点はない」ことを日々実感している。最近取り組んでいるテーマは、コミュニケーション、開発プロセス、見積もり技法、リスク管理など。

制御システムからビジネスアプリケーションへ

三河
このプロジェクトを終えたあと、僕にとっての転機があったんです。
それまで数理制御グループで製造装置やテストプラントの制御システムをずっとやっていたんですけども、ある時、ビジネスアプリケーションをやってみないかと当時の課長に言われました。この時能登原さんも一緒でしたね。

能登原
そう、社内的にも制御系の開発が一段落した時でした。一方で、ビジネスアプリケーションの改廃や再構築のテーマが結構出てきて、今までビジネスアプリケーションを専門にやっていた部隊の手が足りなくなり、我々のところも少し手助けしなきゃいけない状況になったんです。

三河
ビジネスアプリケーションを構築するために、我々はどういう部分から役に立とうかということも議論しましたね。で、やはりデータベースだろうということになった。
能登原さんはそれ以前にも、ビジネスアプリケーション開発を１本か２本経験しているんですよね。

能登原
そうです。その前に生産管理システムをやりました。そこで１回失敗していて、「次にやる時には絶対に成功させよう！」という時だったんです。だから「ぜひ、やろうよ」と三河さんを誘ったわけ（笑）。

三河
その誘い方がまたうまいんですよね（笑）。「これ、面白いから」って。

能登原
その時に、せっかくデータベースをやるんだったら、これまでとはちょっと違う新しいやり方をやろうと思ったんです。DOA（データ中心設計）という設計技法やRAD（ラビットアプリケーションデベロップメント）という方法論を使って一度挑戦してみないか、という誘い方をしたのかな。たぶん、三河さんだったら絶対好きになるはずだと。１回入ったらはまるはずだという確信があったんですよ。

三河
能登原さんには性格を全て把握されていましたね。私は凝り性で、ものがどう動くか徹底的にわからないといやなタイプですから。

能登原
そう、原理までわかってしまわないといやで、１回やり始めたらそれにみんなが従わないといやだという性格でしょう（笑）。これをやったら絶対にそうなるだろうと確信していた。

三河
まず能登原さんが着目したDOAという手法の勉強を始め、講習会にも行きました。それまでビジネス系をやっていた人でDOAを知らない人は、それを習得するためのパラダイムシフトに相当エネルギーを費やすと思うんですけど、私はビジネス系を何もやっていないまっさらなところで、「データベースも含めてビジネス系をやるためにはDOAという仕組みがよい」という単純な理解の仕方だったので、それが当たり前のこととしてビジネス系に入っていけたんです。

そうしながら、過去に先輩方がつくったいろいろなビジネスシステムとか、あとは着手途中のシステム開発のお手伝いで入った時に、すごいショックをうけました。びっくりというか、不可解だったのが、ビジネスアプリケーションはだいたいデータベースを使うんですけども、データベースの図面がないんですよね。

能登原
ないというのはちょっと言い過ぎかな。

三河
そうですね。いわゆるテーブル定義書というのはありました。データベースでデータを集合として扱う単位がテーブルですけども、テーブル一個一個に対して、そのテーブルの名前だとか、そのテーブルの中で扱わなければいけないフィールドとか、フィールドのデータタイプやバリデーションとか。でも、そこそこの仕組みだと200テーブルくらいありますからテーブル定義書が200あるんです。データベース全体を見るためにはその１枚１枚を見ては頭に入れて、見ては頭に入れて、頭の中でテーブル全体をイメージしながら、システムがどういうデータベースを対象に動いているのかを理解することになると思うんですが、そのようなやり方が理解出来なかった。つまり「テーブル定義書１枚１枚の情報しかない状態でどうやってデータベース全体を見通すのかな？」と。

私は既にその時、ER図（エンティティ・リレーションシップ・ダイヤグラム）、データベースの全体図面を持つ意義や価値、そのつくり方（設計→構築→テスト）とか、その位置付けを勉強させてもらっていたので、それが当たり前と考えていました。実際にプロジェクトに入っていった時に、テーブル定義書だけだというのは驚きでしたね。

能登原
なるほどね。

三河
そのやり方で慣れているから妥当な設計は可能なのだろうとは思っていましたが、いろいろ聞いてみると本来データベースで実現する方が楽なはずなのに、それをプログラムで持ってしまっているルールとかあったんです。例えば存在制約をはじめとする各種制約に関して、全部プログラムで持っている。

私がDOAで学んだのは、処理に比べるとデータのほうが安定していて、ビジネスモデルが変わる中でも、そのビジネスが扱ってきたデータは引き継がれる。ただ、それを加工するやり方はビジネスによって変わってくるということでした。だからつくり直す時でも、データベースにはほとんど手を入れずにデータベースを使う側の処理を全面改定するという流れになるんですが、そうなった時にそもそもデータ自身に備わっている制約をアプリケーションで持っていると、全部消えちゃうんですよ。だから単にデータベースを入れ物として扱うのではなくて、入れるためにいろいろ守らなければいけないルールさえもデータベースに持つと、先々の再構築においても資産を再利用しやすいということをその時に学んだんです。
だから「もっとこんなにいいやり方があるのに」と思うんですけど、それをなかなか理解してくれない人が周囲にいて…。

能登原
いっぱいいましたよね（笑）。

三河
結局、人間は困らないと新しいやり方にチャレンジしないし、別のやり方がないかと探さないんじゃないかなと思うんです。

能登原
三河さんはそれとは違って、困っても困らなくてもどんどん変えていく、どんどん挑戦するタイプではあるよね。だからなおさら周囲との意識の差が大きくて大変だったんでしょう。

三河
そうですね。今もそういうテーマに関して悩んでいるんですけど…どうしたらもっとこうエレガントな世界に一緒に行ってもらえるかと。
能登原さんとやっていても、「おいおいちょっと待てよ」と、まだその先に行く必要はないと、時々、手綱を引かれたことがありますね。「今度ちょっと、これをやってみます」って言ったら、「まだいいよ」って（笑）。

能登原
定着化は必要ですからね。今試しているやり方が効果を発揮してからとか、うまくいかないときには直してもいいからとか言っていましたね（笑）。
そのときのプロジェクトはガソリンスタンドの設備関連のシステム開発で、もう会社名もジャパンエナジーに変わっていました。

三河
ええ、DOAを学んで、最初に本格的なビジネス系でやったのが、今能登原さんが言われたガソリンスタンド設備を管理するシステムですね。、導入／改修／保全計画、購買業務も含めた設備の構築と維持のためのビジネスシステムをつくった時に、DA（データアドミニストレータ）とDBA（データベースアドミニストレータ）という両方の役割でデータベースチームのチームリーダとして入っていたんですね。そこでデータベースから見たビジネスシステム全体のつくり方を勉強したし、そのチームの中で「チームを引っ張っていく」ということも勉強させてもらいました。

能登原
そのプロジェクトをやって思ったのは、プロジェクトには三河さんのように突出する人が必要だということでした。突出して高い部分があると裾野が広がるし、全体が上に行く。それがリーダーシップだと思うんですよ。そういう面では、三河さんが最先端できちんとしたことをやろうと突っ走ってくれたから、それについて来る人もたくさんいて、全体の底上げになったと思うんです。
そういうところに僕はマネジメントする側として期待していたし、三河さんはそのとおりの動きをしてくれたわけですよ。

三河
その頃、もうちょっと後かな…「やっぱりひとりでは限界だな」と思うことがあったんです。だんだん大きなシステムを担当してくると、やっぱり何人かと一緒になってやらないと出来ない。それにもともと私は、ひとりで黙々とこつこつやるより、チームで仕事をすることが好きだったんだなと思いました。自分がやりたいと思ったら「ねえ、これやりたいと思わない？」「やりたいと思うでしょ」という感じで仲間を集めてくるというところが性格的にあるのかも知れないですね。

プロジェクトリーダ抜擢に抵抗

三河
次の転機がいまお話したシステムの継続プロジェクトです。今度はガソリンスタンド全体の投資計画や投資に伴う契約関係等の仕組みをやることになったんです。その前のプロジェクトは能登原さんがプロジェクトリーダでしたが、そのときは能登原さんも課長も別の部署に移動するタイミングでした。

能登原
数理制御グループが解体して、みんないろいろなところに散らばったときだね。

三河
情報システム主体で制御システムの研究開発をする時代ではないという会社の判断があって、日本鉱業、ジャパンエナジーと続いてきた情報システム部による制御システムの開発というのはそこで終焉を迎えたんです。制御システムは今私がいるCCSに任せることにして、情報システムの人間はビジネスシステムに集中してやりなさいという雰囲気でした。

その中で能登原さんは別の部署で別のプロジェクトを持つようになって、さっき言ったガソリンスタンドの開発／運営に関わる事務システムに関しては私が呼ばれて「今度のプロジェクトではプロジェクトリーダをやって欲しい」と言われました。その時に、すごく抵抗したんです。

能登原
そう、抵抗しましたね。まだ現場にいたい、マネジメントはいやだ、プロジェクトマネジャはいやだと。

三河
制御をやってデータベースの設計実装をやってというところで、DBMSのコアな部分の仕組みとかもだいたいわかってきて面白くなったところですからね。それがちょうど入社５年目くらいで、周りを見ていると５年目でもバリバリ、プログラミングとか設計とかしているじゃないですか（笑）。
まだまだ現場でプログラミングをしたい、設計をしたいと言ったら、「いや、人がいないんだ」と。確か一晩かけて説得されましたよね。

能登原
この経験をしておくのは三河さんにとっていいチャンスだと思ったんですよ。ちょっと人より早いかも知れないけど。

三河
私の周りでは、全然、早かったですね。

能登原
能力があると思っていたので、三河さんなら出来ると（笑）。

三河
徹底的にいやだと言ったんですけど、「やってみろ、そこではそこでの楽しさもあるし」と説得されました。「いや、マネジメントが大切なことはわかるけど、僕はやりたいことがまだたくさんあって、どれも何一つ満足いく結果を残していない」と言ったら「そんなのはまたやる機会があるよ」というようなことも言われましたよね。それはあとから嘘だとわかったんですけどね（笑）。いったんプロジェクトリーダをやってそこそこの結果を残せる人間は、もう組織がその役目で動かすことを前提に考えますから。

コミュニケーションの重要性を痛感

能登原
で、実際にそのプロジェクトリーダをやってみてどうでした？

三河
最初はつらかったですね。今まで小さいチームで、しかもリーダがいてサブリーダ的立場でリーダとのコミュニケーションもとりながら、全体で方向付けが出来ていたんですけども、自分がリーダになって、かつての先輩も周りにいないし、新しい人も入っていたりしていて。最初、プロジェクトの方向付けをしなければならないんですが、「このゴールに向かってこういうやり方でやっていこう」という意識合わせがなかなか出来なかったですね。一応、「こういう方向でやりたいので協力をよろしくお願いします、じゃあスタートします」とスタートしたんだけども、１週後にはもうみんな向いているベクトルが違っているんです。そこのベクトル合わせにすごく苦労しましたね。

そのとき助けてくれたのは、そのプロジェクトにいた経験豊かな先輩、サブリーダの方で、どうしたら人の気持ちを一つに出来るかについていろいろアドバイスをいただきました。そのときに大事だなと思ったのは、やっぱり人の話を聞くということですね。当たり前のことなんですけど、私は自己主張が強いほうなんで、そういう人間って人の話の聞き方が下手なんですよ。「まず話す前に聞いてみたら」と言われました。

能登原
そう。でも、そういうことはある程度歳をとらないと、なかなかわかってもらえないことでもあります。

三河
アドバイスをいただいて、メンバはお昼ご飯を２～３人の仲間で食べに行くので、「今日一緒に食事に行っていい？」という感じで、日替わりでその２～３人の仲間にいれてもらいました。結局はコミュニケーションですよね。
だから今から思うと、「こういう方向でやりたいんで、よろしく、以上！」で済ませていて「何でわかってくれないのかな」と悩んでいたところがあったような気がしますね。自分では丁寧に説明をしているつもりでも、やっぱりまだ説明が足りないし聞き方が足りなかった。

能登原
リーダになって最初の頃は「自分が思っていることを他人が同じように理解するのは難しいのだ」ということがわからないからね。

三河
そのプロジェクトでは、メンバの半分くらいは年上の方だったんですよ。私より先輩で、開発の進め方や開発のプロセスにしても、開発技法、メソドロジーにしてもいろんな思いがあるし、自分たちの成功体験もあるわけですから、私がこうやると言ったことに対して「そんなやり方、うまくいくのかね」という感じだったんです。一応、リーダの私に表面的には従うんですが、「そうじゃなくて、本当の気持ちを教えて下さい」と思い切って聞いてみたんです。

能登原
それでどうでした？

三河
私は品質の担保をどうしてもしたかったんで、ユーザと確認するためにもビジネスフロー図を徹底的に書いたり、結構ドキュメントを書く量があったんです。メンバからはやはりその部分を「それ、ちょっとやり過ぎじゃない？」と指摘されたんですが、「いや、ここだけは我慢してやって下さい。前のプロジェクトも成功しているし、今回も成功すれば我々としても確信が持てるので」というかたちで、業務フローも徹底的に書いてもらいました。あとになって、業務フローの上にテスト計画書を書き込むかたちです。で、テスト結果も業務フロー上で、「こういうフローをビジネスサイクルテストとして流した」というかたちで書いていって、テスト仕様書にも使えました。テストをする頃にはプロジェクトはすごくいいかたちになっていましたね。立ち上げて、いわゆる外部設計のあたりまではみんな半信半疑という感じでしたが。

最近私が担当しているプロジェクトはイテレーティブモデルでやっているんですが、その頃はスパイラルモデルと言うのをやっていました。そのときやったスパイラルモデルは、外部設計まではどちらかというとウオーターフォール的にやるんですけど、外部設計からプログラム開発のところは、同じ作業を何回か繰り返すんです。作ってうまくいけば残すし、だめなら作り直すって。

能登原
ユーザインターフェイスのところも、一応作ったもので確認しながら？

三河
そうです。作ってそのまま他に持って行けないものは捨てる。作って捨てたり、作って残したりというのをいくつかのサブシステムごとに回しながらやったんです。そのあたりからメンバもまとまってきました。やはりものが動き出すとみんな安心するんですね。もちろんデータモデルも固まってきますし。

能登原
マネジメントでは他にどういうことをやってみました？

三河
コミュニケーションは大事だとわかったので、コミュニケーションのためにいろんな工夫をしました。まずER図ですが、私が最初にリーダをやった時の開発ではエンティティが700くらいあったと思うんですよ。前にやったプロジェクトの修正とかも入っているので、700エンティティのER図を、さっきも言いましたように、システムの全体を見渡すために１枚で表現したかったんです。

ただ、A3に700のエンティティを詰め込んでもエンティティ間の関係の線もいっぱい入っているから見れたものではないので、３×３で９枚を貼り合わせたんです。あの頃はA0プリンタなんてなかったので、全体がA3の３×３に入るようなプリントアウトにして、９枚セロテープでつなげて、それを壁に貼りました。

能登原
まさに「見える化」ですね。

三河
そう、今で言う「見える化」ですけれど、我々は「航海図」と呼んでいました。
その頃、データモデル駆動の開発をしましょうと言われていましたよね。DOAはデータ中心と呼ばれるだけあって、システムの中心にはデータ構造があるという考え方なので、それを壁に貼るんです。データモデルの担当は３人いて、３人が分担をしながら、１週間かけて修正点を話し合いながら最終決定をする。だから週に１回最新モデルをリリースするという感じで、毎週貼り替えるんですね。そうしたらアプリケーションの開発者や運用マニュアルをつくる人とか、いろんな人がグループ単位で壁に貼ったモデルの前で小ミーティングをやるようになったんです。で、「アプリケーションから見て、やっぱりこういうデータの持ち方をして欲しい」とか、「アプリケーションの仕様が変わってデータタイプが変わった」とかということはそこで書き込むんです。だから月曜日にニューバージョンのモデルが貼り出されると、木曜日にはもう青とか赤とかで一杯書き込みがあって。それを担当者が木曜日にはがして金曜日に一気に最新モデルをつくりあげるというようなローテーションでやっていましたね。

能登原
そういうサイクルが動き出すと、チームもまとまるしうまくいく。

三河
ええ、そうやってデータモデルが見えてきて、ものも出来上がって、みんな開発プロセスも理解してくれてという段階になって、始めてベクトルがそろったなと感じることができました。
終わってみたら本当にいいプロジェクトで、ユーザさんも含め大々的に打ち上げをやりました。40人か50人集まったと思うんですけど、「やっぱりこのプロジェクトは良かった」とメンバからも言われたし、ユーザさんからも言われて、もう涙ものでしたね。いろいろあったけど、ここまでみんな気持ちが一つになって、すごくうれしかったです。その時も朝まで飲みました。

（次回に続く）