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

HOME > プロマネへの道 > 島本 栄光さん(4) KDDI株式会社 情報システム本部 システム企画部管理グループ 課長 

2005年5月27日

島本 栄光さん(4)
KDDI株式会社 情報システム本部 システム企画部
管理グループ 課長 

島本 栄光さん島本 栄光さん
KDDI株式会社 情報システム本部 システム企画部
管理グループ 課長 
1988年DDI(現KDDI)に入社。一貫して情報システムに携わる。2001年10月のKDDI社合併においては、システム統合に関する事務局として各種調整にあたった。現在は情報システム本部の人材育成・教育研修を担当。
著書に「情報処理教科書 システムアナリスト」(翔泳社)、「上級シスアド合格への道」(編著:同友社)、「風雲!シスアドの現場」(編著:秀和システム)がある。
上級システムアドミニストレータ連絡会 副会長

合併で高まった人材育成の機運

島本栄光さん

能登原
どういう経緯で人材育成やスキル診断などにご興味をもたれ、必要性を感じられることになったのでしょうか。

島本
大きなイベントとしては、2000年にKDDIに合併したことがきっかけです。
実は私は、合併の際のシステム統合を検討する部会の事務局の一人としていろいろ調整にあたっていました。事務局の仕事は旧DDIの立場で行っていましたが、旧KDDと旧IDOのシステム部門の人達との交流は早かったです。

能登原
それだけの規模の合併になりますと、とんでもなく大変なプロジェクトですね。

島本
なかなか上手く折り合いが付かない問題がどうしてもありますし、大変だったことは確かです。でも結果的に言えば、情報システムに関しては、これだけの規模の合併にしては上手くいった方ではないかなと思います。
合併する場合、元の会社と会社の間でコンフリクトが発生してなにかと問題になってしまうことがよくあります。それは情報システムに関してもゼロではなかったと思います。個人的に一番印象に残っているのは、やはり複数社の中での意見の調整というか、ぶつかり合いですね。

能登原
それはどういったぶつかり合いだったのですか?

島本
まず旧会社が、それぞれ自社で持っているシステムがあった場合、合併後はどのシステムでいくのがいいのかを議論し調整していくのですが、それが大変でした。3社とも同じような業務システムを持っていたので、合併後にどれをメインにするのかを決めなければならない。そのあとは、メインでいくと決まったシステムに精通している人が主体になって運営していくわけですから、どうしても権力争いのような感じが出てきてしまうんです。

能登原
イニシアティブの取り合いみたいな?

島本
ええ。なかには自分の保身のために「うちのシステムでいきたい」と言う人もいるでしょうし。一方でフラットに見て「向こうのシステムの方がいいんじゃないの」という話も出てきます。逆に保身を考える人には、そういう発想が信じられなかったりするんです。そういったところを調整するのがとてもしんどかった(笑)。

能登原
システム的な問題というよりは、人間的な問題ですね。

島本
当然だと思いますが、感情が絡みますからね。だからこそ合併企業同士でやりあうのではなく、旧社内の内部調整が必要だろうと、逆にそうしないとまずいと思ったんです。そこできちんと意見を合わせていかないと、合併企業間ではさらに大変なことになりますから。

能登原
そういう場合、腹の底から話し合わない限りなかなか本当の意見を引き出すのは難しいでしょう?

島本
そうなんです。これはもう、情報システムとかプロジェクト・コントロールとかを超えた話かもしれないですね。
このような問題は私たちだけでは答えが出せなかったりすることも多く、最終的には経営層の副社長か常務かに預けてトップ同士で決めてもらうしかないです。そうでもしないと納まりません。

能登原
会社の政策的な部分にも関わったことになりますね。たいへん貴重なご経験だと思います。その合併がきっかけで人材育成に強い関心を持たれることになった…。

島本
合併したのばかりの状況では、とりあえず旧3社の情報システム部の人間をガーッと寄せ集めた形です。合併当初は400人くらい部員がいたんです。

能登原
400人ですか!

島本
まあ徐々に減って今は290人か280人になっているんですけども(笑)。とにかく合併して寄せ集めた状態ですから、バラバラですよね。そこで情報システム本部長が先頭に立って、情報システム本部内をひとつの方向に向けるために、もう一度企業のシステムを考え、勉強をしようという方針を打ち出しました。まず、本部全体として「人材育成に力を入れていきましょう」と直接打ち出してきている状況があったんです。ですから私個人が、というよりも、もっと全体的な流れだったわけです。

能登原
なるほど、合併によって必然的にそうならざるを得なかったわけですね。

島本
その後、システム企画部の機能を強化しようということになったんです。2003年4月頃ですが、人材育成に特化したチームで具体的な対応をしていくということで私が担当になりました。ちなみにこのとき、システム企画部には、人材育成チームの他、いわゆる要件定義チームと、システム構築手法やツールを導入しそれを活用できる形にもっていく技術企画チーム、そして運用を取りまとめる運用企画チームの計4つのチームが立ち上げられました。これら4つの機能を強化し、情報システム本部全体をさらに高度化すべく、現在も活動中です。

システム部門に必要なスキルをどう捉えるか

島本
それまでは、情報システム本部内もバラバラで、各システムで別々に動いていたんです。それは結局古いシステムや昔の組織のままを引きずっているということなんですよね。そこで本部が人材育成の観点から一元的にまとめていくことになったのです。その時に、それこそユーザー企業のシステム部門として必要なスキルということで、モデリングとアーキテクチャの設計、この2点に力を入れていくことになりました。

能登原
スキル強化のために、具体的にはどのようなことをなさったんですか?

島本
「この人だったら大丈夫」と見込んだ方に講師に来ていただいて、まずはモデリングとアーキテクチャ設計の両方の基礎的部分を、本部内のできるだけ多くの人に、まずは1回勉強してもらうことにしました。それは「こういう考えでうちの組織はシステム構築をやっていく」という本部の意思表示でもあったわけです。より高度な技術が必要で仕事に直結していくような人は、次に演習をやってもらうような場をつくり、そういうことを繰り返してやっていきました。

並行してプロジェクトマネジメント研修も企画しました。それまでは我流で外注管理をやっていたんですが、標準である「PMBOK」というものがあるのだから勉強しようよ(笑)と。

このようなメニューで、まずは、知識を身につけたうえで演習ができるような場があったら、うまくスキルアップにつながるのではないかと思いながら研修企画を行っていたんですが、実はいまひとつしっくりこなかったのです。例えば、その場で研修を受けて、「よかった、勉強になった」と思っても、自分の仕事に戻ってそれがそのまま使えるかというとそうでもなくて、どうしても現実の作業と研修の間にギャップがある。研修修了後のアンケートを取ってもそういうことがわかるんです。何が問題だろうと考えていたんですが、なかなかわからなくて、ひょっとしたらまずはそれぞれのメンバーが、今どういうポジションなのかということを改めて確認した方がいいんじゃないかと…

能登原
そこで弊社のスキル診断にたどり着かれたわけですね(笑)。

島本
はい、なぜそれがよかったかというと、当時、世の中にはITスキル標準(ITSS)準拠を前面に出し、「あなたはIT職種○○のレベルいくつですよ」というのを診断結果として出すパターンのサービスばかりだったのに、アイ・ティ・イノベーションさんはそうではなかったからです。ITSSはやはりベンダーサイドの人材を意識したもので、こちらが求めているものと違うと思うんです。

能登原
そうですね。弊社はITSS以前にスキル診断を完成させていますから。
スキル診断の結果はどのように使われていきますか?

島本
まず時系列で比較できるように診断を継続した方がいいんじゃないかなと考えています。また、今ユーザー企業のシステム部門のための人材スキル標準が必要だと思っているのですが、それは各企業がそれぞれ考えるべきだと思うんですね。そこで「KDDIのシステム部門のスキルスタンダードというものがどういうものなのか」ということを去年の秋くらいから考え始めていて、そこに今回のスキル診断で出てきた結果や考え方のエッセンスを取り込んでまとめようかと思っているところです。こういうのを考えていたところにJUAS(日本情報システム・ユーザー協会)さんから、ユーザー企業向けのITSS検討委員会を立ち上げるというお話があり、検討委員会に参加させていただいています。

能登原
それはよいタイミングでした。

島本
ひとりで悶々と考えていただけでは進まなかったようなことも、そういう場で他の人の意見を聞くことによって見えてくるのではないかなと思っています。

能登原
ユーザー企業サイドのITSSは将来的にどんなふうになっていくと思われますか。

島本
これは個人的な考えになりますが、確かにITSSはベンダーサイドに寄っている標準ですが、ユーザー側の人材でも上手く利用できる部分はあります。まずそれを上手く使ってしまえばいいじゃないかと思っています。その上でユーザー企業側でやるべきことが今のITSSに反映されていないものは何かを洗い出す。要は、最初に職種を置くのではなく「ユーザー企業のシステム部門のやるべき機能や役割は何なのか」をきちんと洗い出すところからやらないと大きな漏れが出るんじゃないかということです。やるべき機能を先に洗い出して上手くマッピングをしながら、これをやるにはこういう人材が必要だという形で職種のようなものを際立たせていければ、本当に意味のあるものになるんじゃないかと思います。

私は直感的に、現在のITSSには調達、評価検証、利活用の3本が足りないと感じるんです。裏返せば、この3つはユーザー企業のシステム部門がきちんとやらなければいけない。

能登原
そうお考えになる背景には、やはりこれまでのご経験が効いているんでしょうね。

島本
そうですね。これまでやって来たことを通じて、「システム部門ではこういうことをやらなければいけない」、「こういうことを考える必要がある」と何となくイメージが固まってきたというのはあると思います。

能登原
最後の質問ですけど、お仕事をする上での信念がおありでしたらお聞かせください。あるいは言い方を変えて、プロジェクトマネジメントには何が大切だと思われますか?

島本
そうですね。信念といいますと…「当事者意識」ですかね。最後は自分がやるというところに尽きるんじゃないでしょうか。
当然ひとりで出来ないこともたくさんありますから、誰かにお願いしてやってもらうとか、あるいは部下に指示を出すということもあるんですけど、もし結果としてそれができなかったり、自分の意図と反する結果になりそうだといった場合には、最終的には自分でかたをつける、責任を取るというところまで意識をする必要があるなあ、と思います。

能登原
人材の育成もひとつのプロジェクトだと思うのですが、プロジェクトのリーダーとしてマネジメントを行う場合、何が一番大切ですか。

島本
非常によく言われることだと思いますが、人の話をよく聞くことですね。相手の話の全てが正しいということはないと思うので、聞いた内容をそのまま受け入れることもあるし、そうではないと別の判断を下すかもしれないし、そこは「自分が考える」というプロセスが入ってこなければならない。そういう意味で、両方の質問に共通して言えるのは、「当事者意識」が大切だということです。

能登原
率直に整理して、話していただきましたが、最後のお答えには仕事への深い「覚悟」がうかがえました。
本日は本当に、ありがとうございました。

↑ このページの先頭へ