おうさまのみみはロバのみみ

ネット上での木の洞

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

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

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

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

一般に「イシューとはなんぞや?」と答えれるひとは恐らく半分くらいじゃないかと思う。 かく言うぼくもイシュー?ああ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つのバグを終わらせる」ことが出来なかった場合、そこには何かしらの問題が潜んでいるわけだ。 それをこそ会議やスタンドアップミーティングで話しあい問題解決を図るべきなのだとぼくは理解した。

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

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

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

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

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

  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の悪いところ

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

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

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

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

f:id:luccafort:20170604174942p:plain

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

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

note103.hateblo.jp

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

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

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

読了した。

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

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

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

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

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

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

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

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

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

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

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

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

最近のエモい話し

最近やたらとエモいマネジメントの話しを聞いたり読んだりすることがあったんだけど結局のところどれにも共通するよね?ってことがあったので書いておこうと思った次第。

  • 問題の本質を理解する
  • 課題の見える化
  • 問題の振り返り

ぼくはマネジメントにすごく実績があるというわけではないのでここで書いてる内容はすごく頭でっかちなことなのだろうと思う。 ただどの書籍や資料、あるいは講演などを聞いたり見たりしてもこの3つは言葉は違えどどれにも共通しているように思う。

本来の課題の本質が「プロダクトの質を向上させる」であるはずがテストコードを書けばいいんでしょ?コードレビューすればいいんでしょ?であったり 問題がどこにあるのか?を検討しないままとりあえず会議して無駄にみんなの時間を奪ってしまっていたり やることいっぱいすぎて整理できてないけどスケジュールは変わりません!みたいなことだったり。

だいたいのプロジェクトで炎上する、あるいは炎上しそうになった際に偉大な先人はまず 「問題の本質がどこにあるかを検討」 それを「チーム全体で共有するために見える化」 「今何をしなくてはいけないのか?あるいはなにをすべきでないのか?」を明確化して乗り切っているっぽい。 これらは手法や経緯は違っていてもだいたい共通している。

もちろん資料からだけでは意味がないのだろうと思うけどぼくらはどうにもイディオムに視点がいきがちだ。 コードレビューをしないといけない、テストコードを書かないといけない、Githubを使わないといけないなどなど…。

それらは確かに打開をしてくれる可能性があるが問題の本質はそこにあるか?と言われると疑わしいことがある。 OSO2017で「レガシーとは当たり前だという思考そのものである」といったような発言があった。 これらは無意識だから気づくことが非常に難しく、そのため改善案を提示しても提示された側は「こんなことは当たり前なのだ」と思っているため芳しい返答が返ってこない… だいたいそのようなことを言っていたと思う。

speakerdeck.com

この資料で「何故本来そうあるべきものがなっていないのか?そうならなかったのは何故か?」という問いを突き詰めろと伊藤直也さんも言っていたがこれは恐らく明日から、あるいは今からでも使える話しなのだろうと思う。 「この問題はこうだったから当時そうしたくてもできなかった」という気づきを得ることが出来る、そしてその問題はいまでは簡単に解決できるものなのかもしれない。 だからこそ、振り返りが必要であり、見える化が重要なのだと感じる。

だいぶ文章がとっちらかってきたが眠いし雑にまとめてしまおうと思う。

詰まるところぼくたちは真面目にシャローワーク(誰にでも出来て専門性のない作業)に従事しすぎているのだと思う。 マネジメントの本質はそこではなくて問題の本質を露わにし、どのように解決していくかを決め、その結果を振り返るところにあるのだと最近思うようになった。 その結果の一部として同僚や部下などの人を管理する工程が入ることがあるということなのだと。 マネジメントそのものには人を管理する工程は必須ではない、というのがぼくの最近の気づきだ。

実際のところそれが正しいかどうかは知らないがマネジメント=人材管理な印象を強く受けていたぼくにはちょっと新鮮でもっと早くに気づかないといけないことだったと最近反省している。

以上、最近のエモい話しでした。

おっさんエンジニアがAirBnBを使うとどうなるのか?

経緯:

巷でいろいろと噂の民泊の代名詞AirBnB。 地元の京都でも使えるところが非常に増えていて一度使ってみたいなと考えていた。 ところがさすがにいきなり海外で使うのは怖いという思いがあったりした、この辺はテレビなどの情報が影響している部分が多大にあると思う。 そんな折にオープンセミナーOkayama 2017に参加することになったのでどうせなら懇親会参加したいし、京都から懇親会参加すると途中退室になっちゃうかー。 だったら一泊したいなーと思ったのが動機。 あとAirBnB使ってみたかったというのと国内だったら最悪多少のトラブルが起こっても言葉が通じるのでなんとかなるな!という考えがあった。

実際の使ってみた感想:

ビジネスホテルやネカフェに泊まるくらいなら断然AirBnB使うわ!って感じで良かった。 たまたま当たりだった可能性もあるけども一泊しただけですがお値段以上の価値があったように感じました。 また岡山いくときは是非利用させてもらいたいと本気で思ってる。

泊まった場所:

www.airbnb.jp

事前にブログに書きたいんだけど?と相談したら「ご自由にお書きください」と快いお返事をいただきました。

お部屋の感じはこんなの。 不動産屋でもカメラマンでもないので構図とか気にしたら負けだ。

今回OSO2017で宿泊したスペシャルルームホンマチのお部屋。これで6k切ってて最高だった。

さっき確認したらだいたい料金が4500円でサービス料が600円、諸々込みで5200円ほどだった。 以前岡山のビジネスホテルに泊まったときは諸々込みで最終的に6kくらいしてたのでそれと比べても安い。

良かったところ、悪かったところ:

あくまでこれは今回利用したところの情報に限定される。 他のところではまた条件が違うと思うのでその点だけは注意して欲しい。

まずは良かったところから。

良かったところ:

  • ビジネスホテルよりも安い
    • 以前利用したビジネスホテルは6kくらいした割に本気で荷物の置けるカプセルホテルみたいなとりあえず寝ることはできるって感じだった、コスパ悪いなーって当時思ってたのを覚えている。
  • 駅から近い
  • チェックイン・チェックアウトの制約がホテルに比べて緩め
  • 連絡のやりとりがAirBnB上のチャット上でほぼ完結する
    • ぼくは電話嫌いな人間なのでめちゃくちゃ高評価!

AirBnB、チャットでだいたい完結するので電話嫌いなぼくにもってこいなサービスだ。

  • 共有スペースが広い!
    • 執筆スペースっぽいところやソファー、食事するスペースなどもあった。
  • インターネットが使い放題
    • 酷いビジネスホテルの場合なかったり、あっても500円取られるとかある。それに比べたらただでインターネット使えるとかすごくいい。
  • 電源が豊富
    • PCやワイヤレスヘッドフォン、モバイルWifiスマートフォンなど充電対象がいっぱいあるぼくのような人間がビジネスホテル使うとたまに電源が足らない問題が出ることがあるのでこの点はめちゃくちゃ重要。
  • 食事代を安く出来る
    • 激安旅行してる人や食にこだわりがない人はトースターがあったので近所のコンビニでパン買って焼いて食うとかできる。
  • 洗濯できる
    • 長期間滞在するとかだと重宝しそう。
  • 岡山駅から非常に近い
  • 近所に自販機合った
    • 寝る前にお茶買ったんだけど地味に便利だった。
  • ゲスト招待機能がある
    • 使わなかったけど急に1人の予定が3人に増えた!とかなってもなんとかなる?機能っぽい。

悪かったところ:

正直悪いというよりはここがこうなっててほしいなーとかこれ人によっては気になるだろうなーということ。 悪いほど強いニュアンスはない。 - 駅から近く回りに飲み屋などが数多くある繁華街なので夜中でもちょっと騒々しい。 - 窓を閉めるとそこまで騒がしいと思わなかったが神経質な人だとちょっと厳しいかもしれない。 - 顔写真をAirBnBに登録しないといけない - ホスト側の判別などで必要になるということらしい、とはいえAirBnBに顔と名前、メールアドレスを握られてるので気持ちが悪いところはある。 - トイレが狭い

ちなみにどれくらいトレイが狭いかというと…

部屋は申し分ないがトイレがちと狭いのが難点と言えば難点か。でも十分すぎる内容だしいいじゃん!

恐らく映画とかドラマなどに出てくる典型的アメリカ人みたいな体型だと入れないと思う。 アジア人なら相当太ってない限りは多分大丈夫、とはいえかなり狭いのでトイレが狭いのはいやだ!とか狭い空間が苦手なひとはつらいかも。

おっさんエンジニアがAirBnBを使った感想:

以前に飛騨高山へ遊びにいったときホテル側のシステムの問題で楽天トラベルを強要されたのだけどこれがすごいストレスだった。 特に楽天はDM攻勢が酷いと噂があるが本当にその通りで全然気にならないどころかノイズにしかならない量のメルマガが送信されてきて非常に鬱陶しかった。 そういった煩わしさはAirBnBにはなくて非常に精神衛生上良かった。 また比較対象が悪いのかもしれないが楽天のシステムは1n年前のシステムかよ!!!みたいな作りをしていたのだけどAirBnBはさすがにその辺流行りのキラキラ系スタートアップなだけあって非常にわかりやすいシステムになっていた。 ただ若者向けなUIではあるのでスタイリッシュすぎておじさんにはちょっと難しいところもあった、このあたりは慣れの問題もあると思う。 ぼくは比較的すんなりいけたように思うが例えばぼくの親世代にやらせたら楽天のほうがわかりやすいというんじゃないかと思う。

最近コワーキングスペースとか話題になると思うんだけどAirBnBコワーキングスペース代わりになるんじゃないかな?と思ったのが1点。 いわゆる開発合宿的な使い方ができそうだなと。 あるいは家だと誘惑が多いし、せっかくだから気分を変えてコードを書きたい!みたいなときにスタバみたいなカフェにいくのもいいんだけどこういう民泊先で1人開発合宿するのは手軽だしなかなかいいアイディアな気がする。 コワーキングスペースいっても会員登録必要なところもあったり月額だけで考えたら値段変わらないとかある。

もちろんコワーキングスペースはやはりそういう用途に合致した施設を提供してくれるわけだがそういうところにいきなりいくのはハードルが高いと思うひとにはちょうど良さそう。 ぼくはとりあえず京都で1人開発合宿をやってみようかと思ってる。京都にいるとどうしても京町家で寝泊まりするとかないので憧れがあるんですよね。

逆にこういうひとたちは向かないだろうなーというのも少し見えてきた。 バケーションを楽しみたい人には日常感があふれるため期待するような情緒感は感じにくいと思う。 あとこれはケースバイケースだと思うけど家族連れは難しいかもしれない。 一応設備的には小さなお子さんが泊まることになっても大丈夫なようにしてあったがホテルのほうがこの点は優れていると思うのでそういう意味だと小さなお子さんがいる場合はホテルに泊まったほうがいざというとき助けを呼んでくれたりいろいろサポートしてくれるのでいいんじゃないかなと感じた。

以上! なんで若い人たちの間でAirBnBが流行っているのかが少しだけわかりました、これは流行るしみんな使うわけだわ。 パリのホテル業界が民泊導入後に阿鼻叫喚の悲鳴をあげているというニュースがあったが分かる話だなと思う。 バックパッカーみたいな泊まるところを安くすませてその分長くいろんな国に行こうとするひとたちからすればホテルの食事ってコストが高い割にパフォーマンスがいいわけじゃないんですよね。 これはぼくも思っていたことがあってペンションとか人里離れているとそういうサービスがあると嬉しいけど街中だとその町の名品とか噂のグルメとか食べてみたいな!ってぼくは思うのでそうするとホテルの食事っていらないんですよね。 なのでぼくみたいな面倒くさいタイプの人間はAirBnBのほうがホテルよりも性にあってるんだろう。