舟を編む

舟を編む (光文社文庫)

舟を編む (光文社文庫)

アニメから入ったにわかだが非常に良かった。 個人的には天地明察(ぼくの中ではかなり上位に位置する小説)と同じくらい楽しめた。 読了感が寂寞とした気持ちと清々しい春の陽気のように沸き立つ気持ちが撹拌されている、そんな気持ちにさせてくれる作品だった。

大きな流れはアニメと大差がなかったが緻密な心理描写であったり、情景の表現のされかたなどはやはり小説特有の良さというべきものに溢れており、原作厨のぼくとしては大変楽しめた作品だった。 アニメを見終わるまで小説を読むのを我慢していたわけだがその甲斐は十分にあったと思う。 最初はアニメと小説の些末な表現の違いや差異に気を取られることもあったが中盤にかけて怒涛の勢いで読了した。

元々の入りはアニメの舟を編むだったわけだがそれ以前から書籍名だけは本屋などで見かけることが多々あったため知っていた。 そのときは「江戸時代(もしくは明治初期)を舞台にした恋愛小説家なにかだろう」と考えていた。

舟という漢字から時代を感じ、編むという言葉から女性らしい柔らかさを想起したので勝手にそう思い込んでいた。 だからこそ書店でも手に取らずにいた(恋愛小説や恋愛漫画が苦手なのだ)のだがこれは大いなる過ちであった。 後悔している。

どうやら本作は映画化もされているようだ。 ボク自身は見ていないがこの内容は確かに実写化しやすかろうと思う。 あとは役者の演技次第と演出の仕方次第なのだろうけどもテ○フォーマーズや進○の巨人みたいなことにはならんだろうと思う。 比較的実写とは相性が良い作品だと思う。

普段本を読まない人に作品の面白さを伝えても多くの場合途中で読むことをやめてしまうか、最初から諦めてしまうケースが多い。 そういう意味ではアニメと実写映画化されているというのは非常にオススメしやすいように思う。

辞書を編纂するという恐らく世の中にある仕事の中でも日の目を見ることがほとんどない地味な仕事を こうまで熱量あふれる作品に仕立て上げてしまう三浦しをんという作家の素晴らしき表現力には脱帽しきりだった。

もしぼくが子を持つ親であったならば子供に是非とも読んで欲しい、そういう気持ちにさせてくれる一冊だった。 非常に堪能させていただきました。

試用期間で会社を〄たって話し

多分あまり巷にはないんじゃないかと思うので書いておこうと思う。

さいしょに

この度めでたく2月に入社した会社を3月末をもってやめることとなった。 理由は以前書いたエントリを読んだかたや実際にあって愚痴ってしまった人には察してもらえることと思う。 なお、件のエントリはブログを見つけられた(特に隠してないけど)ので同意の上で削除した。

試用期間で辞める3つの理由

試用期間で辞めることを決意した理由は大きく分けて3つある。

  • 上層部との間にHRTなどの信頼関係を構築出来ないと確信したこと
  • 求める会社文化が完全にミスマッチであること
  • 技術的なレベルが求めるものに到達していないこと

書こうとするとどうしても愚痴になってしまうのであっさりと書いてしまうとこんな感じになる。 一応上から順により比重の重い理由となっている。

上層部との間にHRTなどの信頼関係を構築出来ないと確信したこと

HRTが構築できないチームや会社で働き続けるのはお互いに不幸でしかないとぼくは考えている。 最初の2週間働いて感じたそのときの印象がその後も全く変わらなかったことが決定的になった。

この話しはどうやっても愚痴が混ざってしまうので聞きたいという野次馬根性のあるかたは美味しい紅茶か珈琲おごってください。

求める会社文化が完全にミスマッチであること

文化のミスマッチはなかなかつらいものがある。 ぼくが求める空気感を持っていた人が(たまたまそういうタイミングだったとはいえ)連続で辞めることになったのでより顕著に感じた。

元々ぼくが求めているスタートアップな文化やエンジニア文化とはズレがあったがより一層ズレを感じる結果となった。 正直、ぼくが望む文化は歓迎されていないのだなと感じたのでかなり精神的に摩耗した。

技術的なレベルが求めるものに到達していないこと

この中の順位としては一番低いが技術レベルがぼくが求めるレベルになかった。

詳細はこれも愚痴が入るので割愛、なお過去にそういった経験がないわけではない。 また、ぼくは自分よりも優秀なエンジニアと一緒に仕事がしたいと考えるタイプの人間なのでこの部分におけるストレスは決して無視できないものだった。 心を殺してお金を稼ぐためという我慢できれば…と一瞬思ったがそういう会社で働き続けることをボク自身がよしとしていないしそんな環境で働きたいとも思わないのでまあ結局遅いか早いかだけの違いじゃないかと思う。

本題の始まり

で、ここまでが辞めた理由という前段階の話だ。試用期間関係ないよね?って思ったと思われる。 本題はここからになる、安心して欲しい。 たいしたことは書いてない。

試用期間に辞めたらマイナスイメージつくんじゃないの?

正直これは採用する側でないのでわからないけど試用期間中(だいたい3ヶ月とか6ヶ月)に辞めようと感じるってことは会社とマッチしてないってことだ。 それは精神的にもつらいし、そのまま働き続ければ身体や精神を壊す。 最悪電通の痛ましい結果に繋がりかねない。

なのでぼくからのアドバイスとしては「試用期間でヤバいと思う会社はなにかしら絶対にヤバいのでとっとと辞めろ!」ってことだ。 なにがどうヤバいのか?は会社毎に違うがそこで時間を費やすよりももっと自分にあった会社で働いたほうが絶対にハッピーになれるとぼくは感じている。

試用期間中っていつでも辞めていいんでしょ?

調べたところ普通に会社やめるときと同じらしく最低でも14日前には申告する必要がある模様。 だいたいは1ヶ月前なんじゃないかな。 「じゃあ明日から来なくていい」と言われてもこれは法律違反なので拒否できるとのこと。 (但し本人と会社の同意があれば辞めれるらしい、お金が欲しいならここでYESといってはいけない。どうせ辞めるのだし嫌われてでもNOといっておけ!)

おわりに

ということでまたしても4月から無職生活になる。 ぼく個人としては担当していたプロジェクトがどう考えてもアレだったので4月中旬くらいまでになんとかある程度のレベルまで持っていこうと考えていた。 その間に次の転職先を決めてから辞めようと思っていたのだが想定外に早く辞めることとなった。 計画としてはズレが出てしまったがまあストレスから解放されたと思って前向きに捉えようと思っている。

次の会社は長く勤めれるような良い会社であってほしいなと思っている。 今年の目標としてはいろいろな勉強会にでてスピーカーとしてもなにかしらアウトプットしていきたいと思ってるので頑張るぞい!

「試用期間で辞めたいと思ってしまう会社はヤバいの中身は違えどだいたい辞めて間違いないのでさっさと辞めろ!」といったな? まさか自分が実践するとは思わなんだ

だいたいこんな感じです。 折よく?新入社員の人とかが増えるシーズンなんで辞めたきゃ辞めろ。 但しお金のことはきちんと考えてな!というアドバイスで締めたいとおもいますまる

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

前提条件

面倒くさいので最初に書いておくがここで書かれるエンジニアの対象はWebアプリケーションエンジニアやソフトウェアエンジニアをイメージしてもらいたい。 いちいちWebエンジニアと書くのがめんどいし、エンジニアとだけ書いた場合「エンジニアという主語がデカい」とかはてブされるのは鬱陶しい&ノイズなので最初に断っておく。

感想

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

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

読了した。 安定の #rebuildfm で紹介されたシリーズ。

最近年齢的なものもあるんだろうけども学習効率の良さをちょっと気にするようになった。 今までのやり方を今後も継続した場合、自分の期待値としての成長効率と現実の成長効率に大きな齟齬が出てしまうぞ、と。 そんなときにタイミングよく紹介されていたので購入して読んでいたが正直「やってみないとよくわからんな」というのが結論だ。 幾つか懐疑的な面や反論などもあるが全体的には試せるものは試してみようという気になっている。

「気になるけど買うのはちょっと…」という人は本屋などで一度ざっと目を通したほうがいいかもしれない。 ぼくは手元においておきたい!という強い欲求は得られなかった。 図書館で借りる、友人から借りるなどでも十分こと足りると思う。

本著は2部構成になっている。 第1部はDeepWorkとはどういう概念であるか?の説明を重点的に、第2部では偉人の例を取り、どのように生活や仕事にDeepWorkを取り入れるか?という方法論に重点が置かれている。

概要

概要自体は簡単で2つの働き方の概念についての解説やその状態を維持する方法やその目的などが書かれている。 なお、以下の概念はどうやら造語らしい(訳者のあとがきにそうある)ので誰かにドヤリングするときには気をつけられたい。

シャローワーク(shallow work)

  • 知的思考を必要でない
  • 新しい価値を生み出さない
  • 誰にでも容易に再現できる

これらの条件をみたすものを本著ではシャローワークとして本題のディープワークと対比させている。 いわゆる「人間がすべきでない」タスクと言えばエンジニアの方々にはイメージしやすかろうと思う。 エンジニアはシャローワークを自動化するのが本来のタスクの1つだと考えているので非常にこの辺の概念はわかりやすかった。

ディープワーク(deep work)

  • 集中した状態を必要とする
  • 新たな勝ちを生み出す
  • スキルを要し向上させる、容易には真似ることが出来ない

最初この説明を読んだ際にイメージしたのがDB設計であったり、クラス設計など設計をぼくは想像した。 ぼくは普段コードを書いているとき周りの音を遮断する目的で音楽を聞くのだけどもどうしてもそれをやめて真剣に頭を悩ませなければならないことがある。 それが↑の各設計のときだ(コードを書いてるときもあるがパーセンテージとして比べると低いという話し)

DeepWorkの存在価値

本著では「機械と人間の能力差は縮まり、雇用主は次第に"新しい人材"ではなく"新しい機械"を雇うようになるだろう」とある。 この問題はすでに顕在化している、わかりやすい例が「車の自動運転機能」だろう。 もし車を機械が運転するようになればタクシー運転手という職業はこの世から消え去るだろう。かつて馬車の運転手だった馭者がほぼ現代ではいないように…。

そしてこの問題はエンジニアであるぼくにとっても決して他人事ではない。 将来的に「ただコードが書けるだけ」のエンジニアの職はこの世からなくなってしまうだろうと予測されている。 ボク自身もそうなるだろうと予測しているし、そのことに対する危機感を抱いている。 但しそういう世界になっていくことは大歓迎だ! :)

本著ではそのような事態を避けるためにはDeepWorkが必要だという、DeepWorkという名称は本著によって作られたものだが概念としては決して新しくないとある。 哲学者のユングを代表に1900年代頃の偉人を例にして彼らのどういう点がDeepWorkだったかの解説が書かれている。 このあたりは正直興味がある人が読めばいい。

日本ではあまりまだ浸透していないがコミュニケーションとコラボレーションのテクノロジーの進歩でリモートワークの可能性が広がり、企業は重要な役割を優秀な人材に委ねる流れが今後より一層加速していくことになる。 そのときに切り捨てられるのは地元の人材なのだ…というようなことが書かれている。

切り捨てられない人材になるにはDeepWorkによって付加価値をつける必要がある。 本著では「何かを習得するには極度の集中が必要だ」とあり、そこでは以下の2つが重要だと書かれている

  • 特定のスキル、または極めようとしているアイディアにしっかりと注意して集中する
  • 最も生産性の高いものに注意を向け続けるためにあなたのやり方を正すためことができるフィードバックを受ける必要がある

これだけ読めばどこにでもある内容なのだが本著ではそれを実行するためにどういう状態であるべきかが書かれている。 気になるかたは本著を手にとると良いかもしれない。

懐疑的

但しいくつかの意見に関してはぼくは懐疑的なものを感じている。 例えば↓の例がわかりやすいだろうか。

あなたが最高の生産性を発揮するには気を散らすことなく、1つの仕事に全面的に集中する必要がある

これに異論を唱えるひとはいないだろうと思う。 ただ現実に行えているひとはあまりいないのではないだろうか? それは個人単位で仕事をするということが少ないからだ、これをチーム単位で仕事をする場合どうなるのか? あるいは外部からの依頼や取引、会議などがあった場合は?

本著ではこれに対しても一応の解答を出している。 ざっくりとかなり乱暴な意訳をしてしまえば「それらの煩わしいものごとが差し込まれる状態を回避せよ。具体的には引きこもれ」だ。 このような対応を行えば当然DeepWorkは出来るかもしれないがチームの評価としては非常に下がるし会社側からも注意されることだろうと思う。 (とはいえこの対応に関する問題点は著者も理解しており、第2部の後半に対応策を明示している)

そういう意味においてはこれらの解決策を求める人にとって(つまりはぼくだが)はあまり明確な解決策が提示されているとはいえないかもしれない。

まとめ

本著は基本的に同じことを繰り返し述べている。 以下はかなり暴力的な意訳なのであまり真に受け取らないでもらいたい。

  • 重要なことを明確化せよ、重要でないものは出来る限り取り除くかまとめて処理してしまえ!
  • 明確な指標がないと人間は多忙さを生産性の指標に据えてしまう。(ShallowWorkを多数こなしたことで仕事をした気になっている)
  • ShallowWorkが悪なのではなくDeepWorkを阻害されることが悪なのだ

個人的に特に面白いなと感じたのは「注意力回復理論(ART)」という理論だ。 この中では自然の中で歩いたりすることで注意力が回復する(実際には注意力を要する行動が減っているため相対的に回復している…ということだと理解している)とある。 また同じように夕方以降はその注意力の残高が少ないためDeepWorkを必要とする仕事には向かない、あるいは夕方以降の仕事は延期しても問題ないと述べている。 この考えが非常に面白かった。

確かに言われてみれば夕方以降(特に16時以降)に妙にコーディングが捗るということを幾度か経験したがそのようなときはだいたいどう実装すればいいかが明確であり、 設計などのDeepWorkを必要とするタスクがなく、ただひたすらにコーディングに専念すればいいという状態が多かったように思う。 これは深夜にコーディングが捗る(割り込みやノイズが少ないという影響もあるだろうが)のも同じ理由かもしれないと妙に得心した。

さいごに

本著にいま現在の課題を直接的に解決する方法を求めるひとにとってはあまり良書とはならないかもしれない。 とはいえ、このDeepWorkという考え方は非常にユニークであると同時に興味深いものがあると思う。 直接的な問題解決を求めるのではなく、今後の将来的な観点にたって本著を手に取るというのはあるいは良い選択肢なのかもしれない。 それに駄目だったとしてもせいぜいが1600円ほどで3時間かそこらの時間の浪費だ。 決して高すぎるコストではないのではないかと思う。

おまけ

amazonレビューについて

Amazonレビューで以下の意見があった。 ぼくは本著を大絶賛しているわけではないけども少し書かれている意見の筋が悪いように感じたので読了したものとしての意見を書き出しておこうと思う。 なおこの意見を否定する意図はない、ただ読了したボク個人の感覚とレビュアーの感覚がズレているように感じたので書き出しているだけである。

原作者の文章もひどければ、翻訳者の翻訳もひどい。適当に一文抜粋してみる。

それぞれのツールについて、あなたが定めたカギとなる取り組みを検討し、そのツールを利用することで、その取り組みに"十分なプラスの影響"または"十分なマイナスの影響"があるか、ほとんど影響がないかを問う。

はっきり言って最低品質。

追記: 1点補足しておくと、本書の購入動機は、 「気が散るものだらけの世界では集中することが重要だ」 という問題提起が鋭かったので、その解決策を期待したからだ。

ところが、その処方箋を期待する読者は(私と同様に)裏切られる。 問題提起の良さに対して、処方箋はインターネットのつまらないライフハックと大差ないのである。 さらに上述のように地の文がひどかったので、総合して最悪な読書体験であった。

この翻訳が酷いという点はある意味では正しい。 自然な日本語としては受け入れられないだろうと思うし集中を乱される可能性は十分ある。 但しそれをもって本著の価値がないとはぼくは思わない。

この翻訳を「原文の意図を正しく伝えるために敢えて不自由な日本語として残した」とぼくは好意的に解釈している。 これが正しいのかどうかはわからないが少なくとも日本語としては不自由であっても意味不明なレベルにはなっていないと考えている。

インターネットのつまらないライフハックと大差ないという意見に関しては半分同意、半分否定というところだろうか。 結局のところ煩わしい事柄に対処しようとするとどうしても似通った部分が出てくるのは仕方ない。 ところが本著はその理由を「こういった点から遠ざけるべき、但しそのためにはこれこれの基準を満たしていること」という根拠を示している。 ぼくはこの1点において「つまらないインターネットのライフハック」とは一線を画すと感じている。

この方にとっては期待したものではなかったのだろうと思うがボク自身は本著を読んだ結果、この批判は少し的外れだと思っている。 もしこのAmazonレビューを読んで買うかどうか迷っている方は参考にして欲しい。

フレームワークの選定

先日↓の話題がちょっとだけ社内で話題になった。

www.webprofessional.jp

個人的にこのエントリは以下の点からあまり真に受けるのは良くないと考えています。

他のフレームワークLoverな方々からはもっとマサカリが投げられると思いますが ぼくが感じただけでも「この内容はちょっと恣意的じゃないか?」と思いました。

ぼくはまだLaravelを使い始めて日が浅いですがそれでもLaravelの設計思想やわかりやすさなどに好感を持っています。 CakeやZend、Symphonyなどよりは好みなフレームワークであると思っています。 (FuelPHPやYiiはあまり馴染みがないので比較できていませんが…) ですがこの内容には少々懐疑的…というか否定的です。

Laravelが優れたフレームワークであるということをぼくは否定しません。 明快な設計思想ですし、MVCの基礎がわかっていれば非常に扱いやすいPHPフルスタック(?)フレームワークだと思います。 ですがそれは他のフレームワークを引き合いに出して比較する必要はないことだと考えます。 閑話休題

何が問題か?

さて本題に戻りましょう。 この問題は要約してしまえばこの1点につきるのですが

「プロダクトやチームによって最適なフレームワークは異なる」

という大前提を抜きにして考えてしまうケースがあるということです。

この辺の話しはフロントエンドフレームワークの話しではありますが先日参加した ng-kyoto#5 の↓が非常にわかりやすかったですね。

www.slideshare.net

問題あるある

たまにエンジニアと話していると「やっぱりこれからは○○だよね!△△はもう時代遅れだよ!」のような発言が飛び出すことがあります。 だいたいこの発言には「△△の何がデメリットで、○○のなにがメリットか」がセットになっています。

ですがその中でまれにこのメリット・デメリットの説明がセットになっていないことがあります。 そういう場合、ぼくは「あ、この人は流行りに乗っかってるだけで思考停止してしまってるんだな…」と感じます。 だいたいまあそんな感じの人が多いという経験からも大きく外れることがなかったですしね。

では問題の詳細はどこにあるのか?

しょせん、言語やフレームワークというのは手段でしかないです。 手段に固執するというのは非常にわかりやすい危険信号ですね。

補足

なんか手段を目的にするのは悪!みたいな書き方になってますが自覚があればOKかなと思ってます。 例えばGo言語で開発したい!なのでGo言語でバリバリ開発している○○社に入社します!とかは全然ありだと思いますし、気持ちもわかります。 問題だと思っているのはこの辺が無自覚な場合ですね。 無自覚に手段が目的化している人というのは他人の意見や客観的な判断が出来ないことが多いので駄目になったとき「めんごめんご、やっぱり○○は駄目だったわ、あれはクソだね!」とか言い出して死ね!ってなりますね。 これはボク自身も含めての話ではありますが。 補足終わり。

当たり前の話しですが会社やチームによって知識や技術的背景というのは異なります。 先程の資料では「マトリクスを書く」ということでその部分の見える化を行っています。

本来フレームワークのような影響力の大きなものはこのような経緯を踏んだうえで選定されるべきだとぼくは考えています。 (これは過去に自分がそれを出来なかったからこそ、より強く実感している内容でもあります。)

つまりはまとめにある以下の手順が守られる、あるいは意識されていればOKです。

  • 現時点でどれだけ知識/技術があるか
  • 要件を整理して、ベター(もしくはベスト)な選択か判断
  • 危険を察知したら"いつもの"を使う勇気

ボク個人として追加するならば「チームとしての合意を取る」が必要かなと思います。 「今度の案件はこれが最適だと思うのでこれでいきます!」となったときに周りを巻き込みやすいからですね。 また合意が取れていれば駄目だったときに「こういう風に考えていたけど○○な点が駄目だった、難しかった」という振り返りの材料にもなるかなと。

まとめ

新しいものは既存の問題を解決するために開発されている。

基本的にはぼくは新しいものに手を出すのが好きですし、楽しいと思っています。 ですがそれは「プロダクトや案件、チームにとってベターな選択かどうか?」とは別軸の評価です。 きちんとマトリクスで見える化していこうな!って気持ちです。

以上、終わり!

Amazon Web Services実践入門

Amazon Web Services実践入門 (WEB+DB PRESS plus)

Amazon Web Services実践入門 (WEB+DB PRESS plus)

今回は実際に写経というか手を動かしながらやったわけではなくて 網羅的にどういう機能がありそれらを触りながら覚える前に一通り目を通して理解するのが目的だったため 実際にインスタンスを立ててゴニョゴニョしたりはしていない。

元々目次を読んだ段階で期待はしていたが大まかなAWSの機能などを知ることが出来たので目的としては達成できた気がする。 ただ予想を超えるような驚きはなかった。 せいぜいが「AWSというサービスはまさしく金の弾丸で殴るサービスを地で行くのだな」と感じたことくらいだろうか。

その代わりAWSという巨人に乗っかれるのでその分のお布施だと考えれば安くないがべらぼうに高いわけでもないのかなという印象だ。

中身に関してはAWSに詳しくないもののおおよそ漠然とどういうことができるのか?が把握できるようなものに仕上がっていると思う。 実際のブラウザ上でどこを操作するのか?やaws-cliを使用する際のコマンド入力の内容やそこで表示された項目の説明など必要十分な情報と密度が兼ね備えている。

というわけで実践はしていないけど入門用としては十分な内容になっていることと思う。 ぼくの使いみちとしては個人開発でサーバーサイドをRailsで行おうと考えていて、そのインフラ部分をAWSで構成しようと思っている。 そのときに必要な機能を使いたいときに辞書のようにペラペラ捲って確認する書籍として手元においておこうかなという感じだろうか。

AWSを業務で一部のみしか使っていない、AWSは知っているが使ったことがない人向けの書籍だと思われる。 業務でバリバリに使っている場合はもっと詳細に書かれた書籍かAWSに詳しいかたのブログを読んだほうがいいんじゃないかと思う。

ng-kyoto meetup #5 に初参加してきた

公式サイト

ng-kyoto

リンクは#3となっているが気にしてはいけない、今回は#5だいいね? connpassはこちら

感想

初参加で知り合いがほぼいない中、この手のイベントが久々だったということもあって最初こそ緊張したけどもそこは良い意味で緩い雰囲気に当てられたのか割りとリラックスして聞けました。 惜しむらくはぼくはサーバーサイドエンジニアでフロントエンドに疎いところがあって一部話している内容についていくのがキツかったり単語や名称自体知らないみたいなことがあったことでしょうか。 その辺もうちょっと知識があれば質問とかも出来たのかもしれないと思うとちょっと残念でしたね。

参加した目的

1番の理由は @takapyyy さんの「フロントエンドフレームワークの選び方」がちょうど個人開発で作成する予定のフロントエンドのフレームワーク選定の参考になりそうだなーというのが動機の一番大きな目的ですかね。 (なおconnpass登録時のタイトルは「Angularを触ろうと思うまで (仮)」だった) この辺のAngularが何向きなのか?とかReactの強みとは?とかVue.JSはなにが優れているのか?みたいなのが触りくらいしか理解できてなかったので聞いてみたかったということですね。 JavaScriptにおける大規模ってどれくらいからなの?みたいな。

実際に発表聞いた感想とか

フロントエンドフレームワークの選び方が一番気になっていた話しだったのでかなり集中して聞いていた。 当たり前の話しだけど「プロダクトにあったフレームワークを選べ」ということ。 チャレンジするのも勇気!だけど時には「いつもの」を選ぶのも勇気!というのが非常にしみた。

個人的な感じた内容や他の発表者のかたの内容から推測すると Angular > React > Vueの順に大規模→小規模な感じだと理解していて、規模感や学習コストなんかを懸案した上で採用するのがベターな選択肢だなという当たり前の結論に達した。

個人開発するものに関してはそこまで大規模にはならないし(する予定はない)SPAにする予定もないのでVue.JSが無難なのかな?という仮決定を出せたので参加してよかったと改めて思った。 ReactはReact-nativeを触った感じだと非常にわかりやすいし、現在のデファクトといってしまって問題ない感じなので最後まで悩んでいる。 それもあってまだ仮決定としている感じだ。 (ただ多分Vue.JSでほぼ決まりかなと思ってる、Reactである必要性が今のところない)

追記: 「TODOアプリは面白くないからオススメしない」とあるけどもこれには以下の理由から完全な同意が出来ないとぼくは考えている。 興味のある分野のアプリを作るが示された選択肢の中でもっとも最善手だとはぼくも思うが興味がある≒学習に最適だとはぼくは考えていなくて 例えばTODOアプリでは一通りの機能を触れるけども特定の興味をもった分野でのアプリの場合、利用する機能や実装が特定のものに偏ることがある。 これが悪いとは一概にいえないのだが初期段階などではぼくは広くいろいろな機能を触っておくべきだと考えているのでそういう意味でもTODOアプリを作成するのは意味があると思っている。 とはいえTODOアプリを作るのがつまらないと感じているのに敢えてやるほどのメリットはないとも思う。 個人的な進め方としてはTODOアプリなど一通りの機能を触るものを作ってから興味のある分野のアプリを作るというのがボク自身の進め方になる。 TODOアプリじゃなくてチュートリアルやればだいたいこの手の内容は解決するんだけどもちょっと気になったので追記しておいた。

他にもいろんな方の発表があって久しぶりにどっぷり技術の話しに浸かれたなあと思いました。 やっぱりこういう勉強会というか技術発表の場に来るのは刺激を受けることが出来るのでいいですね。

他にも実務で使うAngular-CLIの話しやAngularでGUI Animationの話しが個人的に興味深かったですね。 突発LTだった難しいよね、コードレビューも面白かった。 でっかいPR来たらどうすんの?(きみたちどうしてるの?)というLTerからの質問に会場内で解決策が出なかったのは残念だった、非常に知りたい内容だった。

ちなみに今ぼくがいる会社はPRで開発をしていて以下の条件を通過したものをマージすることにしている。

  • コードレビュー済みのPRのみマージ(緊急時などは除く)
  • 必ずレビューは全員のOKをもらう
  • マージ後検証用の環境にデプロイし目視チェックを必ずプロダクト参加メンバー全員に課している

これはプロジェクトの規模がそこまで大きくないからこの手法で成り立っているけどもOSSのような大きなプロジェクトなどでは通用しないだろうと思う。 みんなデカい修正内容のPRが来たらどうしてるのか教えて欲しい。

あと「宗教戦争になりがちな話題はコーディング規約に先に書いたものが勝ち、それに関する議論は別のIssueでやれ!」という意見が個人的にツボった。 いいアイディアじゃねえか!

懇親会の話とか

懇親会はめっちゃでかいピザが届いて「おいおいこれ食いきれるのか?絶対残すやつじゃね???」と思ったが綺麗になくなったので良かった。 カラムーチョうまかった、安定感だいじ。 お酒以外にもソフトドリンクがあったので下戸なぼくには非常に助かった。

懇親会ではフロントエンドの話しがでたかと思えばヨーヨーの話しがでたりWeb Assemblyから始まった話しが最終的に最近のミニ四駆はすごい!みたいな話しに繋がったりで楽しかったですね。 ちなみに光るヨーヨーの動画みて「これ伊藤直也さんみたい!」といった犯人はぼくです、さーせん。 いやでも光るヨーヨーに30kはさすがに出せない!><;

ともあれぼくに近しい、でもぼくよりも若いエンジニアのパワフルさに圧倒されつつも「サーバーサイドエンジニアだからとかフロントエンドエンジニアだからとかもう言ってるやつは死滅していくだけだな、ぼくも頑張らなければ!!!」みたいな焦りと高揚する気持ちとがないまぜになっているので頑張って個人開発進めようと思います。 とりあえず来月以降は今登録してる勉強会とかセミナー以外は参加せずにガッツリ開発に専念しようと思う。

さいごに

だいたいこんな感じかな。 お名前だけはやたらとよく拝見していたこざけさんにも挨拶出来たし、いろんなエンジニアのかたと話せたり、個人開発の選択肢がおおよそ決まったりと得るものが多い日でした。 次はVue.JSからの刺客として登壇できるといいなーとか思ってるのでそのときはよろしくおなしゃす!!!

良いチームと悪いチーム、その差。

最近よく「良いチームとは?どうあれば良いチームなのか?」という疑問をずっと抱えていたのだけども結論が出ずに堂々巡りをしておりちょっと困っていた。 ところが今朝はてブみていたら id:hase0831 さんが明確な答えを示していてくれて「そうか、これが足りなかったのか!」という気づきを得た。

hase0831.hatenablog.jp

技術力が決して高いと言えない開発チームで働いたときに「このチームは技術的課題はあるけども良いチームだな」と感じることと「このチームは技術的課題云々以前の問題がありすぎるチームだな」と感じることがあった。 両者にはある程度共通する(というか内容の根本自体はほぼ同じ)課題や問題があって「じゃあなにが良いチームと悪いチームを分ける分水嶺になっているのだろう?」と考えていた。

技術的レベルにおいては双方ともに同じようなレベルだったのだが明確にチームとしての明暗が分かれているように感じた。 TeamGeekなども読んだけども結局のところ、この疑問の解決や決定的な分析は図れなかったのだけどもここで挙げられている3つの点におけるアプローチが違うということに気づいた。

悪いチーム

恐らくわかりやすいだろうと思うので悪いチームからのアプローチを紹介する。 これらの状態に陥っている場合はチームが機能していない可能性が高いと思うので早急に改善すべき状態だといえるだろう。

Why?まで落とさず作業を進める

よく言われる内容だが「何故それをすべきなのか?」が説明されないまま仕事をすると多くの場合以下の問題が発生する

  • 指示したものと違う提出物があがる
  • 見た目は指示したもののように見えるが実体が異なる
  • 指示されたものにはなっているが将来的な課題に関する対応策が検討されない
  • 指示されたことしか行わない

これらの話しがでるとよく「指示の裏にある意図を作業者が汲み取って欲しい」ということを言われる。 この意見は一見正しいのだけども「指示の裏にある意図を指示者が伝える」のも同じくらい重要だと考えている。 これらはどちらかだけでは成り立たなくて悪いチームはどちらかに押し付ける形で仕事をしていることが多いように感じた。

これらはある意味でコミュニケーションにおける問題だと考える。 そのための解決策は「飲みニケーション」などではなく、「正しく伝える努力」と「正しく理解する努力」を双方が理解することだと思う。 悪いチームはだいたいこれらの努力の方向性が一方通行であることがほとんどであるように思う。

作業者からすれば「指示された通りにしたのにリジェクトされた」と不満が溜まるし「そもそもなにがしたいのか?」というWhy?が共有されていないのだから どうなっていて欲しいのか?将来的にどう発展させるのか?という将来像が見えずただ言われたことをそのまま行うという最悪の状態になる、悪循環のループが完成する。

この状態が何故最悪かというと「何故こんな状態になっているのか?」という問題が発覚したときの分析時に「指示された通りにやりました、私の責任ではありません」という責任の放棄となすりつけあいが発生してしまうからだ。 そしてその悪循環に疲弊したメンバーから辞めていくことになる。

こうなるともうチームとしては崩壊している状態といえる。 マネジメント権限を持つ人間はこれらの問題が発生する前に対処する必要がある。 正直このような状態からチームを立て直すのはかなり厳しい状態であると思う。

これらの問題をマネジメント権限を持つ人間が検知するには 「指示されている内容がわからない」「なにがどうなっていればいいんですか?」 というような意見が作業者から出たら限りなく赤に近い黄色信号になっているのでなにがどう足りていないのかを検討すべきである。

全員の持つ情報粒度にバラつきがある

全員が同じ情報を全て知っている必要というのはないと思うが「誰が知っているのか?」「どこに情報があるのか?」が共有されていないとチームメンバー間に温度差が出来てしまう。 この温度差というのはやっかいで検知するのが難しい。 ただこの温度差というのは不平不満の温床になるので出来る限り無くす、それが難しければ温度差を軽減する必要がある。

件のブログでも危ういところまでいったとのことなので情報を管理する人は特にデリケートに扱う必要があるのだと思う。

大まかにでも「ここからここまでは全員が知ることのできる情報」「ここからここまでは管理者のみが知り得る情報」というようなカテゴライズをするくらいしか解決策が思いつかない。 しかしそうすると「この情報はどっちなのか?」という例が必ず浮上してくるし、その対処に悩む内にうやむやになってしまうパターンがほとんどなのではないかと思う。

TED Talkだったと思うが今まで機密情報だったオープンにして誰でも閲覧可能にしたところ業務効率が飛躍的に向上した、情報に機密性を持たせることによるメリットよりもデメリットのほうが大きいという話しを以前なにかで読んだ(もしくは見た)がチーム単位であればそれでもいいかもしれないが会社規模となるとなかなか難しいのではないかと思う。 ただそういう方針を話しあったり常にブラッシュアップしていけば温度差というのは非常に小さい影響で収まるのではないかとは思う。

またこれらの温度差をキャッチアップする方法として1on1などの手法はあるが結局のところこれらは「どうせ言っても無駄だろう?」という諦めをメンバーが感じてしまった段階で意味がなくなってしまう。 信頼関係が構築できていないところに手法だけ持ってきても意味がないのだ、まずは崩れてしまった信頼関係を構築するところから初めなくてはいけない。

「違う」「間違ってる」しか伝えない

これは最初のWhy?にもかかる部分があると思うのだけど悪いチームというのは最初のWhyが出来ていないせいで期待したものと違うものがあがった際に「これは違います」としか伝えないことがほとんどだと言っていい。 明らかな不具合、例えばブログのエントリを投稿したのに表示されていないとかならそれでもいいと思う(というか普通に考えて大問題だしそれで伝わらないのは別の意味でやばいと思う)

ところが多くの場合は「ここのAという部分が期待した動きになっていない」「このBという表示が本来B'になっていて欲しいのになっていない」というケースが多い。 悪いチームはこの説明を後出しでいうことが多い。 当然、作業者側からすれば「最初に説明しろよ!」と不満が溜まる。 結果チームとしての空気は悪くなるし指示者に対する不信感も募るため「言われたことしか行わない作業者」が出来上がってしまう。

言われたことしかしない部下や社員がいると嘆く前にまず指示者は分析をすべきだと思う。 だいたいの場合は嘆いているだけで作業者側からすれば明確な理由に対する対策が行われていないことが殆どであるように思う。

良いチーム

Why?まで落とさず作業を進める

良いチームは多くの場合伝え方が上手いことが多い。 「Aの機能を追加してほしい、以前似たような実装をBプロジェクトのCに実装してある」などとしてどういう状態が理想なのかを具体性を持って説明する。 これを受けた作業者は当然Cの機能を元に考えるため車輪の再発明を行わなくて済むし、具体的なイメージとしてC機能があるため指示者とのズレも最小限となる。 また「C機能をそのまま使えない理由はなにであるか?」とか「今後この機能はD機能に移行していくことが予想されるので移行が簡単に行えるように実装しよう」と考えることが出来る。

これはWhy?がきちんと支持者と作業者間で共有されているからだろうと思う。

全員の持つ情報粒度にバラつきがある

良いチームの場合「これは全員が知ってる(知っていない)」が明確であることが多いように思う。 そして「このことなら社内のナレッジツールでみたことあるよ!」とか「それは○○さんに聞けばわかるよ!」とかってパターンが多い。 この例でいうなら○○さんが管理者しか知りえないことを知っているという認識がおおよそ全体に認知されていることが大事という話し。

駄目なチームは「誰に聞けばいいのかわからない」が共有されてしまっていることが多いが良いチームは全く逆で「誰に聞けばいいか」が明確なため 「こういうことを聞くのは誰かわからない」というときに「○○さんなら知ってるんじゃないか?」という質問しやすい空気につながっているのだと思う。

「違う」「間違ってる」しか伝えない

良いチームは「ここは出来ればこうしてほしかったですね。」とか「こうやれば次回からはもっと早く実装できますよ!」などOKなときでもどうしてほしいかをきちんと伝えることが多い。 ここが悪いチームとの決定的な差かなと個人的には思っている。 こういう小さな信頼の積み重ねや1つ1つの事柄に対する信頼感がチームを育てるのだと思う。

まとめ

気づけばそこそこ書いているが結局のところ悪いチームの駄目なところっていうのは共通してるけど 良いチームの良いところっていうのはそのときどきやメンバーで変わってるという印象以上のものがないんだよね。 ということで凡人たるぼくらが出来ることは潰せるデメリットは早めに潰すという対処療法しかないのだよ。

前職の同僚によく言われたことだが「一気に変えることは出来ない(難しい)ので少しずつ変えていきましょう」ということですね。 これが出来るからこそ良いチームなんだと。