頑張るということをしたくないという話しをしました

ことの発端はお酒の席での雑談だったのだけど後々考えてみるとこれは一考する余地があるように感じたのでまとめておこうと思う。

誤解されそうなタイトルなので補足すると努力放棄するということではなく、仕事をするうえで頑張るという評価軸は正しくないのではないか?と考えているという話しをしたぞということです。

事の発端:

どういう話しの流れだったのかもう思い出せないのだけど先月末あたりに会社の飲み会の最後のほうに同僚がぼくを「そういえば最近頑張ってますよね?」と評価してくれたことに端を発するのがきっかけだったように思う。

それに対して「ぼくは頑張るということをしたくないと考えていて、何故なら頑張るというのは自己満足の域を出ないと思っているのでそういうエモーショナルな観点から評価されたくない。」と返したんだという流れだったような気がする。

ぼく自身はお酒を飲んでいなかったのだけどしばらく時間が空いてしまったので正確なところは覚えていない。 ただこの件で反省していることがあってもう少し言い方というか表現を変えることができなかったかな?という気持ちがある。

君の頑張りを私は評価しています!というポジティブな意見に対して反論してしまっているので「評価してもらって嬉しいけどもぼくは頑張りではなく成果を出してそこで評価されるようになりたい」という感じに言い換えれたら良かったのになーという気持ちに後日なった。

もしかすると本人は気にしていないのかもしれないがぼくはこの手の発言したあとで大いに気にしてしまうことがあり、その辺り本当に気遣いができない人間だと思っている。

とまれそこはこの話しの本質でないのでここまでにするが何故ぼくが頑張るという言葉に過剰反応してしまったのかという点に関していくつか理由がある。

  • 1つ目は、以前働いていた会社で「頑張るのは当たり前」という言葉が飛び交っていたことに対する不信感があったこと。
  • 2つ目は、ぼく自身は頑張っているというよりは仕事に対して真剣に取り組んでいるだけであって特段頑張っているつもりがなかったこと。
  • 3つ目が、ぼく自身が頑張るというエモーショナルな観点から評価されるのが歪だと感じていて、それを仕事の評価に取り込んでほしくないと思っていたこと。

他にも細々したことがあるのかもしれないが大きくはこの3つが原因かなとみている。

「頑張る」という不信感

頑張るという言葉は非常に便利だ。 日本語のこういうファジーな表現は非常に使い勝手が良いし日本語の優れた点だと思う。

とはいえ、頑張るというのは常日頃から行っているのが当たり前だと息切れをするのではないかとぼくは思っていて、つまり頑張るというのはここぞというときにだけ使うべき必殺技のようなものだというのがぼく個人の見解であり、そうありたいと願っている。

なので頑張っていない状況で働いている時間だけをみて「頑張っている」という評価は不当、あるいはフェアでないと感じたのだろうと思う。 こう書くと怒っているようなニュアンスに受け取る人もいるかもしれないが、ぼく個人の感情としては怒りではなくフェアでないので正しい評価に戻すという印象が近い。

さて、そこで件の頑張るのは当たり前という件に戻る。 頑張るのが当たり前という言葉はかなり語弊があるとぼくは思う。

頑張るのが状態化しているのならそれは頑張っていないことに等しいというのがぼくの考えであり、 期待しているのは頑張るという過程の行為に対する時間や労力ではなく真剣とか真面目とか真摯とか仕事に対する姿勢を問われていると思うのでこの言葉は選択を間違えているのだとぼくは考えている。

例えば5時間かけて苦悩して問題を解決した人と片手間に鼻くそほじりながら15分くらいで問題を解決した人を第三者が見た場合にどう感じるか?という問題がある。

ぼくらのようなエンジニアやクリエイターであれば、苦労した時間が必ずしも成果に対して比例しないので後者のほうが効率よく作業をしたとみなす傾向がある。 そう、あくまでそれを視界にいれていなければ。

文字だとそんなの後者を評価すればいいじゃんとなるのだけど現実にそういう苦労する姿をみてしまうとそれだけでバイアスが自覚、無自覚を問わず働いてしまう。

そこには「頑張っている」というバイアスがかかっている。

苦労をして問題を解決したことに対して尊さを感じていたり、あるいは問題解決そのものよりも苦労することそのものに価値が生まれてしまっているのかもしれない。

人間にとって苦労することはわかりやすい指標なのかもしれない。

苦労しないように苦労をした場合その過程を知らなければ検知することができない、世界一有名な箱の中の猫のようなものだ。 観測されるまでその事実はなかったものとして扱われる、なんという理不尽!

真剣に向き合うことは頑張りではない

努力は報われるべきだし、その点が評価されないのは不当だと思う。 先の例でいうならば仕事という観点で見た場合に評価されるべきは後者であるとぼくは考えている。

仕事の評価という意味においてこの「頑張る」というバイアスは正しい評価を歪ませてしまうので悪、というと語調が強すぎるが良くないものだと考えている。

仕事の評価というのは究極的にいうなら会社の利益にどれくらい貢献したのかだと思っている。 会社は言うまでもなく営利企業なので利益を追求するべき組織だ。

とはいえ、それだけだと目に見えるようになった数字しかみない存在になってしまう。

これの悪い例としてよく上がるのがノルマだろうと思う。 ノルマという制度、もしくは仕組みそのものは悪いわけではないのだと思うがその運用を人間がやると多くの場合、悪化するのではないかとぼくは考える。

ぼくが知るノルマの悪い点は数字を絶対化しすぎていて数字化できない部分で会社の利益に反する行いが横行してしまいがちだということだ。

数字上は良くなっているはずなのに実態は悪化しているという状況はこの数字外の部分で会社に不利益を与えてしまっているからではないだろうか。

そういう思いが根底にあったのでつい過剰に反応してしまったのだと思う。 ぼくは評価はフェアであってほしい、あるべきだと考えているのでそこに無用なバイアスをかけてほしくなかった。

それがポジティブな面であってもそれを許してしまうとネガティブな面のケースでもバイアスがかかるのを許してしまうのが人間だ、ぼくは人間を、特に自分という人間を最も信用していない。

そのため評価に対して「頑張る」というバイアスをかけるのには反対だと考えている。

仕事に対して真剣さや真面目さは必要だと思う、但し仕事に頑張るという方向性を持ち込むのは悪手でむしろ頑張らなくても良いようにしていくのが本質的な仕事の価値ではないかなと考える。 その点においてもやはり頑張るという曖昧な努力目標を仕事の持ち込むべきではないと思う。

頑張るという評価はエモーショナル

頑張るってものすごく感情面に左右された評価だと思っていて、それが大きく影響されるのがフェアでないなと考えている。

同じ労力で2時間の作業をした場合に片方が苦悩しているアピールをしているケースと淡々と仕事をしているアピールをしていた場合により頑張っていると感じるのは前者なわけ。 だとするとあまりよい表現ではないけど演技力のあるほうが評価されるということになる。

自己アピールも能力の一つだとは思うし、それはそれでその人の持つスキルや属人性の一つと言えないこともないと思うのだけど 作業や仕事、やっていることに対してそういった演出によるバイアスがかかってしまうとそれが苦手な人は不満を持つんじゃないかな? 同じくらい苦労しているのに彼、彼女は大げさにアピールすることで自分よりも良い評価を得ているみたいな。

「それも1つの生存競争における闘い方だろう?」という人もいる、それはそのとおりだと思う。 だけどそれに左右される評価式は果たして正しいのだろうか?

ぼくはその式に欠陥があり、不純物を混ぜ込んでしまっていると思う。

なので不純物であるエモーショナルなノイズを除去して俎上に載せましょうというのが理想形だと思うんだよね。 実際には努力したこと、挑戦したことは評価されるべきだと考えているのでノイズを全て排除してしまうと今度は逆にその評価式がおかしくなってしまう。

我々は飲み水がほしいのであって工業精製水がほしいのではない、みたいな感じだろうか? 同じ水という区分ではあるけど必要なミネラルや成分までも排除してしまうと今度は目的を達成することができない、あるいは目的は達せられるが付加価値がなくなってしまうという感じだろうか?

頑張るというのはエモーショナルでものすごくファジー、曖昧な表現なのだけど、努力するには必ず誰が?なにを?という主語と目的語が明確になっていなければならないと思っている。

頑張るはそれらが明確化しなくても使えてしまう。

悪い言い方をすれば具体的な目的、目標もなく逃げれてしまうので評価という点においては不適切だろう。 その点努力するは目標設定したうえでの宣言、コミットメントなのでエモーショナルさはさほど含まれていないというのがぼく自身の認識である。

現実にはそうではないのだけどぼくはそう切り分けて考えているという話しなのでその辺はどうでもいい。

まとめ:

頑張るという日本語はすごくファジーでエモーショナルなので使いやすく便利なのだけどぼくはあまり好きではない。

それよりはぼくが作ったものに対して「使いやすい」「もっとこうしてほしい」「この機能があるおかげで助かった」「こういう機能があると嬉しい」という評価のほうが個人的には嬉しいし、正当でフェアな評価だと思うのでそういう点で評価されるように自分の考えや価値観をまず知ってもらうよう努力していこうと思う。

というようなことを考えていたのでまず第一歩としてここに書き出したということである。

リモートワーク@tomaruba

TL;DR

5月入社で6月からリモートワーク開始してるのでそろそろ4ヶ月目くらい。 現在の状態をKPTでメモ。

Keep:

  • 最低でも週一リモートワークデイは維持
    • 週2回くらいまでは問題なし、それ以上だと問題が出てくる
  • 体調不良によるリモートワークなし
    • 休んできちんと直すのも仕事
  • 自宅だと昼寝するのに気兼ねなくできる
    • 職場だと騒音とか視線とかで心理的安全性にいくつか課題がある
  • トイレに誰かいるという状態がないのでお腹の調子が悪いときめちゃくちゃ嬉しみ
    • 個人用トイレが完備されているようなものなのでめっちゃ助かる、最高。
  • 就業時間を前倒しでやってもよい空気感
    • 職場来てるときと同じ就業時間が大原則
    • なにか予定があるとき便利
  • 通勤時間分の空き時間が生まれる
    • 朝いつもよりゆっくりしたり、なにか用事を済ませることができる
  • 紅茶/コーヒー飲み放題
    • 自宅なので自分の好きな銘柄や品種で入れられる、最高。

Problem:

  • 昼寝してタイマーかけ忘れると無限に寝れてしまう、1度タイマーかけ忘れたことがあって焦った
  • 職場よりも仕事への集中力が下がる傾向がある、作業的にただ手を動かすときは別
  • 小学生、中学生の帰宅時にモチベーションが下がる
  • 天気がいいときにモチベーションさがる、無性に旅に出たくなる

Try:

  • どっか外国行ったときに宿泊先から仕事してみたい
    • そういう状況ならではの問題があるはずなのでそれを経験したい
    • 海外に移住していまの仕事したいとかそういうわけではない、というかそんなのしたくない。
  • 昼寝するときはベッドで寝ない
  • リモートワークする前日までにただ手を動かすだけの状態にする
  • 小中学生の帰宅時間までに終業時間を迎えるよう、前に始業時間を倒す

良かった点:

  • 災害時でも自分で判断して出社するしないを決めれるので台風が来たときとかに指示待ち状態でヤキモキしたり出勤決定したときのガッカリ感がない
  • 災害時でも普段のリモートワークと同じように仕事できる
  • ちょっとした家庭の用事のときに遅刻した分残業する、みたいなことしなくてよくなる
  • 休日は混むのであまりいかないような自宅近辺の美味しいお店で御飯食べれる
    • そのために引っ越しするとき美味しいお店が多い場所にしたいという気持ちが湧く
  • 社内がうるさい!というときにふらっと近所のスタバにいって仕事しても見咎められない

いまいちな点:

  • 相談したいときとか緊急対応だ!みたいなときは職場のほうがいい
    • 基本的に職場のほうがいい派です。
  • ガチで家の外に出なくなる危険がある
    • 元々出不精なのでより加速する
  • 家族がビデオ会議中に乱入することがある
    • だいたいご飯とか貰い物のお菓子をくれるときでありがたいんだけどめっちゃ恥ずかしいのでやめてくれー!?ってなる
  • 時間を気にせず仕事してしまうことがある
    • 終わりの意識が職場にいるときよりも低くなってダラダラ仕事してしまうことがある
  • 災害時にトラブルあるとめちゃ困る、仕事も集中できないのでいっそ休んだほうがいいこともあった

ITエンジニアの仕事環境はどういうのがベストか

仕事環境で重視する理由って人によって千差万別だと思うんですよ、例えばお金とかお金とかお金とか……。

その条件としてぼくがいま重要視してることってなんだろうな?と思ったら結構ざっくりしていたので書き出しておくかー!くらいの気持ちになったという話です。

ちなみに「そもそもお前転職しまくりやんけ!」とツッコミがあると思うんですが転職しまった結果わかったというぼく個人の経験に基づく内容だってことに留意してください。

……昔から気づいてたらこんなに転職しとらんわ!!!

尊敬できるメンバーがいる:

よく転職サイトとかでみかける「成長できる〜」ってやつ。

同じ職場で働くメンバーが信頼できないとそもそも成長以前の問題で辞めたくなるので 大前提で「リスペクトできるメンバーがいる」が必須になります。

なお、かつて働いたところで尊敬できない上司やメンバーがいたところは辞めたあともヘイトが残りましたが 尊敬できる、信頼できるメンバーばかりの職場はそんなこと微塵も思ってないのでそういう意味でも大事です。 (じゃあなんでそこ辞めたか?っていうとだいたいぼくが悪い。)

そういう意味ではTeam Geekは一度読んでおいたほうがいいかもしれない。

でも、これ転職前に知るのはめちゃくちゃ難しいですよね…インターンとか事前に働かないとわからない。 仕事の信頼や尊敬は一緒に働いてみるまでわかりませんからね。

信頼できる経営陣:

チームメンバーはいいんだけど社長(経営陣)に理解がない!!!とかなるとやっぱり辞めたくなる。 ということで経営者が信頼できる、尊敬できるのも重要です。

理由はすでに書いたので割愛。

組織に柔軟さがある:

尊敬できて、信頼できるメンバーや経営者だとしても組織に柔軟さがないと厳しいなってなります。

裁量労働制みたいな全部おまかせ!みたいにしろ!というのは現実的に難しいと思ってる、経営陣側とメンバー側双方にとって。 なのでメンバーを信頼してある程度セルフマネジメントさせてくれる柔軟さがほしいなって思います。

逆に台風明日来るらしいので早めに出社しろとか泊まれとか言われるとその瞬間にクソ辞めたくなる。

don't be evil!:

社会通念上、悪だと言われることをしない、させない。

以前働いていた会社がメールクライアントのBecky!秀丸を不正使用していたり、インターン学生にAdobeなどのアカデミック版を購入してもらい(お金は払っていたらしい)会社で使用するみたいなことをしていた。

「お前それいいと本気で思ってんの?」って感じのヘイトが溜まる会社に長居したくないし、まあそういうところとは付き合いたくないですよね。 人としても組織としても。 当然ながらそんな組織や会社を信頼するのは無理なので早く辞めような!

まとめ:

開発環境、git使えるとかMacBookProだとかIDEがどうとかメモリがどうとかオフィスチェアがどうとかってのは個人的には些事かなと考えていて、それよりもより換えの聞かないメンバーや経営陣のほうが重要だなと考えてます。

なにより結局「働く」って人間が一番ハンドリングするの難しいのでそこを重要視して、ハードウェアやソフトウェアは最悪誰かがお金出せば解決する問題なのでどうとでもなる、くらいに考えておくのがいいんじゃないかなって感じです。

というかそもそも信頼できるひとはそれらの問題をお金で解決するのにだいたい同意してくれるので順番が逆な風潮じゃないですか?という気がしています。

なので「一緒に働きたい!」って思えるのが一番大事。 そのうえでいろいろ揃ってれば文句ないよね!みたいな印象です。

どうせお金とかもらえるだけもらえるほうが嬉しいに決まってるじゃん。

読書アンチパターン

TL;DR

エンジニアの知的生産術を読んで自分の読書方法を鑑みたときに「これって読書アンチパターンでは?」と思ったものを残しておく。 全てが改善されるとは思わない、少しでも改善していけたら御の字というスタイルです。

せっかくなのでアフィリエイトのリンク貼ろうと思ったらKindle版が予約できるようになっていたのでさっそくポチった。

前提条件:

対象者:

  • ぼく

前提:

  • エンジニアの知的生産術の第4章「効率的に読むには」を読了していること
  • 技術書や実用書
    • 娯楽小説をそもそも早く読む意味はない。

結論:

  • 基本的に買うな、読むな
  • 読むなら厳選しろ
  • いま必要なものだけ読め
  • 脳内音読やめろ

ということです。

アンチパターン:脳内音読やめろ

静かな音読をしてしまっている。 脳内、もしくは声には出ていないが文章を音読してしまっているパターン。

ぼくは脳内音読派だったんだけどそのスピードでないといまいち頭に情報が入らない、ということで自覚はしていたのだけど脳内音読を継続していた。 ところがそもそも技術書の読み方を変えて一度目はさっと読んで、わからないところだけ何度も読むみたいな方法に変えるにはここが絶対にボトルネックになるのでここ変えないとどうしようもねえな!ってなったアンチパターン

小説とかは音読でも脳内音読でも問題ないと思います。 っていうかアニメ化とかされるとその印象にめちゃくちゃ引きづられるし、そのほうが楽しかったりしますよね。 娯楽小説はそれでいいのだー!

アンチパターン:定期的に嫁

小説は一気にガーッと読んでしまったほうがいい。 毎週末読むとかすると先週読んだ内容のかなりの部分を覚えていないので平日1時間読むとかそういうある程度の粒度が必要。 そのほうが週末に集中して読み切るよりも精神的コストが低い。 最悪1日読めない、あるいは今週厳しいとかあっても調整が効く。週末集中パターンだと調整が効きにくい。

アンチパターン:YAGNI式選書

必要なものだけを買え、そして買うべき書籍を厳選しろ。 ちょっとおもしろそうとかで買うとだいたい積むだけで読まない、最悪なのでやめろ。 興味を分散させるのは集中に対する最大のノイズ。

アンチパターン:目的が明確でないものは買わない、読まない

選書段階で「この本を読むことで期待するもの」が明確でないならまだ必要じゃない。 その手に持った技術書や実用書は棚に戻すんだ、いいな?

アンチパターン:遅延評価的勉強法

辞書的に引っ張ってくる技術書を買うことがまれによくある。 が、基本そういう書籍は本棚の肥やしになりやすく、また本当に必要なら会社で買ってもらうほうがいい。 本当にそれが必要になってから買うべき。

アンチパターン:読書メモは詳細読みのときに取る

通読時にメモ書くと時間が取られてしまい、スピード感がでない。 明らかに知らない、わからない単語などはむしろメモを取るべきだが、通読時にメモを取るとそれがボトルネックになって全体のスピードを落としてしまっているとは以前から感じていた。 詳細読みを行うときにだけ気になったやわからないこと、違和感を感じたところや私見をメモする形にするのが一番いいのではないか。 そもそもいまでもメモ取るところは知っていることではなく、知らないことが書かれたケースが大半なので通読時にメモしなくてもあまり影響なさそう。

アンチパターン:インなんとかさんはだいじだよ

目次を見て半分以上なに言ってるかわからないものは買わない→自分の知識レベルがだいぶレベルが低いのでミスマッチ

目次みてほぼほぼ内容が想像できる→自分の知識レベルですでに定着しているレベルのものをもう一度読み直す必要はあまりない、ミスマッチ

目次みて7割想像できるが3割がわからない→対象読者として一番レベル帯が近いものであることが多い。買い、但し読書の目的があいまいな場合はなし。

アンチパターン:図式カラー本は選書から外す

なにを目的とするか次第だが図が多すぎるものは初心者向けであわないことが多い。 カラー本は色という情報源が増えてしまい、ノイズになりがちな割に学習という意味で有効だったことがあまりない。 また再利用性(何度も読み直すこと)がほぼない、一度読んで古本屋にGo!するケースがほとんど。

啓蒙書とかは好きにしてくれ、俺は知らん!という感じです。

このアンチパターンから外れる例としてはデザイン関連が挙げられる、視覚的にどう捉えるのか?が脳内で合成できるレベルではないので最初からカラーのほうがわかりみがある。 それ以外のケース、HTMLの組み方とかああいうのは本当に無駄金だなって感じだった。

あとカラーや図が多いとお値段が高くなりがち。お財布的にも厳しいし重い。Kindleだと重さは関係ないけど。

アンチパターン:input → build → outputのサイクルの粒度が大きすぎる

いままでは1冊読む→読書メモから必要そうな文章を組み立てる→ブログ書くのサイクルだったがこれだとサイクルが遅すぎる。 例えば最初の章の内容をきちんと説明できないことが多い、これでは理解しているとは言えない。

1章読む→読書メモ書く→誰かに説明する、図説できる、くらいの粒度がベター。

技術書によっては章だと大きすぎるとかあるので粒度は適当に自分で考えて調整。 読書メモそのものは組み立てるためのパーツなのでアウトプットに含まない。

組み立てたものを説明したり、図説できたりすることのほうが理解しているかどうかのリトマス試験紙として妥当。

理解できていないな?と感じたら、再読リストにその章を突っ込むか付箋紙とかで印つけて読み終わったときにもう一度読み直す。

アンチパターン:パターン毎で読書方法を変える

Aが理解できていることが前提として後述のBが説明される、プログラミング言語を新しく覚えるときなどはこのパターンが多い。 エンジニアの知的生産術だと数学がそうだと書いてあった、足し算わからんのに方程式わからんよな?みたいな話。

ところがそうでなく、読み飛ばしても問題ないケースもある。 これらのいま読んでいる、読もうとしている技術書がどちらなのかを理解したうえで読み方を変える。

多くのケースは読み飛ばしても大丈夫なことが多い。ところが教科書のようなものは前提条件を積み重ねていくのでそうではない。 このあたりは目次みたり、実際に軽く読んでみて判断するしかない。

また前提条件が必要になる場合、理解せずに次に進んでも意味がないので時間がかかりすぎため、それを念頭においておくこと。 時間かかるなら他を優先して読んだほうがいいとかそういうこともあるよね。

アンチパターン:一定数読んだらご褒美をあげる

最重要なのは必要性だがそれだけで技術書を読み続けると正直つまらないし、疲れる。

なので一定書籍数読んだら自分で興味があって買っていたが必要性がそれほど高くないけど興味があって読みたいものを読む。

報酬があるとなんとなく読み切ろうという気になりがち。 娯楽小説とかも含む、クソエモ本は実用書でも技術書でもないのでご褒美本に入れる。

アンチパターン:買ったときに読まずに積読してしまう

基本的に小説でも技術書でも同じなのだけど買ったときが一番「読むぞ!」というモチベーションが高い。 読んでるうちにモチベーションが上がるケースもあるけどそんなのは数年に1度くらいのエッジケースなので考えない。

なので「必要」だから「買った」のに積読してしまうとモチベーションは下降し続ける。 そしてある一定積読したし、そのうち読むだろゾーンで下降が収まり、それ以降読むまでモチベーションが上がることがほぼなく一定の位置を保持してしまう。

こうなると読むぞ!という気持ちに持ってくるまでのフットプリントが大きくなりすぎてしまう。 なので買ったら少なくとも1章くらいは購入日に読む。

当然先に読まないといけないものがあるのに購入してはいけない、発売日に買う必要性は読者であるぼくにはない…やりがちだけど。

まとめ:

基本的に買いすぎ、集中の分散しすぎが積読の大きな原因。 読む速度の遅さは脳内音読のせいだなって感じ。

積読速度 >>>>>> 読む速度なのでできるだけ買わない、買うなら選書段階でしっかり時間をかけないといけない。

ここを改善するだけで大きく読書スピードが上がりそう。 勘違いしてほしくないんだけど、速く読むことそのものには意味がないし、それを目指しているわけじゃない。

ただあまりにも足りていないものやことが多すぎるので技術書や実用書を読んでなんとなくわかって気になれる程度にはレベルを上げておきたい、という目的のために読書スピードの改善を行う必要があっただけの話。

エンジニアの知的生産術でも書かれていたけど「読書は手段、目的は別」、特に技術書や実用書は。 小説の場合は読むことによって目的が達成されるのでこの限りじゃないし、小説は楽しんで読みたいじゃんね。

エンジニアの知的生産術 -効率的に学び、整理し、アウトプットする-

読んだ。

この本を読んだ大きな目的としては4つ。

  • 技術書を早く読む技術の向上、もしくは問題の解決
  • モチベーションの維持管理を学ぶことでムラのある管理方法に一定の持続性をもたせる
  • 何を「いま」学ぶべきか?を論理的に行えるようになる学習効率の最大化を図る
  • 大学に入り直すべきか?という学歴コンプレックスに端を発する欲求に区切りをつける

更にいうなら、この中で重要視すべきは読む速度の向上とモチベーションの管理方法を改善するのがマスト、 なにを学ぶか?と大学に入り直すのは可能であればくらいの気持ちで読み始めた。

感想:

モチベーションに関する管理方法はまだ自分のなかできちんと根を張っていないように感じているが、その他の項目には一定期待した効果を得られたのではないか?と考えている。

モチベーション、つまりはやる気だがその管理の説明は一定納得する部分があるものの根源的にどうやる気を生み出すのか?の部分を解決してくれなかったのでそこを期待していたぼくとしては少々物足りなさを感じる結果となった。

ただ、その維持管理するための方法論や問題点に関しては概ね納得できるものが書いてあったので大きく外しているわけではなさそう。

良かった点:

  • 遅延評価的勉強法ができていないことに気づけた
    • 評判だから、流行っている技術だから、タイトルがキャッチーだからで買ってしまう技術書が多すぎたことに気づいた。
    • いま必要な技術以外に興味を持つのはいいが、数を厳選しないなら単に集中力が分散してしまっているだけになっていると気づけた
  • 読む速度が遅い原因は脳内で音読してしまっていたため、その速度に引きづられてしまっていた
    • 音読する速度以上にならない、小説であればそれでも問題ないが技術書でそれを行う意味がない
  • 今読んでいる本が全て理解しながら読み進めるのがよい技術書とまず全体に目を通してわからないところだけ何度も読み直す技術書のどちらか?というのを気にする必要があることに気づいた。
    • エンジニアの知的生産術は後者だと個人的に思っている。
  • 読んでいる、もしくは読もうとする技術書が「閉じている」本なのか、「開いている」本なのかで読み方を変える必要があることに気づいた。

いまいちだった点:

  • やる気に関する期待したような解答がなかった。
    • ただ書かれた内容がピンポイントで解決してくれなかったからといってその中身が有用でないわけではないが物足りなさを感じた点としてしこりを残した。
  • 説明としては必要と判断されたのだろうけども少々迂遠すぎる説明がところどころにあった
    • あれは省略してもよかったのではないか?という気がしている。

まとめ:

全体的に読むための技術とその際に注意すべき点は大きく改善された、もしくは改善できそうだと感じられた。 但し、やる気に関してぼくが期待したポイントはこの本では示されていなかったため、具体的にどうしなければいけないのかを自分で考える必要がありそう。

これを読むタイミングとしては最も最適なのは実務に関わるようになって半年〜3年目くらいに読むのが一番刺さるんじゃないかと思う。 会社に1冊あると興味がある人が勝手に読むんじゃないか?という気がするので、個人で所有するよりはどこか不特定多数の人が読めるところに置いておきたくなる実用書だった。

ぼくは何度も辞書のように読み返したり、個人的に重要だと感じた書籍は紙媒体で持つようにしているのだけど、そういう文脈でいうとこの本は電子書籍でほしいなと感じた。 重要でない、というよりは読んだ文章に対してメモを書き込みたいという意味あいが強いのと、なにかあるときにふと読み返せるようにしたいという2つの意味で電子書籍版を期待している。

ユーザーストーリーマッピング

ユーザーストーリーマッピング

ユーザーストーリーマッピング

読了した。

会社で、というかぼくのプロジェクトの進め方やヒアリングの仕方などに問題があって渡された感じ。

「課題図書じゃん!w」って言ってたけど本当に課題がてんこ盛りって感じで学びがあった…。 俺はなにもわかってなかった…みたいな気持ちといままでどうやればいいのか取っ掛かりがなくて途方にくれていたけどこうすればいいのかーという気づきを得られた。

感想

属人性がはっきり分かれそうな本なのでおすすめしにくい。

ただいまの時点のぼくにはいろいろな手法や考え方、プロジェクトの進め方なんかを学ぶところが多くて割と良かった。 章立てのサイズがいい感じなので夜寝る前にちょっと読む…みたいな感じでもスラスラ読めていった。

ただ後半が少しなんというかいまいち得心がいかないというかスッキリしないものを感じていたので多分これは自分の中に違和感があったからだろうと思う。 そういう意味では前提となる知識や経験がまだ必要とする水準に達していないか、そもそもぼくにはその手法はあわない…みたいなところじゃないかと想像している。 半年後くらいに読み直したらスッキリしなかった部分が解消するかも?くらいに考えている。

目的:

今回、課題図書として渡されたと書いたんだけどもこの本を読むことで解決したい目的が大きく3つあったと考えている。

  • ヒアリングすることの意図を理解すること
  • 何故それをするのか?を考えること
  • 大まかに全体像を把握すること

実際には渡した側はこれよりももっと大きくて多いことを期待していると思うのだが直近で自分自身でもうまくできていないなと感じたのが↑の3つだったことと本著でそれらを解決するための手法を紹介していてそれが絶妙にマッチしたので多分そういうことなんじゃないかなーと思ってる。

ヒアリングすることの意図を理解する

よく居酒屋などで話されることだが「ヒアリングするのは伝言ゲームじゃない」というやつ。

まさしくぼくはこの伝言ゲームをしてしまっていてどうすればいいのか少し困っていた。

プロジェクトに対する理解が深まれば自然と解消するだろうくらいに当初考えていたのだが、結局それでは駄目できちんとロジカルに解決していくためになにをどう考えていけばいいのか?という話しをここ1ヶ月2ヶ月よくしていたように思う。

ぼくらの会社はスタートアップなので当然人の数が限られている。 なので、「この機能がほしい」「あの機能をこうしてほしい」と言われてもすぐに対応できない、というかどうしてもやらないといけないものがいっぱいある状態だった。

そこでぼくがヒアリングすることで「この機能を追加実装しなくてもここをこうすれば代用できますよ」とか「この機能は本当に使うんですか?それはどれくらい使うのですか?」みたいなことを確認したり、提案することを期待されていたと思う。 思うというか間違いなくされていたわけだがうまくこの期待ぼくは応えることができなかった。

期待されていることがわかっているのに自分がうまく応えられていないというのが歯痒く、正直この時期はちょっとつらかった。

  • これはぼくがいままでこういったことに不慣れだったこと。
  • そういうのを専門で行ってくれるレイヤー、営業職とかプランナーとかが存在していたのでその人達に多くの部分をおまかせしていたこと。
  • そのような経緯があった上での経験値が低かったこと。

そしてあまりそういうのが得意でなかったためこれらの学習を避けていたという問題がある。

本を読んだだけで改善するわけではないが意識することで少しだけ良くなったように思う。 もちろん、聞き手側が配慮してくれた面がかなりあるのは間違いないw

ただ少しマシにはなったかなと自分でも思っているので読んだ甲斐はあったのかなという気持ちがある。

何故それをするのか?を考えること

ヒアリングとかぶる要素があるんだけどもやはり機能というのは追加するのは簡単だけど一度追加してしまうと削除するのはその3倍以上苦労する。 まして人数がいない状態で「言われたから作りますね!」ということをしてしまうと際限なくタスクが増えてしまい、毎日徹夜しても終わらなくなってしまう。

なのでここの部分は上司にすごく指摘された。 本著でもこの点はしつこいくらいに書かれていて、ことあるごとにこれは何故やるのだろう?という問いかけがなされていた。

いわゆるMVPという考えなんだけども、どうやらぼくは少し思い違いをしていたことを理解した。

この例えは本著内でもされていたのだがいままでのぼくは「早く走るものを作って欲しい」と要望を受けたとき、まず最初に車を作ろうと考える。 そして車を作るためにはタイヤが必要でハンドルが必要だからブレーキとアクセルも必要で……etcetcと実装してきたわけだ。 そしてこの車が走るために必要なパーツこそがMVPだと思っていた。

ところがどうやら本著を読む限りにおいてそうではなかったということに気づく。 ここではいきなり車を作るのではなくまずは三輪車を作る、当然クライアントは怒るが次は自転車を作る、バイクを作る…ここまで来たらクライアントは少しだけ機嫌を直す。 そして、ここから車を作り始めるというのだ。

この話しのキモは「早く走るもの」という要望を受けたときにまずそれを満たすものこそが作るべきもので、それをいきなり完成図引いてバーン!と開発してしまうとアルファ版としてリリースするときに最初から車を作ろうとしてしまうとタイヤだけが存在するなんだかよくわからないものをリリースしなくてはいけないことになる(イメージの話ね!)

ところが三輪車であれば少なくとも前に進むなにかを作っていることになる、自転車でもそうだ。 期待値には達していないが少なくとも進む方向性があっているかどうか?という確認ができる。

ところが車を最初から作ってしまうと完成したときに「…実は水陸両用車がほしかったんだよね。ごめんね、だから作り直して?」という話しになってしまい大変時間を損してしまう…。

だからこそ最初に作るべきは三輪車であり、これこそがMVPだ!と書かれているのを読んで「なるほど、確かに思い当たるフシがある」と納得した。

つまりぼく、もしくはぼくたちは本当に作らないといけないものの自分たちで思う以上に姿が見えていなかったということだと気づいた。 そうするとつまり「何故それをするのか?」という問いが非常に重要になってくる。

クライアントは作りたいものの存在を理解していない。 そして開発者は作るべきものの形をそれが完成するまで理解できない。

だからこそ、何故それをするのか?という問いを作る前、同僚などからヒアリングするときに行えなくてはいけないのだ。

それが本著で得られた最大の気付きだったんじゃないかと思う。

まだまだできているとは言えないがほんの少しだけマシになったかなと思うところがある。

取っ掛かりは得たのでこのことを忘れずに自然と行えるようになるのがベター、忘れてそうだと思ったらもう一度本著を読んで思い出せばいいかなと楽観的な気持ちになれた。

大まかに全体像を把握すること

これは簡単だ。 そもそも大まかにでも全体像が把握できないとスケジュールが立てられないし、そもそも設計もできない。 全体像がわからなければ、影響範囲もわからない…それぞれが各々「ここが影響範囲だ!」と考えるものが影響範囲になってしまう。これは設計もスケジュールも同じ。

もし把握せずに設計をしたらどうなるか? 多くの考慮漏れ、不可逆的な変更をしてしまった箇所に対して変更が発生する可能性が高くなるだろうと思われる。

また考慮漏れ自体をなくすことは不可能だがそれが起こったときの影響範囲がわからない、という問題がある。 そして当然これらのタスクを網羅するスケジュールの期限はわからない…ということになってしまう。

そしてぼくはこれらの設計のミス、スケジュールのミス、影響範囲のミスの全てを行ってしまった。

なので「わからない状態で走り出さない」というごく当たり前のことをユーザーストーリーマッピングという手法を介して教えてもらったと思っている。

まとめ:

今回、正直なところ渡された当初はそれほど乗り気でなかったのだが読み始めてみるとなかなかに考えさせられ、反省させられるところが多かった。 特にこのユーザーストーリーマッピングの手法はぼくにあっているように感じたのも大きな点だと思う。 ぼくは優秀な人間ではないので頭の中でこれらのマップを描けない。

そこが優秀な人とぼくとの違いだと思っていたのだが、実はそうではなく脳内で描けないなら付箋紙に書き出して張り出せばいいのだという実に簡単な話だった。

今回本著を読んだことでいままで「なんとなくうまくいかない」と思っていたプロジェクトの進め方のどこに問題があったのか、どのようにアプローチすれば解決に迎えるのか?というのが知れたのは非常によい読書体験だったと思う。

読んだだけでは意味がないが今回は直近の失敗体験と本著内での失敗談が自分に重なるところが多かったのでアプローチの方向性も類似していたのかなと思う。

冒頭で書いたとおりこれらのことが当たり前にできる人は当然世の中にいっぱいいて、その人達には刺さらない本だと思う。 ただぼくは前述している通りさまざまな問題を抱えて、どう解決すればいいのかわからず混乱していたので非常によいガイドブックになったと思っている。

上司がなにを伝えたかったのか、どういうことを行いたいと考えていたのか?を追体験することができて上司に対する理解度が少し深まったし、今後どうしていきたいのか?という考えに対しても理解が深まったのではないかなと思う。

もしぼくと同じような悩みを抱えている人がいれば一度読んでみるともしかすると解決の糸口くらいにはなるかもしれない。

こんなこともやってなかったのかよ!とこのエントリだけを読んだ人は思うかもしれない。

そう、そんなこともやってなかったし、やれていると思っていたことが実は全然やり方を間違えていたのだということを知れたので一度手にとって眺めるくらいはしても良いのではないかと思う。 その上で「こんなの当たり前じゃん!こいつバカじゃねーの?」という方はそのまま閉じていただき、「あー似たようなことしてるぞ?」という人は購入して読んでみるともしかすると苦労しているところが一気に楽になるかもしれない。

問題の本質は勉強(努力)しているかどうかではないんじゃないか?と思うこと。

axia.co.jp

要約すると「プライベートで勉強しないひとがいても自由だけどその因果は自分で払うことになるよ」ということ……で間違っていないと思う。 間違っていたら読解力に難がある人間だったということだ。

この件で大きく気になったことが3つある。

  1. 勉強しない人はエンジニア(技術職)に向いていない
  2. プライベート時間をどう過ごしてもよい、がそれだとキャリアが行き詰まるよ!という主張
  3. アドバイスを求められたときのアプローチが正しくなかったのではないか?

以上、3つの内容を自分の中で整理するつもりで書き出してみる。

1. 勉強しない人はエンジニア(技術職)に向いていない

エンジニア、もしくは技術職に向いていないかどうかというより多分会社組織で働くこと自体に向いていないということではないかと思う。

あいつら働かない!というとよくやり玉に上がるのが公務員だろうと思う、特に地方公務員がその先鋒だろうことが多い。 彼、彼女らは比較的決まったルーチンを決まったとおりに実行し、行政が滞りなく動くよう働いている(はずだ)。

では彼らは決まったルーチンをこなしているので勉強していないのだろうか? ぼくはそうではないと思う。

単純にソフトウェアエンジニアやデザイナーのように目に見える成果が出にくいだけで彼らも勉強しているのではないかと思う。 勉強をしない、を言葉のまま受け取る場合、それは知識のアップデートが行われないだと思う。 であれば条例や法令というのは毎年変わるし、行政のトップが変わることで対応が変わるケースもある。 であれば、彼らも勉強をしていると言えるのではないかと思うわけだ。

なのでそもそも働くということは学び続けるということだと言い換えて相違ないと考えられる。 であるならば「昔とった杵柄」を後生大事にしている人はそもそも働くこと自体に適正がないのだろうというのがぼくの思うところである。 ちなまなくてもわかっていると思うが、働くことの適正はなにも自学するだけではないし、ぼく自身も働く適性は恐ろしく低いと思ってる。

なのでこの件は「勉強しない人はエンジニア(技術職)に向いていない」ではなく「勉強しない人は働く適性が低い」が正しいと思う。 あとこの手の話題がでるたびにTwitterなどで勉強という言葉がよくないのではないか?という意見を見かけるがぼくも全く同意見である。

なんというか勉強という言葉の持つイメージがあまり適切でないかなという気がしている。 努力とかもっとそういう系統の言葉が正しいんじゃないかなー?

会社組織は成果で社員を評価するわけだから件のA氏がとてつもなく優秀で才気溢れる英邁であったのなら努力や勉強をしなくても昔とった杵柄の預貯金だけで戦っていけたのかもしれない。 ところがA氏は残念ながら一般のレベルを逸脱するものではなかったので期待した結果にならなかったということだろうと思う、無念。

2. プライベート時間をどう過ごしてもよい、がそれだとキャリアが行き詰まるよ!という主張

この社長、端的にいってぼくはいけ好かないと感じているのだけど今回も同じ感想を抱いた。 まあそれは個人的感想なのだけど。 ただそう感じるのにも一応理由があって「プライベート時間をどう扱ってもよいですが相対的に勉強しないと評価が下がりますよ」ということに近い発言をされている。

まあ別に間違ったことを言ってるわけではないのだけどこのA氏を雇うときにきちんとこのことを伝えたのだろうか?というのが非常に気になった。 残業ゼロ大いに結構。

でも採用時に「プライベート時間で勉強することを多少なりとも期待しているのでそれがないと相対的な評価が下がることになるけどいいですか?」と伝えていればA氏が無駄に苦悩することはなかったんじゃないかなー?という疑問がある。 そしてなによりもそれは暗に「プライベート時間で勉強をしてください」と言ってるようなものではないか?と感じる点だ。

もしそうであるならば残業ゼロに釣られて有象無象がよってくることによる弊害というような分析はそもそもが間違っているのではないか?ということとそれは大変失礼でかつ不誠実な対応ではないかと思うということだ。 このあたりがぼくがこの社長をいけ好かないと感じる大きな要因なわけだけども。

普通のエンジニアならプライベートな時間を使って勝手にどんどん勉強していきます。

ぼくは技術職しか経験をしていないので他の職種に関してはわからないのですがこれが世の中のスタンダードではないと思いますよ。 またこういうことを思っているならそれはプライベート時間で学習しスキルアップすることを期待しているということなのではないですか? だとするとそれは言ってることと矛盾していませんか?ということが非常にこのエントリが賛否両論をよんでいる所以ではないかと思います。

ぼく自身は「自分が天才であると自惚れられない程度の才能しかなければ自学するしかない、それすらできないならソフトウェアエンジニアを目指すのはミスマッチだと思う」と考えており、 このエントリが主張するところに近いものではあります。

ただプライベート時間をどうするかはあなたの自由です、という薄っぺらく感じる建前に対して不快感を感じているので多分同族嫌悪みたいなものなんだろうとは思います。

どんな職業でも学び続ける日々だと思いますがソフトウェア業界は特にその速度が早いので昔とった杵柄の前提条件がガラリと変わってしまう。 あるいはより簡単ですばやくできることを求められるようになるのでそれが嫌だと少しでも思うならやめておけということです。

会社の経営者としてはそれでは社員がなかなか増えなくて困ることがあるのかもしれませんが。

3. アドバイスを求められたときのアプローチが正しくなかったのではないか?

そもそもA氏はプライベート時間で勉強をしたくないと主張しているわけですがA氏は一体プライベート時間になにをしていたのだろうか? そして何故技術職であるエンジニア(恐らくソフトウェアエンジニアと思われる職種)を希望したのだろうか?

もしかするとA氏は弁護士免許を取得するために勉強をしていたのかもしれない。 いやいや海外で働くために英語の勉強をしていたのかも知れない。はたまた社会人大学生になるために勉強をしている可能性もある。

あるいは家族に要介護者がいるため、プライベート時間を自由に使えないことも考えられる。 もちろん、それ以外にも単に遊びたい!ひたすら読書にふけりたい、趣味で漫画や小説を書いているなどというものもあるだろうと思う。

それらを踏まえたうえでこの社長はA氏にアドバイスしているのだろうか?というのが非常に気になった。 というのもよほど才能があってもプライベート時間に学習をしなくても周りの成長に追いつかれない人というのは稀だと思う。

そんなことは自明だろうと思うからだ。 であるにもかかわらずA氏はプライベート時間での自学、スキルアップを拒否している。 文章を読むにここまで強固な意思であるならば、恐らく採用時点で明言するしないは別にしてその片鱗を語っている、感じられたのではないかと思う。

まして研修を行ったと文中にあるからにはおそらくは未経験、あるいはそれに近い状態であったと推測される。 であるならばそのことを踏まえてアドバイスした内容が↓だったのか?という気がするのだ。

そこで私は「成長したかったら勉強するしかないんじゃないか?」と普通のことを言いました

これは一部分を抜粋しかのかもしれないけどもA氏が成長に伸び悩み、かつプライベート時間を使っての学習が難しいと仮定したならば 彼、もしくは彼女が期待したのは「業務時間を使った学習時間の確保」だったのではないだろうか?

これは非常に難しい、でも実現できないことはないとぼくは思う。

例えばいま扱っている仕事を1時間、もしくは30分早く終える方法はないか? そうすればこのエントリにある毎日30分の学習時間が捻出できる、A氏はそういったことを期待したのではないかな?と脳内で思い描いていた次第だ。

残業ゼロを目指すというのは残業をしないという数字上の目標を達成するのではなくこういうアプローチを重ねていくことでより効率の良い業務を行うということだとぼくは考えているので なんというか「プライベートで勉強するしかないんじゃない?」というアドバイスはA氏のことを見限ってしまっているように感じられた。

ということで勉強をさせることがアプローチとして正しかったのではなく、如何に業務時間で学習する時間を捻出することができるかを考える。 あるいはそのためにはどうすればいいのかを考えさせるのがアプローチとして妥当だったんじゃないかなというふうに考えていました。

まとめ:

まあそもそも論なんですが会社組織は社員を成果で評価するわけでA氏がきちんと成果をあげているかどうかが重要だったんじゃないかと思います。 人それぞれなので成長なんてしなくてもいい、日々生活するだけのお金がもらえて眼の前の仕事をただこなせればいいという人もいると思いますし、それはそれでいいんじゃないですかね?

ぼくが同僚なら殺したくなるくらいに殺意が湧くので絶対に一緒に働きたくないですが、日々の仕事を卒なくこなしているならばその限りではありませんが。

ただそれを正当に評価できていればいいだけで、勉強するかしないかというのはただの手段の問題だろうと思います。

結果が全てとはいいませんが成果をあげるために勉強したり、努力したり、苦悩しているわけで勉強をするかしないかという軸で議論するのは本筋からズレた議論になってしまっているように感じました。

まあつまり採用をミスったとただの事実をこういうエントリを書くのはあまり関心しないなということです。 それよりは↓みたいなアプローチのほうが誰にとっても幸せであろうということです。

quipper.hatenablog.com

あー働きたくない!

働きたくない!!!

働かずにただ日々を無為に過ごして晴読雨読な日々を満喫したい!!!!!

追記:

最近↓が気になってるので誰かプレゼントしてください。

新・水滸後伝 上巻

新・水滸後伝 上巻

新・水滸後伝 下巻

新・水滸後伝 下巻