伝えたいことが伝わらない理由
伝えたいことを話しても伝わらないことってあります。 これ、すごく良くわかります。
自分では「伝わっているはず」ということが実は「ほとんど伝わっていない」ということがあります。
私の仕事はウェブサービスづくりです。 エンジニアとしてではなく、プロダクトオーナーという役割でチームに関わっています。
プロダクトオーナーの仕事は簡単に言うと、サービスの方向性を決めることです。 エンジニアやデザイナーはプロダクトオーナーが決めた方向性をもとに実際に動くサービスを作ります。
そのため、プロダクトオーナーがきちんとやりたいことを伝えられないと、どんなに腕の良いエンジニアがいても良いサービスはできません。 私はもともと伝えることが苦手で、途中の説明や背景を飛ばして伝えてしまうという癖があります。
ですが幸いなことにとても良いチームメンバーに恵まれ、何度もフィードバックを受けることができました。 そのようなフィードバックを重ねることで、どうして伝わらないのかの原因が少しずつ見えてきました。
今回は自分の経験を通じて、なぜ伝わらないのかの原因を紹介していきます。
伝えたいことが伝わらない理由
伝えたいことが自分で理解できていない
伝わっていないときの最も多い原因がこれでした。 特に私は早とちりをすることがすごく多く、かなり早い段階で「自分はもう理解できている」と思ってしまう「イタイ」タイプでした。
そのため、伝えたいと思っていることが実は自分でも理解できていないという、どうしようもない事態に陥ってしまったのです。 これは伝えた後に、伝えた人にいろいろ突っ込まれてみると、よくわかります。
理解できていると自分が思うとき、100%理解できていることは稀である。 ということを肝に銘じておくことがとても大事だと今では実感しています。
前提が違うのに話を進める
話しはじめてしばらくすると、みんなの様子がおかしい。 どう考えたって、頭に？が浮かんでいる。
理解されていないなと思って、言い直してみたけど余計に？が大きくなっている。
こういうことは、自分一人でじっくり考えたことを伝えるときなどによく起こります。 この場合、伝える相手と自分との前提が噛み合っていないことが多いです。
話を聞いているみんなの頭にAという知識がある前提で話し始めたけど、みんなの頭にはそもそもAという知識がなかった。
そんな状態がまさに「前提が噛み合っていない状態」と言えるでしょう。
勘違いならまだ救いはあるかもしれませんが、最も救いがないのは「そもそもみんなにAという知識があるかどうかを考えもしなかった」という場合です。
伝えたいことを100%理解できていたとしても、このような状態では伝わりようがありません。
みんなが知りたいことと自分が伝えたいことが違う
もし、カンボジアの文化について知りたいと思っている人に、 フィリピンの経済発展について説明をするとどれくらいの人が関心を持って聞いてくれると思いますか？
どれだけあなたが伝えたいことを理解していて、前提の知識を考慮して伝えたとしても、相手が知りたいことを理解しないで伝えていると全く伝わりません。
その話は右から左に流れていってしまうだけです。
伝えたいことが伝えるために
自分が100%理解できているか何度も確かめる
自分が伝えたいと思っていることを、自分が本当に100%理解しているのか。 これは疑いすぎて、疑いすぎることはありません。
1時間考えてみて、「理解できている」と思ったらあと1時間考えてみて下さい。
1週間考えてみて、「理解できている」と思ったらあと1日考えてみて下さい。
1ヶ月考えてみて、「理解できている」と思ったらあと1週間考えてみて下さい。
深く考え直した時間は決してあなたを裏切りません。
前提をとことん揃える
何かを伝える前にかならず「前提を揃える」ことを意識してみて下さい。 これは1対1で伝える場合もそうですし、複数人に伝える場合も必ず必要です。
あなたと相手の頭の中のスタート地点が同じになるように、話し始めるめに「これは理解できている？」「これはこういう前提だけど間違いない？」と、事前に用意しておいた項目を確認するようにしましょう。
そして、何よりも大事なのが前提を揃えるために確認する項目に見落としがないようにすることです。そこができていないと、前提はいつまでたっても揃うことはありません。
相手が何を知りたいか考える
基本的に人間は自分のことしか考えていません。もしも、あなたの話を一生懸命聞いてくれる人がいたとしたら、それはあなたのためではありません。自分のためになるからこそ、あなたの話に関心を寄せているのです。ですが、それはとても理想な形です。
そんな理想な形に持っていくために、相手が知りたいと思っていることは何かをとことん考えましょう。 もし、考えてもわからない場合は、実際に相手に聞いてみるのも一つの手です。
僕がエンジニアを辞めた理由
何か成し遂げたい、何かを達成したいと思うことって素晴らしいですよね。 でも、大概のことって1人では成し遂げられないです。
例えば、「楽天を超えるサービスを作る！」と意気込んだところでそんなこと、一人でできるわけがありません。
これって、言葉ではわかっているけど実感するの難しいです。
私が未経験からエンジニアを始めたときも、一人でなんでもできるようになりたいって思っていました。 だからこそ、とにかくプログラマーとして一流にならないといけないと肩に力をいれていました。
でも、今私はエンジニアではありません。 サービス全体を見るプロダクトオーナーです。
どのような考えの変遷があって、エンジニアを辞めてプロダクトオーナーになったのか。 そこらへんを今回は簡単にお話していければと思います。
一番したいことは何か？
私が一番したいことは「自分が作ったもので、人の心に感動を届けたい」というものです。 これは今も変わっていません。
でも、作っているものはいつも変化し続けています。 あるときは映像だったり、小説だったりと。
そして今は「ウェブサービス」でそれを成し遂げたいと考えています。 私がエンジニアになりたいと思ったのも、それがはじめにありました。
インターネットの可能性を強く感じ、ネットを通じて自分が作ったものを届けたい。 そのためにも、とにかくプログラミングをできるようにならなきゃって思っていました。
自分で書かなくても、作りたいものは作れると気がつく
未経験からエンジニアになると決めて、会社で新しくできた開発部に社内転職。 開発部に入ってからはサービスを作るためにガシガシとプログラミングをしていました。
できたばっかりの部署でエンジニアは私以外誰もいなかったのですが、採用を積極的に行うことで仲間が少しずつ増えていきました。 中途で入ってきた人は経験が6年もあるベテランエンジニア。当然、自分とのレベルの差に歴然とさせられます。
なんとかついていこうと必死になりますが、半人前以下である自分は全く戦力になりません。 エンジニアになって半年、全然進歩しない日々に「向いていないのかな」と100回くらい心が折れそうになりました。
そんな落ち込む私を見て、ある日CTOがこんなことを言いました。 「君はエンジニアとしての能力はまあ、普通だね。頑張ればある程度できるようになるかもしれないが、一流になるにはかなりの努力が必要かもしれない。でも、持って生まれた人の感情を動かすようなリーダーシップがある。そっちを伸ばしたほうがいいんじゃないかな」
それを聞いて僕は言いました。 「でも、リーダーシップなんて私はこれっぽっちもほしくないんです。誰かの心を動かすようなサービスを自分の手で作りたいんです。そのために力をつけたいんです」
するとCTOはすかさず言い返します。 「君はサービスづくりは一人でできると思っているの？何も君が書かなくても、君がビジョンを伝え、チームを引っ張ることで君が作りたいサービスを作ることも可能なんじゃないかな」
その時は僕は実感しました。 まるで空から降ってきた氷柱が音もなく頭から体に染み渡るように実感したのです。
自分で書かなくても、作りたいものを作れると。
自分の道を見つける
「では、僕はどのようなことをすればサービスづくりに貢献できるのですか？」
「プロダクトオーナーという役割がある。君にピッタリだと思うよ」
プロダクトオーナとは、サービスの方向性を決めたり、エンジニアに作りたいサービスのビジョンを伝えることで、サービスを成功に導く責任者のことです。ときにはビジネス面やマーケティング面についても関わって、サービスをグロースすることが求められます。
その後詳しく話を聞くと、まさに自分がやりたかったことがすべて詰まっているのがこの「プロダクトオーナー」なのではないかと思えました。 数週間考えてみて、エンジニアを辞めてプロダクトオーナーとしてサービスづくりに関わることを決めました。
この日、僕はエンジニアをやめてプロダクトオーナーになりました。
開発部を発足させてまずやったこと
とにかくわからないことだらけ
意気揚々と「エンジニアになる」と開発部に入った私はやる気満々！
わからないことを全てスポンジのように吸収してやると鼻息荒く出社していました。
しかし、実際にどうOJTで未経験の私が学んでいけばいいのか？
CTOはまず私にこういいました。
「とにかくまずは自分でサービスを作って、リリースするまでの成功体験を」
私は、なるほどね〜まあそりゃ成功体験って大事だよね。と考えていただけだったのですが、後になってこれが本当に大事なことだと気が付きます。
そしてさらに続けて言いました。
本当に身につくのは人から教えられたことではなく、自分で調べて解決したことなんだよ
実際、長年の経験を持つメンターがついた私は学校に行った生徒のように、何かを教えてもらえるものとばかり思っていました。
しかし、CTOの考えは違いました。
「15分調べてもわからないことがあったら遠慮しないで聞いていいからね」
ということでした。
実際この言葉は凄く助けになりました。
まずは自分が調べるということが習慣づきましたし、いざとなればいつでも聞ける人がいるという安心感を与えてもらったわけです。
まずは何を改善して、社内のどんな課題を解決していくかを決めていく
私とCTOの二人で発足した開発は最初悲惨な状態でした。
- ウェブでの売上はほとんど皆無に近い
- 現状のウェブメディアが悲惨すぎる
- エンジニアが全くの未経験の私しかいない
- 会社は営業部が中心で、形見狭すぎる
などなど、色々と解決しなくちゃいけない問題が山のようにありました。
さあではどうやって今後課題に対してアプローチしていくか。
そこで、私達はリアルな看板ボードを用意して課題を書き連ねて行きました。
大きな課題
- ウェブメディアを完全にリニューアルする
- エンジニアを増やす
- ウェブで売上を立て、その売りげを会社の柱にする
まず大きな目標として上記を掲げました。 スクラムでいうところのこれがプロダクトバックログですね。
そして、次に具体的に何をしていくかを細分化していきました。 これはスクラムでいうとスプリントバックログにあたりますでしょうか。
ウェブメディアを完全にリニューアルする
- リリースまでのスケジュールを決める
- 現状のウェブメディアの問題点、課題を洗い出す
- ユーザーインタビューを行う
- リニューアルの方向性を決める
エンジニアを増やす
- 社長に話して採用条件を良くする
- Wantedlyに採用記事を書く
ウェブで売上を立て、その売りげを会社の柱にする
- 現在会社で売上を上げている分野をウェブの力でさらに伸ばすことができないか検討
- PVアップのコンテンツを新規で生み出す
ざっと簡単に洗い出すとこんな感じです。
上記を付箋に書き出しToDo・Doing・Doneの枠組みで壁に張り出していきました。
私の仕事は当然成長ロードマップを元に学んでいくということはもちろん、上記の課題をアプローチすることも含まれていました。
次回は、プログラミングをどのように学んでいったかと上記の課題に具体的にどのようにアプローチしたかをお話できればと思います。
開発部に入ってからまず渡された成長ロードマップ
本当に何もわからずCTOを呆れさせる
新しく立ち上がった開発部は口説き落としたCTOと私の二人でした。
私は当然経験0でエンジニアの知識なんかひとつもありません。
それどころかエンジニアでなくても知っているだろうウェブ、IT業界の基本知識ですら一つも身につけていませんでした。
CTOに関して言うと、彼はこの業界では知らない人はいない大手ITのマネージャーをやってきた人。
私との知識レベルは文字通り天と地ほどの差があります。
二人で今後の開発部の構成や新しく立ち上げるサービスについて話していても
「インフラって公共交通機関と何か関係ありますか？」
「アパッチ？アメリカの先住民か何かですか？」
「Macってなんでエクセル入って無いんですか？」
などのような本当にちんぷんかんな質問でCTOを呆れさせていました。
まずは半人前になるのが目標
そんなCTOからある日言われました。
「まずは半人前になるのが目標だね」
そういって下記のようなロードマップを僕に作ってくれました。
■3ヶ月後
・viを使いこなす
・webページが表示される仕組みの理解
↳リクエストとレスポンス
↳サーバーのプロセスの理解
↳ポートの概念
↳サーバーの役割
・unixコマンドの基礎知識
↳ls mkdir ps pwd top id uname ping tail nslookup touch less cat diff find grep
・shスクリプトの理解
・cronの理解
・すぐにログを確認するクセをつける
↳apacheのログファイルの場所
↳OSのエラーメッセージの場所
・設定ファイルの場所と理解
↳apacheのconfigurationファイル
↳phpのiniファイル
・DNS（名前解決）の理解
・開発サーバ（dev）、ステージングサーバ、本番サーバの概念
・サーバ構成図の理解
【目指してほしい姿】
・上記を理解し、基本的なwebサービスがどのように運用されているかが理解できている状態。
・トラブルが発生しても問題の切り分けができ、解決策を最短ルートで探り当てることができている。
・提供するサービスの内容によって、理想のサーバー構成を思い描けるようになる。
■6ヶ月後
・MVCの完全な理解
・laravelの完全な理解
・基本的なHTML,CSSの理解
・gitの完全な理解
・自社サイトの全運用の把握
・本当の意味でのアジャイル開発の理解
【目指してほしい姿】
・一人で開発の相談を受けることができ、かつその相談で正しい回答ができる
・一人で開発の道筋が立てられる
・開発の改善提案ができる
・サービスやコンテンツのアイデアをテスト環境でモックまで作成して提案することができる
CTOはITのトップレベルで長年活躍してきた人です。
その人から「実際の現場レベルで働くためにこのようなことを覚えてほしい」と言われて、このロードマップを渡されました。
いま思えば私はとても幸運な人間です。
同じ職場にこのような経験豊富なメンターがいて、自分の成長をそばで見てくれるし、どんな質問にでも時間を割いて応えてくれる。
これは成長という結果で早く恩返しせねば！と強く思うのです。
さて、次は具体的に私は現場でどう学びながら仕事をしていったかをお話できればと思います。
営業部から開発部いかに転部したかの話
営業部で広告を売っていた時
私は新卒で入った会社で3年間営業職をずっとしてきました。
私の会社はメディアを持っている会社なので、営業というのは基本的に自分の媒体に広告を入れる活動を行います。
営業をやっているときはいかに実際の価値以上に魅力を伝えるかを信条にしてきました。
そうすることで受注金額も大きくなるし、上手くいけば実際に結果も出るだろうと。
もちろん受注したはいいものの結果も出ないときは多く、その後の受注につながらないことも少なくなかったです、、、
それでも営業部にあっては数字な命！魅力を実際以上に語ることで私はどんどん売上を上げていったのです。
自社媒体をもっと大きくしたいと思うようになってきた
最初の方は自分の実力次第で売上が上がっていくので、私は人よりも多く働き頑張っていました！
しかしながらそれも次第に限界に近づくようになってきました。
つまり、100万円の受注をするなら現状の会員数でも、上手く魅力を伝えれば価値を提供できなくても受注できる。
でも、1,000万円を受注するとなるとそもそも話を聞いてもらえない。
私は段々とそのことに気が付きました。
それで、私は媒体の価値を高めなければいけないと「こんなコンテンツを用意したらいいんじゃないか？」などと上長を通じて外注の開発チームに伝えたりもしました。
しかし一向に動く気配はない。
もちろん、私はまだまだ新人で言うこともめちゃくちゃで根拠もないものではあったと思いますが、もどかしさは募るばかりです。
そういう思いを胸に秘めてモヤモヤと営業活動をしながら思い始めるのです。
自分が媒体を作る側にいけないだろうかと
人生を変えた大手IT会社とのアプリ制作
ある時私は社長から呼び出されました。
「君、今度あの大手IT会社のアプリ制作のマーケティングを引き受けることになったのでやってくれないか」
私の会社は子育て世帯に特化した媒体を作っています。
そこで、ある大手IT会社が子育て世帯向けのアプリを作るためのマーケティングを引き受けることになったのです。
当然、企画という立場からアプリにどのようなコンテンツを入れればいいかなど相談も受けていました。
インターネットサービスやアプリサービスに何ら知識のなかったので、かなりちんぷんかんなやり取りになっていたと思いますが、私の意見もある程度採用されてモックが完成されました。
エンジニアとの打ち合わせを重ねて、子育てママへインタビューを行いました。
そして実際にモックを見てもらい、その場でフィードバックを行うと、2週間後にはママたちの声を反映したサービスが出来上がりました。
私はそのスピード感と出来に感銘を受けました。
私がずっと作ってほしいと会社に訴えかけていたサービスを超えるようなものを彼らは企画から考えて約2ヶ月ほどで作りあげてしまったのです。
こんなことが可能なんだと開いた口が文字通り塞がらりませんでした。
しかし、そのサービスが世にでることはありませんでした。
なぜならそのサービスをリリースするための予算に折り合いがつかず（予算をもらえるはずだったところから予算がもらえなくなり）、その大手IT会社はリリースを見送ったのです。
私は思いました。 いつかこれを越えるようなサービスを作ってみたいと。
社内に開発部を作るという噂を聞く
それから約数ヶ月後、社内で開発部を立ち上げるという噂が流れ始めました。
私が独学で「Hello world」とかをブラウザに表示し始めていた時期です。
「本当かな？」と思い始めていると、とある大手IT企業（上記の会社とは全然違う）の元管理職だったという方がコンサルタントとして自社のウェブメディアをマネジメントすることになりました。
私はチャンスだと思いました。
「私にプログラミングを教えてください」
とそのコンサルタントに直談判。もともとインターネットの興味関心について伝えていたということもあり、色々と知識を教えてもらえることになりました。
ちなみに最初に頂いたアドバイスは「Macを買ったほうがいいよ」でした。私は会社からPCの支給があったにもかかわらず、その日の夜にMacbook Airを買いました。
正式に開発部が立ち上がる
開発部を立ち上げるためには当然CTOが必要でした。
そして、その適任者といえばそのコンサルタント以外ありえませんでした。
私は社長と一緒に必死の説得を続け、ついに口説き落としました。
「よっしゃ！！！！」
しかし、この時私はまだバリバリの営業職。独学でプログラミングを学んでいるとは言え、実際の業務では何も書いていません。
このままではいけないと思った私は社長に「私を開発部に入れてください」と再度直談判。
「まあいいと思うよ。でも、ちゃんと上司に報告して上司の許可ももらわないとね」
ということなので、上司に話をすると
「君は向いていないと思うよ。営業の方がいいよ」
私はそのことばに「確かに、、、」と納得する半面、逆に「ならやってみて見返してやろう」とやる気にますます火がつきました。
そして、それからほとんど無理矢理に通常業務から開発部業務に無理やり変えていき（笑）
周囲の反発（たぶんかなりあったと思いますが）をはねのけて、無事に開発部でエンジニアになることができました。
次回は、開発部に入ってから苦労したことなどを綴っていきます。（いや〜いっぱいある）
9時就寝から4時起床のすすめ
夜がいいか、朝が良いか
私はプログラミングの勉強を本格的にしはじめて6ヶ月ほどですが、ここ3ヶ月は9時就寝4時起床の生活をしています。
実はその前の3ヶ月は逆に12時就寝の7時起きの生活をしていました。
そうして、夜型と朝方の両方の生活をしてみて感じたメリット・デメリットを話していけたらと思います。
夜型のメリット・デメリット
メリット
まず、夜型のメリットを一つ上げるとすると周りも基本的に夜型が多いということではないでしょうか。
人間は基本的にコミュニケーションを取りたがるものだと私は思っています。
そのため、話をしたりSNSやLINEでやりとりしたりご飯に一緒に行ったりすることができるのが夜型の一番大きなメリットかなと。
例えばプログラミング学習でいうと勉強会に参加したり、セミナーに行ったりというのは基本平日の夜に行われていますよね。
なのでそういうコミュニケーションを取りながら学ぶのは夜型の方が良いかなと思いました。
デメリット
これはまさしくメリットの逆で、一人で学習できる時間が少なくなるです。
例えば、会社に努めている人であれば急な飲み会など。
飲み会の日ってもう基本的にきちんと学習するのって難しいですよね。
どうしても夜型だとそのような機会も多くなってしまいがちではありました。
朝型のメリット・デメリット
メリット
何と行っても周りに朝方が少ないというのがなんとも言えずに良いです（笑）
例えば電車通勤では必ず座れるし、朝飲み会に誘われることもありません。
また、基本的にみんなが寝ている時間に起きるので誰かに連絡を受けることもなく、本当に濃密な時間を過ごすことができます。
私は朝5時半にオフィスに来ているのですが、みんなが出社するまでハイパー集中して学習をすることができます。
さらに私の会社は早く来たら早く帰れるので15:45には退社しています。帰りも問題なく電車に座れるし、帰ってから勉強しようと思えばまだたくさん時間があります。
デメリット
私は現在完全な朝型なのですが、まわりの意見を聞いてみると「飲み会にいけなくなる」というのが多いです。
また、「友達と遊べなくなる」というようなことも。
なので、友達と会って遊んだり飲み会にいくような人は結構辛いかもです。
基本的に人は夜集まることが多いので、人とコミュニケーションをとることが必ず少なくはなりますね。
結論
プログラミングの勉強し始めは朝型をまずは3ヶ月やってみることをオススメします。
ひとりKPTを実行しよう
KPTとは
KPTとは、振り返り手法のひとつ。
Keep/Problem/Tryの略で、「Keep＝よかったこと」「Problem＝悪かったこと」「Try＝次に試したいこと」の３つのフレームワークで考える方法です。
私のチームはサービスをリリースした時によくこの手法で振り返りを行います。
これをする事で、チームメンバーからフィードバックを得られて次への成長につなげることができます。
ひとりKPTとは
文字通りひとりでKPTをして行く事です。 まあ一人反省会と同じようなものですが、KPTというフレームワークを使うことで成長志向で日々の振り返りを行うことができます。
実際にやってみる
以下実際にひとりKPTをやってみた例です。
Keep(次につなげたいよかった事)
Progateを30日毎日続けられている foreachの使い方を調べて理解できた for文をリファレンスを見ずに正確にかけた
Problem(悪かった事)
include と include_onceの違いを完全に忘れてた 調べたらすぐにわかったのに調べずに質問した youtubeでクリロナ30分見てしまった
Try(次に試したいこと)
Progateは終わるまで1日も欠かさずにやる 質問する前に10分は自分で調べる
大事なのはTryに何を書くかということですが、KeepとProblemに出てきたことを全て書くのは賢明ではありません。
例えば、 「for文をリファレンスを見ずに正確にかけた」 というのがありますが、もうすでに正確に記述できていることであって、次にTryしたところであまり意味をなしません。
また、 「youtubeでクリロナ30分見てしまった」 というのも、大好きなクリロナのプレーを見ることは息抜きにもなっているので、無理して止めることも今回はしません。
Tryにたくさん書き込んでそれが実行できないと、この振り返り自体いい加減なものになって意味をなさなくなります。
そのため、Tryに書くものは成功しやすいものや意識しなければTryできないことを書くのがいいと思います。
KPTツール
KPTon
これは実際にチームで使ったことがあります。 ひとりKPT向きではないかもしれませんが、チームで使うのはいいと思います。
Coggle
これは私は使ったことないのですが、オススメしている記事がありました。
https://qiita.com/abe-perorist/items/a25103de0433544c46cc
ノート
ひとりKPTをする際はノートにK・P・Tの箱を作り、手書きで書いていくことをオススメします。
