マーケオタクのボヤキ:風情(ふぜい)

2020年の年の暮れ、仕事がほぼ終わったころにこのネタの下書きを書き始めています。いきなりネタバラシかよ、とお思いでしょうが、2020年の年末に思ったことの一つとして、「今年は季節感が全く感じられない一年だったなぁ」という感情でした。

2020年はコロナの年

「コロナ元年」とでも言いますか、新型コロナウィルス(COVID-19)の感染が拡大し、感染拡大を食い止めるための自主的な自粛や公的な措置に伴って、季節的なイベントなども軒並み中止、外出の機会も減って、とにかくCOVID-19に振り回された一年でした。「新しい生活様式/New Normal」という言葉が盛んに叫ばれ始め、それに伴うソーシャルディスタンスだの巣ごもり消費だのといった新しい言葉も多数生まれ、マーケティング的にも今まで(の潮流)とは異なる動きに戸惑いがあったように思えてなりません。

もっとも、2020年は気候的にも、冬は暖冬で雪の便りもなかなか届かず、梅雨はほぼ平年並みの期間だったとはいえ関東ではずっと雨が降り続く当たり年、梅雨が明けて夏本番、と思いきや9月に入ってからはずっと涼しい日が続き一気に秋の様相を見せ、そのまま年末に向かう、という、あまりメリハリのない(印象に残らない)気候で、そういった意味でも「季節感」の薄さはあったのだと思いますが、やはり季節によって変わる人の動きが制限されていたことで更に季節感が薄れてしまったのではないか、と思っています。

マーケティングと「季節」

マーケティングにおいて季節感は密接に関係しています。「デジタルマーケティング」という世界では関係ないと言う人たちもいますし、季節に関係なく売れるものは世の中には存在しますが、そうは言っても時期によって売れる売れない、ということは一般的には季節と関係していると考えていいのです*1

これが、人の動きも制限され、イベントなども控えられてしまうとどうなるか。2020年の例で言えば、オリンピック需要を見越したマーケティングが失敗、というか活動自体ができなくなってしまうことになりましたし、消費行動自体の変化がもともと考えていたマーケティング施策と合わなくなってしまったり、根本的な見直しが必要になってくる、という識者の声は多く聞かれます。ただ、私に言わせれば「そりゃ当たり前」で、キーワードとして挙げられる『新しい生活様式』に合わせたマーケティングは必要ですし、楽観的に「すぐに今までの消費行動に戻るだろう」と今までと同じ施策を打っていても売れることはもうないですし、生活スタイルの大きな変容に気付かないままのマーケティングは無意味だと私は思います。

とは言え、COVID-19で日本の四季がなくなったのか、と言えばそれはまた違うわけで、生活様式とは別に「季節」を意識したマーケティングはまだ使えますし、むしろ消費者に季節感を強く意識させることでメリハリを感じてもらうことだってできるんではないのかな、と思ったりはします。

季節と風情、わびさび

実はこの記事を書くまで「風情」という言葉が日本特有のものであったとは知らなかったのですが...。

ja.wikipedia.org

「風情」は「わび」「さび」などと同じく日本的な美意識なのだそうで、

一般的に、長い時間を経て大自然によりもたらされる物体の劣化や、本来あるべき日本の四季が造り出す、儚いもの、質素なもの、空虚なものの中にある美しさや趣や情緒を見つけ、心で感じるということ

で、わびさびがどちらかと言うと廃れていくものに対する感情であることに対して、より「移ろい」に重きを置いているのが風情かな、という印象を受けます。桜は咲けば必ず散るし、新芽の萌黄色も季節が変われば鮮やかな緑色からさらには紅葉の時期に赤くなったり黄色くなったり。葉が落ちれば一面の銀世界、そして春に戻り、雪解けを迎えると間もなく桜が...、と、季節が繰り返し、失われるものの代わりに新しい何かが生まれるという、仏教的(輪廻転生)な移ろいが風情なんだろう、と理解をしています*2

よくマーケティングで耳にする季節概念として、『二十四節気』があります。更に二十四節気の1つを3つに分けた、『七十二候』というのもあって、どちらもその時期の季節を表す言葉になっています。だからと言って、例えば今が(二十四節気の)「小満(5月下旬)」だから、または(七十二候の)「麦秋至(5月末)」だから、〇〇を売り出すべし、みたいな話には直接はならないのですが、農作物や農産加工品であればそういった季節と収穫はリンクしていたりしますし、年間計画をしているマーケティング施策のトリガーとして使うというやり方もあります(「春分の日特別セール」、みたいな感じで)。

こういった「風情」をマーケティングにもっと取り入れてもいいんではないのかな、と思うんです。それこそ季節感をあまり感じられなくなった今だからこそ、「夏こそ」「冬だから」みたいなキーワードは、イベント中止や巣ごもりで季節のメリハリがなくなった今こそいいフック(キーワード)になるんではないのかな、と思うのですが。

科学的アプローチは必須

さて、ここまで「季節感が」と延々と非科学的なことを述べてきたわけですが、そもそも季節感とマーケティングを結びつけるために必要なものは「エビデンス」だったりします。好例なのは、「土用のうなぎ」の話でしょうか。

ja.wikipedia.org

「平賀源内がうなぎ屋から相談を受けて...」というくだりは真偽はともかく、他の時期に比べて夏場はうなぎ屋の売上が落ちていたというエビデンスがあってこそ、「夏にうなぎを売る口実(マーケティング施策)を作る」必要があり、それが諸説ある土用のうなぎエピソードにつながっているようにも思えます*3。正直ベースで考えれば、旬の季節だから新物を売り出すし、旬と真逆の時期は売るものもない(または貯蔵品だけ)のであまり売れないし、となるのですが、売れないタイミングがある、ということを「仕方ない」と考えずに、その時期だからこそ売れるようにする、というのがマーケティングの真髄だと思います*4

COVID-19で売上が落ちた、という方も多いと思いますが、それは本当にCOVID-19の感染拡大に伴うものなのでしょうか。大きく言えばそうかもしれないのですが、もっと細かい要因があるのではないでしょうか。例えば居酒屋。飲食店はどの業態も軒並み売上が減ったと耳にします。大きく言えば確かに「コロナのせい」なんですが、そのせいで『何が起こったのか』そして、代わりに消費者は『何をしたのか(または何もしなかったのか)』という問いかけは売上減少の分析と対策には必要なことです*5

「風情」を感じるマーケティング

クリエイティブ面では意識されることが多い「風情」であったり季節感ですが、全体的な施策の方向性に「風情」が組み込まれることで、より消費者の消費意欲を高めることが可能です。そして、マーケティングを実施する側にとっても、効率的な施策実施が見込めます。例えばホームページの掲載内容を季節によって変更するというケースでも、「年明けなので」「夏なので」みたいなざっくりとしたスケジューリングから、「年末年始は12月〇日~1月〇日なので」「夏商戦を〇月〇日~〇月〇日まで行うので」となっていれば、バナーや売れ筋商品の入れ替え等の作業も実施しやすくなります。

カレンダーを使ってマーケティング施策を作るケース、マーケ業界内では「50週カレンダー」なんてモノもありますが、こういったものを使って施策の計画を立てることも有益です。

ま、マーケオタクの言うことなんで、あまり真に受けていただかなくてもいいんですが。


*1:デジタル系商材であれば、例えば「情報商材」と呼ばれるノウハウ系のデジタルデータ販売。特に季節関係なく売れるはずのものではありますが、春先(4月)や秋口(9~10月)によく売れるのではないかな、と想像できます。「異動」がキーワードですよね、転勤だったり部署異動だったり。そういったタイミングで「部下に嫌われない上司になるためには?」といった情報商材は売れるでしょうし、7月あたりにはおそらく売り上げが落ちるはずですよね。

*2:あくまでも感じ方なので人それぞれ、と考えてください。私はそう考えるので、この後も季節の移ろいというキーワードをそのまま風情と読み替えて書いている、と考えてもらってOKです。

*3:そもそも「平賀源内が考えた」という説すら眉唾で、うなぎ屋が当時有名だった平賀源内の名前を借りて看板を掲げたのが話題になった、ということだって十分考えられるわけです。まぁこうなると「捏造」なんで今のご時世では到底考えられない所業になるわけですがね。

*4:私の師匠の口癖ですが、「真冬に氷を売る」のがマーケティングなんだ、と私も信じています。

*5:コロナのせいで「全体的な客足が遠のいた」とすると、その客はどこに行ってしまったのか。巣ごもり(家飲み)消費が増えたのだとすれば、居酒屋メニューのテイクアウト施策が効果的に思えますし、ある特定の顧客層、例えば高齢の客層が来店しなくなったのだとすれば、テイクアウトの注文にスマホアプリを必要とするUber Eatsを使うという施策は今一つ響かないような気がします。

Amazon ECSでLAMP環境を作ってみよう(その1:前提と要件)

久しぶりの長編技術ネタです。

最近のWebアプリ開発環境は、わざわざサーバマシンを買ってきてLAMPスタックとかTomcatスタックとか作って、とかいう手間をかけることなく、仮想サーバやコンテナオーケストレーションとかで簡単に作れるので大変便利です。昔はそのためにわざわざマシンを一つキープしていて、開発する環境に合わせてスタックのフルバックアップを個別のHDDに展開してアプリの動作確認をするとかやってました。今は開発マシンとして1台Linuxを置いているだけで*1、あとは手元でコマンドを打つだけでなんとかなるというのは大変楽で仕方がないですね。

なのですが、本番環境としてはなかなか仮想アプライアンス系を提案できにくいです。大きな理由は「よくわからない」から。見えないんですよね。やっぱり一般的なレンタルサーバがわかりやすいです。例えばこの後話が出てくるのでAWSを例にとりますが、EC2とホスティングサービス業者が提供する「専用サーバ」と何が違うのか、というのは技術者的にはなんとなくわかるはずなのですが*2ホスティングサービスのほうが料金体系もサービス内容も明確ですから訴求しやすいんですよね。

とは言え、自分でやる分にはレンタルサーバ借りるよりはIaaSでちょちょいと、の方が楽ですから、外部公開用のテストには積極的にIaaS、特にWebアプリについてはEC2を積極的に使っていましたが、自宅環境では基本的にVagrant→Dockerという感じで、あまり経験がない環境になる場合はVagrantで作り、知見を得ながらDockerでの構築テストをする、という流れでこの1~2年くらいやっていました。この流れはたぶんこの数年くらいは「俺的主流」なんだろうな、と思っています。

コンテナを作るようになると、「だったらそのコンテナ活かせないかなぁ」、と思うようになるわけですが、なかなか外部公開用にはいいサービスが見つかりません。最初に思い浮かぶのがHerokuなんですが、Heroku自身はDocker-ComposeであったりKubernetesであったりのコンテナオーケストレーションツールには対応をしておらず、アプリケーションそのものをコンテナに突っ込む必要がありますので、コンテナの軽量化とは逆の方向に進んでしまう可能性もあるわけです*3。そこで、AWSのECS(Elastic Container Service)というコンテナオーケストレーション機能があるので、それを使ってみよう、と考えたわけです。もしかすると自分の考えていたコンテナ運用ができるかも、と思っています。

ECSに手を出してしまった理由

上記の繰り返しではあるのですが、自宅での(Webアプリ)開発は基本的にDockerを使っています。いくつかの例外がありますが、この場合は漏れなくVagrantを使って開発をすることにしています。考え方は、まずDockerでの環境構築ができるかどうかを検討し、できなければ、またはDockerでの構築が不安な場合(Webアプリサーバに関しての学習が必要だとか)にVagrantを採用する、という方法をとっています。

racchie.hatenablog.com

まぁそんな状態なので、開発はDockerでやっているわけですが本番環境はといえばレンタルサーバがほぼメインなわけです。ごくまれに(と言ってもうちのお客様で1社だけですが)Herokuを使われているところがあるくらいで、なかなかクラウドの良さを理解していただけないのは私の営業能力がないからなんですよね...。

そうは言ってもやっぱり今後はクラウドサーバを推していきたいわけで*4、EC2でのテストサーバは作ったことがあるので次はDockerだよなぁ、と。しかもHerokuはDockerではないですが触ったことがあるのでいつでも試せるし。

ということで、やったことがないことをやるのが大好きなので、ECSで環境構築のチャレンジをしてみた次第です。

やりたいこと

そろそろ「自分の仕事」用のサイトを作らなければなぁ、と数年くらい思っているわけです。2019年のGWあたりでWixを使ったホームページを作っては見たのですが、それ以来手を付けていません。仕事で「Wixのホームページ作成」を受注していないというのも大きな理由ですし、デザインの「難しさ」を感じるのも理由の一つです*5。それと、エディタが重いのは仕方ないことなのですが、あれも耐えられないですね。

閑話休題

で、自分用サイトを作るのですが、コンテナで作るなら、CMS用のコンテナをいくつか用意して、サンプル的なサイトを下層で展開する、というのはどうだろう、と考えたわけです。もっとも、今できることなんて大してないですが、いろんなパターンのサイトも作れますし、テストでドメイン配下にいろんなサービスを付け加えてみて、もちろんサーバ負荷がかかることになるのですが、更にサーバのスケーリングとか、後ろでいろんな実験ができるわけです。当然実験結果はサイトで公開できるわけで、技術系のネタが切れてきた現状、こういう「実験サイト」は大変有効ではないかな、と考えたわけです。

コンテナオーケストレーションLAMPスタックを作るのは、自宅開発サーバではDocker-Composeを使って実装をします*6。まずはコレをAmazon ECSで実現してみよう、と思うのですが、さて、ネットで検索してもわからない。では、まずは自分で試行錯誤することにしましょう。

つづく

また休みの日を使って部屋に籠って作業をすることになりそうです。酒でも飲みながらのんびりやりましょうかね。

*1:他にももろもろに使うメインのWindowsスマホアプリ等のデバッグMacがデスクトップとして置いてあり、更にヨメ分も含めノートPCが何台か転がっている環境です。

*2:マネージド、つまり専用サーバはホスティング業者が「サーバ」のSLAに基づいて面倒を見てくれて、EC2は自分で建てたサーバの面倒はある程度自分が見るという感じでしょうかね。同じ仮想サーバ運用ですからね、アレ。

*3:Herokuが良くない、という話ではないですよ念のため。ただ、LAMPスタックコンテナ群をオーケストレーションツールを使って作る必要は少なくともHerokuではないわけですよ。アプリとプラグインがあればできますから。Wordpressなんかを使う場合はPHPスタックを建ててDBプラグインをHeroku側に導入して、あとはコンテンツ保存用の外部ストレージをつなげてあげるって感じですよね。

*4:もちろんレンサバも必要だと思いますし、完全マネージドなので楽ですよね。考えることをしなくていいんです。ちょっとテストで導入するくらいならレンサバを選んでもいいかもです。契約が面倒なので私はちょっとしたテストでもクラウドを積極的に使いますが。

*5:具体的に言うと、「限られたデザインテンプレートの中で、ある程度自由度の高いデザインを作ることができる」という売りが、デザインセンスのあまりない私にとっては苦痛になってしまうのです。だったらWordpressみたいにテンプレがそのまま使える状態の方が簡単でいいよなぁ、とCMS系の仕事を立て続けにやってみて感じています。

*6:厳密には「LAMP」ではないですが、基本構成はApacheが入ったPHPコンテナとDB/MySQLコンテナをオーケストレーションするという簡単なパターンです。

小ネタ:あなたは今の仕事に満足をしていますか? - 思い出話 -

私自身は「ギグワーカー」が好きではないわけではなく、昨今の副業ブームに乗って雨後の筍のごとく現れた、周りを顧みることのない迷惑系ギグワーカーとでもいえばいいのでしょうか、まぁそういう人たちが嫌いです。

そもそも、自分自身が最初ギグワーカー的にフリーランスの仕事をやるようになり、今でもそういうスタイルを貫いているのですが、では私は「ギグワーカー」なのか、と聞かれるとちょっとそれも違うんです。フリーランサーという肩書も、洒落でつけた「アルケミスト」という肩書*1も、所詮は肩書ですし、私が何者か、といえば私なんです。

そんなことを考えていたら昔の思いみたいなものが少し頭に浮かんだので、すこしまとめてみたいと思います。

イングヴェイ・マルムスティーンとの出会い

ja.wikipedia.org

まぁ、まだ痩せてた若い頃にライブで一度しか見たことがないですが(笑)*2、ヘビメタにハマっていた高校時代、友人から紹介をされて聴いてぶっ飛んで、というお決まりのパターンです。高校卒業後にギターを友人から買って、そのフレットボードをインギー仕様にするべく彫刻刀で削りまくったのは若気の至りというべきか。

いきなり仕事と関係ない話から始まってしまいましたが...。

当時すでにスターダムにのし上がっていたインギーですが、彼は自分では「バンドを組む」ということをしていません。ジャズなんかでよくあるパターンですが、自分自身が「これ」と思ったメンバーを一時的に雇い入れてリーダーアルバムを作る、というスタイルで音楽作品を生み出しています。私がフリーランサーとしてこだわっているのは実はこのスタイルで、自分中心としたプロジェクトを立ち上げるとしたら、それぞれ適したメンバーを一時的に雇い入れてプロジェクトを遂行し、完了したらメンバーはまた別の誰かの仕事に従事する、というような、まさにバンドメンバーがギグバッグ一つ持ってスタジオに参集したり、ライブツアーに帯同する、みたいなイメージの仕事スタイルです。

会社に所属していた時にいつも思っていたことの一つがこの「メンバーの流動性」の難しさです。社内のリソースに限りがあるという前提を取り払って考えても、あるプロジェクトにどうしても参加してほしいと考えるメンバーがいたとしても、部署が異なるとか立場が異なるなど、とにかく柔軟性が低いことが多かったです。最近のフラットな組織を標榜するベンチャー企業さんだとそうでもないのでしょうが。

今は自分がインギーのような「バーチュオーソ(Virtuoso)」ではなく、サポートメンバーのような立ち位置ですので、あちこちの現場にギター、ではなくPCを持って集まる*3という生活をずっとしているわけですが、やっと自分のプロジェクトチームを組むことができるように最近はなってきています。

ジョン・カロドナーの逸話

en.wikipedia.org

『私は私』というのを仕事でも実践できるように心がけているのですが、これはまだ若いころに「伝説のA&Rマン」と呼ばれたジョン・カロドナーが語った逸話に影響されています。彼は自分の肩書を「ジョン・カロドナー」としていて*4、自分の仕事は自分にしかできず、代わりが効かない、という意味でそうしているのだそうです。

インギーの項でもしれっと書いていますが、ジョン・カロドナーも「バーチュオーソ」なんですよね。Wikipediaだとイタリア語っぽくなっていますが...。

ja.wikipedia.org

唯一無二の演奏家、とでもいえばいいのでしょう。代わりが効くかどうか、という以前の問題で、あるプロジェクトをやろうとしたときに、あぁ、〇〇さんなら実現可能かも、とか思ってもらえるような職人、とでもいえばいいでしょうか。

替えが効くかどうかはともかく、「まずはあの人に声をかけてみよう」と思ってもらえることは、仕事をするうえでは大きなメリットになるわけです。受注確率は圧倒的に高くなるわけですから。もちろん忙しくて断る、ということも起こりうるはずですが、それでもまず仕事の最初期に話を持ってきてもらえるようになることはとても大切だな、と思うんです。

だからこそ、私も自分の肩書が自分の名前になれるように、IT系の企画から開発までをお願いしたいと思ったらまず私の名前が最初に思い浮かぶようになりたいな、と思っています。

昨今の「ギグエコノミー」「ギグワーカー」との決定的な違い

「バーチュオーソ」となりたいかどうか、が昨今のギグワーカーとの違いなのかな、と私自身は思っています...、というか、そのあたりが差別化要因になりうると考えています。私自身、フリーランサーなんて「一匹狼」だし、と言って偉そうに『俺は群れたくないぜ』とか言い切れるほど寂しさへの耐久度は強くありませんし、でもまぁ「みんなでワイワイ」というよりは一人で黙々と作業をする方が好きですし。

仕事を取ってきても、最近は本当に忙しくて、他人に一部仕事をお願いすることが増えてきました。ビジネスなので報酬として自分の売上の一部をお支払いして。まさにこれが私が望んでいた姿です。まだまだ先は長いですが。バンド、と言うよりはプロジェクトチーム、と言った方が今どきのビジネスっぽいのかもしれませんが、自分がプロジェクトのリーダーとなって仕事を獲得し、プロジェクトを動かし、自分も「演奏」をしながら作品を作り上げていく。私自身が作っているモノが「とても優れている」とは(謙遜でも何でもなく少なくとも今の時点では)到底思えませんが、そうありたい|あれかし、と思って日々コーディングをしています。

個人的な好みの問題というか、Uber Eatsの配達員さんたちはとにかく嫌いなのでやり玉にあげますが、「地蔵」とか言われている、店舗や店舗密集地帯のある特定の場所で待ちを決め込む配達員さんたちは、どう見ても「バーチュオーソ」とは対極にいるように映ります。自分の代わりになる人たちがたくさんたむろしているわけですし、配達する業務としては孤独な一匹狼かもしれませんが、しのぎを削るためにすることはまさに路上などで通路をふさぐようにたむろする迷惑行為だったり*5するわけです。他人に迷惑をかけてまでしのぎを削るなんて、どの世界でも通らないだろう、と思うんですが。何事かを成したい、というよりは単に「周囲を出し抜いてやりたい」という、なんか自己顕示欲を充足させているだけなのかな、と思ってみたりします*6

(CODA:)あなたは今の仕事に満足をしていますか?

満足か、と聞かれるともちろん不満だ、と答えます。まだまだ自分が至らないところもあるからこそ、なのでしょうけれども仕事も充実しているわけではないですし、仕事が充実していないから実入りも少ないし、もっともっと頑張らないと満足できないんだろうなぁ*7、と感じています。ただ、現状についてはおおむね満足しています。やり方がスマートではなかったにせよ*8、なんとかここまで生きながらえることができ、継続することができています。もっともこのことについて感謝すべきは家族ですが。

ただ「仕事をする」のではなく、『主体的に』仕事を行う、というスタイルを貫いているからこそ今の自分がいて、会社という組織に縛られないで、自由にいろんな人たち(または企業)と手を組んで仕事を遂行する、ということもできるようになった、ということについては、まさに思った通り、独立する前からずっと考えていた仕事スタイルですし、それが実現できているということに関して言うならば、とても満足をしています。特に「今どきのギグワーカーがぁ~」とか言うわけではなく*9、私自身は私のスタイルを貫いているのでそれはそれで、周りに何と言われようとも私のスタイルなのでそれでいいんです。

*1:屋号として登録をしていますが、実際にはハガレンに影響を受けているものの、自分自身が錬金術師のように0から1を生み出したいという思いがあって屋号とし、さらに肩書としても使っています。

*2:1990年、「イクリプス」アルバムのツアーだったかな。なぜか横浜文化体育館に行った記憶があります。

*3:実際には在宅仕事なのでプロジェクトにオンラインで参集している感じです。

*4:本来「A&R:ジョン・カロドナー」となるところを「ジョン・カロドナー:ジョン・カロドナー」としています。Aerosmithの「Pump」アルバム)などを見るとそうなっています。

*5:私を十分イラつかせる行為ではありますが、それよりもイラっとする、嫌いだ、と明言する理由は、とにかく交通ルールが悪いことです。割込み進路妨害は当たり前、一時停止無視やら信号無視もたびたび遭遇しています。唯一遭遇していないのは自転車や原付で高速道路に乗っている輩くらいでしょうか...。

*6:Uber Eatsの配達員を動かす仕組みとして、ゲーム性を持たせているのももしかするとそういうマインドセットの醸成につながっているのかもしれないんですけどね。配達員になったこともないしアプリも見たことないのでよくわかりませんが。

*7:その裏では、どこまで「やり切れば」満足するのだろうという底なしの不安もあるわけですが。

*8:いままでのフリーランサーとしての「私の履歴書」はいずれ書いてみたいと思ってはいますが、その辺のサイトやYouTubeなどで紹介されているような、キラキラしたものではなく、かなり泥臭く、かなりの失敗をして今ここにいる、と自分では思っています。

*9:もちろん、仕事スタイルを客観的に見て好きになれない、というのは依然としてあるわけですけど。

小ネタ:AWSでMacを使う話

ある冬の夜、外は寒いのに寝苦しく、何やらネットの記事で「AWSMacが走るぞ!」と書いてある夢を見た、そんな気がしていたんです。翌朝、ネットの記事をざっくりと読んでいると、AWS re:InventというイベントでEC2のインスタンスとしてMacOSが加わった、という記事が目に留まり、『夢ではなかった』と思ったのと同時に、実際に使ってみようと考えました。その顛末を。

すべてのリージョンで使えるわけではない

現状すでに私は仕事用に東京リージョン(ap-northeast-1)でEC2インスタンスを立ち上げていますが、リリース当初だからなのか、使えるリージョンが限定されていました。日本から一番近いところだと、AsiaPacific内であればシンガポール(ap-southeast-1)のみで使えるということなので、シンガポールリージョンでインスタンスを起動させることにしました。

参考にしたのはこのサイト。

dev.classmethod.jp dev.classmethod.jp

一部このリンクの通りにやっても動かないところがありましたが、まぁだいたいこんな感じで。特に、VNC接続についてはCatalinaではこのやり方では使えません。エラーが出るはずなんだけどこの人はエラーを回避する方法を知ってたんだろうか...。

Warning: macos 10.14 and later only allows control if Screen Sharing is enabled through System Preferences.

Catalina(10.15.7)もMojave(10.14.6)も、画面共有はコマンドラインからではできないよ、というエラーが出るはずで、

dev.classmethod.jp

この記事にあるように追加のおまじないをすると、やっとVNC経由でアクセスできます。ちなみに、ユーザを作らずに「ec2-user」のままで作業をする場合のパスワードは、この動画が参考になるのですが...、

www.youtube.com

パスワード未設定だそうです。基本SecretKeyでの運用ですもんね。

専有ホストは最初使えなかった

ちなみに、設定をしてハマった箇所は2か所。一つは前項でも書いている「画面共有」をコマンドラインから設定できなかった点。これはエラーメッセージを見ないままで処理を進めていた私が悪かった、というヤツですが、もう一つは、専有ホストの割り当てが0だったことです。

割り当てをしてもらうためには、EC2のコンソールから「制限」を選択して、制限されている項目、このケースで言えば「MAC1の専用ホストを実行中」とか書いてある列を選択して「制限緩和のリクエスト」ボタンを押し、理由と使いたいホスト数を書いて送ればOKです。ちなみに私の場合、「業務での利用を検証するため」と書いて送っていて、検証用ということで割り当て制限を当初より少なくされてはいますが一応パスしました。これができないと専有ホスト(要は動画で見ていた「あの」Mac mini)が割り当てられないのでインスタンスが作れません。

少し触ってみて思ったこと

さて、セットアップの方法はこれくらいにして*1、実際に使ってみて感じたことを書き連ねてみます。

解像度が低い

Macは基本的にヘッドレス運用を想定していないからか、ディスプレイケーブルがないと解像度が低いのですが、今回試してみても同様に解像度は最高でも1024x768pxです。これは決定的にリモートで作業するには向かない気がします。

費用がかかり過ぎ

インスタンスの起動状態に関わらず、Macの場合は専用ホスト(要はMacを走らせる専用サーバマシン)を確保しているだけで1日数十ドル取られます。特に今回、インスタンスのストレージも300GBくらいを確保していたので、だいたい1日当たり$30くらい費用が発生していたのですが、仮にこのままのペースだと1ヶ月$900徴収されることになります。だったらM1 Mac miniを買ったほうがよくないか?

動作が重すぎる

今回のテスト期間中はたまたま自宅外にいて、インターネット環境は自宅(オフィス)に比べると貧弱な環境下で使っていたのですが、基本的にVNC経由でアクセスをすることを考えるととても動作が遅くて使い物にはならないような気がしてなりません。

仮に、コーディングなどを外でやろうとするならIDEを使うことになりますが、このレスポンスの遅さはかなりネックになるんではないでしょうか。専有ホストやインスタンスのスペック上は高速であり、AWSの内部では爆速なんだろうと思うのだけれど、リモート、しかももともと動きがもっさりしている(というイメージが強い)VNCでのリモートアクセスはストレスが溜まります。

PoC用途くらい

ローカルマシンのリプレイスという用途としては上記の理由から考えると難しいと思います。ではどういう使い方なら使えるのかと考えてみると、例えば今回、Intel MacのCatalinaでインスタンス生成をしているのですが、M1 Big Surで作ったMacアプリが旧版でも動くかどうかを検証する程度の目的なら使えるかもしれません。

また、私はたまにWebアプリのテスターを受託しているのですがが、その仕事もこれを使えばOS別のテストを単一マシンで対応できるので(解像度の問題があるので正直言えば現実的ではないですが)、費用負担との兼ね合いではあるけれどできるような気はします*2

誰得なのか

www.youtube.com

確か最初に見た紹介ビデオは、Macを使って開発をしている会社(ベンチャー系)が、Macをたくさん使いたいけど買えないよね、と言う話から始まっていた気がするのですが*3、もしこんな感じで使うなら多分、いや、間違いなくM1買うほうがお得でしょう。

もともと(最近の)Macは拡張性に乏しく、例えばメモリをもっとほしい、となれば別のマシンを買わないといけなかったわけですが、AWSでの運用だからといってスケーラビリティはやっぱりないわけです。単一インスタンスタイプだしスケーリングもできない設定だし。単にリモート運用のMac miniを貸してるだけに過ぎない。

サービスが始まったばかりだから今後どうなるかわかりませんが、少なくともIntel Macが仮想サーバで動き出すことはないだろうし、専有ホストであるマシンのリプレイスもかけにくくなるならサービスとしても尻すぼみな状態なんじゃないかな、と思うのですが。

私はもういいです

結論を言えば、私が想定していた、自宅にあるMac miniのリプレースには用を足さないのだな、と思いました。リプレースの必要があるのか、と言われるとちょっと答えに窮する部分ではありますが、普段の開発ではMacを使うことは(最近は)ほとんどなく、逆にMacでしかできないことのためだけにMacを1台用意しているという状況です。

私の今のMac利用用途

具体的に言えば、

  • Xcodeを使わなければいけない「開発」:Swift/Obj-Cによるアプリ開発だけでなく、Flutterで開発したアプリのコンパイルにもXcodeが必要になります。
  • Photoshopを使うデザイナーとのファイルやり取り:ごくまれにMac版でなければ使えないファイルを送ってくるケースがあって*4、そのためにMacPhotoshopを導入しています。
  • Webアプリケーションのテスト用途:クライアントさんの意向でMacWindowsの両OSでチェックをしてほしいという要望があって、Macを使います。最近はあまりOS間での差が出ないようにも思いますが、特に見た目の問題でどうしてもSafariの挙動が変になることが多いです。

この3点だけなのですが、一応Mac miniは「そこそこの」スペックのモノを用意しています*5

M1 Macでもいいかも

2018年頃まではMacがメインマシンで、Windowsを仮想サーバ内で動かしていたこともありましたが*6MacのRDPアプリ経由で使う時にはどうしてももっさりしがち、さらに言えばローカルサーバでの運用でしたのでWindowsマシンとしてのスペックもサーバ以上に設定することはできず*7、さらには当時はWindows7、8.1、10の3つのOSを使って検証をしなくてはいけなかったのですが、現在はWin10のみのサポートしか私が行っていないので*8仮想マシンが必要なくなったこともあって*9、デスクトップの「開発マシン」としては1台だけしか現在は使っておらず*10Windowsで開発ができるようになっていますので、Macは使うときだけあればいいわけです。

そうは言っても開発用に少しスペックは必要*11ですので、いっその事M1 Mac miniをメモリだけフル(16GB)カスタマイズで10万程度ですのでそれを買った方がお得、ということにはなりはしないでしょうかね。今すぐ買う必要はないのでアレですが。ただ、以前から中古で2013モデルのMac Pro(通称:ゴミ箱)を狙っていました。拡張性を考えるとMac Proが最適で、Mac Proは2019年に最新モデル(通称:チーズおろし器)が出ていますので、旧モデルは多少値落ちしていて、それでも10万以上はしてしまうのですが、最新OSが使えるという点ではまだMac Pro(2013)は魅力的です。コスト的に考えるとほぼ同額、若干Mac Proが上ですが、拡張性はMac Pro、最新OSのサポートという点ではM1 Mac miniに軍配が上がります。どちらを取るべきか、ちょっと悩みますね。

*1:と言うかそういうの紹介してないので普段から。

*2:費用的にはWindowsの同スペックマシンを作ったほうが安いような気がするのでやっぱり現実的でないですが…。

*3:いや、ビデオを見直してみたのですが、どっちかと言うと開発用のサーバのメンテナンスをするための管理が煩わしい、という話なんですよね。だとすると、ビジネスでMacの「サーバ」としての利用があるならまぁ使うことを検討してもよさそうですが。

*4:というか、だいたいテキストフォントのラスタライズ化を忘れているケースです。

*5:Late 2012で、OSはCatalina止まりです。デュアルコアの2.5GHz Core-i5、メモリはフルに16GB、似非Fusionドライブにしていますがあまり最近は速度が出ていないような...。

*6:VMWare ESXiを一時使っていて、そのあとCitrix XenServerに乗り換えて2年くらいWindowsを使っていました。

*7:それでも当時メモリは積めるだけ積んで16GBにしていました。今は物置に入れていますが、ハードウェアRAID対応のマザーボードだったのでそのうちファイルサーバにでもしてやろうかと思っています。

*8:クライアントさんにはOSが無料でアップデートできる時期にアナウンスをして「無料だからアップデートがおススメ」とアップデートをさせてしまいました。

*9:WSL2になってからWindowsの中にLinuxを入れておき、シームレスに使うこともできるようになったので、Linuxマシンも厳密には必要としていません。

*10:開発用のサブノートが1台、あとはいろいろとなぜかWindowsマシンを数台持っているのですが(笑)。

*11:なんか「ギガがなくなった」という日本語と同じで気持ち悪いですが...。

マーケオタクのボヤキ:フリーランサーが稼げるようになるたった一つの「キーワード」

毎年、年の暮れには酉の市に出向き、お約束の熊手を買い、年が明ければ初詣に出かけ、神仏に商売繁盛を願う、というのはフリーランサーに限らず商売をしている人たちが必ず行うルーティンのようなものかもしれません*1。でも、何度も神頼みをすれば稼げるというわけではないわけで、結局「どうすればいいのか」ともがきながら売上を上げているのがほとんどのケースなんだろうと思うんです。

せっかく年も明けたことですし、少し「どうやって稼ぐか」ということについて真剣に考えてみたいと思います。

1日8時間労働では足りない?

私は専業フリーランスですので、1日に働く時間は自由に決めることができます。とは言っても寝る時間や休みも必要だと思っていますので、おおよそ1日8時間程度、一般的な会社員と同じくらいの業務時間で週5~6日働いています*2

稼ぐためにどうすればいいか、と言うと、一番最初にこの「労働時間」の延長が思い浮かびます。私自身、ずっと週5で土日休みを貫いてきていましたが、ここ最近忙しくなったこともあって、月1程度土曜日に仕事の時間を入れています。特に落ち着いて取り組みたい仕事などがあると、クライアントからの問い合わせも少ない土曜日の仕事はずいぶん捗りますし、かといって平日に「代休」を取るほど暇もないので、結局毎日働いているような気分になることもあります。

ただ、これで「稼げるようになったのか」、というと微妙なところで、多少仕事量が増えたことによる進捗の遅れは取り戻せている気はしますが、稼ぎに直結したという印象はありません。ではもっと、例えば1日16時間働けば稼げるのか、と言うとおそらくそんなことはないはずです。仮に週5で8時間と、週6で16時間の勤務時間の差は単純に倍にはなるのですが、生産効率が果たして保てるか、というと、おそらく難しい、というよりは無理ではないかと思います。

企業では「三六協定」というのがあり、1日の勤務時間を8時間と定義していて、さらに労働基準法で、「時間外労働の上限(「限度時間」)は、月45時間・年360時間」を超えてはいけない、と規定されています。1か月20日を勤務に充てたとして、月45時間であれば1日当たりの時間外労働の上限は2.25時間(2時間15分)、年換算で考えても(360÷(20×12)=)1.5時間程度です。働きすぎて過労死、とかいう話もその通りなのですが、働きすぎることで正常な思考が保てなくなることがまず最初の問題であって、そもそも1日16時間も働いたところで1日8時間で生産できる「モノ」の倍量生産できるわけではありません*3

1日どの程度働くのが理想的かは私自身まだわかりませんし、体調との相談だったりもするのですが、世の人たちが一般的に働く時間を圧倒的に超えてしまっても生産性は上がらないし、稼げないだろう、とは思います*4

「自社サービス」を作ることは?

私もフリーランスになりたての頃、これを考えていました。...いや、正しくないな。自分でWebサイトやスマホアプリを作って世に出して、それを収益化しよう、というアイデアは今でも頭の片隅にあります。事実、趣味のブログであったりYouTubeデビューであったりと、実現に向けての行動を起こしているものもありますが、これは必ずしも「稼げる」わけではありません。

ネット界隈では「レバレッジ」とか、もっと直接的な言い方で言うと「不労所得」とか、そういったキーワードで出てくる内容を含んでいたりしますが、要は自分でサービスを提供する側に回ることで、そのサービス利用料金などの収益が得られますよ、というお話です。少なくとも『誰かから仕事をもらって稼ぐ』ということではなく、自分で付加価値(とお金)を生み出すサービスを提供するという、一歩踏み込んだやり方です。今どきのビジネスモデルだと「有料サロンの運営」もコレですよね。

ニッチなジャンルに踏み込んでいけばそれだけ固定客も付くだろうし、自分が仕事を取りに行って働くスタイルではなく、自分に客がついてその客がお金を落としてくれるスタイルなので、100%稼げない、とは言いませんが、仮に稼げたとしても、こういったサービスの提供を行うまでの時間、そして提供してからのサービス運営にかける時間は、当然ほかの仕事(自分で取ってきた他人の仕事)を行ったうえで行うべきことであり、時間を相当量費やす必要があるわけです。もちろん効率化をする余地があるのだとは思いますが、それにしたってよくアヤシイ商材に書いてあるような「1日1分メールチェックするだけでOK」というレベルでの運用になるまではそれこそ長い長い時間をかけてサービスの構築や運用を続けてこないとたどり着けない境地でしょう。

似たようなパターンに他人に仕事を頼んでしまう、というのもあります。自分が働かなくてよく、人を(悪く言えば)転がして上前を撥ねるやり方ですが、自分が稼ぐためには撥ねる上前の金額を上げるか、上前をもらえる頭数を増やすか、しか方法がなく、前者の方法では受注するときの金額が高額になり失注確率が上がるか、作業を依頼する側の手取りを少なくすることで依頼者がいなくなってしまうか、といういずれかのリスクがあるわけです。結局安全なやり方は後者の受注件数を増やすこととなってしまい、マネジメント業務も含めれば相当な業務負荷となりうるわけです。

意外な最適解

意外、というか、真っ先にあきらめてしまって考慮していない点、というべきなんでしょうが、

  • 単価を上げること
  • 既存顧客からの継続案件を増やすこと

の2つについては、今まで挙げた方法に比べて時間(労力)をかけなくても稼ぎ=売上の向上につながるやり方です。

単価を上げることに関して言えば、「サラリーマン上がり」のフリーランサーなどは「毎年何パーセントか単価を上げてもらうことは可能だろう」とお思いでしょうが、実際にはめちゃくちゃ難しくて、私もこれで苦労しているクライアントが何社かいたりします。が、単価を上げることが絶対に無理、ということではありません。「単価の上げ方」については別のところであらためて方法論を紐解いていきたいと思いますが、キーワードは「クロスセル」です。これができなければ単価は上げられない、と思っていいです*5

その意味では、既存顧客からの仕事を継続的かつ多くもらう、というのが現実的でしょう。「通常のクライアント」であれば、自身の業務の拡大に伴って作業量が増えていくはずで、それをフリーランサーに外注に出すという流れを取るのだから、その仕事をどれだけ自分(フリーランサー)に振り分けてもらえるかで、自分の売上が増えていくはずです*6。ここでもクロスセルや、「アップセル」なんていう、マーケオタクならではのマーケ用語を連発してみますが、結局はクライアントに自分を売り込んで、他の仕事もくださいよ、と交渉をするのが、フリーランサーにとっては意外ともいえるやり方です。

でも、クライアントだってそんなことはわかっていますし、できるだけ外注費も抑えたい(でもプロダクトはリリースしたい)ので、「仕事をくれ」と言ってよくあるパターンは、「じゃまとめてかなりのボリュームの仕事を出すから割引してよ」。これは受けてはダメです。単価割れも発生しますし、割引の要望を一度受けてしまうと今後も同じように、またはもっと割り引くように要望されるようになります。当然ボリュームは増えますがそれだけ単価が安い仕事になってしまうわけで、結局売上に貢献しなくなっていきます。

最終兵器

もう一つ、これは最終手段というよりは、ある程度売上の見込みが立つようになってから、という話ではあるのですが、

  • 単価の低いクライアントからの仕事を断る(または取引を止める)

という、簡単なようで難しく、難しいようで意外と簡単な方法です*7

この手のクライアントは、「単価の割に時間ばかりかかってしまう」はずなんです。でも、過去のしがらみや、もしかすると前項のような、割引して単価ベースで考えれば激安なんだけど仕事は安定して大量に供給してくれる、とか、そういった『安易に手放すことができない』クライアントだったりします。

私はどうしたか、と言えば、すごく簡単で、仕事が忙しかろうが死ぬほど暇だろうが、対象のクライアントから仕事の依頼が来た時に「今忙しい」と依頼を断りやすくしました。言い方は悪いですが、他にも仕事をしてくれる人はいくらでもいるでしょうから、条件の合いそうな人をクライアントが探して依頼すればいいことなので、それでいいんです*8

もちろん、「あなたにしか頼めないんです」となれば今度はこちらに交渉権があるわけで、「仕方ないなぁ、時間割いて仕事してあげてもいいけど、単価高くなるよ。それでもいいのかい?」と*9こちらに有利に働くように交渉を進めればいいわけです。

「セルフマーケティング」がカギ

新しい商品やサービスなどの提供がカギになるのであればいいのですが、結局は自分が普通に働いていて、それに見合った単価の支払いがあることが「効率的に稼ぐ」方法であり、そのために考えなければいけないのが「セルフマーケティング」ということになるわけです。ここまで書いた内容を「セルフマーケティング」という観点でまとめなおすと、

  • (適切な)単価設定を行うこと
  • 新規顧客の獲得より既存顧客のリテンションを重視すること
  • (新規・既存ともに)安請け合いをしないこと

に尽きるんです。

単価設定の一例

私は実は、普段はお客様には(そしてブログでも)公開していませんが仕事における受注の目安となる「料金表」を作っていて、それに基づいて仕事を受けています。一例で言えば、最近多いPHPの開発については、時給3500~7000円の範囲で仕事を受けるようにしていて、発注をしていただく企業によってだいたい金額を変えて提示をする、というやり方です。金額の範囲についてですが、最低の時給として設定してある下限金額の2倍~3倍を上限金額と設定していて、特にプログラミング系については2倍を上限と決めていますが、どの範囲内で、発注先の「足元を見て*10」決めています。

新規獲得<既存顧客リテンション

私の持論、というよりもこれは、顧客獲得の「パレートの法則」です。労力やコストがかかるのは8:2で新規獲得です。売上は8:2で既存顧客のリテンションをする方が上がります。私の見立てではありますが、クラウドソーシングをやっている人たちはこれを理解できておらず、とにかく新規顧客から仕事を獲得したい、と苦労している気がしますが、そうではなくて、取引を何度もしてくれるお客様は大切にして、仕事の量を増やしてもらえるように交渉する方が新規顧客へのアピールをするより圧倒的に楽なので、これはできるだけやった方がいいと思います。かといって新規顧客の獲得も忘れないようにしないと、突然既存顧客が「店をたたんでしまう」ことだってありうるので、バランスを考えて営業活動をすべきなんですよね。

安請け合いをしてはいけない

新規獲得でも顧客リテンションでも同じなのですが、「特別な事情があって単価を下げる」のは絶対NGです。わかりやすい例が「新規獲得時の単価交渉」です。他のフリーランサーと競争になった場合、例えばクライアントから『ほかのフリーランサーが単価〇〇円でやってくれると言っていてそっちに惹かれている』と言われたらどうしますか?「うちは単価△△円(〇〇円より安い金額)でやらせてもらうんで是非」と回答したいのはやまやまですが、その単価が自分の損益分岐点以下であった場合は、どんなにクライアントが魅力的であったとしても断るべきです。もっと言えば、「単価××円(〇〇円より高い)は譲りませんが、クオリティは保証しますよ(その前段階で品質の良さについて説明がされていることが前提)」など、金額以外のメリットがあって競合との差別化を図ることができるというアピールをした方がいいわけです。もしくは断るか。

特急料金も安請け合い

安請け合いと言えば、これは既存顧客に多いケースですが、「特別な事情があって作業とは別の『手当』を要求する」のもNGです。前項でまとめて割引をする話をしていますが、逆のパターンとして、『特急料金』の設定をするケースです。手取りが増えるんでいいじゃん、と思われるかもしれませんが、これは顧客にとって「あ、『特急料金』さえ払っておけばどんな仕事もしてくれる」と理解されてしまいます。暇なときに「至急案件を頼むよ」と言われれば直前でも対応が可能ですが、忙しい時に「金を積むから仕事をしてくれよ」と言われても、他の仕事も請け負っているのに仕事ばかり増えていき、最悪どちらもコケてしまう、というパターンに陥る可能性だってあるわけです。

自分を正しく売り込みましょう

安いことがメリット、という商売もないわけではありませんが、安さには必ず別の企業努力があって初めて安さを実現できています*11フリーランサーも「企業努力」によって多少単価を下げることはできると思いますが、かといって損益も何も考えずにただただ「ほかのフリーランサーより1円でも安く」とはできません。しかも、常に損益ぎりぎりで受注していてもいつまでたっても稼げません。

自分のポジションを見つけて、売上ではなく利益を得られるような仕事を受注するために、自分を「正しく」売り込んでいく必要があります。

*1:私は酉の市にはいつも行きそびれていますが、毎年初詣に行った先の屋台でだるまと熊手を買うようにしています。どうでもいいことですが、やっぱりルーティーンです。

*2:週6になるのは最近は月に1回程度です。

*3:超短期的にはそれでもいいかもしれませんが、これが恒常化することで最終的には生産性がガタ落ちしていくはずです。昔若かりし頃、私も100時間/月の残業をしていましたが、生産性という面で果たして効率的であったとは到底思えません。ただただ目の前の残タスクを片付けてデッドラインギリギリの仕事をずっとしていただけに過ぎません。

*4:「複業(パラレルワーク)」をしている人たちの否定をするわけではないです。

*5:フリーランスの世界で、「長年貢献をしてくれているから作業単価を定期的に見直そう」と言ってくれるクライアントは今まで見たことがありません。ある業務における単価は契約から何年経っても変わりません。だから「クロスセル」で他の業務の受託をして、そこで単価を現状より上げる、というやり方を取ります。

*6:専属、とまでは言いませんが、メインに近い発注をしてもらえるようになればいいわけです。

*7:私は売上の見込みがあまり立っていない段階で何社かに対してこの対応をしました。

*8:その仕事を自分が受注せず、業務ができなかったことで自分に責任があるわけではない、ということは理解すべきです。

*9:もちろんそういう言い方はしませんが、そんな体で、です。

*10:言葉が悪いですが、実際には発注先がどの程度仕事しやすいかなどを最初の段階で見極めて値踏みをしています...、あぁ、やっぱり言葉が悪いなぁ。

*11:ファストフードは安さがメリットですが、原材料の仕入れや業務効率化などを行っているからその分を商品価格に転嫁できています。

2021年の目標

あけましておめでとうございます。本年も何卒御贔屓のほど宜しくお願い申し上げます。

さて、昨年も行いましたが、2021年はこうありたい、と思うことを備忘録的に書き残す意味での「目標設定」です。

振り返り:2020年の目標について

ざっくり振り返ると、まあまあ、というところではなかったかな。

結局は「コミットメントリスト」になってしまっていた

2020年の年初には、こんな言い訳をしながら書いていました。

(厳しい)目標管理をする目的ではなく、過去の自分がどのように考えていたかを明確にする目的として、年初に何をしたいと考えていたかを自分の備忘録的に書き記しておきます。コミットできなかったからと言ってペナルティを設けるつもりもありませんが、年末に「うわハズっ」とならないように気を付けますね。

https://racchie.hatenablog.com/entry/2020/01/06/080000

全部できたか、と言えばもちろんできていませんし、そもそも「新年の抱負」なんてお屠蘇気分で言うモノで、コミットなんてほぼ無理、と私自身は思っていますが、それでもDocker関連の知見が蓄積できていたり(Kubernetesまではたどり着けていないけれど)、新規顧客に至っては数社、しかもどちらも異なる県の企業さまであったりと、いずれかは実現できています。今年はもう少しコミットを増やしてみたいですが、少なくともそのうちの一つが実現できれば御の字、くらいに思っています。

売上について

お恥ずかしい話ですが、300万円くらいの売上計上ができそうです。目標としていたのは400万円ですので、目標未達は間違いないのですが、今回の「売上」の中には『持続化給付金』が含まれています。金額は(一昨年の売上がバレてしまいますが)60万円程度で、もし持続化給付金の給付がなかった場合、つまりコロナ禍がなかった場合は250万円を下回っていたことになります。

※念のため申し添えておきます。

『持続化給付金』については、単月の売上で前年比マイナスになった場合に申請が可能、という仕組みでした。そのため、実際に単月で売り上げが落ち込んだ月があるため申請をして受理されています。結果として年単位で言えば売上前年比はプラスになっていますが、不正受給をしたわけではない、と理解をしています。

まぁ国から「前年比売上がプラスだったんだから給付金返せ」と言われれば返すことは吝かでないですが...。

※申し添え(申し開き)終了

給付金を除けば、目標に対する達成率は6割ちょっと。コロナ禍で失注した案件がありましたが、それが仮に受注できていたとしても7割程度(おそらく300万くらいになっていたはず)。もう少し目標に対しての努力が必要だな、と思います。今年の目標は後程。

覚えたいこと

現在「モテ期到来中」で、2021年が始まった時点でもすでに大きなスケジュールが9月くらいまで埋まりそうな予感がしているのですが*1、それでもやっぱり勉強は続けないとな、と思っていて、空き時間でいろいろ覚えたいですね。

覚えたい(プログラム)言語

まずは、3年越しですが、Go言語でしょうか。そろそろちゃんと覚えたいです。ほかにも気になっているのは、TypescriptとRustでしょうか。まぁGoを覚えたら次はそっち、ということで。

覚えたいその他の技術的なモノ

プログラミング研修の仕事の関係で、Springフレームワークの勉強を一通りやったのですが、その時にかなりフレームワークの内部構造の話を聞かされていて、興味を持ちました。たぶん今年一番勉強するだろうな、と思っているのはSpringフレームワークなのですが、もっと深く学んでみたいと実は思っています。

それから、Kubernetes、と言いたいところですが、その前に、2020年にだいぶ使い方や仕組みを覚えたdocker-composeの応用編として、Amazon ECSを積極的に使ってみようかな、と考えています。ほかにもAWSに関してはRDSであったりS3であったりと、使い方を覚えておきたいものが多数あるので、きちんと使えて提案もできるようにしていきたいです。

知識の「インプット」を増やしたい

2020年には、かなり自分の持っている知識をフル活用していろんな提案をし、プログラムとしてのアウトプットやブログ記事のアウトプットを行ってきました。おかげさまでプログラムのアウトプットは売上として貢献をしていますし、ブログ記事も2020年は週1のペースで1度だけお休みをしただけでなんとか書き切りましたが、おかげさまで使えるネタストックがだいぶ枯渇しています。

本を読もう

突然いろんなことにハマってしまう友人がいて、最近彼はどうやら本(特にビジネス書)を読むのにご執心な様子。彼は速読家だったように記憶をしていて、毎日のようにFacebookで「今日はこれ読んだ」「読んでみたけど面白い/面白くない」とアップしているのを見て、あぁ、自分も少し本を読まないとな、と感化されました。

もっとも、私自身はどちらかと言うと本を読む速度は遅い方で、さすがに普通のビジネス書サイズなら1日あれば読み終わりますが、小説なんかは数か月かけて読み終わるものもあります。内容が入ってこないと遅くなる傾向にあるのですが、いずれにせよ少し時間を取って自分のインプットとしての読書を習慣にしたいな、と思いました。

「極め」たい

覚えたいことの中でも書いていますが、深く学ぶということを最近あまりやってきていなかったな、という反省を2020年にしています。きっかけはまさにSpringフレームワークの勉強で、仕事をする上では通り一遍の知識を持っているだけで十分だったりはするのですが、もっと深い知識を持っていることで、提案フェーズでの説得力は増すんだな、と感じました。

深く学び、技を極める、というところは今まで余裕がなかったこともあって意識的にやっていなかったことではありますが、「気持ちの余裕」が少しあるので2021年は深める・極める方向で学んでいきたいかな、と思っています。

https://racchie.hatenablog.com/entry/2020/12/19/183000racchie.hatenablog.com

そういう意味では、OSSへの貢献というのも自分の技術知識を定期的に活用できるという点ではいいことなのかもしれません。上の(EC-CUBEの)記事はわりと思い付きでサラッと書いた小ネタではあるものの、今年の目標を設定するという観点から読み直すと大変興味深いというか、「いいなぁ」と思います。

仕事の獲得について

昨年はおかげさまでいろいろなお客様とお会いすることができて、おかげさまで売上もそこそこ立てることができ*2、本当に「いい出会いをいただいた」なぁ、と思いますが、やはり「お客様とお会いしていない」のにお金ばかりいただいていて大変申し訳ないなぁ、とは思っています。今後もそういう仕事獲得のやり方になっていくのかもしれないなぁ、と思いますが、それも時代なんだろうなぁ...。

売り上げ目標の設定

簡単に「前年度目標と同額で400万円」と言ってしまうとアレですが、実は2021年度の売上として計上可能な契約がすでにいくつか締結済みで、よく考えてみたらそれだけで400万行きそうだなぁ...。ということで、今年目標未達だったのに目標額を増額して550万円を目指してみようと思います。

その他の獲得目標

昨年同様ですが、新規の顧客獲得を毎年1件(以上)としたいです。これはもう毎年の目標としましょう。ただ、今年に限っては、新しい道府県の顧客探しは積極的に行わないようにしましょう。また、既存顧客からの保守契約を積極的に取っていきたいですね。

若干私的な話

2020年はクルマの話でしたが、2021年は家の話です。と言っても、少しだけ以前に書いた記事で触れていますが、購入したのはヨメで、私は頭金をちょっと出しただけに過ぎません。ローンを組んだのもヨメですし、実際の所有者はヨメです。これでヨメに頭が上がらなくなりました(笑)。

中古住宅を購入したのですが、個人的には中古住宅の醍醐味はリフォームかな、と思っていて、2021年はちょいちょいと家いじりをさせてもらおうかな、と考えています。もちろん所有者であるヨメの許可ももらっていますので、何をやっても安心です(笑)。

どれだけ安価で住みやすい環境を作れるか、というのは、業界は違えどエンジニアリングという仕事をやっている者としては興味もありますし、実践する機会を与えてもらえるという点ではとてもうれしく思います。仕事の合間にリフォーム、という生活、ワクワクします。以前からやろうやろうと思っていた、スマートホーム計画も進められそうです。あれこれとやりたいことだらけですね。

頑張らないとなぁ...。と言うことで今年もお仕事始めたいと思います。よろしくどうぞ。

*1:すでに6月まではほぼ埋まっています

*2:おかげさまで家を買う頭金をちょっとだけ出すことができました(笑)。

2020年の総括

うーん、2020年の総括と言っても、「コロナがぁ~」「コロナでぇ~」で済ませちゃおうかな、と思うくらいコロナ禍の影響は大きかったなぁ、と感じます。私自身の総括ではないですが、私が2020年の春先からずっと感じていたのは、季節感がとても希薄であったこと。オリンピックだけでなく大小さまざまなイベントが中止になったりオンライン開催に切り替わったりしたことで、季節の移り変わりを感じることがあまりないままに一年が終わってしまったような気分です。

でも、私の総括は毎年恒例のフォーマット通りに。

2020年のイベントカレンダー

仕事の振り返りの前に、まずは2020年の全体的なイベントから振り返り、それを踏まえた仕事の振り返り、といういつもの順に。

2020年に発生したライフイベント

「ライフイベント」と正しく言えるのは一つだけ、家の購入でしょうか。もっとも、私も多少資金を出しているとはいえ、購入したのはヨメなので(現状所有権もヨメにしています)、購入に伴う引っ越しが発生した、というよりは、引っ越しの予定、としておきましょう。結局購入の手続きが11月末に終わったので、年末よりは年明けに引っ越しの作業が入ってくるでしょう。12月は手続き系で終始しそう*1*2

が、2020年はなんだかんだ言って「コロナ禍」ですよね。良くも悪くもいろいろと変えてしまいました。生活様式も仕事スタイルも。ライフスタイルの変容を余儀なくされた、という点では一つのライフイベントでしょう。インパクトは大きかったです。3か月ごとのイベントをこの後整理していきますが、やはりコロナの影響が見えてきます。

仕事に関して言うと、2019年内に仕込んでいた大きなネタが2つ動き出してくれて、結果としてどちらも成功した(ただしコロナの影響で現状継続案件となっていない)、という状況でした。

1~3月

2019年12月にまでさかのぼりますが、実は、福島県内での「就労体験」的なことを2019年度に行うというアナウンスがあり、説明会に参加し、面白そうだな、と思ったので何社か応募をしていました。年が明けた1月から本格的に先方の企業との面談等が始まり、2月~3月にかけて福島県内の2つの企業に訪問し、「就業体験」という名目でシステム開発の作業を現地にて行う、という作業を請け負いました。

費用に関して言えば儲けが出ているとは到底言えず、正直なところを言えば赤字出血大サービス的な費用で請け負ったわけですが、実際にはそのあとのメンテナンスや次につながる提案などを行うことで、次につなげる(もちろん次回からは正規料金で)、という話をしていました。

ただ、最終的には3社との契約を結ぶことになったのですが、1社については契約の途中でコロナ禍による「緊急事態宣言」で県外への移動がしにくくなってしまったことで、現在も宙ぶらりんになっていますし、訪問済みの2社についても再訪問をする機会を逸していて、顧客リテンションという観点で言えば、「コロナ禍でリテンションができておらず」というステータスになっていたりはします。

4~6月

もう一つの2019年内に仕込んであったネタは4月に本格始動しました。IT講師の仕事を、受注自体は2019年の秋口にできていて、2020年に入ってから契約や研修やらを受けて、実際の業務は4月から6月まで。いわゆる「新入社員向けプログラミング研修」、だったのですが...。

全国的に「緊急事態宣言」が発令された直後で、企業も完全に新年度を通常の状態で迎えることができておらず、通常であれば教室に生徒である新入社員を入れて、講師が教える、というやり方であったものを、オンライン会議システムを使ったリモートスタイルの講義+メンターのフォロー、というスタイルに急遽変更となり、ぶっつけ本番での運用変更で対応をすることになりました。

メンター(メインで教える講師としてではなく、生徒のフォローを行う立場)で参加をしたのですが、さすがに完全リモートというわけにはいかず、講師陣は講義を行う予定であった建物に集合し、そこで直にコミュニケーションを取りつつ生徒とはリモートでコミュニケーション、という講義スタイルに落ち着きました。

7~9月

実は、2020年に入ってずっと前半くらい、そんな大きめの仕事をしている中で、ちらほらと引き合いがあり、並行してその話をまとめて契約に結びつけ、さらにコロナでいったん止まって、というような状態になっていました。それでも単発での仕事がちらほらと入ってきていて*3、忙しい、とまでは言わないけれど、「まぁコロナ禍だし全体的に仕事も少なくなってるのかなぁ」、と思いながら仕事をしていました。

ただ、1件だけ、4月の時点でコロナで止まってしまった案件が動き出すかも、という情報があり、打ち合わせなどは頻繁に行っていました。

10~12月

無事、今年の初めに企画が始まって、コロナ禍で止まっていた大型案件が10月から開発開始となり、他にもコロナ禍の補償がらみで補助金が入ったりして細かいプロジェクトの予算として使っている関係で別のプロジェクトが動き出したりと、年末までびっしりと予定が入っている状態だったりします。

さらに個人的なプロジェクトとして自宅の購入手続きと引っ越しが入ってきたりして、結局1週間ほど体調を崩して寝込んでしまっていたのも10月の話です。いやはやアレはひどかった...。

総括

TL; DR

「人生最大のモテ期」と思うほど今年はお客様に恵まれました。契約に至った新規のお客様は(2019年の仕込み分も含みますが)6社、既存顧客からも毎年コンスタントに仕事を発注していただき、おかげさまで今年の売上は過去最高となりました。売上金額については次回の投稿となる「2021年の目標」にて。

要約をせずにグダグダと

コロナ禍と「在宅ワーク

コロナ禍における生活様式の変容、というくくりで、「在宅ワーク」という働き方が急激に認知されたとは思うのですが、それが今年1年の受注につながったとは考えていません。ただ、在宅ワークに慣れているからこそ、引き合いに対して『適切に』対応ができ、受注につながったのかな、とは感じています。

営業の芽が出た

大切なところはここかな、とは思っています。昨年(2019年)は収益を上げることも大切でしたが、リテンションにも新規獲得にもそれなりに力を入れていました。大きなリテンション営業をしていませんでしたが、既存のお客様に対しては「いつでも仕事ができますよ」というスタイルで(いまでもそうですが)やっています。

新規獲得に関しては、力は入れたにせよ、「緩募」的な感じでアピールを続けていたので、

自身の体調について

おかげさまで脳梗塞の再発はまだ起こっておらず、1週間くらい、おそらく腸炎と思われるひどい下痢で脱水症状を起こして寝込んだのが10月にあったくらいで、体調自体はそれほど悪化しているわけではなさそうです。

ただ、コロナの影響で、昨年まで通っていたスポーツジムは通うのを止めることになり*4、運動の量が一時的に、特に春から初夏にかけてはほぼゼロになったのはちょっとした問題でした。室内でもできるトレーニング方法を調べて一時的にやってみたところそれなりの成果が出たので、今後も自宅や公園でのトレーニングに切り替えて運動不足の解消や健康維持に努めたいです。

「来年2020年の展望」の回答

racchie.hatenablog.com

昨年の総括を見て、ちょっと笑ってしまいましたが、実は昨年~今年前半にかけての納品予定となっていた案件が、コロナ禍で一時的に案件がストップしてしまい、結局今年(2020年末)にいったん納品、さらにブラッシュアップを来年(2021年)に行う、という予定になりました。基本的に半年程度大きなプロジェクトについては予定のずれが発生していて、今のところは「次の予定」に影響を及ぼさない程度ではあるものの、今後の動きによっては混乱が生じる恐れもあって、スケジュール的には予断を許さないところです。

もう一つ、「ブルーオーシャン」の話は、おそらく講師の案件を指しているはずです。プログラマ/SEとしての責務とは全く異なる、プログラムの書き方やその考え方を教えるという仕事は、ただプログラムが書けるだけではなく、体系立てて教えるというスキルが求められ、私の経験から*5参入が可能であり、ニーズのほうが多い仕事なんだろうな、とは思っていたのですが、実際に参入してみたところ、予想通りの感触で、スキルレベルも考えるとしばらくはこの手の仕事を「副業」としてやることは『アリ』かな、と思っています。

2020年に覚えたこと

すごくたくさんある気がします。実は、プログラミング研修の仕事をするにあたり、プログラムの基礎について事前の研修があり、それにできるだけ参加するようにしていました。特に研修直前の研修はコロナの影響でオンラインでの開催になっていて、参加しやすかったというのもあり、可能な限り出席をするようにしていました。

言語編

具体的に覚えた言語はなく、結局この数年目標にしているGo言語の習得は今年もお預けとなりました。今年業務で使った言語は、

加えて、DB系を扱う業務(PHPの項目でもDBを絡めたWebアプリが並んでいます)が多かったことから、SQLの記述回数も大変多かったなぁ、という印象を持っています。

その他編

Javaのプログラミング研修の関係で、MVCモデルについてきちんと学ぶ機会ができました。そして、Flutter/Dartに戻ってMVVM(Model-View-ViewModel)モデルについても少しだけですが知見を得ることができました。

それ以外だと、

  • 開発のメインマシンをWindows10にしたこと
    • WSL2との組み合わせで開発を行うようにしたこと
  • Docker/docker-composeの積極的な利用:Vagrantからの移行*7
    • クラウドサービス上でのDockerコンテナの利用(AWS ECS/Heroku)

といったところを習得したように思います。なかなか多忙な毎日を送っていて、いつも通り「付け焼刃」的な学び方ではありますが、それでも実績を作っています。

来年2021年の展望

展望なんてないですけどね(笑)。

と、毎年お約束の言葉を書いてみたのですが、正直なところ、来年(2021年)に明るい展望を見出すことはできていません。コロナ禍の再来、というか、来年の前半も今年と同様に経済活動の停滞を起こすレベルでコロナが蔓延するのではないかな、と、あえて言うなら若干悲観的な展望を持っています。

実際に今年私も契約の打ち切りや延期が相次ぎましたし、今年と同じレベルでコロナウィルスの感染が広がるとすれば、私の仕事も同じような状況になるだろうし、さらに受注がもらえなくなる可能性すらあると考えれば、あまり楽観視はできないかな、と正直思っています。

ただ、「現状維持」という目標を立てるのだとすれば、新規顧客・既存顧客ともに積極的かつ確実な営業を行って、「拾える」仕事は着実に拾わないと、売上に関しての現状維持は難しいだろうと思います*8

私自身は、今年初めて受託した「講師」という仕事についてはメインの仕事ではないと思っていますし、実際のところ、講師の外注に関しては繁忙期のみの対応であることはクライアントさんからも伺っていて、副業というか「出稼ぎ*9」とでも言おうか、いずれにしても短期的なモノであり、むしろ「複業(パラレルワーク)」というイメージで仕事をしています。したがって、あまりIT系講師の仕事を積極的にやっていこうとは思っていませんが、売上のためには出稼ぎもやむなしかな、とは思います。

もっとも、少し時間に余裕ができたら自分でコンテンツを作る方向に向かうのも悪くないかな、とは思っています。それこそ今年の思い付きの抱負でYouTuberとか言っていましたが、配信できるコンテンツのネタとしてはレクチャー系動画という方向も考えられるわけで*10、唯一明るい展望があるとすればオウンドコンテンツの作成なんでしょうかね*11

(最後に)ご挨拶を

繰り返しになりますが、本当に「コロナ」に振り回された一年であったと思いますよ、どの業界でも。それこそ『コロナだろうが何だろうが副業でガッポガッポ』みたいなMLM系の方たちですら悪い影響があったんではなかったろうか、と思うくらい。でも、誰が悪いわけでもないし、自助多助公助とか言いますが、まずは自分の身を自分で守ることができただけでもよしとしたいです。そのうえ皆様のお力添えもあってそこそこ収益もありましたし、本当に周りの人たちへの感謝の気持ちでいっぱいです。

最後になりました。

お仕事の関係者の皆様、そして、何の因果かこのブログにたどり着き、何らかの記事を読んでくださった名も知らぬ皆様、そして家族・友人の皆々様、旧年中は大変お世話になりました。皆様のおかげで今年一年なんとか生き抜くことができました。

来年2020年も変わらずお付き合いのほどよろしくお願いいたします。

末筆となりましたが、読んでいただいている皆々様のご健勝をお祈りいたして筆を起きます。

来年は少しだけゆっくりしたいなぁ。気持ちの面で特に。

*1:11月中旬に書いています。まだ「100%本決まり」ではないので、家の購入自体はまだ完了していません。予定が11月末になっているので。

*2:記事アップの10日くらい前、12/17に少し加筆をしているのですが、無事購入手続きは11末で完了、引っ越し先の諸手続きを進めていますが、引っ越し元の荷物をまとめたりすることがなかなかできていなかったりします。大掃除のタイミングで一気に片付けたい...。

*3:毎年7~9月は単発仕事ばかりしていますね...。

*4:都度会員だったので退会などの手間がなかったのは助かりました。

*5:塾講師のアルバイトから始まって、家庭教師やセミナー講師まで、意外と人前でしゃべる仕事はやっていました。

*6:2020年で一番使った言語です。

*7:Vagrantはまだ開発で使っています。受託で使うことも多いです。

*8:現状維持だから「座して待つ」のは平常時でもおかしい話だとは思うんですけどね。現状に満足して胡坐をかいている、ということですもんね。

*9:普段家で仕事をしている私が八王子の片田舎から毎日都会に出ていく姿は、ヨメから見ても私自身が見ても、そう見えてしまっていました。悪い意味ではなく。

*10:もちろんただのレクチャー系動画では差別化できないのでやりませんが。

*11:時間があれば、です。正直現状はブログのコンテンツを作るだけでも必死です。昨年の年末くらいにはストックが結構あったのですが、だいぶ減ってきました。しかも今年趣味ブログも開設したので記事を書く量は倍に増えていますから。困った困った。