プロジェクトマネジメント、プロジェクト管理におけるポータルサイト

HOME > プロマネへの道 > 宮本 文宏さん(2) 日本ユニシス株式会社

2007年9月28日

宮本 文宏さん(2)
日本ユニシス株式会社 人材育成部 HR変革コンピテンスセンター チーフ・スペシャリスト

宮本 文宏さん宮本 文宏(みやもと ふみひろ)さん
日本ユニシス株式会社
人材育成部 HR変革コンピテンスセンター チーフ・スペシャリスト
1989年3月 岡山大学文学部哲学科卒業 同年4月 日本ユニシス株式会社入社。UNIXによる開発を多数手がける。
2000年からP2/M等、上流工程からのITコンサルティングに従事。
2002年からソリューション開発領域システム構築PMとしてプロジェクトを担当。
2006年から人材育成部に。

無意味な苦労をせずにすむ方法を探して

能登原
UNIXをやり始めて、小さいプロジェクトからだんだん規模の大きなものになっていく中で、私も何を勉強したらいいのか、あるいは、どういうことが上手にできればプロジェクトを成功に導けるのかを考えていた時期があるのです。その当時、いろいろなプロジェクトを手伝いながら、だんだん大きなシステム開発へと移っていった中で、宮本さんはどんなことを考えていらっしゃいましたか。

宮本
そのころも今もそうですけれど、プロジェクトには厳しい局面があります。ずっと徹夜が続いてしまったり。「そういう業界なのかな」と思いつつも、「何かもうちょっとうまくできないかな」と。

能登原
私はあのころ、もう「そういう業界なんだ」と、思っていましたね(笑)。

宮本
でも、「どうせ苦労をするなら、もうちょっと違った苦労をしたい」というのがありますよね。

能登原
そうですね。ありますね。

宮本
能登原さんも、そのあたりでプロジェクトマネジメントに興味を持たれたのですね。「どうやったらもっとうまくやれるのか」というのは、そういった苦労がベースになっていますよね。

能登原
なっていますね。そのころに私が在籍していた、ジャパンエナジーの前身の日本鉱業では、プライドというシステム開発方法論を導入していました。フィジビリティー・スタディ・レポートをシステム企画の段階でつくるのです。それで予算をとる。予算をとったら、やはりその通りにやりたいと思いますよね。それが汎用機のときは良かったのですけど、ダウンサイジングと言うかUNIXの時代になって、なかなかうまくいかなくなったのです。

宮本
ええ、よく分かります。

能登原
これは大変だ…と。GUIになって、そこの仕様をどうやって決めるかとか、新しいCASEツールが出てきて、やってみたらバグがあるとか、パフォーマンスが悪いだとか、いろいろな問題がその当時噴出しましたよね。「これを解決するにはどうやったらいいのだろう」とその当時、かなり考えました。

宮本
今CASEツールのお話がありましたけど、「これを使えばうまくいく」というツールがすごくいろいろ出てきましたが、それを実際使ってみると、なかなか思った通りにいかないことが、結構ありましたよね、あのころ。

能登原
ありましたね。

宮本
いろいろなツールを手探りでやりながら「方法論も、何かいいのがないのかな」と思いながら実際のプロジェクトを回していました。もっとも、あのころは「プロジェクト」と言わなかったですね。何と言っていました?

能登原
システム開発と言っていましたね。

宮本
でも、システム開発はシステム開発なんですよね(笑)。

能登原
それはそうなのですけどね、情報システムの構築、あるいは開発というふうに当時は言っていました。われわれはシステム開発方法論もプライドを持っていたのですけど、その当時はプロジェクトマネジメントの部分と実務の手順が一体化されていて、分離されていなかったのです。

宮本
ええ。

能登原
今はうちの製品もそうですが、開発のプロセスとマネジメントとを分けています。当時は分けずに一体化していましたね。

宮本
マネジメントプロセスと、実際の開発サイクルが不可分で、くっついたままで回していましたからね。

能登原
だから構成上は、オブジェクト指向になっていなかったですね。

宮本
そうですね。まさしくオブジェクトに分離されてない状態ですね。

能登原
今のほうがはるかにオブジェクト指向になっています。

宮本
当時、ツールを使ってもなかなか改善されないし「こういう世界なのかな」と思っていた部分もありますけど、私も、少しでも改善できるものはないかと考えていました。いろいろ話を聞くと、過去に汎用機でやっていらっしゃった方のノウハウが非常に重要であったりする。それを教えてもらったり、「あの部署でこういうことやっているよ」と聞くと、その内容を聞かせてもらったりしました。具体的には模造紙に書いて貼り出してやるとか、それぞれの役割を明確にするとかです。今PMBOKで言っているようなマネジメントのプロセスについても、現場ではちょっと違ったかたちでやっているケースもありましたから、そういったものを取り込みながらやりました。

能登原
御社の場合は、汎用機で構築しているミッションクリティカルなシステムの資産があります。金融系とか、非常に強い分野をお持ちです。そこのノウハウや技術者の力というのは、すごいですよね。

宮本
ええ。そこで培ってきたものは、やはりすごいものがあると思います。汎用機でやってきた文化を持つ先輩方は、最初のころは全然UNIXが分からないし、逆に私はいきなりUNIXという切り口から入っていったので、助けにいくような立場だったのですけども、今となってみると、汎用機の中で伝統的に培ってきた開発ノウハウやプロセスは、ものすごくしっかりしていました。確かにPMBOKとは違う開発プロセスを使っているのですけど、実はその枠組みにすごく当てはまっていたりします。大きなシステムを3年、4年かけて開発している世界では、暗黙的にそういうことがやられていたということなのでしょうね。

能登原
そうですよね。ああいう世界は、難しさや大変さが全然違います。最近大規模なプロジェクトを支援する機会が非常に多いものですから、いつも考えさせられています。やはり汎用機の文化というのも大事ですね。

宮本
私もその経験から、汎用機の中で培ってきた文化が、全て古いからダメというわけでもないし、その中で伝承的にやられてきていたものをもう少し体系化して見ていくと、今のプロジェクトマネジメントのフレームワークの中に当てはまっていったりするケースがずいぶんあると思いました。

ビジネスを作る立場のコンサルタント業務に移行

能登原
UNIXで徐々に大規模なシステムを手がけるようになって、そうこうしていると、今度は2000年問題が近づいてくるわけですね。その後はどういう道を辿られたのですか。

宮本
2000年の後は、プロジェクトの開発をある業種に特化してやっていました。今から思うと、ずっとPMに近い立場で全体のプロジェクトを回したり、あるいはプロジェクトマネジャの下でサブPMとしてやっていましたね。ただそのときは、システム開発のリーダーとか担当とか、そういう言い方でしたが。 何年かして、あるまとまった開発プロジェクトをしていたときがあったのです。「まとまって開発したら、こんなことできるんだな」と感じました。そのプロジェクトが終わったぐらいにP2M(Project&Program Management)というフレームワークが出てきて、それを知識として入れていく中で、コンサルタントに近いことをするようになりました。 そのときは、入社後ある程度年数が経っていたので、お客さんに対して提案をする立場になっていたのです。私も言われたものをそのまま作っていくよりは、営業と一緒に提案をして、それを形にしていこうとし始めていた時期だったので、ちょうどP2Mが頭にも体にもすっと入っていくような感じでした。そのように、お客さんと一緒に上流からアプローチしてスキームをつくっていくのだといって、コンサルタントに近いような作業をやっていたころが2003~2004年ぐらいです。

能登原
もうサブPMからPMもやられて、コンサルタントとしていろいろなところを支援するようになったのですね。

宮本
ええ。

能登原
プリセールスもやられていたのですか。

宮本
プリセールスまではやらなかったです。

能登原
もうちょっと上流のお客さんが企画を作ったり、計画を作るのを一緒にお手伝いするということですか。

宮本
そうですね。営業と一緒にお客さんの元へ行って、何かきっかけをつくります。業務の改善があったりするので、そこをヒアリングして「これを具体的にシステムにすると、こうですよね」とまとめていく感じです。もともとのお客さんとのつながりの中で、「こういう業務知識でやるとこうなりますよ」と提案するわけです。それをやっていくうちに、だんだんコンサルタント的な仕事がしたいと思うようになりました。 コンサルタントはビジネスをつくる立場です。私はもともと、自分で何か作りたいと思って会社に入って、もの作りもそれなりにやって来たのですけど、アーキテクト的な作業が一旦切れてしまって、プロジェクトを回すことが多くなってきていましたし、今更アーキテクトとしてものすごい活躍ができるとは思えませんでした。第一線級のアーキテクトを目指すには素養の面から厳しいのではないかと感じたのです。逆に今までの自分の経歴からいくと、ビジネスをつくる方に興味がむいていました。 ですからコンサルタント、上流からのアプローチというのがイメージとしてあって、そのときにちょうどP2Mに出会ったのです。P2Mは、PMBOKとは違って、構想立案という上流部分にも強くフォーカスがあたっています。スキームのモデル等があって、次にプロジェクト開発のシステムモデルがあって、そのあとサービスモデルという3つのモデルに分けてプロジェクトを見ます。その3つのモデルの中で、特にスキームモデルの考え方が新しくて、「こういうようなアプローチの仕方も考えられるんだな」と、そのときの私にはヒットしましたね。

能登原
なるほど。ちょうど本当に御社のように、SIビジネスを受注しようとすると、そこが非常に大事ですものね。

宮本
そうです。おっしゃる通りです。お客さんの目的が何か、何を持ってプロジェクトをつくるのかと考えないと、ほんとうの意味でプロジェクトにならないのではないかと、すごく感じました。

能登原
そうですね。確かにその通りです。

ユーザー企業の「情シス」縮小時代に、ベンダーに求められること

宮本
開発側のベンダーは、どうしてもつくることが目的になってしまいます。システムをつくって導入すればおしまい。でも本来、そのシステムによってお客様が価値を見出そうとするわけですよね。例えば、それによって新規ビジネス分野を開拓したり、もっと業務改善してコスト削減するとか、システム開発の先に目的があります。そこを意識していかないと、つくったのはいいけれども、運用で使いづらいということになりかねない。開発のベンダーは限られたところしか見なくなってしまうので、もう少し全体を見て、目的と目標を共有化していかないと、使えるシステムにならないなと思いました。

能登原
私はそのころユーザー側の情報システム部門だったので、逆にそういう見方ばかりしていたのです。上流でそれをしないと効果があがらないし、よい提案をしないと予算をつけてもらえませんから。ユーザー部門の人は、要するに販売部門だったら、新しいシステムでマーケティングをうまくやるとか、販売量を増やしたいわけです。最終的には利益を上げるのが目的になります。それをものすごく要求される。「それでは効果があるシステムって何だろう?」と逆方向から考えました。

宮本
そのときはユーザー部門にいらしたのですか? システム部ではなくて。

能登原
システム部にいました。

宮本
システム部門にいらっしゃって、実際のユーザー部門がいてということですね。企画はもうシステム部門のほうでやってらっしゃったのですか。

能登原
そうなんです。情報システム部門も2000年ぐらいまでは力もあったし、強かったのです。それ以降、日本の会社では、徐々に情報システム部門が減らされていき、本当ににそれでいいかどうかという問題もあるのですけど。 かつて情報システム部で企画をしていた時期というのがありました。企画をちゃんとやっているので、ベンダーに出したときも失敗が少なかったと思うのですよね。アメリカでは、もっと情報システム部門が大きくて、自分のところで作っているという場合が多いらしいですけど。最近日本では情報システム部門の人数を非常に減らしているのです。

宮本
そうですね。

能登原
そうするとベンダーにすごく負荷がかかるじゃないですか。要件がプアーなまま渡されますので。

宮本
開発ベンダー側でも、そこをどう聞き出すかという話がだんだん出てきますからね。

能登原
そういう流れが2000年からだったと思います。ちょうど宮本さんがコンサルタントをやられたころというのは、ベンダーがそういう力を付けないといけない時期だったかもしれませんね。

宮本
そうですね。お客さんとずっと相対していたし、お客さんと一緒に開発する現場でやっていたので、そういうニーズを肌で感じていたのかもしれないですね。現場では、トラブルがあればすぐ呼ばれます。でもトラブルは業務に大きな影響を与えて、お客さんにとっては大きな機会損失につながります。トラブルにずっと対応していると、開発側でもコスト面で赤字になってしまう。皆が良い状況にならない。そうすると、だんだん「上流のところできちんとした設計がされているべきだったんじゃないか」という目線になってきます。 ちょっと話が戻りますけど、私たちはシステム部門と直にいろいろやり取りをしていたのですけど、最近はシステム部門と企画部門が、また別に分かれていますよね。

能登原
そうですね。最近はシステム企画部という名称になっています。昔は情報システム部だったのがシステム企画部。

宮本
で、ユーザー部門がある。お客さんの中でも階層的にそれぞれ見ている部分や狙いが違っていたりします。システム開発では、ITを道具としてビジネスを企画する企画部門と、実装するシステム部門、実際にそれを使って効果を出すユーザー部門という、3つぐらいの階層に分かれると思うのです。

能登原
ええ、分かれていますね。

宮本
われわれベンダーとしては、言われたところを作っていくという形でシステム部門と一緒にやることが多い。でもほんとうは上流の企画部門であったり、サービスを回していくことを考えればエンドユーザー部門と一緒にやっていかなければという部分も出てきます。全体のビジネスがどこに向かっていくのかという部分を経営企画している部門ともタイアップしていくべきだろうなと思っています。 いま思うと、そのタイミングは今おっしゃったようにちょうどシステム部門がだんだん縮小化されていって、企画力をどこが持つべきなのかということになった時点なのでしょう。能登原さんの場合は実際に企画も一緒にやられていたので、そういう目線で見ていらっしゃったのかなと、お話を聞いていて思ったのですけれど。

能登原
私は情報システム部に所属していたのですが、そこがシステム企画部になったのです。だんだん情報システム部の人数が少なくなるのも経験しました。そうするともう、企画だけやってあとは全部情報子会社とかベンダーさんに任せるということになっていましたね。

宮本
今はわりとそうですものね。

能登原
ベンダー側もそういう面では大変になったでしょうね。上流までちゃんとやってSIをとらないと…

宮本
とれなくなってきました。

能登原
宮本さんは、そういうことまでやられたということですね。

宮本
ええ。

(次回に続く)

構成:萩谷美也子

↑ このページの先頭へ