野村総合研究所はプロジェクトマネジメント力に定評があります。 中に入ってからのキャリアは選択肢があるように見えてありません。
NRI デジタルや NRI 福岡などの一部の部署を除いて全員がプロジェクトマネージャーを目指します。
昇進のアピールでも、以下のようなシステム規模の報告がメインです。
- ○○MM のプロジェクトを管理した
- ○○MM のプロジェクトを計画通り遂行した
- 障害件数を ○○ 件以下にした
社内の人材が PM ばかりなので、PM の評価しかできないのです。 PM しか評価されないから、PM しか育ちません。
それはそれで OK です。
社外からの評価や転職市場で期待されるのも PM としての役割です。 ほとんどの人は、転職活動では「プロジェクトマネージャー」で応募することになります。
NRI の PM に転職するために必要な資格とは？評価されるのは何？
IPA の高度情報処理試験は NRI 社内では評価されます。 社内には稀に「IPA の試験を全部制覇した」みたいな人もいます。努力の方向性を間違った面白い人達です。
どれか 1 つ取るならプロジェクトマネージャ試験(PM)が良いでしょう。
PMP 試験も評価されやすいです。認定 PM と呼ばれる人たちはだいたい、PMP を取得しています。
最近は NRI 社内でもアジャイルにチャレンジしようという風潮があるので、スクラムアライアンス認定スクラムマスターを取っておくと目を引くでしょう。
資格が役に立つかは置いておいて、資格を取っておけば少なくとも野村総合研究所の社内では錯覚資産となります。
「認定 PM」になれば社内で一目置かれるが、社外では別に評価されない
NRI には「認定 PM」と呼ばれる認定制度があります。
認定されると楯がもらえます。社内で表彰され、社内共有システムで紹介されます。
社内資格制度で社員の自律的なスキルアップを促す｜野村総合研究所における社内資格制度の作り方
部署に 1 人くらい、優秀な人が推薦されます。 優秀な人とは、しっかり仕事をした人です。 しっかり仕事するとは、NRI の社内標準に則って、ちゃんと残業して、プロジェクトを完遂させて、周りから信頼されることです。
しっかり仕事を続けていると、たまに推薦されて、たまに認定 PM になります。
認定 PM の資格に何の意味があるのかはわかりませんが、たしかに認定 PM とされている人は頼りになる人が多かったです。
NRI では技術スキルよりもドメイン知識が圧倒的に重要です。
「業務に詳しいこと」が最大の武器なのです。
ある程度ネームバリューがあるプロジェクト内で、業務にとても詳しく、業務に詳しいがゆえに「ネームバリューがあるプロジェクト」のマネージャーを任されることで認定 PM の道が開けます。
とにかく業務に詳しくなりましょう。
アジャイルの取り組みは NRI では主流にならない
2017 年頃から NRI 社内でも「アジャイルやろう」という風潮が高まってきています。 とはいえ、NRI 社員の姿勢やスキルセット、カルチャー・評価制度はアジャイルと全くマッチしないので、アジャイルが主流になる可能性はほぼありません。
私も転職してアジャイルプロジェクトをいくつか経験しましたが、上から計画の締め切りを設定されて、いちいち報告が必要なプロジェクトの場合、わざわざアジャイルしなくてもいいんじゃないの、という結論に達しています。
NRI では無理にアジャイルをやらなくてもいいと思いますし、会社のやり方と合わないでしょう。
NRI のプロジェクトマネージャーには説明力が求められる
プロジェクトマネージャーの一つ前、プロジェクトリーダーと呼ばれる小さなチームリーダーの頃から、NRI では常に、見積もり、計画し、報告する作業があります。
単なるPJ管理手法としてではなく、『ウォーターフォールの概念は仕事の基本』なので、WFを馬鹿にする人は仕事の仕方に問題あるんじゃないかなぁ🤔
— Henry (@HighWiz) March 3, 2023
計画立てられる？
リスクを想定して取り除きながら進められる？
それらを第三者に説明できる？
『やってみないとわかりません』とか言わない？
このツイ主のような考え方の人がほとんどで、リスクを想定して対策を立てろ、と口酸っぱく言われます。
そして、リスクを想定する力があればプロジェクトはしっかり計画通りに進むと信じられています。なので、リスクを想定し、プロジェクト管理の経験を積んだ年配の方々に計画を「レビュー」されます。 細々と計画にダメ出しされるのです。
想像力の欠如よね。
— Henry (@HighWiz) March 3, 2023
数ヶ月もの時間をかけて必死に見積もり、計画を立て、偉い人に囲まれてレビューを受け、いざプロジェクトが始まると、だいたい計画は外れます（笑）
少なくとも 1 日 8 時間の労働で計画通りに進むプロジェクトは 1%もありません。全部外れます。
見積もっても外れるので、ベロシティを測っていかなければいけないのですが、まぁそういう考え方は SIer には浸透しないでしょう。
NRI の PM の技術的な知識レベルは高くない
NRI の PM は「プロジェクトマネジメントの専門家」であって、技術の専門家ではありません。
ものすごく頭が良さそうなイメージはあるかもしれませんが、人にはそれぞれ専門領域があって、専門領域を外れると素人です。
バスケットボールの神様と言われていたマイケル・ジョーダンが野球ではパッとしなかったように、一流の PM が技術者として優れているわけではありません。
具体例を見てみましょう。
野村総合研究所の社内で「PM の神様」と崇拝されていたのが室脇慶彦 理事（2016 年時点）です。 室脇さんが作ったプロジェクトマネジメントの教本のようなものが聖典（バイブル）とされ、社内の多くの PM が室脇さんの思想を受け継いでいます。
大前提として、室脇さんは社内に多大なる利益をもたらした貢献者であり、その実績は疑いようがありません。
理事は一流の PM だった人です。
正直おすすめはしませんが、NRI にガチで入社したい人は、面接前に室脇理事の本を読んでおくといいでしょう。 NRI に入れば書籍代は軽く取り返せます。
NRI はある程度の年次を過ぎると PM 研修みたいな研修を受けます。
多くの人は室脇理事の経験則を「PM のバイブル」としているので、室脇本を読んでおけば、面接のウケが確実に良くなります。NRI に入社する目的以外では読む必要ないです。
ちなみに室脇さんは「技術者」としての知識レベルはそれほど高くはありません。それでいいんです。
室脇さんの著書ではよく「オブジェクト指向」について触れられていますが「わかってるんだかわかってないんだか微妙だなぁ...」という印象を受けます。
たとえば、以下の文章です。
そんな IT 技術者に依存する IT システムが、攻めの経営を妨げ始める。IT 費用の 7 ～ 8 割が保守・維持に割かれているからだ。 こうした問題解決策の 1 つが、オブジェクト指向の活用にある。 しかも、クラウドの普及がその活用を加速させる。独立したソフト部品を組み合わせて作るシステムは、各々の部品が機能強化されても周りに影響を与えない。密結合のシステムはソフトのバージョンアップのたびにテストに多大な時間をかけるのに対して、オブジェクト指向などによる疎結合のシステムのテストは限定される。 事前の影響調査もいらないので、機能強化が容易に行える。作ったシステムは、部品の機能強化や交換にとって継続的に改善・改良していける。 再編・淘汰を促すオブジェクト指向の到来
「オブジェクト指向の活用」が具体的に何を指すのかがよくわかりません。 上の文章だけ読むと、React のようなコンポーネント志向のライブラリを指しているようにも見えます。
「オブジェクト指向の活用」だけ考えると、Java や Ruby で作られたシステムは基本的に「オブジェクト指向を活用」していますが、レガシーな Ruby on Rails に悩まされている会社が山ほどあるのを考えると、オブジェクト指向を活用（笑）したからといって生産性が劇的に上がるわけではないのは火を見るより明らかです。
また、クラウドの普及とオブジェクト指向の活用は本質的には別問題です。 オブジェクト指向とマイクロサービスをごちゃまぜにしているように見えます。
「各々の部品が機能強化されても周りに影響を与えない」というのはちょっと言い過ぎです。 「あるドメインオブジェクトを変更しても、他のドメインオブジェクトには影響が及ばない」くらいに留めておくのが正しい表現かと思われます。
依存関係が存在しないシステムはありません。 それぞれの部品の影響を極力小さくするために、設計を工夫するのです。
オブジェクト指向で作るのは大前提であって、どうオブジェクト指向で設計していくかの方が大事なのです。
小さなドメインオブジェクトを組み合わせて「顧客」「商品」「注文」などの、より大きな業務の関心事を表現するクラスを設計する...というのはオブジェクト指向での設計の常套手段ですが、それを「オブジェクト指向を活用すればいい感じになるんや！」と言うのは少々雑ではないでしょうか。
理事は何やらオブジェクト指向が銀の弾丸のように感じているようです。 COBOL や C 言語のような、手続き型の時代の人だから仕方ないのかもしれませんが、現代の感覚とは少しずれがあります。
「事前の影響調査もいらないので、機能強化が容易に行える」などという発言はさすがに誤りです。 事前の影響調査にものすごく時間がかかります。
「オブジェクト指向を活用して」作られた大規模な Ruby on Rails のコードを読んでみてください。 地獄が広がっています。
事前の影響調査に死ぬほど時間がかかります。
NRI で動的型付け言語を使う機会はないかと思われますが、オブジェクト指向でも影響調査は必要です。
「密結合のシステムはソフトのバージョンアップのたびにテストに多大な時間をかける」とありますが、単体テストは基本的に自動化しましょう。
時間がかかるのは結合テストです。密結合だと、影響範囲がわからなくなってテストに時間がかかるのは同意です。 オブジェクト指向でも密結合なシステムになります。密結合か疎結合かにオブジェクト指向は関係ないです。
理事！エリック・エヴァンスのドメイン駆動設計を読みましょう！
話は変わりますが、おそらくは若手の社内技術者なら理解しているであろう基本的な内容を社内で誰も指摘しないのは問題です。
NRI には「偉い人が言うから正しい」とされてしまう社風があります。
何を言うかよりも誰が言うかを重視する風潮は是正すべきです。
誤りは恥ではありません。誤りを指摘するのは正しいことです。
間違っていたら、次から勉強して、「あのときは間違っていた。勉強して理解した。正しくはこうだった」と訂正すればいいんです。
指摘するときは、「なんでわかってないんや...」と馬鹿にするのではなく、「より良い方向に導くつもりで」指摘しましょう。
NRI ではモダンなプログラミングスキルは身につかない
NRI でモダンな開発スキルを身につけるのは無理です。 99%の人が無理です。
モダンな開発をしているつもりになっても、おそらく時代遅れです。
一部の部署ではハッカソンなどが積極的に行われていて、若手はもしかしたら独学で割と今風のスキルを身に付けているかもしれません。
しかしながら、実際の業務では「現行仕様」の壁が立ちはだかります。
担当するのは 1990 年代に作られた化石のようなシステムなのです。
Git の使い方も知らないプロジェクトマネージャーが ZIP ファイルでソースコードを管理するように指示してきます。
プログラミング言語は Java 一択です。JSP でユーザーインターフェースを作っていきます。
今やオワコンとなった AngularJS（Angular ではない）で画面を作っているプロジェクトも多数あります。
React や Vue を使っているプロジェクトは見たことがありません。
AWS を専門に扱っていた部署がありましたが、なぜか世の中のトレンドに全くかすりもしない Oracle Cloud の利用が推奨されています。
Oracle Cloud なんて知っていてもエンジニアの市場価値は上がりません。使っている会社がないからです。
パソコンは Windows の 4GB のレッツノートです。
しょぼいパソコンから、さらにしょぼいシンクライアント環境をリモートデスクトップで開き、そこで Excel をいじっています。
こんな環境でモダンスキルを身につけるのは不可能です。黙ってプロジェクトマネジメントに集中しましょう。
NRI に入社したなら、抵抗せずにプロマネに専念するのが正しいキャリアの選び方です。
「新しい技術に触れたい」「手を動かしたい」「物を作りたい」という願望は、NRI の業務においては邪魔になります。
手を動かしている人はサボっているとみなされるからです。手を動かしたいなら転職しましょう。
ちなみに NRI を辞めたい人は、転職サイトに登録しておくと、思った以上に年収が高い求人をもらえるので驚くはずです。 ぜひ転職活動を始めてみてください。