アウトプットは大変だ

本格的な家族の引っ越しは実は未体験で、学生時分や社会人一人暮らしをしていた頃にわりと住所を転々としていたので、一人で引っ越すのは何度となくやっていましたが、私が生まれて実家を引っ越す、という経験をしたのは今回で3度目、1回目はまだ子供の頃、2回目は一人暮らしをしていたアパートからの引っ越しと実家の引っ越しを同じタイミングで行ったため、実家側の引っ越しについてはノータッチ、そして今回の引っ越しで3回目なので、私主導での家族全体での引っ越しはよく考えてみたら初めて、ということになるんです。

ゴミの量がハンパない

今回の引っ越し、戸建て(賃貸)から戸建て(自己|ヨメ所有)への引っ越しなんですが、土地面積・建坪だけで言うと、旧居より新居の方が若干狭いんです。収納スペースも豊富にあるわけではないですし、引っ越しをするにあたって「いらないモノは捨てよう」「新居に持っていくものは現在あるものの2割、8割は捨てよう」と家族で相談し、本当に必要なモノだけを持って引っ越しをしようと話をしました。

その結果として、

  • 引っ越しにとても時間がかかってしまった
  • 捨てたモノの量がとても多くなった

という副作用が発生しました。というよりは、時間がかかった理由がモノの取捨選択のためであり、そして結果として捨てるものが多いため*1、とにかく毎日少しずつ時間を取って、「モノ」を捨てる|捨てないを判断、捨てる場合は更に分別をし、捨てられるタイミングでひたすら捨てていく、という作業を続けていきました。

捨て方の方法論はともかく*2、とにかく「これは捨てるべきか」という判断を下すのには労力が必要です。かなり強い意志が必要です。逆に、これは処分しないと判断するのは簡単で、労力も要りません。若干スピリチュアルな話になって恐縮ですが、日本の(宗教的)文化の中で「つくも(付喪)神」という、道具やモノに神が宿るという考え方があって、目の前にモノがあると、それにはなにがしかの思い出であったり感情であったり、という「神」がいるわけです。そう。この「神」の呪縛がモノを捨てられなくする要因の一つで、解放されるためには何らかの「言い訳」、神との契約解除のための儀礼が必要になるわけです。

個人的には好きではない考え方*3ですが、「こんまりメソッド」はまさにモノの呪縛をどのように解くか、というのを逆説的に、つまり呪縛されたままでよい(=ときめく)かどうかで判断をするように教えています。「ときめかない」というのはモノを捨てる=呪縛から解放されるための「言い訳」になり得ますからね。

ただ、いずれにせよ、捨てるためには意思を表出する必要があって、「ときめかない」と最初思ったとしても、なんでときめかないのか、と思わず考えてしまうのが「付喪神」のなせる業で、何らかの理由があって手に入れたモノが『なぜ不要だ(ときめかない)のか』と考えさせてしまうわけです。「ここにモノがあるのは必然(理由がある)」なので、手放さない場合はその必然を思い出せば済むのですが、手放す場合はその理由を上回る「手放す理由」を考える必要があり、それを生み出すのには時間も労力もかかります。

プログラミング講師という仕事と「事前研修」

そんな引っ越しをしながら考えたのが、プログラミング講師の副業をしたときに受講した「事前研修」のことでした。私自身は普段Javaを使わないので、Javaのプログラムを基本にした講師の仕事を受託するにあたって、単純に言語仕様のキャッチアップでもしておけばいいかな、と最初は高を括っていましたが、テキストを読み進めていくと、「プログラミングの基本」についての知識をあまり持っていないことを思い知らされました。私は教育を受けてプログラマの道に入ったわけではなく、独学で少し、現場でほとんどのプログラム技術を学んでいるので、講義で自分が教えなくてはいけない体系だった学習内容を研修でサラッと学習し、ずいぶんと目から鱗が落ちるような経験をしました。

でも、事前研修自体はそれほど苦痛でもなく、むしろすでに理解している断片的な知識を体系的に紐づける作業でしかないわけで、仕事の合間に受講していたこともあって楽しい研修だったなぁ、と記憶をしています。

そして、実際に現場に赴き、「教える」という作業を始めると、受講する立場と講義をする立場では圧倒的に講義をするほうが大変だ、ということに気が付きます*4。理由は簡単で、「知識を伝える」ために、どうやって伝えなければいけないかをその場で考えないといけないからです。知識をただ伝えるだけであれば、「講義」という形式をとって、講師が受講者に対して説明をする必要はないわけです。テキストがあるのだからそれを読めばいいんです。講師、メンターだの先生だのと呼び方はいろいろありますが、いわゆる「教える人」は「教えらえる人(受講者)」に、ただ知識を伝えるだけでなく、その知識を理解できるように説明をしなくてはいけないわけです。その説明も、あらかじめ「こうやって説明しようかな」と思っていたことが、現場の雰囲気で「あれ?この説明の仕方だとわかってもらえないかもしれないな」と判断して、その場で説明方法を変えたりする臨機応変さも必要だったりします。

覚える:インプット / 教える:アウトプット

「講師」という仕事は、アウトプットをしてなんぼ、という仕事です。もっとも、プログラマという仕事(SEという仕事)もプログラムを書いたり仕様を作ったりと、アウトプットをしてなんぼ、なんですが、いずれにしても、成果物を継続的にアウトプットしなくてはいけません。下世話な言い方をすれば、「アウトプットを出すことで稼げる」わけです。

逆に、「受講者」という立場は、その受講内容にもよるとは思いますが、基本的には何かを学ぶために講義を受講しています。覚えなくてはいけないことがあれば、それを、その場でするかどうかは別にして覚える必要があるわけです。講師の「アウトプット」を自分の「インプット」として取り込む、ということです。

ただ、仕事関係のいろいろなセミナーだったりカンファレンスに参加したりして私が思うことは、「あれ?このセミナー、俺には必要ないかも」と感じたりすることです。できるだけそうならないように事前にセミナー内容を吟味して参加することにしてはいますが、オープンカンファレンスで、ちょっと気になる講演に参加することもあったりします。そんな時に、「必要ないな」と判断したらその場で席を立ち、別の会場に入ったり「サボったり」することもしばしばあります。基本的には、自分の知っていることに対して、他者の知見で得られるものがあるかどうか、という観点で講演なりを聞き始め、得られるものがなければ去る、というのが私のスタイルです。

自分で講義を行う人間がこのようなことを言うのは矛盾しているようにも思いますが、学ぶべきことがないのにずっとセミナー会場で勉強している「フリ」をするのは時間の無駄だと思っています。そして、逆説的になりますが、セミナー会場で登壇する人間(=講師)は、そんなことを受講者に思わせないように、圧倒的に高品質なアウトプットを出力することで、受講者の学びの機会に対して「学んでよかった」「聞いててよかった」と思ってもらわなければいけないはずなんです。

プログラムを書くことももちろん、高品質なモノを書く必要があります。よく議論される「よいコードとは?」という命題の答えには少し遠いのですが、少なくともよいコードの必要条件の一つとして、「品質が高いこと」はあるはずです。何をもって「品質が高い」のか、の議論はあると思いますがそれはまた別の機会に。

会議(ミーティング)

さて、余談ですが私は昔から「会議」が好きではありません。

その理由の一つが、『会議がある情報の「一方的な伝達手段」である(そうなりがちである)こと』です。こういう言い方は語弊があるかもしれませんが、「会議」と称して一方的に会議主催者の持っている情報を伝えるだけの場を作ることで、主催者は「アウトプットを行った」、仕事をした、という気分になっている人たちがかなり多いと考えています。

同様に、そして好きではない理由のもう一つとして、会議参加者もその主催者の「アウトプット」をただ聞いて、インプットを得られた、と満足している人たちが多いとも思っています*5。それでも、会議は開催されますし、召集されますし、参加したらしたで後悔するか目を付けられるかのいずれかの結果が待っていて、それでもまた会議が開催され、召集され、というループが続くわけです。

会議の場は誰か特定の人がアウトプットをし、誰か特定の人はインプットしかしない、という場ではなく、お互いに議論をする場、つまりアウトプットとインプットが参加者すべてに発生する場だと思っています。

品質の高いアウトプットを出すために

コードの品質、という話ではなく、一般的なアウトプットの品質を高めるためにしなくてはいけない事は、とにかくアウトプットを出してみることに尽きるように思っています。

私も昔は、質の高いインプットを得られればおのずとアウトプットも高品質になる、と勘違いをしていたのですが、インプットの質とアウトプットの質は比例しません。言葉を言い換えると理解しやすいかと思います。

  • インプット=知識

  • アウトプット=成果・結果(≠知識)

知識があろうがなかろうが、成果を出すことがアウトプットなんです。

引越しの例で言えば、一軒家からアパートに引っ越す場合には、「知識」として床面積が減少することはわかるし、数値化すれば床面積の比率も分かるはずですが、だからと言ってその知識が「何を引っ越し先に持っていき、何を捨てるか」という結果(成果)には何ら影響を及ぼさないわけです。プログラミング講義に関しても同じで、知識を「覚える」ことだけをすればいい講義になるか、と言えばそれは違うわけです。ただの「知識のひけらかし」でしかない。

よく「自分の言葉で講義をすること」と言われます。講義の内容を自分のモノにせよ、とも。ただの知識として覚えるのではなく、知識を「自分でやってみる」=アウトプットを出すことで、そのアウトプットを自分のインプットとして置き換えて考えてみると、「あれ?これでは説明が足らないな」とか「この部分は自分の理解が足りてないな」とか、アウトプット自体の品質をセルフテストすることができるようになります*6

もちろんインプットがなければアウトプットを出すこともできません。成果・結果は知識に裏打ちされたものです。先ほどの引越しの例だと、床面積が50%減少することが分かっているのに荷物の絶対量が10%しか減っていない(という結果)となれば、当然荷物は引越し先では入りきらないわけですし、そもそも床面積が減少するかどうかわからない状態で荷物を減らすことはできないわけです。知識以上のアウトプットは出せません。となれば、知識も積極的にインプットとして取り込まなければいけません。ただ、インプットを得ることは今の世の中ではそれほど難しいことではないわけです。ネットを見れば情報はあるし、本を読まなくても音声や動画で情報を得ることだってできる。いわゆるスキマ時間でインプットを得ることはできるのですが、アウトプットを出すためにはスキマ時間で何とかなるレベルではありません。きちんと時間を取ってアウトプットを出さなくてはいけません。だから、とにかくアウトプットを出しまくる、出してみて、情報が不足しているようであればインプットを得て、更にアウトプットの質を高めていく。そうすることでアウトプットの質が高まっていくんだと私は考えています。

*1:捨てるモノが果たして所持品の8割であったかどうかは検証をしていませんし、家人の個々の判断ですのでわかりません。私自身、目指したのは8割減ですが、実際に捨てたのは半分ちょっととかそれくらいではないのかと分析をしています。特に捨てた/処分したのは衣類と書籍・メディア類。メディアについては「自炊」してデータ化できているモノについては処分しようと当初から考えていました。

*2:「断捨離」とか「ミニマリズム」とかいろいろありますが、私自身はミニマリズム的な考え方で持ち物を減らしていきました。一番特徴的なのは、「押し入れにずっと眠っていたモノは問答無用で捨てる」です。押し入れに眠っていたモノは、時期によっては前回の、つまり今回の移転元に引っ越してきたときからずっとそこにいたモノもありました。20年近く経つでしょうか。20年必要としていなかったモノを、例えば明後日必要とするか、と考えました。もちろん、ごくごく少ない確率で必要とするかもしれませんが、まぁ9分9厘=99.9%いらないはずなんです。だとしたら処分しても問題ない、と判断できるわけです。

*3:考え方だけじゃないですが、キライなのは。

*4:正直に言えば、プログラミング講師の前に別の、マーケティング系の講師としての登壇経験があるので、講義をするのが大変であることは身をもって知っていましたが、実際にやるとやっぱり「大変だなぁ」と感じるわけです。

*5:会議での発言を一切行わず、会議終了後に休憩室で「いやぁあの会議退屈だったよね」と愚痴るような人は間違いなくその手の人たちです。退屈だと思うなら「そんな上意下達のためだけの会議は即刻辞めて欲しい」と会議の場で発言するか、会議の場を立ち去るかした方がいい。私は立ち去ったことはないですが、会議の運営について文句を言ったことはあります。

*6:プログラムも実際にはセルフレビューをすることで品質が上がると思うんですが。

クライアントマシン用ラックその後

racchie.hatenablog.com 以前、こんなことを考えていて、実際に「ラックの設置」をしたのですが、中途半端に終わってしまっていました。引っ越しを期に、再度ラックをきちんと設計しなおして作り直そうと考えました。

現時点での進捗について

ラックシステムは購入して利用をしていました。もちろん自作、DIYです。

ラックのプラットフォーム

結局メタルラックになりました。しかもダイソーの。

https://www.daisonet.com/product/4549131586701

45cm×20cmという幅は、引っ越し前の家でデスクと本棚として使っていたスチールラックの間にちょうど空けることができた幅がたまたま20cmくらいだったことが理由で、後程ラックに「入れた」ものを列記していきますが、結果としてこの20cmという幅は使い勝手が良かったです。

上記リンクの棚板は普通のタイプですが、もう一つ、「転び止め棚」という、棚板に縁のついたタイプのものがあります。このタイプも2枚買っていて、トータルで5枚の棚板を購入しました。また、ラックの高さについては、延長用のポールを使って、デスクより少し高い80cmちょっと、更にキャスターもつけていて何かあった時に動かしやすいようにしていました*1

ラックに設置していたもの

地面に一番近いところに縁付きの棚板を設置し、ノートPCを縦置きで収納するためのスペースを確保しました。業務用のノートPC収納ラックを何かの展示会で見たことがあったので、それを参考にして、ノートPCを縦に置くために、やはり100均(ダイソー)で買ったファイルボックスを置き、電源を取ることができて充電も容易になるようにしました。これだけでラックの高さの1/3を取ってしまうのですが、ノートPCや大きなタブレットなどを収納できるので便利です。

次の棚にはMac miniを設置していました。2018年夏に壊れたマシンが実はMac miniで、全く同じモノをすぐに購入したのですが*2、特に暑い夏は熱がこもりやすいマシンであることが実経験でわかったので、メタルラックの中間地点に設置、更にUSBバスパワーで動くファンをMac miniのUSBポートに直結し、Macが動いている限りファンがMacを強制空冷するようにしました。10cmくらいの高さを取っていましたが、ファンの高さを考慮したことと、電源を入れるために開口部がそこそこ広く欲しかったからです。

その次の棚はネットワークハブでした。仕事部屋の中にあるマシンはすべて有線LANで接続していました。引っ越し前の家のネットワーク構成は、仕事部屋ではないところにインターネットのルーターが設置されており、そこから有線で仕事部屋にケーブルを引き込むことができなかったため、一度無線のAPを部屋に置き、そこから有線のネットワークを組んでいました。その関係でハブが必要になりました。無線LANの実行速度は100Mbps以上は出ていたはずで(11nを使っていたので)、室内の有線LANも100Mbpsでよかったのですが、おおもとのネットワークは1Gbps(FTTH)だったので、ギガイーサ対応のハブを購入して使っていました。

その上に2段棚が組んであったのですが、使い方を考えていなかったため結局ただの物置になってしまい、ごちゃごちゃした状態になっていましたが、唯一設置場所が決めてあったものはHDMIセレクターでした。ラックを組んでしばらくしてから買ったのですが、当初マルチディスプレイ環境で使っていた構成をシングルディスプレイに変更し、ディスプレイのHDMI入力が不足したため*3HDMI切り替え機を買って、ラックの棚板に結束バンドで固定、ケーブルを棚の中にそのまま這わせて使っていました*4

現時点で分かっている問題点について

そもそも、という話ですが、利用用途がきちんと決まっていないのに棚板ばかり増やしたのが問題の根底にいるのだとは思っているんですよね。

「多用途な物置」と化した

「棚(ラック)」である以上、何かを置くのが目的ではあるんですが、机に隣接した場所であることもあって、とにかく手元のものを置いてしまいがちでした。もちろん、そうする予定があったのも事実なのですが、それにしても雑多にモノを置きすぎたような気がしています。特に引っ越しの直前にはその傾向が見えていたので、何かを置くにしても用途を少し絞り込んでおくべきだろうな、とは思いました。

もっとも、この問題はラックの問題というよりは「片付け方」「整理法」と言ったところの問題なのだとは思いますが...。

電源がごちゃごちゃしていた

だいたいデスクやラックなどの什器類の背面は電源であったりケーブル類であったりが複雑に絡み合っていてごちゃごちゃしているモノだとは思うのですが、もっとスッキリとした配線にできなかったかな、というのは問題として挙げられます。

電源で必要なのは、下から言えば、

ですが、ノートPC用の電源は現状ではラックの前面に配置をしたいわけです。電源ケーブルを複数持っているわけではないので(そうするつもりもないです)、持ち運んで帰ってきて、ノートPCをラックに入れて電源ケーブルを挿して充電をしておく、というフローになり、出かけるときはその逆になるので、電源ケーブルの取り回しは楽になっていた方がいいわけです。

逆にそれ以外の電源については普段抜き差しをしないわけで、これは背後に隠れていた方がいいわけです。タップ(延長ケーブル)は複数使っていたのですが、特に手前に置いておいたものについては結束バンド等でフロント部分に固定しておいた方がよかったのかな、と思っていますし、そもそもタップ自体はいずれの場所にせよ固定をすべきだったかな、と感じています。

ケーブル類があふれてしまっていた

電源系のケーブルもそうなのですが、PCやハブなどを置いているのでどうしてもケーブルが「生えて」きます。結束バンドなどを使って縛ってしまうのがおそらく正解なんだろうな、と思うのですが、とりあえず作ってみて設置してみて、とやっていると、だいたい無造作に生えるようになってしまうのでどうしようもないです。

移転後に作り直したラック

現時点での仮設置状態ではあるのですが、ひとまずこんな感じで組んでみました。

f:id:racchie:20210302151321j:plain

上から、「スイッチングハブ(その上にはAirmac Expressで宅内無線LAN構築)」、「PC(開発メイン機)」、「Mac mini」、「ノートPC置き場」としました。実は引っ越し前に作ったラックの棚板が1枚余っている状態、つまり棚の段数が減っているのですが、結論を言えば開発用PCを設置したことで場所が圧迫されたということになります。ただ、これで床置きにしてしまうと場所を取るPCがラックに収まったのでこれはこれでOKです。

そしてこの後「プラダン(プラスチック製段ボール)板」をサイドに貼り付けると、イメージしていたものが出来上がります。プラダンは、特にMac miniの放熱に関連していて、ファンを使って強制空冷をしていますが、メタルラックのままだと前後左右どこからも空気が入ってきます。その状態だとファンを置く理由が薄れてしまうわけで、少し空気の流れを制限してあげればより効率的に「冷やせる」だろうと考えています。また、移転後のファンの位置はラック後部。排気させるようなイメージにしていますので、更に空気の流れを制御する必要があるわけです。

ミニタワーがメタルラックの幅ぴったりに収まったのはラッキーでした。前述のように、もともとは床置きを考えていた(覚悟していた)ので、設置すべきものが収まってくれたこと自体がラッキーですが、サイズもぴったりできちんと収まってくれている*5のは素晴らしいです。

作り直したラックの問題点

それでもまだ問題点は多いです。

ケーブル類の取り回しは「仮」状態

設置したばかり、というのもありますが、運用上はこの状態でなんとかなりそうですので、少し様子を見てケーブルは積極的に固定しようと思っています。すでにケーブルは背面でごちゃごちゃし始めていますので、これ以上いじらないようにしたいなぁ、と思っていますが。

「静音化」を検討しなければ

実はスイッチングハブの給気ファンが壊れていてすごい音を出していたので、今回の移転のついでにと静音ファンを購入しました。実は以前、我が家で使っていた(今も現役ですが)NASのメインファンが壊れ、静音ファンに交換したところ、とても静かになりいろいろと幸せになれたので、ファン類を静音ファンに交換していこうと考えているのですが、

  • PCのファン各種
  • Mac miniの空冷ファン

の2つがそこそこ大きな音を出しています。特にPCファンは結構大き目な音で回っているので、ちょっとだけ気になります。PC自体のリプレースもそのうち検討しなければ、とは思っていますが*6、とりあえず少しでも静かな環境で仕事をしたいんですよね...。

置き場所はここでいいのか?

ラック化したことで、設置場所の自由度が高くなっていますが、本当にこの場所でいいのか、といった検討は必要でしょう。もっとも、その前に部屋の片付けが必要です。引っ越しの荷物は置き場所が決まっていないモノが大変多いため*7、徐々に置き場所を決めていき、その中でそれぞれ適切な置き場所が見つかっていくのだろう、と思っています。

とは言えラックおススメかも

まぁ在宅ワークでデスクトップをゴリゴリと使う人は、昔はいざ知らず最近は少ないようにも思うのです。ノートPCを使うことが多いと思いますし、Mac使いであれば特に*8省スペースでスタイリッシュな作業机になるだろうと思いますが、デスクトップPCを使う方にはラックを組んで設置するのはかなりおススメです。

ただ、本当はもっとイカしたことをしたかったんですよ。PCも箱から出して、昔のGoogleのサーバみたいにマザーボードとかを直接ラックに固定してむき出しにしたかったんですよね。もうそこまでこだわらないし時間もないので普通にラックにPC入れちゃいましたが今回は。

*1:最終的に設置してから引っ越しをするまでにキャスターが活躍したことは一度もありませんでしたが...。まぁPC用ラックなんで普通は動かないのが基本ですわね。

*2:Core i5版のLate 2012モデルです。メモリカスタマイズが自分でできる、購入当時では最後のモデルでした。というか、Late 2014と現行M1がメモリカスタマイズできないだけなんだけどね。

*3:DVIとかVGAとかの端子もあったのだけれどやっぱりHDMIが見やすいし使いやすいですよね。

*4:購入当時はHDMI対応のKVMがあまりいい出物がなかったんですよね。本当はキーボードの切替もしたかったんですが。

*5:高さが数ミリ程度足らないようで、一番上の棚板はきちんと固定されていませんが、その上にモノ=スイッチングハブを置く必要があったことで固定の必要がなくなっています。

*6:ジャンク品のPCケースを買ってしまってそれを使いたくて仕方がないのです。そうなるとこのPCはNASなどに転用しようかと考えていたり...。

*7:なんならリフォームも終わってない状態です。床が丸出しの場所もあります。優先順位が一番低いので仕方ないですが。

*8:余程のことがなければMac Proを使うこともないでしょうしね。欲しいけど。

マーケオタクのボヤキ:SNSへの書き込みとソーシャルハッキングとか

私のSNSに対するアプローチは若干クローズ寄りで、全く見ず知らずの人とつながることのないように心がけています。SNSのプラットフォームによって閾値を変えていますが、一番クローズなのがFacebook(リアルに顔を合わせたことがない場合は基本的に友達として認めない)、逆にオープンなのはTwitter(全くの見ず知らずでも相互フォローをすることが多い)、という感じですが、もう10年以上になりますがそんな感じでSNSを楽しんでいます。

で、ふとある人の書き込みを見ていて思ったのですが、たぶん「身バレ」防止のためだと思うのですが、『訪問した場所をボカしつつ訪問したことを書き込む』という行為をしていて、「それってお互いに意味があるのかなぁ?」、と考えてしまいました。 もう一つ「身バレ」という観点で言うと、何かのイベントやセミナーなんかで講師/インストラクターをする人が、顔を隠してセミナー告知にデカデカと写真に写っている(顔の隠し方は決まって『絵文字(スマイル)』)というのも、意味がわからないことだったりします。

訪問した場所をぼかす投稿

全くどこであるかがわからない、というのであれば、わざわざ特定しようとも思わないのでいいんですが*1、中途半端に「〇〇駅前で美味しいソバ屋ハケーン」とか言って店の看板を巧妙に隠しつつ、近隣のお店も写るようになんとかカモフラージュしていると、どこなんだろうなぁ、と気にはなってしまいます。この時点では、そのお店側としても場所の検索をしてもらえたり、来店につながるアクションを起こしてもらえるのでまぁよしとしましょう。 しかし、その人(お店ではなく、お店をぼかした投稿をし続ける人)はいつも来訪した店をぼかしているわけで、いちいちその人が来訪したお店を検索しようとは思わなくなっていくわけです。仮に大親友であったとしても、「いつもなんかいい感じのお店行ってるよね」くらいの認識はするし、なんなら「今度飲みに行くときに連れてけよ」、くらいは言うかもしれませんが、特に調べることはしないわけです。

当人にしてみたら、SNSの性質上、身バレを避けたりとかお店への迷惑を考えたりとかするのかもしれませんが、当人が絶大なインフルエンサーでもない限りお店に迷惑は掛からないですし、逆にお店にとってみれば少しでもお店の情報が拡散してもらえればうれしいというケースの方が多いわけです(もちろんそう思わない方もおられます)。

顔を隠す講師の投稿

女性に多いですが、私の意見は(よほどのことがない限り)顔出しをされた方がよろしいかと思っています。ちなみにご自身の容姿に自信がないというのは理由としては却下です(笑)。 もし仮に、そのセミナーに行ってもご自身が顔を隠しておられるのであれば(その時に何で顔を隠すのかは大変気になりますが)まぁ「特段の事情」があって顔を隠さざるを得ないのだろう、と思いますが、オフラインでは顔を隠すことなく普通に話をし、ネットにだけは顔出しNG、とか、ジャニーズかなんかですか?と言いたいです*2。 もちろん、身バレすることでストーカー被害に会うという可能性は否定できませんし、特に女性の場合ストーカー被害は大きな問題だとは思っています。が、それでも顔出しはした方がよいかな、と思うのは、セミナーなどのイベントの信ぴょう性が顔を隠すことで、もっと言えば、ネットでは顔出しをせず、オフライン/リアルでは顔出しOKとするダブルスタンダード状態だと、集客時に講師の人柄を信用できない可能性が出てくるわけです。すでにご存じの方であればそれで問題はないわけですが、新しく顧客を呼び込む際には顔が見えている、またはオンオフどちらでも見えない方がその人に対する信頼性は高いので、中途半端な顔出しNGは集客につながらないと考えています。

参考までに:ROLAND『様』のサングラス

ちなみに、とあるテレビでROLAND氏(カリスマホスト)がテレビではサングラスをかけたままでいる理由として、「本業はホストであり、テレビを見てお店に来てくれればサングラスを取った姿が見られる、という仕組みづくりです」といった内容を話しておられました。コレ、マーケティング的には大変理にかなっていて、マスメディアと言う誰もが見ることができる場所でアピールをし、かつ自店舗(ROLAND氏の経営しているホストクラブ)への誘導をする、というパターンで、デジタルマーケティングであれば最近流行りのO2O/OMOと同じやり方なわけです。しかし、これはROLAND『様』だからできることであって、その辺のオッサンオバサンが「顔出しはリアルイベントだけですよ」と煽ったところで、そもそもイベントは顔目的ではないわけで*3、だったらご自身の親しみやすいお顔をお見せになられた方が相手の安心感も高まるというものではないのかな、とは思いますがいかがでしょう。*4

やるなら徹底的に、がマーケティングの基本

中途半端に情報を隠すのがマーケティングの王道、とも思われがちです。例えばテレビ番組の「続きはCMのあとで!」みたいなパターンであったり、ネットの記事で大事なことが後の方に書かれていて途中は全く無駄な字数埋めの「〇〇だったり△△であったりなかったりします」のオンパレードだったり、要は小出しにするのが期待値を徐々に上げていく方法であり、購入意欲につながると思っておられる方は多いのではないかと思いますが、でも、正直その手はもう見飽きた、と皆さん思ってませんか? 小出しにするパターンは実はその後ろに「ストーリー」が組み込まれていることが多いのです。特にテレビはその例にうってつけで、ドラマであれば「いいところでCMが」となるわけですが、バラエティーでも特集と特集の間ではなく、特集コーナーの合間にCMを入れ、更に言えば特集と特集の間はできるだけ切れ目なくすることで視聴者のチャンネル変更のタイミングを逸させるというストーリーを作っているわけです。 ネットの記事はそこまでできているか、というとそうではなく、小出しにするのと同時に「文章構成」がSEO的に重要視されているため(無意味な言葉の羅列で文字数を稼ぐことで「文字数が多い=情報量が多い」というSEOの弱点が解消されて現在の主流が「文章構成」になっている)、文章の目次を追えばサイトを全部見なくても必要な情報にたどりつけるのであまりうまくいかないとは思いますが、それでもきちんとした文章構成ができていれば内容自体も(それなりに)実のあるものになるはずで*5、小出し、と言うよりは順序立てた情報の出し方なんですが。 少し話がずれましたが、情報を小出しにして滞留時間を延ばすという方法を取るくらいなら、きちんと出せる情報を出し、それが「わかりやすいところ」に配置され、見やすく作るのがやっぱり基本です。

*1:世界のどこかもわからないのに写真数枚で場所特定をしろ(EXIFが消されていることを前提)、と言われても作業コストが見合わないんですよね。

*2:ジャニーズの場合、ネットにおける肖像権の問題がクリアでなかったからネットでのタレント写真の使用を禁止していた、と聞いています。最近それが「解禁」になったということは、肖像権の問題がクリアできたのか、あまりにも莫大な問題過ぎて解決が難しいと見たのか、それはわかりませんが。いずれにせよ、肖像権という話で言うならご自身をジャニタレと同列で扱うのは、肖像権の重さは同一だとしてもちょっと理由としては過剰な言い訳に聞こえてしまいます。

*3:ROLAND氏はホストであり、顔≒自分自身が商品なのだから、顔を見せるタイミングが限定的であることが商品価値につながります。ご自分がイケメン/美女/アイドル級だと自信をもって言え、かつ他者の意見もそうならこの手は使えなくはないですが...。

*4:そのテレビ番組、日テレの「Another Sky」でしたが、たまたま見てROLAND氏の評価がガラッと変わりました。ただのビッグマウスのイケメンくらいにしか思っていませんでしたが、話の内容や話し方など、随分「頭のいい」子だな、と感じました。また、運動部出身(サッカー部で全国大会にも出たとか?)だからか考え方も若干「体育会系」で、負けず嫌いで努力家な一面が見え隠れしていたりのいわゆる「ギャップ萌え」要素も多く、あぁこりゃ人気者にもなるわね、と思いましたし、私もファンになりました。だからと言ってROLAND氏の八王子にあるタピオカ屋には行きませんが。隣の店の方が好みなんだもん...。

*5:「タレント〇〇ちゃんの彼氏は?出身地は?」みたいなのでもそれっぽくはなりますよね。余談ですがあの手の記事はちょっと空白行が多すぎです。空白行もページ滞留という観点から言えばスクロールの手間を増やすことでサイトからの離脱時間を延ばすという「SEO対策」ですけどね。

小ネタ:世知辛い話・借金を返す

まぁフリーランスで仕事をしていると借金もそれなりにするわけですが、最近は儲けも多少出てきたので借金をきちんと返していこうかな、と、わりと真面目に借金払いをしています。

親子での考え方の相違

我が家はまだ母が健在なのですが、借金の話を母にすると、

「借金は早く返せ」

と言われます。もちろん早く返すに越したことはないので、その点については認識は一致しているのですが、どうも母の言い分は、

「借金は今すぐ返せ。金が手元にあるなら何よりも最優先して借金を返せ」

と言っているのです。良くも悪くも母は支払いにはシビアで、とにかく期限内に支払いをすることを是としていて、さらに言えば無借金であることは是、ではなく「当然のこと」であり、借金をすることはどのような状況であっても「他人様にご迷惑をかける悪行である」というマインドを持っているように思えます。

父がまだ存命の頃に一度借金を抱えて会社を倒産させたことがあって、そのトラウマが残っているのかな、とも思うのですが、私もその当時はいい大人でしたから、何が起こっていたかも理解をしていましたし、私にとってその経験がトラウマになったのかどうかはわかりませんが、同じように理解をしてはいないようです。

借金が「他人様にご迷惑をかける」というのは、私も父が会社存続のためにあちこちから借金をし、それを結局自己破産という形で返済できなかった*1、という事実を目の当たりにしているので、お金を貸したら後々迷惑をかけてしまう可能性のある人には借りないようにしよう、と心には決めていますが、金を貸すことを商売にしている人たちについては別、とも感じていました。

金貸し業、と言っても消費者金融闇金から、大手銀行や国の機関に至るまで、金を貸すことを商売にしている人たちはたくさんいます。彼らにとって、もちろん「踏み倒される」のは迷惑だと思いますが、早く返済することで彼らにありがたがられることはおそらくないと思っています。だとしたら、商売にしている人たちから金を借りて返すようにすれば、迷惑は(基本的に)誰にもかからないだろう、と考えたわけです。

「ある時払い」にはしない

そして、お金があればあるだけ借金の返済に回す、という考え方も基本的にはしないようにしています。「基本的には」と言っているのは、今ヨメが抱えている「住宅ローン」に関してだけは、一部の返済についてさっさと払ってしまおう、とは考えているからなんですが、このトリックについては後程。

借金の返済については、通常「毎月〇円」と支払金額が決まっています。と言うか、そういう返し方ができるところから借金を借りるようにしている、と言い換えてもいいのですが、例えば毎月3万円の返済があったとして、月に5万円の収入があったとしても3万円の支払いをし、20万円の収入があっても3万円の支払いにする、ということで、さらに言えば、月に2万円しか収入がなく、3万円の支払いができなければ3000円の支払いにとどめ、でも翌月50万円の収入があったからと言って、前月の本来支払わなければいけない返済額との差額(27,000円)と合わせて今月の3万円を支払う、ということはせずに、やっぱり3万円だけを支払う、という支払い方をしています。

これ、貸している方としては一見迷惑に見えますが、返済はとりあえずされているし、その分利息が増えるケースもあるため(延滞利息など)、それほど大きな問題として扱っていないように思えます。

借りている側にとってみればこのやり方のほうが都合が圧倒的にいいんです。毎月の収入が不安定であったと仮定すると*2、借金は月3万の返済として、毎月5万の収入は固定で見込めて、年に1~2回程度不定期に100万円の収入が加算される(その月の収入は105万)、みたいな状況の場合、100万円を借金払いに回すより、設備投資をする(仕事の効率化のために何かを買う)ほうがそもそもの収入のベースアップにつながる可能性もあるわけです。

私の事例で恐縮ですが、2018年から2019年にかけて収入が激減した時期があって、返済にも困る時期があったのですが、一度臨時収入が入った時に、返済は普通に行い、残りの収入を使ってAWSGCPなどのIaaSを契約し、業務用のサーバを構築したりして仕事を獲得したことがあります。学習(講義を受ける)などの「自分への投資」も悪くはないのですが、お金を生み出す即効性がないのであまりお勧めはできないです*3

借金は「悪」なのか

企業などではよく「無借金経営」を売りにするところもありますし、私も以前勤めていたベンチャー企業で「無借金」を売りに強気の経営をしていましたが、借金がないことは必ずしも企業の体質の健全さを示すわけではなく、投資を受けたり社員の持ち株分が結構大きかったりなど、売上とは関係ない部分での『資本』が大量に入ってきているだけだったりすることもあったりします*4

逆に、借金をしてでも業務拡大を図る企業もあります。これも「投資」なのですが、売上につながる投資をするからこそ、その借金を返すことができる、そういう見込みがある、という意味ではむしろ健全な経営をしている可能性もありますし、知己の経営者に至っては、「借金をしていた方が仕事をするにも張り合いがあっていい」と言い切り、大きな借金を背負っては更に大きな仕事を取ってくる、という人もいるので、必ずしも借金が「悪」だとは言い切れないと私は思っています。

ただ、これは父から学んだ経験ですが、「自転車操業」になっている状態では借金をすることはむしろ最悪だということ。フリーランスという立場だと、仕事は取れない(あっても少ない)、でも生活に貧窮していて借金をして、とりあえず糊口をしのぐ、という状況が長く続けば続くほど借金の存在は悪に近づいていきますし、この状況で心機一転、一発逆転を狙って借金をして投資をするのは悪手以外のなにものでもありません。

経営という観点で見れば、後先を考えずに借金をする、という状況になるわけです。だって、ずいぶん前から経営(家計)は苦しかったはず。だったらもっと前から支出の切り詰めや収入源の確保などを検討すべきだったろうし(できるできないは別にして)、少なくとも経営において「窮鼠猫を噛む」というケースはごくまれで、だいたい一発逆転投資なんて失敗するのが関の山ですし*5、そもそも計画的な経営ができていなかったということですし、いったんお店はたたんだ方がよろしかろう、と私は思いますが。

余談:自分語り

私自身は、表向きは『ラッキーなことに』と、10年近くフリーランスの仕事を続けて来れたことについて感想を述べますが、裏では、もちろん運が味方したことは否定をしませんが、ある程度計画的に事業の継続性を保てるよう、またずっと20~30年くらい、私が70歳くらいになるまでは事業継続ができるようにしよう、と考え、計画の実行をしていました*6。また、その計画は今でも進行中で、かつ常に変動をしていて、数年後に最適化できるように今から行動をしています。

もちろん最初はうまくいきませんでしたし、見えている世界も小さかったので「その時点で最適な解」を実行する必要がありましたが、徐々に世界が広がってくると、「今とその次」「今とその次とさらにその先」みたいな計画ができるようになり、いわゆる企業や国などで行われる『中長期計画』みたいなものも、漠然としたイメージでしかありませんができていたりします。ただ、実際には「一寸先は闇」でもあるので、中長期計画を策定して実行したところで途中で必ずなにがしかの修正が入ることを考えれば、あくまでもイメージとして持っているだけでいいかな、と思っています。

借金という話に戻せば、2011年に副業でフリーランス(プログラマ)業を始めたころから、実際には個人としてはそれよりも前から多少なりとも借金はしていて、ずっと返済を続けていましたし、今も返済はしています。が、2020年の後半くらいになってやっと、借りる必要がなくなり、少なくともここ数年は借りなくてもよさそうな経営状況になってきました。とはいえまだ返すべき借金は多いので、地道に返さなければなぁ、と思っています。

急いで返して意味のある借金

ヨメが今抱えている、いや、2021年から抱えることになった住宅ローンについても、一般的に言えば借金なので決められた期限までに決められた金額を返済すればいいのですが、これに限っては急いで、つまり、決められた金額以上を、決められた期限の有無に限らず返していこうと考えています。理由は、働けるうちに返しておきたいから(=働けなくなっても年金で返すことを考えないようにしたいから)です。2021年に私は50歳になります。ローンは35年ローン(フラット35)なので、最終返済時の年齢は75歳です。一応70歳までは働きたいな、とは思っていますが、その歳になって今と同じ水準の収入が得られるとは考えておらず、60歳くらいで収入カーブがピークアウトするかな、と考えていたりします。

ヨメは会社員ですし、年齢的にはローン完済年齢とフラット35の返済上限とだいたい合致するくらいの年齢、ということにしておいていただきたいのですが(笑)、そうだとしても年間で得られる所得金額は今後ずっと少ないまま。だとしたら、少しでも借金を減らしておいて、定年後の年金生活に入るまでに家の支払いを終わらせておき、老後は借金に縛られることなくつつましやかに生きたい、という考えがあります。いずれにせよどこかで今の生活水準が保てなくなるのであれば、あくまでも無理のない範囲で、ではあるのですが、後にやってくる借金を減らす必要があるよね、と言うのが夫婦の見解です。

前述の「借金をした方が張り合いがある」と言っている経営者と考え方は似ていますが、この決断を夫婦でしてからお互いに仕事の量が増えていたりします。「ガッツリ働いてガッツリ稼いでガッツリ返そうぜ」、とまでスローガンを決めたわけではないですが、なぜかそんな感じで仕事をしていたりします。張り合いは確かにあるかな。

*1:法的にはそれで問題はないですが、金を貸した友人知人にとってみれば「踏み倒された+逃げられた」と思うわけですし、当然顔向けもできないわけです。

*2:フリーランスなんて毎月収入は不安定ですから、私にとっては仮定でも何でもなく、「これが現実」なんですが。

*3:私もIaaSの使い方は使いながら学びましたが、顧客には「私は使える人間ですから」と若干ハッタリをかまして裏でヒーコラ言いながら勉強していました...。

*4:ご推察の通り、以前勤めていたベンチャー企業のことです。今どうなったか、興味もないので調べてないですが。

*5:八方ふさがりで何も見えていないから「とにかく稼げる」と飛びついて失敗、というのがお決まりのパターンです。

*6:計画がうまくいくかどうかが運の要素でしたが、現時点での結果としては「当たりを引いた」と思っています。

ユーザー企業にジョインすることの意味

年末だったり年度末だったり、他にも月終わり月初めといった、基本的には月中ではなく月末月初ですが、『転職エントリー』をよく目にします。いわゆる、「〇〇社を退職しました」「△△社に入社しました」的なヤツです。私は結局書きそびれてしまいましたが*1、退職するエントリーでは該社での実績アピールであったりやり残したことやわかれゆく仲間への思い、就職するエントリーでは前職のアピールもさることながら、該社で求められている姿を明示、今後のキャリアプランについて希望溢れる内容を書き連ねていることが多いように思います。

他人さまのことですが、ふぅん、って感じ

まぁ普通に考えて個人のブログなんてそんなもんでしょ、と思いますが、読後感想があるとすれば、「ふぅん」と思うくらい。まぁこのブログの読者の方もそうお思いだと思いますし。

実績のアピールに関しては、気付きにつながることは多いです。ある社内での課題解決方法として、どのようなフレームワークを使い、どのような意思決定プロセスを経て、どのような開発プランを練ったのか、みたいなことは、読んだ直後は本当に「ふぅん」ですが、実務上での躓きがあった時には他社における成功例として参考にできることもあって、頻度は高くないですがなんとなく読んで覚えていたりします。

やり残したことについても同様に、と言うかこれは反面教師としての側面が大きいのですが、失敗をした事例として参考にすることは多いです。特に「できなかった理由」についてはきちんと分析をされている方が多いので*2、プロセス部分を構築するときの参考にすることは多いです。

『求められている姿』については、「まぁそりゃそうだよな」としか思わないので読み飛ばすことが多いセクションです。そもそもヘッドハンティングされて入社している場合であれば、求められている姿についてはきちんと説明があって、いや、ヘッドハンティングをされるような人材であればそのあたりは説明をきちんと受けていなくても自分なりに理解をしているでしょうし、一般的な転職であったとしても、自分がこれから配置される場所については理解をして転職をしているはずですし、その認識には間違いがないはずです。

エンジニアがユーザ企業にジョインする場合の「立ち位置」

SIerから別のSIerに転職するとかいうケースであれば、だいたい(その道の)スペシャリストとしてそのまま入っていく、というパターンと、管理系の業務を行うパターンのどちらかになるのですが、エンジニアが例えばSIerからユーザ企業への転職をする場合、上記いずれのパターンであってもSIerとは違う意味合いを持っていると私は思っています。そして、それを理解できていないで転職してしまう人が多いのではないかな、と感じていたりします。

ユーザ企業が求める「(その道の)スペシャリスト」

例えば私であれば、「PHPPythonは書けるし、Javaはそこそこ使えるけどC/C++は苦手」なソフトウェアエンジニアであって、ハードウェアエンジニアやインフラエンジニアではないわけです*3。ですが、ユーザ企業にしてみたら、プログラムを書ける人(=ソフトウェアエンジニア)は「『パソコン』のことにとても詳しい人」に映るわけです。私自身の実体験として、ソフトウェアエンジニアとしてずっと生きてきたわけですが、非エンジニアの人たちから『パソコン』についてのアドバイスを求められることは多々ありましたし、『パソコン』の『ソフト』の使い方についてもよく聞かれたりしています。

スペシャリスト」としてユーザ企業が求めているのは、プログラムのスペシャリストではなく、IT全般に関するスペシャリストであるということは見落としがちではないかな、と思います。少なくとも私の知っている「ソフトウェアエンジニア」諸氏は、プログラムを書くだけではなく、ハードウェアを含めた『パソコン』に関する広範な知識を持っていますしインフラについても知識は豊富で*4、特にこの点で困ることはないのだろうと思っています。

ユーザ企業が(エンジニアに)求める「管理系」職種

スペシャリストはどちらかと言うと「社内SE」と言った方がよい仕事内容になるのですが、これとは別に「管理職」としての職責を求められるケースがあったりします。特にエンジニアという前職経験からは、プロジェクトマネジメントの経験であったり開発の上流工程経験だったりを求められ、その経験をユーザ企業の内部で発揮してほしい、という希望を持たれることがありますが、エンジニアは特にこの意味を勘違いすることが多いかもしれないな、と思っています。私がそういう方にお会いすることが多いから、かもしれませんが...。

ユーザ企業とシステム構築について相談するケースは多いのですが、私が開発側に立っているときに、ユーザ企業側の担当者さまが「元SE」ということも結構な頻度であるのですが、たまにユーザ企業側の立ち位置について勘違いをされていることがあったりします。

私の友人を吊るし上げるようで申し訳ないと思うのですがまぁ古い友人で「お前が悪い」と指摘もしている件ですので悪例としてご紹介をします。もともと大きなSIerでエンジニアを長く勤め、更に中間管理職も経験した、かなり腕利きのSE、という友人で、一身上の都合により、というヤツでユーザ企業に転職したのですが、旧知の中ということで私にユーザ企業で使っている基幹システムのリプレース、というなかなか大きな仕事の相談をしてきました。

要望としては、「他の企業からの提案も来ているので、最終的には提案を比較して発注をしたい」という初期フェーズからの依頼。要件に関しては友人も転職してすぐできちんと把握ができていないこともあり、ヒアリングベースで進めようかと考えていたのですが、友人いわく「ヒアリングはこちらでやるので要件定義まではこちらで出す」「要件定義に合致した提案をしてくれればいい」という言葉を信じて『要件定義』を待っていたのですが一向に出てこないんです。状況を確認すると、「資料ができてない」と。他の仕事があるので、というのでこちらで巻き取るべく相談を始めたのですが、なぜかその時点で彼の手元にあった資料はシステムの『詳細設計書』レベルの内容。

開発をする側としては、現状についての簡単なヒアリングだけしかできておらず、その状態で中途半端なレベルの『詳細設計書』を見せられて、お客様に対して、ではなく友人としてブチ切れたわけです。その時点で必要なのは要件を取りまとめることであり、個別要件に対して設計書を作る段階ではないわけです。そもそも、システムの開発を他社に依頼するのだから、システム設計は他社が行うべきことであり、ユーザ企業が基本部分の設計も未確定なのに詳細設計書を作るってどういうことだ、と。

ただ、彼も会社からは「システムをリプレースするための企画をし、提案を取りまとめよ」という指示をもらっていて、そのためにRFP(提案依頼書)を作成するつもりでいて、私と社外で雑談をしていた時に提案していたプラットフォームを採用することを前提に、つまり私に有利になるようなRFPを作るつもりであった、という申し開きがあったのですが、更に聞けば、同じプラットフォームを使ってシステム構築をするという別のSIerが出現したらしく、しかも私より安価な見積を出してくるので、もっと細かいレベルで指示をすることで彼らに諦めてもらいたいとかそんな理由でとにかく難題を仕様に盛り込むべく資料を作っていた、と。

ありがたいことだ、とは思うのですが、当然「難題」が突きつけられればこちらも手数が増えて見積額も増えるわけですし、ベースとなる部分の見積金額から見直すべきところを見直すこともできない状態で、最終的に(前述の通り)提案を比較したうえで決めるという条件で、業務要件が未確定な部分も多かったため資料作成は難航、更に金額も他社に比べて高めの提示をせざるを得ない状況になってしまったこともあって(他にも要因はたくさんあるのですが)失注してしまいました。

エンジニア上がりだと「システムを作る」=設計書を作ることと勘違いをしてしまうのでしょうが、ユーザ企業が求めているのはシステムを作るための要件を取りまとめることです。

実際には「スペシャリスト」と「管理系」のどちらも求めている

ちょっと失敗話が長くなってしまったのですが、彼のもう一つの過ちは、自分が「スペシャリスト」という立ち位置だと勘違いをしていたことです...、いや、この書き方は正しくないな。本来彼の職責はスペシャリストであると同時に管理職でもあったのですが、入社してすぐ、ということもあって、管理系業務に関してはまだ上司にお伺いを立てる必要があったのです。当時の社外での雑談でもその「愚痴」は聞いていて、私も上司攻略法をいろいろと伝授した記憶もあるのですが、どうやらその攻略法は使ってもらえなかったようで(本人曰く「忙しくてそれどころじゃなかった」)、結局その時には職責を果たせませんでした。

ユーザ企業としてはシステムの刷新などについては経験者が少ないわけで、できるだけ「システムのこと」をわかっている人に参画してほしいと思うわけで、最終的にCTOレベルまで職責を果たしてほしい*5と考えているわけです。そのためには社内における折衝能力も必要になるでしょうし、他の人たちに比べても圧倒的に自分が優位であることを早めに見せつける必要もあるわけです。

わかっている人はそう振る舞うはずですが、わかっていない人はそういう振る舞いができず、ちぐはぐな対応をすることになり、社内からも社外からも「あの人はいったい何者?」と言われるようになるわけです。私の知己に(先ほどの友人も含みますが)そんな憂き目にあった人はいないようですので安心していますが。

私だったらどうするか

そういう「理屈」を理解したつもりで私はいるので、できればユーザー企業へのジョインはお断りしたいかな、と思っています。少なくとも今の時点では、ですが。

まず、「自分が作る」という部分で、ユーザ企業が求めている要件の取りまとめという作業だけで終わってしまう(それ以降のテストや運用までお預けを食らう)というのはちょっと『面白くない』と思っています。手を動かして実際に動くシステムを作る方が今は楽しいと感じていて、そういう意味では最初の企画から運用の手伝いまで、ずっと関わることができる案件はとても魅力的だったりします。

ユーザ企業に入ることによって、自分の「IT全般」に関する知識の深さがどこかで止まってしまうことへの恐怖もあります。今はIT業界で働いているので、IT全般に関する知識は当たり前のように入ってきます*6が、技術を追求するためにはどうしてもその知識を深堀する必要があり、それも今の仕事の一つになっていますし、これも楽しい仕事です。でも、ユーザ企業に入ると、もちろん技術的な知識も必要にはなるものの、それよりも実務的な知識のほうが圧倒的に必要になります。特に今までシステム構築の経験がない業種だったりすると、まず業務知識が必要になり、そちらを深めることが大切になってきます。IT技術の追求よりよほど大切なことです。

それこそお金を積まれて更に三顧の礼を持って招聘されるのだとしても、私にとって楽しくないのでごめんなさい、という話です。それでも、どうしても私のような風変りな者を雇っていただける会社様がおられるようでしたら個別にご連絡をいただければ検討させていただきます。*7

余談:ある「退職エントリー」を読んだ

どこの誰、とは言いませんが、「退職」をした方のエントリーをSNSで拝見しました。大手の企業に長くお勤めで、書籍も出されたことのある、エンジニアさんとのことでした。SNSの書き込みでしたので文字数もそれほど多くなく、サラッと書かれたのだろう、とは思うのですが、実績に対して具体的な施策の紹介がなく、必要なことですが前職のお世話になった方たちへの謝意が投稿の半分程度を占め、今後の展望についても、次の就職先が決まっていないこともあるからかとてもざっくりと概念的で、正直「面白くない」エントリーでした。次の仕事に急いで就く必要性がないのだろうとは思うのですが、だったらSNSでいかにも商売っ気がありそうな感じで投稿する?と感じました。

自分をマーケティングする、という観点で考えると、退職エントリーに限って言えばアピールの場になりうるわけですし、特にコロナの影響もあったりして就職・転職市場も落ち込んでいる中、うまくアピールすれば仕事がもらえるだろうに、と、もう一度読み直してみたのですが、どこか「自分は過去の実績があるよ」「自分だけではなく周囲の人たちのおかげだよ(棒)」という、アピールポイントは過去の実績(しかも経験が豊富だ、というレベルでしかない紹介)のみで、このエントリー自体が何かを生み出すとは思えません。

せっかく早期退職をしたのだし*8、多少蓄えはあるとしても今のご時世仕事を確保できなければしばらく仕事にあぶれてしまうでしょうし、もっと積極的に仕事を獲得すべくエントリーを書くべきではなかったかなぁ、と他人事ながら思いました。

*1:最後に勤務していた会社を退職したのは2014年で、当時もブログは一応運営していましたが、今のようなシステマチックな運用になっていなかったことと、ネットへの掲載について大変厳しい会社であったこともあり、更に当時は転職エントリーが流行っていなかったこともあって書いていませんでした。思い残したこと、やり残したことはたくさんありますが、結構今のブログの中でそのうっぷんを晴らしているような気もしています。何を隠そうこの記事もその「思い残し」が一部含まれていたりします...。

*2:そういうことができる人だからヘッドハンティングされるんだよな、と正直思います。

*3:看板に出していないだけでインフラに関しては実務経験も多少ありますし、趣味レベルでも取り扱っているのでハードウェアについても一応対応は可能です。と宣伝と言うか言い訳をしておかないとね...。

*4:私も同様ですが、趣味レベルから始めていて、いわゆる「ヲタク」的な知識も多々持ち合わせているのですが、例えばシステム設計における非機能要件の選定等で机上設計を数多くこなしていたり、その設計をもとにしたハードウェア・インフラ構築や運用を経験しているので、非エンジニアのヲタク諸氏に比べれば実務に耐えられるレベルの経験は持っています。

*5:それに見合う報酬を支払う用意があるかどうかは知りませんが...。私も一度CTO候補という名目で会社に入って、なぜか私が入社した直前に入社したというもう一人のCTO候補の新入社員に「年下+後輩だから」という理由でこき使われ、安い給料をもらっていたことがあります。その会社はそもそもCTO候補が2名もいらない、という理由で早々にクビになりました...。

*6:それでも追いかけきれないほどの大量の情報が流れてきます。

*7:地位も報酬も保証し、私のわがままをいろいろと聞いてくれる、という私にしか利のないような条件が提示されれば検討させていただきますが、まぁそんな会社さんいないと思いますので...。

*8:企業の規模感とこの方の勤務期間から現在年齢を割り出すと、自主的に退職したのではなく企業の早期退職プログラムで退職をせざるを得なかったのでは、と推測をしています。「実績」も大変だなぁ、と思う程度で特に大きな実績ではなさそうですし...。

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

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コンテナをオーケストレーションするという簡単なパターンです。