はてなキーワード: SAASとは
1年目は半分以上が研修で教えてもらうばかりで給料もらって申し訳ないなんて思ってた。
2年目に運用チームに一人だけの女性で入れられて分からないなりに業務をしてた。開発チームが炎上して休日も夜間も作業することになり、インフラの面倒を見ている運用チームのメンバーもローテーションで付き合う羽目になった。
男性メンバーは問答無用でローテーションに入れられた(休出は少なめにしてほしい、みたいな希望は出せた)けど私にはどうする?って質問が来たので「休出も夜間もちょっと…」って渋ったら、たしか「女性が夜間は不安だよね」って言ってもらえたのかな。言葉はもう覚えてないけど私だけ通常勤務、他のメンバーは通常+ローテーション勤務になった。
鎮火に1年ちょっとかかって開発が落ち着いたのは結局3年ちょい過ぎたくらい。その間もちょくちょく休出や夜間作業があったけど私は一回もローテーションに入れられてない。
今は炎上に付き合ってた運用メンバーが作ったansibleやterraformやスクリプトで運用してるんだけど、私は炎上対応中に作られたそれらを手順書通りに実行することしかしていない。
炎上に付き合ってたメンバーは新規プロダクトの打ち合わせにも参加して開発チームと一緒に残業してスクリプトを改修したり作成したりしてるけど、私は定時出社定時帰宅で手順書通りにツールを使ってる。
私だけ楽しちゃって悪いなって思っていたらちょっと前の部長面談で事務系か営業系への配置転換を打診された。「うちの不備で申し訳ないんだけど、開発が燃えてる時に一緒にやってくれる運用じゃないと作業止まっちゃうから」って。
事務だと給与は大幅に下がる。営業は歩合制で今と同じだけ稼げるとは思えない。配置転換を断った場合はどうなるのか聞けなかった。
転職サイトを漁ってオンライン面談もいくつか受けてみたけど私にはスキルも資格も圧倒的に足りてないことが分かっただけだった。
部長面談の返事は5月末までにしなきゃいけない。ここのところ帰宅した後はずっとどうしようかどうなるのか不安な気持ちにしかならない。
https://www.sofia-inc.com/blog/7233.html
情シス(情報システム部)はもういらない?これからの情シスに求められる、あるべき姿とは?
皆さんは情シス(情報システム部)が果たす役割・機能を何だと考えますか? 全社のIT戦略策定・システム企画、社内インフラやアプリの保守・運用、ユーザーサポートやトラブル対応といったことを思い浮かべる方が多いのではないでしょうか。
しかし昨今、情シスにそのような役割が求められていない、もしくは情シスの業務自体がなくなりつつあることをご存知でしょうか?
今回の記事では、これからの時代の情シスに求められる役割、あるべき姿について説明します。
近年Microsoft AzureやAmazon Web Serviceといったクラウドサービスの台頭により、オンプレミスからクラウドへの流れが起きています。社内に物理サーバーを置いて保守・運用するといった必要がなくなり、ソフトウェアもPaaS・SaaSといったクラウド上で提供されるサービスに代替されるようになってきています。それに伴い、膨大な設備投資費や社内SE(システムエンジニア)の人件費を削減できるようになりました。今後すべてのITリソースの保守が必要なくなるという可能性もあります。
デジタルトランスフォーメーション(DX)が多くの企業で重要課題となっている現代において、企業がIT活用で目指すべきことは、単純にITインフラ・ツールを変革させるということではありません。業務変革・組織変革を伴うような、より大きな次元での変革です。経済産業省も、ITを変えるだけがDXではないと説明しています。
「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」
このデジタルトランスフォーメーションの実現を企業が目指すにあたって、情シスの仕事も大きく転換しようとしているのです。次章では、まず従来の情シスの役割について整理・紹介していきます。
DX(デジタルトランスフォーメーション)を推進する上で押さえておきたい3つのステップ
昨今ビジネスの場において、DX(デジタルトランスフォーメーション)という概念が頻繁に取り上げられるようになりま…
これまでの情シスに求められていた役割は主に以下の4つでした。
会社の経営戦略や事業戦略に基づき、システムの企画立案・要件定義をする役割です。社外ベンダーの見積もり検討・選定、およびその後のプロジェクトマネジメントを遂行し、ユーザー部門に対して新しいシステムを開発・提供します。
社内ユーザー部門からのリクエストや業務プロセスの変更に応え、既存システムのカスタマイズなどを実施します。運用・保守によってシステムを安定稼働させ、会社の事業活動を下支えする役割を担います。
自社サーバーやネットワークの構築・運用・保守を行いつつ、セキュリティ対策やデータ保全を実施することで、万が一の事態に備えます。また新技術・製品の導入検討や評価を行って、常に社内環境のサービス向上に努める役割です。
社内ユーザーからの問い合わせ対応・トラブルシューティングを行います。ツールやシステムの導入サポートの他、新卒や転職者へ社内システムの教育を実施することで、社員1人1人の円滑な業務遂行を支援します。
以上が従来情シスに求められてきた役割ですが、現在のクラウド時代において運用・保守業務はその必要性を失っています。また業務システムについても、SaaSなどのクラウド上で提供されるアプリケーションを利用できるようになっており、企業独自でシステムを構築するということは少なくなっているのです。
このような中で、今後情シスには一体どんな役割が求められてくるのでしょうか。次章で詳しく解説していきます。
クラウドで提供される業務システムは、往々にして業務の生産性に関する考え方が先進的であり、しかも随時バージョンアップしていきます。従って「自分の行動にシステムを合わせる」のではなく「システムに自分の行動を合わせる」というのが日常的に求められるのです。
しかし事業部門をはじめとする多くの社内ユーザーは、旧来の業務のやり方に慣れ親しんでいるために、「システムに自分の行動を合わせる」ということに自力で順応するのが容易ではありません。システムを使いこなせないばかりか、新しいテクノロジーに対して抵抗感を覚えてしまうケースもあります。
そこで必要となるのが、自社の業界・事業・業務においてITツールをどうやって活用するかを考え、そのための情報を関係各所へ提供する存在です。これからの情シスには、システムの機能や技術面だけでなく現場の業務プロセスにまで入り込み、具体的なユースケースを提案・サポートすることで、全社的なIT活用を推進する役割が求められています。
また、会社としてDXを推進するうえでは、単にITツールを組織的に活用することだけでなく、同時にチェンジマネジメント(組織変革)を進めていくことが必要です。新しいワークスタイルを実現するためには、職場の文化・風土も変革していかなければなりません。次章ではDXを促進する立場としての情シスの役割について紹介します。
クラウドサービスの台頭でIT部門の仕事がなくなる 企業のIT部門の仕事、と聞いて何を思い浮かべるだろうか。自社の…
DXを促進する情シス(情報システム部)の役割と専門家との協働
デジタルトランスフォーメーションにおいて最も上手くいかないことの1つとして、先進的なITツールに対して個人個人の理解度・受容度が追い付いていけず、会社として変化を受け容れられないことが挙げられます。ツールの機能、業務プロセスへの適用法が分からないことで現場が混乱し、これまでの業務のやり方やワークスタイルから脱却できないといったことがそれにあたります。
これを解決するために必要となる活動が会社のカルチャーチェンジ、社員一人一人のマインドチェンジです。単にITツールの活用法をナビゲートするのみならず、業務プロセスや職場の文化・風土というところまで踏み込んで、ユーザー部門に対して新しいワークスタイルの実現に向けた啓蒙活動を展開していったり、全社的な意識改革に向けたコミュニケーションを展開していったりといった役割がDX推進には不可欠なのです。
しかしこの役割は、専任のDX部門が担おうとしても失敗するケースがあるほど難しいものであり、そもそも経営層が事業戦略におけるITの重要性を十分に認識していなければ到底実現できるものではありません。では、情シスがDXを推進する役割を担っていくためにはどのようなアプローチをしたら良いのでしょうか。
それは情シスが持つIT知識や社内システムへの知見を最大限利用し、経営層を巻き込んで企業を変革する旗振りをしていくことです。ただし限られたリソースの中で上層部や会社全体に働きかけるというのは非常に負担が大きく、失敗に終わる可能性も大いにありえます。そこで1つの解決策となるのが、そういった業務改革・組織改革の支援を行うITベンダーと協働することです。高い技術力と豊富な支援実績を持ったITベンダーが上層部への答申からITツールの全社展開まで幅広く支援してくれます。そして、組織風土変革や社内へのコミュケーションは、自社の人事部門や広報部門が実務として実施していきます。現場部門との協働はもちろんですが、変革を企画する部門と協働することで、より全社的なムーブメントをつながります。
まとめ
以上のように、近年情シス(情報システム部)に求められる役割は大きく転換してきています。従来担ってきたITインフラやシステムの構築・保守・運用業務は不要となり、今後はデジタルトランスフォーメーション(DX)実現へ向けた社内ユーザーへの情報提供・啓蒙活動を行っていくことがその使命となっていきます。
もしあなたが情シスのメンバーであり、従来の役割を脱却できずにいるのであれば、業務改革・組織改革支援を行うITベンダーの活用を検討してみてはいかがでしょうか。
転職活動中で医療系ベンチャー初年度年収650万のところに内定したんだが、
どうやら話聞いてると最近資金調達終わって今頑張って作ってますよーの段階らしい、現時点では全く利益出せてないし先行きが本当にわかんない
資金調達額的には2,3年くらいは食えてけそうな気もするけど
正直話聞いた感じ技術スタックとか構築難易度から考えても相場よりだいぶ高い年収だし、起業家社長や人事がエンジニアの相場観わかってない感じがあってそれも逆に不安だったりする
多分俺の市場価値より多分かなり高い額になってる、転職やってる自分の相場観としては「500万までのスカウトは山程来るけど600万はあんまり来ない」ってレベル
一応リーダー経験とかフロント/バックエンド両方担当してSaasを1から主導構築とかテックリードとかいろいろ経験はあるけどどれも小さい会社だし専門卒だしPHPがキャリアの中心だしそんなもんかなって気はしてる
正直多少給与帯下げても好きな技術スタックの会社狙って安定狙いたいみたいな気持ちはあるけど、
でもこの年収の肩書あれば婚活で戦ったとき有利かなぁとかも思うしどうしようかなって、
先行き怪しいベンチャーに危機感抱きつつも勤めることにして年収で釣って仮に婚活成功したとして年収100万くらい下がったら簡単に捨てられちゃいそうだよなぁって……
技術職だし倒産して仕事クビってなっても食っていけなくなるみたいな心配は全くしてないけどさぁ
どうしたらいいと思う?
転職歴としては1社目は新卒で入った地元の零細受託Web制作会社→4年前くらいに転職し現在自社サービス企業に勤務中。
ちなみにまだ内定は0件。
コロナを機にフルリモート案件が増えたのと、リーダー経験とか積むにつれて市場価値と今の職場が合わなくなってきたのがあるのと、
今の年収だと婚活で戦うのはかなりきついということを実感したので動き出すことに。現年収は400万ちょっとくらい。
専門卒で経験はPHP/JS中心だから経験してきた技術スタックや学歴的にはあんまり上位狙えるようなアレじゃないんけど今回は心が折れるまでは初年度年収600万を目指すことに。
現職でのリーダー経験と、Saasを立ち上げから設計・開発全部8割型自分で進めて競合と戦えるサービスに成長させた経験とか、ゼロイチで既存案件をDDDに移行したりテスト駆動体制を導入したりとか、まあまあ個人開発もやってますよとかその辺をアピールポイントとして戦うことに。
肌感覚としては「500万までは余裕だけど600万はきつい」だわ。
まず某転職サイトに応募すると早速600万のスカウトが来たユニコーン系ベンチャー。フルリモート。
「貴方のSaas開発経験に魅力を感じ~」とか書いてたから誰でも送ってる風じゃないと思い応募。
結果はなんと書類選考落ち。いや学歴とか職務経歴とかほぼ転職サイトにそのまま書いとったやん。
恐らくだけど選考時にGithubアカウントとかTwitterアカウントを求められたときに仕事用のものはセキュリティ上渡せないとか渋ったのと、
渋々渡した個人用Githubアカウントはオープンソース活動とかはしたことなかったからこれがしょぼいって思われたのかな?って思った
ちなみにこの会社からは書類選考落ち後に各転職サイトから5回くらいスカウトが来てる。
大手っていうわけではないけど割と有名なSaas企業。こっちもスカウト。転職サイトの上の方でよく見る気がする。
結構近しい分野のSaasを立ち上げから関わったことがあるのでこちらを武器に面接へ。1次面接落ち。
面接は割とうまく行ったと思うけどなぁ、って思ったけどやっぱりフルリモートでこの給与帯の休日は倍率半端なさそうだからちょっと良いくらいだと全然落ちるんだなと実感。
立ち上げから3年も経っていないベンチャー、ただし既に利益率は割と凄い感じで業界的にも硬そうだから応募。
カジュアル面談のときにCTOに是非応募してほしいって直接言われた。
1次の技術面接のレベルがたけぇ。○○の設計思想の内容だとかDIコンテナとかReactの状態管理用ライブラリの運用とかの質問をクイズ形式っぽく質問される。
割とうまく答えられたと思ったけど1次面接落ち。
有名地元に拠点がある東証一部上場の自社サービス企業。600万の求人と450万の求人で分かれてて600万の方で応募したら書類選考で「600万は厳しいけど450万なら良いですよ~」って言われてる状態。
やっぱ相場観的にはそうだよなぁって思った。
今週1次選考だけど受かっても年収交渉時に450万しかもらえないなら辞退しちゃうかも。
有名医療系ベンチャーと車業界系のSaas。カジュアル面談の要請出すも音沙汰なし。
別の転職サイトで確認すると応募条件大卒以上って書いてたから多分それが原因。ちゃんと書いとけや。実質書類落ち。
少人数の建築系ベンチャー。HPの情報量も少なく恐らく資金調達のフェーズでは?って感じの企業。
なんとなく社長から与沢翼の匂いがする。まだマネタイズまで行けてないのに何百億とか何兆とかやたらでかい数字を言いたがる感じ。
技術スタックに対して年収が高すぎるのが逆に怪しい感じがする。
一応最終選考まで残ってるが、通ったとして行くべきかは悩みどころ……
スカウト来て応募。かなり好感触だが求人票と実態の下限年収に相違あって思ってた年収より100万くらい下がりそう。
去年末くらいから始めた転職活動。今週も面接面接面談面談面接。
自分の市場価値みたいなところは良くも悪くも痛感する。500万までのスカウトはよく来るけど600万になるとやっぱなかなかこない。これが相場観なんだろうなって感じ。
「テックリード」とか「シニア」とかのスカウトは全く来ないからまだそういうレベルではないんだなぁって。
「誰もが知る有名企業で年収600万」は多分俺のスペックだと無理ゲーで、あとはいかに穴場のベンチャー狙えるかっていうところにかかってる感じ。
それはそれで安定捨てて市場価値より高い会社に勤める感じになるわけだし将来トータルで考えるとそれはそれで大丈夫なの?って感じもある。
でも専門卒じゃ20代現年収600万くらい武器ないと婚活じゃ戦えないしなぁとも……はよ彼女作ってこの悩みから開放されたい……
エントリーする度にそこで働く未来の自分を思い浮かべるのに祈られた瞬間に全部がなかったことになるの辛い
あとカジュアル面談受けまくってるけど、これが割と面白かったりする。
「こんな有名企業だけどQAは俺がリーダーやってる案件のがカバレッジ率とかしっかりしてるんだー、バグったら人が死ぬタイプのシステムじゃないし逆に今の運用が過剰品質すぎなのかなぁ」「LeSSって開発手法あるんだー」「前職も現職もSelenium導入って微妙な感じになってるけどこのMablってテストツールだと割と良い感じかも」「今の職場みたいに運用フェーズのエンジニア部署でKPI設定を半期ごとに設定するのは粒度がでかすぎるよなぁ、この会社みたいに1ヶ月周期とかで設定した方がよさそう」「ワーカーサーバーの悩むポイントはどこも同じだなぁ、でもやっぱGoだとPHPよりも並列処理強いんだなぁ」
他の会社の運用とか技術スタックの話を深堀りして質問しまくれる機会とかなかなかないから、落ちたは落ちたなりに吸収できるものはある気がする。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策(不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス)を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能)
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策(不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス)を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能)
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
2022年1月14日(金)奥平 等(ITジャーナリスト/コンセプト・プランナー)
地方発の中小企業からグローバルなデジタルプラットフォーマーへ──決して荒唐無稽な話ではない。すでにシリーズAによる資金調達を果たし、上場へ向けて確かな歩みを続ける企業がある。1960年、奈良県天理市で自動車整備工場として創業したファーストグループである。現在は天理市と東京都渋谷区に本社を置き、自らの事業を「グローバルカーライフテックサービス」と位置づけ、全国の自動車整備工場にSaaS型マーケティングサービスを提供している。本稿では、地方の自動車整備工場がデジタルトランスフォーメーション(DX)に挑む同社のビジョンと打ち手に迫ってみたい。
自動車販売の「オートアフターマーケット」と聞くと、脇役的なイメージがあるかもしれない。だが実のところ、各種の市場調査データからファーストグループが算出した市場規模は下記のとおりで、自動車整備市場だけで実に5兆5000億円に達している(図1)。また、国内外300社以上が出展する国際展示会が開催されるなど、グローバルでも確固たる市場が築かれている。
図1:オートアフターマーケット市場規模(出典:ファーストグループ。自動車年鑑2019、自販連、自軽協統計資料、平成30年整備振興会整備白書を基に調査)
一方、矢野経済研究所が2021年3月に発表した調査によると、2020年の国内自動車アフターマーケット市場規模は19兆14億円。ここには「中古車(小売、輸出、買い取り、オークション)」「自動車賃貸(リース、レンタカー、カーシェアリング)」「部品・用品(カー用品、補修部品、リサイクル部品)」「整備(整備、整備機器)」「その他関連サービス(自動車保険、ロードサービス)」の5事業が含まれている。
前年比1.8%減と2年連続で微減しているものの、2019年10月の消費税増税や2020年2月に顕在化した新型コロナウイルス感染症(COVID-19)の感染拡大をもろに受けて新車販売台数が前年比11.5%減(日本自動車販売協会連合会の発表)と大幅に落ち込んだことと比較すると、マイナス幅は小さいと言える。
ファーストグループ 代表取締役社長の藤堂高明氏(写真1)は、「実はオートアフターマーケット、とりわけ自動車整備市場はリーマンショックやギリシャショック、そして今回のコロナ禍においても大きな影響を受けなかった不況に強い産業なのです」として、その理由を次のように話す。
写真2:ファーストグループ 代表取締役社長の藤堂高明氏(出典:ファーストグループ)
「理由は大きく3つあります。最も大きいのが、道路運送車両法に定められた車検(自動車継続検査)があること。自動車の所有者は半ば強制的に整備工場に足を運ぶこととなります。次に、定期点検やオイル交換などに代表される定期接触が必須のビジネスであること。そして、サービスの供給側と利用側の情報格差が大きく、供給側主導のビジネスとなっていることです」
こうして、オートアフターマーケットは不況に強いビジネスではあるが、年々飛躍的な成長を遂げているかというと、残念ながらそうではない。その背景に、従業員が少ない小規模な工場が地方に分散しているというこの市場の形態がある。ディーラー系を除いた小規模な自動車整備工場は全国に約5万7000も事業所があるが、メカニックエンジニアや経営の後継者の不足などに悩まされ、ここ数年は減少傾向に転じているという。
また、ガソリンスタンドが付加価値の提供を目指したサービスステーションにシフトしていること、整備入庫を包含したビジネスモデルへの再編を狙うメーカー系ディーラーをはじめとする異業種の囲い込みなど、厳しい外的環境にもさらされている。
それでも、藤堂氏はこの市場のポテンシャルに注目する。「全国に約5万7000事業所。この数って、実はコンビニエンスストアの出店数に匹敵します。さらに、ディーラー系を含めると9万事業所を超えるわけですから、コンビニが出店のために費やしてきたコストや労力を考えれば、こんな魅力的な業界は他にないのではないでしょうか」(藤堂氏)
「同時に、これは私の試算にすぎませんが、日本に8000万台あると言われている自動車の登録台数からの換算で、その資産価値総額は約200兆円に上ります。商圏を2~5kmに絞り、1事業所あたり1000人の顧客がいたとして、1台あたり100万円としても10億円規模の資産を預かるビジネスとなるわけです。自社の課題を克服して、ラストワンマイルの発想で、いわゆる自動車整備工場から脱却して、1人ひとりのカーライフを支えるビジネスパートナーとしての地位を担えれば、大きな飛躍があると確信しています」(同氏)
ファーストグループが掲げるミッションは「カーライフ革命で人々に喜びと感動を」、企業ビジョンは「GLOBAL No.1 CAR LIFE TECH COMPANY─世界の人々から最も必要とされるカーライフカンパニーへ─」である。
この壮大なミッションとビジョンに辿り着くまでに、ファーストグループは実際にどのような手法とプロセスで自社の変革を進めてきたのであろうか。藤堂氏は、同社が決して特別な存在ではなかったことを物語るエピソードとして、「父から引き継いだ段階で毎年7000万円の赤字を垂れ流していた企業だった」と振り返る。その歴史と変遷をたどってみよう。
2007年、先代社長の他界をきっかけにMBO(Management Buyout)により事業を取得、2代目を継承した藤堂氏は先頭に立ってマーケティング指向の経営管理手法で企業再生に着手、翌年には黒字転換を達成する。成長への第1ステップは、自らが培ったその再生モデルを武器に、「同様の課題に直面している全国の自動車整備工場を元気にする」(同氏)ことにあった。
それは、いわゆる買収・再生モデルの横展開だが、実際にはそこにも紆余曲折があり、2つの段階を踏まえて、進化と深化を図っていった。①資産・負債のすべてを原則譲り受けるM&Aモデル、②事業のみ譲渡を受け、土地・建物を賃貸借して継続させる賃貸借モデル。この2段階のプロセスを実践した14年間で、ファーストグループは年商1.5億円を約30倍の50億円に拡大したという。
具体的な打ち手はバリューチェーンの創出だ。ファーストグループが特化しようとするカーライフにまつわるマーケットは、①車検をはじめとするメンテナンス領域、②更新が見込まれる保険領域、③カーライフのサイクルを最適化する車両販売領域、④万が一の事故に備えた各種サービス領域に大別される(図2)。
図2:カーライフマーケットにおけるバリューチェーン(出典:ファーストグループ)
拡大画像表示
しかしながら、これまでの自動車整備工場はその一端となるメンテナンス領域のみで、事業の維持に努めてきた。つまり、顧客とのライフタイムバリューを最大化するチャンスを逃してきたのである。そこで、藤堂氏は、同社が買収・再生を手がけてきた自動車整備工場に対し、徹底的にバリューチェーンの創出に注力した。
藤堂氏は、カーライフにまつわるサービスが多岐にわたることを、同氏のシミュレーションを示して力説する。「18歳で初めて免許を取得した若者が生涯にわたってクルマにかける費用は最低でも1600万円。高級車に乗られる方はその何倍ものコストを費やすことになるはずです」(同氏)
藤堂氏によると、これまでの自動車整備工場は車検や修理に依存した事業形態から抜け出すことができず、カーライフの起点とも言えるクルマの販売にはあまり積極的ではなく、むしろ苦手としていました。
「ところが、その壁をクリアさえすれば、バリューチェーンは簡単に創出できるのです。車両販売を手がけて成果を上げれば、自らのメンテナンス領域の仕事も増えて安定します。さらに販売時に必要となる保険やさまざまなサービスを包含して提供する窓口にもなれば、さまざまな異業種の人たちとの接点が生まれ、エコシステムが形成されます。つまり、バリューチェーンによって、LTVの最大化と事業ポートフォリオ変革を同時に成し遂げられるというわけです」(藤堂氏)
ファーストグループ自身が先陣を切って、このバリューチェーンの創造とエコシステム構築に取り組んだ。すると、瞬く間に車検の年間受注件数が急増し、奈良県内では断トツの年間1万件を超えるまでになったという。メーカー系ディーラーが何十年もかかって達成した件数を、ごく短期間で凌駕するまでになったのだ。年商は1.5億円から、現在では実に30倍の50億円に達している。
俺、今地方の自社サービス開発企業に勤めててその中ではテックリード的な立場で、
Saasのシステムを設計フェーズから1から構築したこともあるし、
他にもレガシー目なサービスにDDDやクリーンアーキテクチャ的思想を導入したりTDDの構築と運用へあたっての体制構築や教育を主導したりとか
面接官「うわ。こいつ、実績何もなさそう。面接官受けしそうな言葉ならべてるだけやな・・これ。この人は”面接が”上手い人なんだな。。」
今地方の自社サービス開発企業に勤めててその中ではテックリード的な立場。
Saasのシステムを設計フェーズから1から構築したこともあるし、
他にもレガシー目なサービスにDDDやクリーンアーキテクチャ的思想を導入したりTDDの構築と運用へあたっての体制構築や教育を主導したりとか
メンバーのスキルに偏りがある状態でも品質維持するための体制をなんとか作ったりとか
小さい企業ながら割と経験詰めたし今なら転職とか余裕だよなーって思ったがなかなかうまくいかない。
今のところ3社受けて全部1次面接落ち。受けたのは転職サイトのトップページに一番大きく載ってるような人気企業だから倍率は結構高い気はする。
今のところフルリモートで初年度年収550万~600万くらいを目指してる。多分500万くらいまで水準下げれば求人めっちゃ増えるし余裕な気はする。
あっちからスカウトが来て、競合ではないけど似たようなサービスを俺も構築した経験があったから
御社の製品の○○機能(リリースされたらプレスリリース打つくらいの機能)と似たようなものを営業にほしいと言われてから2日後にはテストカバレッジ率100%の状態でリリースまで持っていきましたとか、
当時はリソース足りず自分一人でほぼ全部対応してたけど爆速でリリースサイクル回して1年で機能数的にも競合製品に負けないくらいまで成長させましたとかこれ以上ないくらいアピールしたよ。
なーにが行けなかったんだろう。やっぱコミュ障なのが影響してんのかなぁ。「えーっとまあ」とか「なんか」「えーーそうですね…」みたいなのが多いのは自覚してる。
フルリモートで給与も高水準だと倍率高いから、もしかしたら20人中の1人や2人採用で第3位だったとかかもしれない。
何をどう変えたらいかなぁ。
転職指南書に書いているようなHPの企業理念読んで面接官が喜びそうなことを事前に作文して頭に叩き込んでおくみたいなことはやりたくないんだよね。
俺会社じゃ面接官する側だけどポートフォリオとか職務経歴しょぼいのに口だけ凄いこといってると
「ああ、この人面接官喜ばすための言葉を事前に作文してきたんだろうなーーー」「この人は”面接が”上手い人なんだな」とかやっぱ内心思っちゃうし
まあ応募して落とされて凹んでまた応募してを繰り返すしかないのかな。
どことは言わないけれど最近AWSで障害が起きるとサービスが利用できません!みたいなことを書く企業多いよね
でもそれちがくない?AWSのサービスを受けているのはSaaS企業であってSaaS企業が提供するサービスを使うユーザじゃないよね?
ユーザに対してサービスを提供出来ないのはSaaS企業の責任なのだからサーバ障害等で利用できない、現在復旧方法などを検討中ならわかるんだ
だけど、AWSの障害だから何も出来ません!復旧をお待ちください!みたいなのを見ると違うでしょ?
課題解決をするんだ!みたいに意識高いことを言っているが、サービスが継続出来ないのをクラウドのせいだからしょうがない!っていうのちがくない?
資金調達とかSaaSとかベンチャーとかスタートアップとかベンチャーキャピタルとか、そういうキラキラとは別な零細自営業について語ります。
特に戦略とか持たずに、のんべんだらりと会社をやってきたおっさんの独り言です。同時期に会社を急速に伸ばした人を見ると、自分のだめさ加減が露呈して辛い。
家族のケアをしながらできる働き方はないかと模索したところ、「起業、、、ありかも」と思い立ち、友人知人から仕事を集めたらなんとかなりそうなことが判明。
よっしゃ、辞めるぞ、ということで、転職から1年未満で退職。退職時は、同じ会社の人に結構微妙な対応をされる。まあ、そりゃ実績も出さずに1年未満で辞める人にかける言葉もないよな。辛い。
退職直後は、友人知人からご祝儀の仕事が来て結構ウハウハとなるが、その後、ご祝儀案件がすぐ蒸発。辛い。
「あなたに任せるよりも、安いインターンに任せることにしました」という屈辱的なこともたくさん言われる。辛い。
友人と共同で受けた案件、お客さん会社の社長がパワハラ気味で、やった作業を簡単にひっくりかえすx3を食らう。辛い。
この時点でサラリーマン仕事6ヶ月(給与)+自営業6ヶ月(売上)=800-900万円
友人からの仕事で食いつなぎつつ、クラウドソーシング。辛い。1文字1円のライター業とかやる。格安SIMがどうとか、転職がどうとか、そんな記事を量産する。
格安SIM記事なんて、定められた構成に従い、機械的に書くだけ。書く機械。人ではない。そして、1円ライターでも「もっとちゃんと書け」と怒られる。辛い。
それ以外にもクラウドソーシングのよくわからない案件をこなす。光通信系の会社の人から「プロだと思って頼んだら全然だめですね」と言われる。辛い。
新卒で入社した会社が結構有名企業だったので、「あー、あんな有名な会社に勤めていたのに、そのまま勤めていれば年収もずいぶん高かっただろうに、いまは1円ライターやっているのかー」と自分を客観視すると、辛い。
単価高いITエンジニアがうらやましくて仕方ない。ああ、どうしてプログラミングやらなかったのだろうと人生を後悔する。辛い。
元同僚の会社の営業代行などしてしのぐ。営業なんて大嫌いなのに。辛い。
自営業12ヶ月(売上)=700-800万円
クラウドソーシングの受注案件から強引に営業したら、月額30万円くらいの安定収入になる。嬉しい!
営業代行仕事も好調で結構売上が伸びる。ただ、営業対応と出張が多いのと、売上にならない案件フォローとかがかなり面倒。フォロー遅れると怒られる。辛い。
家族のうつ病が再び悪化。仕事したいのに、やる気もあるのに、張り付いていないといけなくて仕事できない日が増える。辛い。
Switch買ったら、昔のゲームやるのが面白すぎて仕事が進まない。でも止められない。作業遅れ多発。辛い。
また別な継続案件を口コミで受注するも、親会社が推奨する会社にリプレースされてしまい、一瞬で案件なくなる。辛い。
業界違いの案件を受けたら、「メールかChatworkで連絡してください」としたにも関わらず、毎日電話くる。そのうえ、レスが悪いと怒られて案件終わる。辛い。
自営業12ヶ月(売上)=1000-1100万円
子供が生まれる。しかも双子!嬉しい!でも、お金なくて色々申し訳ない。旅行するときに、泊まりたいホテルでなくて、安いホテルから順に調べないといけない。辛い。
行きたいタイミングで旅行に行けず、カードのマイルを使って特典航空券が空いているタイミングを選ばないといけない。辛い。
元同僚の営業代行していた会社から、いいがかりをつけられて売上が減少。新卒で入社したときは、楽しく酒を飲み交わしたことを思い出す。一緒に仕事しなければ友情は続いたのだろうに悲しい。紙の契約書がないって辛い。
売上どうしようと思い悩んでいたところ、交通事故にあい、そのさなかにクラウドソーシング経由で営業した安定収入案件を失注。辛い。
別な友人経由で仕事をもらうが、「すみませんが、成果でないですね」と言われ、2ヶ月で切られる。辛い。
コロナで友人知人と会えず、精神的なバランスも崩れる。精神的なバランスが崩れても、息子たちのおむつ替えもミルクも待ってくれない。辛い。
自営業12ヶ月(売上)=700-800万円
知人からの紹介で再び別の案件を受注。月30万円くらい。嬉しい。
他の案件がほとんどなくなり、辛い。業績低迷を理由にコロナ融資受ける。ある意味コロナの恩恵を受ける。うちみたいな会社にお金貸してくれるなんて最高。大好き日本国。
妻から、「稼ぎが悪い、お金がないから子供の服を1着買うのも悩む、友人は家を買っているのにうちは車すら買えない、ちゃんと考えずに会社経営しているだろ、融資返せるのか」と言われる。辛い。
さすがに食っていけないので、ほぼフルリモートでサラリーマンも再開する。成功できずサラリーマンに都落ちした気持ちになる。恥ずかしい。辛い。
ただ、普通に考えて自分の会社の仕事しながら、サラリーマンやるのは普通に考えて無理がある。溺れながら時々顔を出して仕事をしている感を装っているような感じ。情けないし辛い。
自営業12ヶ月(売上)+サラリーマン4ヶ月=700-800万円
2022年予定
来年は、サラリーマン年収が1000-1100万円+自営業が600万円。結局自営業の金額はしょぼいので、ダメ社長だ。辛い。
金額全体が増えたのはうれしいが、仕事をコントロールできず溺れている。自分の会社もサラリーマン仕事も完璧にできていない。だましている感が強い。辛い。
大学時代の同期は、キラキラベンチャーでCxOして資産数十億円築いたり、コンサルで上り詰めたり、起業して成功したり、外資系の部長職で年収3000-4000万くらいのポジションについている。羨ましくて仕方ない。辛い。
さて、1Q決算が発表されたので見ていきましょう。
今回のソース
https://ssl4.eir-parts.net/doc/3930/tdnet/2054543/00.pdf
前年同期比で見ていきます。
決算期 | 売上高 | 営業益 | 経常益 | 最終益 |
---|---|---|---|---|
20年8-10 | 570 | 30 | 30 | 19 |
21年8-10 | 733 | 69 | 71 | 49 |
変化 | 28.6% | 230% | 240% | 260% |
はてな大勝利!!!!!!!!!!!!!!!!!!!!!!!!!!!
とはなりません。
残念ながら。
当たり前ですが去年はコロナ直撃していますので異常値が出ています。
決算期 | 売上高 | 営業益 | 経常益 | 最終益 |
---|---|---|---|---|
19年8-10 | 617 | 72 | 75 | 51 |
21年8-10 | 733 | 69 | 71 | 49 |
変化 | 15.9% | -4% | -5% | -4% |
おやおや。
何故利益が圧迫されているのでしょうか。
中長期的な企業価値の向上への取り組みの結果、営業費用(売上原価と販売費及び一般管理費の合計)については
663,913千円(前年同期は539,799千円)となりました。主な増加要因は、広告レベニューシェアに伴う収益配分原価
が増加したこと、主要3サービス拡張と事業創出のため、人材投資を積極的に行ったことによります。人材への経営
資源の配分は、当社が将来にわたり、競争優位性を確保するために、収益基盤の確立に向けた成長戦略投資として位
要するに、広告原価とエンジニアの雇用による人件費が上がったことによって、利益が圧迫されたようです。
では、次は雇ったエンジニアで何をしているのか、事業ごとの売上を見ていきましょう。
四半期ごとの事業別売上は今回はじめて登場したので、前年比較はできません。
広告 | SaaS |
---|---|
73.7 | 49.2 |
計 | 122.9 |
広告 | SaaS |
---|---|
62.6 | 112.4 |
計 | 175.1 |
開発保守 | SaaS |
---|---|
246.5 | 188.5 |
計 | 453 |
見てわかるように現在のはてなはテクノロジーソリューションが主力事業です。
はてブの売上なんてものはコンテンツプラットフォームの広告の一部だと考えられますので、
せいぜい数千万円と言ったところです。
さて、主力事業のテクノロジーソリューションをもうちょい見てみましょう。
https://ssl4.eir-parts.net/doc/3930/ir_material_for_fiscal_ym/106320/00.pdf
・マンガビューワーのGigaViewer
・カクヨム
開発がどのぐらいかわかりませんが、
ほとんどがテクノロジーソリューションに割り振られてるんじゃないかと思います。
伸びしろのないコンテンツプラットフォームに割り振る意味はないのでこれは正しい選択だと思います。
伸びしろのなさは前回のを見てください。
はてなの今後は、出版DXでどれだけ存在感を発揮できるかにかかっているんじゃないでしょうか。
死にたくて死にたくてしかたない。
生きる希望をみつけたくて、ヒルティ、アラン、シューペンハウエルの幸福論を読んだ。そこには理屈が書いてあった。しかし自分が死にたいのは理屈のせいではないと思う。もちろん病院にも言っている。メンタル系の病院で大量の薬を処方されている。リモートワークで仕事もしている。それなりの給料ももらっていた。けれど健康診断で異常な結果が出て、精密検査を受けた結果、高額な手術を受けて入院しなければならないことが明らかになってきた。
手術して2週間入院すると、その間の日割分の月給の収入を失うことも踏まえると、恐ろしく高額だと思う。もちろんいままでちゃんと働いてきていてついこないだまではまとまった貯金があった。しかし老後2000万円必要になることを考えると、資産運用するしかないと思って投資をはじめた。そのとたんにコロナショックがやってきたり、急にSaaS銘柄があがらなくなって海運株と半導体株の時代がきたかと思うと、FRBパウエル議長再任で金利が爆上げしてまたすべてが飛んでいった。そう気がついたら、お金がぜんぜんなくなっていた。そして体調不良のためスキルを発揮できず、収入も約半分ぐらいに減らされてしまった。それぞれは小さなことだった。けれど、ひとつひとつと増えていく重しによって、もともと希死念慮が強かった俺のメンタルは、本当の限界をむかえつつあるような気がしている。
友達もいない。彼女もいない。食欲もない。飯は一日一度の冷凍食品。タバコは吸わないが、酒は500mlで170円の安酒を飲む。ストロングゼロではない。もっとアルコールの低いやつだ。オタクみたいな顏してるかもしれないがオタク知識さえなく、チー牛みたいな顏してるがチー牛を頼む金もない。趣味もない。何をやっても、虚しくなる。疲れてしまう。そして死にたくなる。こんな人生になることを、若いうちに気づいていればよかった。気づいていたのかもしれない。気づいたとしても、できることはなにもなかったのかもしれない。