OBT　人財マガジン

• 「自ら課題を発見し、その課題解決に向け、周囲をリードしながら主体的に行動できる人財」。今、多くの企業がそんな"自律型人財"を求めています。どうすればそのような社員が育つのか。ヒントを求めて、現場で活躍する若手リーダーを訪ね、成長の軌跡を伺いました（聞き手：OBT協会　伊藤みづほ）

  シリーズ──「自律型の人財」の成長プロセスとは (第五回－前編)

  　

  

  株式会社損保ジャパン・システムソリューション
  構造改革・統合本部　団体グループ　課長
  三浦忠信さん（42歳）

  損保ジャパン・システムソリューションは、損保ジャパングループのIT戦略を担う企業。三浦さんは入社以来、団体保険のシステム開発を手がけ、開発の上流から下流に至る全工程を網羅する技術力と、仕事への強い信念を武器に、数々のプロジェクトを成功に導いてこられました。しかし、意外にも新入社員時代は技術研修に苦戦され、エンジニアとしてのスタートは順調ではなかったとか。さまざまな経験と向き合ってこられた20年間の道のりを伺いました。

• みうら・ただのぶ

  1968年生まれ。大学卒業後、安田火災インフォメーション・テクノロジーに入社。一貫して、団体契約向け損害保険商品のシステム開発に携わる。汎用大型機（大型コンピューター）を使用するシステム開発を手がけた後、Web系のシステム開発にも従事。小・中規模から約3000人月規模の大型案件まで、多数のプロジェクトでサブリーダー、リーダーを務める。

  株式会社損保ジャパン・システムソリューション （ http://www.sompo-japan-sys.co.jp/）

  損保ジャパングループのシステム・ソリューション・プロバイダーとして、「システムでNo.1」「ITソリューションでNo.１」「働きがいでNo.１」の「3つのNo.1」を掲げる。中でも人財を「最大の財産」と位置づけ、全社をあげて「人づくり」に取り組んでいることが同社の特徴。設立／1984年、資本金／7,000万円、従業員数／670名（2010年4月現在）、売上高／244億9,048万円（2010年3月期）

• 自らチャンスをつかみ、自ら転機をつくる

  伊藤（OBT）　三浦さんは、1991年に御社の前身である安田火災インフォメーション・テクノロジーに入社されました。大学は文系のご出身だそうですが、そもそもなぜエンジニアの道に進まれたのですか。

  三浦　特にエンジニアを目指していたわけではなく、損害保険分野とシステム分野が今後さらに伸びるだろうと考えて、たまたま出会ったのが当社だったんです。学生時代はキーボードに触れたこともありませんでしたが、まあ何とかなるだろうと（笑）。これが間違いのもとで、新入社員研修でシステム開発の基礎を学ぶのですが、ついていくのが大変で。最初のころは、「辞めてやる」といつも思っていました（笑）。

  ただ、プログラミングに慣れてくると、他の人がつくったプログラムを見て「自分ならこう書くのに」と思うことが増え、「わかりやすいプログラムとは何か」といったことを考えるようになったんです。そういった仕事の質に対するこだわりは、プログラマーの頃から持っていましたね。

  伊藤 　なぜこだわりを持たれるようになったのですか。知識や技術が身につくにつれて、仕事が面白くなってきたということでしょうか。

  三浦　いえ、入社後の6、7年間は、既存システムの保守や改修が中心で、仕事を面白いと思ったことはあまりありませんでした。でも、私は負けず嫌いなところがあって、自分が手がけるからには"いいもの"をつくりたいという思いがいつもあるんです。そういう性分なのかもしれないですね。

  伊藤 　仕事の質にこだわりを持つ三浦さんに、仕事が楽しくない時期があったとは意外です。何か転機はあったのでしょうか。

  

  三浦　入社8年目のことでしたが、団体保険にインターネットで加入できるシステムをつくるプロジェクトが立ち上がって、開発に参画したことが私の一番の転機になりました。「誰かやりたい人はいないか」と上司がメンバーを募集していたので、自分から手を挙げたんです。当時はまだ、インターネットでのビジネスがそれほど多くない時代でしたから、やってみたいなと思って。

  Webの技術は、それまで手がけてきた技術とは違いますから、自分でいろいろと技術書を買ってきて猛勉強しました。なかでも苦労したのがサーバーの準備です。ハードウェアのノウハウがまったくない中、協力会社の詳しい方に教わりながら、その方もわからないことは2人でインターネットで検索して。ヒットするのは英語の文献ばかりで、辞書を片手に翻訳しながら、何度も試行錯誤しました。

  そして、ようやくハードウェアの構築を終えて、アプリケーション（※）との連動を図る段階にさしかかったときに、その担当者が異動になりまして。急きょ、私がアプリケーションも担当することになったんです。これがまた大変な業務でしたが、結果的にこの案件のほぼすべてを担当したことが、私にとっての大きな転機になりました。

  ※アプリケーションソフトウェア。計算ソフトなど、特定の目的のために設計されたソフトウェアのこと。

  伊藤 　本来担当ではない仕事を突然任されて、戸惑いはありませんでしたか。

  三浦　それはありませんでしたね。むしろ、案件のすべてに携われるチャンスだな、と。システム全体の構築に初めて携わって、自分で試行錯誤を重ねてつくり上げることを経験し、私のエンジニアとしての基盤に繋がったプロジェクトでした。この案件に対する愛着は、これまでのプロジェクトを振り返っても、格別なものがありますね。

  伊藤 　困難なご経験を成長の糧にされたのですね。エンジニアとしての基礎を築き、新しいことに挑戦したいという思いを十分に温めていた入社8年目というタイミングだったことも、大きかったでしょうか。

  三浦　いえ、もっと早くてもよかったと思います。私の同期は早い時期に仕事を覚えて自信もつけて、どんどん発言するようになっていましたが、私は仕事に面白さを見出せずにいましたので、職場ではあまり積極的ではなかったんです。新しい技術に触れる経験がもっと早くできていれば、今の自分もまた違っていたかもしれません。でもいずれにしても、このプロジェクトには手を挙げてよかったと思いますね。

• 慣れが通じない"異質な経験"が視野を広げる

  

  三浦　次に、転機というわけではありませんが、勉強になったのは入社15、16年目に経験した新規システムの開発です。2900人月（※）規模で、開発期間は18カ月でした。

  ※人月：システム開発の工数や仕事量を表す単位。1人が1カ月で行える仕事量を「1人月」と呼ぶ。

  伊藤 　素人ながらですが、2900人月規模って、相当大きなプロジェクトですよね。

  三浦　ピーク時には数百名のエンジニアが参加し、サブリーダーの立場では数十名規模のチームを管理する、かなり大規模な開発でした。私は7人いたサブリーダーの1人を務めました。

  伊藤 　仕事の面ではどの様な変化がありましたか。

  三浦　それまでに経験したサブリーダー業務では、自分の担当パートだけ見ていればよかったのが、このときはシステム全体の構造を考えることにも関わったんです。まずは私を含め2人でシステムの設計方針について議論し、社内の有識者を集めて理解を得る。そして会社としての意思決定を図り、開発スタッフを集めた説明会を開いて、設計方針を理解してもう。こうした一連の社内調整が、大変でしたがとても勉強になりました。

  例えば、膨大な人数の関係者と連携をとるには、「全体にとって何がベストか」を考える視点を持たなくてはいけないということ。利害が異なる人たちの意見を調整するには、理解してもらえるまで、とにかく一人ひとりとじっくり話し合うことが大切であること。何もかもが初めての経験で、多くのことを学びました。

  伊藤 　これまでの仕事のやり方が通用しない経験が、視野を広げるきっかけになられたのですね。

  三浦　そうですね。自分で設計して自分でつくるのが一番楽ですが、そうはいかないプロジェクトもありますので。プロジェクトが大きければ大きいほど、さまざまな利害関係が交錯しますから、開発方針を立ててもすんなり全会一致とはいかないんですね。立てた設計方針に対して、関係者からきちんと承認を得たうえで意思決定することの大切さを実感しました。

  さらに、このプロジェクトには、実はもう一つ大変だったことがあって、諸事情により開発の途中で設計方針が大幅に変更されたんです。既存のシステムをすべて新しくつくり直すという当初の計画を見直して、一部の機能だけを新規に開発し、ほかは現行のシステムに機能を追加するというやり方に変えたんです。

  リーダーと他のサブリーダーも状況を把握し、変更の必要性を認識していましたから、反対の声はあがりませんでした。私も異論はありませんでしたが、プロジェクトの途中で方針が変わるのは初めてのことで、今まで考えていたことを覆すのは大変でしたね。

  

  伊藤 　プロジェクトでは、そういった予想外の事態に、柔軟かつ機敏に対応することも求められるのですね。このときの方針変更は、三浦さんにとってどのようなご経験になりましたか。

  三浦　物事は理想通りにはいかないということを学んだ経験でした。開発にあたって、システム開発の方法論やドキュメントのつくり方など、いろいろと本を読んで勉強したのですが、実際には使えなかったんです。予算や納期がありますから、一般論の通りにはいかないんですね。

  けれども、ここで勉強したことは、その次のプロジェクトに活きました。70人月規模の新規システム開発のプロジェクトリーダーを務めたのですが、かなりこだわった仕事ができたんです。

  2900人月規模のプロジェクトでも痛感したことですが、システム開発で一番大切なのは、ユーザーの要求をきちんと仕様化（※）することです。これができていないと要求とは異なるものをつくってしまい、何度もやり直すことになります。ユーザーが何を求めているかを引き出し、システムで実現できるのかどうかを判断して仕様化する。このときは、それがしっかりできたんです。仕様を決めるのに時間がかりましたが、リリースを前もって延期していただくことで開発時間も確保できた。そういった調整もうまくいったプロジェクトでした。

  ※仕様化：ソフトウェアが満たすべき機能などを明確にし、「仕様書」と呼ばれる設計書にまとめること

  伊藤 　とはいえ、経験や知識、技術があるだけでは、プロジェクトを円滑に進めることは難しいのではないかと思います。このときの開発がうまくいった一番のポイントはどこにあったと思われますか。

  三浦　このときは、「いいものをつくるんだ」ということを、常にメンバーに言っていましたね。そして、開発をより安定的に行うということに非常に力を入れました。プロジェクトリーダーに求められるのは、例えば"ヒト・モノ・カネ"の調達やスケジュール管理、品質管理などいろいろなことがありますが、私が一番大事にしているのは、みんなが仕事をしやすい環境をつくることなんです。

  そのために、きちっと設計して、開発できるだけのスケジュールを確保する。進捗を常にチェックして、みんなが遠回りしないようにレールを引いてあげる。これが一番大事な役割だと思っています。

インタビュー後記

「こだわり」の深さが成長に繋がる

「どの様な仕事に対しても、強いこだわりをもつ大切さ」
今回、三浦さんへのインタビューを通じて最も学ばせて頂いたことです。

成長する人は、仕事に対して必ず強い「こだわり」を持っています。
三浦さんの場合、どのエピソードを御聞きしても、
・自分であればこうする
・もっとより良い方法はないか
・必ず完遂させる
等々、ご自身のこだわりや、執着心が垣間見えます。

また、最も注目したい点は、"仕事の大小に関わらずどのような仕事に対しても"、
ご自身で基準を高く設定していることです。

仕事の大きい／小さい、会社や上司に認められる／認められない、という線引きをせずに、
一つ一つの仕事経験を納得いくまで突き詰める姿勢に成長の源泉がある様に思います。

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

三浦さんのインタビューを通じて、思う事がもう一つあります。
それは、多くの企業は「自律型人財育成」をテーマとして掲げるものの、
「なぜ、育たないのか」という点には意識がいっていないのではないか、と言う事です。

「求める社員像」には必ずと言っていいほど、「自律的に･･･」「主体的に･･･」
と言う言葉が上がり、何かしらの形で方針に盛り込まれています。

しかしながら、現実を見れば、大方は上手くいっていません。
むしろ方針を掲げる事によって、焦点がぼやけている様にも感じます。
方針を示すことは重要ですが、見方を変えれば、これはどの企業でもできる事です。

では、実現できている企業とそうでない企業の違いは何か？
それは、「なぜ、なぜ」と現状を深く突き詰める深さの違いにあるのではないでしょうか。

・仕事を通じて社員は成長しているだろうか
・もし、成長していなければ、何がそうさせているのだろうか
・会社として十分バックアップしているだろうか
・上位者はどの様に関わっているのだろうか　･･･　･･･

成長には、本人の持っている「思い」も重要ですが、育つための環境も軽視できません。
この事を、経営陣や人財育成部門がどれだけ目を向けているか。

こう考えると、こだわり抜く深さが成長に繋がることは、
人も、企業も相違がない様に思えます。

On the Business Training 協会　海津茂史

＊続きは後編でどうぞ。
　 第五回【自律型人財－後編】仕事への信念を持って経験を積み重ねることが、成長につながる