とあるIT屋の独白

ITや経営について主に書きます

ハッタリに惑わされない考え方

例えば会社とか事業で成功したいとなった場合、ハッタリをかますこともあると思います。少し前にホリエモンが「ハッタリの流儀」という本を出版してから、個人的にはこういうハッタリをかましてくる人が増えた気がします。ハッタリをかますこと自体は一概に悪いとは言えなくて、下記の記事にあるように、やりたい仕事を掴むためだったり自己の成長の為にプレッシャーをかける意味で有効なのかもしれません。ただ、それはあくまでハッタリをかました以上は、実行するということが前提になっています。

ハッタリは冗談抜きで自己成長のために必要だと思っている話 | メモブログ


一方でハッタリをかますだけかまして、実行しないケースが世の中でどんどん増えてきてしまっているような感じもします。クラウドファンディングに出没する悪徳業者であったり、情報商材屋であったり、ハッタリだけかましてお金だけむしりとるような人達も多くいます。こういう人達が増えている現状を鑑みると、ハッタリを見抜く目というものを周りが養う必要が出てくるわけです。

note.com


ハッタリをかます人の多くは「努力すれば金を稼げる」という、何かある種のプロパガンダのようなものを発することが多いように感じます。もちろん成功する人は努力をしているのでしょうが、努力したら成功するとは限りません。下記の記事でひろゆき氏が言っている通り、「1つの決定的な要因はなく、さまざまなことが絡み合って、人生は成功へと導かれていく。」というのが成功する人の実態に近いのかなと思います。

diamond.jp


だから、ある種のがんばれば何とかなる的な思考には、まず批判的な視点を持つべきと感じます。新しいことに興味を持つの自体は全然良いことなので、まずは自分の生活に大きな影響を与えない小さい範囲から始めてみるのをおすすめします。いきなり仕事辞めたり何十万円も投資したりして、後にひけない状況になるのは悪手でしかないと思うので。

アカウントベースドマーケティング(ABM)とは

マーケティングと言うと、どのようなものを思い浮かべるでしょうか。最近だとあまりリアルでのイベントや販促やイベント等を行うのも難しくなってきたので、オンライン広告やメールマガジンSEOなんかを思い浮かべるかもしれません。もちろん、広く知ってもらういわゆるtoC向けの商材ならこのような施策になるのですが、toBとなると事情が変わってきます。
システムの業界では、SESでの案件獲得にみられるように、直接の顧客はtoBになるケースが多いです。toBマーケティングでもtoCのような施策ももちろん行うのですが、一方で顧客の会社の事情や予算などにも目をむける必要があって、toCとは異なる要素もあります。一般的に論じられるCRM(顧客管理)は、このtoBマーケティングには必ずしもハマらないケースがあります。そこで最近出てきているのが、会社という組織に対するマーケティング、アカウントベースドマーケティング(ABM)です。ABMでは下記の記事の通り会社に目を向けて、周辺の情勢やその会社のキーマンを加味して、いかにコンタクトを取るかという点が大事になってきます。

www.sunbridge.com


ABMで大切なことの一つとして下記の記事にある通り、いかに一社当たりの売上を大きくするか、ということです。企業が新規の会社と契約を結ぶというのはけっこうハードルが高くて、例えばオンライン広告をたくさん流したところで衝動買いが起きるといったことはあまりないわけです。なので、いかに顧客の企業の懐に入っていってビジネスチャンスがあるか深掘りしていくかが大事になってきます。

www.eigyoh.com


さて、そんなABMですが、どんなツールが現状あるかというと、代表的なものの一つとしてSPEEDAやNewsPicksでお馴染みのユーザベース社が出している「FORCAS」です。元々持っている企業のDBを強みに、既存顧客の分析や、既存顧客と類似性が高い会社のサジェスト、企業の状況に特化したシナリオの分析機能があったりします。どの顧客を重点的にアタックすれば良いか、ターゲティングの機能が充実している感じがしますね。

imitsu.jp


もちろん、こういったターゲティングは大事なのですが、既存顧客の売上をいかに最大化するかという観点での支援機能はパッと見た感じ、まだそれほどではないのかなと思いました。逆に既存顧客をいかに深掘りするかという観点でツール化されたものがあれば、けっこう面白そうだなとは感じます。

ソースコードへの意味付けと型に関する私見

以前に私はZennにて、動的型付け言語に関するポエムを書きました。

zenn.dev

 

その際、型が無いと無秩序になりやすいという点や、動的言語自体の問題というよりはそれを使う側に問題があるという内容に触れました。もちろん、使う側のレベルやメンバーの知識の知識のバラツキの為に、静的型付け言語を採用することが有効なのは言うまでもないです。型に合わないような入れ方をしたら事前にコンパイルで落としてくれるし、型を見ることでそれが取りうる値も想定できます。
ただ、型を使えば実装としてそれがOKになるかといえば、必ずしもそうは言えないと私は考えています。その型に対する意味合いが明確でないと、結局その処理何がやりたいんだっけとなってしまって、最低限の秩序は保たれるものの、全体として意味が分かりにくくなってしまうことは防げないとは感じます。例としては少し極端ですが、下記の記事にあるようなJavaのコード例とかで、何も考えないと手続き的な書き方になってしまい、この処理は何がやりたいんだっけってのが分かりにくくなってしまう感はあります。もちろん、これは静的型付けにかかわらず、動的型付けにも言えることではあります。

mizchi.hatenadiary.org


例えばHaskellにしても上級者が高難度な型をたくさん作ってしまうと、まさに型パズルのような地獄にハマります。私も前の現場で少しHaskellを触ったのですが、この型どうやって合わせりゃいいんだみたいな気持ちになって、本来的に処理としての意味合いがよく分からなくなった気持ちにもなりました。(もちろん私のスキルが低いと言われればそれまでですが・・)

これに対する一つの個人的なアプローチとしては、意味合いを明確にすべきコアな「ドメイン」に対しては型をしっかり定義し、下記の私のZennの記事にまとめてある通り、それをモデルとして図示化できることが大事と思います。逆にコアじゃない部分に関しては無理しして型付けする必要はないと思っていて、ある程度ゆるふわでも良いかなと考えています。

zenn.dev


今はPHPとかで、下記の記事のようにプロパティに型を付けられる機能が追加されています。Ruby3でも型をチェックできる仕掛けが追加されています。ので、動的型付け言語であっても、こういった型に関する意識は高まっています。

public-constructor.com


現在の私的な結論としては、コアなドメインに関してはしっかり型付けをし、コアじゃない部分は動的型付けでサクッと書く、というのがベターなアプローチではないかと考えています。結局何がコアになるんだというのは、きちんと業務的な重要性や概念を踏まえないと抽出できないので、第一歩は業務理解であることは言うまでもないです。メリハリをつけることで、その業務の理解が浅い人もコアな概念を押さえるところから始められるので、注力して見るべきところに集中できるのではと感じます。

責任と決めること

日本の政治家や企業のトップが無責任、という印象を持ってる人は多いのではないでしょうか。まぁ、前からそんな感じが続いているような気がしますが、いざコロナ等の問題が起きて一気に顕在化したような感じがします。なぜ日本では、多くのトップが責任を取ることを避けてしまうのか。今回は個人的に感じたことを書いてみます。
まず、日本の大企業や政治での意思決定で大切なのは「根回し」です。別に根回しが悪と言うつもりはなくて、根回しが多すぎるという点が問題で関係各所と調整して上に上がる時には、ほぼ決定事項となっています。結果、トップは根回しされた結果を否定するとそれがちゃぶ台返しと言われてしまうので、必然的に無条件に承認することが多くなってしまいます。

isaac-gaikokugo-school.jp


で、承認された物事の結果については自分は承認しただけだしということで、自分事にはなりにくいのかなと感じます。もちろん周りの人の言うことを聞くのは大事なのですが、最後に決定するのは組織のトップであって、そこをいかに咀嚼して判断するのかがメチャメチャ大事だと思ってます。逆に組織のトップの仕事ってそれが一番大事で、稟議で上がってきたものを承認していくだけのトップは、そもそもの役割を果たしていないと言えるでしょう。
何かを決めるときは、材料がちゃんと揃ってない時が多いと思います。でも、その状況下でも決めなきゃいけなくて、そのような時はどの選択をとればリスクが少なくてリターンが多いかというのを意識する必要があります。特に現代は不確定な要素が多く、ノーリスクの選択はほぼ不可能に近いと感じます。そういった際にいかにリスクを見定めることができるか、というのがトップに求められてくる能力と感じます。

careerlab.tenshoku.mynavi.jp


もちろんトップだけじゃなくて、私のような一兵卒であっても決めることの責任はきちんと持つべきだと思います。「誰が言ったから」とか「慣習だから」とか、今までならそれでも良かったと思いますが、それが正解とは限らない時代になってきました。だから、自分は何を正しいと思って選択したのか、その選択したものに対して自分はいかにコミットできるか、そういった姿勢が一人一人に求められてきているような気はしています。

コネクテッドTVと広告

最近、ちょくちょく「コネクテッドTV」というワードを見かけます。コネクテッドTVとは端的に言うとインターネットにつながるテレビのことなのですが、最近販売されているテレビは大体がインターネットにつながるかなと感じます。コネクテッドTVでは従来のテレビ番組に加え、YouTubeやABEMAといったインターネット配信される動画も視聴できます。YouTubeなんか分かりやすいですが、広告についても民放のように枠で固定された配信の仕方ではなく、ユーザの特性等によって自動的に配信される広告、いわゆるプログラマティック広告が配信されています。

otonal.co.jp


ということは、つまり今までWebやアプリのユーザをターゲットとしていた商材について、テレビを視聴するユーザをターゲットに広告配信が行えるようになってきているということです。下記の記事のように、コネクテッドTVの視聴者をターゲットとした広告制作を行うサービスも出てきています。YouTube広告なども安いというわけではないですが、それでも民放テレビのCM枠と比べたら、全然安く広告出稿できると思います。アメリカではコネクテッドTVの広告市場が大きくなっているみたいですが、日本でもこれから大きくなっていくのではと感じます。

prtimes.jp

現代のシステムエンジニアの仕事について考えてみる

システムエンジニア(SE)というと、システムの開発や設計を行うエンジニアです。そんなん分かっとるわという話ではあるのですが、最近はアジャイル開発やDDDといったアプローチが認知されるようになってきて、SEに求められる役割や仕事のやり方も変わってきてる気がします。というわけで、今回はあらためてSEの仕事について考えてみます。
まず、おそらくおおかたの人がイメージするSEの仕事は、以下の記事にあるようなウォーターフォールの工程において、要件定義や設計を行うというものになると思います。もちろん実際にはウォーターフォールで行われてる開発はたくさんあるし、イメージとしては間違いではないです。

proengineer.internous.co.jp

ただ、与えられた要件を開発する、それだけがSEの役割となってしまうことには私は少し寂しさを感じてしまう派です。以下の記事にあるGoogleのエンジニアだった方が、Googleを辞めて、よりユーザに近い環境で開発したいといった気持ちは分かります。
私自身も元々はウォーターフォールの現場で仕事をしていて、与えられた要件を開発していくこと自体は嫌いではないのですが、よりシステムやサービスの価値を高めるかといったことを考えたくて、転職もしたりしました。

amiq11.hatenablog.com


「価値を高める」といった観点はアジャイルが認知されるにしたがって、エンジニアにも少しずつ求められてきている気がしています。以下の記事にある「SEはお客様と一緒に価値を創造する仕事」というのはけっこうしっくりきていて、言われたものを作るところから脱却していく必要があると感じています。
今の環境は不確実性が高く、顧客やプロダクトオーナーが要件の正解を持っているとは限りません。だから、ただ言われるままではなく、本当に価値を作り込むという姿勢をエンジニアが持たないと中々良いものが出来ないと考えています。

logmi.jp


それはコンサルの仕事では、という意見もあるとは思います。システムや機能の企画フェーズにおいてコンサルを入れるケースも、出てくるでしょう、ただ、コンサルは企画するだけ、SEはそれを作るだけで上手くいくでしょうか。下記の記事にある通り、
「自分は企画しかしないからといって実装を考えず机上の空論でやりすごしていいはずもないし、他人が企画したものだからといって何も考えずに実装をしていいものではない。」
という考えは個人的には共感できるものがありました。

note.com

 


もちろん各々の得意分野があるので、大まかな役割は定めておくべきですが、「企画だけやれば良い、開発だけやれば良い」ではなく、エンジニアも企画段階で価値を見定める必要があるし、コンサルも開発フェーズ時に本当に価値があるものは完成できるか考える必要があると思います。だから、コンサルだからこれしかやらないとか、エンジアだからこれしかやらないという時代はおそらく徐々に終わっていき、自分が価値向上のために何が出来るかという姿勢で仕事が出来る人材が、
生き残っていくようになっていくと私は感じます。

経営資源としての情報の変化

経営資源というと、ヒト、モノ、カネ、情報の4つがあげられます。ビジネスでお金を動かすとなると、この4つのいずれかを動かさなければいけません。例えば旅行業や宿泊業は、顧客である「ヒト」が動かないと始まらないし、Amazon楽天などのEC業は「モノ」が動かないとビジネスになりません。コロナによる影響で、今このバランスがコロナ前と比べて大きな変化があると考えています。コロナによる影響として、「ヒト」が動くハードルが非常に高くなりました。ヒトが動けなくなった分、情報を動かすようなビジネスが大きく伸びて、おそらく今後もこの流れは続くでしょう。
「情報」と一口に言っても何ぞやという話なのですが、情報というと「データ」がまずは挙げられると思います。データというとデータベースに格納されるような、顧客情報や取引情報などのいわゆるレコード情報がイメージされると思います。もちろん、一昔前まではそれでもよかったと思いますが、最近ではITのコンテンツも情報資産としての重要度が大きくなっていると私は考えます。下記の記事ではコンテンツを「情報の中身」として位置付けていて、コンテンツの区分としてデジタルコンテンツやWebコンテンツを挙げています。

blog.core-j.co.jp


 情報を活用したビジネスといえば、データ販売やレポーティングのようなものが、まだまだイメージとして強いと思います。もちろん、こういったビジネスは今後も継続して行われていくと思いますが、いわゆる「コンテンツ」が今後はIT業界以外でも重要になってくると私は考えています。
例えば下記の記事にあるような製造業の例。製造業ではデジタル上で製品の評価等のシミュレーションを行う仕組みが、今後も検討されていくでしょう。もしそういった取り組みが上手くいけば、その仕組み自体をパッケージ化してビジネスができる可能性が出てくるわけです。まさに、自社で行われている業務の「コンテンツ化」であると私は思います。

monoist.atmarkit.co.jp


まだ当分コロナで人が動きにくい状況は続くだろうし、コロナが終息した後に人が従来通り動くかというと、そうでない可能性もあるわけです。だから、人が動かなくても情報を動かすことでビジネスが行えるコンテンツ化の取り組みは、意義があると感じます。