おれたちはふいんきでリモートワークしている

副業がほぼリモートワークっぽいなにかなんだけどそこで得た知見とかを書き出しておく。 リモートワークに興味があるひとは参考にするなり、踏み台にするなりご自由に。

なおリモートワークに関してよくまとまってるなーって最近思ったのが↓なので先に読んでおくと幸せになれるかもしれない。

daiksy.hatenablog.jp

portalshit.net

という退職エントリで少しだけリモートワークに言及しているんだけどコレ読んでまず最初に思ったのが「リモートワークって実は才能とかじゃなくてスキルだよな」ということ。

もちろんリモートワークに向いている性格のひとっていうのは少なからず存在すると思う。 なので↑のエントリが間違っているわけではないと思ってる。

ただ才能というか属人性の高いものなのか？と言われるとそれもちょっと違うかなと思っていて リモートワークをする能力というスキルが不足している、というほうが個人的にしっくりくるので最近は「リモートワークはスキル！」って言い張ってる。

あと本当に数日前に気づいたことなんだけどもリモートワークは実は働き方ではなくて福利厚生的なものなのではないか？と考えるようになった。

そのきっかけを作ったのが↓

リモートワークをはじめよう from MILI-LLC

www.slideshare.net

このスライドでは「チームのQOLを上げるためのもの」と紹介されていてふと 「職場に自販機があるとか職場のオフィスチェアが高級椅子だとかに通じるものがあるなー。( ﾟдﾟ)ﾊｯ!そうか詰まるところリモートワークは福利厚生の一環だったのだ！」 みたいな天啓を得ました。

多分間違ってるけどいまのところ一番自分のなかで得心を射ているのでこれでいいのだ。

で同じくこのスライドで「リモートワーク=自分の好きな時間で働くという考え方をしない」というのがあってここを勘違いしてしまうとリモートワークはつらいなと感じています。

どんな職業でもある程度共通すると思うんだけどやはり複数人でチームを組むとなると完全に分業というわけにはなかなか行かないことだと思う。

これはもしかしたらというレベルの話しなのだけどフリーランスにおけるリモートワークと会社としてのリモートワークは全然別物でリモートワークに失敗する理由の1つはここを勘違いしているからなんじゃないかなと思うようになった。

こんなこと書いたらフリーランスのひとにめっちゃ怒られる気がするけど言いたいこととしては個人とチームのリモートワークはそれぞれ別なんじゃないか？ということが言いたい。 ただその個人を表すのにパッとイメージされたのがフリーランスだったということであって他意はないです。

個人的にリモートワークをして考えが変わった点として「オフィスでチームが集まって仕事してるならリモートワークすることによるメリットはぶっちゃけギョーム的にはそんなにない」というのがある。

それはそれとして今働いている会社でリモートワークを導入してほしいなとは思っている。

なんでかというと今の会社は通勤で疲弊することがほぼない(自転車通勤でおよそ30分ほど)んだけど やはり副業をやっているとその通勤時間ですらも短縮したいかったり日本に住んでいるとどうしても台風や大雪などの自然災害は避けられないしそんなときほど電車がクソほど混んでいて疲弊して出勤、そのあと8時間働くとか正気の沙汰じゃないと考えているからだ。

本当ならそういうときだけリモートできればいいんだけどいざそのときになるとなかなか環境が整っていなくてストレスが溜まることになると思う。 というかぼくはなった。

なので平時からそれらを行っておくことで突発的な対応に対処できるようになっておくべきだろうと考えているからだ。 あと社員旅行とか海外旅行にいくときに普段からリモートで仕事が出来る体制が整っていれば突発のアラートにも対処しやすかろうという心理的安全性を確保できるので長期間の休みを申請しやすくなると個人的に思ってる。

最後にいままでオフィスに全社員が集まる形式で働く環境にリモートワークを取り込もうと考えているひとへ。 恐らくリモートワーク導入直後は効率が落ちると思います、その原因はチームごとに違うので一概には言えませんがリモートワークを導入するとほぼ間違いなく最初効率が激減します。

元々リモートワークをしていたひとや慣れ親しんでいる環境であれば問題ないですがなにかしらの問題が噴出するため日々KPTを回してなにが悪くてどう改善し、今後なにを継続すべきなのかを常に考えることが肝要です。

以前 id:soudai 氏と「リモートワークがない環境にいきなりリモートワークをぶっ込むとだいたい破綻するよね！」話してたので参考にしてください。

この効率が落ちるのもやむなしと考えれるかどうか、許容できるかどうかが結構重要な因子じゃないかと思います。

なんのためにリモートワークするのかがきちんと芯を得ていないと多分失敗することになると思います。 時短勤務やフレックスタイム制を導入するのとは難易度が全然別物なので注意したほうがいいと個人的には考えています。

取り留めがないけどもいいたいことはだいたい書ききったのでこれからリモートワークを自社に取り込もう！という人はぼくの屍の上に築いてくださいな。

齢30を越えてようやく気づいたWebエンジニアの勉強に関するベストプラクティス

…を書こうと思っていた矢先に↓が投稿された。 しかもぼくが書こうとした内容よりも理論付けられていたり、充実した内容だったり、深掘りされてたりして非常に良いのでこれ読めばだいたい終わるし書かなくていいじゃんね！ってなった。 完。

employment.en-japan.com

これを読んだあとで「あーこんな良いエントリあるならぼく書かなくてもいんじゃね？っていうかぼくも知らない内容書かれてて充実度で完敗だし書く必要性無くね？？」とか思って書かないでおこうかと思っていたのだけども 別にぼくが似たようなことを書いてもPV数やまとまっている内容の充実差で件のエントリに微々たる影響を及ぼすこともなかろう、あと単純に書いて頭の中を整理しておこうと思い直したので今書いてる。

タイトルは元々の主旨なのだけどそれは↑を読めば満足できると思うのでこのエントリはそこからちょっと外れているものを書いておこうと思う。

ぼくの「これがあかんのやぞ！」とかを列挙して自戒を見える化のログとするのが目的に急遽変更する。 なので多分考えをまとめるとかすっ飛ばしていきなり書いてるので支離滅裂なことになっている点に注意してもらいたい。

パラシュート勉強法

ぼくは恥ずかしい人なのでこのパラシュート勉強法なる呼称を知らなかったのだけど最近自分のできる技術的な範囲を広げたい、広げよう！と思ってパーフェクトRuby on Railsの初版本を片手に写経していたのだけどこれがかなり難航していた。

パーフェクト Ruby on Rails

理由としては単純でこの書籍が刊行された当初のバージョンがRails4.xを基準にしており、最新の5.xでは動かない…みたいなことが多発したというだけだ。 とはいえコードの部分ではなくgemのインストールやライブラリの依存関係など解決したい問題の本質以外の部分で大いに煩わされていてストレスフルなので↑の書籍を買おうか悩んでいるかたには現時点ではおすすめできない。

第2版が出て最新のRailsやRuby、gemなどに対応してくれたら検討する候補にあげてもいいかもレベルだと思う。 不満な点でいえばGithubなどに書籍のサンプルコードをおいてくれていないのでRailsの変更があったのでここを直さないと動かない！みたいな部分のサポートがないのが非常に不満だった。

蛇足だが、この手のサポートはGo言語によるWebアプリケーション開発が非常に良かった印象がある。 Githubに掲載されているコードがあって書籍との差異を検知できる仕組みがあったので非常に良かった。

今後買う「書いて覚える」系の技術書はこの手のサポートがあるかないかを購入基準にするのがベターかもしれないなあと思ったりなんかした。

Go言語によるWebアプリケーション開発

PHPはこの辺後方互換がかなり考慮されているので、技術書に書かれているレベルのものであまり困ることがなかったのだけどRailsはJavaScriptほどでないにせよ変化の激しいものがあって初学者には書籍で学ぶのが難しいと感じることとなった。

「公式チュートリアルを写経」にしておけばよかったといまは後悔している。

railstutorial.jp

そんなわけなので「まず自分が作りたいアプリケーションを実装していってわからないところがあればそこだけググったほうが早いし理解度あがるんじゃね？」的なことを考えていた。 先のエントリ紹介されているがそれをパラシュート勉強法というらしい。

「超」勉強法

何故最初からそうしなかったか？ この手法では単純に体系的に学ぶことが出来ないからだ。

ぼくもエントリを書かれた方と同じく大学でコンピューターサイエンスを専攻していたわけではないので非常にわかるのだが、体系的に学ぶ強みというものがある。

これがあるため「最初は遠回りに見えても最終的に体系的に学ぶことが最短なのではないか？」と考えるに至ったので今回は書籍を一からなぞるという行為を選択した経緯となる。 そして「学問に王道なし」という言葉があるように恐らくは体系的に学ぶことが出来る以上の効率の良い学習方法はないとぼくは考えている。

ところが結果だけみるとこのパーフェクトRuby on Railsにおいてはそれはあまり正解ではなかった。 基本的にはこのアプローチで間違いない。

ではなぜぼくが失敗したのか？というと一次ソースを当たらなかったことが原因だろうと思う。 これは件のエントリでも書かれていて非常に耳が痛い内容だった。

重要なのは「実際にLinuxを触る前からコマンド一覧をひたすら眺める」とか、「単純なルーティングも設定したことがないのに『マスタリングTCP/IP』を読みはじめる」 というようなことを一切しないことです。 必要なピースを拾い集めながら、知識のマスを少しずつ埋めていきます。上記でカッコ書きしたようなことは、勉強の初期段階よりも、学習が進んでから全体の横串を通すときに行ったほうが効果的です。

この一言でほぼ言いたいことがまとまってたので引用させてもらったが改めて端的にまとまっていて良さを感じる。 他にも遅延評価的学習方法は個人的には若干疑問視する部分があって完全には同意していないけど「必要になってからやる」「やったら徹底的にやる」は真理だと思ってる。

閑話休題

ところでこのパラシュート勉強法という命名がぼくには非常にユニークで面白く感じたので一応補足的に書いておこうと思う。 これは件のエントリには書かれていなかったのだ！(ﾄﾞﾔｧ

以前バズってくれたエントリリーダー(管理者)ではなくエンジニア(実務者)でありたいと願う人々へで紹介したElastic Leadershipに書かれていたことなのだが「学習フェイズにおいて挑戦的課題が重要だ」と述べられている。

挑戦的課題とはなにか？

• 不安を感じる
• 挑戦するのに勇気がいる
• リスクがある
• 類似点はあるがその時とは違うと感じている(悪い意味で)

乱暴にまとめてしまうならば、これらの要素を兼ね備えたものが挑戦的課題だ。 これらは全て「信頼を損なう」「力量を低く見積もられる」「自分の底が露呈してしまう」などの心理的安全性の外側に踏み出していることで初めて実感するものであり これこそが成長には絶対的に必要なものだと書かれている。

逆にこれらの不安要素が含まれない学習は学習したつもりになっているという旨が記載されている、課題ではあっても挑戦ではないという意味だと認識している。 著者はこの状態を「安全領域から一歩踏み出す」というような表現をしているのが面白い、体感的にも成長が飛躍的に向上したときはこれらの挑戦部分を克服したときであることが多かったなあと思う。

この件がどうパラシュート勉強法の命名がユニークであることと繋がるのか？だがパラシュートというと一般的には遙か上空の彼方から身一つでアイキャンフライしちゃう頭のおかしいスポーツだと思う。

そのときに感じることはなにか？ ↑の不安要素を内包しているんじゃあないかとぼくは考え、このパラシュート勉強法という命名が非常に端的に成長するために必要な学習要素を含んでいるように感じたというだけの話しなんだけどね。

実際にそれらを意図しているかどうかは不明なので勝手に妄想して「おおこれは言い得て妙だぞ！」と感心したよと。

恥ずかしいことを隠さない

ぼくの知人に id:otiai10氏という方がいる。 このひとをぼくは非常にすごいなと思っていてその理由が「恥ずかしい勉強会」というものを開催しているのだ。

hazukac.connpass.com

これってすごいことだと思っていて「今更聞けないけど知っておきたい〜」みたいなエントリが定期的にはてブには流れてくる。 これらを読んで満足しているひとはぼくも含めて多いだろうと思う。

そこから更に一歩踏み込んで「ぼくはこれを知らない恥ずかしい人なのだけど恥ずかしいからこそ学ぶぞ！」みたいな精神は見習うべきものがあるし、なによりそれを実行できる勇気がすごいなと感じている。

なので最近ぼくも真似をしてQiitaに恥ずかしい話しを投稿したら速攻でアドバイスやフィードバックが返ってきて自習ではなかなかこういったフィードバックは得にくいし恥ずかしい話しはもっと公開すべきなのではないか？と思った次第。

恥ずかしいことを隠しても問題が秘匿されるだけで技術力の向上には1mmも貢献しないが恥ずかしい話だぞ！って予防線貼れば対象読者も「ああこれは恥ずかしいやつの書いたことか」と思ってくれるかもしれない。

心理的安全性を確保しつつフィードバックによって技術的な知識や知見を得られるのでもっと早くに恥を晒してればなーって思った。

技術力以外の恥なら晒し放題なくせにチキンなので日和って損してたなーと改めて思いましたまる

本を買って満足しない、本を読み切って満足しない

はてな社員の誰かがいってたけど「手を動かしたやつが一番エラい」は真理。 本を買っても、ただ本を読みきっただけでも技術力の向上には1mmも貢献しないのだ。 手を動かして真に頭で理解することが重要、書籍はそのための案内板のようなものだと思おう。 勉強会に参加も然り。

本業以外でスキルセットを磨く場を作る

これは万人向けってわけではないのだけど本業以外にスキルセットを磨く場を設けておくとパラダイムシフトが起こって点と点、線と線が繋がりだして学習速度が飛躍的に上がるように感じたぞ！って話し。 僕の場合は副業がきっかけだった。

副業をはじめてどういう点で変わったのか？ まず時間に対する概念というか考え方が大きく変わったように思う。

時間のやりくりやスイッチングコストが大きいことがどれだけ問題か？がようやく理解できた。 平日の夜に自宅に帰ってから副業にジョインするのでどうしても残業が出来ない(しない)、少ない時間で成果を出せる実装をしないといけないなどの自己制約を課すようになった。

それまでは本業で「このタスク定時までに終わらんかったけどあと1時間残業すれば終わりそうだなー」とか軽く考えてた。 「残業は悪だ」みたいな基本思想は元々あったんだけど悪とか正義じゃなくて終わらないと副業先に迷惑をかけることになるのでなんとしても終わらせる！！！みたいな方向に考え方がシフトした。

あと「本業+副業」を行っているためどうしても自分の学習にかける時間が激減する。 本業にせよ、副業にせよお金をもらっている以上そちらを優先するのは当たり前なのだけど、エンジニアとしては日々技術力を磨かないとぼくみたいなへっぽこ園児ニャアはおまんまの食い上げになってしまうと思うし、事実そうなるだろうなと日々感じている。

なので土日をかなり意識的に時間をとって自習にあてたり技術書を読む時間に宛ててるようにしている…んだけどこれがなかなか大変。 これは本業だけだと実感しなかった点で自分の時間の大切さを噛み締めてる、アニメみる時間とかゲームする時間が激減した。

「短い時間で如何に効率よく学習できるか？あるいは如何にシャローワークを殺していくか」みたいなことを考えるようになった。 その結果として「Elastic Leadership」「イシューからはじめよ」「DeepWork」「GRIT」みたいな今まで読まなかった自己啓発系？なのかわからないけど書籍を読むようになった。

ある意味ではこれはいい転機だったのかなと思う、それによって今まで得られなかった、あるいは意図的に避けていた事柄に触れたり知ることが出来て少しだけ考えの幅が広がったように思う。

過去エントリでも紹介しているが一応列挙したものを再度あげておく、興味があれば読んでみるといいのではないかなとぼくは思ってる。

おすすめはElastic Leadershipとイシューからはじめよの2つ。 DeepWorkとGRITは興味があれば…って感じかな。

エラスティックリーダーシップ ―自己組織化チームの育て方

イシューからはじめよ―知的生産の「シンプルな本質」

大事なことに集中する―――気が散るものだらけの世界で生産性を最大化する科学的方法

やり抜く力 GRIT(グリット)――人生のあらゆる成功を決める「究極の能力」を身につける

これらのことから離れる時間を意識的にとる

人にもよると思うが技術だけではなくて観光したり温泉入ったり娯楽小説読んだりゲームしたりすることも時には必要。 ぼくは元々このあたりのスイッチングコストが大きくて下手だったので最近は意識的に土日のどちらかは必ずジムにいったり気になってた小説を読んだり買ったままになっていた技術書を読むようにしている。 あとたまにブログ書いたりブログネタを考えたりとか。

意識の切り替えが重要で本当に必要なときだけ集中するモードを養うことが肝要。

集中できる場を作る

人によるが自分がここなら誰にも邪魔されない！という場所を持っておくのが重要。 読書なら鴨川デルタ(近くにベンチが沢山ある、デルタから少し離れただけでほぼ確実に座れる)、コードを書くときは会社近くのスタバか烏丸御池近辺のスタバを愛用してる。 ↑のスタバ休日はほどよく人来ないし京阪三条にあるスタバと違ってほどよく長い出来るので大変助かる。 テラス席だと広々と使えるしだいたいヘッドフォンしてコード書いたりしているので騒音とかもほぼ気にならなくて捗る。 唯一のネックは電源だけど店内なら電源あるので最悪一定時間だけそこから拝借する。

継続性を持つ

自分でこれくらい出来るだろ！と思うのからちょっと少なめに見積もるようにしている。 例えば英語の学習をしようとして1日2時間！とかいきなりぶっ込むとだいたいどこかで詰む。 なので寝る前の30分だけ！とかかなり緩めの条件に設定する、人間は怠け者なので恐らくはコレですらサボる。

…サボるがたった30分だし！と思えるかどうかが個人的に重要かなと思ってて2時間だとその分を取り戻すべく翌日分に追加するとその分の時間を確保できなくて心折れてやらなくなる。

出来ると思ってやったことが出来ないと心が折れてやらなくなるのは万国共通なので条件は緩めにする。 物足りないと感じたら増やす方向で今のところちょうどいい塩梅。

あと重要なのが出来ない場合のリカバリー方法。 必ず翌日にもっていくと溜まったときに心折れるので週の最低ラインを設定して最悪それを超えていればOKという風にぼくは調整した。

このあたりは属人性が高いので話半分くらいで聞いておいて欲しい。

まとめ

もっと早い段階でこれらの学習方法に気づいていればもう少しマシなエンジニア人生を送れたのかなーと思うけども現状よりも悪化させないためにも今後も継続してやっていこうと思ってる。

イシューからはじめよ―知的生産の「シンプルな本質」

イシューからはじめよ―知的生産の「シンプルな本質」

鴨川で半裸になりながクッソ熱い中、読了した。 本日は良い天候に恵まれました。

一般に「イシューとはなんぞや？」と答えれるひとは恐らく半分くらいじゃないかと思う。 かく言うぼくもイシュー？ああgithubにあるissueのことね？課題とか問題とかそんなんじゃねえの？？？と思ってた。 この本ではイシューとはそのようなものとは全く別次元のものとして扱われている、この点を勘違いしてしまうと本著は非常に退屈なものになってしまうだろうと思われる。

本著のおよそ7割はそのイシューについて語られているといっても過言ではない。 万言を費やす価値があると著者は考えたのだろうと思う。

然るにぼくはというとはっきりいってまだイシューが理解できているとは到底言えない状態だと明言する。 これは本著が悪いというわけではなく本著の最後に書かれている↓が全てを物語っていると思われる。

結局のところ、食べたことのないものの味はいくら本を読み、映像を見てもわからない。自転車に乗ったことのない人に乗ったときの感覚はわからない。恋をしたことのない人に恋する気持ちはわからない。イシューの探求もこれらと同じだ。

イシューとはなにか？

本著のおよそ7割を費やして語られているであろうイシューとはなにか？ もしかしたら著者の考えているイシューとはズレてしまっているのかもしれないがぼくは「本当に、どうしようもなく解決すべき問題、またはその本質的な課題」だと理解した。

ぼくは自転車にのってダラダラと走っているときにしばしば「人類は何故ここまで繁栄しても戦争をやめることができないのだろうか？」とか「学問というものは本質的になんであるか？」といった漠然とした問いを頭の中だけで展開することがある。 だいたいその直前などに目にした大きな社会情勢を考えることが多いように思う。

ぼくにとってはこれは頭のスイッチ切り替えを行う儀式のようなもので問いそのものに意味があるわけではないのだがずばり本著でこのことに言及されていて驚きと少しの理解を得ることが出来た。

曰く、

僕の考えるこの2つの違いは次のようなものだ。 「悩む」=「答えが出ない」という前提のもとに、「考えるフリ」をすること 「考える」=「答えが出ること」という前提のもとに、建設的に考えを組み立てること

最初この文章を読んでもいまいちなにを言っているのかわからないなあと感じていたのだが読み進めていくうちになんとなくまだまだ感覚的ではあるがわかってきたような気がしてきた。 ちなみに読んだ当初のメモによると「個人的に「考える」は論理的に問題提起と解決を模索することだと思う」と書かれている。今は少し違う。 何故違うのかは後述したいと思う。

バリューとはなにか？

知人や素晴らしいとぼくが感じている幾人ものエンジニアのひとが「バリュー」という言葉をまれによく口にされている。 これを聞いていた当初と本著を読み終えたあとではその言葉に対する重みが全然変わってしまっていることに気づいた。 バリューを求めるにあたって↓の方程式を理解していないと通じないと思うため引用させてもらう、どうもこの方程式は有名らしいがぼくは知らなかった…恥かしいことなのだろう。

生産性 = アウトプット/インプット = 成果/投下した労力・時間

ぼくは今まで「バリュー」とは「質の高い仕事」であると認識していた、たまたまなのかバリューという言葉が内包する範囲が大きいためかその文脈で読み解いても特に不自然さを感じることがなかったためそうなのだろうと勝手に思い込んでいた。 ところが本著ではさはあらじと一刀両断に切り捨てている、曰く「それはバリューを質に言い換えているだけだ」と。ズンバラリン。

本著によるバリューとは「イシューの質」と「解の質」この2軸が高い水準であることだと説明される。 このことは縦軸が解の質で、横軸がイシュー度というマトリクスで表現されている。

この説明だけでは抽象的で恐らくなんのことかわからないことだろうと思う、安心していいこの本を最初読んだときぼくもそうだった。 今は違うか？どうだろうか、まだ抽象度が高いように自分では感じている。だけれども読んでいた当初よりはその言葉の意味を理解できているようにも感じる。

そして最もぼくがこの章で重要だと感じたのが次の1文だ。

ここで絶対にやってはならないのが「一心不乱に大量の仕事をして右上(高いイシュー度)に行こうとする」ことだ。 「労働量によって上(高い解の質)にいき、左回りで右上(高いイシュー度)に到達しようとする」というこのアプローチを僕は「犬の道」と呼んでいる。

このことに対して心当たりがある人も多いのではないだろうか？ 少なくともぼくには心当たりが多すぎるほどにあった。

ぼくは優れたエンジニアではない、だがしかし優れたエンジニアになりたいと思っておりそのために「技術書を読み」「コードを書き」「カンファレンスや勉強会でさまざまな刺激とエッセンスに触れる」、そういった数による方法で目指すべきエンジニアになろうと考えていた。 まさしく「犬の道」だ。

いやそれは違う！という方もいると思うが少なくともぼくにとってはぼくが取っていたこれらの行為は「解の質」を上げるための行為だと自覚してしまった。 他の人もそうであるとは思わない。 ただぼくの状態に関していうのであれば「何故自分が優れたエンジニアではないのか？そのために必要なものはなにか？」を突き詰めるべきだったのだという厳しい現実を目視せざるを得なかった。

これこそがイシューの質であり、本来この質をあげることが最も理にかなっていたのだがぼくはそこから逃げ出したのだ。

そしてその逃げに対する負い目があったこと、ぼく自身が解の質をあげることに対して楽しみを感じる性格や性質だったために変にハマってしまっていたのだと思う。

ところで何故これらの行為が「犬の道」と呼称されるに至ったのだろうか？とぼくは思ったのだけどこれもまあ「悩む」という行為なのかな。

仮設ドリブン

とはいえこれらのことは言葉こそ違うものの似たようなことは自己啓発系の書籍などでも書かれているのかもしれない。 ぼくが本著を特別足らしめているのは以下の1文によるところが大きいのではないかと考えている。

「このイシューとそれに対する仮説が正しいとすると、どんな論理と分析によって検証できるか」と最終的な姿から前倒しで考える。

言葉にすればたったこれだけの話しなのだが、ぼくは今まで多くの人もそうなのではなかろうかと思うが以下のような考え方をしてきた。

• 「Aという問題がある」
• 「Bという仮説がある」
• 「Cという分析結果がある」
• 「故にDだ」

ところが前述されたものはそうではなく「Bという仮説がある」だとすると「Cという分析結果が必要」であり、それによって「Dという結果」に持っていけるか？という意味合いだとぼくは読み取った。 これはぼくにとって思考のパラダイムを巻き起こした。 これこそが イシューとは何か？ で後述するに至ったものだ。

つまりここの例を借りるならば「Bという仮説が成り立つ」と言う前提において「Cの分析」を行うこととなる。 この分析によって「Bという仮説」は成り立たなくともよいのだ、それは詰まるところ新しい発見であり新たな仮説の誕生であると考えることができる！と本著では紹介されている。

ちなみに本著でも書かれているがこの考え方は別に 「結論ありきである」というわけではない ので、その点にだけは注意してもらいたい。

まとめ:

イシューとはなにか？つまるところこの本はそれを問い続けている。 本著で書かれている内容は全ての職業、現場で当てはめることができるわけではないと思う。

ただ知的労働という時間という制約から自由になるためにはほんとうの意味での「問い」とその「解決策」が必要になる。 本著はそれだけを突き詰めているのだろうとぼくは感じた。

この本はマネジメント層に所属する人々に響くものがありそうだなと読了後に感じた。 Elastic Leadershipはぼく個人の直近の経験などからいろいろ明文化できないモヤモヤした部分に輪郭を与えてくれたが 本著ではまだまだ輪郭にぼやけたものを感じる。

これはぼくがまだこの本を読み、理解するに足るだけの実力がないのだろうと思う。 まさしく読むだけでは理解できない、手を動かせということだろうと思う。

いきなりはなかなか難しそうなのだが自分で出来る範囲からイシューを問い、イシューの質を向上させるべく手を動かしていこうと思う。

リーダー(管理者)ではなくエンジニア(実務者)でありたいと願う人々へ

「お前は向いていないんじゃない、やってないだけだ」

この一文を読んでほんの少しでもなにかを感じた人は是非とも↓の本を今すぐに読むべきだ。

エラスティックリーダーシップ ―自己組織化チームの育て方

本著はみんなが考え、感じているリーダーシップという曖昧模糊な概念に対して具体性をもたらせてくれる。 それは「チームリーダーの役割は優れた人材が育つのを助けること」と定義付けていることだ。 このシンプルである意味で本質をついている定義付けが本著を名書たらしめているとぼくは思う。

この本の構成は1部〜4部(おおよそ本書の半分ほどを占めている)までが著者によるリーダーシップとはなにか？3つのフェーズの分類とそのときに期待されるリーダーの振る舞い、あるいはチームの状態などについて語られている。 5部〜6部(残りの半分)は著名なエンジニアやコーチング、コンサルタントなどのエッセイなので特に興味がなければ読み飛ばしてしまっても問題はないだろうと思う。 章の数は全46章だが元々はブログかなにかを元にして出版物へと昇華しているためか1章1章の文章がそれほど長くない、さらさらと読み進めることが出来るだろうと思う。

エッセイ部分を読み飛ばすならば本腰を入れて読めば1日で読み終えることが出来ると思う。 どんなに読むのが遅い人でも毎日の通勤で1章づつ読んでいけば46日後には読み終えていることだろう。 ぼくは読みながらメモをとったりしていておよ8時間ほどかかったので読むことだけに専念すればその半分ほどの時間で読めたのではないかと思う。

評価した理由

ぼくが本著に対して高評価を下しているのは以下の3つの理由からだ。

• 3つのフェーズと各フェーズで取るべきリーダーシップのスタイルが具体的
• 別フェーズへと脱却するための目標や取るべき行動が明確であること
• 明日から、あるいはいますぐにでも使える技術であること

本著はぼくのなかにあったリーダーシップという概念を再構成してくれた。 それはなにか？これが3つのフェーズとそのリーダーシップスタイルにある。

リーダーシップとはなんぞや？

世間一般でリーダーシップを発揮するというと「みんなを引っ張っていく快活でポジティブな人間像」を思い浮かべると思う。 スポーツ漫画でよくみる野球のキャプテンやサッカーのキャプテンみたいな背中で語るだとか人情味で引っ張っていくだとかバリエーションはあるが基本的にはマッチョイズムな感じだろうと思う。 ぼく自身もそう思い込んでいた、だからこそそれがリーダーシップのただの1面でしかないということに気づいたときの衝撃はかなりのものだった。

本著では各フェーズにマッチしたリーダーシップのスタイルを紹介している。

フェーズ名	リーダーシップスタイル	補足とか
サバイバル	指揮統制型	一般的なリーダーシップのイメージ
学習	コーチング型	アジャイルコーチングとかが最近だと有名？
自己組織化	ファシリテーター	イケてるエンジニアリングの会社のCTOとかのイメージ

そして面白いのはこれらのフェーズはサバイバル→学習に移行してしまえば逆戻りすることがないのかと思っていたが実際にはそんなことはなくいとも簡単に自己組織化されていたチームがサバイバルチームに変化してしまう可能性があるという点だろう。 例えがうまいことを思いつかないが水のようなものをイメージすると良いのかもしれない。

蒸気→液体→個体とそれぞれ別の形態を持つがその元々は同じ物質(チーム)であると…うん、わかりにくい。本著を読めばわかるので例えがわからん！というのであれば本著を読んでくれ。

「彼が言いそうなことはわかってる」ゲーム

これは無自覚に直近で行っていたので非常に印象に残っているのだが本著の例文でAさんが「わたしはBさんにテストコードの書き方やその意義を説明したがBさんはそのことに対して理解を示してくれない。それどころか彼にはこのプロジェクトに関心がない、もしくは怠惰だ！」いう一文が紹介される。 これは意訳をしているが概ねこのような内容が書かれていたと思って欲しい。 この文章、皆さんも心当たりがないだろうか？ぼくには大いにある。

Aさんは確かにBさんに対して「テストコードの重要性」を説明したのだろう。 だがしかし後半の「Bさんはプロジェクトに対する関心がない、もしくは怠惰だ！」とする部分はただのAさんの憶測であり、いってしまえば下衆の勘繰りだ。

だが往々にしてこのようなことはチームで起こり得る。 ぼくが先日行っていたのは「この会議は意味があると思えないのでやめよう」と提案したところにちょうどBさんのように芳しい反応がない、あるいは反対意見が出たことがあった。 そのときぼくは「ああこの人たちは業務を改善することに興味がないのだな」と無自覚的に感じ、そういう人たちなのだと色眼鏡でみるようになってしまった。 実際にはぼくの場合興味がないというよりはその人たちにとっては意味や意義があると感じられた会議だったのかもしれない。 ところが関心がない、怠惰だという色眼鏡をつけると「ぼくは間違っていないが彼ら彼女らが協力してくれないのが悪い」という自己保身に走ることができる。

そしてこの問題の最も悪い点はそれが後々にまで響いてくるということだ。 チームとしてギスギスするところまで行かずともなにか新しいことをするとなったときに無意識的にか意識的にかは置いておくとしてそのメンバーを誘わない。 あるいは「でもきみは興味がないのでしょう？」というスタンスで形だけ誘う、というようなことが考えられる。

これは誰にとっても不幸な結果だと思う。 本著ではこのような事態に陥らないよう影響力チェックリストというものが紹介されている。 これは非常に客観的に状態を見える化することができる、素晴らしいチェックリストだとぼくは感じた。 直近で似たようなことを無自覚的であったとは言え経験したからこそ余計にそう感じたのかもしれない。

コミットメント言語

追記:
ブコメでコミットメント言語に関して「日本ではあわない」とか「お前いつまでにやるっていったのにやれてねえだろ！と劇詰めされる」とか「コミットメント言語でドン引きした」みたいなネガティブなコメントがあったのでちょっと訂正をば。

コミットメント言語が紹介されているのは学習フェーズでの紹介だという情報が漏れていたためにこんなコメントが増えたのかなと思う。

つまりコメントされているような心配があるということは漏れなくサバイバルフェーズであるわけで学習フェーズでそのようなことが起こるということ自体がチームの危機を察知できるということです。
それは事前に危険を予知するという点においてうまく機能しているということだと認識していているので問題ないというのがぼくの認識です。

つまるところそれはコミットメント言語の問題ではなくそれ以前のチームの問題だということを可視化しているということなので、まあつまりそういうことだと思う、強く生きてくれ。

コミットメント言語自体は当たり前のことを当たり前にやるというだけの話しでお腹が痛くなる類のものではないんだぞ！ってことが言いたい。

あと「リーダーとマネジメントは分けろ」という主張はまったくもってその通りだったんだけどうまいことぼくでは分割できなかった、諸兄が本著を読んで書いてくれ。
ぼくはあくまで本著のごく一部のみを書き出しただけなのでこれで十分じゃね？と思った人は多分手にとって見てみるほうがいい。
追記終わり:

寡聞にして本著で読むまで知らなかったのだがコミットメント言語というものがある。 数値目標と宣言を行う。乱暴に約してしまうならたったこれだけのことだ。 本著では「やることをいう」、「予想される終了日もしくは時刻を示す」と書かれている。

コミットメント言語などという仰々しさは全く必要ないように思える。

だが本著で出て来る例題が秀逸なのでいくつか引用させてもらう。

コミットメント言語変換前	コミットメント言語変更後
今週中には終えたいです	今週中までに終わらせます
5つのバグを修正します	今週末までに5つのバグを修正します
今日中にはやれると思います	今日中にやります
できるだけ早くやろうと思います	18:00までに完了します

これらの変更前の発言をぼくたちは一度ならず聞いたことがあるはずだ、もしないというならばそれは素晴らしいチームに所属している証拠だ。誇りに思っていい。 コミットメント言語とは詰まるところ、「なに」を「いつ」までに行うと宣言することだということだ。 これによって会議やスタンドアップミーティングのようなみんなで振り返りやタスク情報を共有することに初めて意味が出ると思う、ただ他人の今日やる作業内容を聞かされても退屈なだけで時間の無駄だろう。 もし仮に「今週末までに5つのバグを終わらせる」ことが出来なかった場合、そこには何かしらの問題が潜んでいるわけだ。 それをこそ会議やスタンドアップミーティングで話しあい問題解決を図るべきなのだとぼくは理解した。

これは非常に有効でいまからでも実践することが可能な手法であるとぼくは感じた。 またこれを実施することによるデメリットがほぼないという点も素晴らしい。

仮に期限を定めることが難しいタスクが合った場合はどうするのか？本著にはその対応策も書かれている。 曰く「毎週ｎ時間をその問題にあてる」、あるいは「今週中にその期限を定める」ということだ。 非常に明快でわかりやすい、またこれによってタスクが滞ることなく進捗している状態にあることが見える化に拍車をかけていると感じた。

クリアリングミーティング

これを説明するのはぼくには少々難しい。 本著では実際にあった事柄にアレンジを加えて実際のミーティングの様子を再現してこのクリアリングミーティングの概要を説明している。

簡単にいってしまうなら以下の手順を行うことで問題の洗い出しと共有などを図っている…と書くと非常に陳腐な内容に思えてしまうがまあ大体そんな感じだ。

1. 今週うまく行かなかったことはなんですか？
2. あなたはそれに関してなにをするつもりですか？
3. 今週良かったことはなんですか？

この順番に各リーダーに質問を投げかけるというものだ(本著の例ではクリアリングミーティングは各セクションのリーダーのみが参加したミーティングであった) だいたいの場合どれほど順調にいっても問題というものは発生する、1日に1度あるかどうかの問題でも1週間となると程度の差はあれ必ずなにかしらの問題がでるはずだ。 この第1の質問は非常に示唆に富んでいるとぼくは感じた。 まず問題から聞き出すというのが非常にスマートだと感じたのだ。

また本著では第1の質問に対して「うまく行かなかったことがない、全て順調だ」と答えるリーダーが存在したがその際に「本当に？全て完璧だったのですか？今週、仕事でもっとよく出来たといえることが1つもなかった？」と念を押している。 これが実に素晴らしい、会議のときに意見を求められると「特にありません」と答えることが多々あると思うがそれらは事実ではないとぼくは思う。 ただ「報告するほどの価値があると考えていない、もしくはこの場で話す必要性のある事柄ではないという問題が存在している」が正しいという考えだ。

会議というものはみんなの時間をかき集めて行うものだ、つまり余分に使う時間はどこにもない。 その意味でも問題を深掘りし、その解決や共有に勤める必要性があるとぼくは考える。 そして第2の質問でその問題に対して「なに」を「いつ」までに行うのか宣言することとなる。 これによっていわゆる「会議でなにも決まらない」現象が激減するのではないかという期待がある。

実際にはそれほどうまくいかないこともあるだろう。 ただコミットメント言語とクリアリングミーティングが徹底できるのであれば多くの問題は解決できるのではないかと愚考する。 この考えを補足するような文章が138ページにある。

チームがする予定外の仕事の多くは車輪の再発明や情報共有の不徹底といったところに根本的な原因がある可能性がある。

まとめ

本著はリーダーになった人にとっても素晴らしい1冊であることは間違いないのだが それ以上に読んで欲しいと思ったのがぼくのように「リーダー職やマネジメント職に興味がない」という現場至上主義ともいうべき実務者だ。 恐らくぼくたちが想像しているリーダー像というのは本質から歪んだ情景が映し出されている。 あるいは別のなにかとごっちゃにしてしまっており、リーダーシップの本質に気づけていないのだと思う。 誤ったリーダーシップを持ち続けたままでは間違ったリーダーになりかねない、またリーダーシップというぼんやりとした概念は本書を通してきっと受肉されることだろうと思う。

本著ではリーダーシップとは確あるべし！といったことは書かれていない、ただリーダーがなすべき役割が定義づけられているだけだ。 適切に、論理的にこのフェーズにはこのリーダーシップスタイルがマッチしやすく、次のフェーズに移行するにはこういうことに注力する必要があると書かれている。 実にロジカルで明確な説明がなされている、ただそれだけなのだ。

ぼくは本を読んだときに良いと感じた書籍を良書、誰かに伝えたくなる後世に残るであろう書籍を名書という区分わけを自分の中で行っている。 本著は間違いなく名著であるとぼくは確信している。 もしあなたがまだリーダーでないならそれは素晴らしいことだ、一刻も早く本著を読むことをオススメする。

さいごに

最後にエッセイで伊藤直也さんが書いていたことがかなり自分にとって反省すべき事柄だったと感じたので紹介しておく。 恐らくいろいろなところで似たようなこと、あるいは同じことをいっているのだと思うが本著を読んだあとだったからか余計に重く受け止めることになった。

「チームがよくなれば物事がうまくいく」というのはチームが良くなればうまくいくというロジックではなく「チームが良くなって欲しい」というただの願望ということはないでしょうか。自分の胸に手を当ててよく考えてみてください。それはロジックなのか、願望なのか。

ぼくは伊藤直也さんの論説が好きだ。 それは否定しないが今回のことはそれとは全く別系統での評価であることを明言しておく。

この一文によってぼくは「チームが良くなることで物事(プロダクトや会社)がよくなる」という願望に取り憑かれていたことを自覚した。 チームが良くなることは良いことだ、でもそれは問題の本質ではないのだということをぼくは常に問い続けなくてはいけないし、問題の本質を考えなければいけない。 それはリーダーだとか一般社員だとか新入社員だとかCTOだとかは全く関係のないことなのだと思う。

レアなTシャツをてにいれたおれたちは…

前回Qiita丼はじめたブログ書いたらTシャツもらえるらしいので雑に書いたぞ！ってQiita丼で広報のかたに凸ったら本当にもらえました、いえーい！

luccafort.hatenablog.com

1枚だと思ったらまさかの2枚+ポストイットとQiitaシールも入ってた！！！うれしいサプライズだぜ！

Qiita丼はじめましたブログ書いたら先着5名のレアTシャツもらった丼！！！#qiitadon

ポストイット？とQiitaシールもいただけて余は満足じゃ。

早速貼るところがないくらい貼ってあるMacBookProのケースに貼り付けた図がこちら…

ゴチャゴチャしすぎてもはや何が何だか感ある。

これはひどい…。

Qiita丼は(まだ)牧歌的なのとエンジニア率が高いので非常に住み心地がよい。 Pawooとかだと逆にアウェイ感あってそれはそれで楽しいのかなとか思うけどストリームが酷いことになりそうなのでいまのところ自重してる。

というわけでIncrements広報部のかた、迅速なプレゼント発送ありがとうございました！ …さっそく明日会社に着ていって自慢したろ。

Qiita丼はじめました。

http://blog.qiita.com/post/161193715974/qiitadon

blog.qiita.com

昨今の話題にあがっていたmstdnが技術的な興味は除くとしてSNSが中央集権的で企業に依存することに問題を感じたことがなかったので特に始める必要性がないかなーと思っていた。 ただ技術的な内容が中央集権的に握られるというのはなんというか改善して欲しいしそういうアプローチとしてのmstdnは意外とマッチするのかも？とか思ってたらサービスがリリースされたので登録してみたという話し。

qiitadonの良いところ

• Twitterと違い技術者が多いのでノイズが少ない
• 初めてTwitterを始めた頃のような「誰をフォローしようかな？」感を楽しめる

qiitadonの悪いところ

• 別にこのサービスである必然性がない

ところでインターネットでよく退職エントリで恨み節が炸裂することがあったりすると思うんだけどTwitterやFacebook、ブログに投稿するよりこういうマストドンライクなサービスに投稿するのがリスク回避できていいのかな？とかちょっと思ったりpodcastのライブ配信時にチャットとして活用できると楽しそうかな？と雑に思ったりしました。 まあ実際にはそんなことないんだろうけども。

ぼくは割りとTwitterで連投したりTL汚してると思ってるのでこういうクラスタというかカテゴリーというのかわからないけどそれのみに限定された人たちが集まりやすいSNSというのは意外とニッチで楽しいなと思ってる。 あとまだ人数が少ない？からか牧歌的で初期の頃のTwitterを思い出す、TwitterはTwitterでカオスな感じが楽しいのだけどノイズが多いときはやはり鬱陶しいと思うこともあるのでその辺住み分けの問題かなという印象。 リスト使えとかあるけどリストにいちいちアカウントをぶち込んでいくのがクソだるいので却下だ、ウォルター。

んで、なんでこんなエントリを書いたかというと元々書く予定ではあったが↓の投稿がされたのが大きい。

ということでレアなTシャツの発送をお待ちしております。

って書いてる間に先を越されてしまったくやしー！！！

note103.hateblo.jp

会話もメールも 英語は3語で伝わります

会話もメールも 英語は3語で伝わります

読了した。

先に述べておくとこの本を読んだからといって英語は話せるようにならないし、書けるようにもならない。 ただ英語の文章の組み立てかたは変化するかもしれないと感じた。 一度読んで終わりではなく、何度か読み直して都度修正する感じの本かなという印象だ。

結論から言ってしまうとこの本では「SVOで文章を組み立てろ！」とクドいくらいに主張している。

例えば「チョコレートがある」という日本語を英語に変換すると多くの人は「there is the chocolate.」と訳すのではないかと思う。 これは学校で習った英語の教科としては正しい。

だが英会話といてみたときに違和感のようなものを感じることがある。 本著ではこれの日本語を「i have some chocolate.」と訳す、とある。

この本で得られる気づきとしては主に3点ある。

• 英語における主語の重要性
• 平易な英語を組み立てる重要性(だいたいの英会話はSVOで組み立てるのがわかりやすくまた進んでいる感があってよい)
• 日本語を英語に変換するのではなく日本語を英語に意訳することが重要

この本全体を通して感じたこととして、英語というのは主語の「私」「あなた」「私たち」が非常に重要なのだなと感じた。 だから「チョコレートがある」という日本語自体がある意味では間違っているのだろうと思う。 英語と日本語はそもそもが全く異なる言語なのでそれを無理やり当てはめようとすると直訳では意味がわからない、あるいはわかりにくい英語になってしまうということなのだと思う。 このギャップというか齟齬が英文を読んだときに自分が組み立てた英語と文章が異なるので「わからない」に繋がってしまうのかなと思った。 つまり意訳するならどうなるのか？を英語で考える能力が圧倒的に足りていないのだなというように感じた。

そしてこの本を通じて感じたのが語彙力がすごく足りていないということだ。 平易な英語を組み立てるにも語彙力がやはり必要だなと痛感した。 そのあとジュンク堂でパラパラと単語系の書籍をいくつか立ち読みしていて一番しっくりきたキクタン Basic 4000という単語本を寝る前に1DAY毎にすすめている。 (よく英語学習系のエントリで紹介されるDUO 3.0でも良かったがあれは受験に必要な単語として非常によくまとまっているという印象を受けたので候補から外した。英単語n000も同様だ)

改訂版キクタンBasic4000 (英語の超人になる!アルク学参シリーズ)

英語を書けるようになるにも話すようになるにもやはり単語を知っているというのは言わば筋トレ的なものだと言われているが非常によくわかる、というか体感することとなった。 いますぐに効果がでるようになるとは思わないが徐々に語彙力を増やしていきつつ、SVOを意識した平易な英語を頭で組み立てていくことで英語が苦手！という状況を打破できればなあと思っている。

次回のGoogle I/Oに参加できればその結果を出せるとよいな、っていうか参加したいなって気持ち。