何をモチベーションに(ソフトウェアエンジニアとして)働くか
前提として、ソフトウェアは何かを便利にするためにつくるものだ
だから、何かを便利にしたい(なってほしい)と思ってない人のために働いてもしかたがない
この考えで行くとすると、一般に言われる「人に楽しんでもらいたい」「喜んでもらいたい」という動機で働くのは私にとってはやや厳しいことがわかる
楽しめればよいと思っている人は、別に何かを便利にしたいとは思っていない
便利にするためにつくったものが結果的に誰かを喜ばせたならもちろんうれしいが
そこに内的必然性はないと感じるだろう
むしろ、「人の能力を高める何かを作る」方が自分にとってはしっくり来るらしい
能力の中でも、特に知性や創造性にあたるものがそれに該当しそう
運動能力とか身体知はあまり該当しなさそう
しかしアプローチによっては興味を持てるかも
自分は計算機そのものには大した興味がないのに「情報」はめちゃめちゃ好きらしい
だから、情報をうまく扱ったり、新たな情報をつくる人のことがむちゃくちゃ好きらしい
コンピュータサイエンスに行かずに学際情報系に行ったのは正解だった
そもそも向いてなかった気もするが
「理転する」という発想がなかったので受けてないだけだし
toCの場合、たとえば「絵を描く人のためのアプリ」や「音楽をつくる人のためのツール」は該当するだろう
一方、「音楽をつくる人の交流サービス」はちょっと違う
なぜなら交流そのものは、人の能力を拡張することには寄与しないから
「勉強に使うアプリ」とかは近いようでしっくり来ない
少なくともクイズの一問一答は人間の能力をあげるためのものではない
あれは能力を測るためのものだ
自分は体重計をつくりたいのではなく運動器具がつくりたいのだ
サブで体重計を作るのはいいけど、サブとしか考えられない気がする
それよりは、「読書やメモ書きを効率化するツール」とかのほうがまだしっくり来る
よく言われるように、「ソフトウェアの時代では余暇と仕事の境界が曖昧になっていく」のだ!
誰が言ってたか忘れた
ピエール・レヴィが近いことを言ってた気がする
だから勉強を良くするツールも、だんだん仕事っぽいツールになっていく
Notionをプライベートで使ったりね
だから、真に優れたSaaSにとってはtoBかtoCかは本質的な対立ではないことになる
#Notion が toB か toC かを気にするのは無意味だと思う toBの場合、「仕事の方法を良くするツール」が該当するだろう
DXとは、本質的には「より優れた道具を使いこなせる人間の価値観を、他の人々に押し付けること」だ
その結果、「すべてのホワイトカラーがソフトウェアエンジニアのようなツールを使う」ことをある程度"善"と信じていなければならない
ホワイトカラーというか、「すべてのパソコンを使って仕事をする人」と言うべきか
1億総「パソコンくん」化計画!
ここには「ソフトウェアエンジニア≒他の人より優れた道具を使いこなせる人間」という仮定があるが、それは現在たまたまそういう分野が一定数あるというだけの話
他の分野では他のタイプの人達から押し付けられるべきだということになる
その事実から目を背けるべきではない
また外向けにサービスを提供しない場合、「社内の開発を効率化するツール」の仕事も良いだろう
要するに自分は「良いツールをつくること」がモチベーションの源泉らしい
サービスや #コンテンツ を作ることを(少なくともITの仕事として)やりたいと思っていない可能性がある ただし「趣味ならできる」理由も、結局は「人に楽しんでもらいたい」が希薄であることの表れでは?
正直「売れるか気にしなくていいなんて最高〜」と思ってる面は否定できない(同人は気楽だ)
「サービス」というのは広すぎて語弊があるか
でも自分はサービスの中のツール的側面こそをもっとも愛している気がする
あるいは「プラットフォーム」と言っても良い
プラットフォームとしての側面を持たないWebサービスへの興味が弱い
一般消費者がよりよい #消費 をするための仕事を、モチベーションにすることはできない 実際自分は現職以外に toC の会社を一切受けていない
#クリエイター あるいは広く「知的生産者」を対象にしないような toC の仕事(とくに意志決定に関わること)をできる気がしない 開発者としての仕事はできるが、たぶん「実装する人」以上の働きができないだろう
しかし当のクリエイター自身は「よりよい消費をするため」に仕事をする人たちなのだ
その人たちと同じ価値観を共有してないで大丈夫なのか?
消費の裏方(受託でテレビ番組のサイトをつくるとか)は結果的にそれをつくるクリエイターのための仕事としてできるんじゃないかと思っていた時期もあった
が、おそらくこの発想で働くことは互いにとって幸福ではない
就活で自社開発の会社ばかりにしてなかったのはこの辺が関係している
それがお金になるかはまた別の問題
toB なら DX 需要に乗っかれるかもしれない
ただし、日本の DX 需要は「すべてのホワイトカラーがソフトウェアエンジニアのような働き方をする」ような思想に則ってはいない
欧米圏の DX は日本の DX よりこの側面が強いと聞く(うわさ程度だが)
この考えを共有してない人とは働くべきではない気がする
社内の開発効率化も(お金は生みづらいが)需要がある
そういう仕事はフリーランスで傭兵として関わるほうがあっていそう
toC でそのような需要を掘り起こすのが多分もっとも難しい
よく言われる通り「ユーザーは自分が欲しいものを理解していない」
ある種の toC サービスは放っておくと「交流サイト」になりやすい
ツールとしての側面がだんだん重要ではなくなる
可能な限り、サービスの強さと売上に相関のあるビジネスモデルが望ましい
これは別に「いいもの作ってれば売れる」といいたいわけではない
営業を軽視したいわけではない
サービス利用料や会員数みたいに、サービスの使いたさそのものが指標になる方がやりがいに繋がりやすそう、ということ
その前提の元での営業活動には関心があるかも
よい商品だから売りたい、みたいな
取扱高(サービス上のユーザーの実力に相関する)がメインの業界はこの点がやや異なる
いや、取扱高も広く「サービスの使いたさ」ではあるが
ECやUGCは影響が間接的になりやすい
タスクレベルでのモチベーションの違いはあるか?
もちろん「ツールをつくること」のコアに関わる開発ほどやる気になるだろう
「使ってもらうための改善」も嫌いではない
動線の改修や宣伝のための開発みたいな
しかしあくまでそれを「サブ」として扱いたくなる癖はあるかもしれない
マーケットインの考えは向いてない気がする
何かを便利にしたいと思ってる人のために働くというのは、ユーザーだけに限らない
当然いっしょに働く同僚もそのタイプの人間でなければならない
「もっといい道具がもっといい仕事ができるのに」と思ってない人を仲間にして頑張れるだろうか?
あまり頑張れない気がする
そういう人を積極的に助けたいという気持ちがわかなさそう
「あなたはそもそも助けられるべきひどい状況にいる」というのを相手に教えるところからスタートしなければならない
対顧客ならともかく、そういう人に仲間意識を持つのは難しい
「こいつ仲間じゃなくて客じゃん」という気持ちを同僚に抱きたくない
というか、そういう人が同僚いたとして、その人に与えるべきものは道具ではないだろう(何をすれば良いのか?)
しかし考えそのものを変えるのはきっと効率が悪い
一方で真に DX をする人はどこかで「人の考えを変えるための頑張り」もしなければいけない
目的をインストールするということ
いやでもそれは無理なのかも(そういう人が淘汰されるのを待つしかない?)