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

HOME > プロマネへの道 > 坂入 啓一さん(2) 関電システムソリューションズ株式会社

2008年3月21日

坂入 啓一さん(2)
関電システムソリューションズ株式会社 技術サポート本部 技術部 プロジェクトマネジメント室 システム技術支援グループ

坂入 啓一さん坂入 啓一(さかいり けいいち)さん
関電システムソリューションズ株式会社
技術サポート本部 技術部 プロジェクトマネジメント室 システム技術支援グループ
和歌山大学卒業後、1995年に関電情報システム(株)入社。
同年10月 技術開発室に配属。関西電力様からの受託研究、開発業務を担当。1999~2000年に関西電力様システム開発プロジェクトに参画した後、2001年より技術開発部にて再び研究、開発業務に携わる。
2005年、社内研究企画/統括業務に従事しつつ、社内プロジェクトマネジメント標準の策定に携わり、2006年よりシステム技術支援グループの統括業務を担当。

技術部で研究業務を担当しながら、開発プロジェクトも経験

能登原伸二

能登原
今の技術部である技術開発室での最初の仕事のあとは、どういうお仕事をされたのですか。

坂入
技術部の仕事は研究が中心でしたが、私の場合は、研究といっても会社の中で行うものではなくて、関西電力さんの研究を、委託を受ける形で行っていました。
入社4年目ぐらいに、システム部門に行って、そこで2年ほどシステム開発の仕事をしました。

能登原
それは関西電力さん向けのシステム開発ですか。

坂入
ええ、管理会計のシステムです。技術部だったこともあって、インフラ系の仕事が中心でしたが、バッチアプリケーションの設計や開発も行いました。

能登原
システム部門への異動ではなくて、技術部から支援というかたちで、開発のプロジェクトメンバーに入ったということですか。

坂入
そうです。今なら、弊社にも「プロジェクトチーム」という制度がありますが、当時はそういう考え方がなかったので、籍は技術部に置いて、実際にはもうずっとプロジェクトに入って仕事をしてました。でもそのときはシステム部門に異動という扱いではなかったので、社内的には、私のことをずっと技術部に居て、システム開発の経験がないような言われ方をするんです。でも一応経験はあるんですよ(笑)。
ただ確かに、業務アプリケーションを作るという意味では、そのプロジェクトが私が経験した数少ない開発プロジェクトになってしまいます。技術部に戻っても担当したプロジェクトはあるのですが、どちらかというと、システム基盤を構築するようなものばかりで。例えば、関西電力さんのディレクトリサーバを立てるとか、メールサーバを置き換えるとか、ポータルシステムを立てるとか、だいたいそんなプロジェクトでした。

能登原
そうすると、坂入さんの得意分野というかスペシャリティーは、ITスペシャリストの中でもインフラ系だとかミドルウエアになるのでしょうか。

坂入
どちらかというとミドルウエアですね。今の仕事もそのあたりを扱っています。インフラというよりは、DBMSやアプリケーションサーバというようなミドルウエアになりますから、ちょうど当時私が担当していたところを、今のグループも担当していることになりますね。

能登原
そういうことですね。私も経験しましたが、最初はいろいろな開発を担当し、だんだんミドルウエアやインフラが得意な人とか、データベースのスペシャリティーを高めていく人とか、ネットワークを専門にしていく人とか、スペシャリティーが分かれていきます。御社の技術部の中でも、そういうふうに分かれているのでしょうか。

坂入
自然とそうなりますね。昔はインフラと言ったら、OSからデータベースからネットワークから、全部担当したりしてましたが、最近はそれでは通用しませんので、データベース、ネットワーク、OSといったように、得意分野がだいたい分かれて行きますね。

能登原
坂入さんが入社されたころは、何でも一人で、全部担当されていたのですね。

坂入
まあ担当業務の多くが規模的に小さかったのもあると思いますけどね。だから大規模なところに入ったときは、そうではなかったです。先ほど話しましたシステム部門にいたときは、開発の規模が大きかったので、そんなことはありませんでしたよ。

能登原
大企業の、しかも電力会社の開発プロジェクトは普通のところと全く規模が違うじゃないですか。大規模なプロジェクトだと発想自体が全然違いますよね。技術にしても相当な信頼性がないと採用できないですし、ちょっとした小さいプロジェクトのように、適当にやるわけにいかないでしょう。開発にあたる人数も多いですし。

坂入
そうですね。規模が大きいプロジェクトとかになると、すごくきっちりしていますよ。でも、まだ最初のころにそういったシステム開発にもある程度関われたのは良かったです。それが逆だったら辛かったと思うんですよ。最初にある程度手を抜けるようなプロジェクトから始めてきっちりとしたプロジェクトに入ると、「何でこんなんせなあかんねん!」ってなるでしょうね。

能登原
そういう難しいものや大規模の開発を、最後まできちんとやりきる大変さというのは、実際にやってみないと分からないですが、とにかく、やらないと終わらないですよね。それで、仕事のやり方とかお作法を覚えるというところはあります。

坂入
そうですね。私なんかやっぱり最初は「ホントにそこまでせなダメなん?」と思いながらやっていましたけれど、最後の方になったら、「ああこれは、設計書をちゃんと残して良かったな」とか、そう思ったりした経験はいくつかありますね。
でも今の悩みはそこから発展して、「コストや期間を抑えるためには、タスクの中のどれを端折ってもよいのか」というところですね。端折ってはいけないことまで端折らないように・・・、ということを考えるのが難しい。

能登原
システム部門で開発を経験されて、また技術部に戻って来られた時期が、2000年ぐらいだったということですよね。

坂入
ちょうど2000年です。2000年問題をクリアしたタイミングくらいにちょうど帰って来たっていう記憶があります。

能登原
2000年問題のとき、技術部は大変だったのではないですか。

坂入
どうでしょう。その時の技術部の状況はよくわかりませんが、システム部門の方がやはり大変だったんじゃないでしょうか。正月なのに会社に来て張り付いてたと思います。でも大きいトラブルは聞いていないですね。

能登原
全体で見ても、思ったよりトラブルはなかったですね。あらかじめ、だいぶ言われていましたから。あのとき私も初めてコンティンジェンシープランというのを本格的に作りました。計画を作るのがけっこう大変でしたが。

坂入
まあ、この日のこの時間と決まっている分、作りやすいと言えば作りやすかったかもしれないですね。あれからコンティンジェンシープランみたいな発想が、いろいろ出てきたので、2000年問題はよい機会だったと思います。

能登原
プロジェクトマネジメントでも最近「いや、コンティンジェンシープランを作らないとだめですよ」と言っていますけど、じつは2000年問題がよい経験になっています。

坂入
みんなそう思っているんじゃないですか。

能登原
戻られてから、技術部の中ではどういうお仕事をしたのですか。

坂入
また研究業務です。ネットワーク系から何からいろいろと。

手探りで試行錯誤のプロジェクトマネジメント

坂入啓一さん

能登原
今まで伺ってきたお仕事の中で、一番大変だったのはどういったことでしたか?

坂入
それでは、私のプロジェクトマネジメントの失敗談を最初にお話しましょうか(笑)。先ほどちょっと触れた、関西電力さんのディレクトリサーバを立てる開発ですが、最初はまず「こういうのが本当に役立つのか、導入できるのか」といった検討から入り、そこから実際に設計、構築、導入といった流れで行いました。今でこそ技術部は、お客さまのシステム構築はあまりしないんですけど、その頃はまだそういう仕事も行っていました。私にとっては、それが、最初の研究ではないシステム構築という意味でのプロジェクトマネジメント経験でした。

能登原
立場はプロジェクトリーダーですか。

坂入
そうですね。実際はほとんど運営は任されていましたが。

能登原
それではプロジェクトマネージャですね。

坂入
実質はPMの仕事を行っていたと思いますが、あの頃は身の回りにプロジェクトマネジメントの方法として何か確立されたものがあったわけではありませんでしたから、どうやって進めていけばいいのかと、すごく悩んだ時期でした。私もまだそんなに経験を積んだ立場ではなかったですが、他のメンバーも若い人ばっかりで。
そのプロジェクトでは、私も設計書やプログラムを書いたりもしていましたが、特にマネジメントの仕事は、「マネジメントとは何?」、「どうやれば上手く進められるんだろう?」と日々考えながら過ごしていました。あのころはまだPMBOKもそれほど知られていなかった時期でしたしね。

能登原
PMBOKそのものはけっこう昔からあるのですが、PMBOK 2000というのが2000年に出て、それで脚光を浴びたのです。

坂入
それは第2版ですよね。

能登原
そうですね。PMBOK2版という名前ではなく、PMBOK 2000と呼ばれていましたが。

坂入
私が最初見たのは、その前の版なので、第1版ですね。

能登原
ああ、それはもうちょっと前の、90何年に出たものでしょう。

坂入
それを買って読んだんです。現在の版と比べるとだいぶ小さな冊子で、取り寄せるのにも時間がかかった記憶があります。

能登原
そうですね。2000年版でまともになりました。

坂入
そのまともじゃないやつを読んでいたんですかね(笑)。プロジェクトマネジメント関係の書籍自体もそんなになくて、いろいろ調べていたらPMBOKとかいうのがあるらしいというので、取り寄せて読みました。他にもいくつかプロジェクトマネジメントを扱った書籍があったので、それを読んだり、試行錯誤しながらやっていました。

能登原
そのときは何人くらいのプロジェクトだったのですか。

坂入
それほど大きくはなくて、部のメンバーは4人ぐらいでしたけど、委託さんの他に、インフラ部門であったり、開発部門であったりと、他の関係部門が絡んでて、それが難しかったですね。
マネジメントをどうしたらいいのか必死で考えたのは、あのときが最初です。だから今我々が作っているプロジェクトマネジメント標準のようなものがないと、きっと何人かは私と同じように悩みながらやるんだろうなと思いながら取り組んでますね。私はその時は何とかなったからいいようなものですが。

能登原
研究開発の部門では、チームでマネジメントという発想がどうしても薄いですからね。私も前の会社にいたときに、最初研究開発的な仕事をしていたのですが、スケジュールも、作らずというか作れずにやって、個人の実力でやるようなところがありました。

坂入
スケジュールとか、進捗管理と言った面での違いは大きいですね。でも、研究業務になると、また別の意味で難しいところはあるんです。例えば、「研究成果が出たら予想と違っていたので、今度は結果に添った方針でこういう調査も必要だ」とか、臨機応変に変えざるを得ないという面で、すごく難しい。あまり厳密に管理しても意味がない場合が多いし、管理できないという面があります。特性の違いですね。

辛いプロジェクトの経験から学んだこと

能登原伸二、坂入啓一さん

能登原
そのディレクトリサーバのプロジェクトでは、マネジメントだけでなく部下の育成についても考えた初めての経験ではないかと思うのですけど。

坂入
そうですね。でも、一応考えてはいましたけど、正直、深く考えられるだけの余裕がなかった。私の力量不足でしょうが、プロジェクトがコスト的にも膨れてしまって、残業時間も増えて、すごく苦しかった。だから、モチベーション維持にはかなり苦労しました。幸いにもメンバーには恵まれて、頑張り屋が揃っていましたが、それでも大変でした。

能登原
そういう研究開発部門では、それ自体が好きな人間が多いから頑張るでしょう。
私も研究開発部門にいたときに、夕方に何か、部下に技術的な質問をすると、みんな次の朝までに宿題をやってくるのです。

坂入
そんなこともありましたね。

能登原
要するに、夜中にやっているんですよね。すぐに答えることに喜びを感じているわけですよ。そういう部下はいますごく伸びています。

坂入
私は解決しないと落ち着かないから、ある意味、好きで遅くまでやっていただけなのですが、メンバーのみんなもなかなか帰らなかったですね。

能登原
技術的に好きなことだし、好きでやっているというのがあるから、長時間でももつのでしょうね。

坂入
みんな私が帰らないから、帰れなかっただけかもしれない(笑)。
私は、今では、上があんまり頑張ると良くないと思っているのですけれど、あの頃は自分がやらないと示しがつかないと思っていた部分があって、「お先に」と言って帰るのはなかなかできませんでしたね。
メンバーはたぶん、「もう早く帰ってくれよ。あんた帰ってくれんと僕も帰られへん」とか思ってたでしょうね。

能登原
絶対そうだと思いますよ(笑)。特に真面目な若手はそうですよね。歳を取ると、状況がわかっているので帰れますけどね。

坂入
そうそう。「やることやったんやから何悪いねん」って、実は仕事残ってるの忘れてるのに大きい顔で帰ったりして(笑)。
まあ若い人ほど帰りづらいでしょうね。

能登原
それは坂入さんが。30歳から31歳くらいのことですか。

坂入
そのくらいだったと思います。

能登原
皆さんそのあたりでちょうど、なんらかの失敗を経験したり、たいへんな思いをするみたいですね。私も失敗経験があって、そのときに「じゃあせっかく失敗したんだから、何とか違うやり方でやって次をやろう」と考えました。坂入さんもそのときになにか考えられて、変えたことはありますか。

坂入
そうですね。まず、あまり頑張り過ぎないようにと。先ほどの話に戻ってしまいますが、「帰れるときは帰るのを自分が実行して部下に見せるようにしなければ」とか。ただしばらくは直らなかったですけどね(笑)。
でも、そのプロジェクトではみんなにすごく負荷をかけましたし、そもそも当時はプロジェクト評価をそんな厳密に行っていなかったので、採算面でそれほど厳しく見られたわけではなかったのですが、コストが膨らんだことが一番の反省点です。そのときは、「お客さんが喜んでくれるんなら」と思って取り組んでいました。「頼まれたらそれをするのがみんなのため」「喜んでくれたらそれが一番」みたいな感覚でしたから、今考えるとコスト意識が欠落していたんですよね。今後は「そうじゃダメだ」と思ったのが、一番大きな変化かもしれません。正直かなり反省しました。次からはできるだけ「それは最初の話じゃないですよね」とか言って断るように心がけました。それが一番大きいと思います。まあそれでも、全部が全部断るわけにもいかないですけどね。

能登原
でも、お客さんに喜ばれるように、という感覚は非常に大事ですよね。それがなかったら仕事は面白くも何ともないですから。

坂入
それを実行しつつ、会社に儲けを出していかなければいけない。

能登原
そうなんですよ。

坂入
上司にも喜ばれるように(笑)。なかなか難しいですね。

能登原
ものすごく難しいです。

坂入
永遠の課題かもしれないですけど。

能登原
現場の人間は、まずお客に喜ばれたいと思いますけれど、立場が変われば、それだけというわけにもいかないです。

坂入
それは、お客さんに喜んでもらうのが一番いいと今でも思っていますけど、あくまでも会社に利益をもたらした上で、ということです。自分がどうやって食べていけてるのかは忘れてはダメでしょうね。だから、プロジェクトに関わった全員がほどほど満足した中で、お客さんの満足度が一番であれば、それは最高でしょうね。

能登原
そうですね。

坂入
でも、それが簡単にできるなら誰も苦労しないですね(笑)。

能登原
それでは新しいプロジェクトからは、やり方を変えられたのですね。

坂入
スコープの管理というか、最初の前提と違うことを言われたときは「それは今回の対象外です」とか、「それは最初の話にはなかったので、別予算ならやらせていただきます」と。正直に言うと、別予算もらってもこちらの体制はそのままの場合が多くて、「もういらんから…、お金いらんから、作業も勘弁して…」と思うんですけれど、そこはがんばることが多かったですね。
まあ、スコープの中か外かのグレーソーンが一番難しいんですけどね。みんな苦労するのはそのあたりが多いでしょう。

能登原
でも、スコープ外の仕事であるなら、それは断る姿勢が確かに必要ですよね。

坂入
とは言ってもスッパリと割り切れないことも多い。そういう時は最終的に会社判断になるんでしょうけど、うちの会社がどうかはわかりませんが、その辺りのことにすごくドライな会社さんはありますよね。
「それはうちの仕事じゃないです」って、バシッと切ってしまう(笑)。そこの業績がすごく伸びていたりして。「あれが正しいんかな?」とも思うのですけど、一方では「そんなことしてお客さんが困ることになってもねぇ」と思うし。すごく難しいところですよね。バランスだとは思いますが。

能登原
その辺りの心境や考え方の変化は、だんだんお立場が変わってきたからですよ。

坂入
そうかもしれませんね。

(次回に続く)

構成:萩谷美也子

↑ このページの先頭へ