集中と選択

現在、まさに就職活動中なのだがブログやWantedly上でリモートワークに興味があると書いているせいか、企業側からリモートワークじゃないと駄目ですか?などの質問をいただくことがある。 ぼく個人としては関西圏であれば特段リモートワークに強いこだわりはない。 関東やそれ以外の地域だと引っ越すのがダルい諸々の事情があり可能な限りリモートワークでお願いしたいと考えてはいる。 ただそれもいま現在は…という条件であって将来的に東京に来て欲しいとかは全然OKかなと考えている。

で、なんでこんなことを書いているかというとぼくの中でのリモートワークというものに対する整理をしておこうと考えたからだ。

リモートワークのメリットとはなにか?

これは非常に明確で働く場所に縛られないということだろう。 他にも通勤がない、働く時間の制約が緩いなどなどあるが結局のところ一番はこの働く場所という依存性の解決が一番大きいのではないかと思う。

リモートワークのデメリットとはなにか?

自発的にコミュニケーションを取れないと孤立する。 もしくは成果で判断せざるを得ないため、同じオフィスで働く以上の成果やアウトプットを求められる。 セルフコントロールの求められるレベルが高い(オフィスで働くよりも)

大きな点はこの3つかなと考えている。 これはフリーランスで働いていたという人やリモートワークが可能な会社で働いている人に共通して語られたことなので恐らくそれほど的外れな内容ではないのだろうと思う。 (これ以外にも重要な点があればマサカリWelcomeです!)

リモートワークをどう捉えているのか?

ぼくはリモートワークはあまり良いものだとは考えていない。 同じオフィスで働くほうがコミュニケーションコストは低いし、認識の齟齬なども起きにくいと考えている。 これがタイトルの集中の部分だ。 全ての問題が1点に集中するが故のノイズなどもあるが基本的な効率としてはオフィスに出勤して仕事をするほうが効率が高いのではないかと考えている。

恐らく最初からリモートワークを導入している、あるいは経営層のかなり上のほうがリモートワークを推奨していない限りにおいて 途中から導入して上手くいく企業は少ないのではないかと考えている。 あまり途中でリモートワークを導入してうまくいっているという話しは見かけない気がする。

ただそれでもぼくは思想的にはリモートワーク推進派だ。 それはリモートワークは選択肢だと考えているからだ。 これがタイトルの選択にあたる、言わずもがなだとは思うが。

リモートワークという手段が取れる企業に実際にぼくが就職したとしても恐らくは殆どの場合オフィスに出勤するだろうと思う。 (朝は自宅で作業して昼からオフィスで仕事する…みたいな感じにはなるかもしれないが) ぼくにとってオフィスというのは仕事に専念する場所であり、それだけに専念するというスイッチが入る場所であるからだ。 ただそうはいってもオフィスはノイズが多い。 例えば集中したいときに「電話がなる」「同僚などに声をかけられて思考が中断する」などなどこの辺りは体感的にもわかるのではないかと思う。 集団で働く以上どうしてもこのノイズは一定数入ってくる、仕方のないことだとは思うが歯がゆさも同時に感じることがある。

そういったときに以前からぼくは「精神と時の部屋が欲しい」と言ってきた。 似たようなことは多くの人が感じたことがあるだろうと思う、ただこの問題は基本的に解決することがあまりない。 集中するための部屋を用意してくれるような余力のある企業でないと難しいからだ。

ところがもしリモートワークが可能ならどうだろうか? どこか邪魔の入らないスペースに移動して作業に専念すればいいだけだ、瑣末事に心を煩わされることがない(とはいえないと思うが頻度は激減すると考えている)

この辺の感覚はDeepWorkでも少し触れていたので万国共通なのだろうと思う。 また仕事をする以外のさまざまなノイズを遠ざけられるというのも大きな要因かなと思っている、特に通勤電車とか。 仕事をする前に人混みのもみくちゃにされて精神を疲弊してそれだけで帰りたいと思わされる、そのような事態を避けることが出来る。 DeepWorkに集中することができる状態を維持することが出来るのではないかと考えている。

良いことばかりではないし、自分がリモートワークに向いているかどうかは正直なところ自信がない。 だがしかし、日本は災害大国だし将来的にもリモートワークはより普及していくと思う。 そこにはいろいろな試行錯誤があるだろうと思う。 オフィスで集中して働くことがなくなるとは思わない、ただ将来的にコミュニケーションとコラボレーションの技術躍進によってリモートワークはより進化していくとぼくは考えている。

つまるところリモートワークは手段であって、それが使えるという選択があることが重要なのだと考えている。 というような考えを持っているということを書き出しておくので面接のときにいちいち聞かれなくなるといいなーという気持ちでいっぱいです。

同じことを説明するのは非常に面倒だ。 別々の企業ならそれも仕方ないかなと思うけど1次面接、2次面接と進んだ際に同じ企業内で同じ説明しないといけないのは端的に言って面倒以外のなにものでもないし、自動化したいという気持ちに駆られることが多々ある。

舟を編む

舟を編む (光文社文庫)

舟を編む (光文社文庫)

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

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

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

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

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

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

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

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

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

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

さいしょに

この度めでたく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からの刺客として登壇できるといいなーとか思ってるのでそのときはよろしくおなしゃす!!!