１つの会社になるということ

勤務先の会社でグループ内の再編が行われ、大きな２つの事業会社を含む５つの会社が合併または吸収分割によって１つの会社になった。
再編の発表があってから８カ月。実際にプロジェクトが動き始めてから６カ月余り。それぞれに年月を重ねてきた複数の会社が１つになるのがどんなに大変なことか、日々思い知らされながら過ごした数カ月間だった。
僕自身は法務部門に籍を置いており、契約管理のマネジメントを行う立場であったことから、今回の再編においては契約インフラ統合を推進するポジションを与えられた。

※この記事は約5000字あります。

複数の大企業を１つにするのは想像を絶するプロジェクトだ

基盤システムの強制変更

今回の再編において、僕の立場から見た一番大きな変更点は、慣れ親しんだ基盤システムからの決別だ。
再編前の会社が設立された経緯を遡ると、もともと海外の上場企業が100％出資した日本法人というのがルーツ。そのため、親会社が開発したミドルウェアが基盤システムとして採用され、その基盤上で動く様々なシステム群が開発・導入されてきた。
これら数多くのITシステムはビジネスの根幹をなすものであり、会社としてはその恩恵を受けてきた。
かつて上場した際も、市場に売り出されたのは株式全体の３分の１程度で、親会社が３分の２を支配する構造は維持されてきた。

その潮目が大きく変わったのは３年前の経営統合。
上場は廃止され、資本関係が変化して親会社が従来とは異なる国内の上場企業になった。ただし、その時点では法人格に変化はなく、外形的に見れば単に資本関係だけが変わって別の持ち株会社の傘下に入る（子会社になる）手続きが行われたに過ぎなかった。
人事制度や組織、社内システムはほぼ変更なく維持され、現場での混乱が生じることもほとんどなかった。
恐らくそれは今回の再編に向けた前段のステップであり、急激な変更による社内の混乱を避ける狙いがあったものと推測する。いきなり合併するのは社内の動揺が激しすぎるから。
別の見方をすると、3年前の時点では言葉こそ「経営統合」というあたかも１つの組織体になったかのような響きを用いていたものの、実際のところ、事業の統合やバックオフィス部門の業務をスリムにするといった機会がほとんどないままに会社経営が続けられてきたということでもある。

（やや視点が異なるものの、前回の経営統合に関して書いた記事は以下です。よろしければお読み下さい。）

今回の再編は大きな事業会社同士の合併を伴うもので、人事制度や組織体制も１つにする大変革が必要となる。もちろん、社内システムの統合も不可欠だ。
１つの会社でありながら人事制度が２つあるということはあり得ないし、新たな会社の理念に沿って社内規程類、決裁権限基準、組織体制、給与体系、評価基準といった仕組みや決めごとはもちろん、人事システム、財務システム、決裁システム、様々なITシステム群も原則として統一される。
１万人規模の複数の法人を数カ月で１つにする再編、それは本当に想像を絶する困難なプロジェクトだ。しかし、これをやり遂げなければ会社にとって（もちろん自分にとっても）未来はない。

再編前の会社が複数のIT企業ということもあるし、もし仮にIT企業でなかったとしても、現代の会社においてはあらゆる業務において様々なITシステムが導入されており、統一のために手当てしなければならない社内システムは気が遠くなるほどたくさんある。

社内ネットワークにログインするための認証基盤から始まって、メール、チャット、スケジュール管理といったミドルウェア、ファイルストレージ、ナレッジ共有はもちろん、人事システム、各種申請やその決裁、財務経理、経費精算、法務、購買、特許、電子契約、契約書管理、委託先管理等々、数百とも数千ともいわれる重複したシステムを１つにしていかなければならない。

システムの選択

システムやツール類を統合するといっても、複数のシステムのいいとこ取りをして１つの新たなシステムを作れるわけではない。同種のシステム同士で機能比較はされるものの、結局は会社の目指す方向性にどちらがより合致するか、コストはどうか、もしくは資本関係の影響などを含めた様々な要因でどちらか一方だけが選択されていくことになる。
ITシステムはビジネスの細部にまであらゆる場面で複雑に連携して影響し合っており、１つの変更が他システムに大きな影響を及ぼすことも多い。
そのため、統一の判断には多面的な要素を考慮する必要があり、必ずしも現場の声で選ばれるわけではないし、使い勝手や機能で選ばれるわけでもない。
本来は、システム選択の前段階の作業としてどういう体系で物事を進めていくのか、その考え方から統一していく必要があるが、そこまで遡って検討することも容易ではない。
再編のデッドラインが決まっており、限られた時間の中で「最善とはいえないが現実的な落としどころ」として決定された選択も数多くあると推測する。

システム選択の結論

システムと運用の両面で検討すべき課題は山ほどあるし、考慮すべき点も数多くあるものの、実は論点はそこにはない。
結局のところ、３年前に出資元の変更があったことが恐らくは決定的なポイントだった。
結論として、かつての親会社が提供してきた基盤システムは新会社では採用されず、もう一方の法人が利用してきたシステムを軸に各種業務フローが構築されることに決まった。

契約実務で発生する諸問題から見る再編

さて、現場で契約を締結する実務を例にシステムの統一を考えてみよう。

財務経理システム

取引先と契約を結ぶには、前提として自社の経理システムにその取引先が登録されている必要がある。
では、その経理システムはどちらの会社に合わせるか。双方の会社に登録されている取引先情報は統一すべきか。するとしたらどうやって統一するか。それぞれ何万件もある取引先情報の突合と各種データのその差分をどのように確認して統一していくか。
ここを見るだけでも考えたくなくなるほどの気が滅入る話だ。

法務システム

ビジネスを担当する事業部が法務部門に対して契約の相談をしたいと考えたとき、法務相談のシステムはどちらの会社のものを使うのか。
契約書のひな形はどちらに合わせるか。秘密保持契約書（NDA）や業務委託契約書といった基本的な契約形態を取ってみても、そのひな形に落とし込まれている考え方は会社によって異なるため、細部まで見ていく必要がある。
法律上はＡでもＢでも間違いではない場合は会社として方針を定めなければならないが、これまで複数の会社で異なる経緯を踏んで整えられてきたひな形について、統一の手順については正解がない。どちらでもよいけれどどっちでもいいわけではないというジレンマが生まれる。

組織体系と決裁権限基準

契約条件が固まって契約締結の実務を進めようとしたとき、次にぶつかるのは必要な決裁手続きが何かという問題だ。そもそも決裁権限は誰が持っているのか。ここでは人事組織体系の統一化と決裁経路の明確化が不可欠となる。
どのような場合に誰の決裁が必要かが分からないと話が進まない。
どんな役職があって、それぞれがどんな決裁権限を持っているか。金額基準はいくらか。ここでも各社においてこれまでルールが改定されてきた経緯を踏まえて、大きな議論が発生する。
役職と決裁権限の話は会社の組織設計の話とリンクするし、この情報がもとになって決裁システムに繋がっていく根本的な部分なので、幅広な議論を必要とする上にステークホルダーも多く、そう簡単には進まない。
（ところで、今回の会社の話ではないが、まれに決裁権限基準が定められていないのに決裁システムが存在する会社がある。そういう会社は一体どうやって決裁ラインを決めているのだろう。考えると夜も眠れない。いや眠れる。）

組織情報と決裁権限が固まったら、それをどの決裁システムを使って決裁するのか。金銭が発生する取引であれば、どちらの会社の財務経理システムと連携させるのか。金銭の発生しない取引はどのような考え方で決裁ラインが組まれて決裁されるのか。

印章管理から契約書管理まで

決裁経路が明確化して無事決裁が完了したら、次は押印手続きだ。
会社に存在する印章は実印がすべてではない。会社にはどのような印章の種類が存在するか。それぞれの印章類はどの部門がどのように管理するのか。
押印者にどのような権限を持たせるのか。
電子契約はどのサービスを利用するのか。
会社ごとに異なる電子契約サービスを利用していた場合、いずれも継続するのか、それとも１社に集約するのか。
押印や電子契約が完了したら、契約書原本を先方と取り交わす運用はどうするか。押印部署から事業部に届けるのか、押印部署が直接取引先に発送するのか。
さらには、会社としてどのように契約書を保管・管理していくか。紙の原本は社内倉庫保管なのか外部委託なのか。業務委託に対する考え方についてもその差分をすり合わせていく必要がある。
契約書データを管理・参照可能な仕組みは何を使うか。どのように契約の期限管理をしていくか。原本回収の仕組みはどうするか。
みんな自分が正しいと信じているが、本当の正解がどこにあるかは誰も知らない。結論は現場では決まらない。

文化の違い

会社の理念が似ていても、それぞれの持つ文化は全く別のものだ。
よいか悪いかは置いておくとして、それは今回の再編で日々感じたことだった。
明確な上下関係とパワポを使って慎重に判断をしたりその根拠や裏付け資料を残すことを重視する文化と、フラットな組織と広い個人の裁量を軸に、資料はwikiで意思決定はメッセンジャーといったテキストベースで迅速に判断して事業を進めていく文化。
誤解を恐れず荒っぽくいえば、お役所とベンチャー企業ほどの差がある。

コストのかけ方にしても、ユーザに展開しているサービス部分に重点を置き社内システムは刷新コストをかけるより人手でカバーしようとするのか、それとも社内システムの使い勝手を向上させ人手の作業を極力なくすことで効率を高めようとするのかといった部分。これも全く異なる。

僕が所属していた会社では、システムでできることはシステムに任せようとする文化が会社全体に浸透していた。社内システムの構築によって極力人手を介さずに現場の運用を効率的に回せるよう改善を重ねていく。
社内システム開発と運用の現場との距離感の近さが特徴で、システムの使い勝手について改良の相談をすると適切なサイクルで目に見える改良が行われてきた。

他方、業務運用について相手方へのヒアリングでよく聞いたのは、「それは小人さんがやっている」「妖精さんがやっている」というフレーズ。
話をよく聞くと、システム間がAPI連携されていないので、ＡというシステムからＢというシステムに情報を渡す際、「人手」でデータをＡからダウンロードしてＢにアップロードしたり、コピペで手入力したりする仕事が存在するという。「それ繋げたらよくない？」と何度言ったか分からない。
コピペを容易にするためのツールが別途開発されていると聞いた。謎of謎。
「運用でカバー」という言葉もよく聞く。システム化できることをあえてシステム化せずに人力で対応するときに使われるフレーズ。
これらは僕だけではなく様々な人から同様の話を聞いたので、そういう文化でこれまで動いてきた会社なのかもしれない。
もちろん、これらの事例はある種の色眼鏡で見てしまっている可能性があり、自分の振る舞いにも気を付けていく必要がある。

ここがゴールではない

2023年10月1日。会社法上、会社組織が１つになる日。
この時点で制度上最低限の不備が起きないよう、会社をまたいだ組織間をつなぐ多くのタスクフォースが設けられ、様々な角度からもろもろの制度設計や運用の仕組みが検討され実装されてきた。
ITシステムにとどまらず、事業部門とバックオフィス部門のあらゆる領域において、誰もがそれぞれの痛みを抱えながらこの日に辿り着いた。

インフラ上は恐らく致命的なトラブルなく迎えられるだろう。
とはいえ、ここが新会社のゴールだと考えられる要素はない。
組織はツギハギ感があるし、ITシステムの移管はツール単位でいくつかの段階を踏みながら行われている。仕事の進め方ひとつ取っても、当面は各所で混乱やせめぎあいが起きることは避けられない。
組織として成熟していくには、まだまだいくつもの段階を経ていく必要がある。様子見を経てぶつかり合いと混沌のステージ。その後同じ方向に視線を合わせる局面を経てコラボレーションが生まれるレベルへの昇華に向かっていく。

これからは、選択したことを正解にしていく戦い。
変化できるものだけが生き残る。
遠慮することなく、あるべき姿がどこにあるかを追求したい。
個人的なテーマは、あきらめない、くじけない、くさらないの３つ。
やるべきことはいくらでもある。いくぞ。