中小企業のM&A、留職事情について調べてみた

最近新規事業として大企業から中小企業に留職（留学の社会人版）する事業を検討していて、周辺事情について調べてみた

背景

日本に380万社あるといわれている中小企業は後継者不足がとにかく深刻。ざっと試算ではこの中で１００万社ほどが 社長が６０歳以上＆後継者不在だと言われている。当然この中には黒字企業も含まれている

中小企業のM&Aについて

上記のような問題があるので、ここ数年で中小企業と個人のM&Aが盛んになってきた。M&Aというと企業がやるもので 数百億のディールとかイメージしてしまうが、中小の場合は数百万レベルでM&Aできるものも多く存在する。 ただ当然だけど、購入しようと思っても個人が中小企業を探すの大変だから最近多くのプラットフォームができてきている。

https://macloud.jp/

https://www.tranbi.com/

https://fundbook.co.jp/

あとはこの辺りのテーマについてドンピシャな本がある

要約すると

• 老後不安だろうし、頑張って資本家になろう
• とはいえ０→１企業は難しいしリスク高い
• 飲食店経営もレッドオーシャンでおすすめしない
• 後継者不足の中小企業を経営するのがおすすめ
• 中小は普段大企業で当たり前にやっているような業務効率改善（Excel使うとかのレベル）ができていないから、普通に大企業で働いて自然に身についたスキルで十分貢献できる

https://www.amazon.co.jp/dp/B07C21NBMM/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

事業検討について

事業検討していく中で、それなりのキャリアの人が中小企業で働くにしても、会計、人事とかの専門知識ないと厳しいかなーと思っていたのですが、中小の業務の実情が結構レトロそうなのでいわゆる真ん中くらいの普通の層でも大企業でしっかり業務プロセスの仕組みを学んでいれば中小企業で業務改善などで活躍できるかもというのは新鮮だった

本だと上のTRANBIとかM&A仲介サイト使って探すの進めてるものの、相当ハードル＆リスク高いと思うので、実際やる前に一度体験するという留職は中小側にもニーズありそう （実際、本でもリスク把握のためのデューデリジェンスと社員との信頼関係を作るためにまず２年位は役員で働くこと勧めている）

留職だと現状は大企業とベンチャーを結ぶこういうのがある。

http://loandeal.jp/

留職考える上で難しいのは、派遣元企業、派遣先企業、社員のどこにピン留めするか。 それぞれのニーズ想定すると

• 派遣元企業

  • 中間層派遣して、メッチャ優秀になって帰って来てほしい
  • 最悪優秀にならなくてもいいから、さっさと退職させて代謝良くしたい

• 派遣先企業

  • 大企業のノウハウ知りたい。業務改革したい
  • 後継者欲しい
  • お金はあんまりかけたくない

• 社員

  • 経営者やってみたい（ここは老後ゆっくりしたい層と、暇だし肩書欲しいし働きたい層で結構違う）
  • とはいえ年で老後もあるし、金銭的なリスクは最小限に押さえたい

上のローンディールとかは派遣元の「中間層派遣して、メッチャ優秀になって帰って来てほしい」にフォーカスしてる気がする（しかもメインターゲットは３０代）。 中小企業の後継者不足＆黒字倒産にピン留めするならどういう座組みがいいか要検討。

エンジニア組織における組織開発について

先日会社でこんな感じのイベントをやってきました

https://tech.recruit-mp.co.jp/event/post-16667/

ぶっちゃけ転職して今の会社に入るまでは組織活性、組織開発という言葉も知らずにひたすら

• 雑談大事
• 1on1大事
• メンター大事

みたいな戦略なき根性論みたいなことしかやってこず（それでも一定の効果は出ていたと思う）、しっかり組織開発について自分でも学んでみました。

イベントの趣旨として、実現したいのは開発組織におけるあらゆる知見がなめらかに循環する世界で、 中でもこのイベントの中でも参加者の１人が言っていて印象に残っているのがエンジニア組織は組織開発のsandboxということ エンジニア組織は規模もそれほど大きくないことがほとんどだし、エンジニア自身が勉強熱心で流行りに敏感だし、変化の許容量が大きいので最適だと、確かにその通り

ただ現状の問題として大体会社ごとに１つしかsandboxを持ってなく、そこへのcommitログが公開されておらず他社から見れないこと それにより、ある場所で起きているrevertとか、他の場所でも全く同じこと繰り返したりしてる ここらへんを循環できるようにしていきたいなと

最終的には別に他の会社のsandboxにcommitしてもいいと思うし、お互いのログを見せ合うことでかつてないほどお互いのコアな部分を知り合うことができると思っているので その関係値を利用した、施策とかが行えれば面白いなと思っています。

アジャイルについて最初に知るべきことだけをまとめてみた

今の副業してるところが本格的にフルコミットのエンジニアと学生インターン数名で開発組織を作ろうとしていたものの アジャイル開発について開発フローも何もかも全然わからんという状態だったので、 とりあえずアジャイルサムライとかScrum Boot Campとかエンジニア組織論への招待とかは読んでもらうとして

最初に知るべきことだけをまとめてみた。

• 歴史
• アジャイルに対する誤解
• 目指すべきところ、そのために明日からやること

という構成に

特にこだわったのはアジャイルに対する誤解のところ

これだけ色々なところでスタートアップやっているアントレプレナーやエンジニアがいる中で アプリの開発について色々聞いたことや、ちょっとググって色々な資料が出てきたりする。

大体開発やったことない事業サイドの人だと、それらの情報から間違った開発フローのイメージ持って 突き進んでしまうなと経験的に感じているので、歴史的経緯と誤解を解消して事業サイド、開発サイド もゼロベースでスタート地点を合わせてこれから皆でインプットして健全に議論しながら 進めていこうというところを目指してみた

https://speakerdeck.com/hikoharu06/aziyairudeiketerutimuru-men

GTmetrix使ってサイトのパフォーマンス改善した

これは何

ブラウザアプリをGTmetrixというサイトのパフォーマンス計測するサービス使って、速度面でのボトルネックを特定して解決した話

https://gtmetrix.com/

そもそもなぜやろうと思ったか

最近、SEOやらコンテンツマーケティングやらに興味が出てきて、グロースハック的なmeetupに行っている。 その中である人が、「グロースハックには色々施策あるけど、一番コスパのいい施策は速度改善」と言っていたのが印象的だった。 実際に自分がプロダクトオーナーやっているサービスで試してみた

実際やってみた

これが最初に計測した時

屈辱のF評価。。。。 どの項目が悪いか調べると

• Serve scaled images: 必要以上に大きい画像を用意して、cssでサイズ調整している

• Enable gzip compression: gzip圧縮を使っていない

• Leverage browser caching: ブラウザキャッシュが有効になっていない

が問題なのがわかる。

なので、それぞれ

• Serve scaled images: 画像のサイズ調整

• Enable gzip compression: nginxでcss,javascriptをgzipするようにnginx.conf設定変更

• Leverage browser caching: nginxで静的ファイルを30日間ブラウザキャッシュするようにnginx.conf変更（ブラウザキャッシュはブラウザ側の設定だけだと思っていたので、nginxにも設定あるの初めて知った）

結果が

喜びのA評価！！

まとめ

まだサービスが動くようになってから、数ヶ月ということもあり２〜３時間程度で対応できた。nginx周りで少し詰まったので、知識ある人なら１時間以内とかでできると思う ただこれが１年運用したとかになると、膨大な修正を入れなければならず、永遠塩漬けになる未来が見える。。。

持論だけど速度改善（にとどまらず改善系全般）は担当者がちょっと手が空いた２時間くらいで「やってみるか」という状態にいかに保つことが重要だと思う。

• マメにリファインメントして、課題の粒度を細かくしておく
• 計測方法、修正方法の確立
• チームの文化（空いたらその分機能開発ではなく、改善に力を注ぐ）

のを常に実行しようというのが改めて身にしみた

Google I/Oで発表された電話予約、Duplexについて

Google I/O行きたかったけど、行けなくて発表されたものを一通り見ていました。 多分みんな同じだろうけど、一番の注目はDuplex

https://www.youtube.com/watch?v=bd1mEm2Fy08

https://japanese.engadget.com/2018/05/08/google-ai-duplex/

電話予約をGoogle Assistantがお店の人と電話してやってくれるという、ペコッターの中の人いない版ですね これは大きなゲームチェンジの可能性があうのではないかと。。 従来、電話で予約やら問い合わせやらやっていましたがこれだと

カスタマー - 時間に縛られる同期的なコミュニケーションしかできないので、人によっては手間

店 - 電話でのやり取りがデータとして残らないので、Q&Aや予約状況とかを公開ができず、いつまでも工数確保が必要

という課題があり、「じゃあWebサービス上でやったらよくね？」ということで美容院やら飲食、最近は病院とかまで ネットで申し込むという文化が徐々に広がってきたわけですね ただ結構長いことやっているけど、色々な問題がありカバレッジが一向に100%にならない。これって性質上、60%と80%の違いってそれほどなくて100%にならないと 意味がないものかなと思っています。

Duplexは技術の未来感、カスタマーから見たらとても便利なものの、店側としては対応工数変わらず、それほど嬉しくないという特徴があり、これが広まっていって 誰にとってもいいのかという不安があります。 まあ、Googleのことだから店側もAI用意して、AI同士で解決できる。もしくはAIと店側の会話内容からデータ作成するくらいやってくれそうですが

とにかく、レガシーなコミュニケーションしていたのをWeb上でやることで価値を出してきたサービスはこれから危なくなるんじゃないかというのがざっくりとした感想です。

Macのメモ帳のデータを手動で復旧した話

知人がMacのデータが全て消えてしまって、死にそうになっていたのでメモ帳の復旧をした話。経緯としては

• Adobe Illustratorを入れようとする
• インストールしようとするも、ハードディスクの設定が「大文字/小文字を区別する」という設定になっており入れられない
• どうにもならないので、ハードディスクを初期化して設定を変えようと思い、Time Machineを使って全てバックアップした上でフォーマット
• 「大文字/小文字を区別しない」設定にして、Time Machineから復旧しようとしたところ、フォーマットが異なっており復旧できないという事態に。。
• しょうがないので、ファイルは外付けHDのTime Machineから手動で復旧、ただメモ帳に関してはファイルの実態がわからず、復旧できない。超大事なデータが入っておりヤバイ。。
• iCloudに保存されていれば大丈夫だと思ったが、なぜかバックアップの設定をしていなかった。。。

というところで依頼され、色々ツッコミどころはあるものの、すでにメモ帳以外のデータが復旧されていたため、一旦スルーしてメモ帳の復旧作業始めることに

アプローチとしてはiCloudにバックアップされてない以上、メモ帳の実体ファイルを特定してTime Machineのバックアップ内から探して持ってくる以外は手がなさそうなので、 やってみる。

色々調べた結果、どうやらメモ帳の実体は

• ユーザー名/Library/Containers/com.apple.Notes/Data/Library/Notes/ の NotesV6.storedata** :独自の拡張子でメモ帳内の情報がファイルに記載されている。一応テキスト形式なので、エディタで確認可能。
• ユーザー名/Library/Group Containers/group.com.apple.notes/ の NoteStore.sqlite** :sqliteファイルでインデックスなどの情報が格納。ここにはあるテーブルにメモ帳の題名と、上記のファイル内の対応する本文のキー情報が記載されている

で管理されているらしい

ということでTime Machineのバックアップフォルダの中から、上記のファイルを探して、Macのものと置き換えて無事復旧。 まさかMacのメモ帳がsqliteで管理されているとは思わなかった。。。というかなりマニアックな知見でした。

ちなみに多くのブログやQAでは

ユーザー名/Library/Containers/com.apple.Notes/Data/Library/CoreData/ExternalRecords

というところにデータの実体があるという回答が多かったのですが、確認できず

https://discussionsjapan.apple.com/thread/10175353

このブログがなかったら、なかなか厳しかった（とはいえ、該当フォルダ内のファイルはそれほど多くないので、手当たり次第チェックすれば多分たどり着ける。未確認だがフォルダ毎もってきても多分うまくいくかも）

https://gachan55.blogspot.jp/2016/05/el-capitantime-machine.html

React,Vue..どのFW使おうかなー 〜それSEO考慮しなくて大丈夫？〜

これは何？

とある新規のWebサービスを開発することになり、フレームワークを選ぶことに 「React使おうかな、Vue使おうかな、Angularはちょっと古いかな」とか色々考えていたら、作るサービスがKPIはMAU,Googleでの自然検索流入がメッチャ重要、SEO意識しないとダメということに気づき、これはエンジニアリング的な目線だけで決めてはマズいのでは？と思い調べてみた

そもそもの疑問

Googleがサイトをクローリングして検索のインデックスが作られて、自然検索に引っかかる訳だが、このクローリングはHTML要素をチェックしているはず。その時に

• 操作によってHTML内のDOMがサーバーからのレスポンスによって動的に切り替わる場合:初期表示されていないものをクローリング対象にできないよね？
• Reactとかだと、そもそもHTML単体だとほとんど情報がなくて、全部jsで差し込むけど大丈夫か？

というのがそもそもの疑問

クローラーとjsについて調べてみた

Googleのクローラー（GoogleBot）がサイトを巡回して、キーワードを解釈してインデックスにしていることでGoogleで検索可能にしている。

Q.GoogleBotはjavascriptを認識できるのかどうか

A.できる どうやらGoogleが2015年くらいに公式で「JavaScriptで動的に表示されるコンテンツのインデックスはされない」という発表をしたらしく、それが広まってしまっているのが色々な認識齟齬の原因。 現在はGoogleBotがJavaScriptを実行してその結果を見ている。 この改善が公式発表されているわけでなく、GoogleのJohn Muellerさんが2016年くらいにtwitterでさりげなくつぶやいている。カジュアルか

https://twitter.com/GiceOne/status/804332185130008576?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fpromonista.com%2Fevaluation-of-javascript%2F&tfw_creator=Prmnista&tfw_site=Prmnista

Q.じゃあ何も気にしなくてもいいのか

A.いいえ 確かにGoogleBotはjavascriptを認識してくれるものの、

• jsが正しく実行されるか
• ページ内をもれなく操作してインデックスしてくれるか

を考慮する必要があります。

jsが正しく実行されるか

GoogleBotはページにアクセスしてレンダリングするが、ChromeとIEの違いがあるようにブラウザによってjsの処理、パフォーマンスは微妙に変わってくる。 2018年現在GoogleBotのブラウザはChrome41(2015年1月リリース)を使っていると公式が発表しており、かなり古い これにより、意図しない部分でjsエラーが起きる。または処理が異常に遅くなりタイムアウトする可能性がある。

ページ内をもれなく操作してインデックスしてくれるか

GoogleBotはサイトのFirstViewにアクセスしてから、サイト内を操作して、FirstView以外のページの情報を取得している。この時にこちらが意図した通りに全ページを見てくれるかを考慮する必要がある

SSR（サーバーサイドレンダリング）とは

GoogleBotはjsは実行してくれるけど、正しく実行されない可能性がある。。。という問題に対して、現状よく使われているのがSSRです。 解決策としてはAPとは別でレンダリングサーバーを用意して、そこでjsが実行されたhtmlをキャッシュ、リクエストが来た場合はそれを返すというもの イメージは下記

なおSEO的な意味とは別に、jsが事前に実行されているので純粋に初期描画が速くなるというメリットもある

なおSSR以外の解決策としてPrerenderingというものもある これはサーバーの中にヘッドレスブラウザ（Phantom.jsとかが有名）を用意しておいて、リクエストが来たら、ヘッドレスブラウザでレンダリング処理を行って、htmlを返すというもの。 どうやら、あまりメジャーではないよう SSRに比べて、導入も運用も低コストでいいと思うが、厳密には違うもののリクエスト投げてからブラウザ描画するのを２回やるオーバーヘッドを気にするのが理由かなと

SSRはいいことづくめ？

SSRには否定的意見も結構多い。ほとんどが

• 費用対効果が悪すぎる:SEOと初期描画高速化に効果があることは間違いないが、それにしても導入、保守が大変だし。開発効率も大幅に落ちる
• そもそも解決が本質的ではない:速度に関しては別の効果的な打ち手もあるし、SEO対策にしてもGoogleBotが更新されていけば改善されるのでは？なおかつなんか時代に逆行している気がする（歪なキメラという表現がされている）

というところに収束する 最近はNuxt.jsといったSSR専用のフレームワークとかも出てきているので、それで改善されるか？

結論

SPAにするかどうか、フロントエンドフレームワーク何使うかはSEO的には色々回避策あるので、それほど気にしなくてもいい。 ただ対応に尋常でないコストがかかる or 開発後期に見つかってアーキテクチャー変わると悲惨なので、こまめにGoogleBotにどう見られているのか確認する

このFetch as Googleを使うと簡単にチェックできるらしい https://support.google.com/webmasters/answer/6066468?hl=ja

一通り調べてみたものの、ぶっちゃけこれからやっていく段階で多分いろいろ試行錯誤しそう このあたり知見ある方いれば、ぜひご意見いただきたいです。

備考

SEO以外にも、近年のSNSの盛り上がりを経てOGP（Open Graph Protocol）対応も重要。 Facebookが始めた概念で、urlをSNSとかに書き込むと、概要が表示されるあれのこと

このOGPもGoogleBotと同様にjavascriptの動作が通常のブラウザと違うという問題があり、SSRを含めて、対応が必要。これについては直近使う予定がないので、また必要になったら調べて書きます。

後日談

この記事を社内で共有したところ、いろいろ反響いただき結論としては SSRは導入、保守にとてつもない労力がかかるというのと、その労力をかけてまでSPAで表現する必要があるんだっけ？ ということから、よほどの必要性がない限りはSSRに踏み切らないほうがいい（サービス全部をSPA前提にしないほうがいい）という結論に収束しつつあります。 ただサービスの中で部分的にSPAにするのは全然ありなので、サービスをデザインする時には初期段階で

• どの部分をSPAで表現するか
• そこはSEO的にクローリングされなくても問題ない部分か

ということを考慮すると、フレームワーク選定、リリース後にくる「こんなはずでは」を防げるのではと思いました。