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

去年末の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本だけは今年中に読破するつもりなのだけど中々厳しい感じで第一次世界大戦中のドイツ軍もこんな感じだったんすかね?と最近幼女戦記読んでた影響で考えたりしています。 アバババ。

しがないラジオ 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年を振り返って感じました。