メンバーが働きやすい環境をつくるのが私の仕事
最初は銀行に総合職として就職し、後にITエンジニアにキャリアチェンジしたケービーエムジェイ インターネットプロダクト事業部 プロダクトサービスグループ2 グループマネージャー プロジェクトマネージャー 喜多紀子氏。数々のプロジェクトや会社を経験し、周囲に求められるようにしてプロジェクトのマネジメントに携わるようになった。その後、さまざまな困難を乗り越えることでプロジェクトマネージャとして成長し、いまでは存分にその力を発揮している。
http://jibun.atmarkit.co.jp/lcareer01/rensai/cas018/cas001.html
どのような経験が、そこで身に付けたどのようなスキルが、喜多氏をプロジェクトマネージャにしたのだろうか。
■ITエンジニアとスケートを両立した日々
少し低めの声、落ち着いた物腰に頼もしさが漂っている。今回インタビューしたケービーエムジェイの喜多氏は、これまでITエンジニアとして、プロジェクトマネージャとして多くの経験を積んできた。
意外にも最初の就職はIT業界ではなく地方銀行であり、総合職で広報や資料整理などをしていたという。あるとき、銀行がWebサイトを立ち上げるのがきっかけとなり簡単なHTMLの講習を受講した。ここでHTMLやWebサイトの仕組みなど、ITの初歩的なスキルを得た。
ケービーエムジェイ インターネットプロダクト事業部 プロダクトサービスグループ2 グループマネージャー プロジェクトマネージャー 喜多紀子氏
その後、喜多氏は銀行を離れる。実は大学時代にフィギュアスケートの一種、団体で演技をするシンクロナイズドスケーティングの活動をしていたのだ。出身校の仲間とともに再びスケートを始めるため、卒業して戻った地元を離れ、再び東京で暮らすことにした。しかしプロフェッショナルとしてスケートをするわけではないので、何らかの職を探さなくてはならない。
銀行で身に付けたHTMLの知識を生かそうと、ITエンジニアで職を探した。ITエンジニアの方が収入が多そうに見えたという理由もあった。そしてソフトウェア会社にプログラマとして就職。喜多氏のITエンジニアとしてのキャリアの始まりだった。
仕事は主に官公庁向けのシステム開発で、C++やVisual C++などを使い、画面処理などのコーディングやデバッグを担当した。数カ月から1年ほどの短いサイクルでプロジェクトを経験し、多くの場合、4～5人のチームで開発を行った。
ITエンジニアとして働きながら、勤務時間以外ではスケートを続ける日々だった。スケートはアマチュアだったため、費やす時間は仕事の方が多かっただろう。だが気持ちのうえではスケートの方が勝っていた。「このころは、まだITエンジニア業よりスケートがメインでした。スケートをするために仕事を早く切り上げ、その分土日に働くこともありました」と喜多氏はいう。
■外資系企業でシステムのローカライズを担当
スケートのために転職と引っ越しをしたのだから、その意気込みは相当なものだったはずだ。だがITエンジニアとして働き続けるうち、次第に気持ちはスケートよりITエンジニア業に傾いてきた。
2年半ほどスケートと仕事を両立する日々を過ごした後、喜多氏は本格的にITエンジニアとして働くために会社を選び直した。仕切り直しである。最初の会社では主に官公庁向けのシステムを扱っていたが、IT業界で働くにはより先端の技術に携われる環境の方がいいと思ったのだ。オープン系やWeb系の開発ができる環境を求めて、喜多氏は転職した。
転職後は派遣社員という形態で、外資系医療機器メーカーに情報処理システム開発関係業務担当として派遣された。本国で開発されたシステムを日本の環境向けにローカライズするのが仕事だった。
開発に直接携わるというよりは、各方面との調整や運用に関する作業、ドキュメント作成などを行った。システム開発全体の調整役である。ここでの仕事が、プロジェクトマネージャにつながる最初のきっかけだったのかもしれない。この仕事には1年弱ほどかかわった。
■自社サービスのプロジェクトマネージャは孤独で重責
インターネットでサービスを提供するソフトウェア会社に正社員として転職した喜多氏は、本格的にプロジェクトマネージャとしての任務を受け持った。ITエンジニアとしてはまだ3～4年目だったというのに、プロジェクトマネージャとは大抜擢だ。社員数約30人という小規模な会社だったこともあるかもしれない。
喜多氏は、顧客の要望をくみ取り、費用を見積もり、開発プロジェクトの進ちょくを管理するという責任ある仕事を任された。プロジェクトでは数千万円単位のお金を動かす。だが喜多氏は、「この案件は本当に3000万円で妥当か？」と疑問を抱えていた。間違いであるという確信もなかったが、正しいという自信もなかった。それが不安だった。上司は気軽に「いいんじゃない」と了承していたが、まじめに考えれば考えるほど疑問はストレスになった。
誰かに相談したくても、納得できるように教えてくれる人は周囲にはいなかった。重責を抱えてストレスが高まり、一時は食欲が減退し通院したこともあった。「（このときは）自分を追い込んでしまいました」と喜多氏はいう。一方、上司は後から「あなたならできると思った」といったという。
重責のストレスが負担となり、喜多氏は「もう一度、開発がしたい」という気持ちで次の転職先へと移った。
■上司としての困難、技術的な困難を抱えて
今度の会社ではリモートアクセスシステムの開発と運用管理に携わった。プロジェクトはまだ企画書があるだけで、これから開発を始める段階だった。そこに喜多氏が開発要員として合流した。しかし3カ月ほどして、当初のプロジェクトマネージャが抜けることになり、後任として喜多氏がプロジェクトマネージャを引き継いだ。
このプロジェクトでも、喜多氏はさまざまな困難に直面した。まだプロジェクトマネージャとしてノウハウや経験が豊富でなかったせいか、スケジュール計画など実務で悩むこともあった。だが特に手を焼いたのが、プロジェクトメンバー間の調整だった。
メンバーの中には喜多氏よりはるかに年上で経験の長い人がいて、扱いに困った。ITエンジニアとしてのプライドやこだわりがあり、細部の問題を指摘されて「これではできません」と仕事を断られるなど、なかなか指示が通らないことがあった。
人間関係がうまくいかないのは喜多氏とITエンジニアの間だけではなかった。ITエンジニア同士にも対立があり、こちらの方がより深刻で険悪だった。当時を振り返り、喜多氏は「困りました。仲裁をしようにも、こっちを立てればあっちが立たず……。しかしここで人を動かすことの難しさ、仕様を伝える難しさに直面し、そんなときにはどうすればいいかを学びました」と話す。
前職とは少し種類が違うが精神的な苦痛があり、同時に体力的にも「きつかった」という。開発から運用までトータルで携わったが、主に開発のフェイズで徹夜を何度も経験した。時間が予想以上にかかってしまったのは技術的に新しい取り組みだったせいもあるが、困難に直面してもなかなか有効な解決策が見いだせなかったからだ。
