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

よく来たな?ここはチラシの裏だ。電脳世界に人格などというゴミを持ってくるんじゃあない。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

さまざまな会社を転職してきて思うことの1つに「良いチームや良い組織とはなんだろう?」というのがある。

TeamGeekを読んで良いチームには必ずHRTがあることに気づけたし、Elastic Leadershipを読んで良いリーダーは自分がどうやれば成長できるのか苦心してくれていたなという気付きも得ることができた。

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

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

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

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

なのだけども、ではどうすればよい組織やチームになるのか?という疑問にはなかなか明確に答えがこれだ!と言えるものを実感できていなかった。 TeamGeekやElastic Leadershipは良いチーム、あるいは組織という下地があった上でのストーリーなのかなと感じる部分があって、いわゆる「イケてないチームや組織をどう改善していくのか?」に対する明確な答えという点では力が不足しているように感じていた。

カイゼンジャーニーなども読んだがなんというか理想論仕立てな面があって、うーん?と思ってしまう面があった。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

実際にカイゼンできる面もあるんだろうけどもそうではなくプロジェクトやプロダクトレベルではなく、組織そのものが抱えている問題に対してどう解決をはかるのか?がいまいち不鮮明な状態で頭にもやがかかってしまっていた。

それはどうしてそうなるのか?という背景やそのためのロジック面において納得がいっていなかったからなのだろうと今にして思う。 もちろんそれらの書籍にも改善するための方法が書かれていたのだけどそれは方法、つまり「How to(どうやるのか)」であって「What to(何故やるべきか)」が腹落ちせず、消化不良を起こしていたのだろうと思う。

これらの書籍を読んだ当初はこれらの内容に関しては自分のマネジメントや前提となる知識に甚だしい知識の不足があるのだろうと思っていたのだけどもこの「エンジニアリング組織論への招待」を読んだことで一応の解答を得られたかなという気がしている。

とはいえ、こういう要因があるということがわかっただけで実践するためには必要になるものがまだまだ足りているわけではない。

この書籍、非常に興味深く読めた。 その割りにはサラサラと読め進められていたので読書スピードの早い人は1日で読み切れるのではないだろうかと思う。

この本は各章ごとにテーマがあり、1章は個人、2章が1on1(メンター&メンティー)、3章がアジャイル、4章がチーム、5章が組織という構成になっている。

各項目で重複する内容があるのだがそれぞれの立場やテーマが違うのでここで同じことを言ってる背景にはこういうものがあるよという強調になっているので割と中だるみせずに一気に読み切れた。

(あとで知ったがAmazonのレビューで繰り返し同じことが書かれていた点を冗長と表現されていたがこのあたりは強調と取るか冗長と取るか判断がわかれると思う。)

また今いる会社がエンジニアが足りないねという話しを以前からしており、自分にもこれらの役割を求められていると感じていたなかで読めたということもあって非常にタイミングが良かったように思う。

今まで少人数のベンチャー会社にジョインしたことはあったけどもそれは2か3→10にしていくぞ!という感じで1→2や3へのフェイズではなかった。 なのでいざ自分がそういう立場になったときに「やったことがないので何をどうすればいいのかわからない」というまさしく不確実性に起因する不安がそこはかとなく心の内側にわだかまっていた。

一応そういう話は月に1度、CTOか外部の技術コンサルタントのかたと1on1を行って話していたのだけど解消とまでは行かず、またどうしても普段の仕事のほうにフォーカスがいきがちだったなと読了後に感じた。

本来はそこを解決したかったのかもしれない、コーチングって難しいなと改めて感じた。

また外部の技術コンサルタントのかたが1on1のときに「PCを開いてパチパチやってるけどこれは1on1で気づいたこと、気になったことなどをメモするのが目的だから話しに集中してないわけじゃないよ」と言っていて「いやそれはわかるけどいちいちそんなことを相手に伝えるなんて律儀だなー」と思っていたがそれが間違いであったことに気づいたりと日々の仕事で何気なくしていることにもどういう背景があるのか、どういうことを気にかけてくれているのか?ということがわかったという点だけでも読んだ価値があったかなと思っている。

個人的な感想としては1章、2章が一番知りたいところであり、一番時間をかけて読んだ箇所でもあった。 だけど3章のアジャイルに関しては正直いまのチームでやれていることが多くあり、「今のチームの進め方で間違っていなかったな」という自信を補強はしてくれたがあまりクリーンヒットを繰り出すようなものではなかったのでさらっと一読だけしてさっさと次に進んでしまった。

もし前職のシーズで働いているときに読んでいたらまた違った印象を受けたかもしれない。

第4章と第5章に関しても、まだ実際にそういう立場になっていないからかいまいちピンとこないように感じた。 ここの話し、例えば「4-2 スケジュール予測と不確実性」や「5-3 技術的負債の正体」に関しては面白く読めたのだけど他の項目はさらりと流してしまった。

ぼくが先頭にたってチームを引っ張っていくような立場になったときに読んだらまた印象が変わりそうだなと感じたけども今の時点では一通り目は通しただけで終わってしまっている。

Kindle版で買っているのでまた必要になったときに引っ張り出して読めばいいかな。

似た本としてティール組織という本があり、そちらは購入はしたがまだ未読なのでこちらも合わせて読むといろいろな組織における知識の補強がされそうな気がする。

ティール組織――マネジメントの常識を覆す次世代型組織の出現

ティール組織――マネジメントの常識を覆す次世代型組織の出現

個人的にはオススメな本なんだけども一方で誰にでも進められるかというと気がかりな箇所もある。

ぼくは良いチームも悪いチームも良い組織も悪い組織も体験してきたので非常にどの項目もそのときの記憶から書かれた内容がイメージできたのだけどこれは今までの体験があったからイメージできたのかな?と感じる点があった。

そういう意味でいうならばこれは新卒で会社に入って2〜3年目くらいに読むのが最高のタイミングでそれ以前に読んでもバズワードの説明書以上の価値を見出すのはもしかしたら難しいのかもしれない。

Amazonのレビューをみていると実際にどうなのかはともかく実践するには難しいのではないか?といったレビューやなんだかよくわからないというコメントがあった。 今現在素晴らしいチームに所属している人には刺さりにくかったり、あるいはその真逆でいま飛んでもなく酷いチームで働いていてそれが普通だと思いこんでしまっている人には不可能な理論を展開されてしまっているように感じるんじゃないかなという気がした。

Elastic Leadershipのことをぼくは良書だと思っているんだけどその良書の下地にこのエンジニアリング組織論への招待があるのかなと読んでいて思った。 なのでElastic Leadership読んでからエンジニアリング組織論への招待を読むと納得感がますかもしれない。

またElastic Leadershipを良書だと感じた人ならこの書籍を興味深く読み進められるだろうと思うのでオススメです。

v-kansai Vue.js/Nuxt.js meetup #1

Vue.jsのコミュニティーができたということで第1回に参加してきた。

vuekansai.connpass.com

なお、すでに2回目のスケジュールが確定してる。 いまみたら30人枠(抽選)のところに80人募集がかかっていてVue熱の高まりを感じる。

vuekansai.connpass.com

第3回の開催場所なども募集されているそうなのでいま会場提供すると会社の宣伝として強そうだなと思いました(小並感) あと個人的には Vue Fes 関西 (…がやりたいなという話が出た)が実現するとめちゃくちゃ嬉しいし、やってほしいという気持ちしかないです。

参加した感想

個人的には参加してよかったという面とそういえば「これ質問したかったんだけど忘れちゃってたな…せっかく質問できる機会があったのにもったいない」という反省点があります。 そのあたりは後述しますが登壇してるときに観客側がめちゃくちゃ静かすぎるくらい静か&質問があまりされなくて「おや…?この雰囲気で懇親会いくと…嫌な予感がするぞ」という気持ちで聞いていました。

良かった点

懇親会で質問コーナーや質問にテーマをもたせてくれたこと

漠然と「登壇者の人に質問ありますか?」と言われてもレベルの低い質問をしてしまうのではないか?という不安があって質問しにくいという現象がありますが この質問のテーマをもたせることでそれに関することならなんでも質問してOK!という空気感が出来たので「Vueはデザイナーフレンドリーだとよく聞くけど実際どうなの?」という質問ができたのはよかったです。

会場の一角で突然のホワイトコーディング

Vueそのものには関わらないのですがたまたま「最近Kotlinのこういうところで困っていてさー」という会話の流れから「それPHPRubyでも同じ問題あるけどこっちはこう解決してるよ!」みたいなホワイトボードコーディングしながら議論が起こったのが面白かったです。 はじめて会ったかたとも技術の話しだと比較的容易に「そこはこうしたらいいんじゃない?」という話しになったり、興味あるひとが全然関係ないけど参加してくれたりして楽しかったですし参加することで得られるものがあったという充実さがありました。

改善してほしい点

wifiがほしい

インターネットは人権なのでゲスト用のWifiがほしかったなというのが正直な感想です。 テザリングすればいいだけなんだけど会場に予め用意されていると嬉しいなと言う感じです。

まとめ

仕事では普段Vueを使ってないので「こういうことがしたいんだけど…」とか「Vueのこれってどういうことなの?」という質問できる機会が増えることを期待して参加したのですが、そういう意味では目的は達成出来ました。

…が肝心のVueの質問をし忘れていてもったいなかったなという気持ちです。 次回の大阪は参加できないので第3回に参加できればなと思っています。

未経験エンジニアがベンチャーに採用されるのは無謀なのだろうか?

タイトルはいい感じの内容が思いつかなかったのでダンまちっぽくしようとして失敗したので気にしなくていいです。

TL;DR

このエントリは上記の発言を今朝みてしまい申し訳なくなったので懺悔の気持ちで書いています。 グーメン。

ちなみに今回の件はリモートだからというのはあまり関係ないと思いますまる

発端

先日ひょんなことから下記のブログを拝見し、「ここは正しくないし誤解しているから直したほうがいいよ(意訳)」というコメントをしました。 そのあとで正直な気持ちをはてブしたところ思わぬ方向へバズってしまったらしく、 その一因を作ってしまったという反省の思いから「じゃあどうすれば良かったのか」を書いて許しを得ようという下衆い動機が出発点になります。

shimarisu-esa.hatenablog.com

問題の洗い出し

さてまずは問題点の洗い出しを行ってみようと思います。 あくまで伝聞なので、おそらくはこの5〜10倍くらい実際には問題があったんだろうと思うんですがまあそこはエスパーでもないとわからないので考えないこととします。

問題点その1

まず最初にはてブでも書いているのですが今回の件は応募者側と募集者側による意思疎通のミスマッチによるところが大きいと思っていて 期待値と実測値のズレがあったということに尽きるというのが個人的見解です。

なのでこの採用された会社の社長さんを悪くいうつもりではないのですが

企業はEdTeck(つまり教育×IT)をやろうとしていた

とあるので恐らくは「教育の現場を知っている」≒「ビジネスを理解している」という期待をそのまま勘違いしてしまったのか、 あるいは楽観視してしまったのではないかなと想像しています。

これが新卒正社員とかならまだ教育して期待値の方向に舵を切ることもできるのではないかと思うのですが フルタイムではないアルバイトで、かつ未経験者でリモートワーク、そして会社側も不慣れな言語だった?ということで悪条件がこれでもかと重なってしまったんじゃないかと思います。

それぞれ1つ1つの要素はそこまでネガティブな要因にはならないと思うのですがこれだけ重なると採用に踏み切るのはなかなか勇気がいるなと感じます。

ぼくなら絶対採用しない、ミスマッチになるのがわかりきっているので誰も幸せになれない未来しかみえない。

問題点その2

そもそも雇い主も普段はrubyをやってない

個人的に気になったのがこれです。 まずrubyやったことないのにいきなり戦力として未知数なアルバイト社員をアサインしたのが気になりました。

ありそうなストーリーとしては別の社員が普段はrails/rubyを理解していて普段はそちらに頼むんだけど別件で忙しく手が回らない。 そしてそこまで難しくないチケットなのでアルバイトでも出来るんじゃないか? 最悪その理解している人をチューター役に据えてサポートすればいけるんじゃないか

と会社側が思ってしまったのではないか?…というのを考えていました。

もし、「誰もrubyとかわからんけどそんなコード量ないし、サクッと直せるっしょ!」みたいなノリか考えだったとしたら勇気を通り越して蛮勇の域に達していると思う。 とはいえさすがにこれは考えにくい。

なのでおそらくは上記のストーリーのほうが有り得そうだなと言う感じです。 そしてその目論見はチューター役の人がめちゃくちゃ忙しくなってしまってそこまで手が回らず机上の空論と化したみたいな展開じゃないかなという気がします……つらい。

問題点その3

バイト通過の際面談してくれたのは社長のみ

ブログ内では明確に言及はされていないので詳細はわからないのですが社長はエンジニアでなかったとしたらなかなか冒険したなという気がします。 少なくとも技術的な観点からエンジニアにアドバイス求めていればミスマッチが起こらなかったか、心構えはできるよう整えられたんじゃないかな。

一番最悪なケースとしてはかつて少し技術をかじっていたのでスキルレベルを測ることはできないが多少知識があって応募者のスキルレベルを見間違えてしまったパターン。 一言エンジニア職の人に面接時に相談とか質問してもらっていれば良かったのにな、という気持ちがあります。

ただそうするとその場合応募者の方は採用されなかった可能性が非常に高いのでそれが誰にとって良いのか?というのは難しいところですがプロダクトにとってはそちらのほうが良かったと思います。 一度書いてしまったコードを引っ剥がすのはコードを追加することの何倍も難しいですからね。

問題点その4

恐らくですがこの会社でリモートワークされる方はあまりいない、もしくは初の導入だったんじゃないかなという気がします。 「リモートワーク」というのは「言うは易く行うは難し」みたいなところがありますし、性格的に向いてたり向いてなかったりすることもあります。

ただなによりもリモートワークには「リモートワークするための能力」が絶対に必要になります。 リモートワークを実践している会社では多かれ少なかれ、この手の問題を認識しているので未経験の方をいきなりリモートワークで働いてもらうというのは考えにくいかなというのが根拠です。

これがフリーランスなどであれば、単純に出来たか出来てないかという成果だけをみれば何時間働いていようとどこで働いていようと働いていまいと関係ないのですが 今回はそういう方面での採用ではなかったようなので完全に謎、故にリモートワーク初導入かそれに近い状況だったんじゃないかと愚考する次第です。

問題点その5

これは主に会社側の問題だと思っているんですが「わからない」と伝えてきた人に対するサポートの仕方がかなり不足しているように文章から読み取れました。 実際のところはどうなのかわからないですが質問されたかたが「まず何がわからないかわからない」状態になっていることは恐らく伝わっていたと思います。

そのときに文章で伝えるのは立場的なものを考えるとかなり心理的ハードルが高くて現実的に難しいといって良いかと思います。 「わからないことがわからない」と伝えるのは非常に勇気がいりますが今回は未経験であるというある種の負い目などもあったためより言いにくい状況であっただろうと推測されます。そこはチューター役がいればチューター役が、会社の上司部下、先輩後輩の間柄であれば上位者側から「どこがわかりませんか?」と質問する必要があります。

そういえばこの手の「わからないことがわからない」空気って何故か一瞬で周りは理解できてしまうのですが何故理解できたのかを言語化するのは難しかったりします。

そういう意味ではサポートの仕方が信頼や愛が足りないなと感じました。 とはいえ、これは一方から見た、それも勝手に文章から読み取った内容なので大きくミスリードしている可能性は大いにあると思っています。 ただもう少しやりようがあったのではないかなというのが個人的に引っかかっています。

問題点その6

何の自慢にもならないのですがぼくは年齢の割に転職回数が多いです、いや本当になんの自慢にもならないのですが。 んで転職している回数が多いということはそれだけいろんな文化を持った会社やチームに触れてきたということでもあります(客先常駐やフリーランスとは比べない)

良いチーム悪いチーム、良い会社悪い会社それぞれいろんな特徴があり一概にこれがあったら駄目というのが難しいのですが 1点だけこれが担保されていない職場は悪いチーム、悪い会社になる傾向が非常に強いのでそこでは働かないという指標をぼくは持っています。

それが「HRTのないチームでは働かない」です。 このHRTが毀損していてもチームは良かったと思えたことがないですし、そもそもそういう環境下で自分のプレゼンスを最大限引き出せるとはとても思えないです。

ぼくは小心者なので萎縮してやれることだけやるという方向に逃げること間違いなしです。 TeamGeekでもHRTは大事って言ってたので多分そんなに外してないと思う。

社長は気さくに接したり、かわいいスタンプも使ってくれるけれど、 他の社員さんはそういうのゼロ。 必要最低限のことしか返ってこないし、絵文字顔文字を多用するのはこちらのみ。 うわ、もしかしてリス、嫌われてる??

……おわかりですね? この内容が真だとするならぼくの経験則でいうとチーム崩壊間近な空気感です。 信頼性皆無でただ言われたことを必要最低限やっている(と本人だけが思っている)チーム、これに近い経験が数回あるのですが正直そのときのことは思い出したくないです。

これはこの応募者のかただけの問題ではなかったとぼくは思っていて、恐らくはこのかたが入られる前から不穏な空気が流れていたか顕在化していたんじゃないかと思います。

そのあたりは完全に想像なので真偽の程はわかりませんが、未経験のかた1人入っただけで全てがぶち壊されるほど繊細なチームだとは思いにくいのでそっちのほうが妥当な予測かなという気がします、これが上位者だったら1人によってチームが破壊可能だったりするわけですが今回はそうではないのでその辺はないかなと。

恐らく社長さんはそういう空気を感じつつもなんとか孤軍奮闘したけどどうアプローチすればいいのかわからなかったんじゃないでしょうか、……めっちゃ胃に穴が空きそう。

以前働いた会社でも技術力の有無に関わらず、信頼関係のない職場というのはギスギスした雰囲気がありますしそこかしこで誰かしらの悪口が横行していました。 そういう環境に身を置き続けると心が萎縮してしまい、本来の能力に蓋をしてしまいます。 そうすると悪循環で以前よりパフォーマンスが落ちているのでそれを責められ、また消極的になりだんだんと生産性が下がってしまいます。

こうなるともう最悪です。

改善編

さて長々と問題を書き出してきましたが「ではどうすれば良かったのか?」を書いていこうと思います。

問題点その1

これはもう簡単で採用面接時にエンジニアと会話させる、面接という形でなくてもある程度時間を設けて話しをさせておけば回避できた状況だと思います。

slim?JSのエラーの出し方?gemを使わない検索システム?SQL外部結合?地図のAPI?例外処理?自動テスト?そもそもテストってなんぞ??

とあるので恐らくなにかしらの予兆は感じ取れただろうと思います。 少なくとも依頼しようとしている内容に対してスキルレベルが足りていないぞ、という。

仮に依頼しようとしている内容を把握していなかったとしてもどういう状態であるかはなんとなく察することができそうなのでそのときに感じた違和感を社長さんに報告していればなにかが変わったんじゃないかなという気がします。

問題点その2

これも簡単。その道に通じているフリーランス雇いましょう、それで全て解決です。 ……とはいえエンジニアの採用は昨今かなり難しいと聞いているので筋のいいエンジニアは単価が高そうです。 次善の策としてはそもそもその慣れていないであろうrubyの案件を断るとかでしょうか?

それはそれでなかなか厳しいと思いますが受けてしまって出来ない、あるいは突っ込んで社員が燃え尽きているところに無理やりねじ込むよりはまだマシな気がします。

問題点その3

これは問題点その1とほぼ同じかなという気もするのですが他にもやりようがないか少し考えてみました。

面接前でも後でもいいのですがエンジニアと座談会っぽいものを求めて話をするというのは1つあってもいい気がします。 いけるなら飲み会ではなくランチだとよりよいですね。

あるいは「ホワイトボードコーディングを行う」というのは1つ解答としてありかなという気がします。 言語を問わず、なにか自分たちが抱えている問題の中で比較的簡単なものを解いてもらえばどういう能力が欠けているのかを知る機会はあったかなという気がします。

ぼくが過去に受けたホワイトボードコーディングだと有名なFizzBuzz問題フィボナッチ数列、レシートからDB設計を考える、プロダクションコードを読んでどのあたりに改善の余地があるか考えるあたりはありました。 どれがより効果的であったのかは不明ですがレシートからDB設計を考えるやプロダクションコードのどのあたりに改善のよりがあるかを考えるテストは刺激的でした。 またそのような発想にいきついた論理的な思考や説明を聞くことでどのような分野に強みがあるのかなどが知れたのではないかなと思います。

そういえば1ヶ月くらい前にブラウザの仕組みを面接で説明してもらうのが実力を知るのにいいのではないかという話題がありましたがあれなんてまさにそうでプロトコルの中身は実装から語る人もいれば、そうではなくサーバーサイドの仕組みを語る人、フロントエンドの仕組みを語る人などいてなかなかいいリトマス試験紙なのではないかという気がします。

問題点その4

これに関してはうまくやれている会社もあるんだろうとは思うんですが個人的には信頼のない方とリモートワークするのは不可能だと思っています。 これは未経験であるかないかはあまり関係がないです。

ただ未知数であること、未経験者であることなどを考えるとリモートワークさせるべきでなかったというのが最終見解です。

よしんばやるとしても週5勤務だとしてフルタイムでなくてもいいので週2回は物理的に出社してもらい意見のすり合わせなどを行う必要があったかなという気がします。 そこから徐々にフルリモートへの移行というならば適正と会社に受け入れるだけの土壌があれば実現できたかもしれないです。

このあたりは個人の適性やスキルにも大きく依存するのでなかなか難しいですが文章を読んでいる感じだとまだセルフマネジメント能力が圧倒的に不足しているように思えたので時期尚早だったんじゃないかと思います。

問題点その5

ぼくなら文章で説明がなんかよくわからん!となったらビデオチャット使って説明してもらいます。 あるいはペアプログラミングするとかでもいいと思う。

とにかくやりようと伝え方に関してテキストだけでやり取りしているように見受けられるのでそこを改善したらもう少しマシになったんじゃないかなという気がする。

問題点その6

チームが崩壊しようとしているときにどうすればいいのか?……ぼくも知りたいです。 手っ取り早くチーム解散するくらいしか思いつかないけどそれって根本的になにも解決してないんですよね。

とにかく何が問題なのかチームメンバー集めてポストイットとかに貼っていってもらって本当に困ってることを見える化するところから始める、とかかなあ?

まとめ

今回の問題は未経験であるとかリモートワークだったことではないと思っていて、求人の不幸なミスマッチというただその1点につきると思う。 恐らくこの応募者のかたはそれなりに優秀なのだろうと思う、ポートフォリオを2つも作りきっているとのことなのでそれは純粋にすごいことだし評価されていいと思っています。

他方、オンラインプログラミング教室の問題であるチームで開発する能力が不足していたのではないかと思います。 会社というのは個人で開発することよりもチームで開発することのほうが多いと思うのですがそのためのスキルというのは実際にやらないとなかなか育たない、1人では育てられないという問題があるのでこれは仕方のないことなのかなという気がします。

応募者の方のまとめにも答えが書いてあるのですが…

そもそもプログラミングの本質って問題解決ですよね。 リモートってことは、あらかじめ決まった仕様が送られ、 それをコーディングしていくっていうのがイメージなんでしょうけど。 コーディングする側だって、実装するシステムが 本当に顧客の問題解決になるかを考えなきゃいけません。

結局のところ、そういうことだと思うのですよね。

プログラマーライトスタッフとしてぼくが必要だと考えているものが3つあって

  1. 問題認識力
  2. 問題解決力
  3. 実現能力(プログラミング)

だと思っています。 そういうこの中で一番重要だと思っているのが問題認識する力で、問題を認識すればどう解決していくのかはある程度的が絞れます。

ぼくが見てきた中で優秀だと感じたかたはだいたい問題の捉え方が芯を喰っていました。 逆に言い方は悪いですが無能だと感じたかたは問題を問題として捉えることすら出来ていないことが多かったです。

そしてこの中ではプログラミング能力、問題を解決するために実現する能力というのは最後の最後に必要になるだけで実はこの3つの中では一番重要度が低いと思っています。 だからといって軽視してるわけじゃないよ!選択肢はあればあるだけ問題を認識する視野や解決する能力に幅をもたせてくれると考えていますからね!

そういう意味でいうと応募者のかたは今回の件はこの全てに問題がある、言い切ってしまえばプロとして必要な水準に達していなかったということではないかと思います。

ただこれは募集していた企業側にも言えることだと思っているのでどちらがより悪いということではなく、ミスマッチが生じていたのが時間がたつ毎に悪化してしまい非常に残念な結果になってしまったのが悔やまれるということです。

応募者のかたはいまSESとして働いているということなのでひとまず良かったのかなという気がします。 非常に珍しい経験をしたということで少しでも人生の糧にしてこのあとのエンジニアライフを謳歌していってくれるといいなと心よりお祈り……だと駄目なので期待しています。

ボク個人の感想としてはマジで↓な感じでアグレッシブさを忘れずに「ガンガンいこうぜ!」をこれからも実践してほしいなと思っております。

……はークソながかった。懺悔は時間がかかる、ちぃ覚えた。

2018年に買ってよかったもの

今週のお題「2018年に買ってよかったもの」

厳密には2018年に買ったものだけではない、特に書籍類は買ってから読むまで放置していたケースがあるので不明。 ただ基本的にはログを漁ったので2018年に買ったものリストになっているはず。

順不同、時系列不同。

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発デバッグ技法まで

以前ブログのエントリでも非常によかったと書いたがやはりこの1年、一番触った言語であり度々「本の○○でこう書いていたのはこういうことだったのか」みたいな気付きや理解をする最初の1歩を手助けしてくれた良書だと思う。 Railsチュートリアルでうまくいかなくて途中で投げ出してしまった人に是非とも読んでほしい1冊であり、今年読み切ってよかった本と言える。

luccafort.hatenablog.com

RubyKaigi 2018 Super Early Birdチケット

人生初の国際的カンファレンスに参加したという意味で思い出深いアイテム。 仙台にいったのも初だったのだけど街そのものがコンパクトだったことやRubyKaigiの時期がグンバツによいシーズンだったこともあって非常に過ごしやすかった。 また行きたい。

Roost

会社で使っている。 首の傾斜が下ではなく正面に近くなるため長時間座りっぱなしなぼくのような職業には非常にありがたい。 会社で使って結構いい感じだったので自宅用に買おうか検討している。

一応持ち運べるぞ!というウリがあるが持ち運ぶことはほぼないと思ってよい、あくまでそういうことも出来るので出張とかあっても大丈夫くらいの気持ちでいたほうがいい。 毎日持ち運んだ結果持ち運ばなくなるということが理解できた。

ユーザーストーリーマッピング

ユーザーストーリーマッピング

ユーザーストーリーマッピング

万人にとって良いとは思わない。 文章そのものや展開の仕方にも冗長なところがある、だがしかしその当時の自分が持つ課題に対する手法として参考になったという、時期と状況が合致したということであげておくべきだと判断した。

5年前なら恐らく響かずそのままスルーしていたと思う、書籍の中身もそうだが自分が求めるものや方向性、課題など諸々の理由で当てはまった結果だと思っている。 ヒアリングが出来ていないということで課題図書として上がった本だが有用だったと思っている、手元に1冊おいておきたい。

luccafort.hatenablog.com

空挺ドラゴンズ

ドラゴン、船と来たら熱いバトル展開……と思っていたらなんかいきなり捕獲した龍を食べだしてなんじゃこりゃ!?という驚きとついつい先が気になる展開でKindle大人買いしたものの1つ。 面白いよ?

さよなら私のクラマー

四月は君の嘘」は無音という雰囲気と情熱を聞かせる漫画だとしたらこっちは青春の一瞬のきらめきと熱量を描きだした漫画。 なにいってんだこいつと思ったそこのあなた、正しいのですが面白いので手にとってください。

Anker PowerLine+2 Lightningケーブル

会社で使ってるライトニングケーブルの端子部分が劣化により回線むき出しになったので購入。 柔軟性という点においては難があるがそもそも会社ではPCかAnkerのPowerPortにつないで充電しているか音源データ転送してるくらいしかしてないので別に問題ない。

からかい上手の高木さん

とりあえず西片殺○、いいたいことは以上です。

ペルソナ5』オリジナル・サウンドトラック

『ペルソナ5』オリジナル・サウンドトラック

『ペルソナ5』オリジナル・サウンドトラック

オシャンティー。 アニメのOP/EDのCDもほしいが売ってないので買えない、困る。

ペンギン・ハイウェイ オリジナル・サウンドトラック

映画のほうもよかったけどサウンドトラックも癒やし感あってよい。 映画のお姉さん最高でしたね。

フィリップス ソニッケアー 替ブラシ ダイヤモンドクリーン ブラシヘッド スタンダードサイズ ブラック

以前までは購入時の付属のものと同じやつを買ってたんだけどこれにしたらめちゃくちゃ歯が綺麗になった、おすすめ。

真・天地無用!魎皇鬼外伝 天地無用!GXP17 簾座編

文句なく面白いのだけど1年に1冊ペースなので前回の内容忘れるし、忘れた頃にしれっと販売していたりするのでめちゃくちゃ困る。 四半期に1冊とは言わんので半年に1冊ペースになってほしい……今年は2冊出たけども。

というかまさか新展開するとか思ってなかったのでめちゃくちゃ続きが気になります、はよ続編。

なんだかよくわからない「お腹の不調」はこの食事で治せる! 世界が認めた低FODMAP(フォドマップ)食事法

これに書いてること守ってれば絶対大丈夫!!!…みたいなことはない。 ないんだけどとりあえず書かれているうちいくつかの食材をあまり食べないようにしてみたところ確かに謎の腹痛が発生する確率が下がった。 なりにくくなっただけでなっていないわけではないので解決はしていないのだけど同じように苦労している人がいたら参考にしてほしい。

Apple Magic Trackpad 2

Apple Magic Trackpad 2 MJ2R2J/A

Apple Magic Trackpad 2 MJ2R2J/A

会社においてるんだけど自宅にもほしい。 あると便利、ないと不便。 でも高い、Apple死ね。

ASUS 9.7インチ タブレット ZenPad 3S

なんやかんやでこのサイズが一番お手頃。 値段もそこまで高くなかったのでだいぶお得だった感がある。 とはいえOSのバージョンが古かったりするので特定の用途でのみ使うという運用(主に漫画ビューワー)での実績である点に注意されたし。

Anker SoundBuds Surge

https://www.amazon.co.jp/gp/product/B06XXNZ77R/

Bluetoothなイヤフォンでそこそこのお値段、かつ耳にしっかりフィットするのをいくつか試した結果一番コスパがよかった。 ただもう販売していないっぽい。

後継がどうなってるのか少し気になるが期待薄、残念。

コクヨ オフィスチェア ベゼル

実際にはまだ購入しただけで手元には届いていない、なお中古。 購入はオフィスバスターズとかいうオフィス用品の中古販売しているところ。 KOKUYOのBezelシリーズは中古がなかなか見つからなくて苦労する、バロンやアーロンチェアがそこそこの数出ているのはそれだけ買われているからなんだろうけども。

最近腰痛で会社を休んでしまったのでいずれ買おうとは思っていたのだけど我慢の限界が来たっぽいので実費で購入。 座り心地などは過去に試しているため問題なし、夏場のムレが気になるくらいか。

まとめ

以上、基本書籍や漫画が多いのはそういうことです、ご理解ご協力のほどうんたらかんたら。

幻想水滸伝 x JAGMO Orchestra Concert in Osaka

jagmo.jp

東京公演のときに「関西ないのかよ、さすがに東京までは難しいぞ……」と思ってたら年末に大阪公演があると知ったのでちょっと奮発してSS席を購入したので行ってきた。 場所はNHK Osakaホール。

でけえ

着いたのが11:15分くらいで開場が11時だったのでまあまあいい感じの時間帯につけたと思っていたらすでに人が大勢いてちょっとビックリした。 年齢的にはやはりぼくくらいの30歳前後の方が多かったように思う。 幻想水滸伝1の発売日が1995年12月15日らしいのでわからんでもない感じの年齢層だ。

ところで「幻想水滸伝 発売日」でググるとこんな感じの検索結果がでてくる、知らなかった。

f:id:luccafort:20181202210302p:plain

こうしてみると最後のナンバリングタイトルである幻想水滸伝5からもう12年近く経ってしまっており6が出るのがほぼ絶望的という感じがしていてつらい。 クラウドファンディングとかでアニメ作るケースがあるんだし幻想水滸伝の続編もクラウドファンディングとか使って作ってくれないかな……マジで。

閑話休題

ともあれ、以前JAGMOのコンサートに行ったときには物販がなかった(もしくは知らなかった)のだけど今回は事前にグッズがあるということだったので購入する気満々でいってきた。 結果からいうと事前に買いたいと考えていたものは全て購入できた…のだが隣で買っていた人がはじまりの紋章と罰の紋章のピンバッジを購入してるのみて、しまったこれも買っておけばよかった!と少し後悔した。 ……というか多分全種購入してたっぽい、すごい。

んで、こういうコンサートやライブにあまりぼくは行かないのだけど今回少し感動したことがあって物販の注文シートを事前に渡してくれていたのですよね。 世間一般としてスタンダードなのかわからないんですが非常に物販がスムーズに回っていたので大変助かりました。

物販の注文シート、事前に用意してるの is 良い。

そして、肝心要のコンサートなのですが、非常に良かったですね。 ぼくは音楽に造詣が深いわけではないので技術的な点などはわからないのですが座った席がすごい良かったです。

なにがどういいかというと通常、この手のクラシックやブラスバンドなどのコンサートでは真ん中に宙吊りにしたマイクで集音、スピーカーなどで全体に聞こえるようにしてあります。 なので座席の位置によってはいわゆる生の音でない状態になります、あくまで厳密な意味で言えばということですが。

ところがこの位置ですよ、皆さん!!!

超近い。

舞台から4列目の真ん中…ではないもののかなり音響的にはいい位置に座れました、わたくしたいへんまんぞく : ) (更に欲を言うならぼくは低音スキーなので逆側の低音パートが多く配置されていた逆位置のほうがよかったなーって少しだけ思いました、少しだけね!)

この通り非常に近い位置からに座れたことでヴァイオリンの生(だと思い込んでる)音が直接耳に届いたり、指揮者が演奏中に吐く息継ぎの音や靴の擦れる音など非常に眼の前で演奏しているんだ!という臨場感のある音楽が楽しめました。

特に個人的に気に入ったのがチェロのソロパートがあったこと!選曲も良かったけどあれだけ長くソロパートが聞けるとは思ってなかったのでめちゃくちゃ感激してた。 はっきりと覚えていないのだけど多分幻想水滸伝2の吸血鬼ネクロード戦のBGMじゃないかな、間違ってたらすまん。

とまれかくまれ、非常に満足のいく公演でした。 大阪公演が今後定期的に開かれると個人的には大変ありがたいのだけど予算とかの問題でどうなんだろうなー?という気がしています、個人的には応援したいのでなんとか頑張っていただけると嬉しいです。

そういえば以前書いたユーフォニアムの定期公演のときと違ってしっかり音圧があったのは楽器によるものや技量もあるのかもしれないけどやはりNHKホールの音響の良さがある気がしていて音の反響の違いを如実に感じられた気がします。

luccafort.hatenablog.com

京都市内にもコンサートホールがあるんだけどそれと比べても良かったように思う。 あと座ってる椅子の間隔が絶妙で狭くもなくかといって広すぎずという感じでいい感じでした、椅子そのものもしっかりと深く腰掛けると腰が痛くなりにくい設計になっているみたいで腰痛持ちの身としては大変ありがたかった。 この辺はSS席だったからかもしれないが比較対象がないのでわかりません。

文句のつけようがないくらい満足して帰ったんだけど1点だけ……昼公演と夜公演両方チケット買っとけばよかったと公演終了後に思いました。 もし次回があって興味あるゲーム音楽やるときは昼夜通しでチケット買おうと心のメモ帳に書き残したった。

Qiitaに寄稿システムっぽい仕組みがほしい

Qiitaに怪文書が出てから嫌な方向で盛り上がっているのがクソいなというお気持ちをまず表明したいと思います。 いいかここはチラ裏じゃないんだ。そういうのは増田でやれ。

さて、本題なのですがそういえばQiita改善の方法を書いているエントリを読んで「インセンティブよりもかつて所属していた会社のQiitaTeamから抜けたらその成果が虚無に消えたのが悲しかったので寄稿という形をとってほしいな」と思ったのがきっかけです。

当時QiitaTeamには社内向けで一般公開が出来ないもの、一般公開しても問題のないものの2種類エントリを書いていたわけなのですが問題なのは一般公開しても問題なかった投稿が自分の投稿一覧から消えてしまったことです、悲しい。 社内向け非公開というエントリが虚無に消えてしまうこと、これ自体はTeamから外れたのでいいのですがそうでない投稿の場合寄稿という形でQiitaTeamに投稿したいなという気持ちがあります。

最初から一般公開しても良い内容ならQiita(Teamでない)に投稿すればいいのですが、一般公開するには情報が足りなかったのか。ログ的に書き出していたからかQiitaTeamで書いてしまっていたエントリがいくつかあってその情報をかつてQiitaに書いたよなーと自分が投稿した一覧から遡ったところ「あ、これTeamで書いたから見れなくなってるわ!」となったので寄稿というシステムがあれば嬉しいなと思った次第です。

せっかくの経験や知識、なによりアウトプットしたものが見れなくなってしまうのがもったいないなと思ったのでそういう仕組がほしいですね!という意思表明しておきます。 あと寄稿という形ならスポット的に参加したメンバーとかも投稿しやすいような気持ちがしたけどただの推測なのでよくわかりません。

響け!ユーフォニアム 公式吹奏楽コンサート ~北宇治高校吹奏楽部 第3回定期演奏会~

前回参加したとき(多分第一回)はまだ東京に住んでいたのですが、今回は宇治で参加なんだなーとなかなか感慨深いものを感じながら参加してきました。

ここのところあまり体調が良くなく(のちにアレルギー性の鼻炎が原因と思われることが発覚)、当日になったら早めにいって宇治の聖地巡礼してやろう!とか思っていたのですが叶わず、ギリギリまで休んでいました。残念。

せっかくの自転車日和という季節になったのに週末が悪天候になりがちであまり今年は楽しめないでいることが多かっただけに結構残念に思っています、また大吉山まで行きたかったんだけどなあ…。

演奏は満足の一言でした。

前回のときよりも演奏の円熟度が増していたように思います、 個人的には宝島のテナー・サックス(低音のサックスだと思うけど確かでない)のソロパートがMVP上げたいくらい良かったです。 元々サックスとか低音パートのほうが好きなので個人的主観に基づいてるので実際に上手い下手は正直わかんないです、みんな上手いと思うんだよなあ。

TRUEさんの歌声などもなかなか迫力があり大変満足しています。

ただ演奏そのものの不満ではないのですが素人ながら前回ほどに音のボリュームというか圧がないように感じました。 これは指揮者の意図なのか、音楽ホールの設計の問題なのかわからないですが個人的には後者なんじゃないかなと思ってます。

こういうところでも差がでてしまうのかなー、音楽って難しい…みたいなことを演奏後に思い返していました。 そういう意味では宇治は聖地だし特別感があるんだけども、京都市内の音楽ホールや大阪のほうの音楽ホールだとどう聞こえたのかな?というのが少し気になりました。

非常によい音楽を休日に堪能できたなという思いと音楽はいいなーと3万回くらい思っていることを改めて感じました。 どうやら追加公演があるそうなのですが、残念ながらぼくは参加できそうにないのでもし参加できなかった!という方は応募されてみるのもいいのではないかなと思います。

anime-eupho.com

クリスマスイブだそうなので友達や家族と行くとリア充っぽくていいんじゃないかな。

この定期演奏会がずっと続いてくれるといいなーという思いでブログを書こうと思っていたのですが冒頭でいったような体調とどうにもここ数日トラブルが頻発していてブログを書く時間をなかなか捻出できなかったので1週間ほどたってしまいました。

またそのうち時間を取って宇治まで聖地巡礼してみたいな。 とりあえず来年の新作映画が鋭意製作中だと思うのですが楽しみに待ちたいと思います。

Instagram post by るっかふぉーと • Nov 4, 2018 at 9:40am UTC

以上、参加レポートでした。 絵書いたり音楽できたりするのってなんかカッコいいなーって感じでいいですよね。

暗くなってきました。

Instagram post by るっかふぉーと • Nov 4, 2018 at 9:39am UTC

宇治市内

今回わかったのは宇治市内の夜は京都市内に比べてめちゃくちゃ暗い、ということです。