完全無料

結局何がしたいのか？を考えてみた

CTOとしてゲームチェンジャーになれるようなポジションはそうそうないって事がわかったところで改めてじゃぁ、自分は何をしたいのか、何を求めているのかを考え直すいい機会でした

・裁量を持って働きたい

過去の記事で楽天の面接に受かったのに辞退した理由でもある、管理職はいくつもあるけれどそれでも大企業のマネージャーのポジションはあくまでいちポジションの歯車という点はいなめないかと思います。

やはり過去に経験したような会社の命運を左右する立場で働ける方がやりがいはあるので、やりたいことの軸の1つかと思います。

・システム・ITの第一人者になりたい

会社が破産しそうな所を一人で救って、なおかつ大きぼな基幹システムのリプレイスを実行して黒字に持ってきた経験があるので、当時はしんどかったけどもやりがいもありました。

実力では第一人者になれるはずですが、なれてないです。

第一人者になるには、数をこなすか、有名企業のシステムリプレイスなどに携わるかって事になります。

・社会貢献したい

元々SEになったきっかけ過去の記事にも書いた通りほかの業種に比べればより便利なものを提供する職種で、働けば働くほど世のため人のためになるという所が気に入ってSEになったし、続けているモチベーションになっています。

IT企業では当たり前の事がITに弱い会社では当たり前ではなく未だに古いしきたりで運用費用を費やしている所も多いかと思います。

そういった所を改善して、より多くの人を喜ばせることは自分も幸せになるかと思います。

同じように困っている会社ITに弱い会社は多いと思うので自分が役に立てる機会はあると思います。

そういった会社を一つずつ救っていって社会貢献したいという欲もあります。

そういった3つの事を総合的に踏まえた結果

起業して、中小企業に対してDXを進めることができるコンサルタント
っていう答えが自分のやりたい事に最も近いのではと考えました

しかし、この記事でも書いた通り起業しても絶対に成功しないです。

中小企業に対してという事でまず、外注に依頼する費用は低くなりますし、
自分が起業したところで、人脈もないのでクライアントを見つけてくるのにかなり苦労するかと思います。

それでもその自分のやりたいことに一歩でも進もうと考えた場合、
副業として働けば安全に起業するリスクも抑えられるんじゃないかと考えました。

具体的には完全無料でシステムを導入する方法をブログに紹介していく
そうすればお金に余裕がなくて、業務効率をしたい中小企業の役に立って社会貢献になるのではという結論になりました

なので、これからできる限りタダで作る自作SaaSを作ってみてブログに上げてみようかと思います。

起業・新規事業が成功しないたった一つの理由

ネットでなぜ煽る？

よくネットで起業が正義のように取りだたされ、成功もしそうにない人に煽りまくるのはなぜなんでしょうか？

「起業で成功するための5つの理由」みたいな記事をよく見かけますが、
そもそも起業して簡単に成功するならば、その記事を書いた人が
それを実行して成功して、そんな記事を書く必要もないのではって思います。

そのネットでの煽りを受けて起業して損害を被っている方も多いのではないでしょうか？

今回はその逆で起業・新規事業がなぜ成功しない。

起業しちゃダメな理由を書きたいと思います。

起業を時代とともに見ていく

起業がうまくいく確率は時代とともに変遷していくというのが自分の考えです。

起点はやはり1995年のIT革命です。今ネット業界を席巻している、いや、全ての産業を呑み込もうとしている
GAFAをはじめ成功しているいわゆるIT企業の起業の年代は2000年前後かと思います。

GAFA とは？｜カンタン比較① 株と歴史まとめ｜2020年の勝者は？ | 前向きリサ☀︎カリフォルニア with 難病EGPA

Google	1998
Amazon	1994
Facebook	2004
Apple	1976　(1997にジョブス復帰)

Facebook、日本だと2ちゃんねる、グリー、さくらインターネットなど個人で開発、構築したシステムがあれよあれよと言う間に巨大な企業やサイトに成りあがりました。

理由は簡単で時期です。

IT革命直後ではインターネット市場も少なければ、参入する会社もすくなく寡占化がまだ起こってなかった所にあります。

なので1990年代にインターネットで起業するという話であればめちゃくちゃ成功する確率は高かったのではと思います。

自分も2003年ぐらいの当時に今でいうUberみたいなビジネスモデルで自転車のシェアリングサービスのアイデアをビジネスコンクールに応募した事がありましたが、それが受かって出資を受けていたら人生が変わっていたのかもしれません

2010年前後

しかし、21世紀に入って数年がたつとネットビジネスに参入する企業も増えITバブル、ネットバブルの変遷を経て個人開発では太刀打ちができない状況になってきました。

2010年前後ではアプリ特有のアドバンテージを活かしたサービスが頭角を現してきます。
メルカリ、LINE、Instagram、tiktokなどなど2010年代なので、もはやこの時には個人開発ではなく、スタートの時点で出資を受けて会社としてサービスを立ち上げている企業ばかりです。

スマホアプリ以外で成功したサービスはSalseforce、チャットワーク、slack、ビズリーチ、Shopify、BASEなどのSaaSと言われるようなB2Bのビジネスモデルのサービスです。転職の振り返りでも書きましたが、2010年以降ではConsumer向けのサービスは寡占化が進んでいるので厳しく、

SaaSなどのB2Bの方がチャンスがあるのではと考えていました。

ところが、SaaS企業を転職活動中に見ていくと

「これってGoogle Spread Sheetで事足りるんじゃ？」

っていうサービスが多かったです。

つまり無料でできる事を合えてお金を払ってツールを使う訳がないってなります。

その点からも、個人開発や学生起業では太刀打ちできるものでもないかと思います。

2001年から2021年の期間で上場を達成した学生起業家13名

これらの見解からスマホアプリ開発もすでに寡占化していて、SaaS開発も飽和状態

2010年代ですら会社としてあるていど出資を受けてからでないと成功しないのに今の
2020年代から起業となるとさらに難しくメリットも少ない状況なのではと思います。

情報は平等という公平さが格差を広げていく

1990年代はまだ、情報が不十分で偏りがあったため、

「ネットビジネス市場が成長する」

という情報が平等にはいきわたらない状況ではあったものの今では「仮想通貨」が儲かる「NFTが儲かる」といった情報は瞬時に平等に伝わって飽和状態になります。

そんな中で自分にしか思いつかない起業して成功するアイデアが浮かぶのでしょうか？

そんな都合のいいことがおきるはずがないです

状況証拠としては仮に大学生が起業して成功したサービスがあったとしても、数多くの資金のある会社が買収しにいく、もしくは似たようなサービスをすぐに作ってしまう

FacebookがInstagramを買収して、snapchatの機能を開発したのが典型的な事例かと思います。

もう一つの証拠としてはかつてネット黎明期で名をはせたホリエモンやひろゆきは一度成功した経験があり実力もあり、知名度もあります。

それに加えて、資金もあり、人脈もあります。

そんなチャンスに恵まれた人たちですらインフルエンサーどまりとなっています。

これらの状況で起業して成功するビジネスモデルって一体なんでしょうか？
ほぼないんじゃないかと思います。

皮肉なことに情報が平等になればなるほど、実力や能力がある人が稼げるのではなく、

既にお金を持っている人がさらにお金を稼げる仕組みになってしまっているという事です。

チャンスのある領域

とはいえダメダメと否定するだけでは面白くないので、

ネットの歴史から色々可能性が少ない中成功しそうなサービスを絞りだしました。

	資金	やりたい事	スキル・知識
VR, メタバース	不要	×	各々のプラットフォーム独自 のスキル
古い産業に参入 DXコンサルタント	必要	〇 古い産業をシステムで改善	今あるITスキル　＋ 各々の産業の知識
フリーランス	不要	△ システムの仕事でも ただの労働者	自分の今持っているスキル

市場を独占しているプラットフォームにのっかってビジネスをする方法

Google Play, Apple Store	LINE, メルカリ
ブログ	ブロガー
Youtube, Instagram, Tiktok	インフルエンサー
VR, メタバース	ここがねらい目！？

プログラミングで開発する立場からするとどうしてもプラットフォームを作る発想になりがちですが、コーディングすることは一旦忘れてプラットフォームにのっかる事を考えて起業というか、お金を稼ぐ方法を考え見た方が成功する可能性が高いのではと思います。

今現時点で誰もが使っているメタバースやVRがないので、流行りそうなものに先取りしてその中で頑張れば何かしら稼げるかもしれないですが、果たしてVR・メタバースが今のスマホアプリぐらいな一般的なものになるのかは疑問の念が残るところです。

fortniteみたいなゲームが広義の意味でのメタバースなのであれば、今存在してますが、
もうすでに凄腕のゲーマーがいるので手遅れですね。

そもそも自分のやりたい事から大きくずれてもいます。

昭和の会社のDX化

他にチャンスがありそうな領域は古いしきたりがあるような業界で
システムを用いてディスラプトしていくといった起業がチャンスがあるのではと思います。
転職してた時の会社選びの軸ともかぶりまが。

そういった他業種参入で上手くいってる会社もいくつかあります

冠婚葬祭が未だに費用がバカ高いので、結婚のみんなのウェディング
葬儀屋のよりそうなどが上手くいっている会社の一つでもあります

２つとも会社からの資金があってはじめて成功したサービスなので、やはり時間が経つにつれて資金の額も大きくないと成功できないようになってはいます。

フリーランス・クライアントワーク

最後に残ったのが受託開発などのクライアントワークやフリーランスの仕事。
クライアントワークやOEMで起業の場合は投資する金額も０でも問題なく、
受託をすれば確実に報酬がもらえるので、成功する可能性は高くなりますが、
そうなると結局経営というより、下請けのただの労働者になってしまいます。

結局過去の記事にも書いたようにITゼネコンの最下層の仕事で割に合わない仕事が
中心になって「なんのために起業したんだろう？」ってなりそうです。

サービス起業年表をザックリ

念のためもう一度記載しますが、起業やサービス立ち上げには時期が重要でその表です。

2000年代	起業の時代
2010年代	弱小企業が淘汰もしくは買収され勝ち組企業が成長の時代
2020年代	GAFAMかそうでないかの時代

20年前であればネットビジネスで起業することを強くお勧めしますが、
2020年代になった今GAFAMが手を出しそうにないような利益率の低いビジネスを
狙わざるを得ないです。
日本政府が中国やEUのようにGAFAMに対して厳しい規制（
https://www.aljazeera.com/economy/2022/2/7/dataspatmeta-threatens-to-pull-facebook-instagram-from-europe
https://www.nikkei.com/article/DGXKZO32055000R20C18A6H56A00/
）をかけない限りは変革の時期ではなく2010年代をゆるやかにしたような市場を独占した企業がさらに伸びていく時代になるかと思います。

煽りは謳っている人のポジショントーク

よくIT企業を特集しているメディアやイノベーションサミットみたいな所では
「これから数年がさらに変化が起きる時代・革命の時代」
とあおる事が多いですが、自分個人の意見としては変化はより少なく安定していくのではと思います。
上記のニュースのリンクのように巨大ＩＴ企業がさらに成長して各国の政府を脅かす存在になることが予想されます

自分も若い時はそういったあおりを受けてその気になってました。
https://www.youtube.com/watch?v=fuP0bMvHhZM
未だに覚えているのは

「これから少ない資金でも能力があればいくらでも起業して成功できる」
「どんどん成功しやすい世の中になっている」

といった事を田端信太郎さんが言ってたのを真に受けてました

それから10年くらいが経ちどうなったかというとむしろ真逆で新規事業や起業の資金が高騰して、いくら能力があっても資金力がないと今の時代では到底不可能という状況になっています。

考えてみれば事業を成功する能力とはなんぞやとなるとその知識・アイデアの元がインターネットとなりそのインターネットがみんなに平等にあります。

そうなるとそもそも能力で人とアドバンテージをつけて事業を回すという事自体がしづらくなってきます。

そうなると、結局能力以外の人脈、資金、資産がある人・企業が勝ち残るっていう論理が成り立ちます。

これらの情報から起業を考えている人や新規事業を考えている人もいると思いますが
絶対にやめた方がいいです。

成功しません。

自分も新規事業案も数えきれないほど提案したり、起業も考えたりして、めちゃくちゃ好きなのですがITの技術者がはじめる起業の成功する可能性はほぼ０で年々さらに成功率は減少していきます。

それが現時点での結論です。

いや、そんな事ないよとここ最近で個人開発のサービスが成功したケースがあればコメントお願いします。

事業会社でのCTOの求人で想定内と想定外

希望通りの事業会社のCTO

希望通りシステムが弱く店舗経営している事業会社に入社することが決まりました。

入社する会社は上場している会社なのでオファーを承諾する前から調べるだけ調べる事にしました

代表取締役が65歳で他の取締役は全員70歳以上
社長の持ち株割合は15%以上なので、ワンマン社長が予想されます。
今までサラリーマン社長の会社だったので、ワンマン社長とかってが違ってきますが、
ワンマン社長の方が決断が早いのではと思います。

やはり昭和からの会社なので、色々な改善できそうな点が出てくる出てくる

メールが社内からしか使えない

メールサーバーがオンプレミス内にあって、オフィスとそのオンプレミス内のメールサーバーがIP-VPNでつながっているのでプライベートLAN内からのアクセスとしてメールサーバーがアクセスできるという仕組み

社外にでてしまうとメールが見れない。。こういった環境は10くらい前の環境に近かったです。
今やリモートワークが当たり前になっているのに、メールでのしばりがあったとは驚きの一つです。

あとで自社ドメインで運用するemailサービスをどれくらい安くできるかという記事を書こうと思います。

今この状況はオンプレミス内のメールサービスなので、メールアドレス単位での費用はかからないですが、それに対応する社内エンジニアの工数は取られると思います。

コーポレートサイトがhttpのまま

コーポレートサイトがSSL証明書の対応しておらずhttpのまま。

10年ぐらい前ならまだしも今の令和の時点でhttpのコーポレートサイトは怪しまれる
可能性もあるので、httpsにすべきかと思います。
SEOでも何年か前にHTTPSを推奨してるぐらいなので、会社の信頼を上げたいのであればHTTPSにすべきかと思います。

チャットツールなしのコミュニケーション

チャットワーク・slackを使い始めてから久しくもう慣れてしまったのでむしろそれなしで、よく仕事ができるなぁという状態です。
確かにチャットツールはお金がかかるので、導入には躊躇しますが、社内のコミュニケーションが電話とメールになると、コミュニケーションのコストがだいぶかかります。
チャットツールに慣れて、それなしの現場で働けばなおさら効率の悪さが際立ちます。
電話の場合は相手方が何をやってるのか知ったこっちゃないっていうコミュニケーションになってしまいます。
かける相手が集中したくて作業しているのか、ミーティング中なのか、外出してたりしてて作業してたら作業効率はさがってしまいますし、お客様と話してたら印象は悪くなってしまいます。
かけてもいないことが多いので、折り返すのも効率が悪いです。
電話で聞かれても調べないとすぐに回答ができない場合も結局折り返して電話ってなり
じゃぁ、初めからメッセージで要件だけを書いてってなります。
メールの場合は社外のクライアントとかであればメールしかないと思いますが、社内のみのやりとりにEmailを使うと非効率極まりないです。
「○○チーム　○○さん、お疲れ様です。小松です。　～～～　以上です。」
をちょっとした返信でも必要なのが非効率で且つ面倒です。
それだけじゃなくて、チャットツールであれば間違えて別のクライアントに機密情報が入ってるメールを送信することもないので、セキュリティ的にもEmailでの運用はできる限りすくなくすべきかと思います。
Emailでのコミュニケーションが主流になっている場合はEmailの添付を開くことになんの抵抗もない人がほとんどだと思います。
社内で添付付きのEmailでのやりとりに慣れてしまって、ついSPAMや悪意のあるEmailからの添付を開いてしまいウイルスに感染する可能性が大幅に増えてしまいます。
チャットツールを使えばスマホからでも確認がしやすいので移動が多い人、リモートワークの人はそれなしでは働けないはずなのですが、まだまだ電話とメールに頼っています。

タイムカード

高校生の時によくタイムカードで打刻してたのを覚えてますが、社会人になってからタイムカードの打刻で勤怠管理している所は初めてです。

打刻の時刻を派遣スタッフがいちいち目視で見てエクセルに反映して給料計算しているという作業でもこの令和の今でもまかり通っているとの事です。

どんな高いSaaSを選んでもコスト削減と効率アップにつながることは間違いないかと思います。

BIツールが高い

何をどう分析するかにもよりけりですが、BIツールとかは無料からかなり高額のツールまで千差万別です。
また、ある人はAnalyticsを使い、またある人はGrafanaを使い、またある人はDataStudioを使いとそれの有料版になってしまえばその分お金もかかってきてしまいます。

従業員の共通認識も増やす意味でBIツールはできる限り少なく済ませる方が無難かと思います。

以前の職場でも数千万円かけてとある会社から購入して、構築したりしてましたが、結局なんの役にも立ってなかったので、月額コストがかかることもあり、廃棄することになりました。

SQLができない場合スタッフにRDBMSのデータを検索させたいという無料ツールでも結構あると思うので、のちに紹介していこうと思います。

SaaSやツールのコストが高い

社長がITを知らないことをいいことにBIツールにしても、ECサイトにしても、マーケティング広告にしても色々な業者がハイエナのごとくたかってきます。

寄ってくる数ある業者の中から勝ち得た業者がECサイトを売り込んできて年間数千万円という法外な料金で契約させられています。

グーグルマイビジネスを使用していない

店舗経営しているにも関わらずグーグルマイビジネスを利用していないとなると競合他社と比べてかなり厳しい戦いを強いられる事になるかと思います。

グーグルマイビジネスのコンテンツの最適化だけでいけばそこまで工数も取られないので、真っ先に行うべき事項だと思います。

ファイルサーバーが社内にある

ファイルサーバーもIP-VPN内に独自のサーバーを立てて運用しています。

SaaSを使うかどうかはデータ量との兼ね合いですが、ファイルサーバー内の整理ができてなくて容量が膨大になって立ち行かなくなるって事もあるあるかと思います。

これに関してはSaaS導入よりもデータ・ファイルの整理、方針決めの方が大事な気がしますね。

Google Spread Sheetを多用すればファイルサーバーの容量の削減できますし、SaaSの導入前にGoogle Spread Sheetで検討してみると結構お金払わなくてもできるもんだったりします。

ファックスとハンコ文化

プリンタの複合機が何台もあって、印刷して見せる、もしくは承認するという文化もできる限りペーパレスで業務を行えるようにしないと、全国の店舗となるとわりと頻繁に複合機が動かないって事になります。

修理や設定のコストがばかにならなくなります。

そのためにはクラウドサインなどのツールが必要になってきます。
承認が必要なワークフローのジョブカンを導入したときは幹部からそうとうな非難をされたそうです。
なぜなら幹部は高齢なので、新しいツールを使いたくない、使えないって事になりそうだからそうです。
それだけでなく、今まで承認していた幹部からすれば、契約書なりの紙を持ってきてもらい頭を下げて「お願いします」と目の前で言われて承認するとったフローだったところに威厳を見せることができました。
その承認する過程が一番の仕事の見せ所だった幹部からすれば、ツールの導入で顔も見合わせずワンクリックで済んでしまう事に不満を抱いてしまうのではと思います。

予約、問い合わせが電話がメイン

電話アプリを使えば電話機の分だけコスト削減にもつながります。
予約に関してもカレンダーアプリを使っていないので、ミーティングや会議室を取る時は電話やメールでいちいちメモして確認するしかない。

CRMも店舗経営であればLINEの問い合わせを使えばより多くの顧客を獲得もできますし、現に競合他社を含めた多くの会社がLINEを問い合わせや予約などに活用しています。

改善できる点はあるけれど

このように改善できる点は山のようにあり、むしろこのような状況でよく利益が出ているなぁと思うくらいです。
そこで、改善できる点を一つずつ最適化していけば、小さいことの積み重ねでより多くの利益をもたらせることができる「ゲームチェンジャー」になれると思い期待が大きく膨らんでいきました

しかし

そうなれないという大きな理由があることに気づきました。

変化が嫌い

ゲームチェンジャーという文字にチェンジャーという文字があります。
変化を促す人みたいな意味ですが、その組織自体がこの変化を許容できないと組織も変化できないし、自分自身もゲームチェンジャーになりえないです。

組織の幹部が高齢の場合、変化をとてつもなく嫌がります。そう
変化が嫌いなのです。
そうなると、何一つ運用の変化＝改善ができなくなってしまいます。

その理由以外にも想定しきれなかった事があります。

いきなり信頼は勝ち取れない

今回、転職活動をしてCTOなどのシステムのトップというポジションを探していましたが
ほとんどの場合、既にシステムのトップは在籍済みでその直下でのポジションで社長直下ではなかったです。

入社したリサイクルショップはCTOのポジションで社長じきじきの面接だったので、これしかないと思いオファーを承諾しました。

しかし

考えてもみればわかったことかもしれませんが、社長からすればどれだけ実績が
あった人物でも「知らない人」になるわけです。
20代前半ならまだしも、60歳以上の人からするとこれまでも信頼を勝ち取ろうとしてきた人は多かったはずです。
そんな状況でたかだか1回あっただけの「知らない人」にCTOのポジションを任せて
会社の命運を託す経営ではあまりにもリスクが高すぎます。
なので、入社してから気づいたのですが、CTOのポジションとは名ばかりで結局複数人いる中の社長の取り巻きの一人でしかありません。
とは言え、そうなることはごく自然ではあり、そこから信頼を勝ち取っていけばいいだけの話ではあるのですが、ここまで裁量がないって事は大きな驚きの一つでした。

タイトルはどうであろうと、小さい仕事から少しずつ裁量の大きい仕事をもらえるように持っていくかがポイントになるかと思います。

結論

今回、転職活動を通してわかった結論は
ゲームチェンジャーになれるポジションなんて存在しない
という事。
採用する会社側からすれば、募集しているポジションで十分に発揮して
ゲームチェンジャーになれると方便でいえるかもしれないです。

でも少なくとも自分の一番の実績である赤字の会社を黒字にするぐらいの
大きな裁量をもったポジションは存在しない。

もしくは今の経歴では不可能という事を実感しました

じゃぁ、これからどうする？

それをもう一度考えなおす必要が出てきました。

退職・転職活動ふりかえり

2か月ぐらい転職活動をしてたので、退職・転職を通しての情報や
自分の方向性の変遷をメモしておこうと思いブログにアップしました。
新しい会社に入ってからの感想も含めて記載していこうと思います。

自分の価値

IT市場で転職活動するにあたって自分の価値を客観的に見た場合一番の価値は

エンジニアのチームが全員同じタイミングで退職して一人で
会社を支えて乗り切ったこと

ずっと赤字だった会社をシステムを全てリプレイスして
業務効率を極限にまで最適化して数億円の利益が出る会社に作り上げた事

この２点が自分の大きなアピールポイントかと思います。
自分の中ではかなりの偉業を成し遂げたと思っていたので、
転職すれば引く手あまた、かなりいい転職ができると思ってました。

実際面接の時の反応も技術よりの会社であればあるほどどれだけこの2点の偉業が
大変かをわかってもらい反応がよかったです。

これ以外でざっくり自分のスキルをできる限り客観的に見てみると
「なんでもできる」になってしまいます。
プログラミング、フロントエンド、LinuxのほかにWEB、ロードバランスの設定
AWSの運用、MySQLなどのDBの設計 etc etc
広義の意味でのスキルに関して誰にも負けない自信はあるのですが、
WEBサービスであればSaaSであろうが、B2Cであろうが、「なんでもできる」
になってしまい採用する側からすれば「浅く広く」そして「薄い」人材に見られてしまいます。

なので、想定していたよりも書類選考落ちが多かったのもそれが原因だったのではと思います

なぜ退職？

退職せずにずっと同じ会社働くことも選択肢の一つとしてあることはありました。
現場では会社を復活させた英雄扱いされ尊敬はされていますし
給料や待遇も悪くはなかったです。

でも居心地がよすぎると成長しなくなるような感じもしていました。
それに、リプレイスの大仕事が終わって約2年がたちいいシステムを作りすぎてしまい
時間に余裕ができすぎてしまったのもあります。
5年後も同じような仕事しかしていないようなイメージしかできなかったので、
自分のキャリア的にも成長という観点からもチャレンジもかねて転職してみようと考えました

志望の軸

次に７年間務めた会社を辞めて次に何を目指すのか、自分のキャリア・スキルがどれくらい
市場で刺さるのかも含めて転職しながら方向性を決めていくような形となりました。

はじめは何も考えずに下のような希望の軸で考えていました。
上から優先順位が高く

会社	時価総額が高い、非上場であれば出資がどれだけされてるか
年収	1000万円以上
ポジション	マネージャー
待遇	リモート可や年間休日日数など

みたいに漠然とした軸で初期の方は探してたと思います。

自分に合ってる仕事と会社は？

採用ステップが進むに連れて具体的な求人が選別されて面接までいきます。

その中で楽天の面接が印象的でした。
自分の経歴を話すとやはり一人で持ちこたえた所が刺さったみたいでした。

その求人の仕事内容は
・20人くらいのエンジニアをまとめる管理
・他部署との調整
という仕事内容で会社の規模は楽天というECのトップ企業で有名なので
会社の規模的には問題なかったです。

会社	ECトップ　時価総額1兆以上
年収	1000万円以上
ポジション	マネージャー
仕事内容	エンジニア20人の管理 他部署との調整

一流企業の素晴らしい会社なので、年収も待遇（リモートではないけど。。）
も問題はなかったのですが、自分が楽天で働く事を考えたら、マネージャーとはいえ
歯車になってしまい、なおかつ待遇がいいので、

そのポジションをキープするような保守的な行動になってしまうんじゃないかと思いました。

楽天から転職する時にはポジション、会社の規模、年収、待遇の面で悪くなる可能性が
高くなってしまい、
どうしてもそのポジションから離れたくないという保守的になってしまうのではと思いました。
また、仕事内容も限定的でサーバーのトラブル対応をすることもなければ、
プログラミングもすることない限定的な仕事ないようでもありました。
考えてみるとそれが正しい組織のあり方なのかもしれませんが

自分のスキルをもっと活かせる仕事があるのではとも思いました。

そういった理由により1時面接は受かったものの辞退することになりました。

他部署との調整であったり、管理のみになると自分の持ち味が出せずに他の人でも
やれるんじゃないかって思ったりもしました。

リクルート時代の時の仕事内容と似ていて
「嫌われず舐められず」という人間関係をキープする仕事が中心になってしまうんじゃないかとも想像できました。

自分ではWEBサービス一通り全てできるので、

プログラミングからサーバー構築、DB設計
全てを活かせるポジションとなると楽天のような大きな会社ではそういった求人はなく
どうしても会社の規模もしくはシステムチームの規模が小さくなってしまうんじゃないかと気づきはじめてた時でした。

ゲームチェンジャーになりたい

どの会社でも人間関係はよくなったり、悪くなったりするもんで悪くなった場合
会社を辞めたいけど次行く会社で今以上にいいのがないからストレスを抱えながら
同じ会社にしがみつくっていう事に陥りそうな気もしました

そのほかにも、以前に転職エージェントからモノタロウのマネージャーポジションのお誘いがあった時も年収が1200万円、完全リモートで待遇はかなりよかったのですが、歯車感は否めず「ゲームチェンジャーになりたいので辞退します」って言った事はありました。

という事で転職する際の会社の規模は必然的に小さい方が自分に合ってるという事になりました。

なので希望する軸はこう変わりました

ポジション	CTO候補ではなくて本当のNo.1 上司は社長のみ
会社	成長しそうな会社 自分の手で成長させたいから

その軸にしてからDMMから面接のオファーがありました。

ポジション	プログラマー
会社	上場はしてないけど巨大IT企業
年収	1000万円

ポジションも会社の規模も合わずゲームチェンジャーになれないので、辞退しました

CTO募集ってだいたい嘘

それからいくつかSaaS系の会社からの面接のオファーがあり、面接しましたが、
なかなか思った通りの企業は現れなかったです。

求人ではCTO募集と言っていながら既にCTOが会社にいてCTOと面接という会社がほとんどでした。
とりあえずハイクラスの人材が欲しい時はCTO募集って記載しているのでしょうかねぇ～。
過去の記事にも書きましたが、エンジニアが既に在籍してるのにCTOを募集したり、VPOEを募集したりしている組織は組織として終わっているかと思います。
ハイクラスの人材を雇わなくてもいい状況をつくらなければいけません。

2020年以降は全てのIT市場が飽和状態

中には本当に社長面接でCTOのポジションもありましたが、
事業内容が成長しそうに感じなかったりしたので辞退しました。

この「成長しそう」な企業ですが、2021年時点でこれから伸びそうなIT企業・スタートアップってかなり難しいんじゃないかって思います。
需要がある市場には既にその市場を占有して落ち着いている状態が今の状態だと思うんで、誰もが思いつくようなB2Cはすでに飽和状態でB2B・SaaSがねらい目だと思ったのですが、

SaaSもほぼほぼスプレッドシートとかのGoogleの無料サービスで事足りるんじゃ？
っていうサービスを提供している企業がほとんどのように感じました

なので、ITのスタートアップよりシステム以外で儲けている会社のDX推進している会社に自分が入ってゲームチェンジャーになれるのではと考え始めました。

なんでCTOのポジションを募集しているの？

面接していくうえでCTO枠のポジションなので、なぜ今CTOがいないのか？
どうやって今まで開発していたのか？
という質問に対しては海外を含む外部の業務委託者が開発していたと回答でした。
そこで考えたのは、じゃぁ、そもそも正社員でCTOのポジションを探すのではなくて
フリーランスで業務委託を受けて、お互いに合えばその会社のCTOという形で社員になるという形が自然じゃないかとも考え始めました。

なので、希望の軸は

ポジション	採用、設計、技術選定ができる立場 フリーランスでも可
会社	システムに弱い事業会社

という風に切り替えました。

事業会社のDX推進室

その軸に切り替えて転職活動を進めていきました。

そのように絞りだされた会社が葬儀屋、カラオケ屋、リサイクルショップとなり
ご縁があってリサイクルショップからオファーが来て入社することになりました。

上場している会社なので、役員の組織の情報は公表されています。
なんと社長が65歳で他取締役は全員70歳を超えています。

リサイクルショップの店舗経営しているのにグーグルマイビジネスの登録されておらず
まったくシステムに弱い会社という印象を受けました

ゲームチェンジャーになれるまさにこういう会社を望んでいました。

役員がネット、システムに詳しくないので自分が入ることによりゲームチェンジャーになって売上、利益、時価総額を上げれるのではと希望を抱いて入社に踏み切りました
が
入社してから気づいた想定外の事がありました。
そのことについては次回で詳しく

#11 CSSのテクニックを使えばJavascriptなしで実現できて速度もUP

youtu.be

今回はCSSの話をしたいと思います。
普段はあまり重要でないと思われているcssですが、
ベストプラクティスを知らないとネットワークリソースを浪費
したり、無駄なコーディングをすることにつながるのでとても重要です。

1.javascriptよりcss
2.CSSスプライト
3.scssは不要

1.CSSでできるならできる限りCSSを使うべきです。

例えばバリデーションのCSSの擬似クラスを
使用すればjavascriptでわざわざコーディングしなくてもいい事はあります。

まずはじめはcssで数値のみ且つ1文字以上５文字未満という
バリデーションを作成します。

次にvuejsでバリデーションを作成します。

computedもしくはwatchを使えばリアルタイムでバリデーションできると
思いますが、さらに時間がかかるためチェックボタンを用意して
methodsを使うことにしました。

ソースコードを見ても分かる通りjavascriptでバリデーションすると
CSSに比べると複雑になっている事がわかります。
なのでJavascriptよりCSSの方が簡単に時間をかけずに作成することができます。

これらの理由で本来はJavascriptよりもCSSを使うべきなのですが、多くの
エンジニアが故意にJavascriptを使いたがります。
その理由は先程も述べたようにJavasciptは応用が効いてより柔軟に
作成できるので確実に作りたい機能を作成できます。
そのためCSSで実現できるかどうかを確認する前に
Javascriptで作成してしまう理由があります。

それ以外にはJavascriptの方がCSSよりもはるかに需要が多いので
経歴書に「CSSでバリデーションを実現」と記載するより、
「Vuejsでバリデーションを実現」と記載したほうが経歴書の見栄えがよくなって
しまいます。
そうなると、できる限り多くJavascriptで書きたくなってしまうエンジニアが
多くなってしまいます、しかし、本質的にはCSSで実現出来たほうがいいので、
CSSでできる限り使用することをおすすめします。

2.アイコンはCSSスプライトを使うとネットワークの通信のやり取りを10数回から
1回にできるのでネットワークリソースの節約ができ、スピードも早くなります。
CSSスプライトとは使用する複数のアイコンを一つの画像に合成して、その画像を
CSSでバックグランドイメージと扱う事です。

画像を合成しないといけない事と
position,画像の幅、高さを調整しないといけないため、時間がかかりますが、
WEBのユーザー体験の観点からミリセカンドでも早くしたほうがいいので、
このCSSスプライトを多用してスピードアップを向上させたほうがいいかと思います。

この動画では元々アイコンが３つそれぞれ違うアイコンとして画像取得していた所を
CSSスプライトを利用して、１つの画像として取得してネットワークのやりとりを
３回から１回に減らしています。
本番のページではもっとより多くのアイコンを利用されると思いますので
このネットワークの減らせる量も増えるかと思います。

3.最後にscss,sassについてですが、コンパイルが必要で元々
CSSは簡単に書けて書いてすぐに確認、リリースできるのがいい点なのですが、
そんな所をコード量を少なくするためにあえて
環境を用意して、別ファイルにするのは面倒です。
さらにコンパイルしないといけないのでページ確認のために
毎回コンパイルしないといけないのは時間がかかるのと本番と開発のCSSコードが
違ってきて本番のデバッグを難しくさせるので「コード量を少なくする」に対しての
デメリットの方が大きく上回っているのでおすすめはしません。
javascriptの最適化の動画でも実証しましたが、google のページインサイトでは
キャッシュを考慮しないためインラインの方が速いと証明しています。
SEOもキャッシュを考慮しないのでSEOが必要なページは
インラインを多用したほうがいいのですが、
SCSSではそもそもインラインでコーディングすることはできません。
マイページなどSEOとは関係ないページではキャッシュの効果が大きいですが、
CSSを一つのファイルにしてキャッシュさせたとしても
訪れることのないページのCSSまでキャッシュさせることはその分パフォーマンス
が下がってしまいます。なので、全てブラウザキャッシュありきというわけではなく
ユーザーのアクセス回遊具合によって決める事がいいのではと思います。

#10 Linuxとネットワークのベストプラクティス

youtu.be

「DBのベストプラクティス」の動画でも説明したようにLinuxでも
基本的にはLinux特有の機能はできる限り抑えて
できる限り誰もが知っているPHPやPythonのサーバーサイドプログラミングで
機能開発すべきです。

なので、Linuxですべき機能はあっても
デプロイ、ログ収集、監視設定
ぐらいかと思います。

iptablesに関してもできる限り最低限の設定で済ませるべきです。
アクセス元のIPをブロックするなどは、PHP,Goなどで制御して
iptablesではプライベートネットワークを許し、webアクセスを許すといった
最低限の設定を一律全てのサーバーにすべきです。

例えば、Linuxに詳しい人はiptablesでポートフォワーディングできるので、
HTTPアクセスを別のサーバーに転送することも可能ですが、そうしてしまうと
ほとんどの人が知らない中そんな設定をされると現場が大混乱してしまいます。

クラウドのベンダー選定ですが、「AWSエンジニアの悲劇」でも取り上げたように
AWSを使うとろくなことないので、AWSは使わないようにしましょう。
その他のGCP,Azureも同じく高いのでやめておきましょう

さくらの専用サーバーはコンソール画面のログインの2段階認証機能があるので、
セキュリティが高いのとコンソール画面がターミナルと同じように使えるので
おすすめです。

Kagoyaに関してはさくらインターネットは北海道に集中しているので
ディザスタリカバリ DR の事を考えて開発用、DRバックアップ用
として考えておくといいかと思います。ただし２段階認証やコンソールからの
ターミナルが使いにくい所がマイナスです。

Time4VPSはリトアニアの激安VPSベンダーです。
安いさくらVPSのさらに３分の１ぐらいの値段です。
ただ、サーバーがリトアニアで地理的に遠いのでSSH接続は若干遅いです。
２段階認証、ブラウザからのターミナル、
プライベートネットワークもサポートしているので、
デメリットはなく素晴らしいサービスですが、
実績がないので大規模な本番のシステムに組み込むのは
少し躊躇します。
Kagoyaと同じようにディザスタリカバリ DR や開発用であればまず問題ないと思います。

以前の大規模システムの構築の時はさくらVPSを多めで
スケールアップよりもスケールアウトを心がけて
さくらの専用サーバは少なめに設計しましたが、サーバーが増えると
監視などの管理が大変になってくるのと、同じサーバーに
複数のサービスを立てたほうがリソース消費は少なく済むため
さくらの専用サーバでネットワーク構築することが望ましいかと思います。

なぜスケールアップよりスケールアウトを心がけていたかというと
スケールアップに頼るとどうしてもサーバーのスペックがどんどん上がってしまい
高額になってしまいますし、サーバーのスケールアップには限界があるので、
その限界に来た時には手におえない状態になる可能性があります。

例えばDBのスロークエリーが多くなってきたので、メモリを増設してDBのキャッシュ
に頼るとその一時しのぎであれば解決できますが、
DBのキャッシュもSQLのパターンが増えれば
すぐにその増設したメモリでは足りなくなってきてしまうので、
根本的なDBの設計とSQLを見直さないといけません。

しかし、その時点で時既に遅しで深みにハマってしまっているので
どうしようもなくなっている現場もありました。

なので、いつでもスケールアウトできる仕組みで
専用サーバーで構築するのがベストかと思います。

プライベートネットワークを構築する前提で踏み台サーバーの設定を
説明します。

iptables,linuxアカウントの設定のみ踏み台サーバーの設定が違うので
先にこの２つの説明をしていきます。
iptablesの設定は
プライベートネットワークは全許可
WEBも許可
NTPやICMP,PING、ループバックも許可

踏み台サーバーの時のみsshのポートを許可する設定をします。
セキュリティのため念には念を入れsshのポートは22から
違うポートの39870にしています。39870は決めの問題で適当な番号を
指定すればいいかと思います。

踏み台サーバー以外のサーバーではSSHのポートはpublic向けには
開放しないので、設定なしでOKです。

Linuxのアカウントですが、踏み台サーバーのみ各スタッフ用の
アカウントを作成して、各部門もしくはチームのグループを踏み台サーバーで
あらかじめ用意しておいて、所属しているグループにアカウントを追加します。

そうする事で踏み台サーバー以外のサーバーはスタッフのアカウントは追加せず
engineerなどのチーム単位をLinuxのアカウントとして登録するだけで済みます。

以前は全てのサーバーにスタッフ分、エンジニアの数をLinuxのアカウント作成
していましたが、スタッフが入退職するたびに全てのサーバーに入って
アカウントの追加、削除が必要でコストがかかり大変でした。

踏み台サーバーだけにスタッフのアカウントを用意すれば、入退職があった場合も
踏み台サーバーだけを変更すればいいです。

サーバーの追加の時もチーム単位のアカウントのみの作成で済むので、楽できます。

オペレータなどのアカウントはほとんどのケースで不要で、サーバーから生成される
CSVなどをSFTPで取得する時とかに必要なぐらいです。

なので、だいたいのサーバーはエンジニアが使う共有アカウント１つで十分かと思います。
このようなネットワーク構成であれば運用コストもかからず済みます。

セキュリティリスクが高くなるのではと考える人もいるかもですが、
踏み台経由でしかサーバーにアクセスできないようにすれば、作業ログも取得できて
監視できるので、セキュリティレベルも変わらないと思います。

１回踏み台にログインした時のログはbash_historyにログが保存され、
ポートフォワーディングの場合は/var/log/secureにログが保存されます。
bash_historyの履歴変更できないようにするにはchattrを使えば防げます。

全サーバー共通の設定をざっくり解説していきます。

linux userはあらかじめ生成バッチなどを用意してたほうが
運用が楽かと思います。
engineerというグループにこのアカウントをアサインしています。
ssh keyの空ファイル生成までの設定をしています。

visudoの設定はCRITICALのコマンドを定義して
グループのengineerにアサインします。
CRITICALのコマンド以外は何でもOKにしています。

アカウントとvisudoはrootで行う必要があるので、管理者が
設定を行う必要がありますが、
これ以降は一般Linuxユーザーでもできるので、管理者以外の
エンジニアに任せたほうがいいかと思います。

sshの設定でポート番号は踏み台のみ設定変更で問題ないと思います。
それ以下の設定はrootでのSSHログインを禁止
パスワードログインを禁止
等の設定をしています。

FirewalldとSELinuxの無効化の設定します。

hostnamectl set-hostname ＜HOSTNAME＞
でホストネームを変更します。

これらの設定が全サーバーにインストールしてからの必須の設定です。
この必須の設定ドキュメントはgitでバージョン管理すればいいかと思います。

PHP,Go,MySQL,PostgreSQL,nginxなどは各サービスの担当エンジニアに
任せればいいかと思います。

サーバーのスペックはさくらの専用サーバーで現在一番安いサーバーで
４コア、メモリ８GB、SSD５００GBのサーバーを標準にすればいいかと思います。

大量アクセスが想定されるロードバランサーに使う場合は回線の
帯域幅を上げるといった設計が必要になるかと思います。

画像とDBのアーカイブ、バックアップサーバーについて。
どれだけ大きいサービスでも
DBのフルダンプでだいたい最大で２０GBぐらいかと思います。

それ以上になるとログ系のデータが含まれていたり、
メンテナンスで物理削除していないとか、アーカイブ化していないとかの
設計ミスかと思います。

どんな大きなサービスでもDBサーバーが５，６つぐらいかと思いますので
１００GBぐらいがDBのバックアップで充分かと思います。

世代管理もしてても今まで古い世代のリストアをしたことがないので、
最新のバックアップのみで問題ないかと思います。

なので先程の標準のサーバーを選択しておけばデータのバックアップ兼
サーバーの物理障害兼、ステージングサーバーとして扱えるかと思います。

画像に関してはサービスによって大きく変わってくるので、相当数
必要な場合は専用サーバーのディスクをあらかじめ多めのHDDにしておく
なりの対処が必要です。

AIの画像解析サーバーが必要な時がありましたが、どれくらいの負荷がどこに
影響するのかわからなかったので、
その場合はすぐにスペック変更できるようにさくらのクラウドにしました。

ディザスタリカバリ、開発用サーバーでまずディザスタリカバリ用に
先程の本番のダンプファイルを保存するサーバーを用意しておく必要があります。

まずディザスタリカバリとは？
ですが、地震、戦争などでデータセンターそのものが破壊された時の事を考えて
地理的に違うサーバーでバックアップファイルを用意しておく事です。

なので、もしさくらのメインのデータセンターの北海道に何かあった場合は
大阪、東京とかのサーバーを使うべきですが、全員が全員同じさくらのサーバーに
引っ越してきたらさすがに大阪、東京のさくらのデータセンターもパンクしてしまう
のではと思うので、念の為違うベンダーにしています。

DR用のディスク容量は最低でも２００GBのキャパシティのサーバーにすべきかと思います。

そこに保存するだけではなく、実際にDBを立ててリストアします。
リストアしたデータで機密情報のあるデータを適当なダミーデータに変更します。
変更後ダンプします。
そのダンプを開発用のサーバーに送ります。

そうすることによって、開発用サーバーでいつでもほぼ本番と同じデータが手元に
あるので、開発→テストがしやすい状況が作れます。

これらの構築ができる状態というのは開発初期ではなく運用のフェーズに入った段階
での作業でそこまで緊急に優先度が高いわけではないと思います。

本番のデータがあるディザスタリカバリ用のサーバーはあくまで管理者のみが
使えるようにして、開発用サーバーとはアカウントもろもろ完全に別に切り離して
おくべきです。

これらが、Linuxのネットワーク構成も含めたベストプラクティスでした。

間違っている、改善点などがあればコメントで指摘してもらえればと思います。