∑考=人

そして今日も考える。

マリオメーカーは革命

Youtubeで「明日香チャンネル」というマリオのゲームをひたすらクリアする動画チャンネルがある。ただ遊んでるだけじゃん、って話なんだけど、チャンネル登録ユーザ数がなんと40万人を超えているという驚き。

 

で、見てみるとこれが結構面白くて。40万人の人を魅了するのも頷けるというか。で、その面白さは何から来るものなのだろうか、と少し考えて見た。

 

もちろん、当人のプレイ中の解説とかも面白いんだけれど、やっぱり決定的なのは、「マリオメーカー」というゲーム自体の革命性、というが私の結論。

 

一応知らない人のために補足すると、マリオメーカーとはその名の通り、誰もが一度はやったことのあるであろうマリオのゲームを自分で作ることができるゲームだ。このゲームの何が凄いって、要はみんながゲームプログラマーになれる、ってことであり、つまりは消費者から創造者へ変わったと言う点が革新的なのだ。

 

創造市場というのは、近年は確実にマーケットとして拡大している。おそらく、大量消費の時代に多くの人が飽きを感じ、創造を新しい娯楽として捉え始めているからだ。近年成長するサービスの多くは人の創造性を駆り立てている。

 

LINEスタンプ・Instagramなど、あるいはメルカリとかもそれに該当する。そして創造する人たちに支えられたサービスは、アップデートのスパンが非常に早いため、消費に新しさが生まれる。結果的に利用者にとっても面白いものになる、という好循環が生まれるのである。

 

マリオメーカーの場合も、同じで、①マリオメーカーにて多くの人が娯楽としてゲームを創造する。②新しいステージをクリアする(消費する)人が増える、と言う流れで利用者が増えている。

 

ただ、マリオメーカーが他のサービスと決定的に異なっているのは、「消費の仕方」自体に対する面白さがあることだ。つまり、「人が難しいステージをクリアしている様」も一つの作品になる、ということ。

 

それはゲームのスポーツ性というか競技性によって達成される性質なのだろう。例えば、Lineの非常に作りこまれたスタンプやInstagramに投稿された美しい写真は万人が平等に楽しむことができる。そこに競争原理が存在しないからだ。逆にいうと「消費の仕方」に差異はなく、よって価値もない。

 

しかし、ゲームはプレイする人によってその結果に差異が出る。昔、神動画というサイトでゲームを最速でクリアする動画とかが流行っていたけれども、これらが人気が出るのは、普通の人にはできないことをできる希少性があるからで、それはプロ野球が人気なのと全く同じ理屈である。

 

大げさに言えば、マリオメーカーは、「誰にでも簡単に新しいスポーツを作るためのプラットフォームを作った」のである。スポーツ観戦に踊らされている人口数を鑑みれば、どれほどの影響を起こしているかは計り知れない。

「能力が高いこと」と、「パフォーマンスが高いこと」は完全に別である

今日は課長から夏のボーナスの評価を聞いた。結果は、

 

「期待通りの働き」

 

であった。つまり、普通ってこと。

 

「役職が着いた初年度は全員一律最低の評価をつけられる」という謎の社内規定によって、昨年は全く自分の働きが客観的にどうなのかがわからなかったので、ようやく純粋な評価がもらえると、ほんの少しだけ期待していたのだが・・・。世の中はそれほど甘くはなかった。

 

冷静に考えれば同じ役職内の相対評価で決まるので、年次が最も低い私の評価が低いのは当たり前といえば当たり前なのかもしれないが、ここ半年くらいは自分の成長を割と実感できていた。若干の手応えがあっただけに残念である。例のごとく、課長からはエラい人へのアピールが足りないのでは、とだけ言われた。

 

私はエラい人に媚び諂ったり、過度なアピールをするのが得意ではない。というか嫌いだ。わざわざ社外で交流することは皆無に等しいし、仕事上で、必要な時だけ伝えたいことを言うだけ。それが私の最大限のアピールだし、そのスタンスで今のところ問題はないと思っていたものの、もしそんなことだけが原因で他の人に比べて本当にパフォーマンスが低いと思われているのは少し癪だなーとは思う。

 

でも、事実ベースでアピール云々ではなく、それほど高いパフォーマンスを出せていない、とも私は考えている。

 

そもそもパフォーマンスとは何なのか?資料を作るのが早い、成果物のクオリティが高い、プレゼンが上手い、そんなことを考えている人ももしかしたらいるかもしれない。確かに現場レベルであれば、そういう人はパフォーマンスが高いと考えられる傾向にあるだろう。

 

しかし、部長、事業部長、などレベルが上がってきた時にそんな話はどうだっていい。全て手段でしかないのだ。その結果チームとして何を成し遂げたのか?が重要で、その結果に対する貢献度が個人のパフォーマンスなのだ。

 

学生の頃は、「能力が高いこと」と「パフォーマンスが高いこと」は同じであった。試験で100点を取れるやつは勉強において能力が高い。そして、100点という結果自体がパフォーマンスである。二つは全く同じなのである。

 

しかし、社会人の場合は、この二つは完全に別物だと考えた方が良い。なぜなら、仕事によってパフォーマンスのレベルが左右されるからだ。たとえるならば、100点満点の試験を実施するのか、1000点満点の試験を実施するのかを仕事によって左右される。そして、ほとんどの仕事は人事によって左右される。

 

もし、仮に同じくらいの能力を持った二人だったとしても、解くテストの上限が10倍違えば、満点の働きをしたとしてもパフォーマンスも10倍の差が開く、ということなのだ。そして、評価というのは基本的に「能力」に対してではなく「結果」に対して下される。

 

良い仕事を自分から取りに行くことがいかに重要であるかがわかる。

生きていくって

ドラマ半沢直樹の最終回で、主人公である半沢が、自分を裏切った近藤に語りかけるシーンがある。

 

生きてくって大変だな。ときどき思うよ。なんで銀行員なんかになっちまったんだろって。・・・

 

社会人になってこのシーンを見ると、妙にじーんとする。この「生きていくって大変だな」って言葉に非常に共感してしまう自分がいるのだ。私も時々思う。なんで今の仕事なのか。なんで今の自分なのか。

 

私は収入も安定してるっちゃ安定してるし、労働時間だって極端に多いわけじゃない。仕事だって別につまらなくはない。警備員みたいに単調な仕事に比べればずっと面白いはずだ。それでも、毎日大変なのだ。そして、これからずっと今ぐらいの大変さは続いていくのだろう、と考えるとやはり憂鬱である。


では、子供の頃は楽だったのだろうか。そうではない。考えてみれば、楽な時なんてのはほとんどなくて、常に切羽詰まっていた。夏休みの宿題は終わらせなければいけない、毎日部活はしんどいし、バイトもしんどいし、学生を全うするためには勉強も必要で、研究しないといけない。決して楽ではなかった。さっさとシンプルに社会人になりたいと思っていた。

 

ただ、学生の頃に比べて暇になった感覚はあるけれど、楽になったという感覚は正直あんまりなくて。一方で学生の頃よりも楽しくなった、という感覚もない。はて。学生の頃に思っていた社会人はもう少し面白いものだと思っていたけれど。

 

慣れてくると結局飽きてくる。業務に飽きるというのはもちろん一つあるとして、人間関係に飽きる、というのもあるし、毎日目にするものに飽きている、というのもあるかもしれない。

 

考えてみれば、大学院で別の大学にいったのも、5年も同じところに所属していると、もうさすがに飽きたな、と思ってしまうのだ。

 

今の私も5年目なので、たぶんそういう頃合いなのだろう。そもそもそんなに気の合わない人たちとずっと一緒にいても楽しいわけもなく。限界が見えていて、ほとんどのことが飽和状態になっているのだ。

 

ただただ飽きない何かを見つけたい。

ホンモノの要件定義

システム開発プロジェクトにおいて、まず最初に行う工程が要件定義である。要件を定義するわけであるが、ざっくり言うと、「何を開発するのか」を決めること、である。対照的に、設計工程では「どうやって実現するのか」を決めることも合わせて覚えておきたい。

 

要件定義は、作るものを決める工程であるが、それはお客さんからの要求を元に作る。だからこそ、システム開発の中では最も重要な工程だと言われている。だって、「作るもの」を間違えたら、どうやって作ろうがどれだけ美しく作ろうが全く価値のないものになるからだ。

 

例えば、テレビが欲しい人に対して、カメラを売ったって何の価値もない。それがいかに精密に作られていたとしても、だ。これから開発プロジェクトを進めるチームメンバ・ステークホルダーの仕事を無駄にしないためにも要件定義は確実に抑えたい。

 

ただ、一方で要件定義というのは非常に難易度の高い仕事でもある。難しい所以の一つが、お客さん自体が何がほしいのかを把握していない、ということである。これはシステム開発に限らずだけれど、いかに潜在的なニーズや課題意識を引き出せるのかがポイントだと言われる。

 

先ほどの例で言えば、テレビが欲しい人に対してテレビを提供しても満足してもらえない場合があるのだ。なぜなら、お客さんは、「何かを達成するための手段としてのテレビ」が欲しいのであって、本当に欲しいものはその「何か」であるからだ。その「何か」を提供するために必ずしもテレビが最適だとは限らない。むしろそうではないことの方が多いかもしれない。

 

もっとも厄介なのは、特に受注型であるSIの場合は、要件定義がミスっていても開発プロジェクトとしては成功、と判断されてしまうところだ。お客さんがすごく満足したわけでもなく、売上増加に貢献できたわけでもないが、お客さんからお金をもらってシステムを納品できればプロジェクトとしては御の字になってしまうという構造的な問題がある。

 

すると、ホンモノの要件定義を理解することもなく、「要件定義とはこういうものだ」みたいな誤った認識がまかり通ることになる。

 

話を戻すけれど、要件定義の難しさはお客さんとのコミュニケーション・ヒアリングによって答えを導き出していくことにあるのでは?と考えた人もいるかもしれないけど、実は企画型案件の場合でも同じ、もしくはそれ以上の難しさがあったりする。

 

企画型案件とは、ある課題に対してこういうことをしたい、そしてそれを実現するためのシステム開発のことである。お客さんの要求を元にシステムを作るのではなく、自分たちの理想を元にシステムを作る。だから、内部だけで進めることができるので一見すると簡単そうに見える。

 

しかし、「自分たちがやりたいことは何なのか?」を本当の意味で突き詰めて考えていくことに難しさがある。

 

一つは、理想を明文化・言語化するプロセスは難しいということ。お客さんが自分たちの欲しいものがわかっていないように、私たちも自分たちが欲しいものが実ははっきりとわかっているわけではない、ということだ。

 

特に、それが組織としての理想である場合、各々が考える理想像は微妙に食い違っていたりしてそれらの方向を合わせるのも一苦労である。また、変に理想を追い求めすぎたりして、青い鳥症候群のような、あるはずのない構想だけを描き、結果絵に書いた餅になる可能性も孕んでいる。

 

二つ目は、先ほどの話と少し逆で、地に足のついた発想をしてしまいがちであるということだ。どういうことかというと、つまり設計や実装のことをわかっているが故に、技術的な制約から理想を逆算して考えてしまうのである。まず、「やりたいこと」を考えてから「できるのかできないのか」を判断・検討すべきなのだが、頭の中で「できない」と判断してしまうと、そもそも「やりたいこと」として挙げられない。

 

目的から考えるべきなのに、まずツールや製品ありきで、あるいにニーズから考えるべきところをシーズありきで考えてしまう、というのはよくある話なのだろう。今の私たちもそんな感じで割と要件定義にハマってしまっている気がする。これらの点にはぜひご注意いただきたい。

Low-code開発とは

最近、「Low-code(ローコード)開発」というキーワードを耳にするようになった。具体的にはプログラミングが必要ない開発のことだ。そして、それはローコード開発用のプラットフォームによって実現される。

 

例えばどういうことか。通常であれば、html, css, javascriptなどの言語を用いてWebページを作成する。このはてなブログのテーマなども、誰かがそういったプログラム言語で記述したものだ。

 

しかし、ローコード開発プラットフォームでは、Webアプリケーション(ホームページ)などをドラッグ&ドロップなどの直感的な操作によって作成できる仕組みが提供されている。つまり、プログラムの知識がなくとも画面のデザインができるということだ。

 

他にもデータベースを簡単に作れたりする。もちろん、設計項目を考える必要はあるけれど、それをsql言語を使って記述したり、Webフォームとデータベースへの挿入を関連づけるのも直感的操作でできるので、プログラミング言語を使う必要がない。

 

ただ、これらの技術は最近になってできるようになった、というわけではなく、結構前からある統合開発環境Android Studioなど)でも提供されてはいた。ただ、なんというか技術者目線で考えれたときに、「コードを書かないのに開発と言えるのか?」といった葛藤や「技術習得を怠り甘えているやつのやること」みたいな風潮があったのだと思う。

 

私もAndroidアプリを作った時は全てコーティングで作った。GUIだと微調整ができない、という機能的な問題もあったが、やはり開発=コーディングという考え方があったからだ。

 

しかし、ローコード開発というキーワードが浮上してきたのは、世間にこのような開発が受け入れられ始めた背景が存在するからだ。考えてみれば、アセンブラに始まり、C言語、htmlなどプログラミングは時代を重ねるごとに簡単になってきている。それらも当初は技術者の甘えなどと揶揄されていたかもしれないが、今では当たり前になっている。それらを踏まえれば、今後も普及していくのは間違いない。

 

言うなれば、英語を必死で勉強して外人と話すよりも、翻訳アプリを使って話すのが当たり前になっていくようなものだ。確かに英語を話せるのはかっこいいかもしれないが、外国人と話すという目的達成のために必ずしも英語を勉強しなくても良いならみんなそうする。英語はただの手段だからだ。

 

プログラミングも全くもって同じで、要するにサービスを提供するための手段でしかない。だからわざわざ複雑で難解なことに時間をかけなくてもいいし、その方がビジネス的には合理的なのだ。プログラマーの時代が終わりを迎えつつあると思うと少し感慨深い。

 

ただ、誰でも使えるほど簡単なのか、というと正直そうではない。今、私も現在の開発案件でこのローコード開発プラットフォームを使って開発をしているが、使っていて思うのは、結局システム設計のスキルは必要だということだ。

 

本当に優秀なプログラマーであれば、何を使うにせよ、良い設計で勝負していくことを目指して欲しい。

ディスカッションバカになってはいけない

会社の中に一人や二人はいるのではないだろうか。ディスカッションになると饒舌に話をし、自分の意見をいけしゃあしゃあと発言する人。「議論で発言しないやつに価値がない」という意識が根付いた人間が陥りがちなパターンだ。

 

無論、会議の場で何も発言をしないよりはマシかもしれない。ただ、発言だけをひたすら繰り返すことにそれほど大きな意味はない。しかし、発言にある程度慣れてくると、自己顕示欲が出てくるのか、自分の思考に陶酔してしまうのか、なんなのか、そういう”ディスカッションバカ”になってしまう人がいる。

 

議論というのは基本的に2パターンしかない。一つは結論を出す場であり、もう一つは気づきを得る場だ。これらが意味することは何だろうか。それは決して「思考を深める場ではない」ということだ。なので、どんなテーマであっても、長時間議論をするべきではない。

 

もちろん、議論によって思考が深まることもあるだろう。だから、議論はどんどんしていくべきだ、と考えている人もいるかもしれない。でもそれははっきりいって生産性の低下を招いている。

 

気づきさえ得れば、各々がそのインプットを元に情報収集を行い、思考を深めることは可能である。次は結論を出す場で、再度話をすればいいのだ。その方がはるかに生産性は高い。

 

一般的な会議であれば、大抵の場合が時間が決まっているので、それほど無駄話に終わることは少ないかもしれない。しかし、休憩程度の小話のような、ちょっとした相談のような、それも割と立場の近い人同士の会話がこのような議論に発展していくケースも多いのではないか。

 

当の本人達は沢山話して頭の中はスッキリしているかもしれないが、それはたぶん一人でやるべきだったし、必要以上の時間を掛けている、場合が多い。たとえ会議の場ではなくとも、「結論を出すために」あるいは「気づきを得るために」という意識を持っておかなければ、ディスカッションバカに認定されることになるのでご注意を。

世界に希望はあるのか

会社が嫌で自殺してしまう人がいる。


そんな人に対して多くの人は「辞めればいいじゃん」と考えているだろう。私もどっちかと言えばそんな風に考えている。たかが会社だし辞めればええやん、と。

 

 しかし、「辞める」というのは問題解決ではないこともまた事実である。たとえ今の会社をやめたって別の会社に勤めなければ生きてゆくことはできない。あるいは、会社に勤める必要なんてない、という人もいるけれど、何かしらの手段でお金を稼ぐ必要はあるわけで。

 

つまり、「辞めた」代償に「始めなければならない」、という負債を負うことになるのだ。しかもその返済期限はそれほど長くはない。そして、「会社なんてどこも同じだろう」と推測で結論付けてしまうと、世界中に希望がない、だから命を絶つ、という判断になってしまうのだと思う。

 

私は別に会社がめちゃくちゃ嫌、というわけではないし、労働環境についての不満はそれほどない。ただ、すごくやりたい仕事をしているわけではないし、正直最近は退屈を感じることも多い。人との調整にもうんざりだ。そして何よりこんな仕事が一生続くのかと思うと、会社を辞めたくなることも当然ある。

 

しかし、辞めてどうするのか。でも何らかの労働は始めなければならない。では、別の会社を選んだとして、何かが変わるのだろうか。きっと何も変わらないだろう。こういった憶測で答えを出した瞬間、世界に希望がなくなるのだ。

 

だから私たちは実験をしなければならない、のだと思う。

自動化の先にあるもの

合理化・自動化の先に新しい価値は生まれるのだろうか。

 

自動化や合理化は大抵がその効果を定量的に測ることができる。例えば、自動お掃除ロボットルンバを使えば、掃除にかかる時間が丸ごと削減できるので、当然人がやるよりも明らかに良い、という判断がつく。こんな風に何かが自動化されるというのは効果が単純で価値が明白ではある。

 

他にも、高性能化、というのも価値が明白だ。テレビで言えば、画素数は高い方がいいに決まっている。CPUなどの性能も同じである。他にも定量的に測れる価値は必ずどっちが良いのか判断がつく、という単純明快な特徴を持つ。

 

しかし、そこに対するコストは発生する。そして、定量的に良いと判断できるものは必ず費用も嵩む。すると費用と効果のバランスを考えなければならない。つまり、必ずしも良いものを皆が選ぶわけではない。

 

また、一定の高水準を満たすようになると、それ以上のコストをかけたくない、という心理が働く。SHARPの亀山モデルが失敗に終わり、韓国メーカーのテレビが売れたのはそのためだ。ある程度高水準になると、単純に数値が高いだけでは「価値」として認定されなくなる。

 

現代に求められているのは、「数値が向上すること」ではなく、「数値が向上したことによってどんなことが実現できるのか」を示すことだろう。例えば、CPUなどの技術は今もなお性能という数値的な改善が求められている分野だ。CPUの性能が上がることそれ自体にはおそらく価値はない。

 

しかしながら、AI、ディープラーニングなどの演算処理に今のコンピュータスペックでは不十分であるという課題があるから、CPUの性能向上には価値が認められるのだ。さらに言えばAI技術を使うことによって、世の中のこれまで解決できなかった課題が解決できると信じられているからこそ、なのである。

 

などと考えていると、自動化や合理化もその先に何かに繋がる価値があるのでは?と思ったり。あるいは、自動化や合理化を最終目的にしてはいけないのでは、という懸念。今では〇〇自動化、みたいなキーワードは、それ自体が一つの価値であるように語られているけれど、もうそんな時代ではないのでは、という懸念。

 

実際、自動化されたからこそ生まれた新しい価値、というのはあるはずで。例えば、自動車。自動車が生まれた頃の自動車の価値というのはきっと、「より速く移動できる」ことだったはず。でも、自動車の価値はそれだけではないはずで。

 

例えば、「宅配サービス」なんてのは自動車の仕組みなしには考えられなかっただろう。自動車があったから「物を速く届けられる」という価値が生まれた。そして、物が速く届けることができるからこそ成り立っているサービスやそれを提供する価値が必ずある。

 

では、システムオペレーションが自動化されると、どうなるか。システムオペレーションが自動化されたからこそ実現できる価値とは何か。

 

その答えが見つからない。

幸せの方程式とは

 幸せの方程式とは何なのか。そんなことを考えると、大抵語られるのは、「良い人間関係」とか、「生活の保証」とか「家庭」、そして「お金」などだ。他にも、「他人からの承認」、「達成感」、「自己実現」みたいなものも候補には上がるだろう。

 

これらは多分正しいのだと思う。もちろん、年収が2000万以上になっても幸福度は上がらない、みたいに多ければ多いほど幸せなわけではないけど、やっぱりこれらが多いほど幸せと考えるのが妥当だ。

 

ただ、私は幸せとはもっと動的なものだと思っていて。つまりは幸せな状態が続いたとしても幸せではない、という矛盾した状況が起こり得るのでは、と考えていて。要するに、時間微分値で定義するのが正しいのでは、ということだ。

 

何を言っているのかわからない、という声が聞こえてきそうなので、もう少しわかりやすく。

 

例えば、すごく欲しい車があったとする。そして、必死に働いてお金を貯めて、その欲しかった車を購入できたとしよう。すると、どうだろう。すごく嬉しいはずだ。そのまま数週間はドライブに出かけるのが楽しみでならないはずだ。そういう状態は幸せと呼べる。

 

しかし、そのままさらに数ヶ月、半年と時が経った時に同じ気持ちが続いているだろうか。物を購入したことのある人ならば誰でも共感していただけるはずだが、その幸福感は決して続かない。その幸せの状態が普通になってしまうからだ。

 

絵にするとこうなる。車購入時の幸福度は高い。そして、車を手にいれたらその幸福度は変わらないはず。なのに、幸福度が異なるという矛盾が発生する。

f:id:n1dalap:20180511220720p:plain

なんでこんな現象が起こってしまうのか。その答えが、幸せとは動的に定義されるものだから、である。具体的に言うと、幸福度の時間微分値、つまりは上の絵で言う矢印の傾きが幸福度を決定している、っていうわけ。矢印の傾きが横ばい、すなわちゼロなので、車を購入して少し経てば、特別な幸福感は感じないというわけだ。

 

逆に、幸福を感じられるのはどんなときか。それが下記。

f:id:n1dalap:20180511220106p:plain

未来に今より幸福度の上がる状態が手に入る見込みがあると、人間はそれだけで幸せだったりするのだ。例えば、さっきの例でも、実は「あと6ヵ月頑張って働けば車が買える!」と考えている時が実は一番幸せだったりするのだ。恋愛で片思い中が一番楽しい、みたいなのと同じ理論。

 

なんとなく、読者のみなさまに私の意見は伝わったのではないかな、と勝手に思ってる。今の説明のまま終わると、数学的には、こんな式になってしまう。

 

d(幸福度)/dt = 幸福度

 

受験数学をよーく勉強した人とかが見ると、「幸福度=e(ネイピア数)のt乗で表せるのか!笑」みたいな誤解を招くことにもなりそう。

 

なので、ちょっと補足をしておく。結局、さっきの絵の縦線は「幸福度」という言葉で表すべきではない、という話。じゃあ、どう表すか。理想値、理想像、目標値、目標、そんな概念っぽいものではなかろうか。

 

「でも、理想って結局幸せな状態をイメージするんじゃないのか?」と問われればもうノーアンサー。今の日本語では、その両方の概念を幸せと呼んでしまうけれど、多分概念としては本当は別なんじゃないか、というのがギリギリ出せる答え。「憧れ」とかが近いのかも。ほぼ理想と一緒だけど。

 

ということで、最後まとめ。

 

f:id:n1dalap:20180511223822p:plain

 

今でも何かに憧れてますか。 

分担する技術

仕事を適切に分担するのはそれなりに技術がいる。

 

もちろん、どんな組織でも仕事は分担して進めているとは思うが、分担して進めただけの効果が果たして得られているのかが大事であって、分担したけど何かそんなに速く終わらなかったね、みたいなシーンは多々見かける。ということはつまり、適切に分担できていないと考えるべきなのだ。

 

分担する上での障害は大きく三つだ。

 

まず一つ目。超基本だが、ちゃんと分担できるレベルに作業をブレイクダウンすること。システム開発プロジェクトの場合は、WBSという階層構造で作業分解を行うが、ちゃんと分担可能な範囲に分解することが重要だ。

 

ちなみに、WBSを考えるためのツールは無料で公開しているので、ぜひインストールしてほしい。

play.google.com

 

ただ、このWBSを作る、とか、計画を立てるみたいな作業はそれなりに時間がかかる場合もある。少なくとも計画が立たないと他の作業が進められない、みたいなことになってしまっては意味がない。つまり、分担を考えるまでの時間はできるだけ短くしなければならないのだ。

 

どうするかというと、ざっくり分担できるレベルの粗い計画を立てる。そこから先の作業分解は分担を決めてそれぞれで進めてもらう。あとは各々で作成した計画のパーツを積み重ねれば全体計画となる。他にも例えば、計画と平行してもう見えている直近の作業に着手してもらう、でもいい。

  

そして二つ目。殊の外、日本企業においては人に対して仕事を割り当てる、みたいなやり方が取られるため、誰が何の仕事をやるのが適切なのか判断がつかないシーンが毎度毎度訪れる。特に、チーム内での検討事項は、「誰が」「何を」するのかを決めるということがよく必要になる。

 

ここで、大事なのはみんなで相談して決める、みたいなやり方はしないことだ。もちろんリーダーによってはそういうやり方を選択するもいるが、私に言わせればその時点で一歩意思決定が遅れている。セオリー的にはスキル適正、経験、稼働量などで決めるべきだろうが、適当でもいいからまず決めることが大事だ。別にスキルが足りなければ、それはむしろ成長のためだとも言えるし、稼働量の問題は進めてみてから再度調整すればいい話。

 

そして、最後。分担したら、ちゃんと任せること。特に、みんなよくわかっていない仕事をすることになると、なるべく多くの人が一緒になって考えようとしてしまうことが多い。これはここ半年間新規ビジネスの検討をしていたのでよくわかる。やたらとみんなで考える時間が多くなってしまうのだ。

 

 これはある意味良いアイデアを生み出すためには必要なアプローチにも思えるが、「みんなで考える時間」を作りすぎると生産性は極端に落ちる。みんなでやるのは「ブレスト」の場だけでいい。例えば、ブレストの結果をまとめる、みたいな仕事は一人でやろうが数人でやろうがほとんど大差はない。日本人の生産性が低いのは打ち合わせが多いのももちろんだけど、「みんなで考えましょう」が多すぎるのではないだろうか。

 

資料のレビューをむやみやたらにやるのも、ちゃんと任せきれていないからで、これも生産性が落ちる。レビューをすればするほど品質は上がるという幻想に取り憑かれている人は非常に多いが、たかがコミュ二ケーションツールである資料にそこまで過度な品質はいらないし、そもそも初めからちゃんと作れる人が作ればいい。

 

分業をちゃんと効率化するためには、必ず分担する技術が必要なのだ。

人はギャップを認識することしかできない

私たちが「これはおかしい」とか「間違っている」と判断する時、頭の中で行われているのは「比較」、それだけである。よく、変化に機敏に反応したり、違和感を検知できる人は感性の鋭い人と言われたりするが、感性の実態は、比較対象となる「答え」を頭の中に持っているかどうかが全てである。

 

例えば、以下の数式を見て欲しい。

 

1+1=5

 

ほとんど全ての人がこの数式をみると間違っていると考えるはずだ。そして、「間違っている」と判断した理由はたった一つ。頭の中で出した正しい結果と違うからだ。きっとほとんどの人が頭に下記の式を思い浮かべたはずだ。

 

1+1=2

 

すると、自分の前にある情報と自分の頭の中にある情報が違う。よって間違っていると判断するのである。つまり、自分の頭の中にある情報、すなわち”答え”と比較することによってのみ「間違っている」、「おかしい」などの疑問を抱くことができるのだ。

 

 なので、下記の例のように、少し複雑な式になった途端に判断が難しくなる。

 

1983726578÷24998378=924

 

この式は正しいか?否か。もちろん、適当に作った数列なので、電卓を使って実際に計算してみれば間違っていることは判断できるだろう。ただ、もう一度やって正しさを検証する、というのは、仕事をする上での良い方法論ではないし、少なくとも分担して仕事を進める意味がない。というわけで、この数式を見た瞬間に「何かがおかしいな」と違和感を抱けなければ確認者としては失格である。

 

ちなみに上の式は、複雑ではあるが、ちゃんと違和感はある。まず、結果の一の位が4になるのはあり得ない。なぜなら、4×8=32なので、少なくとも…2÷....8=となっている必要がある。逆のアプローチで考えても、...8÷....8という数式でありえる選択肢は1か6だけだ。だからやっぱりありえない。よってこの数式は間違いだ、と計算し直さずとも判断できる。

 

 

もし、一の位が1だったとしても、オーダーがおかしかったり、先頭の数字だけ計算して見てもおかしいということがわかる。いずれにせよ、「これが正しいはずだ」という知識をすでに持っているか、「こうすれば確からしき答えを瞬時に出せる」という方法を事前に知っておかなければ、妥当性を測ることができないのだ。

 

仕事の場合は、唯一の正解というものはないので、ざっくりでいい。また数式の例をするなら、

 

1983726578÷22998378=91

 

ぐらいであれば、何となく合っていそうだと判断して良い。(もちろん、誰が計算したのか、とか何の数字かによってはもう少し慎重に判断しなければならない場合もあるが。)実際に計算してみても、86.25…ぐらいなので大きく外れてはいない。数字の場合はこんなに外れるとよくないかもしれないが、「大きく外れてはいない」という状態を維持するのは仕事を進める上では非常に重要だ。

 

 もちろん、この考え方は自分が管理や確認をする側になれば当然求められるとしても、別に自分が作業者であったとしても、自分の頭で妥当性を判断する癖をつけるためにも「正解らしきものは何なのか」を事前に考えるようにしておくことをオススメする。慣れてくると、「何となくこれが正しい」という答えにたどり着くまでの時間が短くなっていくことだろう。

没頭感

「モチベーション革命」という本の中で、人間の欲求は五つに分類されるという話があった。達成・快楽・意味合い・人間関係・没頭、この五つである。

 

著者曰く、昔の世代は、達成や快楽の欲求が強かったそうな。まだ社会的な課題が沢山あったこともそうだし、何かを達成する(仕事で成功する)と、快楽が満たされる(高い車に乗れる)、みたなロールモデル的スキームがあったからだ。

 

ただ、現代を生きる若者が違うらしい。確かに自分の周りにも、高い目標を達成したい、みたいな人間は少ない気もする。それよりは人間関係を重視したり、仕事に意味を求める人の方が多い気はする。相変わらず快楽を追求する人間はいるけれども、今の時代は結構安価に快楽を買うことができたりもする。

 

そんな中、私にとっては、「没頭感」というのは昔から非常に大切な要素で。没頭し始めるまでに結構エネルギーがいるのだけれど、没頭しているときが楽しい。没頭する対象が好きかどうかはたぶんあんまり関係なくて、「没頭するから好きになる」というホリエモンの言葉に割と共感している。

 

ただ、昔と少し違うのは、没頭状態に突入する前に、「意味合い」を求めてしまうことが増えた、ということだ。例えば、アプリ開発とかも始め出すと止まらないし、絶対に面白いことはわかっているけれど、そこに意味を求めてしまうと、没頭状態に入る前に「めんどくさいな」となってしまって、進まない。そういう意味では、「意味合い」というのも大事な要素になってきたのだろう。

 

とは言え、先日も10時間ぐらい買ったばかりのスーパーファミコンクラシックをやり込んだぐらいなので、別に「意味合い」なんてなくたって没頭はできる。長くは続かないけれど、始める障害を小さくできれば始めることはできるのだ。

 

一方で、「人間関係」については今はまだあんまり意識していない。というのも、人間関係が全くないと、困るし確実に不幸ではあるけれど、今ある人間関係が大切にできればそれでも幸せ、って意味では十分な気もしている。友達の数が多いとか少ないとかはあんまり生きる上で重要なパラメータではないな、とまだ思っている。ただ、まぁむやみに人を毛嫌いする必要もないかなーというぐらいで。

 

とまぁ、自分の特性を客観的に考えてみると、私があんまり仕事を楽しめない原因の一つはやっぱり「没頭感」の欠如なんだろうな、という気がする。

 

例えば、日本人が当たり前にやるマルチタスクで進める仕事のスタイル。別にスキルとしてできないことはないけれど、やっぱり好きにはなれない。

 

あとは凄く漠然とした仕事も本当は好きではない。まぁある意味具体化するためにどうすればいいんだっけ?と考えるまでは没頭できていいんだけど、それを実行に移す(大抵が誰かに聞く、資料を調べる、打ち合わせを開く、みたいな)仕事は非常に億劫である。

 

逆に、まとまった資料を作ったりするのは結構好きで。基本作成する資料は作品だと思っているので、プロダクト志向の私にとってはいかに無駄な資料であってもそれなりに面白い。表とか絵とか作るのが楽しい。ただまぁそれって手段であって目的ではないよね?みたいな葛藤は常にある。実際資料作りにハマって仕事をやった気になっている人間もいるので。

 

だから、「プログラムを作る」みたいなことまでできれば、ちゃんとそれ自体に「意味合い」もあって「没頭感」もあって、かつ「達成感」も得られる、と私は思っているけれど、全ての作業を一貫してやることって組織で仕事をするとないわけで。やっぱりこれはサラリーマンの限界かなーという感じ。結局どの部分を担っても「おれが作ったと言えるのか?」という感じがある。

 

そんな思いを抱えながら、とりあえず今はまだ見ぬ気づきを探してひたすらやったことのない仕事をやってみてる。

「ため」のサービスの衰退

「ため」のサービスは時代と共に衰退する。これは歴史が証明している。

 

電話交換手という職業をご存じだろうか。昔は誰かに電話をかける時、実は今のように電話番号を入力して発信、みたいなことができなかった。そういう仕組みが存在しなかったからだ。

 

当時の電話交換手は、かかってきた電話を一限的に受け、発信したい相手に線を繋ぐという仕事を担っていた。今では考えられないが、ダイヤル発信という技術が生まれるまではそれが普通だったということである。

 

電話交換手の価値とは何だったのだろうか。通話ができること?遠隔地の相手との会話ができること?厳密には違う。相手と通話をする「ため」に必要な作業をするという価値だ。つまりは「価値」を実現するための手段に過ぎなかった。別のもっといい手段が見つかればもはや勝ち目はない。

 

比較的新しい話では、ショッピングモールは巨大なECサイトに置き換えられつつある。まだ百貨店等は残ってはいるものの衰退の一途をたどっていくだろう。なぜか。

 

洋服という価値を届ける「ため」に場所を提供する、あるいは沢山の洋服を見る楽しみを与える「ため」に場所を提供するのが価値だからだ。別のもっといい手段があれば、やはり勝ち目はない。せいぜい「リアル」の価値をどう訴求していくか、という別の対策を考えるぐらいの余地しかない。

 

もっとIT業界よりの話をすると、クラウドの普及が本格化している。一方で、オンプレミス、すなわち自社でサーバを保有するスタイルは衰退しているはずだ。すなわちサーバなどのハードウェアメーカーやサーバ構築などをこれまで担っていたインフラエンジニアと呼ばれる人たちの雇用は確実に局所化し、衰退していく。なぜか。

 

インフラはそもそも「アプリ」というサービスに直結するプログラムを動かす「ため」の場所でしかないからだ。自分たちでサーバを調達して、セットアップするよりもクラウドを使った方が楽で簡単であれば、当然そうする。もちろんセキュリティなどの課題はまだ残ってはいるが、クラウド化の方向性が変わることはないと断言できる。

 

最後に、現金。日本には拝金主義が蔓延っているし、一定数の人たちはまだまだ現金自体に価値を感じているかもしれない。ただ、現金も手段の典型例だ。仮想通貨というより良い決済手段が登場したことで、必ず、現金の発行数は減少する方向に流れていく。今は価格も不安定で、決済インフラが整っていないが、決済インフラを簡単に作る仕組みが出来てくれば、この辺りの課題は将来的にはクリアされる。

 

個人個人は感情で動く社会ではあるけれど、世の中全体としてみれば合理化されていくみたい。そして、それを支えるのは技術革新だ。このことは、特に仕事をする上では頭に入れておきたい。

 

そして、手段としての価値が淘汰されるスピードは近年格段に上がっているのは間違いない。例えば、数年前まで我々SIerというのはサービス提供の手段としての価値を提供するBtoBの業態であった。

 

だが、時代の潮流を受け、今や「サービス創出」を事業戦略に掲げている。一言で言えば、BtoCにシフトする、ということなのだ。価値を提供する「ための」ビジネスは今後確実に衰退するのだから当然である。

 

これは全てのBtoB企業に突きつけられている課題である。もちろん、差別化・専門化によって生き残る術はあるが、生き残れる企業数は確実に減っていく。かつ、新しい技術によって代替可能となったら終わりである。

 

また、少し違った味方をすれば、「会社」という仕組み自体が、個人の能力から生まれる価値を誰かに届けるための手段でしかないので、やっぱり淘汰されていく。最近、メルカリなど、CtoC市場が発展し続けているのは、つまりそういうことなのだ。

 

もしかすると、ECサイトの例など、プラットフォーマーと呼ばれるBtoB企業の威力と矛盾するように感じるかもしれないが、市場を制した一部の企業にしかできないビジネスになるという意味で、業界としては衰退せざるを得ない。

 

さらに付け加えるならば、今はまだ凄まじい影響力を持つプラットフォーマーも、実は手段でしかないことを考えると、将来的に全く別のものに今後置き換えられる可能性は高い。

 

究極的には、新しい技術を創出する人とサービスを創出する役割に二分化されていく。これを念頭に置いて、仕事をしよう。

DX時代のプログラマー

今、SIer業界はデジタルトランスフォーメーション(DX)の流れを受けて、ビジネスモデルの変革を余儀なくされている。では、どういった変革が必要になるのか。

 

これまでは、何となくお客さんの要望を聞いて、開発を受託できればそれで売上をあげることができた。プライムコントラクターの立場からすると、なるべく大きい開発案件を受注して、多くのベンダを雇って、マネジメントをすれば良い。

 

リスクマネジメントや高品質を言い訳に、新しい技術を使う必要もなかったし、新規開発以外は、既存のスキームのコピーでできるため、大した技術力は求められない。プログラマーの立場でも一度開発を経験すれば、そのシステムの有識者として重宝されるようにもなった。

 

今は既にそうではなくなってきている。プライムコントラクターの立場であっても、技術、特に最新の技術動向を知っていなければ良い提案ができない。これはSEに限らず営業もそうであるべきだ。お客さんの御用達に甘んじていれば、お客さんの事業継続が怪しくもなってくる。

 

当然、システムを実装するプログラマーだって、技術の理解を求められることになる。これまでは、特定のプログラム言語、例えばC言語Javaなどに精通しているだけでも使いものにはなったかもしれない。しかし、既に世の中はパッケージ開発があたり前で、すなわち、他の製品と組み合わせて何を実現するかを問われており、そういうスキルが技術力として再定義されている。

 

古い人は、コンピュータの根本原理を理解していることにすごく重きを置いていたりするけれど、別にそういった根本の難しい部分を理解しているだけでは使い物にならない時代になっている。

 

実際のところ、新しい企画や新技術の活用を検討する時に、果たして、今のプログラマー相当の人たちのスキルを活用しようとすると、壁にぶち当たることが多々ある。また、色んなものを組み合わせるということはステークホルダーも多岐に渡るので、たとえプログラマーであっても一定以上のコミュニケーション能力は必要になる。

 

別の言い方をすると、本来の”プログラマー”という仕事はほとんどの開発現場でいらなくなっているのが現状なのだ。だから、C言語がめちゃくちゃ得意とかJavaの経験がある、ぐらいでは正直なところ、ビジネス創出時には頼りにできない。

 

今、IT業界で生きていくために一番求められるのは新しいことを学ぶスキルに尽きる。この4年間を振り返ってみても、「この人は優秀だ」と感じる人は、新しいことを意欲的にキャッチアップできる人だった。別に世間の中で必ずしも新しい必要はない。要するに「ここまでは自分の領域」みたいな線引きをしない人が結局一番頼りになる。私も無意識にそんな人を目指していたのかもしれない。

 

もし、今プログラマーを目指す人がいるなら、新しいことを学ぶこととコミュニケーションスキルがないと、本当にレガシーシステムの保守・運用とかをやらされることになるので、注意した方がいいだろう。

生みの苦しみ

新規ビジネス創出・サービス企画。これらの仕事は、花形なイメージがあるかもしれない。確かに難しい仕事ではあるし、面白い部分もある。ただ、この半年くらいやってみて思ったのは、本当に泥臭い、ということだ。そもそも画期的なアイデアや斬新な発想が簡単に出るはずもないし、それらを本当の意味で使える形・売れる形にしていくのには手間もお金がかかる。

 

今の仕事を始める前に、「生みの苦しみを味わってこい」と課長から言われたことがある。確かに新しいことを考える、という時点でも苦しい側面はあった。そもそも仕事をどう定義するのか、仕事の進め方をどうするのか、アウトプットの結果をどう分析すればいいのか、全て考えなければならない。常に仮説を立てて、その通りにやってみて、ダメならブラッシュアップしていく、という繰り返しがベースにある。

 

ただそうやって、考えて自分なりの答えを出して創りあげていく、という活動は実は結構面白かった。この辺はアプリ開発とかにも似ている。理想の形を作る、理想を描く。こういうのは慣れてくると、稚拙だとはしても意外と考えられるようにはなってきて、形にできるようになると面白いのだ。

 

ただ、考えるだけ、で事が終わるならばいい。上述した通り、それは一つの仮説でしかない。「こういうことに課題意識を持っているから、こういうサービスを提供すれば売れるのではないか。」みたいな仮説を立てたとしても、実態はそんな上手くいかない。

 

そもそもユーザが課題意識を持っていない。すなわちニーズがない、という場合もあるし、サービスとしての価値を認めてもらえない場合もある。単なる心理的な抵抗を示されることもあれば、政治的要因に阻害されることもある。

 

これに対して、どういうサービスにすれば良いか?だけを考え直すのであればそれでも私は構わないと思っている。ただし、会社員である以上、そのサービスの中のパーツを自分たちが作る、あるいはそのサービスを展開する上での何らかの役割を担う必要がある。つまりは、そのサービスの中で自分たちが発揮できる強みを持っている必要があるのだ。

 

もし、その強みを持たないのであれば、自分たちでサービスを創出することはできない、ということと同義である。また、その強みとなりうる部分が自分たちのやりたい領域ではない、という場合も往々にしてある。はっきり言えば、今の私の状況がそうだ。

 

今の時代は一つの会社や一つの組織でサービスが完結することなど皆無に等しい。また、本気でサービスを考えるのであれば、適材適所でそれぞれの強みが発揮できる分野で仕事をした方が合理的だ。となると、強みがないのであれば、そのサービスの創出に関わるべきではない、と思う。ただのマッチング業者でしかない。

 

生みの苦しみとは、差し詰め、全体のサービス創出のためにどれだけ、割に合わない役割を引き受けられるのか、という部分も大きいと思う。