しがないラジオ Advent Calendar 2017 12日目 - 都落ちエンジニアの地方転職活動記 -

しがないラジオ Advent Calendar 2017

どうも、しがないラジオ Advent Calendar 12日目を担当する@lucca0showこと、るっか和尚です。 11日目は id:radiocatz さんです。

radiocat.hatenablog.com

はい、パーソナリティのお二人でもないのに6日目に続きまして2度目の登場でございます、いえーい!!!

実はぼく、去年2016年10月まで東京にいたのですが諸事情あって今は京都でサーバーサイドエンジニアをやっているので「都落ちした地方エンジニアから見た地方転職事情」を報告しようかなと思います。 転職活動そのものや転職してからみえてきた地方エンジニアのあれこれを思い出しながら書いてるので多分支離滅裂なのでそこは勘弁してくれ(人∀・)タノム

ところで東京から京都に出戻りしたときも都落ちなんでしょうか? 都から都に落ちていてこれはまさか無限地獄(゚A゚;)ゴクリみたいな気持ちになったりならなかったりします。

注意: 当たり前ですがこの情報は「ぼく」というPHPerエンジニアなフィルターを通しているため非常にバイアスがかかっています。

「そんなことねえよ!」とか「主語がでけえんだよ!」とかあると思うんですがその場合はコメントやはてブで補足するんじゃなくてブログで反論していただけるとより良いインターネッツな世界が拓けるのじゃないかと思うのでよろしくでしょでしょ。 ついでにその反論ブログをしがないラジオAdvent Calendarに書いてくれたりすると実にいい感じです :)

結論

東京にいま住んでいる、あるいはいま地方だけど東京に移住するのに抵抗がないなら東京の会社で転職活動するほうがエンジニアとしてはいい。

ぼく個人は東京に戻りたいとは思ってないですがしがないラジオのリスナーが求めている「エンジニアとして活躍できる場所」みたいなのはやはり東京のほうが圧倒的に多いと思うのでその点だけで考えるなら東京行くしかないとぼくは思います。 最近は地方でもリモートOKだぞ!って会社もありますが狭き門である点は留意しておいたほうがいいかも。

求人の数

京都在住なので近辺で通えるWeb系の会社…となるとだいたい京都市内か大阪のだいたい2つに絞られる。 この辺は東京でも渋谷新宿辺りにWeb系企業が集中する、みたいなのと然程変わりないかなと思います。

ただ東京と違う点で大きいのはまず分母がめちゃくちゃ少ない!!!ということ。 ぼくは専門学校が東京でそのあとほとんどの時間を東京で過ごしていたのでびっくりだったんですが関西レベルでもWeb系企業の求人は非常に少ないと実感しました。

というより東京が多すぎるだけなんだとは思いますが体感的には1/4くらい。 それも求人を出しているのはだいたいいつもみかける企業…という感じです。

逆に組込系はめっちゃある、なんでこんなに求人があるのかわからないレベルである。東京にいたときは気にならなかったけど東京もそうなんでしょうか? JavaScala、Cあたりの組み込みで使われる言語使えるひとは困らないかも、給与とか待遇とかは不明。 あとiOS/Androidはどこも引っ張りだこっぽい感じですね。

受託開発メインが多い

東京なんかだとキラキラしてるWeb系企業は多かれ少なかれ自社サービスだったりすると思うんですがこれが地方になると受託メインが9で自社サービスメインが1みたいな比率のように感じます。

実際はもう少しマシなんだろうと思いますがスタートアップで有名度がなくて知ることすら出来ないパターンなのかなと思います。 東京もそうなんですがなにせ分母が大きすぎるので上澄みだけでもいっぱいあるように見えます、すごい。

それでも受託開発メインが多いなと感じるのは組み込み系やハードウェアに強い会社が京都には多いからかなと思います。 オムロンとか京セラとか任天堂とか。 大阪もやはり自社サービスよりも受託開発が多いなーという印象です。

旧態然とした開発スタイル

いまだにFTPで編集したファイルをアップしてたりIDEあるのに使ってなかったりとか諸々ある。 人によってはモダンな環境を勝手に構築していたりするがやらないひとは秀丸エディタFFFTP使ってファイルアップロードしてたりする。 ソースコード自体はgitで管理しているというのに…謎い。 ところによってはsvnとか悪名高きVSS(ビジュアルソースシュレッダー)が現役とかある。

いいのか悪いのか判断がつかないけどもクライアントとの距離感は東京よりも近いことが多いかもしれない。 その分クライアントのやりたいことを自分たちで汲み取って形にしていく感じはより強い。 忖度が発生しがちなのが個人的にはクソいなーと感じる。

レガシー業界なクライアント

何故かはわからないがクライアントの業界がレガシーでシステムに例外対応を求められやすい…という印象が強いです。 そのため最初から使うかわからないような汎用的な実装を、短納期で納品することを求められることが多い。 東京だと「レガシーな業界をおれたちの技術で風穴あけてやるぜ!」みたいなスタートアップ企業を見かけますがあまりそういうのは期待されてない気がする、主に転職先の企業とクライアントの双方から。

また勤めている会社も「納品=ゴール」という意識が強い気がしていて「リリース=スタート」みたいなスタートアップ感は薄い気がします。

なぜそうなのか?はよくわからないけど東京ではそういう案件が受注されなくて地方に回ってきたのかな?と推測しています。 東京よりも地方の方が単価安いしそれじゃあお願い!みたいな。

受託開発が多いのもこの辺に理由があるのかもしれません。 アジャイルリーンスタートアップみたいなことに対するクライアントの理解度が東京の頃よりも低いように感じることはある。 単純に所属した会社がそういう属性に強いところとの取引が多いだけというのは否定できないのでもうちょっとデータが欲しい。 なので転職する際に受託開発は嫌だなーと思ってたらその旨を伝えておくとお互いにミスマッチが減るかもしれないですね。

向上心のない技術者

これはたまたまぼくが働いた会社がそうだったというだけだと思います。 あと地方限定の話でもないかなとは思う。

いわゆる向上心のない技術者のかたが関西ではよく見かける…という印象を受けました。 これは東京の場合生存競争が激しく、自然淘汰されていくから見かけなかっただけだと思っているのですが地方だとそこまで競争原理が働いていないのでそういう人が残りやすい土壌みたいなものが出来るのかな?と思っています。 この手の話はしがないラジオでも度々話題になっていたりするので、地方特有ではないですがより顕著な傾向があるきがしています。 恐らく地方はものすごく出来る人たちとそうでない人の格差が東京以上に激しい。

仕事としては向上心なんてなくてもそこそこ回せるので結果としてそういうのが嫌な人たちは転職して東京にいってしまうイメージ。 京都に戻ってきて「この人と話してみたかったんだ!」と思って勉強会とかイベントいったら「あ、その人なら転職したよ、今は東京」ってパターンが何度か……つら。 あとはフリーランスになってるパターンもありますね、大変そうです(こなみかん)

閉鎖的?な文化

全部が全部というわけではないけども東京ほどオープンな感じがしないことがままある。 これは京都だけなのかな? いやでも某大阪の会社もそうだったので京都限定の話しではないはず。

「求人サイトで目にしたのでとりあえず会社に遊びに行かせてよ!」ってメールしたら「無理です!」って返ってきたり OKでたから遊びに行ったら何故か面談開始されて「あれ?会社の雰囲気を知りたかっただけなのに転職前提の話しをされている???」みたいなことがあったり。

特に困るのがこの2つのパターン。

後日「ご期待にはお答えできそうにありません…」みたいなお祈りメールもらって「いやその前段階だったから遊びに行ったんだがぼくもアンマッチだと思っていた」みたいな気持ちになったり。 「1次面談はOKだから2次面談来てくれよな!」というメール。 良い会社ならいけばいいのだけどだいたいあまり自分とマッチしないなと感じてお断りするケースが多いので非常に気まずい。

東京のときは友達経由で遊びにいくことが多かったからかあまりこういう事態が少なかった気がする。

面談時の服装

現職の1次面談で私服(パーカーにジーンズ)でいったら驚かれたこと。 いまだに人事の人に「スーツじゃない人はじめてだったのでこやつ出来る!って思いました、エンジニアっぽい」みたいなことをことあるごとにネタにされてます。 なので割りと会社の文化によってはスーツじゃないと駄目!とか履歴書は手書きで!みたいなクソな古き良き文化の香りが漂っているかもしれないです。 ぼくはクソ食らえだと思ってますが。

Skype面談

最近はSkype面談も増えてきていると思うんですがどうも関西方面だとあまり好意的にとってもらえないことが少なくない。

「大阪に仕事終わってから行くのキツいんでSkype面談でお願い!」ってメッセージを送信したら最終的にはOKになるんだけど非常に難色を示されることが何度かあった。

会えるなら直接会うほうがいいとぼくも思うけど「こういう会社でどういう人材を求めているか説明させてください!」ってオファーを投げてきたのはぼくではないのに時間工面して移動費払うのがぼくというのはちょっとダルいなーって思う。 しかも時間がタイトだし、なんかのついでならいいけどさすがに話し聞きに行くだけにそこまでのモチベーションはないのでかなりつらい。

同じ条件でも東京のオファーだと距離的なものもあるんだろうけどだいたい快くOKだしてくれる、非常に楽だし助かる。

フリーランスの知り合いが増える

たまたまなのかわからないけど京都に来てからフリーランスの人と関わることが増えました。

これは「ワタシチョット○○デキル」人が会社やめた結果フリーランスになる確率が東京よりも高いのか?と思ってたりします。

東京の場合は辞めても受け皿となる会社があるけど地方だと少なくて場合によっては求人募集してない、みたいなパターンもあったりします。 結果としてフリーランスになるのが一番合理的だと判断されてそうなってるのかな?と考えてます。 真偽は不明だし、憶測としてもかなり乱暴な説。

地方の勉強会/カンファレンス事情

圧倒的に勉強会、カンファレンスが少ない。これはもうどうあがいてもなんともならない問題の1つだと思う。 少ないというか東京が異様なのであって恐らく地方の方が正しい数値なんだよ。

これはあくまで観測範囲内の話だけど東京との違いとしてもう一点あると思っててキャンセル率が東京ほど多くない、気がします。 地方の勉強会の場合割りと内輪ノリが強くてその分キャンセルしにくい空気感があるのかな?と思ってます。

数が少ないし、ドタキャンとか東京と同じ感覚でされると勉強会自体が成り立たなくなってしまうからじゃないかな?とも考えているんだけどどうなのだろうか?

気のせいでなければ地方の勉強会のほうが内容の密度が濃い、というか尖った発表が多い気がするんだけどこれは東京だとターゲット層が広範囲になりすぎてしまうからなんだろうか?

QOLがあがった

実家に居候してるからという点を抜いても東京に住んでいたときよりもQOLが上がったと言い切っていいと思う。 給与が下がっても、諸々かかる諸経費が下がってるのでトータルでは上がるみたいな感覚、で伝わるかな? これは他の地方エンジニアのひとも似たことを言っていたので多分ぼくだけが感じているというわけではないと思う。

元々生まれ育ちが京都だからというのもあるけど京都くらいの都市規模がぼくにはマッチしていたという点はあると思っている。 もちろん、すごい田舎にいった場合とかはわからない。 東京に比べれば京都は田舎だけど、他の地域に比べればそれなりに都会だしこの辺は相対的感覚なのでケースバイケースだとは思う。

通勤電車がつらくない

大事。 京都の満員電車ってこんなもんだった?みたいに拍子抜けする。 ただしその分電車の本数は東京とは比べ物にならないくらい減っているので調子こいてると終電逃して歩いて帰る羽目になった。

通勤におけるストレスが下がったのは地方ならではなのかわからないけど非常に良い点だと思ってる。 そもそも通勤手段のメインが電車ではなく車とかもある、ぼくは自転車だけど。

さいご

ネガティブフィードバックが多くなってしまったが基本的に東京という環境がエンジニアにはすごく恵まれているということだと思う。 なので相対的にネガティブになってしまっている気がする。

今のところぼく自身は東京のメリットよりもデメリットが大きいと感じているので特に東京に戻って再起をかける!みたいな気持ちがわかない。 それよりは妹氏の夫がドイツに赴任されてるので1ヶ月くらいドイツで働いてみたいなーって気持ちのほうが大きい。

東京は良くも悪くもなんでもあるんだけどその分の対価がストレスだったりするのでぼくとしてはあまり馴染めない感じで地方エンジニアも悪くないなって気持ちです。 東京の仕事を地方に住みながらやっていくみたいな働き方ができるようになれば最高。

Rails Developer Meetup 2017

techplay.jp

ハッシュタグは #railsdm

過去何度か大阪会場で参加しているrailsdmに久しぶりに参加してきました。 2017年最後の〆に相応しい豪華登壇者のかたがたと濃ゆい内容から初心者に刺さる内容まで多岐に渡っていたのではないかなーと思ってます。 ちなみにぼくはRails初心者なので割りと得るものがあったなーという感じです。 特に一番最初の「レールの伸ばし方」 by 前島 真一@willnetさんのやつとか。

感想:

通常こういうイベントは東京で開催されると他地域では参加できなくて指をくわえるしかないのですが railsdmは過去何度か参加させてもらったのですが大阪サテライト会場にGoogle Hangoutで中継されるので非常に助かっております。 会場を提供していただいているAimingさんには毎度感謝の念しかありません、ありがたや。

今回特にすごいな!と思ったのはセッションの中身…ではなくて運営スタッフによるタイムスケジュール管理の完璧さです。 ほぼ遅延することなく、予定時間通りに進行して古強者感をヒシヒシと感じていました。 もちろんセッションの中身も良かったですよ!

個人的MVP:

個人的に本日の登壇者のかたからMVPを選ぶとしたら誰かな〜と帰りに考えていたので発表しておきます。

セッション部門:

株式会社ソニックガーデン 伊藤 淳一 氏のRails ♥ SQL

受賞理由: 賛否両論ありそうな議題の提案と対応の仕方、実務に近いコードをどう対応するかが想像出来る余地を残しつつ議論出来る余地もあってメモ取るよりもコードみながら頭のなかで「ぼくならこうするああする」「これはどう対応するんだ?」と主に思考方面にCPUを割り振ってました。 Twitter上の反応などもみていると賛否両論あったり別角度からの意見もあって初心者なぼくには「そんなアプローチがあったのか!」と目から鱗な思いでした。 コードをみるだけではわからないが実務でありがちなことということ。 そして何よりも本日最も得るものが大きく多かったと感じたため勝手にMVPを送らせていただきますドンドンパフパフ〜♪

LT部門:

セッション部門は割りとハッキリ「今日の一番はこれだな!」と感じたんですがLTはめちゃくちゃ難しかった。 どうしてもLTという特性上時間に限りがあるので濃縮圧縮された情報になってしまうので突出して良い!と感じにくい土壌があったので非常に悩ましい。

悩んだ末に↓を選びました。

株式会社Gunosy 榎本 敏丸 氏の「Railsでまだ消耗しているの?」 ─僕らがRailsで戦い続ける理由─

受賞理由: ぼくは今までPHPerで最近、というか今年になってからRailsのイベントに参加するようになったりRailsで簡単なアプリを自分で作ってみたりしている。 そういう意味で「何故ぼくらはRailsを使うという判断をしたのか?」という根源的な問いを突き詰めていたこのLTは個人的に一番刺さったかなと思ったから。 他のLTも甲乙つけがたいものが沢山あって非常に悩んだのだけど「一番印象に残ったLTはなにか?」と言われたらこのLTかなと感じたので選ばせていただきました。 特にお気に入りなのが「Railsって遅いよね?」というネガティブフィードバックに対して「処理系の速さと開発の速さは別」という切り返しがスマートでカッコいいな!と感じました。 確かに処理系の速さを求めるところでRailsを選択するのはそもそもその俎上に上げるやつがどうかしてるのであってRailsどうこうの問題ではないし、なによりも開発の速さこそRailsが誇る持ち味の1つなんだから比較対象がそもそもずれてるな!と気づきました。 ISUCONでRails選択せずにGo選択したりNodeJS使うという選択をするのは正しい判断であって、Railsを頑なに使うのはただの思考停止だなといろいろ考えてしまったので特に印象に残っているのかも。

ネガティブフィードバック:

とまあ良いことばかり書いているんですが95%くらいはいいことだったんですがとはいえ改善してくれると嬉しいなーというフィードバックもあるのでそれも紹介しておきます。 個人的には解消は難しいと思ってるものばかり。

  • 東京会場の騒音(環境音?)がノイズだった
    • ものすごくうるさいわけではないが(一部消防車の音など例外あり)ちょいちょい登壇者の声のボリュームが小さいと聞き取れないことがあったのが残念
    • ただ窓を閉じると空気が薄い…みたいな話もあったので空気は大事、騒音よりも大事だぞ!って思ってるので改善されたら嬉しいくらいのものです。渋谷らしいし仕方ない。
  • Google Hangoutの音声品質があまりよくない?
    • リモート中継枠のためだと思うんですがrailsdmで毎回いってる気がするが音声品質悪いので聞き取りにくい
    • 最初は機材の問題かと思っていたがどうもソフトウェア側の問題なきがする、Google頑張れ。
  • 東京会場と大阪会場の会場の雰囲気に温度差がある
    • 会場のストリームも資料の配信とは別で流して欲しい、でも映されたくないとかで絶対問題になる現実的解答でない。
    • 大阪会場で拍手がまばらだったりとか質疑応答がしにくい空気感を感じることがあるので何かしらの善処はしてくれると嬉しい
  • アンケートが各セッション&LT毎だったので書いたあとでTwitterで「アンケートはこちら!」というのを見かけると「あれ?これ書いたっけ?」みたいな感じで不安になる
    • うまい方法を思いつかないのだけど記入済みのものはなにかしらのチェックされてるされてない的なものが欲しい
  • 懇親会(大阪会場)あるって思ってなかったので別の予定いれてしまった
    • 懇親会あるのってどこか情報あったかなー?なかったとしたら次回からは懇親会あるかもよくらいの情報はのせてほしいなって。
    • せっかくのRailsエンジニアの方々との交流する機会を逸してしまったのマジもったいなかった。

以上! どのセッション&LTも楽しかったし学びがあって良かったです。 2018年のやつは…参加したいができるんだろうか? とりあえず全32セッションは狂気の沙汰だなと思ってます、運営スタッフ大変そう(こなみかん

しがないラジオ Advent Calendar 2017 6日目! :)

しがないラジオ Advent Calendar 2017

どうも、しがないラジオ Advent Calendar 6日目を担当する@lucca0showこと、るっか和尚です。 5日目は@HKDnet さんになります。

さて、Advent Calendarを書いたことがある方はわかると思うのですが なにを書くのか?が非常に難しいのですよね。 誰かとネタがかぶると困るしかといってなかなか事前に準備できるものというのは限られるわけです。

そこでこの1年、今まで行わなかったことを実は勉強していてしがないラジオでも似たような話しがよく上がっているのでそちらの話しをしようと思います。

マネジメントとかリーダーシップをまなびはじめたよ!

なにかといえばそういうことです。

自己啓発本などはいまでも「意味ないなー」と思う程度には世の中を舐め腐ったナメクジクソ野郎なのですがとあることがきっかけでマネジメントやリーダーシップについて学んでみようと思い立ちました。 それがだいたい今年の2月頃の出来事。

マネジメントを学ぶきっかけ

ちょうどその時期、大阪のWebのベンチャー企業に転職が決まりました。 そこで働いて2週間ほど働いていて明らかにおかしなことがあります。 そう誰もマネジメントをしていないのです。

明らかにうまく回っていない、問題の本質はタスクがどれくらいあって今やってるタスクはなにを解決するためのものか?優先順位はどこか?

これらを問うと「そういうのはよしなに空気感を感じ取ってください」といわれたので 「あ、これマネジメントを学ばないとぼくが過労で倒れるわ」と思ったのが最初のきっかけです。

はじめてのマネジメント

そこでまず誰がどのくらい出来るのか?をまず調査しました。 外注のデザイナーさん(週3回)以外は学生エンジニア(プログラミング未経験インターン)、 そのうち1人は1週間後の退職が決まっておりしかもぼくの前任のメイン担当者。

もう1人は大学の研究室が忙しいので来月あたりから1ヶ月ほど来ないと言われています。 最後の1人は不定期ではあるけど週のうち3日ほどは来れるとのこと、唯一の希望。

そして結論からいうと仕事を通してプログラム未経験から半年くらい学んだレベルでした。 それ自体は全く問題ではないのですが現状を鑑みるとぼくが望む最低限のレベルに達しているフルタイムで働けるメンバーがいないという問題が浮き彫りになりました。

また、外注のデザイナーさんは非常に手が速いもののgitがわからんとのこと。 デザインに関しては非常にアウトプットが速い点やレスポンスが速かったりといい感じだったのですが如何せんプログラマと組んでチームで開発する経験値があまりなさそうに感じました。 このあたりは経験がないというよりどうやればいいのか上手くいってなくて今までおまかせ(丸投げ)だったのが原因かなと考える部分があったりなかったり。

そんなこんなでまあやばいよね?って感じでした。

まずgitとはなんぞや?からはじめた

ってことでまずgit commit&git pushはできるけど他はなんかよくわからん!なメンバーをまず全員集めます。 なにせ修正中のコードをpushされたらmasterをデプロイしていいのか、悪いのかすら判断つかなくなります。 なのでまず基本方針とそのために必要なgitの使い方をレクチャーしました。 そして今後どうやって開発をしていくかの説明を行います。といっても大した話しではなく

  • 修正依頼は必ず口頭ではなくチケット切って依頼。
  • 修正依頼が来たらブランチ作ってそこで修正する。
  • 修正が確認できたらそのブランチをレビューしたあとでマージ。
  • レビューの通ってないものはマージしない

本当はテストコードがどうとか諸々あったけど一度にいきなり変えても情報過多で対応できないだろうと判断したので比較的導入が簡単で効果のあるものだけを導入しました。 ちなみにぼくが入るまでは他人のコードの修正がmasterにガンガン入っててデプロイしたら動かなくなるページとか普通にあって原因調査にめちゃくちゃ時間がかかりました。 「手元の環境で再現しないのになんでだ!?」みたいな感じになって、本番のログみたら普通に400系や500系のエラー吐いてやんの。

タスクの割り振り方を変更

さてそんな状況でフルタイムで働けるメンバーがぼく以外誰もいないという状態だったのでまずタスクを1週間単位で切りました。 Aさんの今週のタスクは「メール送信時に文字化けが発生する原因の調査と解決、マストは原因の判明。最悪解決できなくてもいいですがどこまで調査してどういう対応をしたかを必ず書いてください」 Bさんは今週のタスクは「一覧のソートがこの条件のときに意図した並び順になっていない原因の調査と解決です、そこが終わったら詳細に移動したときに表示されない画像があるのでその原因の調査です」

といった形でタスクを切りました。 そして週一で進捗会議を行いました。

今どのタスクが残っていて、どのタスクの対応が優先順位が高いか、今週中に渡したタスクが終わりそうかなどなど。 他のも問題点や疑問点などがあればそこで報告するようにしていました。 この会議は全員が集まることが難しかったのですがTrelloでタスクをカードで管理してオンライン上でいつでも確認できるようにしたため、休んでいたメンバーもどういうタスクが追加されてどのタスクが割り振られているかがわかるようになったのでメンバーからはそれなりに好評でした。

このときに「これはリモートワークなどでも通じるコミュニケーションロスとその対応が応用できそうだ」と感じました。 いままでフルタイムで働くメンバーばかりだったので、こういう対応やその場にいないメンバーもいるメンバーと同等の情報にアクセスできる状態を保つのはなかなか難しいぞと感じたのが正直なところです。

そのとき参考にしたマネジメントの手法はWEB+DB PRESS Vol.97を一部真似させてもらいました。

とにかく課題が山積みだったのでトリアージを行って多少のバグや優先度の低いものは後回しにして緊急度の高いタスクのみを片付けることに専念しました。

とにかくこれによって「マジでこれはやばい、徹夜してでも直さないと!」みたいなバグはなくなりました。 潜在的には同じようなバグが眠っているとボク自身は感じていましたがとりあえず現段階で表面化していなかったこととそこまで手を入れるなら作り直したほうが早いので無視しました。

はじめてのマネジメントから学んだこと

その現場を通してぼくがマネジメントから学んだことは

  • 1日に対応できるタスクはだいたい3個、多くて5個
    • これ以下だとタスクの粒度が大きすぎるし、それ以上だとタスクが細かすぎることが多い
    • 1タスクにかける時間はおおよそ2〜3時間ほどが一番バランスがいい。
  • タスクに優先順位をつけて、合意をとる
    • 当たり前のように感じていたが顧客から言われた質問をそのまま投げてくるバカひとが世の中には存在するので今週はここまでしかやりません!というのは非常に効果的だった
  • フルタイムメンバーのありがたさ
    • 今までほとんどのメンバーがフルタイムな職場ばかりだったのでそれが当たり前だったが非常にありがたいことなのだと実感した
    • なによりタスク管理やスケジュールの組みやすさ、計画のしやすさを実感した
  • マネジメントはある種の技術
    • この会社のCTO的な立場のひとが「マネジメントはやればできるようになるよ!」とか言ってて当人は全然できてなかったが確かにある種の技術的な素養があった。
    • いままで属人性の高いスキルだと思っていたが単純に対処手法を理解していないだけだと気づけた。
  • 仕事の信頼は仕事でしか得られない
    • この言葉自体はもっとあとで知ったことだがマネジメントという仕事を通して学生エンジニアのメンバーと信頼関係が築いていけたかなと思ってる
    • 逆に経営層に対しては不満感をもってしまったが

今までマネジメントというのはあまり興味がなく大変そう(コナミ感) と思っていたが実はそうではなくてコードやデザインのように問題解決するためには ある程度出来るようになっていたほうが問題の本質を解決することができるしなにより無駄なところで疲弊せずにすむのだなと実感できた。

まとめ

マネージャーやリーダーになるかどうか?は本人の気持ち次第だと思うのですが エンジニアとしてそういう方面の異質な技術力があるというのはある種の強みになるのかもしれないなと思いました。 マネジメントもやっているエンジニアではなくマネジメントに強いエンジニアをイメージするとニュアンスとしては近いかなと思います。 またマネジメントは扱える範囲がべらぼうに広くて「こんなにいろんなことができるのか!」と純粋に驚きました、プログラミングやエンジニアリングで対応できることのなんて幅の狭いことか!とようやく世のマネージャーやCTOたちがピープルウェアに書かれている引用をよく使うのかが理解できました。

実際にはそれでも嫌だと感じるひともいると思います、そのひとは無理に目指す必要もないかなと思います。 ただぼくが思うにエンジニアリングだけ、プログラミングだけが許されるのは一部の超人だけなんじゃないかなと。 それはマネジメントさせるには価値がないほどに狭い範囲で成果が出せる超人でなくてはそれに専念させる価値を会社側が見出だせないからだと考えるようになりました。

エンジニアにマネジメントをさせることがいいことか悪いことかは判別つかないのですが、そもそも問題解決という意味ではエンジニアリングもデザインもマネジメントも取り得る範囲や場所が異なるだけで行っている本質は然程違いがないんじゃなかろうかと思います。

ただし例外もある

問題は技術力がないからマネジメントに逃げるタイプの人でマネジメント系の本やセミナーに参加して身につけた気になっているひとはかなり注意が必要だと思います。 ぼく個人としてはマネジメントはコードの何倍もの勉強量と質を求められると感じています。

なので技術力がないからと尻尾を巻いて逃げ出したひとが安易に逃げ込む場としては不適切だと思います。 実際には課題から問題の本質を抽出し、それに対して効果的な対策を考え、データを計測し、結果を分析し…とあまりにも多岐の知識、仮説や問題に取り組まないといけないのですから逃げ出した先が地獄の釜だったみたいな結果になるだけだと思います。

ぼくらが遭遇している問題の殆どはマネジメントが起因の問題であると思います。 であるならばそれを解決することが本当の意味でエンジニアリングやデザインに集中できるようになるのではないかと最近考えるように意識が変わったかなとこの1年を振り返って感じました。

3大今年買ってよかったもの

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

よかったもの

Inateck ラップトップスリーブケース

以前も紹介したが今年のベストバイをあげるならこれかなという気がしている。 使いやすく、また使い心地も良い。 不満点もいまのところないため、ほぼ満点に近い。 ポーチもついているのだがそれも結構収納力があるので周辺機器くらいならだいたい入る。 不満点の少なさ、満足度の高さからまだ1ヶ月ほどあるがベストバイといいきって問題ないと思う。

Bianchi リュックサック/ディパック NBTC50

スリーブケースとどちらにするか一瞬悩んだが結局スリーブケースをベストバイにあげてしまった。 このディパック自体は決して悪くない…悪くないのだけど2点だけ小さな不満点があるので順位を下げてしまった、それ以外は概ね満足いく品だと思っている。

不満点:

  • タブレット用スリーブがiPad Pro 12.9インチだとギリギリ、出し入れのときに引っかかることがあって手間。
  • 定期入れなどをすぐに取り出しにくい、ポケットは全体的に見た目以上に大容量で満足している。やはり一手間が惜しい。

今までは通勤用のディパックにNORTH FACEのディパックを使用していたのだがタブレットと書籍だけもってふらりと読書にいくには幾分大掛かりだったこともあり、もう1サイズ小さいものを探していた。 持ち物としては弁当、水筒(500ml)、タブレットに書籍。あと通勤後に汗をかくため着替えを詰め込めればOKということでこのサイズがベストになった。

このディパックで満足度が高い点としてショルダー部分がNORTH FACEのものに比べてずり落ちにくい点がある。 NORTH FACEのものはチェストストラップがあるが使うと窮屈、使わないとずれ落ちるという微妙さがあった、その点が結構ストレスになりがちだったので解消されてQOLが上がった気がする。 値段もNORTH FACEのものより安かったし、特にぼくが気にしていたディパック自体が自立する(会社で地面に置くため)という点でも安定しているので不満点がなければもしかするとベストバイにしていたかもしれない。

APPLE iPad Pro 12.9インチ 2017年モデル用【書き味向上】液晶保護フィルム ペーパーライクなペン滑り!

商品名がよくわからないけど3位がこれ。 いままでタブレットにシートを貼るなんてアホらしい…と思っていたのだけど少し考えを変えた。 そういう意味でノミネートしている。

これは使い方の問題だと思うのだがぼくはよく読んだ本の感想をiPad ProのメモアプリにApple Pencilで書き込んでいる。 ペン先をタブレットに当てたときの感触が硬い、当たり前だしそれが普通だと思っていたのだけどこのシートを貼ってから感想が変わった。

シート後にタブレットでメモを取ると書き味が滑らかなのだ。 以前は硬い、それこそ硝子にペンを当てているという感触だったのが紙とまではいわないがかなり荒い和紙に文字を書いているような感覚に近いものを感じるようになった。 それまであまり意識していなかったが、このことで硝子板にペンを当てるようにメモを書いていたことがそこそこストレスだったのだと自覚するに至った。

たまたまだが「書き味向上」という文字につられて購入したが割りと正解だった、とはいえ他のシートを試していないのですごくいいとも言い難いのだが。 また他のシートに比べて若干高めであるが個人的にはApple Pencilを使うなら買って損しないんじゃないかなと思う。

まとめ:

電子機器そのものではなく、それを運搬するものや保護するものがベストバイだったのは改めて考えてみてもちょっと意外だった。 ワーストバイをあげるならApple Pencilになる、充電方式がクソいのとバッテリー容量が単体で確認できないのは大きな設計上の問題だと思う。

2割に集中して結果を出す習慣術

結論:

なにはともあれ結論から述べる。

この本は愚にもつかない内容だし、全体的に目新しさも具体的な解決の話もほぼ皆無だ。その辺にある自己啓発本に書かれているものと然程変わり映えしないものだと思う。

だけれども疲れているときや精神がネガティブなとき、ダウナーな思考が続いているときに読み返すと「これは出来ている」「これは出来ていないから出来るようにするには○○しよう」という一種の踏み絵的効果がありそうだなと思った。

全てを満たす必要はないが「自分が出来ていない重要なこと」を見える化するのにちょうどよいページ数と文章量になっている。

感想:

殆どは「やらないことを決めよう!」とか「やることを絞って短時間でやりきろう!」とかそんな話しばかり。 なので当たり前の話ししかされていない。

その上で「これ出来ていないな?」と強く思ったのが以下の5点。

  • 最も効果を出している人にインタビューする
  • 強みを活かした成長戦略を考える
  • まずやることを決めて、とりあえずスケジュールにいれる
  • まず試しに動いて、本格化させる
  • 満足度を数値化し、グレーゾーンを見出す

気になった点や意見、反論、補足なんかをメモしていたけどやはり自分にいま大きく欠けていると自覚している点である↑の点が印象深かった。 奇しくも今は年末であるし、忘念する前に本書を読んだことで振り返りが出来た気がしている。

来年はこれらを課題としてPDCAを回していこうと思う。 そういう意味では1200円だったし、その分の価値くらいはあったかなと思わなくもない。

手元においておいて、ダウナーやネガティブな思考に陥ったときに読み返して「どう解決するのがよいか?」を自問自答するきっかけにしたいと思う。

ちなみに本書を手に取った動機だが「副業と本業忙しすぎて時間が足らん、どうすればいいんだ…」みたいに悩んでいたときにたまたま本屋で目についたから。 そういう意味では当初の問題に対する寄与は全く与えていないので解決に繋がるわけではないが見直しを行う際のチェックシート的なものだと思えば買って損したということもないのかな?というのが素直な気持ち。

ただこの本を購入することをおすすめするか?と問われたら図書館とかで借りて読んでみて面白い、あるいは買ってもいいかもな…という気持ちになったら買ってみるといいのでは?くらいに消極的な感じ。 正直本書である必要性はほぼ見出だせないと思う。

プロダクションレディマイクロサービス - 運用に強い本番対応システムの実装と標準化

概要:

satonaoki.connpass.com

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

当選した方は、11月末までに、書籍の感想をブログ、Qiitaなどで公開してくださいね。

とのことで、当選した方なのでブログを書いている。 なおなぜ11月末までかかったのかというと書籍が実際に届いたのが11月24日だったからだ。

ようやくキタ━━━━(゚∀゚)━━━━!!今月中に読了してブログ書くぞい!!!

結論:

まず最初に結論から。 タイトルにWIPがあることからわかるようにまだ最後まで読了出来ていない。 付録を除けば残り6章と7章で34ページなのだが読んでから書いた場合間違いなく日付を交信してしまうため慌ててこのエントリを書いている。 なお本書はやる気さえあれば1日で読了できる程よいボリュームであることをここにお伝えする。

そのうえでこの本を読んだ感想は「モノリシックなサービスで心を痛めている」「マイクロサービスという名前は知っているがどういうものかきちんと理解していない」そういう人に手にとって欲しいと思わせる書籍である。

冒頭にも記載されているが本書はステップバイステップなチュートリアル的教本ではない。 マイクロサービスエコシステムをUberの事例を元に8つの原則に分解してなにか特定の言語やフレームワーク、実装に依存しないように汎用的に書かれている。 この書籍から学び取れることは本書の各章で書かれた標準をきちんと理解したうえで「さあ自分たちのサービスに当てはめるためには何が必要だ?」というマイクロサービス化する際に基準となる部分を担ってくれる実用書であるとぼくは紹介する。

なおこの内容は冒頭に書かれているが実際に読んでいるとそのことが非常に体感的にわかるようになると思う。

感想:

ぼく個人の本書を読んだ感想としては「マイクロサービスを構築するのは非常に難しく、繊細で、パワーがいる」ということが学べたと感じている。 というのもぼくは今までのプロダクトでさまざまなモノリシックなサービスに触れてきた。 そうしたときに「ここの部分だけ切り出せればいいのに…」「この部分とこの部分が疎結合にして1つの群体としてのサービスが構築できればスケールしやすく現在抱える問題も全て解決するのに…」というようなことを考えてきたし、感じてきた。

それそのものは確かに正しいのだけど「じゃあ実際にマイクロサービス化すればどうなるのか?」というところまでは考えが及ばなかった。 これは当たり前でモノリシックなサービスをマイクロサービスへ移行したことがないからだ。 (疎結合にしたことはあるがそれはマイクロサービスとは程遠いものだったので含めていない)

ともあれ、本書ではマイクロサービス化することで顕在する諸般の普遍的な問題について書かれている。 「マイクロサービス化するとここが問題になるぞ、さあどうする?」というわけだ。

そして本書はアドバイスはしているが明確な解答を避けている、何故ならマイクロサービスが同じ構成になることは極めて起こり得ないことだからだ。 Uberで解決した方法が自分たちにとっての最善でも解決にもなりえないことがわかっているからだ。

あくまでも汎用的な問題に対してどういう解決のアプローチを取るとよいか?というアドバイスレベルの内容に留めているように感じた。 そしてそれは正解だろうとぼくは感じている。

書籍プレゼントのためではないがぼくはこの書籍をあと2回、つまり都合3回は最低読み込もうと考えている。

1度目はマイクロサービスとはなんぞや?という問題を解決するために読む。 2度目はマイクロサービスエコシステムの8つの原則がどういうものか、それぞれの標準とはなにか?を理解するために読む。 3度目はマイクロサービスを自分たちのサービスに当てはめてどう調整するか?という実用としての補助のために読む。

と1度目に読んでいて「これは何度か読み直したり、理解しなくては本書の本当の価値が得られないな」と感じたためだ。

奇しくもいまぼくの職場では「障害対応」や「保守性を高める」ということで議論が起こりがちになっている。 これはここ最近問題が発生し、それが人為的なミスからシステム的な対応、根本的な解決が求められるという事態になっているためだ。 ところが「やりたい」という意思は各人持っているものの実際にどこまでやるのか、どれくらい大変なことなのか?があまり理解されていないように感じることがあった。

本書を読んでもらえればどういう方針を取るのが最適であるのか?を考える一石を投じることに繋がるのではないかなと感じ、そういう意味でも実用書としての価値が高いなと感じる事ができた。

偶然ではあるものの書籍プレゼントをされ、読む機会が得られたことを嬉しく思っている。 もし当選していなかったなら恐らく自分で購入していただろうことは間違いがない。 Kindle版がでたら是非とも購入させてもらいたいと考えているので何卒ご検討のほど……。

以上! 実用書として素晴らしいバランスのよい良書でした。 とりあえず残りの6章7章&付録を読み切って週末に突入したいと思います。

追記:

読むぞ!

いただきまーす!

なお、一応サボっていたわけではなくポートフォリオサイトをVueで書いたり、人と会う予定がありそちらに出向いていたりで中々まとまった時間が確保できなかっただけなのだ!と言い訳させてほしい。 恐らく本気で読めば8時間かからずに読了できるんじゃないかなと思ってるので読書が速いひとは買ったその日に読み切れる内容になっていると思います。

追記2:

読み終わったぞ!!! 基本追記することはほぼないのだけど1箇所だけすごい刺さった部分があったのでなぜ刺さったのかだけ書いて終わりにしようと思う。

ドキュメントの更新が行われないのはサービスの技術的負債の1つ

というようなことが150ページに書かれている、原文ままではないが主旨は変わってない。

ドキュメント大事だけどどうしても実装優先だし、タスクから漏れやすいよねと常々思っていて、今の会社でレガシーなサイトを触ったときにドキュメントがオオカミ少年状態になっていて殺すぞ!!!みたいな気持ちになったので本当にドキュメントは大事だなって感じた。

だけどどうしてもドキュメントそのものはサービスの動き、そのものに影響しないので軽く見てしまいがちだったのだけど ドキュメントのメンテナンスを怠るのはそのまま技術的負債だと考えれば、定期的にドキュメントの見直しが必要だし メンテされていないならそれはしないといけないし…と考えるに至り、サービスの技術的負債という表現が非常に鋭いなと感じた。

いやいやなにいってんの、そんなの普通でしょ?と思うかもしれないがこういう現象はままあるので学びがあるなと思った。

チームの能力の下限は誰が決めるのか?

まず最初にこれは過去の経験からぼくが現在考えている仮説でしかない点を留意してほしい。 タイトルがあおり気味な点は懸念しているがこの課題の仮説を考えたときに適切なタイトルがこれ以外に思い浮かばなかったためそのまま採用している。

チームの能力の下限とは

いままでに体験したチームの中でこんなに能力の高いひとがいるのになぜこのチームの能力は低いのだろうか?と感じることが幾度かあった。 最近ふとした現実逃避を行った際に「これはチームメンバーの最も能力が低い人間に依存して発生する問題ではないだろうか?」と思い至った。

理由として「水は低きに流る」ではないがレベルの高い方にあわせるよりも低いほうに合わせるほうが簡単だし速い。 急激な成長が見込めない以上レベルのが高いメンバーが低いレベルにあわせるほうが合理的だと考えたからだ。

しかし例えばこれが新人だった場合はどうか? この場合新人は伸びしろと成長速度の早さからこの問題に適応しにくい存在であると仮定できるのではないかと考える。

犯人はヤス

つまりチームの下限を決めるメンバーというのは「そこそこ経歴が長く年齢もある程度あるメンバー」ということになる。 そしてスタートアップやベンチャーなどの能力至上主義でもない限りこの手のメンバーというのはそれなりのポジションにいることが多いように思う。

例えばリーダーやマネージャーのようなポジションだ。 もしそのような発言権の強いポジションにチームの下限を決める、あるいはそれに近いメンバーがいた場合、これはチームの能力に対する枷になっている可能性が非常に高いと思う。 単純に年齢が高いだけではそう感じることがないのでやはり勤続年数が1つのキーワードなのではないかと思う。

ボトルネックが組織の下限を形作る?

つまり、そのボトルネックとなるメンバーのカバーできる範囲でしか行動が許可されないため能力的に高い人間が挑戦しにくい環境を作ってしまうと考えられる。 少なくともぼくの経験上、良いマネージャーはある一定以上の能力値を誇っていた。 だからこそなのかは因果関係がはっきりしていないがその下で働くときに不自由さを感じることが少なかった。 ところが下限に近い能力のマネージャーのもとで働くと檻の中で働いているような感覚に陥ることがある。

これは選択できる幅の差ではないかと考えている、能力が高い場合は挑戦をしても最悪マネージャーがカバーをしてくれるという安心感がある。 ところがそこに信頼がないマネージャーと働いている場合、全て自分で解決する必要があるため心理的安全性を確保するために安全方向にマージンを取ってしまい結果として無難な選択肢を選ぶこととなり、それが檻の中で働いているという比喩表現に繋がるのではないかと考えた。

スキルアップのモチベーション

閑話休題

ぼくたちエンジニアやデザイナーは他の職種に比べて精力的に自己学習、自己研鑽に励んでいるように感じる。 これはつまるところ、自己のモチベーションであるところもあるが現状を打破するためには技術力が必要であると感じているためではないだろうか?

もちろん「こんな会社転職してやる!」とか「もっとレベルが高くなりたい!」という個々人の動機はあると思う。 会社や組織をよくするために自己研鑽に励んでいるつもりはないと恐らく多くの人が考えているのではないかと思う。 それはそれとして結果としてそれこそが現状の組織の課題であると認識してはいないか?というのがこの疑問の趣旨だ。 つまり能力の下限を引き上げなければ自分たちにとって良い未来が訪れないと感じるところがあるということだ。

そう考えたときに組織のフェイズが重要な要素になるとぼくは考える。 サバイバルフェイズのように目の前のタスクに追われ続けていては能力の下限に対する改善は行えない、これはほぼ間違いなく実行に移せない仮に計画しても中折れしてしまうか中途半端に行い有名無実化するのが関の山だろう。 結果、成果のレベルが上がらず同じようなサイクルを延々と回し続けるというつらい状態を継続してしまう。

会社組織としてみたスキルアップ

急成長したスタートアップやベンチャーが勉強会やカンファレンスなどでスキルアップに対して肯定的であるのはこの点にも一因があるのではないかと考えた。

エンジニアやデザイナーに対する福利厚生としてだけではなく、それが結果として組織の能力値の下限を引き上げる効果があると理解しているのだとしたらサバイバルフェイズでいつまでも燻っている企業との差は凄まじいものになるのではなかろうか。

業績などの目に見える部分以外のところで歴然たる差を生み出しているように感じる。 だからこそさまざまな企業や組織がサバイバルフェイズから学習フェイズへの移行、そして自己組織化への改革へと手を伸ばしているのではないだろうか?

どうすればよいか?

「チームの能力の下限が低い」という課題があったと仮定してではどう対処するのがよいか?

多くの場合、急激な成長が見込めないメンバーこそが下限の原因であると考えていることは先程述べた。 であるならば急激な指導や教育は逆効果であると思われる。 何故ならば彼ら彼女らはいま現在でも困っていないからだ。

困らないからこそ能力が低くても、自己研鑽に励まずせいぜいが現状維持レベル(少なくとも当人はそのつもり)をしているのだと考えられる。

であるならば本人の自由意志で勉強会の参加や自己研鑽を待つのは正攻法ではない。 ある程度強制的に参加させ、どういう課題があるかを自覚させるように持っていく。 それによって目的意識や目標が漠然とながら生まれる。

それらがないままに強制的に学びの場に打ち込まれても寝てるか、そっぽを向いているかのどちらかだ。

これがアメリカのような契約社会だったならば「お前はクビだ」の一言で済んでしまうのかもしれないが ここは日本なのでその対応は現実的でない、また勤続年数がそこそこあるメンバーにその発言はしにくいだろうと思う。

なのでまずは強制的にでも能力値を上げる、少しでも上がればその分業務の負担が減る。 業務の負担が減ればその分自己研鑽などに当てる時間が増える。 このサイクルをとにかく回していくしかないのではないかと思う。

ここで重要なのは勉強会に参加させることが能力の下限をあげることではないということだ。 勉強会に参加しただけではなにも能力には寄与しない、発表をする、手を動かすことで初めて「かしこさが1あがった」状態になるのだ。 ここを勘違いして講師役の人から内容を聞いただけでやった気になってしまう人がいるかもしれないので念のため注意書きを残しておく。

まとめ

  • 特効薬はないのでまず下限にいるメンバーを調教する
  • 中長期的な対応が必要になることを自覚する、一気に全てをひっくり返すことは難しい
  • 何が問題であるのか?仮設を立てて検証、実行することこそが肝要