AsIsとPRDのフォーマットを固めている。

これらのフォーマットはオリジナルのものを使っていますが、
書籍やこれまでの経験から何度ものアップグレードしてきたものです。

AsIsとPRDのフォーマットをきめるとこれまでの経験を次に活かしやすくなります。
また、過去のAsIsやPRDを振り返ったときにも読みやすくなります。
フォーマットが自分の最適な思考回路になるんです。

まだ、最適化を続けている次第ではありますが、AsIsやPRDは書けば書くほど、問題解決力、新規事業提案力が身についている実感があります。
フォーマットにある程度従うことで、論理的かつ多面的に物事を見ることができるようになるからです。

僕のAsIsとPRDのフォーマットは下のURLから見れるので、ぜひ参考にしてください。
https://hackmd.io/8DJJpdeDQaeCtduyz-IXJQ
https://hackmd.io/hC1aaa_dTxusdkiGpOSUYg

あと、月に一回は必ず、この組み合わせで資料を作って、これまで誰もやったことのない課題に取り組み、社内外に大きな影響を与えるような成果を残してきています。
これが、まさに「仕事は誰かに与えられるものではなく、自分で生み出すもの」という僕の理念を具体的なアクションプランに落とし込んだものだと思います。

とにかく文字に起こす。

AsIsとPRDの話に非常に似ているのですが、考えは文字に起こすことが非常に重要です。
自分が今考えていることが認識できるから。
本当に解決するべき問題は何なのか
たくさん書こうとするので考えが自然に深まる。

といったメリットを感じています。

しかし、どうするか何も思いついていない。
つまり、仮説がそもそもない状態ではPRD(事業計画をたてるときはMRDを書きます)はかけません。

そういう時は、とにかくホワイトボードに殴り書きしています。
大体左上にテーマを書いて、
左半分くらいの所に思いついたことを列挙します。ブレストのような要領です。
(この時に後述ファクトベースは絶対に意識する必要はありますが。)

例えば、
なぜ早く起きれないのか
出会ったら、

起きる気合が足りない
目覚ましの音が小さい
寝るのが遅い
睡眠が浅い

とか色々仮説は立てられます。
そのあと、３つの質問をします。
「Why so」「So What」「if not」の３つです。

起きる気合が足りない
- 眠いから(笑)
- 1ぶっちくらいでは落単しないから
- まだ寝てても間に合うような気がしてる
目覚ましの音が小さい
- スマホが遠い
- スマホだからそもそも音は小さい
寝るのが遅い
- 夜Qiita見てるから楽しくなっちゃう
- 夜に仕事しがち
- そもそも仕事から帰ってくるのが遅い
睡眠が浅い
- 寝る直前までQiita見てるから

まぁこんな感じでどんどんでかくなっていきます。
このあとは「So What」です。
だから何？って問い直すと本当の意味が見えてきたりします。
あとは、「if not」です。
もしも、寝坊しなかったら....
とか考えるのもいいかもしれません。
寝坊しないんだったら、夜更かしできるな。でも睡眠不足が祟るよな。
だから早起きすることに意味はないな。早く寝ないと。
でも、結局トータルの時間は変わらないから、翌日夜やるべき仕事をやらなきゃいけない。
最終的に大切なのは、無駄な時間を減らして効率よく生きることなんじゃないか。とか

話が飛躍しているように感じるかもしれませんが、これが「if not」の威力です。
普通の人だったら考えないようなことを考えるきっかけをくれます。

何を作るかではなく、誰に作るかを常に考えるようにしている。

僕のようにエンジニア側の人には伝わると思うのですが、すごいものを作ることが目標になっている組織ってありません？
もちろん便利だったり、高速に動作したりした方がいいに越したことはないんです。

でも、そもそもITっていうのは人類の暮らしを豊かにするものなのです。
たとえ需要がニッチだったとしても、使ってくれる人のことを考えてものを作るんです。
そうでないと、的外れな改善案が出来上がるんです。
豊富すぎる(誰も使わない)機能だったり、難しすぎる開発手法に手をつける必要は本当にあるのでしょうか。
本当に世の中で使われるサービスというのは、すばらしい機能を提供しているというよりは、利用者にとって最高の体験を提供しているのです。

ファクトベースシンキング

聞いたことないかもしれませんが、僕が勝手にファクトベースシンキングと読んでいるだけなので、知らなくて当然です。

世の中の構造として、私たちが見ている現象というのを二次情報とここでは呼ぶことにします。
本質となるような事柄の因果関係によって引き起こされ、私たちに直接的に影響を与えているものです。

そして、本質的な原因となる事象のことを1次情報と呼ぶことにしましょう。

簡単に言えば、

先月に比べて今月はラーメン屋Aの売上が2倍になった

というのは、2次情報です。
その一次情報というのは、

先月に比べて平均気温が6度下がったことによって、寒いと感じる人が増えたために、身体を温めるためにラーメン屋Aに入った人が増えた。
店先に英語のメニューを設置したために、外国人観光客にとって、入りやすい印象を受けたために、普段だったらスルーしてしまっていた外国人観光客がラーメン屋Aに入った

のようなものです。

んで、要するに1次情報について考えて改善策や今後について考える必要がありますということです。

もっと言えば、この世のどんなことも全ては、世界の構造によって事象は決まります。

僕達が改善するべきは、起こった事象ではなく、その自称を引き起こす構造そのものにあるということです。

まだ、しっくりきていない人もいると思うので、具象に落しこむなら、

日本人の労働時間が長すぎたり過労傾向にある。

という課題があるじゃないですか。
その解決策として、実際にあるのは、労働基準法という法律ですね。
「何時間以上残業しちゃダメだよ」的な感じです。

これはファクトまでさかのぼって考えていないですよね。

これの1次情報を考えると、
そのそも仕事の量に対して、労働者の人数が足りていないという構造にから、残業をしているんです。
別に好きで残業させているわけではないはずです。

なのに、人も増やさず、仕事の絶対量を減らすわけにはいかず、労働時間だけを減らすように要求したらサービス残業が増えるだけに決まっていますよね。
ファクトベースで考えたら当たり前のことなんです。

だから、本来作るべき法律は、どの程度以上の仕事を引き受けるときには、○人以上のチームを作ること
とか、
そのために、毎年何人以上採用しなければならないとか、ですよね。
採用がうまく進まないならば、そのサポートをしてあげるのが、本来の問題解決です。

今施されている法律は問題対処
僕たちがやるべきは問題解決

モグラ叩きで例えるなら、
出てきたモグラをハンマーで叩くのが問題対処です。キリがありません。
そもそもモグラが出てこないように機械ごと壊すとか、穴を塞ぐとか、それが問題解決です。
圧倒的に効果的な発想なのです。

世の中では、この働き方改革の問題に限らず様々なところでファクトベースに考えられていない問題が起こっています。

本当に問題解決に大切なのはスキルや思考力ではくて〇〇である。

問題解決というと、なぜかみなさんケース面接で問われるような柔軟な思考力が大切だと思われるようですね。
エンジニアの方は競技プログラミングで問われるような難しいプログラミングスキルが重要だと思われている方や、難しいツールを使ったクリエイティブな開発が重要だと思われている方が多いですね。

問題解決に必要なのは競技プログラミングやケース面接ではありません。
というか、逆にそういったものだけが大切だと思っているようでは問題解決のスタート地点にすら立てていません。論外です。

大学受験や大学での勉強が「誰かが作った一つに決まっている答えをいかに効率よく解けるか」を競うような性質のものだったので、仕事においてもそうだと思ってしまっているからなのかもしれません。

しかし、社会に出ると、誰も問題は渡してくれません。与えられたことしかできない奴はただの無能になります。
社会で価値のある人というのは、自ら答えのない問いを立て、それに対して結果を出せる人です。
というと少し難しく感じるかもしれません。

「実際に現場でも本質的な課題に気が付いているが、そもそも誰も解決策を実行しようとしないために放置されている問題」
というのがもう世の中に溢れかえっているんです。

会社内部や世の中に大きな問題があったとしても、
誰も解決しようとしないのです。

これを解決するために必要なものはなんだと思いますか？
それは、

周りを巻き込むリーダーシップ
誰に与えられたわけでもない課題に自ら取り組む主体性
新しいことをやることを認めさせる人間性

の３つです。
この３つを合わせて、問題解決力なのです。
これについては別の記事で何故この3つが重要なのかについて話しているので、是非ご覧ください。

目標を掲げる

僕個人の目標は、GoogleやFacebookに劣らないような世界中に大きな影響を与える会社を作ることです。
「多大な苦労を伴ってもそこに到達してみたい」という風に心から感じられる目標を掲げていないと、周りの何倍もの努力は重ねられません。
僕が、大学に入ってどんなに辛い時も努力を継続してこれているのは、心から到達したいと思える目標があるからだと思います。
そして、身の回りの人にも常に目標を提示してあげましょう。
「目標を失った組織は腐ります。」
目標は「多大な苦労を伴ってもそこに到達してみたい」という風に心から感じられるものであることが前提です。
そうやって、周りのモチベーションを保てると自然に
「新しいことをやることを認めさせる人間性」が身につきます。

バリューを出し続ける

バリューとはつまり成果のことです。
もっと言えば、
自分の出した成果　ー　普通の人の出す成果
という感じです。
これが、0ということは自分は普通の人と何も変わらない、「与えられたことしかできない人」
ということを認識してください。

今自分のやっていることはどのような付加価値を生んでいるのか常に意識していきましょう。
このちょっとした付加価値は圧倒的な信頼を勝ち取ります。

また、自分に与えられた役割の中でのプラスアルファはもちろん重要ですが、
私はインターン先のの上司や仲間の誕生日には普通の人は絶対に渡さないような額のプレゼントを渡すようにしています。
いつもありがとうございます。と必ず感謝を述べ、誕生日を祝うと同時に職場を盛り上げます。
これも私が職場で働いていることの付加価値の１つです。
こういったことの積み重ねが、「信頼」に繋がると思っています。
とにかく、常に普通の人ならやらないことをやることを意識していきていきましょう。

もう一点、「結論を出す。ポジションを明確にする」
というのもバリューの１つになります。
エンジニアやデータサイエンティストに多いのですが、

PM「この機能を実装して」
エンジニア「はーい」

———————————————————————————————-

エンジニア「できました！」
PM「ありがとう」

というような流れのやり取りです。

エンジニアの人は、必ず、
「その機能は誰のどんな課題を解決するのか」というのをPMやディレクターなど機能要件を定義した人に確認して当然だと思います。
(そこがないとバリューは生まれません。なのに頑張ってしまうと不必要なワークによる所謂ゴールドプレーティングが起きるだけです。)

そして、その機能の価値として自分の意見を持つべきなのです。
そうでなければバリューは0です。これこそ、「与えられたことしかできないやつです。」
データサイエンティストで分析しろと言われて、数字やグラフを出す人はそれ以上にひどいです。
KPIとかいうかっこいい名前を使って、DAUやRRをダッシュボードに掲載して分析してる感を出すIT企業も最悪です。
「だからなに？」
としか言いようがありません。

分析に限らず、常に「ファクトベースシンキング」でないといけないんです。
DAUやRRは私たちに見えている現象です。
その原因を突き詰めるにはもっとたくさんの分析が必要です。

しかし、数値をみたいからという理由でSQLやDataprocを使っていたらエンジニアが過労死します。
だから、まず先に仮説があってそのベンチマークとしてデータを使うべきなのです。
「ファクトベースシンキング」でいう本質を一旦仮定して、それを確かめるようにデータを使うのです。仮説が外れたらそのデータからまた新しい仮説を立てるのです。

利用者をクラスタリングしてみたり、利用時間や使っている端末に対して仮説を立ててみると致命的な欠陥が浮かび上がってくることは多々あります。

ここまで持ってきて初めて「バリューを出した」と言えるのです。
ここまでの話で、地頭は必要ありません。ロジカルシンキングも高度なプログラミングも必要ありません。
基本的なWeb開発や分析のスキルと「ファクトベースシンキング」
そして、メンバー全員が「バリューを出す」意識、つまり「主体性」「リーダーシップ」を持つことだけが必要です。

できるようになる前にやる

当たり前ですね。できるようになるまでやらなかったら一生やらないので、いつかやらないとできるようになりません。
あなたには難しいとか、できない、やめておけ、とか周りに言われたら必ずやるようにしましょう。
できないことをできるようにするチャンスです。

日常から周りの問題を解決する人になる

大学の講義が終わった後、そこに財布が忘れられているのを見つけたら、あなたならどうしますか？

取りに戻ってくるかもしれないからそのまま放置
講義室を出ていった人たちに財布の持ち主ではないですか？と聞いてみる
中に身分証などが入っているはずなので、教務課に渡してみる

などの選択肢があります。この時にアクションが起こせない人は、目の前にある課題を放置する側の人間です。

目の前にある課題の解決策がわかっていてもリーダーシップを発揮する人がいないために解決されていない問題というのは本当にそこら中にあるんです。

また、これが大学の講義室ではなく、最寄駅の改札であれば多くの人が
「これは駅員の仕事だからそのままにしておく」というでしょう。
しかし駅員が来る前に誰かがネコババするかもしれません。
だから、近くの人に聞いてみたり、駅員のもとまで持っていったりというアクションが必要なのです。
それでもほとんどの人はこういったことをしません。
「これを解決するのは誰の役割か」を重要視しているからです。

解決策が明らかであればその課題をリーダーシップを持って解決する側の人間になるべきなのです。

どうせ誰もやらないから、あなたがやるのです。それがバリューを生むということなのです。