何がプロジェクトの成否を分けたのか？あるいは20年後に見えた答え
先日、古河電工さんのシェアードサービスセンター立ち上げプロジェクトの20周年パーティが開かれた。
プロジェクトに関わった各社のメンバーと、シェアードサービスセンターでいまお仕事している皆さんの総勢60名ほど。自分も含めて、20年経つともちろんそれなりに老けてはいるんだけど、「その人らしさ」みたいなものは全く変わらないものですね。
僕からは「いまだから分かる、当時は分かっていなかった、このプロジェクトの成功の秘訣10選」をスピーチした。
この20年前のプロジェクトについては本も書いたし、このブログでも折に触れて書いているのだが、時が経って振り返るからこそ分かることもある。
というか、20年前のプロジェクトについて誰かが振り返ったブログをあんまり読んだことがない。ということで、11選をココでも紹介したい（スピーチでは1つ話し忘れてたのでいま足した）。
★いまだから分かる、当時ピンときてなかった成功の要因10選
①システムを作らせる技術の異様な高さ
プロジェクトをリードした僕らケンブリッジのワークスタイルは、当時の古河電工とは全く違っていた。システム基盤として選定したCOMPANYも、かなり癖があるパッケージだった（そしてワークスさんもかなり癖があるベンダーさんだ）。
でもプロジェクトを成功させるためにはそれらにうまく乗っかるのがベストだと古河電工さんは決断し、ケンブリッジ／ワークス（COMPANY）の良さを十分引き出そうとしてくれた。
これは後に僕が作った言葉で言えば、「システムを作らせる技術」が異様に高かったと言える。というか、あの本は発注者として古河電工の方々がやっていた優れた行動を念頭に書いた面もある。
これはプロジェクトをやっている最中はそこまでは意識できなかった。いい方法論を使って、僕らが頑張ったから成功した、と思っていた。でもプロジェクト後5年ほどして、僕の見えないところで様々に手を回してくれていたことに気づいた。つまり僕らは古河電工さんの手のひらの上でヒイヒイ頑張っていただけなのかもしれない。
＋＋＋参考過去ブログ＋＋＋
・普遍的な「作ってもらう技術」とは何か、あるいは建築とシステムの共通点
②生き字引のフリーマン化
プロジェクトに配属されるクライアント側のコアメンバーの人選は、プロジェクトの成否を分ける。それはどの会社も分かっていて「その業務を背負ってきた生き字引」みたいな方を配属しようと考える。でもその方がいないと今の業務が回らない。諦めざるを得ない・・。
このプロジェクトでは、それまでプロジェクト企画の中心メンバーだった方を現場の長に異動し、それまでその仕事をしていた生き字引の方をプロジェクト専任にした。
変革人材を現場に、現場ゴリゴリのベテランを変革プロジェクトに、というのは奇策だったが、結果的には決定的な成功要因になった。
この辺の経緯は数年後に本を書く際に改めて事情を取材して教えてもらったことだが、プロジェクト体制を本気で整える、という意味でこの事例に学ばなければならない会社は多いはずだ。本気度が足りない。
③要件定義の障壁防止
30年もCOBOLを継ぎ足し継ぎ足ししてきた現行システムの詳細ロジックは、当時かなりブラックボックスになっていた。どういう風に給与を計算しているのか、誰も語れない状態。前回のブログに書いた「要件定義の障壁」そのものだ。
このプロジェクトでは、僕らが業務調査やシェアードサービスセンター構想を検討している横で、先の生き字引のベテランさんやエンジニアの方を中心に、COBOLのロジック調査をしてくれていた（リバースエンジニアリング）。
これもねぇ、やっている最中は価値をそんなに理解できてなかったですよ。正直言って。何やってんのかなぁ・・という感じで。
でもこれのお陰で、いざ新システムを設計する際に圧倒的にスムーズに進んだ。僕がその価値を理解したのは、「要件定義の障壁」という言葉で課題定義した10年後だった・・。
＋＋＋参考過去ブログ＋＋＋
・要件定義の障壁。あるいはビジネスロジックの複雑さが招くプロジェクトの悲劇
④管理項目の整理統合
BPR（業務改革）というと、業務の手順や役割分担を変えて効率化を目指す、という姿をイメージする人が多いだろう。
でもそれ以上に「管理項目の適正化」がパワフルなケースは多い。
古河電工の場合、工場ごとに給与項目がバラバラだった。
例えば・・
日光の寮社宅関係の給与項目は「日光変動電気代」「日光固定電気代」「日光クリーニング控除」など30種類。千葉は「千葉電気代」など別途13種類・・みたいな感じで。
これを関連会社含めて全て整理統合した。具体的には、当時の給与担当の方が全国の工場と電話で交渉しまくって、どこも困らない、でもシンプルなToBe項目を作り上げてくれた。
この辺も、当時の僕はあんまりマネージできてなくて、気づいていたらコツコツとやってくれていた。そして後からこれがいかに大事なことだったのかを実感した。これによってシステム構築も楽になったし、シェアードサービスセンターでまとめて業務を面倒見ることができるようになったからだ。
（逆に、管理項目がバラバラなままだと、仕事の手順が同じになっても全然効率化できない）
⑤抵抗勢力防止
人事システムは全社員がユーザーであり、影響を受ける。業務のやり方が代わること（例えば自分の工場に詳しい人がいなくなり、気軽にお願いできなくなる）も、全社員が影響を受ける。これは「変革の抵抗勢力」がとても生まれやすい状況だ。
このあたりの社内説明、社内調整は古河電工のリーダー、副リーダーが顔の広さと人徳とフットワークの良さで未然に防いでくれていた。
当時の僕は、お二人があまりに全国を飛び回っているので、「プロジェクトの意思決定が滞って困るなぁ」と嘆いていた。
その後色々と経験し（泣）、日本企業で変革をやるには必要なことだったと思うに至った。
⑥データ移行やI/Fをなんとかした
大きなシステムの再構築では、データ移行やI/F（インターフェースプログラム）構築でつまずくことがかなり多い。エンジニアに任せっぱなしではうまくいかないので、「システムを作らせる技術」でも1章を割いて説明した。
だがこのプロジェクトの時は若輩者過ぎて、その大変さをきちんと理解していなかった。
実際には、この2つの仕事は
・新システムと旧システムや周辺システムの両方の知識が必要
・システムと業務の両方の知識が必要
・関係者が多く、コミュニケーションスキルが必要
という、難しい仕事なのだ。
そしてこのプロジェクトの場合、
・BPRの一貫で、全てのコード体系やデータの持ち方を大きく変えた
・現行システムや周辺システムがCOBOLベースの古いものだった
・現行システムや周辺システムは全国の工場に散在
という三重苦もあり、さらに難易度が高くなっていた。
これらは情報システム子会社のFITECさんが担ってくれていたが、彼らの頑張りを正当に認識したのも、他のプロジェクトで苦労した後だった・・。
⑦方針の一貫性
プロジェクト立ち上げ段階で多くの方針を決め、愚直に遂行したことが、作った業務基盤が20年たっても使えている大きな要因だと思う。今思えば。
だが、プロジェクトの最中はあまりにしんどくて、その方針を妥協したくなったことも何度かあった。
例えば社員番号。
それまでは、転籍や出向の度に新たな社員番号が振られていた。これを「1人格1社員番号の原則」を忠実に守ることにした。そうすれば、出向しようが再雇用しようがその人の経歴をずっと追っかけられるし、データ件数＝社員数なので、統計を取る際に便利だからだ。（逆に言えば、この原則を蔑ろにすると、当たり前の情報を得るのに苦労する羽目になる）
それは良いのだが、数人だけ特殊な待遇の社員さんがいて、その方々の給与計算や出向費用の計算を自動化するため「1人格1社員番号の原則」を崩すのはやむなし、という結論に達した。（詳細は忘れてしまったのだが）
それを会議で報告したところ、先に書いた「生き字引的なベテラン」に怒られてしまった。
「1人格1社員番号の原則は、白川さんがこだわって決めた方針でしょう、こんなことくらいでその看板を下ろすんですか？こういうことが"蟻のひと穴"となって、良いシステムが崩れていくんじゃないですか！」と。
今となれば些細なエピソードではある。
だがこのプロジェクトでは、会社の垣根を超えてガチンコの議論をしながら、ちょっとでも良いものを作りたい、とみんなが思っていた。
長持ちするシステムって、こういう細部が大事なんですよね。
⑧現場の非現代的な粘り
⑥で書いたFITECさんもそうなのだが、このプロジェクトに参加した人々の責任感、粘り強さ、そしてその結果としての残業の多さは半端なかった。
本社のプロジェクトコアメンバーはもちろん、各工場で発生した課題（現地の業務に合わないとか、プログラムバグがあるなど）を潰すのに奔走してくれた方々が、全国にいた。
この20年間で世の中がずいぶんホワイト化して、いまこのプロジェクトを横から観察したら、ブラック過ぎてドン引きされると思う。そういう意味で20年前の仕事っぷりは「非現代的」だと思う。その責任の多くはプロジェクトマネージャーをしていた僕にあるので、申し訳なく思う。
が、「なんとかこのプロジェクトを成功させたい」とみんなが思っていたこと自体は、尊いことだった。
そして20年後に「あん時は大変だったなぁ」と酒を飲み交わしている。いいとか悪いとかではなく、大変な思いをして成し遂げた仕事こそ、本当に思い出に残り、参加者にとってその後の糧となったりする。先日のパーティでも何人もの方が「あのプロジェクトはその後の自分にとってとても大きかった」とおっしゃっていた。
もう1回やれと言われたら嫌だけど。
⑨COMPANYの製品コンセプトは本当だった
古河電工の皆さんと人事パッケージを選定したのだが、当時COMPANYはいまほどデファクトスタンダードという感じではなかった。
COMPANYを提供しているワークス社は「永続的にバージョンアップできるERPを提供することで、日本企業のシステム投資を抑制する！」みたいな、耳障りのよいメッセージを謳っていた。
選定した僕らはそれに共感しながらも、どこか胡散臭さも感じていた。
だが結果として、古河電工さんは20年たったいまでも当時作ったCOMPANYを使い続けている。もちろん改修もしているし、たまに必要なバージョンアップには苦労している。
でも同じ頃に他のパッケージを選んだ会社は、20年の間にもう1回や2回はシステム再構築プロジェクトを（苦労しながら）やっている。
システム導入プロジェクトはお金と社員の時間を大量に消費するので、やらないに越したことはない。だから20年使い続けている、ということ自体が経営面での達成と言える。
⑩連結経営の基盤
どこかに書いたことがあるが、古河電工グループの連結経営へのインパクトが、当初考えていたよりずっとあった、という話。
このプロジェクトの成果として、グループの関係会社30社以上の仕事を集約することができた。業務的にはシェアードサービスセンターが各社の仕事を請け負ったし、システム的には一つのドラム缶でグループ全員を管理できるようになっている。
全てを一元管理できていると、会社の統廃合などが非常にスピーディかつ低コストで出来た。（例えば本社の事業部と、関係会社が合併して新会社を作る際）これは変化が激しい経営環境、そして古河電工のようなコングロマリットでは極めて重要なことだ。
そういう金額換算しにくい価値を実感したのは、プロジェクトが終わって数年経ち、いくつかの再編を経験した後だった。
⑪終わらないプロジェクト
数年前（プロジェクトが終わってから10年後くらい）に、他のお客さんを引率して古河電工さんのシェアードサービスセンターを訪問した。
いやあ、びっくりしましたね。僕が関わっていた頃に比べてすごく進化していたので。コロナ禍の時だって、全国各地のご自宅から人事業務をバリバリやっていた。もともと全国の工場の仕事をリモートで請け負っていたので、当然だ。
プロジェクトの3年後に、業務が40%効率化したところまでは測定したのだが、いまはもっと効率化しているはずだ。
何が言いたいかと言うと、プロジェクトで大騒ぎして変革をして、それでおしまい、というのはもったいないという話。そうではなく、プロジェクトで身につけた変革マインドを忘れず、不断の改良を続けると、こんなすごいことになるんだと、しみじみ思いましたね。
これも20年たったからこそ、その価値が実感できた。
＋＋＋参考過去ブログ＋＋＋
・Withコロナ、Afterコロナの2つの論点。あるいは中長期的に僕らの仕事はどう変わるのか？
ということで、11個もあるので結構長くなってしまった。
20年という異例に長いスパンで振り返ると、プロジェクトの成否を分けたのは何だったのか？そもそもあのプロジェクトは成功だったのか？ということについて、考え込んでしまう。
＋＋＋参考過去ブログ＋＋＋
・プロジェクトの成否はどこで分かれるのか？あるいはQCD教から離脱しませんか