CADDiで1年フルコミしたインターンから見た、事業・組織の拡大に合わせたオペレーションの進め方

こんにちは、去年の2月からキャディ株式会社というスタートアップで働いている上田といいます。

上田 知洋 (@tomohiro101006) | Twitter

現在キャディは、製造業における煩雑な部品調達のオペレーションの課題をテクノロジーを用いて解決し、カスタマー（機械装置メーカー）とサプライヤー（町工場）がより本質的な業務にフォーカスできるような構造にアップデートしようと挑戦しています。

事業の一面を切り取ると、いわゆる「DX（デジタルトランスフォーメーション）」に関連の強い事業ですが、「紙やExcelで何がいけないの？わざわざそんなすごいシステムにする意義はなに？」といった疑問も当然生まれると思います。
同時に、「いや、意味はあるのだ！」と思っていても、いざ理由を問われると明確に「○○だから！」と答えられる人も思ったより少ないのかもしれないなと思います。（恥ずかしながら私は完全にこれでした。）

年齢や立場を問わず本質的に事業に向き合うことが求められているというありがたい社風もあり、インターンという立場ながら入社以来1年弱フルコミットで様々な仕事をさせていただきましたが、直近はテクノロジーを用いて社内のオペレーションを改善するという、キャディの事業ど真ん中の仕事をしています。

そんな中で、冒頭の「なぜExcel(・VBA)やスプレッドシート(・GAS)ではいけないのか」という問いに自分なりの解を持つようになったため、noteの形で残して置ければと思います。

DXに興味がある方や、複雑なオペレーションを回している方、業務効率を追求している方などの参考に少しでもなれば幸いです。

キャディがやっていること

キャディがやっているのは、（超ざっくりいうと）機械装置の部品を調達したいメーカーと部品を実際に製作する町工場を最適にマッチングするという事業です。
メーカーの図面データから、形状把握・原価計算ロジックにより瞬時に見積りをお出しし、最適なパートナー企業に発注します。
（ただマッチングするのではなく、その後品質管理をしてお客様にお届けするところまで請け負っています。）

言葉で言うのは単純ですが、デジタル親和性が低いという業界の特性や、キャディがその中でも「多品種少量かつオーダーメード」の製品をメイン領域として扱っている、ということもあり、その裏では非常に緻密で複雑なオペレーションが走っています。

（具体的なオペレーションや業界の特徴についてはこちらの記事に非常に詳しいです。)

noteを書こうと思った理由

冒頭で頭出ししましたが、私はこの2か月ほど、CTO、SPS(サプライパートナーサクセス)本部長と3人で社内のオペレーションのコアシステムのうちの一つをExcelからWebサービスへリプレイスし、業務効率を改善させるというプロジェクトをしてきました。

また、2020年のキャディのテーマとして、「ビジネスとテクノロジーの連携」があげられています。

私はその一側面を、今までの「一定人力によるオペレーションを、テクノロジーの力によってスケーラビリティある形へと変革すること」と理解していますが、私自身その変革の解像度が低く、他メンバーからも「このままExcelとかスプシとかで進めていった方が早くない？GASやVBAとか使えたらいろんなことできるし。」というような率直な意見を実際にぶつけられても、あまり芯食った回答ができないでいました。

ただ、この2か月の社内コアシステムWeb化PJで、運よくその変革期をインターンという立場ながら、ある意味最前線で体感し、解像度が高まったこともあり、「なぜExcelやスプシなどの対処療法ではなく、『しっかりしたシステム』によってオペレーションを回すべきなのか」、について私なりの見解を述べると、メンバーがかなり興味を持って聞いてくれ、議論が盛り上がることも数度ありました。

そのため、恐縮ながら私の学びを還元する意味でも、今回noteに残しておこうと思います。（あくまで会社ではなく私個人の見解ですし、記載できないこともあるためあえて抽象度を高めて書いています。）

複雑なオペレーションを回すにあたって課題となっていること

私が関わっているシステムは、社内のオペレーションフローの中でかなり下流の工程にあります。

そのため、上流のオペレーションフローやシステムのインターフェースの変更があると、それに合わせてシステムを修正する必要や、場合によっては複数バージョンに対応する必要があります。

また、そのシステムに新たなインプットが必要となった場合、上流のオペレーションフローを変えてもらう必要がありますが、その上流のオペレーションは、私が修正したいシステムだけでなく、それより下流のありとあらゆるオペレーションに影響するため、元は軽微な修正だと思っていても、場合によっては、多くの人や部署を巻き込んだオペレーション変更が必要になってしまうことがあり、組織として速くPDCAを回すボトルネックとなる可能性があります。

なぜ「しっかりしたシステム」を用いる必要があるのか

平たく言うと「負債」がたまり、上述のような課題が起きるからだと思っています。

ただ、一言で「負債がたまる」といっても、「負債」には様々な形が存在しますし、その解像度に個人差がかなり大きく、その差がコミュニケーションの障壁になっているケースが散見されると感じています。

ここで私が指す負債は、そんな負債のあくまで一つの形にすぎません。

が、あえて言語化すると「組織・事業の拡大による、個々の業務の影響範囲の拡大」と「個々の業務の個別最適化による複雑性の増大」が同時に進むこととだと理解しています。(以降で噛み砕いて説明します。)

不確実性が高い初期

特にベンチャー企業において、事業初期の不確実性は極めて高いと思います。

そのため、オペレーションやシステムの修正頻度が極めて高く、不完全な状態でもいいからどんどんアップデートしていきたいという要請が強く、この状況下ではExcelやスプレッドシートなどで業務を進めていくと、初期はPDCAが圧倒的に早く回ります。やはりこのスピードは驚異的だと感じます。

理由はいくつかありますが、私が思いつくExcelが早い主要な理由は以下です。 

1. 比較的多くの人が扱うことができる(エンジニアが関わる必要がありません)
2. システムとして単純なので開発工数が小さい
    ➀ ビュー（UI）の実装工数が極めて小さい。(HTMLとか書かなくて大丈夫)
    ➁柔軟性が高く、デバッグがしやすいので、ロジックの開発が速い。
    ➂データベースを内部に一体化させて持つことができる。(SQL書いたりする必要がありません)
    ④インフラを考慮する必要がない。(Excelが起動するかを心配することはあまりありません。)
3. バージョン更新による差分がとりづらいこと、BizとTechの文化の違いにより、レビュー・テストが行われることが少ない結果、リリース工数が小さい。

そのため、不確実性の高い初期においては、一定負債を積んででもExcelやスプレッドシートで業務を構築する利点が上回ると思います。

拡大につれて問題となっていくこと

ただし、組織と事業が拡大することで、上流の業務が影響を及ぼす業務工程が増えていきます。
さらに、スケーラビリティのある業務を志向する結果、業務自体を縦割りにして、それぞれに業務を分業によって進めるようになるため、業務の修正に多くの部署・人を巻き込むことが必要になります。

同時に、Excelがあまりに便利で誰にでも使いやすいからこそ、各部署が業務を個別に最適化していき、部署内の業務の複雑性・属人性が高まっていきます。

この「組織・事業の拡大による、個々の業務の影響範囲の拡大」と「個々の業務の個別最適化による複雑性の増大」が同時に進んでいくことがここで言う「負債」の正体だと思っています。

負債がたまった結果、自部署に収まらない業務修正をするときには、

1. それより下流（場合によっては上流も含めた）業務プロセスを含めて変更する必要がある
2. ただし、その影響範囲は組織と事業の拡大により大きくなっていく。
3. しかも、各部署の業務プロセス変更は業務が個別最適化され、複雑性が増せば増すほど修正工数と認知負荷が上がり、ミスが起こる可能性も大きくなっていく

と、組織・事業・個々のオペレーションの複雑性の3つのファクターすべてに比例する形で改善工数が上がるという悪循環が起こっていきます。

ではどうすべきなのか

想像の通りですが、Webサービスのような「しっかりしたシステム」（定義が難しいのであえてこう呼んでいます。）を用いるべきだと考えています。

もちろんTechの水準に大きく左右されますが、「しっかりしたシステム」はシステムの規模が大きくなっても、比較的影響範囲がコントロールされやすく、複雑性も上がりづらいと考えます。

こちらも理由は様々ですが、私の思う主な理由は以下です。

1.  ロジックやデータの重複が起こりづらい → Excelでは、Excel AとExcel Bの見ているデータに重複がある場合、同じ修正をしたくてもA,Bの2か所に同じ修正を行う必要がある、というケースが往々にして起こります。
2.  インターフェースが厳密 → エクセルの場合は解釈するのが人間なので、セル位置のずれや表記ゆれ、型（数値なのか文字なのか日付なのか空白なのか、など）の揺らぎといったインターフェースのゆらぎが起こりやすいですが、「しっかりしたシステム」は解釈するのが機械なので、インターフェースの厳密性が担保されやすいです。
3. 適切なリリースフローを踏みやすく、ミスやバグの発生率も比較的小さい。
    ① Gitでバージョンごとの差分が明確にトラッキングできるため、開発者以外がコードをレビューし、承認が下りて初めてシステムに取り入れられる、というフローを組むことができる
    ② 一般的には本番環境に取り入れられる前にテストが走る

その過渡期に起こる問題

こういうと、「じゃああるところまではExcelとかで業務フローを組んで、あるところからちゃんとシステム設計すればいいのね！」となりますが、それがなかなか難しいのが現実だと思います。
その過渡期ではBiz側とTech側の認識の齟齬によってコンフリクトが起きることがあるからです。

Bizサイドから見ると、Excelやスプシでは、目の前の短期的な開発速度が上がるため、急に「しっかりしたシステム」が導入されるとBizサイド視点ではPDCAの回るスピードが下がったと感じられます。
さらに、インターフェースの厳密性が上がり、「よしな」に業務を進めることが難しくなるので、煩わしく感じる業務フローや修正手続きが増えます。

逆にTechサイドもエクセルの解読や差分の追跡など、本質から離れた、かつ重い業務をこなす必要があります。

ここまで偉そうに書いてしまいましたが、要は特にあるタイミングからはBizサイドとTechサイドが双方のPros / Consや考え方を理解する機会を適切に設け、歩み寄って仕事を進めていく必要がある、というのが今回の私の学びです。

最後に

キャディでは、4つあるバリューに「大胆」、「卓越」を掲げていますが、実際に重要度、難易度の高い仕事でも年齢によらず果敢にチャレンジできるような環境が整っています。

今回の私のプロジェクトもまさにそうですが、むしろ、立場、年齢によらず、常にオーナーシップを持ち本質的に事業の推進に向き合うことが求められているシビれる環境です。
（こちらの私の先輩が成長環境について書いたnoteに詳しいです。）

そんな熱い環境でともに切磋琢磨できる仲間を大募集しています。
ここまで私の記事を読んでいただき、少しでも「キャディおもしろそう！」、「そんな環境にもまれて圧倒的に成長したい」と感じた方は、TwitterやFacebookなどでご気軽にご連絡ください。
より踏み込んだ話や成長環境についてお話しできると思います。

また、もう応募がしたいという方はぜひこちらからお申し込みください。

最後まで読んでいただきありがとうございました。