しがないラジオ sp 14の補完・補足

紹介:

sp.14a【ゲスト: lucca0show】楽しいコミットメントの始め方

shiganai.org

sp.14b【ゲスト: lucca0show】楽しい積ん読カンバン術

shiganai.org

ゲスト出演しました! …がいくつか話していて説明不足であったり、うまく説明できていないなと感じることがあったので補足話を書いておこうと思います。

好きなことを仕事に!だけでは難しい:

よく「好きなことで食べていく!」とかキャッチフレーズみますよね? ぼくは割りと好きなことを仕事で生活できていると思っているんですがゲーム業界で働いていたときに「ゲームが好きってだけだとこの業界で働き続けるのは難しいなー」と実感したということが伝えたかった主題です。

実際にゲーム業界で働く前は「好きのレベルが低いんじゃない?」という疑念が頭の片隅にあったのですが業界で働く内にその幻想は木っ端微塵に砕け散りました。 主に悪い方向で。

podcast内で補足してもらえましたが好きにもいろんな形があって、ゲームを作るのが好きなのか、作ったゲームを遊んでもらうのが好きなのか、ゲームをプレイするのが好きなのか…それぞれいろんな形の「好き」があります。 アニメや漫画、ゲームなどのエンターテイメント系はこれらの境目が曖昧なことが問題の1つだとぼくは考えていて、 そのときに「好き」だけではなく「楽しめる」という軸がないとうまくいかないのだと実体験から結論を出しました。

なんというかこの2つはどちらが上とかではなく車輪の両輪のようなものだと思っているというのが正直なところです。 「好き」という原動力が「楽しむ」というエンジンで加速エネルギーを得ていく…とでもいうのでしょうか? どちらかだけでは疲弊してしまい、人によっては好きが反転してしまうこともある…ということを伝えたかったのです。 説明ベタで申し訳ない。

Write Code EveryDayを4ヶ月してみた:

podcast中で語ろうと思ったままついつい忘れてしまったのですが実はぼくはいま現在毎日コードを書いているわけではないです。 というのも自分の課題として基礎的な技術力が不足しているという思いがあります。 その基礎的な技術力を向上させるためにはまず質の良いインプットが重要だと考えました。 ところが毎日ある程度とはいえコードを書いているとなかなかまとまった質の良いインプットを行うのが困難であるということに気づきました。

そこで意図的にインプットの質と量を担保するためにそれまで継続して書いていたコードを毎日書くのではなく、書けるときにだけ書くという方針に変更しました。 これはGithubの草を生やすことが主題になってしまっているように感じていたことも1つの理由です。 「イシューからはじめよ」でいうところの「犬の道」に自分が陥っていると感じたからです。 これはpodcast内でブログをただ書くだけでは難しい…といった発言にも共通している思いです。

結果はまだまだついてきていませんが、目的の部分がブレているとはまだ思っていないのでそのうちまた毎日コードを書く日々に戻ってくると思っています。 いまは充電期間のようなものだと考えて、しっかりと質の高い、あるいは高くなるようにインプットに専念したりしています。

ブログ執筆の話し、書いてるだけではうまくならない問題が難しすぎる:

この問題は多分ぼくにとってある種の転換点を迎えたからこそ発生しているのだと思っています。 昨年、期せずしてElastic Leadershipという書籍を紹介したところ変な形でバズることとなってしまいました。 そのときに「伝えたいことがしっかり伝わらない」という思いをしました。

ここが転換点だったのだろうと思います。 その瞬間からぼくは「ぼくだけのブログ」から「読者に伝えたいブログ」に変化していったのだと思います。 いわゆるコンテキストを共有している人からは好意的なコメントをいただきました。 一方、コンテキストが共有できていないと感じる方からは「コミットメント言語は日本人の文化にあわない、圧迫されてしまう」というコメントを沢山いただきました。

コミットメント言語は手段であって、目的ではないのですがそこがしっかりと伝えきれなかったなと今にしては思います。 バズっていたときは「それはチームの問題でコミットメント言語自体の問題ではない」と思っていたのですが コミットメント言語を手段として用いるその目的や目標をたしかに明確にしていなかったなと最近は考えることがあります。

先程もちらっと書きましたがそのことに気づいたとき「ぼくのブログを書くのはただ「犬の道」になってやしないだろうか?」という思いが頭をよぎりました。 そういう思いや考えから件の発言元である「ただ書くだけで上達するわけではないので難しい」という主旨にたどり着きます。

自分のスキルに不安があるので転職迷う問題:

概ね自分の考えはpodcastで語った通りなのですが一点だけうまく伝えられなかったと聞き直していた際に感じたことがあったので補足しておきます。 ぼくがpodcast内で「フリーランスを意識するほうがよい」という主旨の言葉を使っていますがこれは実際には正しくなく「自分の価値を常に意識する、そのための方法として転職やフリーランスを常日頃から意識すると良い」というのがぼくが考えていた思いに一番近い回答となります。

フリーランスになることそのものが重要なのではなく、「自分の価値を自分で見極め、知る」ことが肝要ということが伝えたかった全てです。 podcast内でも語っていますがぼくは自分の副業先の給与を時給換算でいただいています。 そして副業をしているときにふと自分の価値を客観視し、「ぼくの技術力はたったこれだけの価値しかないのだろうか?」と感じる結果となりました。

実際問題、副業先のスタートアップはそこまでお給与を支払えるわけではなく(フリーランスの人のほうがコミットメント率が高く重要だったとかの理由はある)ボク自身も契約当初はどれくらいコミットできるかわからなかったこともあり、納得の上で給与を決めたのですがそこには「これだけ高い給与もらって結果が出せなかったら怖いので低く見積もろう」という心理がありました。

結果から言うとそれは大きな間違いでぼくは自分の価値をもっと真剣に査定すべきだったのだと思います。 いまだにぼくは自分の価値の適正値がわからないです、ですがそれは自分の価値と向き合わないということと等価ではないとも思っています。

ぼくらは自身が持つ自由な時間を労働して成果を出すことで会社から給与をもらっています。 もちろん諸々の経費などは差し引かれているでしょうが、そこにはそれだけの価値があると会社に認められているわけです。 自分の価値を低く見積もるというのは自分自身を卑下して貶めているようなものだと最近は考えるようになりました。 その行いは自分と、自分の価値を認めてくれるひとたちに対して不義理で、あまりに失礼な行為ではないかとも思っています。

とはいえ、スキルがないと自分の価値を認めにくいのも真理です。 だからこそフリーランスや転職のように他人から見た評価を参考にするのが良いとぼくは思っているのです。 いまの自分のスキルセットはどのくらいの市場価値なのか?を意識することは十分価値があるし、またもし転職することになった際にも話のネタになります。 転職するしないは関係なく、自分の給与が実力に対して適切に評価されていない場合1つの提示する資料にもなります。

転職サービス側からすると迷惑千万な行為だと思いますが、市場価値を知るために転職サービスに登録しておくのは割りとコストパフォーマンスのよい施策でないかなと思っています。

出演してどうだった?

概ねいいたいことは言えたかなと感じています。 ビブリオバトルについては語れなかったので次回出演するか、自分のpodcastでやろうと思ってます 反省すべき点は多々あるのですがパーソナリティのお二方に助けていただいて非常によい体験をすることが出来たと思っています。

どうしても対話というベースや技術系の話しではないため、議論的というか話しが盛り上がってしまい時間が長くなってしまったのがpodcastというものの難しさを改めて実感しました。

どうしても1人だとうまく掘り下げられない内容もパーソナリティーの方がいるといい感じにまとめてくれたり、思わぬ方向からの意見をいただいて改めて考えるきっかけになるなと感じました。

ぼくはネット弁慶の割に打たれ弱いので基本的にあまりエゴサをしないようにしているのですがついつい誘惑に負けてしまいTwitter上で検索してしまいました。 いろんな意見やぼくの意見の補足、共感、反論諸々読んでいて自分の発した一言が与える影響がこんなにあるのかと新鮮な驚きを得ています。 そして改めて自分のためのpodcastをやっていこうと思いを新たにしました。

いつになるかはわからないけども自分の中でこのくらいの時期に行いたいなという獏っとした思いがあるのでリリースしたらTwitterやブログで報告させてもらおうと思います。 あと、今回ヘッドフォンから自分の声が聞こえてきたり、思った以上に早口だったのでしがないラジオにリベンジしたいですね!

プロを目指す人のためのRuby入門

2017年中に読了する予定だったがゼノブレイド2やってたら諸々あって2週間遅れで読了した。

対象:

本著の冒頭でも語られている通りプログラミングの未経験者がこの本を読了するのはかなり根気がいることだろうと思う。 プログラミング初級者(初心者でない)が次のステップへ行こうとするときに読むべき本であると感じた。 一方で手元にあって困ることがない本だとも実感した。 他の言語である程度プログラムを書くことが出来る、あるいは最低限if文、for/while文、関数がわかる人が対象としてボリュームゾーンであるように思う。

感想:

結論からいってしまうと個人、というよりは業務でRubyを扱うことがあるなら1冊教育用途で置いていてよい書籍だ。

本著を手に取るきっかけとなったのが目次の例題が非常に適切なレベルで設定されているように感じたからだが結果振り返ってみるとそれは正しかったように思う。 4章の繰り返し制御や配列、ブロックなどの概念や使い方ハマりどころは以前Railsでアプリを作っていた際に「よくわかっていないがサンプルとして書かれている通りにかけば動く」というものを十分に解決してくれたし、5章のハッシュやシンボルを理解するも大いに不勉強な知識を補完してくれた。 ぼくの今までの主言語がPHPだったこともあり、なにがRubyとその他の言語で違うのか?が書かれているのは非常にわかりやすく、またハマりどころを事前に教えてもらえたと実感している。

クロージャーの振る舞いの違いやサンプルコードでなく実務でよく見かけるような書かれ方をしたコードの説明などがされており、まさしく入門として正しい1冊だと感じた。

カバーに「Railsをやる前に、Rubyを知ろう」という一語があるが自分が如何にRubyを知ることなく、極端な言い方をしてしまえば「舐めていた」かを直視することとなった。 まだまだyieldやProc、それにシンボル。 そしてなによりもクラスのPublic/Private/Protectedの概念はまだまだ自分のなかにしっかりと根づいていないと感じている。

そうそう、本著ではRubyらしいコードの書き方が乗っていることがある。 Rubyにはいくつもの書き方や実装の仕方があり、独学の初心者や初級者は相談する相手がいないことが多いため、どの実装を選択するのがベターかわからず戸惑うこともあると思う。 会社であれば先輩社員や詳しいひとにレビューをお願いすればいいが、独学ではなかなか難しい。 全体的な総量としては少ないが本著にはその点について言及されているところが何箇所かあり、そうすることの意図も非常に明確に書かれている。 今後迷ったときにどれを選べばいいのかの判断基準になりそうだと感じた。

もしあなたが他言語のプログラミング経験はあるが、Railsを覚えたいと思うのなら最初に手にとって読む1冊として最適だろう。 恐らく幾つかの内容についてRuby独特の解釈で戸惑うことや思考が追いつかないことがあると思うが、それがRubyという世界の流儀なのだろうと思う。 今後の目標としては以前挫折したRailsチュートリアルやPerfect Ruby on Railsなどを写経していわゆる「Rubyらしい」書き方を身に着けていこうと思っている。

2018年の抱負

今週のお題「2018年の抱負」

まだ第1週なのでセーフだろうという自分ルールを適用したい。

具体的には3つ。

英語のアウトプットをする

インプットは最悪1人でも出来るけど喋るのは1人じゃ無理なので英会話教室でも行ってみようと思ってる。 そこでまず苦手意識を克服することを目標、目的は外国人に喋りかけられてもネガティブに感じなくなるようにする。 流暢に喋れなくてもいいし、単語が出てこなくてもいいけど今のぼくは伝えることに対して非常に腰が引けている状態なのでまずはそこの意識改革が大事だと思う。

あと最近感じたことなのだけどアジア圏の人が英語で話しかけられても身構えることが少ない(ネイティブでなければ)のだけど白人黒人だと身構える事が多いのは多分意識の問題でここを乗り越えれることができたらある程度喋れるようになりそうだなと思ったりなんかした。

英語をやっていくぞ!

インプットの量と質を保つ

実質的には昨年末からだけど積ん読をカンバンで管理する、ということを行っている。 量に関してはこれで担保がほぼされているので質をどうやって保つか?が今年の課題だと考えている。 読むだけでは身につかないのでなにかしらの改善策が必要、そこを考えて是正していく。

欧米(イタリア)に旅行する

ぼくは小学生の頃にグアムにいったきり外国にいったことがない。 ところがイタリア、特にヴェネツイアには行きたいと常々思っていたが実行していないし結婚したりすることが今後あるかもしれない(特にいまそのような予定も相手もいないが) ということでやるぞ!と宣言することで自分を追い込もうと思う。 ちょうど?妹夫婦がドイツにいるのでついでに挨拶してこれたらいいなと思う。

できれば夏くらいが理想。

あれ?Podcastは???

これはすでにやることが決まっている決定事項なので抱負ではない。

以上。 とりあえず旅行はスケジュールやらパスポートやら事前に用意する必要があるので早め早めに対応していこうと思う。

しがないラジオにゲスト出演しました

去年末のAdvent Calendarに参加していたしがないラジオにゲスト出演しました。 収録日は2017/12/30、大晦日ではない! ちなみにすでに公開されているep30は31日大晦日に収録されているとのことです。

shiganai.org

出演した経緯はこちら↓

2018年にぼくもpodcastやってみようかなーとか思ってたらまさかの2017年中にPodcastにゲスト出演することになってました。 ……どうしてこうなった。

以下、初めてのPodcast収録を経た反省点や振り返りなどをば。

結論:

まずは結論から。 ぼくの準備不足が目立ったなーというのが実感としてまずあります。

反省点は後述していますがなによりも喋るのがあまりにも聞き苦しくなってしまったこと、この1点につきます。 これは今回の収録が少々イレギュラーな収録の仕方をしてしまったために起こったことなのですが 収録中に「ああこの回は聞きにくい!というフィードバックが来てしまうだろうなあ…」と話しながら考えていたのを覚えています。 大変申し訳ない気持ちと次回があればリベンジしたいという気持ちです。

次回は自己紹介を5分で終わらせて本編にTech系ネタ、真の本編であるAfter Showでキモオタトークをやっていきたいですね! というわけでリスナー諸氏に対しましては大変お耳汚しをしてしまう回となってしまいましたが 次回リベンジの機会をいただければと思います、なにとぞ〜。

振り返り:

パーソナリティつよい!!!問題

まず良かった点のなかでもやはりここに言及せねば!と思ったのがパーソナリティーのお二人の会話術が巧みだったことでしょう。 普段聞いているpodcast上でのお二人の掛け合いそのままで進行したこともあり、開始直前は緊張していたものの割りと話し始めるとエンジンが徐々にかかってストレスなく話し始めれたのが印象に残ってます。 さすがに1年に渡ってPodcastをやってきただけのことがあるな!という印象を持ちました。

パーソナリティーのやっていきちからがすごい

経緯をみてもわかる通り、お二人のフットワークの軽さ、回転の速さはさすが!と思わざるを得ませんでした。 お誘いいただくことがなければぼくはゲスト出演することはなかったんじゃないかなーと思います。 ちょうどPodcastやってみたい!と自身でも思っていたのでタイミング良く声をかけてもらったかなという感じです。

直接フィードバック

気恥ずかしい面もありますが @zucky_17 さんからブログのエントリに関するフィードバックを直接いただくことができたのは非常に良かったです。 これはpodcastだから、というわけではないのかもしれませんがなんというか自分がコンプレックスだと思っていたことが誰かにとっての楽しむ一助になっていたといえばかしこまりすぎていますが ぼくの文章を楽しんでくれたというフィードバックを対面で言ってもらえたのが嬉しくて「ブログ書いててよかったなー」と思いました。 元々ボクはどちらかというと自分のためにブログを書いていた人間だったので純粋に喜ばしい出来事を胸に秘めて2017年を締めることが出来ました。

パーソナリティーのお二人がよく「フィードバックまってまーす!」と仰ってますが本当の意味であの言葉の深さというか怖さと楽しさを実感することが出来ました。 是非とも皆さん、フィードバックをお待ちしております。 ……ぼくの出演回に関して言うならできるだけマサカリ風味は避けていただけると嬉しいかなって。

音声メディアならではの振り返り

pupupopo88.hatenablog.com

軽い気持ちで #しがないラジオ に出演したら畑に埋まりたくなったお話でも書かれていましたが取り返しがつかないメディアだなというのを実感しました。 ブログは書いてから構成を変えたり、文章の言い回しや補足を簡単に添削できます。 その点において文章というのは非常に凶悪なアドバンテージを要しています。 ところが音声メディア、あるいは動画メディアというのはこの補足部分などの編集が出来ません。 多少の修正を書けることは出来ますが基本的に自明のことだろうと省略してしまったことや説明を省いてしまったがために本来の意味を捻じ曲げてしまいかねない表現をしてしまった箇所がいくつかあったなと収録後に反省しました。

これはエピソードが公開されてから補足点としてまた別に書き出したいと思います。 というかそうしないとうまく意図が伝えられていないと思います。

声の大きさ問題

↑の音声メディアならでは問題と若干かぶるのですが声の大きさというのが今回Podcastに出演して一番困ったというかどうすれば正解なのか?がわからず、結局最後までわからないまま完走してしまいました。

このあたりは数をこなす内に自分の声は音声が拾いにくい、拾いやすいなどの感覚値が定まるのかなーと思いました。 最悪編集とかでもどうにかなるのかもしれないですが、あまりこういう部分で編集はしたくない(ライブ感が薄れてしまう)と個人的に思っているので今回収録にあたり公開されたエピソードを聞いてみて改めて振り返りたいと思います。

反省点:

全体的に反省点が多いのですがその中でも特に「これはよくなかったなー」と感じたものをピックアップしました。 もしPodcastをやろう!あるいはゲスト出演することになったぜ!というかたは煮るなり焼くなり好きにしてくだされ。

snob問題

ぼくのことです。 「知識・教養をひけらかす見栄張りの気取り屋(Wikipedia引用)」という実にインターネッツインターネッツした性格をぼくはしていると自覚しておりいくつかのトピックにおいてその手の発言をしてしまっています。 これは現実問題としてあまりよくない、とは思っているのですが如何せんなかなか直すのが難航している問題でもあり、 リスナーの方が不快に感じるかもしれないという点や自分のコンテンツでもない場所でこの手の発言をしてしまうというのはよくなかったなと思っています。

小馬鹿にしたような発言があったらこのゲストはドラえもんに出てくるスネ夫みたいな嫌なやつなんだなと脳内変換してください。 だいたいあってます。 次回ゲスト出演時には気をつけたいと思います。

要点をまとめる能力が欲しい問題

元々ぼくは文章を書くのも喋るのも苦手でして、いわゆる「要点をまとめる」ことが出来ないタイプの人間です。 「要は〜」って言いながら全然要約出来てない人が身近にいますよね?ぼくはそのタイプです。

なので喋りながら考えていることが常であり、その結果伝えたかったことがズレてしまう。 あるいはその逆で聞く側のことを一切考えずに自分の主張だけを誇示してしまう傾向があります。

そのあたりかなりパーソナリティーのお二人には助けていただいたなと感じています。 特にgamiさんは普段からそのスキルを遺憾なく発揮されていて安心感がありました。 そのおかげもあってあまり緊張せずに喋ることが出来たなと思っています、ありがとう!

ヘッドフォンの準備不足問題

まず、今回 @zucky_17 さんが帰省されるタイミングでわざわざ京都に立ち寄っていただいての収録となった、通常の録音回と異なる方法で録音したというのが大きなポイントだったと思っています。

普段からヘッドフォンは使用しているので用意していたのですが、ぼくのMacBook ProをHigh Sierraにしたせいかここ最近BlueToothバイスへの接続が微妙な感じになっていることを忘れてBoseノイズキャンセリングヘッドフォンを持参してしまいました。 結果からいうと(今回は)問題なく接続できたため事なきを得ましたが、ここ最近微妙な接続状況だったことを認識していたのについつい無線式のヘッドフォンを持っていってしまい収録当日に慌ててしまいました。 事前に有線と無線両方を持っていくようにしたほうが良かったなと感じました。

次回からはiPhoneについている付属のイヤフォンを持っていくようにしたいと思います。 無線系のデバイスは接続トラブルがあったときのことを考えて有線式を予め用意するなどしたほうが無難ですね。 どちらをメインで使うのか?はさておきトラブルシューティングとしてあるほうがよいですね。

会場&Wifi問題

年末年始だったこともあり、軒並み会議室のレンタルやコワーキングスペースがお休み状態に……。 安定した回線と長時間話していても大丈夫な会場を用意するのは重要だなと感じました。 当初2時間もしゃべれないだろうと高をくくっていたのですが、トイレ休憩を少し挟んだだけでほぼ4時間くらいぶっ通しで喋ってました。 これはかなり想定外でした、もし貸会議室などを使う場合は延長できるかどうかを事前に確かめたほうがいいでしょう。

さらっと終わらせられなかった問題:

いくつかのトピックでShow Noteに「○○についてさらっと語る」とか書いてたのにめっちゃ語ってたり、ネタ枠として話すことがなくなったら話そうと思ってたトピックがめちゃくちゃ長くなってしまったりと想定外のことが多々発生しました。

ネタ枠はまだしも、サラッと話すところに時間がかかってしまっていたのは反省ポイントとして結構大きいかなと思っています。 「リスナーはそんなくだらないこと求めてないだろー、というかぼくならさっさと切り上げて欲しいって思う。」とか収録後の電車で1人凹んでました。 このあたりもうちょっと会話力というかサラッと終わらせれるようになりたいですね。 そう考えると #rebuildfm や #ajitofm のすごさがよくわかります。

まとめ:

いろいろ書いてますがまだ公開されていないということもありますし あまり書いてしまうとネタバレしてしまうのでこのあたりで止めておきます。

一応ep.30 楽しい2018年の強気な目標でぼくがゲスト出演することに言及しているのでこれくらいなら書いても大丈夫かなーという線を攻めつつ、ネタバレしない程度に抑えました。

エピソードが公開されたら各トピックの補足を書いて一区切りとしようかなと思います。

webdesign-manga.com

湊川さんが書かれている通り、ひょんなことから憧れのPodcast出演を果たしてしまいました。 どうやらこのエントリからゲストが出演決定しているという話しをTwitterPodcast内でお聞きしたので割りと期待しています。 個人的には「お、世界のMatzがしがないラジオ参戦か!」と勝手な妄想をたくましくしているので皆さんも期待して待っていましょう。 (実際に誰が出るとか本当に知らないのでなんでも言えてしまうメソッド)

Kyoto.rb Meetup 20171216

kyotorb.doorkeeper.jp

初参加してきました。

目的:

  • Rubyの理解度をあげる

目標:

  • 1章の写経を完了
  • 2章の写経を完了

LT発表:

SFCをむやみに使うべきではない in Rails(Single File Component)

発表者: shantti_y さん

HTML/CSS/JavaScriptがvueファイル内で完結している状態。 影響がそのコンポーネントに閉じ込められるのがいい。 LTを英語でしていてかっこよかった。

プロRuby

文字列の比較:

↓がよくわからない、文字に当てられている番号で比較している?という質問を参加者のかたにしてみた。

'a' < 'b' # true わかる
'a' < 'A' # false わからない
'a' > 'A' # もっとわからない

'abc' < 'def'  # true  わかる
'abc' < 'ab'   # false ?アスキーコードの合計値で比較しているわけでもない?
'abc' < 'abcd' # true  ???もしかして文字列の長さか?

'あいうえお' < 'かきくけこ' # true

プロRuby本にはさらっと書かれて説明がなかったのでこういうときコミュニティーで聞けるひとがいるのは心強いですね。

アスキーコードで比較されているんじゃないかな?

とのことだったのでググってみた。

Ruby リファレンス <, <=, >, >= (String)

文字列の順序は、バイト列の単純な比較によります。"α" < "あ"は、文字コードUTF-8なら結果はtrueShift_JISならfalseになります。

とあるのでバイト列での比較になっていた。 でもこんなトリッキーなコード書くことがあるのだろうか?

多分だがこの比較が発生し得るコードがレビューで来たらぼくならリジェクトすると思う。 少なくとも動作の予測が立ちにくいので別の実装を求めるか完全比較以外はリジェクトするかな。 入力される値がある程度決まっているなら配列とかに持たせてチェックさせる…みたいな実装する。

反省点:

いろいろ雑談やLTに対するコードの指摘などなどを行っていたらすぐに時間がなくなってしまったので 目標だった2章の写経完了まではいけていない。 もっと集中すべきだったか…。

追記:

著者の id:JunichiIto さんからフィードバックを受けていたのですがブログ側に反映し忘れていたので追記です(いまさら)

qiita.com

こちらの記事で捕捉されている内容が解答なのですが最終的にチェリー本を全て読了したあとでこのブログの内容を読み返したところ 気づくきっかけのようなものがチェリー本のなかにありました(具体的にどこのページだったかは忘れた) なのでとりあえずわからなかったところはメモして一読するのをオススメします。 そのうえでまだわからなかったらブログとかに書くとRubyチョットデキルひとたちが心優しく教えてくれると思います!

異文化理解力 ― 相手と自分の真意がわかる ビジネスパーソン必須の教養

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

luccafort.hatenablog.com

id:daiksy さんが以前開催した京アジャビブリオバトルのときにおすすめしていた異文化理解力をようやく読了した。

結論:

もし、あなたが少しでも「うまくチームが回っていないな」と感じるならば是非ともこの本を手にとって読むべきだし、可能ならメンバーにも読ませるべきだと思う。 もし、メンバーが読まないなら要約をしてメンバーに教えればよい。 せめて本著で紹介されている8つの軸を元に自分がどういう文化の人間であるか、どういう文化のチームであるか?は最低限見える化しておくとよい。

本著の対象者は全ての人類といっても過言ではないと思う。 それぐらい汎用的で実用性の高い話しが大盛り特盛りてんこ盛りな内容だと思う。

問題点:

さてここまで絶賛?しているがぼくは本著において実に重大なことが全編に渡って欠けていると感じている。 それはTeamGeekでいうところのHRTがメンバーに必要不可欠だということだ。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

どういうことかというと本著では異文化における違いを8つの軸から解説している。 会社のメンバーに対してHRTがないとどうなるのか?

端的に言ってメンバーを信用していないので「理屈はわかるが自分たちに当てはめるのは難しい」と感じてしまう。 つまりこれら8つの軸はまずHRTという根本の関係を構築した上で更に前進するための方策なのだと思う。

故にHRTがないチームにこの手法だけを取り入れようとしてもうまくいかない可能性があるのではないかとぼくは読んでいて感じた。 本著の問題というよりはチームとして崩壊しているところに手法だけ持ってきても仕方がない、というニュアンスで捉えてもらえればいい。 まずチームとして最低限の体裁を整えたうえで8つの軸にチームやメンバー、会社がどういう文化を持つのかを見える化していくのが重要であると思う。

理想の文化:

ぼくにとって本著を読んでどこに当てはめたかといえば現職の職場であり、チームであり、会社だ。 本著の8つの軸とは…

  1. コミュニケーション(ローコンテキスト vs ハイコンテキスト)
  2. 評価(直接的なネガティブフィードバック vs 間接的なネガティブフィードバック)
  3. 説得(原理優先 vs 応用優先)
  4. リード(平等主義 vs 階層主義)
  5. 決断(合意志向 vs トップダウン式)
  6. 信頼(タスクベース vs 関係ベース)
  7. 見解の相違(対立型 vs 対立回避型)
  8. スケジューリング(直線的な時間 vs 柔軟な時間)

となっている。

ぼくの中で理想的なエンジニア文化を8つの軸から抽出すると以下のようになる。

ローコンテキストなコミュニケーションで、 直接的なネガティブフィードバックな評価をし、 応用優先(帰納的思考)で説得を行い、 平等主義なリードによって敬意を得て、 合意志向な決断を下し、 タスクベース(認知的信頼)によって信頼関係が構築され、 対立してでも見解の相違を話し、 計画に引かれたスケジュールのとおり、直線的な時間で管理されている

この考えには一部強くアメリカの西海岸あたりの思想が混じっており、その影響をブログだったり書籍から受けている点は否定しない。

だがしかし、人によってこの理想となるエンジニア文化というのは当然異なっている。 会社としてもそうだし、個人としてもそうだろう。

そうしたときにいわゆるこの文化のミスマッチが発生する。

この軸と簡単な説明を事前に渡しておけば文化によるミスマッチは減るのではないかと期待している。

まとめ:

ともあれ、まずは会社、チーム、自分が理想とする文化を見える化し、そのうえでチームとしてどの文化で行くのか?会社としてどの文化を求めていくのか?を考えていくのが正しいのかなと思っている。

多くの場合、人は納得さえすれば文化的にかけ離れていたとしてもその決まりに沿って行動するのだ。 つまり、「チームとして上手く回っていない」というとはこの文化の相違による摩擦が起こっているのではないかと考えルヨ地がある。

少なくともぼくは現職に対して2つの相反する文化を感じており、それがうまくチームが回っていない原因かなと感じている。 どちらかがどちらかの手法に合わせる必要があるのだが、放置してしまっているせいでチーム間にギスギスした澱のような沈殿物が堆積していき、最終的に爆発するのではないかな?と考えている。

ところで異文化理解力を読んでると書いたところ幾つかのコメントで「あれいいよね!」と言われたのでやはり文句なく良書といっていいのではないかと個人的には思っている。

今週のお題「今年中にやっておきたいこと」

今週のお題「今年中にやっておきたいこと」

プロを目指す人のためのRuby入門

プロRuby本、もしくはチェリー本と言われるやつ。 先日参加したKyoto.rbで少し写経したり、読み始めたのでこれを今年中には読了&写経も含め読了したいと考えている。

テスト駆動開発

テスト駆動開発

テスト駆動開発

Rails Developer Meetup 2017でテスト駆動開発はいいぞ!ということで「まだみてないです、すみません…今年中にはなんとか」と発言してしまったので少なくとも読み始めることを始めるところまでは持っていく。 完読するのは今のペースだと1月中頃になりそう…。

Goでチャットアプリ作る。

最近Go言語書いてないよなーっというときに id:otiai10 氏の↓のエントリを読んで「やるか!」となったので年末年始を使って久しぶりにGo言語でチャットアプリを作ろうと目論んでいる。 これまた今年中にやっておきたいことじゃないけど。

otiai10.hatenablog.com

まとめ:

このタイミングで今年中にやっておきたいことが完遂間近でないというあたりに「お前これ全部今年中にやれると思うのか?」という心の叫びが聞こえてきますが硬く耳を閉ざして貝に私はなりたい。 とりあえずプロRuby本だけは今年中に読破するつもりなのだけど中々厳しい感じで第一次世界大戦中のドイツ軍もこんな感じだったんすかね?と最近幼女戦記読んでた影響で考えたりしています。 アバババ。