続・玉木聖愛

去る１２月２５日、東新宿駅からほど近い新宿JAMというライブハウスで玉木聖愛さんが出演するライブを見に行ってきました。

玉木聖愛さんについては、２年近く前の記事で紹介していますが、それ以来、ライブに行こうとおもいつつ、どうしても予定が被ってしまい行けないでいました。

smartenergy.hateblo.jp

２３日からの２５日の３連休、私はこもって黒い画面と向き合い、せっせとプライベートなpublicリポジトリにcommitを積み続けるという苦行をやっていました。少しは外に出ないといけないと思い、最終日の夜は、東新宿へ。この駅に来たのは就活の時以来でしょうか。

ライブハウスは苦手でイケイケなやんちゃな方が多いし喫煙可ですし、今回はワンマンライブではないので、決して上手くもない人のパフォーマンスを見なければいけなく、よっぽどのことがない限り行かないのですが、久しぶりに玉木聖愛さんの歌が聴けると思い、恐る恐る行ってまいりました。

生歌を聴くのは２０１５年３月の日吉以来ですから、１年９ヶ月ぶりです。

歌ったのは私が初めて聴く曲でしたが、バンドでの出演だったので、元気な曲でした。Youtubeや日吉では、３６６日（HY）や西野カナ、阿部真央の曲が多かったので、それとは全くイメージの違う曲です。こういう曲も歌えるのだなと玉木聖愛さんの幅の広さに驚きました。

ただ、最も印象に残っているのは、複数いる出演者の中でボーカルとしては圧倒的に格が違ったということです。他のボーカルの方は、バンドの演奏に声がかき消されて何を歌っているのかわからなかったり、伝わってくる感じがあまりしなかったのですが、玉木聖愛さん1人だけは、後ろの方で聞いている私のところまで声が届いて、伝わってくるものがありました。

出演が終わった後、本人と少し会話をさせていただくことができたのですが、バンドやダンサーもつき、２年前より体重も10 kgほど減ったそうです。川崎で見た時はすこし体つきが大きく、それが声に乗ってくるのかなと思って見ていて、その時の印象とはだいぶ変わっていたので、そのストイックさに感服しました。

こういう世界で勝ち残っていくためにはストイックさは必要不可欠なものです。これはそう遠くない将来にもっと多くの人に知られる存在になるのではないかという確信を持ちました。

今は以前所属していた事務所をやめてフリーで活動中で、オーディションも何個か受けているそうです。近々新たな発表があるかもしれません。

私が文章で書いてもなかなか伝わらないものがあるので、是非動画などで感じてください。

玉木聖愛 - Google 動画検索

また、2017年3月25日(土)には、ライブがあるそうなので、生で聞きたい方は是非行って見てください。

Facebook　Twitter

 Amazonでシングルも購入できます！

自由な社風

２０１７年最初のブログ更新になります。明けましておめでとうございます。

昨年もいろいろありました。社会人３年目ですが、毎年毎年いろいろなことがあるものです。

昨年は３年で３社目という「近頃の若い者は」という感じで転職をし、２年連続で、健康診断を２回受ける（通常＋入社時検診）という健康意識の高い日々を送っています。今年は２回とも胸部X線で左気胸になる可能性が診断され、また肺に穴が空くのではないかとドキドキしています。

さて、少し前に「ドワンゴの呪い」と題したブログを読みました。ドワンゴの自由な社風について書かれたものですが、「自由」という観点からみれば、私が昨年１０月まで勤めていた会社もなかなかの自由だったと思います。

全社的な始業は朝１０時なのですが、エンジニアは裁量労働制なので、朝１０時に来なくても全く問題ありません。中には１４時ぐらいまで予定をunavailableで埋め尽くし、１５時に出社する強者もいます。裁量労働制がうまく回っている良い例ではないでしょうか。

服装も自由で、冬でも半袖・半ズボンOKです。そういうディレクターもいます。

エンジニアとしてのメンバーのスキルも高く、２０代の超優秀なイケイケエンジニアも複数名いますし、３０代後半の安定感抜群のエンジニアもいて、学べることは多いです。

そういう意味で、前職は非常に働きやすい環境であったと言えます。欲を言えば、まだまだ彼らと一緒に働きたいというのが本音です。事業は違いますが、今の会社と一緒になればかなりの良い化学反応を起こす気がしています。人間的な面でも技術的な面でもです。合同開発合宿や人材交流をできたら良いなと思っています。

ではなぜ辞めたのかというと、もともと志向していた業界で、Webエンジニアという現在のスキルを活かせる会社と出会えたということです。

もともと政治やエネルギーといった公共性の高い分野に関心を持っていた私は、そうした方面で働きたいと思っていので、そのような会社と出会えたから転職することにしました。

話を元に戻すと、「自由度の高い会社」という意味では、前職もかなりあてはまるのではないかと思います。裁量労働制がうまく回っている良い例であるともいます。

ただし、エンジニアはそれぞれ役割があります。たとえば、技術力がすごく高いけれども、裁量労働制をふんだんに駆使して午後出社する人もいれば、技術力はさして高くないものの、コミュニケーション能力があり、営業やサポートとも円滑に会話ができ、業務要件を素早く汲み取り実装ができる人もいます。

会社としてはそれぞれ必要な人材だと思います。エンジニアの能力を測るには、技術力だけでは測れない部分もあります。

不具合報告はサポートや営業から上がってくることが多いので、定時に出社することは、不具合に素早く対応するためには必要なことでしょう。営業やサポートはシステムのことがよくわかっていないので、対面で伝えた方が伝わりやすいということはままあるので、リモートで対応しきれない部分もあるわけです。

中には、技術力が高くて、定時に出社し、コミュニケーション能力も高くて、人当たりも良く、要望にも愚痴一つこぼさず粛々と対応してくれるエンジニアもいると思いますが、必ずしもそういう人ばかりとは限りません。だからこそ共に働く仲間を集めて会社を回していくわけですが、人によって何を重要視するかは異なってくるので、そうした様々な観点から会社の制度を構築していく必要があります。

私が会社を辞めた内部的要因の一番大きなものとしては、最後まで人事部長と相いれなかったというところが挙げられます。

当時、私がいた時には、休みがちの人が多く、私が辞める前日にも数ヶ月の休みから復帰した方がいました。それぞれ理由は様々なのですが、私は一緒に働く仲間である以上、どんな方でも働きやすい風土を作るべきだと思っています。私だっていつ会社に来れなくなるかわかりません。ベンチャーで働くと常にフルスロットルを求められますから（現に１２０％の成果を要求されていた）、突然生気が切れることは往々にしてあります。その恐怖とも戦いながら働いているわけですが、そのような状況で継続して最高のパフォーマンスを出し続けれる人はほんの一握りでしょう。

事業は一時的にプラスになってもそれが継続しなければ意味がありません。私は継続的に社会に価値を提供していくにはそうした側面の重要性を訴えてきましたが、人事部長には響かず、面談では「従業員のガス抜きしておけば良いんでしょ」という魂胆が丸見えで、最後まで理解されることはありませんでした。

とは言え、そういうことを気にせず、午後出勤可！という裁量労働制を十分に満喫したい方には前の会社はとてもオススメです。前職の悪い点も少し書いてしまったので、具体的な社名は伏せますが、個別に連絡いただければお教えしますので連絡ください。

Wantedlyでは今もエンジニアを募集しているので是非。アルバイトエンジニアもかなり勉強になる環境だと思いますので、応募してみてはいかがでしょうか。

（特に紹介したからといって私にはなんのメリットもありません。）

Webエンジニアの苦手な仕事３選

エンジニアリングに関する話題は別のはてなブログで書くこととが多いですが、今回は読み物ということで、このブログで書いて見たいと思います。

Webエンジニアの仕事は多岐に渡ります。私はアプリケーションよりのエンジニアなので、主にソースコードと呼ばれる英単語の羅列（ときたま日本語）を書いたり、営業やサポートからの要件を聞いて設計をしたりしています。

その中でもWebエンジニア歴１年半弱の私が苦手とする仕事を３位から順に３つ上げていきたいと思います。

第３位　環境構築

第３位は環境構築。私はアプリケーションよりのエンジニアなので、設計やプログラミングに対する苦手意識はあまりないのですが、開発環境を作るための環境を整備したりする必要はすべからく全てのエンジニアに求められるスキルです。

あらゆるライブラリはバージョンが違うだけですぐに動かなくなるのが常です。設定ファイルの置き場所が変わっていたり、なぜか相性が悪かったり、原因は様々です。エンジニアがまずやるのはそのエラーメッセージで検索することです。しかし、同じエラーメッセージでも原因が違い、自分の環境には当てはまらないこともありますし、当てはまる場合でも、多くは英語で書かれている場合が多いので読み飛ばしてしまう場合もあります。最終的に本家本元のドキュメントを読みに行く場合でもやはり英語なので、読み解くのには労力が入ります。

同じ環境を構築しようと思っても少しの違いで動かなくなるので、毎回環境構築は怖いのです。

第２位　レビュー

エンジニアはお互いの作業が正しいかどうか、リリースに足る品質かをチェックし合います。これがレビューです。このレビューほど頭を使うものはありません。

そもそも、他人がやっている仕事がどういうものかを十分に理解しなければレビューなんてできません。そこから把握する必要があるわけです。時には、ソースコードを読むだけでなく、自分の環境で動かして見たり、直接聞きに行くなどして背景を把握します。それだけでもそれなりの労力だと言えます。

加えて品質についても担保しなければいけません。テストが十分に書かれているか、コーディングガイドに乗っ取っているかなども大事な要素です。先輩のレビューをするときも、自分が試されているような気がしますし、あえて指摘が必要なプルリク（レビューを出すために作る）を出してくるかもしれません。後輩のレビューをする場合でも、やはり自分の環境に持ってきて、うまく動くかどうかをチェックする必要がありますし、「あれ？」と思ったところを修正して実際に動かしてみるまでは指摘なんてできないので時間がかかります。また、いかに相手を深いに思わせず、気持ちよく修正してもらえるかというコミュニケーション能力も必要です。デール・カーネギーの「人を動かす」も読んでおく必要があります。（半部冗談・半分本当）

自分のエンジニアとしてのレベルが一番分かるのがレビューだと思います。それゆえに苦手なのです。

第１位　デプロイ（リリース作業）

映えある第１位は何と言ってもデプロイでしょう。新しく機能を追加したり、バグを修正したりしたあとは、本番環境に反映させなければいけません。そのためには様々な手順を踏む必要があり、その一連の作業のことをリリース作業と言ったりします。本番環境に反映させる前には諸々の前作業があったりするわけです。そしてそれらが一通り終わり、実際に本番環境にソースコードを反映（展開）させるのをデプロイと言います。（厳密には違うかもしれません。この業界は用語の使い方に厳しいので優しい目で見てください）

この作業は、基本的に単純作業で、一度身につけてしまえばスキルの上達はありません。しかし、本番環境に反映させるということは、それだけ不具合が発生したり、負荷が高くなってしまってサーバーが落ちたりする確率が高いということです。そのため、一瞬たりとも気が抜けません。

不具合があれば、サポートとも連携を取らなければいけませんし、どの修正で不具合が発生したのかを見極め、適切に対処しなければいけません。必ずしも自分の修正した箇所のみをリリースするとは限らないため、日頃から、どの人がどのような作業を行なっているかを大まかに把握し、発生したエラーから修正してもらうべき人に連絡する必要があります。取り返しのつかない不具合であれば切り戻しを行う必要も出てきます。その判断力も必要になってきます。

デプロイ作業はエンジニアリングのスキルとは別の総合的な人間力が試される作業と言って良いでしょう。

一番精神的に疲弊する仕事がデプロイと言って過言ではないと思います。エンジニアでデプロイ作業を好んでやる人はあまりいないのではないでしょうか。

いかがだったでしょうか？（久しぶりにこのフレーズ使った！）Webエンジニアの生態が少しは垣間見れたのではないでしょうか。

私たちは、どんな手強い環境構築にもめげず、どんな鋭い指摘にも動じず、多発するデプロイ時の不具合にも平常心を保てるエンジニアを募集しています！

We are hiring!

いけてるベンチャー起業の技術ブログならこうなりそうですが、私は一個人なので、残念ながら募集はしません悪しからず。