かつてERPパッケージソフトの導入プロジェクトは、大規模な人数かつ長期間にわたって行われていました。これはもう過去の遺物かと思っていたのですが、どうも今でも残っているようです。
いわゆる「デスマーチ」ともよばれる長時間かつ過酷な労働状況で、最近注目されている「働き方改革」という残業時間の見直しとは完全に逆行しています。なぜこんなことが起こっているのかを、若干抽象化した実体験もふまえてのべたいと思います。
資料作成量が膨大
リスク管理のためなのか、とにかく作成すべき資料の種類と量が多いです。例えば、議事録。ベンダーが作成し、それを内部でレビューした後、客側でレビューして修正事項を指摘して、それを再度ベンダーが修正して・・・という「ラリー」を2，3回行って終了。当初のミーティング時から3週間くらいは経過しています。ミーティングが週に3－4回あったとしたら、それだけでもかなりの作業量です。
他にも、ミーティングのために事前に送付する資料も、当日投影する資料だけではなく、どういうことを聞きたいのかを詳細に質問事項として記載した一覧も添付していました。要は、具体的に何をきかれるのかを事前に明確にしておかないと何も答えられないと・・・。
自分が担当している業務のことなら、普通はその場である程度こたえられるものじゃなくて？
私はそう思うのですが、どうやらそうではないようです（笑）・・・。
管理のための管理
元請けのベンダーの下に2次受け、3次受けの会社がついているため、その管理のための物的証拠としての「内部文書」が必要以上に多いと思いました。例えば、レビューをした際のレビュー指摘事項を羅列し、それに対してどう対処したのかを一覧化する必要があります。これは、客からのレビューだけではなく、元請けが2次受け・3次受けに行なう「内部レビュー」も含まれます。
その「レビュー指摘事項一覧」を完成させてから、該当の成果物などの修正を行うことになります。「レビュー指摘事項一覧」は品質管理のために存在しているらしいのですが、それを作成する時間があるならば、実際の成果物を修正する方に集中した方が品質管理の観点では効果があると思うのは、私だけでしょうか（笑）？
これとは真逆の状況もあるようです。アクセンチュアについての記事を最近、拝見しました。アクセンチュアが、徹底的な「自前主義」をとっていると記載されています。
外部のベンダーに委託するとシステム開発作業の進捗や成果物の品質を管理しづらくなる。内製でプロジェクト管理を徹底し、失敗を減らして利益率を高める。
まさに、この指摘どおりです。下請け構造だと「管理のための管理」のタスクが多いと思います。さらに、突然降ってくる「管理のための管理」タスクは、プロジェクトのゴールとどうつながっているのかが全く不明というものがチラホラあります。そして、それに対して建設的な質問や意見を言わない/言えない環境が、（諸々の事情で）既にできあがっています・・・。
（やはり）客が丸投げ
これが一番大きいかと。
客側で調整すべきことが、まったくなされないことがあります。例えば、ある業務フローに対して、A部門は「帳票出力は、今後はB部門が担当のタスクなので、そのように修正してほしい」と指摘があったので、そのように修正すると、今度はB部門から「帳票出力はB部門とは決まっていないので、現行通りA部門と修正してくれ」といった指摘をされるといった具合。
こういうことは、社内で調整する以外に解決策は無いし、そもそも、ミーティング時には「今後はB部門で行う」という結論が出て、その旨を記載した議事録も承認していませんでしたっけ？
って思うわけです。客側でとりまとめる担当はアサインされているものの、実態は単なる「左から右に動かすだけ」のような存在。
たしかにプロジェクト費用を支払っているとはいえ、客側が丸投げしてはどんなプロジェクトも成功しません。
リスクをベンダー側だけに負わせようとする行動は、一見リスクを回避しているようで、最終的には自社に戻ってくるというのは、いろんな会社で立証されています・・・。「業務のやり方」にばかり固執しないで、それを使って何をするのかという「本質」が置いて行かれています。
こんなデスマーチは百害あって一利なしでしょう。やはり、本質を見据えてHR Techをうまく使いこなした業務設計をやってみたいと思います。もし、そういうことを検討されている企業がおりましたら、ご連絡を！
