受託開発はDXの一丁目一番地
□はじめに
株式会社INJUS（2022年1月より「API.inc」に社名変更予定）は、スマホアプリ・ソフトウェアの開発会社としてクライアント様の業務用システムの開発ニーズにお応えすべく受託業務を行なっています。
同時に自らがチャレンジする姿勢を大切にし、積極的な研究・投資による自社事業の二刀流経営を実践しています。今後は「ケンカツ」および「ケンカツで実装したシステム群」を用いて、より簡便によりインスタントに企業や特定業界のDXを支援していきたいと考えております。
□システム開発会社以上の価値提供
これまでは開発依頼を前提とすることが多かったのですが、事業売却やアクセラレーター、経営革新計画やIT導入補助金の取得や特許・商標などの知財、銀行融資等、上流工程の対応幅が広がっており、提供出来る価値が確実に増えています。
にも関わらず発注あるなしで区切ってしまうと、どうしても案件単価が高くなり、お付き合いのチャンスが分断されてしまうと感じていました。事業再構築補助金も始まり事業転換にIT化を検討される企業様も増えることが予想され、見積もりの妥当性などセカンドオピニオンとして開発の前段階で相談に乗れる存在こそ、これからの時代、本格的に必要になってくるはずです。
そこで、もっと浅い所でカジュアルにご相談頂ける体制としてスポットコンサルを商品化することに致します。幸い弊社は一括見積もりサービスに登録しているため、毎月80件程度の開発要望書に目を通しトレンドを追える環境にいます。アウトプットに責任が持てる開発会社が提供するコンサルティングということもあり、実効性のあるサービスになるものとご期待下さい。
なお、今後はコンサルのやり方そのものを変えようと思っております。コミュニケーションを完全オンライン化、LINEやFacebookメッセンジャーにて弊社からの回答のテキスト数を自動でカウントし、文字数に応じた完全な従量課金制を実施。zoomの場合は1時間ミーティング一回5000円とし、コストパフォーマンスが見えにくかったコンサル業務の明朗会計を実践します。取り急ぎ、これまで通り弊社webサイトの「簡易お問い合わせフォーム」よりご連絡下さい。
また、技術をどのようにビジネスにするかという立ち位置から情報発信をするツールとして、noteを記事コンテンツ化していきます。
１回目は「受託開発」（個別開発）です。結論から言うと、企業のDXを達成する上で個別開発は必要というスタンスです。
□大企業にこそイノベーションのキーマンがいる
折しも現在の日本はデジタル化待ったなし、国を挙げて取り組むべき最重要課題と認識しています。「IT企業化したい（事業部門としてでも）」という切実な思いに後押しされ、予想もしないような企業様（規模や業種、地域を超えて）から弊社に白羽の矢が立つということが現実に起こり始めてきました。この傾向は大手やトラディショナルな企業ほど強く、ひとえに受託開発力を評価・期待されていると理解しています。
自社事業を運営する上で常々痛感していることが、どんなに素晴らしい製品を開発出来たとして、それを届ける能力は全く別物です。これまで売上を作ってきた商品力、顧客基盤や知名度、営業や宣伝リソース、地場や業界への影響力を既に持っている大手企業が社内の遊休資産をITと掛け合わせ、最大化させて新しい価値を作っていく、これは新規事業を作る上で非常に合理的かつ贅沢な戦略だと感じます（むしろ、羨ましさすら感じます）。
新規事業の場合、仕様が完璧に決まっていると言うよりはMBOやベータ版として開発し、叩いていってフィットさせる、そんな流れになると思います。ある日、突然、AIさんがやってきて業務のあり方を丸っと変えました、そんなことはなく、既存業務がじわりじわりとデジタルに置き換えられていく。結果として、常にベストプラクティスになり続けるようなイメージです。その時、必ず企業のハウスルールや外部環境が影響してきます。
こうなると外注ベンダー単独でどうこう出来ることではなく、相手先の企業にキーマンがいるかどうかで成果が変わってきます。その担当者こそが汗をかくことになるからです。
大手とベンチャー企業のアライアンス、アクセラレーターが増えている背景には、事業化したいのはもちろん、それ以上に社内人材の育成という側面もあるはずで、受託開発を経験することで実際、そういう成果が出ると思います（これについては後述します）。
どうしても「起業家」に注目が集まりがちですが、日本経済が大きく前身する可能性は既存企業の中にこそいると考えています（ニューノーマルという言葉は「ノーマル」な状態を知っている人じゃないと難しく、起業家はどちらかと言うとアブノーマルなので笑）。
□受託開発って何がそんなに良いの？
実際に仕事を共にすることになると、
「これって実現出来ますか？」
「それってその仕様じゃないとダメなのでは？」
みたいなことを頻繁に聞かれますが、出来ますし、その仕様じゃなきゃいけない理由はないです。何か指定するようなこともありません。お題に合わせてこちらが受託する、文字通りどこまでいっても受け師であるということです。結局、何を使うかというのはこちらが決めることではなく、ユーザーやクライアントが決めること（もちろん、提案はします）。オーダーメイドで作るから上記の哲学を込めることが出来るわけです。
これが受託開発の最大の利点です。企業によって何をどう使ってどうなりたいか、ゴールが違うという前提があるわけです。今はこれ使ってるけど「これじゃない何か」を探している、ことITに関してはそんな状態。
デジタル化が目的となり、それありきで振り回されるのはなく、業務やビジネスがデジタルの上位に来ること、デジタルを「自分の力として」活用しつつ、パーソナライズされた形でシステムを持つということ。この要件が必要になるのではないでしょうか。
これは自社事業にも通ずる考えで、「ユーザーの声を聞いて自社プロダクトに反映」というアプローチは、ユーザーに向き合っている企業として大変評価の高いプロダクトドリブンな会社と言われますが、それって正に、要求を聞いて個別開発してバグや新機能フィックスさせていく受託開発的なアプローチです。その上で、その通りに作るだけではなく、こちらから先回りして正解を導いていけるか、それがクリエイティビティです。この攻守のバランスはケンカツの開発哲学にも大いに影響しています。
DXというバズワードが用いられて久しいですが、右へ倣えで「紙をなくそう！」がその正体だとは考えません。建設現場などは現実的に紙が重宝されるシチュエーションはありますし、その需要がなくなることはないでしょう。問題なのはFAXとシステムが繋がっていないことで、盲目的に「なくす」のではなく「活かす」ことを考えます。実際、ケンカツの管理システムには、LINE・zoomに続き、FAXで送信する機能実装を予定しています。弊社の自社サービスは個別開発出来る要素を残した形で作っています。
□SaaSとの関係
では、全部ハンドメイドで手作りするのか？ということですが、そんなことはないです。スマホが登場して10年以上が経過し、CRMにせよ決済にせよ、極端な話wordpressにせよ、世の中には既に十分なサービスが出ているわけで、何かを新しく作り直す必要ってあるんだっけ？というものが多々あります。実際、弊社が当たる案件はスタート時点で70%程度が何らかの既存システムとの連携を前提としています。
具体的な切り分けの事例を出すと、弊社で最も依頼の多いLINE公式アカウントの場合、必ずMessaging APIを使うわけですが、この場合、外部のシステムから「LINEで配信する」この部分だけを見れば他のクラウドサービスを使う形でも問題はありませんし、個別開発は必要ないかもしれない。実際、弊社が個別開発を引く場合もあります。今は必要ないんじゃないですか？という感じです。
ただ、リッチメニューを作って何かしらのコンテンツを盛り込みたい、既存の配信システムの拡張性が乏しく想定している導線を作れない、管理システムとのインタラクティブな連携が出来ない、といった問題は現実的に起こります。
SaaSか個別開発かみたいな、分断を煽るような二元論ではないということ。SaaSを辞めたいという要望もあれば、逆に「◯◯を使って」というお題も両方あります。それらを切り合わせたりつなぎ合わせたりして最適化していく、満たせないところは個別開発していく、そこら辺の方法論が明確な開発会社です。
□要件定義にかかるコスト
個別開発するのかAPIを使うのか（多くの場合はその両方ですが）、いずれの場合も重要なことが、要件定義です。
ありがたいことに「ケンカツのようなものを作って欲しい」というお問い合わせを頂くことが増えました。一方で、「ような」とは「100%ケンカツではない」ということで、どういう部分が「ケンカツっぽく」どこから先は「ケンカツと同じではいけない」か、そのギャップを埋めるプロセスが要件定義です。そして、ここに対する評価があまりに低いと感じています。
ドラ○もんを例に説明すると、
①のび太「ドラえもん、（今のこの私の気持ちをうまいこと収めてくれる例のアレ）出して」
②ドラえもん「仕方ないなぁ（と言いながら、要件定義をしいている）」
ジャーンジャ、ジャンジャンジャーン
③「◯◯！！」
つまり、何かしらの課題（解決したいこと=要求仕様）があり、それを満たすには何を出せば良いか、顧客（のび太）を幸せにするソリューションを提示する。「道具が問題を解決したこと」に注目がいきがちですが、実は「どういう道具を出すか」から既に始まっているということです。
ただし、ドラえもんの悪いところは、事前にきちんとリスクの説明をしないため、のび太のような悪意ある（開発側が想定していない）使い方をするカスタマーの暴走が起こってしまう点ですね。
いや、やっぱり書いていて気付いたのですが、ドラえもんでは既に出来上がっているプロダクトを選定するので今回の趣旨とは少し違うかもしれません。それで言うと「キテレツ大百科」の方が近いかもしれません。いずれによせ、サイエンス・フィクション作品ではこういうシーンがよく出てきますね。
話がずれましたが、弊社はケンカツという代表作を持っていることで、想定される機能をあらかじめリストアップし、パッケージ商品として公開しています。この場合、相手のやりたいことが予想出来る範囲であれば特段、要件定義に時間を必要とせず、コミュニケーションコストも低く、最低限、見積もりを出すくらいのことは可能なのですが、もっと踏み込んだところ、これまで人間が、感覚・経験・空気を読みながら「よろしく！」やれていたことを何の手心も加えてくれない無機質なシステムにやらせようということになると、まず言語化（場合によっては資料化）する作業が発生します。場合によっては法律や規制が関係してくることもあります。それは大きなウェイトを占めているため、発注契約が成立してない状態で誰がそのコストを持つのか、個別開発の場合、この問題が非常に悩ましいのです。
しかも、単に模範解答が分かれば良いというわけではありません。常識的に考えれば「こう」だけど、ウチは「そう」なっているみたいなハウスルールがあるからです。実際、（人とのコミュニケーションを増やすため）システムによるオートメーション化を避け、わざと使い辛くしたいというケースもあります。「人間がやらなきゃいけないこととシステムがやるべきこと」この切り分けというのは、意外と各社マチマチだということに気付きます。そこのポジションって、絶対にAIに取って変わらないと考えています。クライアント企業さんに人的な汗をかいてもらうところはこういうところです。
これをきちんと社内の担当者が意思決定をしてくれれば良いのですが、社内にそれを担える人材がいない場合もある。その場合、どういう選択肢が残されているかと言うと、「やることがざっくりしていて自分たちでもよく分かっていないので、まずはそれを開発側の視点から形にして」ということはもちろん可能です。ただ、その場合、有償での対応となります。発注までのアイドルタイムが長く、その間に調整や調査等で弊社の工数が発生するけど、その間はまだ発注してないから無償で、という対応は弊社としてもお取引が難しくなってきます。
本当は「予算はどれくらいですか？」と聞いてしまいたいのですが（予算に合うか合わないかだけのジャッジは瞬時に分かるから）、「見積もりを頂いてからでないと金額の提示が出来ません」とご回答頂くことを予想します。初見の相手に懐事情を明かすようなことはなるべくしたくないということはよく分かるからです。ただ、本当にやることがざっくり過ぎる場合、こちらとしても正確な見積もりを出すことは難しく、極端な話「300〜800万円のどれかです」みたいな回答になってしまうこともある。
それくらいバッファが開いてくると、蓋を開けてみた時、上と下とで発注そのものが成立しなくなることになり、それなら最初から断る方がお互いのためになるので、そういう意味での予算をヒアリングしています（実際はほとんど聞かないようにしています）。
□ラボ型による商流
あるいは、契約方法で対応するという選択肢もあります。具体的に言えばラボ型と呼ばれるものです。特定の業務に対して技術者の労働を提供する契約「SES」に似ていますが、ラボ型はあくまでも支払い方の話なので、受注自体は請負型で受け人月で支払う、という感じです。
繰り返しになりますが、「この世にない」少なくとも「不確定なもの」をシステム実装していくことが増えてきたため、事前に工数を洗い出し、その金額および期日に間に合わせる、ということが現実的に難しいケースが出てきています。クライアント側も何を作りたいかがまとまっておらず、作りながらぼんやりしたものを形にしていくという感じなので、流石にそこまでを想定して見積もりや工期は出せません（どうしてもという場合、リスクバッファを取った肉厚な内容になってしまいます）。
また、開発途中での仕様変更や当初は後回しにしていた機能をやっぱりこのタイミングで盛り込みたいとなった場合、中小零細の開発会社にはリソースを温存しているほどの余裕はありません。そうなると、別案件が終わってから2ヶ月後の着手ですみたいなことになり、あらかじめ稼働を確保しておくラボ型の方が開発効率・コスパが良いということになります。
場合によってはクライアント企業の内製エンジニアやデザイナーと一緒にプロジェクトを進める、といったレンタルディレクターみたいな関わり方も増えてきて、創業当時の10年ほど前と比べ、働き方の多様性が広がっていることを実感します。
□重要！エクセルによる「なんちゃってシステム」
とは言え、契約形態の変更が直接的な解決になるとも言い切れないし、ラボ型はそれはそれで考えなければいけないこともあります（マネージメントコストが上がります）。
長くなりましたが、最後にこの記事で最も伝えたいことを記載します。これまでつらつらと記載してきた問題を解決するための現実的な策として、エクセルで良いのでご自身で「なんちゃってシステム」を作ってみるという提案です。それがあるかないかは仕事のやりやすさが全然違います（当然、開発コストもだいぶ落ちます）。
エクセルなら割とどんなビジネスマンでも使えると思いますし、慣れている人なら自分一人で構築出来てしまうでしょう。エクセルで運用が出来ているということはシステム的な定義が出来ている、ということになり、やりたいことが明確になります。それがそのまま弊社への要求仕様になる。それに「脱表計算ソフト」みたいな謳い文句がありますが、計算ソフトにすらなっていなければ、そもそも必要性から考えるきっかけにもなるでしょう。
これはもちろん、エクセルではなくCRMなどでも良いです。何なら、新システムに移行する際、そのCRMがそのまま使える場合もあります。ケンカツも各種CRM上で動かせるようにしていく予定です。
コンサルプランを推してきた最大の理由は、この部分から関与していくきっかけになればという意図があります。本格的な開発を弊社に依頼する場合、その分を要件定義に充当して相殺出来ます。もちろん、社内人材だけで作れるならそれに越したことはないですが、助けが必要なら安価でコンサルが可能です。
□人材採用が一番の目的
以上、割とクライアント目線で書いてきましたが、本ブログ一番の目的はクリエイティブチーム（エンジニア・デザイナー）の採用です。
弊社は、代表者自らが、技術やデザインをどうビジネスにするかを真剣に考え、「やりがい」という言葉に置き換えるのではなく、クリエイターの金銭的価値を上げることに真剣な会社ということが少しでも伝わればと思います。
もちろん、「こう思う」「認識が間違ってるよ」といった異論・反論はあるかと思いますので気軽にお受けします。
その際は何卒「FAXで」ご連絡下さい。
この記事が気に入ったらサポートをしてみませんか？