キャリアよりも小さなやりたいこと

先月の話ではあるが、主任というポストがついた。ついこの間まで新入社員、今もまだ後輩は二人しかいない。そんな中の、出世である。聞いた話によると役職がつかない人も一定数はいるらしいが、年功序列のお決まりみたいなもので、実質的な価値はない。

そんな経緯もあり、主任向けの研修とやらを先日受講させられた。テーマはキャリアである。平たく言えば、「あなたは将来にわたって何がやりたいのかを本気で考えましょう」、というやつだ。うちはITの会社ではあるが、会社が用意しているキャリアとしては営業とかコンサルとか、技術系のスペシャリストとか様々なものがあるので、その選択肢を考えることが趣旨となる。

日本人の中で、自分がやりたいことを明確に意識している人はほとんどいない。実際、私のグループは皆、私よりも年次が2年も上の先輩だったが、誰一人として、自分がどういうキャリアへ向かっていきたいか、ビジョンがはっきりしていなかった。かくいう私も技術系へ進むこと以外はそれほど考えていない。

あなたは自分のやりたいことを考えたことはあるだろうか。あるいは、やりたいことがない自分を嫌だと思ったことはないだろうか。

私は今まで自分のやりたいことを考えてきたつもりである。やりたいことをやる人生、自己実現が幸せだという仮説を信じているので、当然実行するための「やりたいこと」が必要である。逆に、やりたいことがなければ人生はつまらない、ということでもある。

だから、やりたいことがない、やりたいことがよく分からない自分が嫌であった。しかし、本当のところ、「やりたいことがある」状態にさえなれば、悩んだり考えたり苦しんだりすることなく、幸せになれる保証を手に入れたかっただけなのかもしれない。俗に言う、青い鳥症候群とはこういうことを言うのだろう。最近はこういう若者が多いのだとか。

さすがにこの年次にもなると、自分が永続的にやりたいと思い続けられることなんてものはない、ということを悟ってしまいつつある。人生というのは、具体的なやりたいことを見つけて、それをやって、それに飽きて、また別の新しいやりたいことを見つけて、それをやって、の繰り返しである。悩んだり考えたりする時期があって、楽しい時期があって、それを繰り返していくだけだ。そういう過程を通して、自分の中の抽象的なやりたいこと（しかし、それは単なる憧れとかではなく経験から帰納化されたもの）を理解していくしかないのである。

だから、今やりたいことがなくても問題はない。というか、子供の頃はやりたいことなんてなくても楽しかったんじゃないだろうか。ちょっと昼休みにドッジボールしたい、とか気になるあの子と話したいとか、みんなで花火やりたいとか、そんな些細なことをやってるだけでも幸せだったのではないだろうか。

ただ一つ、子供の頃と今の違いは、未知の領域の広さである。子供は普通に生きているだけでも教育の場で新しい情報を与えられ、初めての経験をさせられるが、大人はもう自分から動いたり行動パターンを変えない限り、新しい興味や関心を得ることはできない。そのため、些細なやりたいことすら簡単には思い浮かばないこともあるだろう。

そのためのやりたいこと探しだ。人生全てを捧げるほどのやりたいことを見つける必要はない。ただ少しでも新しい情報に触れる、新しいことをしてみるぐらいの努力をしないと、小さなやりたいことさえ見つからない。

さて。長期的なキャリアという視点にたつと、今の選択がすごく重要で、それを間違えると人生全てが崩壊するような気持ちになったりもするだろう。しかし、どれを選択したところで大して変わりはしない。むしろ、一度選択したきりで思考を停止してしまうのが問題なのだ。

ライバルの設定方法

昔は、ライバルと呼べる存在がいた。勉強でコイツには負けたくない、バスケットでこいつには負けたくない、ゲームでは、おしゃれでは、腕相撲では・・・などなど。数えればキリがない。たぶん私が勝手に思っていただけだけれど。

ただ、おそらく私に限らず、子供の頃は、この手の「誰かに負けたくない」という思いを抱きがちな時期なのではないかと思う。子供の頃に人間関係が悪くなったりするキッカケの一つには、常に敗北から来る嫉妬心がランクインしていたはず。

子供というのは思慮が浅い。例えば、自分と相手の生まれ持った才能の違いとか、育った環境の違いなどには目もくれない。ただ、今の自分と今目の前にいるライバルとの違いがあることを受け入れられず、負けたくないと強く思う。

この思いが良い方に転じれば自らの能力の向上につながるし、悪い方へ転じれば相手を陥れるセコいやつになってしまう。私は決して性善説を信じているわけではないが、少なくとも自分の経験では良い方に転じている人の方が多かった。というわけで、ライバルという存在は、実は自分の能力を高めるためのモチベーションとしての効力が高い。

ただ。会社に入って、ライバルと呼べる存在が身近にいるだろうか。

年齢を重ねると、人は人、自分は自分、という思考がかなり強くなる。これは幼少期とは逆で、相手の今ではなく、その人を取り巻く環境とか、その人の特性みたいな、自分ではコントロールできないところに原因を見出してしまうからである。

例えば、私はシステムエンジニアという仕事をしているが、このシステムエンジニアという仕事は文系の人間もかなりの割合を占めている。文系・未経験でもOKのIT企業はたくさんあるのだ。ただ、ちょっとした専門用語とか、サーバの操作とかは理系・情報系の人間の方が馴染みやすい。

さて、あなたが文系の人間だとして、理系の人間が例えばLinuxのサーバコマンドをバリバリ叩いたり、シェルスクリプトを作ったりできるところを見て何を感じるだろう。子供の頃なら、「なんであいつにできるのにおれにできないだ！おかしい！」と思う。しかし、大人になった今であれば、「あいつは理系でおれは文系だから能力に差があって当然だ」と考える。そういうことである。

もし、ライバルがいないと思うのであれば、自分が常に上記のような思考回路で他人を見ていないかを少し振り返ってみてもいいかもしれない。一番の原因が相手は相手、自分は自分と完全に切り離して考えてしまうことなのだ。

もう一つ原因があるとすると、社会人というのは学生の頃と違って、チームを構成するメンバの多様性が広がっているために、自分と相手との差をより明確に感じやすい、ということだ。

学生の頃に一緒につるむメンバは必ず、同じ学校とか同じ部活とか、生活の大部分を共有しており、かつ趣味嗜好も近いことがほとんど、そしてほぼ間違いなく同年代である。また、高校以降は能力の近いメンバが同じ学校に集まるようになる。類は友を呼ぶ、と言われるように、同類なのだ。共通点が8割ぐらいあるので、決定的な差を意識することは少ない。

社会人は背景も違うメンバの集まりだ。もちろん、思考パターンや行動特性など抽象的な共通点は多分にあるのだろうが、具体的な経験、興味・行動などは異なる。また、日本に強く根付いている年功序列の精神のせいで、先輩とか年上の人と対面すると、無条件に自分が下だと考えてしまうよう洗脳されている。

ライバルとはそもそも自分と同等相当の能力を持っている相手に対して定義される言葉なので、先輩に対してこの概念を当てはめることは難しい。ただ、それは先輩とは自分よりも経験があり自分よりも優れた存在だと勘違いしているからにすぎない。同様に、後輩が自分よりも経験が浅く自分よりも劣った存在だと勘違いしているからにすぎない。

確かに経験は大切である。長く経験を積んだ人へ敬意を持って接することも日本ではやはり大切だ。しかし、経験があるから自分より優秀、ということはない。ここは断言しておく。経験から何を学んだかが重要であり、経験を何に活かしているのかが重要なのだ。だから、なんかこの人に言われると腹立つな、と思う先輩をライバルとして考えてみてはどうだろう。

Webテストの数学攻略のコツ

最近、リクルートスーツに身を纏う学生を良く見かける。エントリーシートがどーたらこーたら。就活って8月からになったんじゃなかったっけ？面接が8月からだから就活準備としてはそろそろ本格始動という感じなのだろうか。

就活というと、エントリーシートの書き方はもちろん、Webテストという、日本の勉強しない大学生には頭を悩ます関門がある。中でも文系諸君は数学に苦しめられていたことだろう。私も数名の大学生のWebテストを手伝った記憶がある。

ただ、Webテストの問題自体はそれほど難しくはなく、ゆっくり考えれば誰でも（中学生ぐらいの知識があれば）解ける問題がほとんどである。つまり、難しいポイントは時間内に全ての問題を解くことなのだ。たぶんみんなそれをわかっているはずで、だからこそ数学のWebテストを受験する際は電卓を脇に置いて挑んだことだろう。

実は数学のWebテストにはコツがある。というよりも、そのコツを抑えることこそがWebテストで求められている能力だと私は理解していた。それは一言で言えば概算力であり、オーダーを把握することだ。そしてここがこれまでに私たちがやってきた数学のテストとは明らかに異なる点でもある。

例えば、こんな例題を考えてみよう。

問題

以下の表はとあるコンビニの過去3年間の売上である。 2011年において、ファーストフードの売上は、同年の売上総額のおよそ何％を占めているか。

項目	２００９年	２０１０年	２０１１年
ファーストフード	310	270	320
日配食品	150	170	140
加工食品	390	410	370
タバコ	170	210	200
文房具	270	260	260

[A] 14％

[B] 25％

[C] 36％

[D] 41％

[E] 50％

2011年の話なので、表の右端列の数字のみを見れば良いことはご理解頂けるだろう。ファーストフードが全体の何％かを問われているので、全体の売上額とファーストフードの売上額がわかれば解答が得られる。

まず、

全体の売上＝ファーストフード＋日配食品＋加工食品＋タバコ＋文房具

　　　　　＝320+140+370+200+260

　　　　　＝1290

よって、

（ファーストフード/全体）×100＝（320/1290）×100＝24.806・・・[%]

したがって、正解は[B] 25％である。

 これが一般的な数学であれば模範解答である。Webテストの画面を見ながら必死で電卓を叩いてこのような計算を瞬時に導き出している人もきっといることだと察する。が、ことのほか、Webテストで上記のような解き方をするのはタブー中のタブーである。

私がこの問題を解くのであれば電卓は使いません（別に使ってもいいです）。頭の中で組み立てる計算式は、

3/（3+1+3+2+2+1+1）= 3/12 = 1/4

です。よって25%が正解であると導けます。

やったことは簡単です。合計値を出すときの100の位以下を全て無視して計算しただけです。すなわち概算、というわけです。上の例では、一応10の位が繰り上がる可能性を考慮して1を余分に足してますが、別に足さなくても結果には影響はありません。（3/11=27.27%）また、10の位を四捨五入してから足す、でも良いです。（ただ少し計算手順は複雑になるのでオススメはしません。）

なぜ概算でも解けるのか。これは概算でも解けるような選択肢になっているからです。もし、例題の解答の選択肢が下記の5択だったら概算で解くとほぼ不正解を引きます。

[A] 24％

[B] 25％

[C] 26％

[D] 27％

[E] 28％

ポイントになっているのはオーダー、スケールです。この問題の場合は、だいたい書く選択肢の差は概ね10％ぐらい開いています。つまり半分の5%ぐらいの差は無視しても良い、ということです。5％の差がどれほどなのか、を論理的に突き詰めようとすると難しいですが、この辺りは感覚です。

感覚がない人にはできないじゃないか。確かにできません。しかし、Webテストの数学、特に表問題は概算で解ける問題が多いことを理解しておくだけで十分です。まず、概算でやってみて答えが怪しかったらちゃんと計算する、とかでいいと思います。というよりも、全て正確な数値を算出しようとすると時間が足りません。問題が後半にさしかかってくると、5連立方程式を立てないと解けない、みたいな複雑度の問題も登場します。

あるいは、ネットに掲載されている数字も全く同じ問題が出ることを祈る、というのも現実的かもしれませんね。

仕事ができない先輩の、一言に非常に共感してしまった話

先日、私の目の前で繰り広げられる会話を小耳に挟んだ。

Aさん：

「この資料だとわかりづらいから修正しといて」

Bさん：

「また、修正するんですか？こういう資料の修正にどれだけ時間かかるかわかってます？だいたいあの人達（課長とか）が理解しようとしてないんじゃないですか！」

Aさん：

「でも、今のままだと課長にはわかりにくいよね？修正はしないと。」

Bさん：

「こんなことばっかりやってるから本当に大切な仕事ができなくてバグが出るんですよ！」

まだしばらくやりとりは続いていたが、内容としてはだいたいこんな感じである。ちなみにここで登場するBさん、というのが仕事ができない先輩である。

軽く補足をしておくと、仕事をする上で、お客さん向けとか上司向けの報告資料をその報告内容に合わせて作っているのだが、それを作ったり、わかりやすく整理することに時間を取られ過ぎて、本業であるシステム開発の仕事が疎かになっていることについてBさんは憤慨しているのだ。その結果バグが出て問題になる、と。

Bさんに問題がないわけではない、要領よく全てをこなしている（ように見える）人はいる。なので、この手の議論になってもBさんの主張はまともに受け入れられないことが多い。組織の中で仕事ができない（と思われている）と何をゆっても説得力が半減以下になってしまうのだ。

ただ、私はBさんの意見に共感した。というのも、私は報告資料には大した価値はなく、そこに膨大な時間をかけるのはバカバカしいと考えているからだ。確かに、ビジネスの現場では伝えることは非常に重要視されているし、実際伝えるべきことを誤ると、仕事が間違った方向に進んでしまうことは日常茶飯事だ。

また、たくさんのことを伝えすぎると、結局何が言いたいのかわかってもらえないことが多い。伝える上では要点に絞る必要もある。よって、相手に何かを伝える場合は、伝えるべき情報が正しいこと、その情報の中から重要度の高い情報を選定すること、さらにそれらが伝わりやすい可視化、そして伝わりやすい構成にすることが求められる。

お客さん向け資料ならここまでやるべきだし、ここまでやる必要はある。でも、上司に対してここまでやる必要あるのか？と私は常々思う。私たちと同じ立場で、私たち以上の収入をもらっているのに、一目で理解出来るような資料を私たちに望むのはいかがなものだろう。

理論的には情報さえ揃っていれば加工の問題であるので、部下が整理してまとめた内容を上司が作り上げることだってできるだろう。ん？上司は忙しいからそんな時間はない？じゃあその忙しい時間で一体どんな価値を創出しているのだろうか。それこそ部下が理解出来るように説明してほしいものだ。

例えば、上司の最も重要な役割の一つに、意思決定がある。ただし、意思決定が本当に決めるだけだと思っている人が多すぎる。

例えばこれから進むべき方向としての選択肢が三つある場合を想定しよう。優秀な人なら、選択肢とそれぞれの具体的なメリットやデメリット、それらの論拠がマトリクスに整理された状況で上司に見せて相談、という形になるのではなかろうか。部下としてはいい仕事のやり方なのかもしれない。

ただし、ここまで整理された上で意思決定をするのは、本当の意思決定ではない。そんなことは私でもできる。ただ承認しているだけだ。せめて、部下が出し切れていない観点をアドバイスする、とか別の方法を提案するなどがないなら、上司が存在する意味はない。

上司に求められているのは経験から来る大局観だと私は思う。大局観とは、将棋などでよく使われる言葉で、全体の状態から自分の形成が良いのか悪いのかを判断できる能力のことを言う。将棋が強い人はたいてい大局観を持っていると言われる。

大局観の特徴は、具体的な個別の論拠に基づいていないことだ。例えば、王の駒がこの位置にいるから今は優勢、とか成金が少ないから今劣勢、みたいな局所的な考え方ではなく、ただ盤面全体とかこれまでの流れから見て優勢、といったようにマクロ的考え方で判断する。

上司の意思決定もこうであるべきじゃないだろうか。なんでもかんでも部下に個別の状況を整理させて、それらの内容を積み上げさせて、その結果を統合して判断という仕方しかできないから意思決定が非常に遅くなる。将棋の世界でこんな意思決定の方法論ばかり使っていたらあっという間に持ち時間が無くなってしまう。

上司の大局観不足は、残業時間とも密接な関係がある。一度上司に何かを理解してもらうための稼働を計算してみる価値はあると思う。恐ろしく時間を取られているはずだ。一人当たりの時間はそこまでではないかもしれないが、階層構造の深い組織体制であれば、各人が抱える時間は膨大になる。

先に述べたように、上司の大局観が欠けているから個別の事象からデータを取り、積み上げ、そぎ落とし、それらの根拠を分析し、伝える必要が出てくる。メモで内容を伝えるだけで現状をわかってくれる上司とか、普段の働き方を観察する中で問題を検出出来る上司であれば、残業時間は圧倒的に少なくなるのだ。

大局観を持つために必要なことの一つは高いセンサーを持っていることだ。例えば、進捗報告資料上は問題無しとなっているが、全員が定常的に残業をしている、とかがわかりやすい例だ。こういった予兆に気づけないようであれば、マネージャーとしての意味はない。部下が問題だと認識していない部分を検知できなければ、部下と同じレベルの判断しかできないし、それでは上司としての存在価値はない。

人工知能とは

人工知能という言葉が最近また脚光を浴びだしているが、「ん？それって人工知能なのか？」と思う瞬間が多々ある。実は、人工知能という言葉の範囲は結構広いのだ。つまり、大したことない人工知能もめちゃくちゃ凄い人工知能も一口に人工知能という言葉で語られている。

例えば、OKGoogleやSiriなど、スマホに搭載されているアプリは人工知能が入っていると思う人もいるだろう。「〇〇への行き方を教えて」と聞けば、電車の乗り換え案内が表示されることは確かに凄いことではある。しかし、あれは単に、音声認識技術や字句解析技術が向上しただけであると私は思う。本質的には、特定の条件に対して特定の処理を実行する、という従来のプログラムの領域を超えていないように感じてしまう。

実際、これらの人工知能としては最も弱いAIだそうだ。物事を認識する力のみが人に近くなっているだけ、といったイメージである。これをAIと言われても正直あんまり腑に落ちない。

当然、ではお前の考える人工知能とは何なんだ？、という話になるだろう。その前に、従来のシステムやロボットにはできなくて人間にしかできないことが何なのか、について私の意見を述べたいと思う。

端的に言えば、演繹化と帰納化ができることである。例えば、私のやっているSEの仕事というのがまさにそれだ。プログラミングは既に自動化されつつあるが、SEの仕事がまだ自動化に至っていない最大の要因はここにある。

SEの仕事の本質は帰納化、すなわちお客さんの「こうしたい」を実現するための方法をプログラミング可能なレベルまで具体的にすることである。プログラマーは既に具体的になった手順書をプログラミング言語に翻訳していくだけの仕事である。（もちろん、実際にはSEの設計が悪く、プログラマーの試行錯誤が必要な場合が多いことも補足しておく。）

ちなみにSEに限らず、優秀な人間ほど、具体的な何かから抽象的な教訓を得たり、抽象的な教訓を具体的な別の事象に落とし込んだりするのが上手い、と個人的には思っている。 

例えば、プロのスポーツ選手に頭がいい人が多かったりするのも、学業で成果を出すための方法論と、スポーツで成果を出すための方法論には何らかの共通点があり、その共通点を意識できているからこそどちらも良い結果につなげることができる。実際、分野は違っても一流の人たちの考え方に共通点があることはよく知られた話である。

と、非常に前置きが長くなってしまったが、今まさに本当に注目されている人工知能というのが、この優秀な人間と同じようなことができるものを指す。すなわち、具体的な事象から抽象的な共通点を導き出し、その他の事例に適応できるのだ。

一つ、全世界に衝撃を与えたニュースとして、「猫を認識するAI」が少し前に開発されたのを覚えているだろうか。素人目にはSiriなど、人間らしく振る舞える方がすごいように見えるかもしれない。しかし、コンピュータが現実世界の概念を理解出来るというのは凄まじいことなのである。

すごい点は、ズバリ特徴量を抽出できる点である。

次の写真を見て欲しい。

この写真に写っているものが何かと問われれば、おそら誰でも”ネコ”と判別できる。ただ、この写真、このネコを見るのはほとんどの人は初めてのはずである。では、なぜ初めて見るものなのに、それが”ネコ”だとわかるかというと、それは私たちが”ネコ”という概念を理解しているからだ。

ネコの概念とは、簡単に言うと、ネコの特徴のことである。髭が３本ずつあって〜、小さめの動物で〜、色は白とかグレーとかベージュとか茶色とかマーブルとかで〜、耳が上についている〜。そんな生き物が”ネコ”なんだということを経験を通じて学んできたのだ。そして、私はネコの概念を学んだわけではなく、個体として存在している様々なネコを見る中で”ネコ”が何かを学んだのである。

そう、人間なら誰でも当たり前にやっていることを今までのコンピュータはできなかった。しかし、これからの人工知能はできるようになる。ちなみに膨大なデータを与えるだけで特徴量（概念）を自分で作り出すことができる技術がディープラーニングと呼ばれている。

これは画像に限った話ではない。例えば、同じGoogleが開発したAlpha Goという囲碁プログラムは強い棋士達の膨大な戦局データから強い囲碁の打ち方の特徴量を抽出しているからなのである。ネコの概念を理解するぐらいなら誰でもできるかもしれないが、良い戦術の概念や特徴を掴むのは人間なら誰でも、というわけにはいかない。

だから、人工知能は少し優秀ぐらいの人間であればあっさり超えてしまう可能性があり恐れられてる。ただ実際のところ、今はマシンの性能が追いついておらず、アルゴリズムであるソフトの技術は実用化されつつあるが、ハードウェアはまだまだ実用化できるレベルにはない。（例えば、ネコを理解するAIはCPU以上の性能を持つGPUを1000台ぐらい繋げて計算しなければ処理しきれないほどの計算量なのだ。）

今はまだ人間の方が低コストで利点があるから一安心だが、今後のためにも人工知能に何ができて何ができないのかぐらいは知っておいても損はないと思う。

人工知能は人間を超えるか ディープラーニングの先にあるもの (角川EPUB選書)

ソリューションって何？

IT業界には横文字が蔓延っている。日本語で言えよ、てなるけど、みんなが当たり前に使っているのを日々聞いていると、いつのまにか自分も普通に使うようになる。でも、こういう言葉ってだいたい雰囲気で使われてるし、雰囲気で使ってしまいがち。

例えば、ITビジネスの中で「ソリューション」という言葉がしばしば使われる。直訳すれば解決策なので、なんとなく問題を解決するための方法、ぐらいのことは誰だってわかるとは思う。

じゃあソリューションビジネスとは何なのか。さっきの延長で考えれば、「解決策をお客さんに提案することで利益を得る仕事」のことだろう。もちろん、それはそれで間違ってはいないと思う。ただこれは、「カラスとは何ですか？」と聞かれて、「生き物です。」と答えているようなものだ。

例えば、ソリューションビジネスというものをもう少し具体的にイメージしてみる。例えば、お客さんが自分たちの商品を全世界に向けて販売したいと思っているけど、そういった物流ルートの確保が難しい、という状況だとする。

この場合の、解決策、ITソリューションの一つはオンラインショッピングサイトの構築ということになる。あー確かにーなるほどーと思うかもしれないが、これは単なるSI、システム開発である。

あるいは、お客さんが会計業務を効率化したいと考えているけど、どうしたらよいかわからない場合、一つのITソリューションは会計ソフトの販売である。でもこれはこれで単なるソフトウェアパッケージの販売とも言える。

以上を踏まえると、ソリューションというのはSIとかソフトウェアパッケージとかそういうものをもろもろ包含するビジネスのことを指しているのだろう。概念の関係としてはソリューション＞SI＞ソフトウェアパッケージだ。

教育などに喩えて考えてみるとわかりやすいかもしれない。

学力を上げたい人のために教科書を販売するのがソフトウェアパッケージ販売。活用の仕方とかは使う人次第、効果を大きくさせるかどうかも本人次第である。ユーザが目的達成のために活用することができるものを販売している。よって、他に必要なものもあり、それらを別で揃える必要があることも多い。

教科書・問題集・ノート・シャーペンなどを組み合わせたり、オリジナルの参考資料とかを作ってセット販売を行うのがSI。ユーザが活用方法を考える必要はほとんどなく、カスタマイズの余地もほとんどない。下手にカスタマイズすると効果が下がる可能性すらある。

そして、教材から効果の高い教育カリキュラムまでを提供するのがソリューション。効果の高い教材の活用方法を教えたりするところにSIやパッケージ販売にはなかった価値があるのだと思う。

ちゃんと知っている人がいたら教えて欲しい。

SIerは残業を減らせるのか

SIerの平均残業時間は月50時間ぐらいだと言われています。これはあくまでも平均の数値であって、会社の規模とか、プロジェクトの工程や状況、開発か維持かといった役割などにかなり左右されるのも事実です。まぁ、私個人としては数年の平均残業時間もだいたい月40〜50時間ぐらいなので間違った数値ではないと思います。

で、この残業時間って多いの？少ないの？って話ですが。同じ業界にいる人、特に上の世代の人から見ると少なめです。過労死のボーダーと言われている月80時間残業の半分ちょっとしかありませんし。

うん。この感覚が多分問題なんですよね。

私ずっと思ってるんですけどね、一度何らかのシステム開発プロジェクトが終わったら、必ず原価にの計画値に対して実績値がどれくらいだったのか、を振り返ることがあるはずなんですよ。システム開発の原価、中でも人件費は工数で算出されます。例えば30人が10ヶ月やってできるなら300人月なので、そこに単価を掛けた値が人件費でとなります。

一般的には１人月は20人日で、１人日は7.5人時として計算されているはずです。よって、もし残業時間が発生している場合、その残業した時間分だけ原価が増しているはずなんです。仮にメンバ全員が月50時間残業していたならば、30人×500時間＝1500人時なので、1500÷7.5÷20＝10人月分だけ原価が増えていることになります。よって見積が誤っていたと判断できるはずです。

であれば、次回開発時の見積の数値はこの反省点を踏まえた見積金額となっていなければおかしいですよね。単純に考えたとしても、50kステップのシステムが300人月でできると思っていたところが310人月かかったのであれば、次100kステップのシステムが600人月では終わらない、620人月はかかると考えるべきです。

つまり、何が言いたいのかというと、SIerは開発の経験値が蓄積されればされるほど、残業時間はなくなっていくはずだ、ということです。でもそうはならず、残業が状態かしている職場がほとんどではないでしょうか。これはいったいなぜなんでしょう。

考えられる要因は三つです。反省していない、楽観視、見積金額高騰の回避、です。

そもそも、見積金額の妥当性を振り返っていない、という組織は十分にあると思います。実を言うと、私の組織もやっていないんじゃないかと思います。というのも各工程の生産性とかは未だに数年前の数値を使ってたりしますし、誰かが開発完了時に生産性を計算しているのかもしれませんが、現場レベルの人間は全く意識していません。

また、プロジェクトとして黒字になればOKとか原価率このぐらいであればOKみたいな基準さえクリアされると、一切問題分析がされない可能性もあります。システム開発の場合は、原価の中にリスク費と呼ばれる、想定外の問題が起きた場合に対処するためのコストが積まれるものですが、残業によるコストもこのリスク費で吸収できれば問題がなかったと見なされてしまいかねません。成功したにしろ失敗したにしろ過去はちゃんと振り返るべきですね。

次が楽観視です。プロジェクトは一つとして同じものはありません。プログラムの規模だけで工数が決まるわけではなく、そのプロジェクトの特性とか、環境・要員のスキルなど、様々な特性を考慮して決める必要があります。過去の類似プロジェクトを参考にはできますが、その値をそのまま使えるということはほとんどないのです。

すると、ありがちなのが、過去のプロジェクトの生産性を基に考えした上で、「今回は有識者が多いからこのぐらい生産性が上がるだろう」とか「今回は開発の難易度が過去よりも低いからこのぐらいの期間でいけるだろう」みたいな意見がでます。そして、この場合に語られる「このぐらい」という数値には何の根拠もありません。

単なる楽観視です。この楽観視が原因で、簡単だと思われたプロジェクトも常にみんな忙しそうにしている光景はよく見受けられます。PMなどのポジションの方は安易に数値を変更してチームメンバを苦しめない様にしましょう。

最後の理由は、上記の２つを引き起こす原因ともなっている、見積高騰の回避です。

知っている人もいると思いますけど、システム開発費って、めちゃくちゃ高いんです。下っ端1人1ヶ月雇うだけで100万近くします。例えば、私が先日作ったAndroidのアプリですけど、あれをSIerに発注して作ってもらうと、たぶん500万ぐらいはかかると思います。本気です。

なぜそんなに高くなってしまうのかは、オーダーメイドとか多重下請構造とかいろいろ理由はあります。が、とにかく素人の方が直感でイメージするよりはるかに高い、ということです。

ただでさえ高いのに、10人月増えるということはさらに1000万円高くなる、ということです。無理です。そんな額をお客さんに提示したら受注できません。営業に怒られます。見積もり精査という名の、リスク許容、残業容認の末、受注を勝ち取っているのです。

つまり、今のSIerの働き方では残業減らせないよね。

あなたがやっているのは「設計」ではなく「仕様決定」です

今日は中々ノッてるので、３本目のエントリ突入。

テーマはシステム開発における仕様と設計の違いについて。私が業務系エンジニアから基盤系エンジニアに泣く泣くシフトチェンジした一つの大きな理由も、この仕様と設計の違いに関連しています。

仕様と設計の違い。それは端的に言えば「どうなるか」を定めたものが仕様、「どうするか」を定めたものが設計です。単純にログイン機能を例にとって説明しましょう。下記が仕様です。

ログイン画面にてユーザ名とパスワードを入力して、ログオンボタンを押下した場合、

• ユーザ名とパスワードの組み合わせが正しければトップページ画面へ遷移
• ユーザ名とパスワードの組み合わせが誤っていればエラー画面へ遷移

仕様から読み取れるのはあるべき動作であり、特定の条件下における処理の結果です。そして、これらはSEがお客さんと一緒に考え、合意した上で決めるものです。では、この仕様からプログラムを作ることはできるでしょうか。

もちろん、できる人もいるでしょう。しかし、これだけの情報からプログラムを作れる人は設計ができる人です。仕様をプログラムへ落とし込むためには、データ（およびその格納先）とロジック（条件分岐や順序）、そしてそれらの連携方法を考える必要があります。

上記のログオン画面を設計するには下記のようなことを考える必要があります。

• ユーザ名とアカウント名を保存するためのデータベース・マスタ情報の定義
• 各データの型（数字なのか英文字なのか真偽値なのか）
• ログオン画面レイアウトの設計
• ユーザ名・アカウント名を入力するための入力フォームの配置
• ログオンボタンの配置
• 入力フォームで受け取った情報からデータベースの値を取得するSQL文
• SQL文で取得した情報と入力情報をチェックする処理
• チェック結果に応じて遷移先の画面を切り替えるロジック
• トップページおよびエラー画面のレイアウト

などなど。今は順序性も考えず箇条書きで、かつパッと思いついたものしか書いていませんが、それでも仕様と設計では考えるべき項目の数が全然違うことがお分かりいただけるでしょう。さらに仕様を満たす最適な設計を考えるのはさらにハードルが上がります。それが面白いところでもあるんですけど。

私は業務系のエンジニアはこういうことを考える仕事だと思っていたんですよ。いや、実際こういうことをやっているエンジニアの方もたくさんいらっしゃると思うんです。でもITゼネコンの上の方に位置する会社がやるのは大抵仕様を決めるところまでなんですよね。

要するに設計してないんです。お客さんと調整して、仕様という名のゴールを決めるのがメイン。そのくせ、「あれはおれが設計した」みたいなこと言ってる人もいます。いやいや、あんたは仕様決めただけでしょ〜って。

ただそうならざるを得ない理由もあって。一つはお客さんと調整するのは結構ハードな仕事だということです。仕様を合意するためにはその仕様が最も良いという合理的な理由が必要です。そのために、あらゆる調査をして、あらゆる資料を作って説明をしに行かなければならない。規模にもよりますが、多くても数ヶ月ぐらいの期間内に収める必要があります。

もう一つの理由は、既に既存システムが運用されている場合です。要するに機能追加開発のことですが、0からのシステム開発でない場合、既存の機能の流用で済ませられる場合が多いです。

0からシステムを作るのは結構リスクがあります。一般的には、過去の類似プロジェクトの機能や処理を参考にプログラム規模や工数は見積もられますが、新規システムの場合は作ったことがないので、工数見積の精度がどうしても落ちてしまいます。なので、精度誤差分を踏まえてバッファを積むことになります。

加えて、前例のないことをやると、必ず想定外の問題にぶち当たりますから、問題が起こった場合のことを考えて、バッファを積むことになります。さらに問題の影響度も見切りにくいため、機能追加開発に比べてその割合は多くなるでしょう。

すると、どうなるかというと、お客さんへ提示する価格がめちゃくちゃ高額になってしまうわけです。すると、案件が受注できない。営業から怒られる。じゃあどうやって安くするかというと、最も代表的な手法として、既存システムをうまく流用することを考えるのです。

既存のものを活用した方が効率的に良いものを生み出せるので、これは会社としては全く悪いことではありません。ただ問題なのは、こういったやり方では、SEが本当の設計をする機会はない、ということです。

例えば、家を新築で建てるのも同じですよね。似たような家が既にあれば、その設計図を流用した方が早く作れる。でもそれはつまり、家全体の設計というフェーズをすっ飛ばしているということです。

うちの会社では近年開発力の低下が叫ばれていますが、ほとんどの社員が設計という設計をしていないのだから無理もありません。さっき言ったように、仕様を決めることを設計だと勘違いしている人さえいる次第です。

実際、今振り返ってみても、自分がやってきたことのほとんどはただの決め事でしかなく、既に出来上がった既存システムの枠組みに新しいデータを追加しただけ、という感じが拭い去れません。いと悲しや。

もちろん、SEとして働いていれば、今動いているシステムの設計を勉強することはできます。でも設計図の内容を把握したいからではなく、設計をしたいからSEになっているはずですよね。設計を理解していくことと、実際に設計することに圧倒的な違いがあることはアプリ開発を通じて実感しました。なので、次やるなら是非とも新規開発がいいですね。

正直、今の担当で業務系エンジニアをやっていても何の専門性も身につかないだろうなと思いました。（先輩や同期に聞いても、業務知識は身についたけど、設計スキルは身についていないと感じている人がほとんど。）確かに業務知識はつきましたが、金融みたいに大きな業界ならともかく、ニッチな業界相手だと汎用性が低すぎてエンジニアとしての価値はあんまり発揮できないでしょう。

私は、それが嫌で嫌で仕方なく、基盤系エンジニアになったというわけです。もうしばらくしたら、基盤系エンジニアが何たるかも書き連ねたいと思います。

クーラーシェアリング

私は「時を指定されたタスク」が嫌いである。時を指定されたタスクとは、「15時〜16時の間にこの書類を完成させてください」みたいな仕事のことだ。簡単にいえば、予定を入れたり、予約というのが嫌いなのだ。

ちなみにタスクとは言ったが、これは公私を問わない。極端な話、「8/1にバーベキューをやります」、みたいなのも嫌いだ。特に、前もって先の予定を決めるのが嫌いなのである。なぜなら、直前になって行きたくなくなることが往々にしてあるからだ。

その中でも、待機を強要される仕事が最も嫌いである。例えば、郵便物の受け取りなどは、受け取り自体には1分とかからないにも関わらず、午前中に届けますとか、13時〜15時の間に届けます、みたいなことを平気で言っている。そこに合わせて家で待機するというのは、自分の行動が非常に制限されている気がしてならない。

少し別の事例として、公共機関での移動も同じ話だ。移動時間中は行動に制限を受ける。もちろん、読書とか音楽聞いたりできるからいいじゃん、みたいに考える人もいると思う。さっきの郵便物の話でも家でできることやってればいいじゃん、という意見もあるだろう。

でも、つまりはそれが行動が制限されているということなのだ。例えば、郵便物を待っている最中に小腹がすいた、と思ってもコンビニには行けない、ということになる。電車の中で用を足したいと思ってもトイレには行けない、ということだ。やりたいことはできるが、その時一番やりたいことはできない、ということである。

そういう意味で、宅配ボックスというのはネットショッピングの亡者である私にとっては実に素晴らしいサービスである。宅配ボックスがついている家に住んでからこの手の煩わしさからはほとんど完全に解放された。

ただし、全ての荷物が無人で受け取れるわけではない、というのが今の宅配ボックスの残念なところでもある。

最も社会的にも課題だと感じているのが、ネットスーパーでの買い物である。実はネットスーパーでの購入品は、宅配ボックスに届けることができないのである。おそらく、食材とか生物を常温の空間に置き去りにすることは衛生面から許可されていないのだろう。ただ、私はこの宅配ボックスに届けられない、という理由でネットスーパーは最後まで利用しなかった。

もともと、ネットスーパーは普段は忙しくて買い物に行けない人、すなわち主婦以外の層がネットを通じて買い物をしてくるような企みで開始されたサービスだった。しかし、結果は真逆で、既に買い物に行っていた主婦たちがそのままネットを利用するようになった、という話を聞いたことがある。

そもそも主婦は基本的に家にいるので、この家での受け取りに煩わしさを感じる人は少ないのかもしれない。ただ、ネットスーパーが本当に忙しくて買い物に行けない人向けにサービスを展開したいのであれば、無人受け取りの仕組みも必要だと思う。

こう考えると、一つの選択肢として、宅配冷蔵庫というサービスはあってもいいと思う。マンションや団地に導入してもらう。ネットスーパーと提携して、生物はそれぞれの冷蔵ボックスに入れてもらう。今風に「クーラーシェアリング」とでも名付けてみて。住民から月額数百円とかでできれば最高だ。

ネットで調べた感じだとまだ誰もやってなさそうだけど、こういうアイデアもちょっとアリなんじゃなかろうか。

日本で画期的なサービスが生まれないワケ

Amazonがまた新しいサービスをリリースするようです。ネットの覇者だったアマゾンですが、今回はリアル店舗でのサービス。動画を見ればどういうサービスなのかはだいたい見当がつくでしょう。

youtube

UX（ユーザエクスペリエンス）という言葉の象徴とも言えるサービスですね。今まで買い物といえば、買い物かごに自分が欲しいものを入れて、レジに並んで精算する、というスタイルが主流でした。

もちろん、これまでも、様々なシステムが導入されレジ業務は改善されていました。例えば、POSシステムというのも今ではほとんどのレジで採用されていますし、セルフレジなる買う人が自分で精算する仕組みもありますし、精算機をレジと分類することによって作業効率を高めるといった仕組みもあります。

ですが、基本的に買い物の中で「レジ業務」というものは効率的にはなったものの、店員もしくは購入者、すなわち人間がやらなければならない業務として残っていたのも事実です。しかし、Amazon goは買い物の中からレジ業務を完全に排除しました。

背景として、IT技術の進歩があったのは言うまでもありません。センサーの高精度化、画像認識技術の向上によって、誰が何を買い物かごに入れたのかを正確に検知することができれば、システムがリアルタイムでレジ打ちすることが可能です。なので、ゲートを潜り抜けさえすれば勝手に決済が済んでしまう。非常に画期的だと思います。

ここで疑問になるのはどうして日本人はこんな発想ができないのだろう、ということです。日本人のクリエイティビティが足りないからでしょうか。

個人的には、日本人の中にもこのような発想をしている人はきっといたのだと思います。ただ、日本人の場合、画期的なサービスを思いついたとしても、そのサービスを導入した場合の弊害とか導入した結果付随する問題にすぐに着目しがちです。

あなたは、このAmazon goというサービスを見て、何を思ったでしょう。すげえサービスだ、と思った反面、でもこれで上手く機能するのか？とも思ったんじゃないでしょうか。

例として、私が思いついた問題点をいくつか挙げてみます。

• 事業性があるのか（この技術の導入コストより削減可能な要員コストの方が大きいのか）
• 本当に正しく認識されるのか（カメラの死角だと認識されないあるいは誤認識されるのではないか）
• 残高を超える額の買い物をした人がゲートから出た時に請求はどうなるのか
• いくら使ったかわかるのか
• そもそもお客さんはやってくるのか（ネットで済ませるんじゃ？）

上はほんの一部です。こんな風に新しい仕組みを導入すると必ず問題点が上がります。で、日本の会社だと特に、この想定される問題についてどう対処する予定なのかを事前に深く検討させられます。そして、その障害をクリアできないと、まず可決されません。

日本人はリスクをとにかく避けようとする人種です。なので、事前に懸念が思い浮かぶのであれば、それに対し万全の対策を打った上でしか新しいことを始められません。しかし、アメリカはリスクに対し寛容です。とりあえずやってみて、もし問題が起こったらその時に考える、というスタンスです。（このあたらいはUAI指標という形に表れています。）

今回のAmazon goも、まずシアトルで検証も兼ねてやってみる、というスタンスなのだと思います。ただ、こういう取り組みはマーケティング的にも非常に重要だし、本当の問題が何かを知るためにも良いと思います。日本企業も海外で生まれたサービス自体だけでなく、こういう姿勢を是非マネしてほしいですね。

一億総クリエイター時代の幕開け

ここ数年でヒットしているITサービスは、生産活動を促進する仕組みが非常に多くなってきている、と私は考えています。一億総クリエイター時代に本格的に突入しつつある、というのが正直な感想です。

ここで言っている生産活動とは、「何かをアウトプットする」ことです。それは知識なり、作品なり、サービスのことです。例えば、今私が書いているブログも生産活動だし、Youtubeに動画をアップロードするのも生産活動です。音楽を演奏するのも生産活動です。しかし、読書とか映画鑑賞とかは生産活動ではなく、消費です。食事も消費です。おわかりいただけるでしょうか。

そもそも兆候としては、カメラ付きケータイの大ブレイク時代からあったのでしょう。確かに当時カメラ付き携帯が流行ったのは、思い出を手軽に残せるのが良かったからだったのかもしれません。しかし、今はどうでしょうね。

例えば、風景だけの写真を撮る人がいます。そんな写真ならネットに同じものがあるやないか、と言いたいところですが、これも本当の価値は、「自分がその場で撮影したこと」にあると思うんですよ。で、自分の手で撮影した風景だからそれは生産活動なんです。

今インスタグラムとかにアップロードされる写真も結構拘ってる人が多いですよね。あれも自分ならではの撮影、ようするに作品としてネットにアップロードしているわけなんです。もちろん、そういう活動が盛んになったのはインスタグラムの影響でしょうが、既に人々の潜在的なニーズとして「何かを生み出したい」というものがあったのでしょう。

ブログやYoutubeが流行ったのも全く同じ理由です。アップされる動画が面白い、というのは結果的に生まれた価値であり、動画を作ってアップすること自体に喜びを感じる人がいたから急成長したプラットフォームです。

そして、最近のITトレンドの一つであるシェアリングエコノミーというのは、本質的には、今まで無駄になっていた価値を、その価値を必要とする人とリアルタイムでマッチングするサービスです。が、これは個人の行動領域が、趣味のしての生産活動からビジネスとしての生産活動に変化している兆しでもあります。

ブログやYoutubeも元々は収益を期待して投稿する人はさほど多くなかったと思いますが、ブロガーやYouTuberなどとして、個人として稼ぐためのプラットフォームへすっかりと変貌しています。

ある意味、今なお人気のあるソーシャルゲームのアプリなども、自分だけの最強のキャラを作っている、みたいな意味では生産活動に近いのかもしれません。個人的には、ゲームを生産活動に分類する気はありませんが、一時期レアなカードを現金で取引されることが問題となったように、ゲームの中に閉じれば価値あるものと言えます。

こんなふうに、今、消費者は単なる消費者ではなくなろうとしています。さらに、「趣味で生産する」から「生産してビジネスにする」人が増えています。その理由は、世の中がすごく便利になったから、そして場としてのサービスが整ったからです。

例えば、ショッピングといえば昔は娯楽の一つだったと思います。私も高校生ぐらいまでは服を買いに出かけたりするのが好きでした。でも、今はほとんどショッピングに行くことはありません。ほぼ全てネットショッピングで済ませます。

なぜならば、ネットの方が在庫も多いし、種類も多い。しかもレコメンドまでしてくれる。決済も簡単だし、店員との無駄なやり取りが必要ない。さらに、決定的なのが、いつでもどこでも変える。ネットショッピングの方が明らかに合理的なんです。

ゲームも同じです。昔は家に帰ってから数時間だけしかできない環境でした。また友達を家に呼んだりしなければ、複数人で遊ぶことはできなかったはずです。でも、今はいつでも、どこでも、誰とでもできます。しかもほとんどのスマホアプリであれば無料で色んなゲームを遊ぶことができます。

でもこれ、俗に言う不便益が損なわれた状態です。いつでも、どこでも、だれとでもできるようになったことで、それ自体の価値が薄まってきているんですね。たぶん、電話とかも同じです。今の私たちにとっては電話とはただの連絡手段でしかありませんが、私たちより一世代前の人たちは、「電話」という行為自体が娯楽のようなものに感じていたんじゃないかと思います。

つまり、これまでの消費活動が徐々につまらないものになってきた最中、現れたのが生産活動を公表できる場としてのサービスの登場、そして、自分のリソースをて提供することで収益を得られる場としてのサービスの登場です。消費への飽きと生産ハードルの低下が個人の生産活動を促進しているんです。

と、ここまでは、消費者についての話でしたが、実は労働の現場でも同じようなことが起こっています。労働は基本的に何かを生産する活動ですが、生産するもの自体が事務的なものからアーティスティックなものへと変わってきています。

例えば、単純な事務処理とかは既に業務システムに置き換えられていますが、さらに今後は人工知能の発達により、コールセンターの受付業務など、やや高度ではあるが単純、といった作業もどんどん無くなっていきます。よって、人間の仕事はより創造的でクリエイティブなものにならざるを得ないのです。

まとめると、消費者の消費活動はより創造的になり、労働者の生産活動もより創造的になっていくということで、これすなわち一億総クリエイター時代ということです。もし、何の創造活動もしていないとしたらこの先の時代に置いていかれますよ。

こんな上司や先輩には気をつけろ

あなたは一緒に仕事をする自分の先輩や上司に何を望むだろうか。 的確に指示を出して欲しいとか、ある程度自分に任せて欲しいとか、人によりけりだとは思う。

ただ、残念なことに部下の期待が様々であるように、上司の特性も当然様々である。そして、組織に入る以上は上司や先輩のタイプを自ら選ぶことはできない。そもそも自分にはどういう先輩や上司が向いているのかさえよくわからない、といった人もいるのではないだろうか。

個人的には、何のための仕事で、どんな成果物を作る必要があるのか、そしてインプットとなる情報は何かさえ教えてもらえれば、後はあんまり干渉されたくないと思っている。要するに「裁量」があった方が良いということだ。

ただ、自分の上司は裁量を与えるタイプなのか与えないタイプなのか、という一つの軸だけで考えていると、仕事を進める上で面倒になることも多い。そこで、私は「裁量を与える」という状態を少し掘り下げて「指示」と「決定権」の二つの観点から下記のような上司の分類を考えてみた。

上司タイプ

	指示が曖昧	指示が的確
決定権を委ねる	Aタイプ	Bタイプ
決定権を握る	Cタイプ	Dタイプ

上の表において、左上（Aタイプ）がもっとも裁量があり、右下（Dタイプ）へ行くほど裁量が小さい。なので、「裁量」という一つの軸で考えてしまうと、ほとんどの人はAかDの二択で分類してしまっているのでは？というのが私の仮説である。追ってそれぞれのタイプを説明しよう。

▪️最も自由なAタイプ

まず、わかりやすいAタイプとDタイプから。Aタイプの上司を持つと、最も自由に仕事ができる。反面、あまり能力がない人がこの上司にぶつかると、「何をやればいいかわからない状態」になる。ただ、始めからAタイプの上司や先輩のもとで働くことはない、と断言しても良い。もしそんな先輩がいるとしたら監督能力ゼロの無能社員である。

Aタイプの振る舞いは基本的に部下の能力を評価、信頼していなければできない。部下にとって、先輩や上司をAタイプへ変貌させることが一つのゴールだと私は思う。

課長とか部長クラスの立場の離れた上司はだいたいこうで、細かい指示も出さなければ、成果物も細かくチェックしない。なぜなら、あなたと課長の間にいる先輩が何とかすると考えているからだ。逆にいうと、あなたの仕事の価値を高める上ではあまり助けにはならない、ということでもある。

▪️家庭教師Dタイプ

Dタイプの上司は最も不自由である。仕事のやり方も決めつけられ、わからないことがあったら、すぐ報告・相談を求められる。試行錯誤の余地も小さく、ただただ自分が作業員でしかないと痛感させられるだろう。

ただ、このタイプの先輩や上司も基本的には存在しない。せいぜい会社に入って数ヶ月の新入社員期間限定で現れたりするぐらいだ。誰にもメリットがないので、もしこんな先輩に付きまとわれているなら、さっさと仕事を覚えて信頼を勝ち取ろう。

▪️実は最も理想的なBタイプ

Bタイプの先輩を持つと仕事がやりやすい、と個人的には思っている。要点については的確な指示を出し、あとは任せてもらえる。先輩としては、重要な点は伝えてあるので、その部分の要件さえクリアしていれば、多少プロセスや成果物に問題があっても大きな仕事の後戻りにはならない。

仕事を受け取る側としても、何をやらなければならないかの全体像は把握しやすいので、何から始めて良いかわからない、といった状態にはならない。その上、細かい部分については自分で考えたり、調査したりと工夫を凝らす余地がある。

これがあるかないかで、本人がやっているものが「作業」なのか「仕事」なのかのモチベーションにもつながると思う。Aタイプに比べると自由度は劣るが、正解らしきものが欲しい人にとっては最も理想となる上司だと思う。ただ、こういう上司や先輩も絶対数としてはそれほど多くない。

▪️要注意のCタイプ

Cタイプが最も危険である。このタイプの上司を持った部下は苦労する。指示は曖昧だが、決定権は持ちたがるタイプである。指示の抽象度だけではかれば裁量を与えてくれているように勘違いしてしまうが、決定権を委ねているわけではないので、実際には裁量は小さい。

例えば、Cタイプの先輩を持つとこんな問題が発生する。

Cタイプの先輩：「ここのプログラムの再試験やっといて。前にやった試験項目があるから参考に。」

私：「了解です。」

試験完了から数日後…

Cタイプの先輩：「この間の試験項目間違ってない？」

私：「参考にした過去の試験項目と同じです。」

Cタイプの先輩：「じゃあその部分直してもう一回やり直そうか。」

私：「はい…。」

Cタイプの先輩：「あと、ここの手順もこういうやり方の方が良いと思うから修正しといて。」

私：「…」

こんな風に裁量があるつもりで行動する、と手戻りが発生する。だからこそ、事前に細部まで確認合意しておくことが求められる。スコープは？品質のレベルは？参考資料の妥当性の確認方法は？いつまでに？などなど。あとは作業途中で段階的にチェックしてもらう、というのも一つである。これも手戻りを防ぐ方法ではある。が、こういった仕事のやり方は非常に窮屈に感じるので、対策を打つか打たないかは自由意志に任せるとする。

ーーーーー

もう一度、上司タイプを見返して欲しい。実は上司のタイプはあなたの行動によって変えられるものと変えられないものがある。指示の的確さはあなたが成長すれば曖昧になっていく。逆にあなたの理解度が浅いと感じたら、かなり的確に指示を出してくる。

しかしながら、先輩や上司が持つ決定権についてはあなたの行動で変えることは難しい。というのも、先輩や上司の役職・権限などに依存する部分が大きいからだ。また、生まれもった性格によって、自分で決めたい、人に決めてもらいたい、などの価値観にも依存する。

よって、必然的にあなたが成長すると、あなたの上司はAタイプかCタイプということになるだろう。だからこそ、Cタイプへの対処法は早めに理解しておくことをお勧めする。

「作る」と「売る」の壁

自作のアプリを開発して、1ヶ月が経った。気になるダウンロード数であるが、漸く二桁に突入、といったところである。アクティブユーザはその半分ぐらいしかいない。わかってはいたが、「売る」というのは相当に難しい行為である。

とりあえず宣伝。

インストールはこちらから↓↓↓

まず、第一の壁は「認知」である。既にAndroidには100万以上のアプリが存在するが、この中に一つのアプリが追加されたからと言って、誰が気づくのだろうか。検索でヒットするところまでが遠い。

特に、個人や無名の会社ではプロモーションの手段がない。例えば、各種メディアで取り上げられれば認知度は上がるが、お金もかかる。一応アプリを公開して少し経つと、アプリ紹介会社のページに掲載されたりはするんだけど、ほぼ全ての新着アプリを紹介しているから他との差別化にはならない。

直接Gmailを送ってくる海外の会社とかもあって、たぶん有料プランに入れば優遇して紹介しますよ的なことを英語で提案してきたりはするので、結局良いプロモーションをするにはお金が必要ってことらしい。

本ブログがもう少しメディアとして機能するものであれば良かったが、到底そんなレベルではない。なので、タダでできる事というと、ASOぐらいの方法論に落ち着く。アプリストアには検索エンジンでのSEOならぬ、ASOという考え方がある。なるべく、アプリを上位に表示させるためのテクニックだと思ってもらえればいい。最も簡単な例としては、検索されやすいワードを説明やタイトルの中に含める、といったものだ。

しかし、もちろんこれも単純ではない。検索されやすいワード、というのは多くのアプリに含まれており、レッドオーシャン状態なのだ。結局ASOの効果を生みにくい。だから、私は「WBS」というキーワードで押している。そもそものコンセプトがWBSであったし、プロジェクト型の仕事をしている人ならば、そのワードで検索する可能性は十分にあると考えたからだ。

実際、「ToDo」や「タスク管理」などで検索しても、私のアプリは検索結果に表示すらされないが、「WBS」で検索すれば、上から数えて6番目ぐらいには表示される。実際インストールした人が存在しているのは、このブルーオーシャン戦略の功績ではないだろうか。ただ、どのくらいの数の人が検索しているのかがわからないので確かなことは言えない。

次は、認知の先、「インストール」の壁である。今時点で、少なくとも、私のアプリのページにたどり着いた人は70人程度存在する。（これはGoogle Play Developer Consoleという、アプリを公開するために使う管理ページから確認できる。）ただ、インストールまで至っているのは、たった10人ちょっとなのだ。しかも全世界で。

これには様々な仮説が立てられる。

1. イメージしていたものと違った。ワールドビジネスサテライト（WBS）のアプリを求めていた、とか。
2. 画像のサンプルが日本語だった。海外の人が見つけたが、日本語だったので断念した、など。
3. 「〇〇万ダウンロード」みたいな表示がなく、使う気を削がれた。
4. 機能が不十分だと感じた。
5. 使い方がわからなかった。

　　　：

　　　：

キリがない。ただ、個人的には無料なんだからとりあえずインストールしてみては？と思ってしまうのだけど、このあたりは庶民の感覚とずれているのだろうか。信頼できないアプリを入れてスマホがバグるのを恐れているとか、そもそもよくわからないものはインストールしたくない、みたいな考え方があるのかもしれない。UAI指数の高い日本人にはありそうな話ではある。このあたりは分析のためのデータが少なくて検討が難しい。

インストールしてもらった後も、まだまだ壁はある。次の壁は、「継続利用」の壁だ。たとえインストールされても、使ってもらえなければ意味はない。最悪の場合、アンインストールされる。冒頭で述べた「アクティブユーザが半分しかいない」というのは半分ぐらいが既にアンインストールしてしまったという意味である。

ただ、この原因については大方予想はついている。実は開発したアプリがインストールやアンインストールされると、そのアカウントの国籍や、Androidバージョンなどの情報が開発者にはわかるようになっている。その結果によると、面白いことにアンインストールしたのは全て海外の人であった。

私のアプリは日本人以外が閲覧すると、タイトルや説明文は全て英語で表記されるようになっている。グローバリゼーションへの対応はASOの基本でもある。しかし、肝心のアプリ本体は全て日本語での表記となっている。

なるべく、言語要素を無くした設計にしたが、それでも知らない言語が出てくると、使いたくなくなってしまうのだろう。よく、中国のアプリとかで、説明はギリ日本語なのでとりあえずインストールしてみたが、中身は全て中国語だと気づいた瞬間に私がアンインストールするのときっと同じだ。ただ、このあたりは対策の余地が残っている気がする。

ここまででもかなりやる気が失せてしまうが、最後の「課金」の壁が残っている。ちなみに私のアプリは現時点では課金の仕組みそのものがない。「売る」ことを全く視野に入れていないのだ。だから、なぜ課金してもらえないかを考えるための材料すらないし、「売る」ために必要な基盤さえ揃っていない。ただ、壁としては存在している、その点についてだけここでは言及しておく。

ーーーーー

営業をやっている方には失礼なのだろうけど、会社、特に大きい会社において、営業というのはそれほど難しくはないと私は思っている。もちろん、会社が大きくなるまでにはとてつもなく大変だった過程はあっただろう。しかし、既に大きくなった会社の営業は、本当に0からモノやサービスを売るまでに必要となるはずの障壁のほとんどは既にクリアされている前提から戦うことができる。

自分たちを認知してくれるユーザが存在し、商品を宣伝するための広告チャネルも存在している。開発部門が優秀なら尚よしだ。ただ、それですら営業という仕事の方が、開発よりも難しいと個人的には思う。

モノを作るのは、数学によく似ている。全ての数学の問題はあらゆる定義の組み合わせで解ける。モノやシステムを作ることが問題だとすれば、あとはどういう技術（定義）を組み合わせて実現するか、それだけの話である。もちろん、方法論はたった一つではない。ただし、それぞれのやり方は類似しているし、合理的に考えれば、自ずと良い選択肢は定まってくる。

ただ、モノを売るという問題の方法論は全く異なる。例えば、収益を上げる上で、市場規模の大きいマーケットを狙うべき、という考え方に対し、ニッチな市場向けのビジネスを展開するべき、という相反する解がありうる。さらに、それらの選択肢は合理性だけでは選択できない。

改善の方法も無限だ。今回のアプリ開発で、壁がたくさんああって、それらの原因も多種多用であることはわかった。しかも、それらへの対策がどう影響を及ぼすのか、ということは数字などのデータでしか見ることができない。ひたすら仮説と検証の繰り返しである。具体的な答えは得られないし、そもそも具体的な答えなどないのだ。だから私は売ることに対し積極的になれないのだと思う。

強いて良い点を上げるなら、答えがないからこそ自分のやりたいようにできる、ということぐらいだろうか。

トイレビジネス

私は胃腸があんまり強くありません。なので、朝会社に出社したちょっと経ったら、だいたいお腹が痛くなります。それがほぼ毎日です。

当然、トイレに駆け込むわけです。でも、トイレの入り口に近づくと見えてしまうんですね。既に並んでいる人の影が。並んでいる人の数が2を超えていたら、上下のフロアのトイレへ行きます。でも、今までの統計的に朝の時間帯はどの階も一人か二人は並んでいることが多いです。

で、このトイレに並んでいる時間ってめちゃくちゃ無駄なんですね。私にとっても無駄ですけど、会社にとっても本当に無駄。例えば、社員の給料が時給換算で2000円ぐらいだとすると、この並んでいる10分ぐらいの時間は300円をゴミ箱に捨ててるようなもんなんです。トイレ待ちながら仕事はできませんから。

いや、べつに一人くらいなら気にする必要もない些細な損失です。でもこれが各フロアで起こっていて、かつ一時間に数回の頻度で起こっていて、それが毎日起こっているとしたら。。。大きい会社なら年間数百万ぐらいの労働力は損しているでしょうね。

ただ、そんなに沢山人が待っているような印象は受けないと思います。これはさっきの私と同じような行動をする人が沢山いるからです。要するに、2人以上並んでいたら空いている他のフロアを探す、あるいは少し時間を置いてからまた行くといった具合に。フロアが狭ければ構わないでしょうが、この単純往復作業も何回もやると積み重なっていきますし、疲れます。

この問題について私は対策案を二つ考えてます。

１つはトイレ課金制度の導入です。例えば、今日本において、ほとんどのトイレは無料で使うことができますが、そのせいで、トイレを使いたい時に使えない人がたくさんいます。というのも、無料だと、一人の人間が長時間利用することができてしまうからです。

トイレに入ってから5分までは無料、それを超えたら100円払わないとトイレから出られない、という仕組みを入れてほしいと思います。個人的には3分でもいいくらいです。トイレが長い人やトイレで休憩する人が少しでも減れば、みんなハッピーになります。

トイレのロックにセンサーをつければ、一人の人間がいつからいつまで使ったかがわかりますし、お金を払わないとロックが解除されない仕組みがあれば、お金を払わざるを得ない、というわけです。

ただ、現実的には財布を忘れてしまった人は出られなくなってしまうので、指紋で電子通貨の支払いができる社会が実現していることが理想ですかね。とはいえ、今の技術でも工夫すれば可能なのではないでしょうか。

もう一つの案は、トイレのIoT化、トイレの稼働率を監視する仕組みの導入です。自席やスマホからトイレの稼働状況を見ることができれば、今トイレに駆け込むべきなのか、少し待った方が良いのか判断できます。こうすることで、無駄な待ち時間が排除できる寸法です。

ただ、これはあまり良い解決策にはなっていないんですね。なぜなら、トイレの稼働状況を全員がウォッチできるようになると、「あ、今ここのトイレ空いてる！」と気付いた人が一斉に駆け込んで、トイレについた時にはすでに行列が出来上がっていた、みたいな事態が発生してしまうからです。このリアルタイム性の壁を超えない限り、あまり現実的な解とはならないでしょう。

少し調べてみると、チームラボとかがこういうアプリを作ってるみたいですが、どのくらい役に立っているんでしょうね。

おばかアプリ勉強会資料 チームラボ from atmarkit

www.slideshare.net

そういう急激なトイレへの人員駆け込みを避けるとなると、結局今の技術では、5分間隔でトイレを予約する、みたいなとこが落としどころになってしまうのか。うーん、予約してまでトイレに行くというのはどうも堅苦しいし面倒くさい気もします。

なんか、いいアイデアはないもんでしょうか。

インプットとアウトプットのスタンス

私が受験で成功した主たる要因は自分のアウトプットを最適化する学習方法を実施していたことにある。テストというのは本来、当人の理解度を推し量るためのものであるが、その実そういう風にはできていない。要するに、深く理解していることがテストで良い点を取れることを保証するものではないのである。

仕事も全く同じである。与えられた資料を読み込み、深く理解したから良いアウトプットが出せるか、というとそうではない。どんなに理解していても、期待される成果物を作れるかどうかは別なのである。

頭がいい人の多くは、理解すなわちインプットに重きを置く人が多い。仕事でわからないことがあれば納得いくまで話を聞き、自分で調べたりする。ただ、インプットに時間をかけた分だけ、アウトプットの時間が減ってしまうことは考慮しておくべきだ。仕事の現場において理解することは単なる手段でしかない。

例えば、プログラムを作る場合はアウトプットに最適化すべきである。ネット上に使えるリファレンスがあるならそれをコピペして使いまわした方が早い。Googleのアルゴリズムのおかげで信頼性の高いものがヒットする。実際に動かしてみて問題がなければOKとする。その方が早い。

もちろん、自分で一つ一つプログラミング言語の文法を調べて、少しずつ段階的に作った方が時間はかかるが、次に同じものを０から作り上げることができる可能性は格段にあがる。しかしながら、０からプログラムを作る必要があるケースなどほとんどないので、このあたりは残念ながら自己満足でしかない。

ただ、アウトプットに最適化することが必ずしも良いか、というとそれも違う。確かにアウトプットに最適化したインプットをしていると、生産性は高いし、良い成果物も作れるだろう。ただし、それは短期的な成果に限る。上に述べたように、付け焼き刃で身につけた、本質的な理解を伴わない知識はすぐに忘れてしまうからだ。

また、アウトプットに最適化していると、どうしてもイレギュラーに弱くなってしまう。特に、説明資料を作る場合などは、目的や経緯、問題点、原因と対策案などを深く理解している必要がある。説明の伴う成果物については、どちらかといえばインプットを重視した方が良いのだ。

最近気づいたのが、こんな風に状況に応じて、インプットとアウトプットのバランスを変えられる人間は非常に少ない。成人した頃には、インプット重視なのかアウトプット重視なのかが大方決まっているからではないか、と思う。

インプット重視型は他人への説明が得意であるし、ある程度のイレギュラーにも即座に対応できる傾向が強い。これは事前準備を綿密に行う資質からくる対応力であろう。ただし、色んなことにスピード感が欠ける。

アウトプット重視型は説明が不得意で、とりあえずやってみてから考えるスタンスを取る。最低限の準備でスタートを切るので、仕事は早い。準備を嫌い、想定外の問題が発生した時は、発生してからトライ&エラーで問題解決にあたる傾向がある。いうまでもなく、私もアウトプット重視型である。

ただ、これらも意識的に変えることは可能である。説明が苦手なのだとしたら、少しインプットに比重をかけてやればいいし、仕事が遅いと感じるのであれば、少しアウトプットに比重をかけてやる。

無意識に仕事を進めると、自分の基本スタンスで仕事を進めてしまうため、問題が顕在化してしまうが、仕事の種類に応じてこれらを使い分けられるようになれば、特に致命的な問題にはならない。