この度、「CorpTech Lounge」という勉強会を主催しましたので、記念すべき第一回のレポートを書かせて頂きます。

CorpTech Loungeとは？

CorpTech Loungeは「カイシャの成長を支える技術」をテーマにした勉強会です。
会社の成長を支える屋台骨はコーポレート部門であり、様々な複雑かつ重要な課題を抱えています。それらの課題を「テクノロジーをもって解決していきましょう」という観点で様々な企業に登壇頂くスタイルになっています。

第一回は50名ほど参加していただき、大盛況に終わりました。

登壇者

第一回は以下の三名に登壇頂きました

・クックパッド株式会社 コーポレートエンジニア部 部長 中野 仁 さん
・Sansan株式会社 人事部 高橋 洸（たける） さん
・株式会社メルカリ Corporate Solutions Engineering Team マネージャー 衣川 憲治 さん

「世界でつかえるシステムをつくる」 クックパッド 中野 仁 さん

記念すべき第一回、一人目の発表社はクックパッド株式会社の中野さんにお願いしました。

情シス界隈の方はご存知の方も多いと思いますが、中野さんはなんと言っても「5並列プロジェクト」が有名です。

中野さん曰く実際は「7並列だった」とのことですが、分散と分断が進んでいたクックパッド社の情報システムをグローバルなデファクトスタンダードとなっている各種SaaSのシステムに統合したプロジェクトです。

クックパッド社は当時既に海外に展開しており、海外の様々な企業の買収や、国内事業の統廃合、新規事業立ち上げ、によって組織が「ドラスティックな変化を伴い成長している状態」だったそうです。

当然、それを支えるコーポレート部門やシステムもそれに対応するため大幅刷新を迫られることになります。

日本のITベンチャーには特にありがちですが、当時のクックパッド社もコーポレート部門の各業務まで含めた社内システムを広く戦略的に統括する横串の組織が無く、各部門が「自分たちの業務にとって使いやすい最適なサービス」をそれぞれの予算のもとで導入した結果上記のような個別最適化した社内システムになっていたそうです。

このようなシステムになると一体何が起こるかというと、「組織とプロセスの分散と分断」が起こります

私も過去に経験があるのですが、分かりやすい例でいうと「オレオレ社員マスタ」が複数の部門で乱立します。

本来「一人の従業員」に対して「一意のID」が存在し、それをキーとして様々な情報（所有するPC、社員番号、人事制度の適用履歴、ジョブグレード、給与情報、経費清算、etc...）を取得出来るべきなのですが、各部門で個別最適した結果、以下のように「各々の業務に特化したマスタ」が出来上がるのです。

各部門では同じような工数をかけてマスタを手作業でメンテし、手作業で連携することになります。
人事部のあるチームでは社内制度の管理シートが存在し、総務部門にはドアセキュリティカードの管理シートが存在し、情報システム部門にはPCやスマホの管理シートが存在するイメーです。
正しく設計と統合ができていれば、一つのマスタだけを管理すれば良いので、多大な人件費が失われていることが分かるかと思います。

こういったシステムの元で、グローバル化や他拠点化が進むと、業務プロセスの分断を生むことにも繋がります。

そこでクックパッド社では「分散と分断」から「統合と連携」を目指すことになるのです。

これを行うにはAPIやSSOを利用した徹底したシステム連携が必要ですし、海外でも使えることが重要になってきます。ここから導き出される解としてグローバルなデファクトスタンダードのシステムを組み合わせることが考えられます。その結果生まれたのが以下のような形だそうです。

システム連携基盤が一意のデータを持ち、そこから各部門が必要な情報だけを引っ張り出して利用する形に様変わりしていることが分かります。ダブルメンテや手作業による連携がなくなり、頻繁な組織変更や急激な増員に耐えうる設計となっています。これはプロジェクトのはじめに、NETFLIX, Salesforce, Microsoft, Johnson & Johnsonなどの外資系企業に行ったヒアリングをもとに、設計されたそうです。

私は「組織の成長には変化とコストの最適化が不可欠」であると考えています。

「皆さんの所属する会社はグローバルに成長したいですか？」

もちろん答えは「Yes」ですよね。

日本に存在する悪しき風習として「各部門に個別最適化したシステムを構築し、他部門との連携部分はアシスタント職が手運用で頑張る」というやり方があると思います。
コスト最適の誤った解決策です。これでは成長に伴う変化の為に「ひたすらアシスタントを増やす」という解決策しか取れなくなってしまいます。

「成長したい」のであれば、海外の企業のようにコスト最適化はシステムによって行うべきです。世は令和でクラウド時代なのです。発表の結びに中野さんも述べていましたが「システム投資は経営が経営の為に行う」ことが必要で、決して各部門が「自分たちの業務に最適化したシステム」を作るべきでは無いのです。

現場からは様々なハレーションが起こりますし、そこへのケアを怠ってはいけないのですが、究極的には「トップダウンで落とし込む必要がある」ということですね。

まさに第一回にふさわしい大局的なお話でした。

「業務の難しさ、開発の難しさ」 Sansan 高橋 洸（たける）さん

二人目の登壇者は私の前々職Sansan株式会社の高橋さんです。

Sansanの開発や新サービスの開発に携わった後、昨年から人事部に異動しエンジニア採用や業務効率化プロジェクトを担当している異色の経歴の持ち主です。
今回は後者の「業務効率化プロジェクト」における経験から、「シスステム開発とコーポレート部門の業務の間に存在する様々なギャップをお互いに理解し正しく技術を使おう」というテーマで発表してくれました。

「開発側に伝えたい、業務側の難しさ」

元々開発部時代に面接官として採用面接をこなす中で、人事部の採用フローについて、エンジニアらしく「もっと自動化などで効率化すればいいのに」という印象を持っていたそうですが、実際に人事部に異動してから一筋縄ではいかない複雑さに気づいたそうです。

コーポレート部門における業務フローは非常に複雑である
・アルゴリズムとして表現が難しい
・似た業務でも状況によってパターンが分かれる
・同期/非同期の概念が整理されていない
・すぐに変動する

例えば採用一つ取っても、「新卒/中途で人事側のチームが違う」「ポジションによって面接官が違う」「面接官によって、面接前に伝えて欲しいポイントが違う」など、各面接の対応業務は個別の実装になってしまいます。

さらにトリガーも様々で「メール」「Slack」「口頭」「スプレッドシートのステータス」などが存在しており、「アルゴリズムとして表現が難しい」のです。

これは人事以外でも同じで、総務における物品の購入一つ取っても、取引先によって全く購入方法が異なってきたり、経理においても社員による領収書の提出タイミングと締め日の関係によっては特別対応が頻発したりなどが考えられます。

こういった状況の一つの理由として、中野さんの発表にもあったように「システム化」を前提とするのではなく、「各業務にシステムをあわせる」対応をしてきたことも挙げられるとは思いますが、それを差し引いてもコーポレート部門の業務は非常に複雑なのです。

性質上クローズにしなければいけない業務も多く、サイロ化が進みやすい部門です。

「業務側に伝えたい、開発側の難しさ」

・要件定義は難しい
・技術選定は難しい

特に上記の二点の難しさが挙げられていました。そのうちの要件定義について解説します。

しばしばエンジニアリングに馴染みの無い方から「エンジニア」は魔法使いだと思われ、「プログラミング」は魔法だと思われるのですが、実際はそんなことはありません。

要件定義などのいわゆる「上流工程」がしっかりと出来てこそシステム化することが出来るのです。

例えば、データ分析を考えてみると、「何のためにどんな分析がしたいのか」がはっきりしないとデータ分析はできません。この点について、「不確実性コーン」を引き合いに出されていました。（不確実性コーンについては詳しくは広木大地さんの以下の記事をご覧ください）

実は「作るものが最初から決まっている」ということはほとんどの場合まやかしで、成果物は完了時に初めて確定するのです。「業務効率化」と一口に言っても着地点を最初から決めるのはとても困難です。

では、どうすればよいのか？

要件定義の前に課題や業務フローの洗い出しを綿密に行うしかありません。そして、「いろんなパターンがある」という共通認識を持つことが大切です。

その上で、いきなり開発に着手するのではなく、業務のスリム化やシンプル化を一緒に考えるべきなのです。実はこの作業自体が「エンジニアリング」です。エンジニアリングは魔法ではありませんし、誰もが出来ることなのです。

おそらくそういった過程をこなしていくと、必要な材料が揃っていないことにも気付くでしょう。例えば「データ分析」であれば、その基盤となるデータストアが整備されていないと何も出来ません。「オレオレ人事マスタ」がある状態では何も出来ないのです。

また、エンジニアが陥りやすいハマりポイントとして、「ものつくり」モードになってしまって、「どうあるべきか」の分析が疎かになって、不必要に高度な技術選定をしてしまう、あるいは作ったはいいが誰も使わないものが出来上がってしまうことも挙げられていました。業務フローを双方で分解していった結果、解決策が「技術ではない」ということは、コーポレート部門においてはよくあります。

以上のようにお互いが歩み寄って、技術を正しく使って問題解決に取り組むことが大切である、ということでした。

「カイシャの成長を支える技術」メルカリ 衣川さん

3人目の発表者は株式会社メルカリのCorporate Solutions Engineering Teamの衣川さんです。

「カイシャの成長を支える技術」とCorpTech Loungeのテーマに合わせたタイトルありがとうございました！

発表では、人力でスプレッドシートなどを用いて運用されていた「5年かけて作り上げてきた評価制度」を内製でシステム化していくお話をしていただきました。（メルカリの評価制度については「メルカリ 評価制度」と検索すれば、過去のいくつかの時点での評価制度が記事化されており、その変遷を知ることができます）

資料が公開されているので、細かく解説することはしませんが、特に私が注目したポイントを3つ紹介します。

まず1つ目ですが、「課題解決」のステップについてです。Sansanの高橋さんの発表でも「業務フローを担当者とエンジニアで分解していくことが大切」というお話がありましたが、衣川さんは「課題解決」に必要なステップを鋼の錬金術師に出てくるセリフで表現していました。

「理解・分解・再構築」

また、広木大地さんの「エンジニアリング組織論への招待」から「エンジニアリング」についても引用されていました。

コーポレート部門の複雑かつ重要な課題を「理解・分解・再構築」していく過程のすべては「エンジニアリング」そのものです。特にこの中でも「理解・分解」の2つはコーポレート部門の各担当者と開発をする人が協力して行う必要があるということですね。

また「すべての」というところが大切で、コーポレート部門に属する方々には、「システムや隣の部門については担当外」と自分たちの業務に線引をするのではなく、入退社対応一つとっても、関連部署全体の業務フローを「理解・分解・再構築」してエンジニアリングしていって欲しいのです。

衣川さんの資料にもある通り「理解・分解」を行った結果、なにもコーディングや開発を行うことだけが「再構築」の手段では無いのです。

何かのサービスを使うことかもしれないし、フローを組み替えるだけで解決するものもあるかもしれません。そういった過程をコーポレート部門全体が日常的に行っていかなくてはなりません。

2つ目は「経緯には敬意を」という言葉です

「イケてないから変えましょう」みたいな向き合い方はダメ。

高橋さんの発表にもあった通り、エンジニアはついつい「こんなの自動化して効率化すればいいやん」となりがちです。これまでの経緯に最大の敬意を払ってカイゼンしていくことが大切です。

3つ目は「文化」です

GitHubを使ったことがないHR担当者が、GitHubのアカウントを作ってその日のうちにプルリクを出して、確認を催促されたそうです。

そのHR担当者の方と懇親会でお話する機会があったのですが、「使えないことが恥ずかしいと思った」と言っていました。

今回の発表では「Zapierからの脱却」が取り上げられており、その中でGitHubのくだりも紹介されているのですが、これは一足とびで成し遂げられたことではありません。

そもそも日本のITベンチャーでZapierが流行り初めた事自体メルカリ社の影響が大きいのですが、以下の2記事にもある通り最初はQAチームのエンジニアから草の根的に社内勉強会などを開いて全社ツールとして根付いていったのです。

Zapierはノンプログラミングでのシステム連携ツールですが、これを用いて手作業の業務を自動化していく過程でも当然「理解・分解・再構築」というエンジニアリングが必要になってきます。これによって、開発やコーポレート部門問わずエンジニアリング文化が形成されていったのは明らかでしょう。

こういった経緯から「使えないことが恥ずかしいと思った」という言葉が出てくるような文化が形成されるのだと思います。

かのドラッカー大先生が述べているように「企業文化はあらゆる戦略に勝る」のです。メルカリ社の話を聞いて「職種関係なく本来の意味でのエンジニアリングを社内全体に根付かせる努力をすることが何よりの近道」と感じました。早速自社で取り組んでいきたいと思います。

飛び入りLT

なんと懇親会中に株式会社イエソドの竹内さんが、自社のサービスを紹介する飛び入りLTをしてくれました。最初は立ち話だったのですが、本日のテーマに非常にマッチしたサービスであった為、徐々に人が集まってきて「もう前でやっちゃえ」という感じのノリで急遽登壇

実はこのサービス、メルカリ社のCSEが内製しているTeamsと非常によく似たサービスで衣川さんが「Teamsに求められていた機能が揃っている！1年前に欲しかった。。」と言っていたのが非常に印象的でしたw

参加者全員非常に興味を持ったサービスでした。β版事前登録中なので、ご興味あれば是非登録してみてください！

勉強会の運営自体の反省事項

初の勉強会主催で、手伝いも頼んでおらずワンオペだったため、会場設営など含めて運営が非常にバタバタしました。オープニングトークの練習と資料作成の為、早めに会場に行ったつもりでしたが結局全然時間がなくて、ボロボロでしたw

今回はサポーターズさんに会場提供頂き、懇親会のドリンクまでスポンサーして頂きましたが、設営やドリンクを運んだりなど一部サポーターズの皆さんにご協力頂きました。

サポーターズさんでの開催じゃなかったら間違いなく崩壊していました。サポーターズさん本当にありがとうございました！

次回は絶対運営メンバーを増やそうと思います。

まとめと今後

つたない運営でしたが、非常に多くの方に参加していただき盛り上がった会になったと思います。発表内容も特に私から指定したわけでは無いのですが、中野さんの発表から、イエソド社の発表まで流れるようなシナジーがあったと思います。登壇者の方々、本当にありがとうございました。

今後は「総務」「経理」「労務」「法務」「人事」などコーポレート部門の中でもいくつかテーマを区切って、コーポレート部門の方とエンジニア寄りの方半々くらいの人数になるように調整して3ヶ月に一回くらいのペースで開催したいと考えております。

次回開催についてのアンケート中なので、良かったら回答をお願いします。

次回は7月頃を予定していますので、是非私のTwitterやConnpass、Facebookなどチェックしてください！

読んで頂いてありがとうございました！参加お待ちしております！