人材価値を上げるために必要な３つの視点（ヒト・モノ・カネ）

前回記事では上流工程に引き上げてもらうことが、IT技術者にとっての年収アップの道だという話でしたね。

そうだ。フリーランスなどで既に十分な収益を得ている人ならともかく、一般的なSIer系会社勤めのシステムエンジニア（多くは平凡な人）であれば上流工程を目指すのが年収アップの道だ。何故なら上流工程ほど人材としての希少価値が上がるので、単価が上がりやすく、したがって年収が上がるのだ。

そんなにうまくいくでしょうか。

上流工程を任されてしばらく経ったのに年収が据え置かれた、という人は転職を視野に入れた方がいい。上流工程の経験は履歴書に書ける。上流工程経験者としての単価で売れる人材となるので、条件面も当然有利となる。

募集する側は、履歴書の経験により判断する（っていうかそれ以外の判断材料が乏しい）から、自分のキャリアを履歴書にどう書くかは常に意識した方がいいな。

なるほど。そうしたら、次は上流工程を任されるためには具体的にどういうことをしたら良いか知りたいです。
要件定義や基本設計をこなすためには、システムだけじゃなくてビジネス（業務）的な視点も必要なんですよね？

その通りだ。

ビジネス的な視点も持っているということを、リーダーや上流工程の担当者に示すにはどうしたら良いでしょうか。

良い質問だ。これは非常にわかりやすい解があるぞ。
それは「ヒト・モノ・カネ」の視点を持って話すことだ。

おー、どういうことでしょう。

ところでペンちゃん、ERPっていう単語を聞いたことあるかい？

あ、ぼく聞いたことありますよ。ぼくの会社ではERPソフト事業部という部署があって、知り合いが何人かいますし、たまに開発支援に入ったりします。

なるほど。ちなみに、どういうことをやっている部署だ？

えーと、なんかすごく高い外国のERPパッケージソフトを顧客企業に導入したり運用保守したりしています。ソフトの規模もめちゃくちゃ大きくて、顧客企業のあらゆる部門の業務に対応した機能を持っています。

主なソフトはSAP、Oracle ERP Cloud、Microsoft Dynamics 365など海外勢が強いが、OBIC7など純国産のものもある。

自社に何が入っているか、確認してみるといいかもだ。

パッケージソフトってたくさんあるんですね。

そうだ。それとは逆にスクラッチ開発というものもあり、顧客企業の要望に合わせて1からシステムを構築していく。

一般的なシステム開発のイメージはこっちだろう。

ぼくの部署の主な仕事はそれですね。

しかし、個々の業務に合わせたシステム構築に陥りやすく、そのようなものを「部分最適」と呼ぶ。

部分最適が集まった時、全体としてちゃんと機能するかというと、実はそうではない。データ構造があまりにも違いすぎて、受注と生産システム間で連携が取れない、連携しているけどバッチ処理なので一日遅れ、なんてことがよくある。

企業を一つの生き物として考えた時に、個々の臓器が連携できていないとするとどうだろうか？

ああ、たしかにうまく機能しないですね。
無理に繋げたら、あちこちツギハギだらけになるイメージですね。

フランケンシュタインみたいです。

一方、ERPパッケージというのは、最初から「全体最適」を目指してデザインされている。各業務の細かい要求には応えられないが、データ構造が共通化されており、全体として整然とリアルタイムに連携できるというわけだ。

なるほど。ところでERPを知ってるかどうかって質問でしたね。
質問の意図を教えてもらえますか。

そうだな。ERPって何の略かわかるか？

ええーと、なんだっけ～……。

一般的な日本人のエンジニアは返答に窮する事が多いが、大事なことだからしっかり覚えておこう。
答えは「Enterprise Resource Planning」だ。

日本語にすると経営資源計画、ですか。

そうだ。経営資源とは何かを知っているか？

ぴんと来ませんね。

「ヒト・モノ・カネ」といった企業活動の源泉となるものを経営資源という。

そして経営資源計画とは、それら「ヒト・モノ・カネ」を効率的に運用していくということだ。

そのためのソフトがERPパッケージソフトというわけだな。

はえ～。

ERPソフトを例に話してみたが、ここで言えることは、「ヒト・モノ・カネ」の視点で語るとき、それは自ずとビジネスの視点から語っているということになるのだ。

なるほど、ぼく話が見えてきましたよ。
上流工程、つまり要件定義と設計の工程っていうのは、お客さんから業務を聞き出して、それを支援するためのシステムにどう落とし込むかを考える工程です。つまり、上流工程担当者は企業活動＝「ヒト・モノ・カネ」の視点で仕事をしつつ、それをシステム化するということをしているんですね。

明察だ。上流工程の担当者の視点を持つということは「ヒト・モノ・カネ」の視点を持つということだな。
そして、その視点を持っていると感じさせることが出来れば、自ずと「上流工程を担当してみないか？」という声がかかるわけだ。

結局「ヒト・モノ・カネ」の視点って具体的にどういうことを意識したらいいんでしょうか。

まずは基本的な企業活動のモデルを意識することだ。
どこの企業も、営業部があり、生産管理部があり（製造業の場合）、購買調達部がある。

この図は？

非常に基本的な企業活動のモデルだ。
おもにロジスティクスの面を記載した図だが、企業活動とは要するに
仕入先から調達し、加工（付加価値を付ける）し、得意先に売るということを行っている。

なるほど。買って造って売って利益を出すのが会社ですからね。

そうだ。そして、上流工程の担当者と話すときは、常にこの図を意識しながら「いまこの人はどこの話をしているのか？」ということを考えるんだ。まず全体が理解できてないと、その中の一部分の話になった時にも理解できないからだ。

たしかに細かい話や用語が出た時、全体がわかってないと、どんどん混乱してしまいますよね。

その通り。例えば、生産の部分をさらに細分化すると、計画生産とか、受注生産といった生産方式の分類や、プロセス加工や組立加工といった加工形態の分類などがある。
そしてシステム構築は「計画生産機能」とか「受注生産機能」、「組立加工管理機能」や「プロセス加工管理機能」などといった、部分ごとに細分化しながら各機能開発を進めることになる。

なるほど！
ぼくらプログラマーは、そういった細分化されつくした末端のところを実装することになるので、結果的にその機能が全体の中でどういう役割と目的を持つか、モノやどこから来てどこへ行くのかっていう全体のフローが意識しづらいわけですね。

そういうことだ。それがわかれば、あとは各業務領域の知識について掘り下げて行けばいい。

全体がわかっていて、かつ、いずれかの領域の専門知識があれば、怖いものなしですね。

そうだ。全体をイメージすること、全体感を持つことは、マネージャーやプロジェクトリーダーを任される上でも重要だ。

いずれにしても年収アップの礎となるわけだな。

ところで、上の図で「仕訳」って書いてあるのは何ですか。

良い所に気付いたな。
これは「カネ」の流れを表現するための記述方式だ。
会社の財産が増減するとき、必ずこの仕訳というものを行う。

おー、カネの流れ！？

例えば、【原料/債務】というのは、仕入先から原料を購入したので、
会社に「原料」という棚卸資産が増えたことを意味する。
同時に、購入をしたことにより仕入先への支払義務が発生したので
「原料」を得ると同時に「債務」が立ったというわけだ。

うーん、左右に記述する意味がよくわかりません。

会計知識についてはまた別途教えよう。

複式簿記においては、このように会社の資産、債務、純資産、費用、収益の増減を記録することで、最終的にその期ごとにどれだけ儲けたか/損したか（損益計算書）、その会社の財政状態はどうか（貸借対照表）という報告等が可能となる。企業会計の原則だ。

これが簿記ってやつなんですね。

でもなんか難しそう。

たしかに簿記や財務会計の論点は難しいものが多数あるが、まずは大まかな原則を押さえるだけでいい。「会計的な考え方をきちんと踏まえているか」は、「ヒト・モノ・カネ」の視点で語れるかどうかに大きくかかわっている。

そうなんですね。たまに会社でも、簿記を勉強した方が良いぞって話を聞きます。

勉強した方がいいどころか、一流のビジネスマンにとっては必須科目だ。

「経理部でもないんだから、必要ないだろ（笑）」と斜に構える人もたまに見かけるが、世界中のあらゆる企業が従う【企業会計の原則】という言葉を甘く見ない方がいい。

様々なビジネスのレイヤーにおいて会計の考え方は根を張っており、会計を知ることで初めてビジネスを理解できる、と言っても過言ではない。

とても大事なものということはわかりました。

会計の勉強は「ヒト・モノ・カネ」の視点を持つうえで、非常に言い取っ掛かりにもなる。社内で使われる言葉も、会計用語から来ているものも多いしな。言葉の意味が分かれば世界が広がる。
そんなわけで、今回はいったんここまでにしよう。

ちょっと簿記も勉強してみようかなって思い始めました。
ありがとうございました。