JaSST'20 Tokyo RejectCon
勢いでブログ枠に参加登録していたイベントに参加しました。
なぜ「わかった」と返信したのか、今でも覚えていません。 「そういうこともあるか…」と勤務先から前向きに会場へ向かおうとした矢先、お気に入りのジャケットが派手に破けました。心も破けそうになりました。わかった
— Mass Kaneko (@masskaneko) January 29, 2020
主催の tsuemura さんとは彼がソフトウェアエンジニアになる前からの間柄です。 昔から変わらないなと思うのは物おじしないことで、イベント慣れしているという印象でした。 特に、「節度を守っての行動をお願い致します」とアナウンスした直後に 「今日は節分なので拍手の代わりに豆をまいても結構です」と述べて、節度とは一体何かわからなくなったのが最高でした。
以下、発表ごとの感想です。 私はモバイルと Web はよくわかりませんし、聞き飛ばしてしまった部分もあるので、変な理解をしているかもしれません。
note でのテスト自動化に関する取り組み
iOS アプリのテスト自動化のお話でした。 Web は毎営業日デプロイしているけど iOS アプリはそうでもなくて、リグレッションチェックを効率化したいとのことでした。 「5種投稿、会員登録、ログインくらいができれば」と言っていた覚えがあります。スモークテストなのかなと理解しました。 ツールにはサポートが早いことから magicpod を選んだとのことです。
QA部門にいる発表者と一人の iOS エンジニアが組み、週15分の定例会議を設け、毎日一回リリース版で実行という形で歩み、変更箇所に集中できるようになったことが良かったことだそうです。 はまりを解消するためにエンジニアを巻き込むのが大事とのことでした。 どのようなはまりなのか聞き逃してしまったのですが、iOS アプリ固有のテクニカルな何かだったのでしょうか。 Pull Request をトリガーに実行すると時間がかかるそうで、Android の方が早いそうです。
発表者の増原さんは #ソフトウェアテスト タグがついた note 記事を書くとQA部屋に流れてくる仕組みを作っているそうです。
サービス愛と職業愛があるなあという印象でした。
リベラル・アーツの世界〜Flow理論に学ぶレベルアップの鍵〜
冒頭で「ソフトウェアテスト一切関係ありません」とのたまってヤベェなと思いました。 お話は面白くて、個人のレベルアップに適した状態を "フロー体験とグッドビジネス (チクセントミハイ著)" を参照して語るものでした。 横軸に能力、縦軸に挑戦を設けたメンタルステート図では、不安、退屈、覚醒、コントロール…そして最も右上のフロー状態という領域があり、 フロー状態へ至る際のルートについて語られました。簡単に言えば、能力を上げるのと、挑戦的なことに手をつけるのと、どちらを先にするかということです。 挑戦ルート、能力ルート、という言葉が使われていました。
発表者は、テストコードを書いているときはコントロール領域にいて、以前は心配の領域にいたのではないかという自覚があるそうです。 メンタルステート図が頭にあると、そういった振り返りができそうです。
フロー体験という言葉は初めて聞きました。
「ゾーンというとわかるのではないか？スポーツの世界はゾーンになりやすいように設計されている」
という説明があり、そういえばゾーンであればどこかで聞いた気もしました。
ただ、私のイメージでは、スポーツにおけるゾーンというのは1秒が10秒に感じるような集中している状態であって、
技術者のレベルアップに適した状態とは時間単位がずいぶん違うのではないかという印象を受けました。
さて、これは RejectCon でしたよね。これはどうすれば Accept されるのだろうか…と考えると、
…という案が出てきました。いやはや。#JaSST_RejectCon
— Mass Kaneko (@masskaneko) February 3, 2020
同じ能力の人を同じ人数集めて、挑戦ルートと能力ルートに2分させて実験して、挑戦ルートの方が早く育つけどメンタル死ぬ人が多いみたいな鬼畜結果出してもう一度投稿しては
WebアプリケーションE2Eテスト自動化の3つの壁
WebアプリケーションE2Eテスト自動化3つの壁 - Speaker Deck
Web のことはちょっとしかわかりませんが (チョットじゃないぞ)、 何が理想と異なるのか、賢いツールがあるのか、わかりやすいお話でした。
実行速度の問題解決方法としてテストデータをAPIやコマンドで作るというところがよくわかりませんでした。 お話ではView A→B→C があるとき、B, C の前に Aを操作しなければならないとのことでした。 それはわかるのですが、View A に遷移することや、View A での操作をすることを "テストデータを作る" と言うのでしょうか。 また、それらの操作をするための API またはコマンドは備わっていることが普通なのかがわかりませんでした。 「そんなのないよ」という場合も結構あったり？と想像しました。
おそらくこれを含め、お話の最後で「E2EでなくてもいいテストをE2E環境でやっている」と述べられました。 例えば画面表示だけテストしたいときにサーバーサイドとの通信がいらないみたいな場合があって、 でもそうした部分的に動かす仕組みを作るのが難しいのかも、と想像しました。
また、Accept を狙うなら3つのうち1つの壁に絞って特定プロジェクトの改善事例とするか、 沢山の改善事例が3つの壁に当てはまるという話にするか、かなーと思いました。
プロダクト開発におけるアジャイルQA活動
JaSSTRejectConf - Speaker Deck
査読者からの Reject 理由が述べられていて、RejectCon らしい発表だと思いました。 健康を診るという例えは私が前々から意識しているので親近感がありました。 プロダクトまたは組織が今は動いているけど急病になるリスクを検知して手を打つということですね。 具体的なリスクの種別、見つける方法、対処方法を掘り下げると事例発表らしいのではないかと思いました。
なんかだんだん批評家っぽくなってきたぞ。
テスト？自動化？それよりもQA/QCの業務とは（仮）
JaSST'20 Tokyo RejectCon for Session - Speaker Deck
サービスが世に出て何年か経った組織によくある状態はこうなのかも、と想像させられたお話でした。 対ユーザーの活動よりも開発組織内の活動に焦点を当てていたので QA よりも QC のお話だと思いました。
Webサービス企業において Qが頭につく job が個々の開発チームに入るか俯瞰するかという話って どこかで聞いた覚えがあって、掘り当てると何か理解が進むかも。(LIFULL が俯瞰型でメルカリが入り込み型だったような？？)
ウォーターフォール（V字）開発でモブ設計してみた
週一回二時間30分交代とのことなので、ソロが中心で、力を入れる時にモブとしているようです。 見間違いでなければ、人数は開発3人、テスト4人と書いてありました。テストの人が多くありませんか？
本編とは関係ありませんが、そろそろVモデルに全く出会わないキャリアを歩んでいる方も珍しくないだろうなと想像しました。 生まれたときからスマホがあって、ガラケーを見たことがない、という感じで。どうなんでしょうね。
さいごに
発表者の皆様、運営、会場提供をしてくださった皆様、ありがとうございました。
RejectCon っぽくないけど面白かった！というのと、査読者コメントや採択率などの RejectCon っぽい話も聞きたかったというのと、両方ありました。
また、職業柄なのか、事例発表が IMRaD (Introduction – Method – Results – and – Discussion) の構成になっているかを無意識に期待するので、 そうでない構成が多かったセッションを聞いて、「別にそうじゃなくていいのよ」と言い聞かせたりしてました。
あと、ソフトウェアシンポジウムのプログラム実行委員長から論文出せって言われて、うっかり「ネタあります」と答えてしまいました。 さすがにブログ枠ありますに対して「わかった」と応えるのとはわけが違うと思うのですが、はてさて…。
ボーイング737におけるソフトウェア外注の結果
Boeing’s 737 Max Software Outsourced to $9-an-Hour Engineers
長い原文を私から見て要約/意訳するとこうなります。
- ボーイングは航空ソフトウェアの開発費を減らすためにオフショアを企業戦略として大々的に検討。H1B ビザで渡米している優秀な技術者に頼ると時給 $35 になるのを減らしたかった。
- 時給の安いインドのソフトウェア開発企業に外注することに決めた。中には時給 $9 の人も。
- ただし、この企業は航空ソフトウェアの開発経験がなかった。
- ボーイングはこのインド企業に、できるだけ上位の仕様を送り、より下位の仕事を任せるようにした。
- その結果、航空業界人から見れば自明な仕様の理解に 18 回もやりとりするなど、ボーイングの社員はより多くの監督作業をすることになった。
- 作られたソフトウェアは、ボーイングが培ってきた設計原則に違反していた。テストもろくにされなかった。
- 監督作業や彼らの誤りの修正を換算すると、安くしたはずの時給は $80 にもなっていた。
- ボーイングのベテランエンジニアは、「ボーイングの設計者の能力は時間と共に低下しているように見える」と語った。
- 結局、新製品の市場投入は 3年も遅れ、予算も数十億ドルオーバーした。
- ソフトウェアの欠陥によって、2018年10月と2019年3月に2件の墜落事故を起こし、346人が死亡した。
- 長年ボーイングの技術者を務め、2015年から CEO となった Dennis Muilenburg は「これまで外注していたソフトウェア開発を内製に戻す」と述べた。
私の知識と経験では、高品質なソフトウェアを開発するには、医者が持つような体系的知識とスキルに加え、数学者やアーティストのようなセンスが求められます。 ユーザビリティが重視されるゲームやモバイルアプリ、セーフティが重視される自動車や医療機器など、製品分野によって求められる品質は異なりますが、 ベースとなる知識・スキル・センスは同じです。重要なのは素人にはできないということです。
素人でも、高校までに文系でも概ね身につくであろう命題論理・述語論理をもとに要求仕様を自然言語で書き、簡単なループや条件分岐のあるコードを書くことは 見よう見まねで可能でしょう。しかし、それだけでは、影響範囲を局所化して再利用するための構造設計、高速なアルゴリズムの設計、システムの一部が故障しても継続稼働可能な信頼性、バグを狙い撃つテスト設計、 成果物間のトレーサビリティ確保、円滑なバリューストリームを実現するツールチェーン、ソフトウェアの特徴を考慮したプロジェクトマネジメントと品質保証といった、 高品質ソフトウェアに求められるエンジニアリングは到底実現できないことでしょう。
中には、工学や科学を専攻していなくとも、独学と実務経験をもとにソフトウェアエンジニアリングのスキルを身につける方々がいます。 大学でソフトウェアを学んだ人を追い抜くケースも見ますが、そう多いものではありません。
なので、企業は能力の高い人材を探したり、育つ仕組みを整備することが重要です。 そして、そのような人が自国に限られるのであれば、海外に活路を求めるというのは良策かと思います。 それはオフショアという呼び方かもしれませんし、その企業のグローバル開発拠点かもしれません。
逆に、人件費を下げたいだけがために経済発展途上国の企業に外注すると、自分の首を絞める結果となるのではないかと考えます。 ボーイングの件は、それを示す良例ではないでしょうか。
それは能力不足によることだけではありません。 オフショアに限らず外注の場合、要求仕様に基づくものさえ作れば売り上げることができるので、ユーザーにとって価値のないソフトウェアを作るリスクがあります。
外注か内製かについて、どのような条件であれば、どのようなバランスをとるのがビジネス上最適なのか。 それを工学的、統計的に示すには多くの実験をしなければなりません。
そのような工学的、統計的な判断を時間をかけて行うか、 センスや信念をもとに素早く定性的な判断をするかという概ねの二択があります。 企業にとっては前者を選択する余裕は無いと思います。 ボーイングはソフトウェアエンジニアリングにおけるセンスのない経営者が後者を選択して失敗したのではないかと想像しました。
さて、このブログがソフトウェア開発に携わる誰かの目に留まり、何らかの意思決定に影響するでしょうか。はてさて。
全身麻酔で親知らずを3本抜いた
親知らずを一度に3本抜くというのも、全身麻酔をするというのも、入院するというのも初めての体験だったので記しておきます。 これを書いているのは術後1ヵ月～2ヵ月です。結果から書くと手術はうまくいき、そこまで辛くはなく、やってよかったと思っています。
手術をした経緯は、親知らずの前の歯が痛んで近くの歯医者を受診したことに始まります。 その歯を治療をしたいのですが、後ろの親知らずを抜かないと治療ができないことがわかりました。
以前に1本だけ親知らずを抜いたことがあります。 そのとき、治療器具を奥に入れられると吐きそうになることがわかりました。嘔吐反射が一般人よりも強いらしいです。 当時は我慢を重ねてどうにかなったのですが、ものすごく辛くて同じ苦しみを耐えられるかわからなかったので、楽な方法がないか助けを求めました。 そういった場合、全身麻酔下で手術をするという手があるそうです。 全身麻酔をする際には泊りがけの入院になるとのこと。 そこで「そんな大掛かりなことをするなら残りの親知らずも全部抜いてください」とお願いし、大きな病院を紹介されました。
いきなり入院をするわけではなく、全身麻酔ができるかどうかを検査しました。 血液や心電図までとられたのですが、そういうものらしいです。 麻酔医から麻酔時に行うこと、検査の理由、リスクについて丁寧な説明を受けました。
この検査と説明を受けてから入院をするまでの間は2週間ほどだったでしょうか。 入院、全身麻酔、手術というのは初めてのことなので、予習でもしておこうと YouTube を見ることにしました。 世の中は YouTuber だらけなので "親知らず全部一気に抜いた" といったものがあるだろうと踏んで探したところありました。 あるもんですねえ。
全身麻酔で親知らず3本一気に抜いた結果・・・ - YouTube
私の場合、1日目は主に検査、2日目に入院、最後の3日目は午前中に退院するというスケジュールでした。
1日目：準備
10時ごろに病院へ。病室は個室で、ベッド、トイレ、クローゼット、貴重品入れがあります。 個室といってもホテルのように鍵つきのドアがあるわけではなく、入口にはカーテンがあるだけです。
食事は昼食と夕食の2回。 病院食はおいしくないものと知人からは聞いていましたが、意外とそうでもありませんでした。
この日は検温や血圧測定などの簡単な検査、麻酔医の問診、執刀医の問診、歯のクリーニングがありました。 それら以外は暇です。 術後何日かは満足に食事をとれなくなるだろうからと考え、 ちょうど YouTube で公式配信されていた孤独のグルメをずっとみていました。
2日目：手術
いよいよ手術当日。6時30分に起床。早い…早すぎる…といっても看護師が各病室を周るだけで、二度寝してよいとのことでした。 この日は朝食と昼食はなく、水を飲むこともできません。 水を飲めない代わりに点滴があります。たしか10時ごろに点滴の器具を腕に設置しました。 そして手術着に着替えました。見た目は完全に病人です。 私の番は前の手術が終わり次第だそうで、何時に始まるか決まっていませんでした。 結局10時ごろに準備ができてから手術が始まるまでに3時間くらい経ったでしょうか。とにかく暇でした。
手術のお呼びがかかったときには「待ってました！」という気持ちで手術室に向かいました。 自分で歩いて手術室に入り、自分で手術台に上がりました。 テレビドラマなどで見る患者はことごとく手術室に運ばれていたのでどこか新鮮でした。
手術台に上がると「これから麻酔薬を入れていきます」と告げられ「はぁい、おねがいします」と応えました。 その次の記憶は病室に戻されるときでした。その間のことは何も覚えていません。
病室に戻されるとき、おそらく2人か3人がかりでベッドに私の体を置こうとしていたのだと思います。 看護師らが私の体を動かす瞬間、私はタイミングを合わせて「せぇのッ…」と言ったのを覚えています。 看護師らが「運ばれる患者が "せぇのッ" って言うのは珍しいねえ」と言っていたのも覚えています。
ほか、ベッドに戻って直後のことはよく覚えていません。 手術が終わったこと、何やらマスクのようなものをつけていることだけわかりました。 しばらくすると思考がはっきりして、不快感が出てきました。 抜歯箇所の痛みはそれほど強くないのですが、口に血がたまっていたり、 喉にも血か淡がたまっている感覚がありました。 そして、それらを吐き出したいのですが、体がうまく動きませんでした。 あれこれどうにかしようとしているうちにシーツを真っ赤に汚してしまいました。 さらに、頭痛がして熱も出てきたので抗生物質を投与しました。 これが術後2時間後のことです。
さらに2時間ほど経つと夕食の時間となり、8時間ほど付き合った点滴も終了です。 この日は朝も昼も食べていないのですが食欲は全くありません。 術中に口をずっと開けていたせいなのか、口の端が切れていてかさぶたになっているので口が満足に開きません。 抜歯箇所は糸で縫ってあるそうなのですが、常に少しずつ出血しているので血の味がしています。 抜歯箇所が鋭く痛いわけではないのですが、常に鈍い痛みがあって口を動かしたくありません。 それでも食べないと治らないと考え、一口噛んで飲み込むごとに気力を振り絞り、完食しました。 前日と違って料理は全て細かく刻まれており、米は米でもおかゆでした。 健康であれば5分や10分で食べて終えてしまいそうな料理でしたが、このときは30分以上かかった覚えがあります。 看護師は完食したことに驚いていました。
食後は調子がよくなり、病室から出て休憩室でコーヒーを飲んだり、家族に手術が終わったことを連絡したりしました。
3日目：退院
この日も6時30分に起床し、朝食までの間しばし二度寝。 痛くて目が覚めるかもしれないと懸念していましたが杞憂に終わりました。
朝食は手術当日の夕食と同じく全く箸が進みません。 相変わらず口は開かないし、血の味がします。 料理も同じく細かく刻まれたり柔らかく煮込まれているのですが、噛んで飲み込むには時間がかかります。 バキという漫画とアニメの作品にて主人公が毒におかされたときの場面を思い出しました。 薬膳料理を「ウマくはないぞ」というセリフと共にふるまわれたり、 恋人に「食ってないじゃん！」と泣きながら叫ばれたりする場面を思い出すと、 食欲そのものは無いものの、治したいという気力が出てきて完食することができました。 病は気からというのはこういうことでしょうか。
朝食後、簡単な問診と直近の生活指導を受け、抜糸の予定日を決めたら退院です。 かかった金額は事前の検査も含めて約10万円でした。病室が個室ではなく相部屋であればもう少し安いでしょう。 虫歯になりやすい親知らずを一気に抜くことができ、その前の歯を磨きやすくなるのであれば安い金額だと思います。 抜歯された親知らずを見ると2本は割られていました。あごの骨を削り、歯を細かくしないと取れなかったそうです。 嘔吐反射のある自分には耐えられなかったのではないかと想像します。 退院後のダメージとして大きいものはありませんでしたが、退院して1週間ほどは集中力が続きませんでした。 それを差し引いても行って良かったと思っています。
さて、親知らずの抜歯は順調に進んだのですが、その前の歯は今でも治療しています。 早く親知らずを抜歯して治療を始めていれば、とほほ。
GitLab Meetup Tokyo #12: 2018年振り返り に参加しました
GitLab ユーザーなので GitLab のイベントに参加してみました。
上記イベントページの概要欄をみると、GitLab ってどんどん成長しているんですよね。 基本的には Git リポジトリホスティングシステムで Issue トラッキングと CI もできる奴、 昔で言えば Trac Lightning みたいな立ち位置かなー(伝わるのか？これ)、という認識だったのが…… Docker イメージを登録できたり、IDE を備えたり、「もうみんな Kubernetes クラスタあるよね」とばかりに Auto DevOps を出したり、 最近では Serverless なんてものまで出てきました。
本家ブログに We believe Kubernetes is the future. と書いてあるのを知り、 「あぁ…そっちに行ったんやなぁ…」という気持ちです。 GitHub および Circle CI, あとは Atlassian 製品のように役割別に製品を分けている同種のツールとは方向性が違うなぁと思わされました。
また、チームでコラボレーションをする環境というのは、幅広い業種や職種に関わるものなので どういった方々が来ているのか知りたくなったのも参加した理由です。 GitLab は Kubernetes が未来と信じる方向に進化しているそうですが、別にコンテナやサーバレス環境で動作する ソフトウェア以外の開発にも使えるので、Web システム以外の世界の方々も来るんじゃない？と思ったんですよ。
とまぁ、知らない機能も沢山あるし、どんな人が来るのか気になったので参加することにしました。
GitLabとKubernetesではじめるAuto DevOps
イベントが始まる30分前に Google カレンダーの通知がありました。 イベント会場まで1時間かかります。遅刻確定です。 アラームを何分前に鳴らすかはイベントによって変えておきましょう。 このブログもイベントが終わってから1ヵ月後に書いているので二重の意味で遅刻してしまいました。 しょんぼり。すみません。
"GitLabとKubernetesではじめるAuto DevOps" の途中から聴講し、ちょうど Auto DevOps のデモを行うところでした。 デモは Spring を使った簡単な Web アプリを変更する際にパイプラインに含まれる様々なジョブが実行され、 Merge Request の画面にも表示されるというものでした。 実際に使われたプロジェクトが今でも公開されており、パイプラインの詳細な実行結果を見ることができます。
デモで使われた sprint-app プロジェクトがあるグループ名は
イベント当日は demo-auto-devops という名前だったのですが、
今は cl-demo という名前に変わっています。
古い URL を開くと新しい URL にリダイレクトされ、
Group 'demo-auto-devops' was moved to 'cl-demo'. Please update any links and bookmarks that may still have the old path.
と表示されます。親切ですね。
Auto DevOps だけでなく Issue やラベルについても触れているのが丁寧だと思いました。 それもそのはず、発表者は日本で GitLab の正規販売代理店に勤めており、コントリビューションも行っている方でした。
LT
ここからは LT (ライトニングトークス) のお時間。 ライトニングといっても、稲妻のような速度で話すわけではありません。しみじみ。
GitLabソースにコントリビュートしてみて勉強になったこと
GitLab Summits 改め GitLab Contribute | GitLab の参加費用は 2499 USD ですが コントリビュートすると無料になるそうで、そのためにコントリビュートしたそうです。 オープンの Issues がたくさんあり、API の変更であれば UI が無いので簡単そうと考え、1つを選んだとのこと。
所要時間は GDK (GitLab Development Kit) のインストールに4時間、 最初のコーディングに1時間、1回あたりの CI パイプラインに3時間、 レビューとそれを受けての変更に10日。
レビューでは「ローカルで Rubocop を使おう」「TDD で書こう」「あそこのコードが参考になる」 といった助言を頂けた、誰かに頼まなくてもコメントをもらえたのがありがたかった、 テストコードが頼りになったとのことです。
自発的に Merge Request に参加する方がいるというのは良いチームですね。
API の変更であることと、Merge Request がクローズするまでに11日間要したことからすると、 該当する Merge Request は多分これですね。複数のレビュアーが助言している様が見られます。 1st contribution というラベルがあるのも面白いです。 もちろん CI パイプラインにある各ジョブの実行履歴も残っています。 開発手法を勉強する材料としても良さそうです。 gitlab.com
(仮) 独自パッチで進化させ過ぎたGitLabのOmnibus package移行
GitLab がバージョン4の頃から使っており、不足していた点を独自パッチで補っていたとのこと。 例えば公式では MySQL を使っていたのをパフォーマンスのために PostgreSQL にしたり、UI を変更したり。 独自パッチの数は 30 以上になっていたそうですが、公式 omnibus package が育つにつれ、 独自パッチをあてる利点や必要性が無くなっていったので omnibus package に移行したとのこと。
私も omnibus package を使ったことがあるのですが、初めて使ったときは既にバージョン8でしたし 独自パッチをあてるという発想はありませんでした。 もちろんソースからビルドするということもなく、Ubuntu にパッケージをインストールして gitlab.rb を書き換えて gitlab-ctl reconfigure を実行する程度のことしかしていなかったので、 別の世界のお話に聞こえました。
確か別の事例で「社内には Ruby on Rails の開発経験を持つエンジニアが多数いたから GitHub Enterprise を使わずとも GitLab (Community Edition!!!) でやっていけると判断した」 という趣旨のものがあったと記憶しているのですが、そういう企業でないとやっていけないのではないでしょうか。 というか、それだけできるなら本家にコントリビュートすれば良かったのでは、というのが感想です。 まぁ、今でこそ上述のようにコントリビュートしやすい土壌が整っているように見えますが、 バージョンが古かった時代は違ったのかもしれませんね。
GitLab-CI/CD+Pagesでポートフォリオを作ってみよう
ソフトウェアエンジニアの中には作品を集めたWebサイトをポートフォリオと呼んで公開する方がいます。 この発表ではそのサイトを GitLab を使って作ってみようというものです。 スライド自体も GitLab にある reStructed Text と Reveal.js を使って作っているようです。 GitLab-CI/CD Pagesでポートフォリオを作ろう
ポートフォリオはこちら。 Portfolio of attakei
Reveal.js はちらっと見たことがあるんですが reStructed Text で書けましたっけ…？ と思ったところ、どうやらそれを実現するものを作ったみたいです。すごい。 github.com
そういえばこのブログもこのイベント参加を機に Hugo + GitLab pages に移行しよう、 それが終わったらこのイベント参加エントリーを書こうと考えていたのですが、 見た目を考えたり、検索機能をどう実現するか調べたり、結局ブログサービスに戻したという文章を見たりして ずるずると1ヵ月経ってしまったので、先にこの文章を書くことにしました。とほほ。
スポンサーLT
スポンサーは Grooves 社です。 頻繁に勉強会のスポンサーをしているそうで「また出たな Forkwell」とツイートされるのが恒例になっているそうです。
なるほど。https://twitter.com/search?f=tweets&q=%E3%81%BE%E3%81%9F%E5%87%BA%E3%81%9F%E3%81%AAForkwell
私は Forkwell Jobs を以前から知っていたので「なるほどこの会社か！」と思いました。 Forkwell Jobs はソフトウェアエンジニア向けの求人サイトで、プロダクト、職務、開発環境などが エンジニア目線で書かれていると感じられます。 転職するわけではなくても、いろいろな会社の開発環境をざっと知ることができて面白いですよ。
ところで「また出たな Grooves」ではなく「また出たな Forkwell」なんですね。なんでだろ。
懇親会
ここからは懇親会。12月20日なので忘年会とも言えます。 料理はお寿司とピザ。私は Connpass などで参加するイベントの懇親会で寿司が出た場合もピザが出た場合も経験していますが、 寿司とピザの両方がそろっている場合は実は初めてかもしれません。お酒もあります。 きっとスポンサーの Grooves 社のおかげです。「ありがとう Forkwell」とツイートすべきだったのではないか…と思いながら乾杯しました。
こういったイベントでは友人がいることも多いのですが今回は知り合いは誰もいません。 あんまりお話は得意ではないのですが、せっかくなので初めての方々とお話しました。
話してみると色々な方がいらっしゃいました。 コンテナオーケストレーションは当たり前という環境の方、 LT であったような独自パッチを使っているという方、 インフラ運用に使っているスクリプトを管理するために GitLab を使い始めたという方、 Git をこれから始めるという方、会社のサーバーはほとんど Windows だけど Linux もあるという方、などなど。 業種は聞く限りは必ずしも Kubernetes やクラウドネイティブに技術的に縁がありそうな方々ばかりではなさそうに思えました。
社内SNSの投稿でこのイベントを知って参加したという方もいらっしゃいました。 で、それを投稿したのは私だと。えっ？？？そういうこともあるんですね。
「海外では Enterprise Edition を使うのは普通。日本ではあまり使われていない。」 という情報も得られました。 これを聞いたとき、JIRA と Redmine の海外と日本での違いを思い出しました。 Google トレンドでみると、海外では JIRA の方が検索キーワードとしての人気が圧倒的に高く、 日本では Redmine の方が高いそうです。なんなんでしょうね。
- 世界の JIRA vs Redmine https://trends.google.co.jp/trends/explore?q=JIRA,Redmine
- 日本の JIRA vs Redmine https://trends.google.co.jp/trends/explore?geo=JP&q=JIRA,Redmine
最後に。ラッキーなことに GitLab 帽子を手に入れることができました！
今は冬で実用性がありますし、友達に自慢することもできます。ありがとうございます。
以上、1ヵ月遅れのブログ枠でした。
チェコ、ドイツ、フィンランド旅行記
チェコ(プラハ, ピルゼン)、ドイツ(ドレスデン)、フィンランド(ヘルシンキ) の3か国を旅行してきた。 主な目的はビール。チェコにはピルスナーウルケル(Pilsner Urquell)というピルスナーの祖となるビールがある。 これをお目当てとして、ついでに周辺にも行くという狙いの行程だ。 計画は同行した友人がほぼ全てを行い、私はそれに乗っかった。感謝感謝。
以下、8日間のことを記す。写真も多いのでそれなりにスクロールすることになるだろうから、最初に私が覚えておきたい点をかいつまんで記す。
- ヘルシンキのサウナ施設ロウリュは最高！！！！！
- ピルスナーウルケルは飽きない味
- 昔の石造りの建物が残った街並みはとても新鮮
- 夏の日の入りは21時以降
- めしは全部うまい。量に注意。
- 観光客を相手にしてる人なら英語は大抵通じる
- プリペイドsimでモバイルインターネットは安心
- 電車の駅に改札はない。特定の地域を一定時間乗るチケットを買う。
- 路面電車は珍しいものではなく一般的
- Google Maps のルート検索は頼りになる
- トイレの多くは有料
- 現金はクレカで手に入れられる
- ヘルシンキのサウナ施設ロウリュは最高！！！！！
さて、ここから本文。繰り返すが、画像つき8日分なので長い。
1日目: 成田からヘルシンキ経由でプラハへ
家を出る前の40分で荷造り。 なんとかなるものである。
プラハへの直通便はないのでヘルシンキを経由する。成田からヘルシンキまでは10時間ほど。 エコノミークラスなので快適とは言えない。こんなときはビールでも飲んで寝てしまおうと思い、1杯目は缶のカールスバーグとなった。
結局、断片的な睡眠をとっただけで大して眠れずヘルシンキに到着。 生体認証パスポートを持ってる人だと自動で入国審査ができるとの案内があったので、そんな機能あったかなぁとダメもとでやってみたら通れた。パスポートを機械にかざすと1つめのゲートが開く。顔をカメラに向け、何秒かすると2つめのゲートが開く。顔の照合をしているのだろうか。その後は審査官がいて、いつものようにパスポートを渡す。あれ？結局、人が審査するのね。
ここで simカードをヨーロッパで使えるプリペイド式のものに切り替えた。TwitterもLINEもGoogle検索も、何もかも使える。ひとまず安心。 私が使ったのは AIS プリペイドSIMカード データ通信 15日 4G/3G というもの。この旅行で行ったどの街でも通信できた。タイの通信事業者らしく、使用し始めるとタイ語が入ったSMSが届く。 日本でも使用することができるので、simを入れ替えるのは出発前でもいいだろう。
ヘルシンキで友人と合流して2時間後にプラハへ。再び飛行機で2時間。空港にはクレジットカードでチェコの通貨であるコルナ(CZK)を買える機械がある。 1000コルナだけ買った。この時点のレートは1円≒5コルナだったので、1000コルナは約5000円だ。 現金などいらないのではないか？とも思ったが、公共交通機関、トイレ代を見越して最小単位を購入した。
このとき、クレジットカードで現金を買ったつもりだった。 しかし、帰国後にわかったのだが、実は買ったのではなく借金をした扱いらしい。 つまりキャッシング。利息がつく。カード会社に電話して繰り上げ返済すれば利息が減る。 といっても、今回の旅行で手に入れた現金くらいの額では利息は数百円なので、電話して振込という手間とそれを覚えておく方が高いと判断し、 何もしない、つまりショッピングの支払いと同じく翌月一括払いのタイミングで返済することにした。 「クレカで他国の現金を買えるのではないのか？何で借金扱いなんだろう？」という疑問が残るが…まぁいい。旅行記に戻ろう。
(画像はプラハ中央駅の外にあるキャッシング機。似たようなものが空港にもある。)
プラハ空港からタクシーでホテルへ。19:30だというのに昼間のような明るさ。空は青い。タクシーの運転手いわく、日没は21時以降で、フィンランドだと1時だそうな。30分ほどでホテルに到着し、時刻は20:00。日本の家を出たのが6:30なので、家からホテルまでの所要時間は20時間くらいか。いやはや、遠くへ来たもんだ。日本とチェコの時差は7時間。日本はGMT+9、チェコはGMT+2。つまり、例えばチェコで20:00のとき、日本は翌日の3:00ということ。
ホテルの部屋でめぼしいレストランを検索して徒歩で向かう。昔からある石造りの建築物をそのまま使ったような街だ。高層建築物は見当たらない。目に入る店は、飲み屋、レストラン、ホテル、土産物屋、ライブハウス、電気店、マクドナルドなどのチェーン飲食店、などなど。
レストランでは早速ピルスナーウルケルで乾杯。うまい。旅の始まりである。時刻は21時。日本の感覚で言えばまだ明るさが残る夕方になりかけといったところだ。 料理は、うさぎの足のロースト、チキンの煮込み、豚の…なんとか、ハンガリアンキューカンバーサラダ。メニューには英語が併記されていて、店員も英語を話せる。問題ない。
肝心の味は……うまい！！心が賞賛するんじゃ。何の香辛料を使っているのかわからないが独特の落ち着く香りがする。チキンとうさぎはやわらかい。豚の料理はさつま揚げのような形をしたピカタなんだけどこれもうまい。優勝。
二日目: チェコ - プラハ観光
旧市街からカレル橋を渡ってプラハ城へ行った後、ウルケルを一番うまく飲ませてくれると評判の店 U Zlehato tygra へ行くという計画を立てた。
その前にホテルで朝食。種類が豊富なバイキングだ。一日目の夕食にひけをとらず、とてもおいしい。チーズの塊が4種類置いてあり、自分で切ってとることができる。ハムとサラミが3種類ずつ。野菜は酢漬け、和え物か何種類か。ケーキが何種類か。トマトと豆のスープ。飲み物はコーヒー、ジュース、紅茶、ミント水。
プラハには地下鉄と路面電車があり、一日券が110コルナであることがわかった。券は地下鉄と路面電車で共通している。券をどこで買えるかわからなかったので、プラハ中央駅ならあるだろうと踏んで歩くことにした。少々迷ったが売り場に着き、1日券を買うことができた。乗るにはまず時刻を印字する必要があり、印字時点から24時間乗ることができる。改札は存在せず、乗車毎に券を見せる必要は無い。ときどき、ホームにいる駅員が券を持っているか確認しに来る。こうして地下鉄に乗り、まずは旧市街近くの駅で降りた。どの駅で乗り降りすればよいかは Google Maps の道案内機能を使えばなんとかなる。
旧市街を散歩。改めて書くが、昔ながらの石造りの建物しかない。
10:30に飲食店で小休憩。ビールを1杯、36コルナ。日本円にして180円ほど。コーラは55コルナ。ビール安い。
カレル橋、英名Carles bridge を渡る。銅像がたくさんある。何の像だかさっぱりわからない。ベルセルクのモズクズ様御一行を思い起こさせるものもあった。 これなんて今にも魔女狩りを始めそうな奴らだ。こわい。
像も多ければ観光客も多い。スリも多いらしいので気をつける。川には鴨の群れがいる。チェコに鴨がいるのか、やつらが鴨なのかわからないが、鴨にしか見えない。やつらはときどき逆さまになり、首を水中につけ、足を水面から出している。魚を捕りにもぐるのならわかるが、何をしているのだろうか。プリプリした体で逆さまになるのは間抜けに見える。
そんな面々を目にして歩いていると、いよいよプラハ城だ。街もそうだったが、城も全面石造りだ。城というより王宮や聖堂などの大きな建物が集まった地帯という方が近いのではないか。もちろん日本の城のような天守閣は無い。荷物検査をして中へ。広く、暑く、人が多い。
無料で見物できる場所と有料の場所に分かれている。無料でもそれなりに楽しめると思う。 今回はBコースのチケットと撮影権を買った。日本語の案内もある。
武具が並んでいる。ベルセルクで見たことある！タクティクスオウガのテンプルナイトだ！…くらいしか感想が出てこないのが悲しい。
このステンドグラスに描かれた人々もドラクエのキャラクターのようだ。色使いがとても似ていると感じた。 もちろん、こちらの方が先に生まれたものであるのだが。
城下町といった風景。「ここがグランバニア城です」だとか適当なことを言っても通じそうだ。
さて、街全体が世界遺産ともいえるプラハ。至るところにIngressのポータルがある。Ingress というのは実際の場所を使ったスマホゲーで、青と緑の2チームで陣地を取り合ったり、行った場所(ポータル)の数を記録したりすることができる。私はこの時点でレベル11であり、12に上がるためにはあと1つのゴールドメダルが必要。そして、ゴールドメダルを獲得できそうな条件としてcapture unique portals があったので、道中で集めることにした。あと100個の unique portals を capture すればレベルが上がる。結果、旧市街から城内の散歩だけで100個集まってしまった。ありがとうプラハ。
城の散歩にも飽きてきたところで、この日の最後の目的地、ウルケルが評判の店である U Zlehato tygra へ。15:00開店に合わせ14:30に到着。早く着きすぎた…待つしかない…。もう歩き疲れており、昼食も食べていないのでおなかもすいている。まだか…まだか…と思いつつ待つ。気づくと後ろに列ができている。やはり有名店なのか。
15:00になり開店。ほぼ満席だ。早速ウルケルを注文…する必要はないらしい。勝手に出てくる。しかも、飲み切ると次が出てくる。終わりにするときはコースターをグラスにかぶせる。まるでわんこそばだ。店員の1人はひっきりなしにウルケルを注ぎ、グラスを洗っている。この光景だけで酒を飲むことができる。料理は、豚の中華あんかけのようなもの、ニシン？の酢漬けでザワークラウト？を巻いたもの、あと2品は忘れた。ほとんどの客はビールだけ飲み、料理を頼んでいない。1杯飲んだら帰る客もちらほらいた。15時だしその方が普通なのかも。我々は料理についてきた大量のパンとビールによっておなかいっぱいになってしまった。
こんな風に空きグラスを置いておくと…
店員が新しいビールの入ったグラスを持ってきてくれる。わんこそばという表現をしたが注ぎ足されるわけではない。
飲んでいる途中、こんな風に泡が偏るのがウルケルの特徴。ほかにもこのようなビールはあるのかもしれないが、私はこれしか知らない。
この日はホテルに戻ってシャワーをあび、19時に就寝。夕食抜き。
3日目: チェコ - ピルゼン
ピルゼン(Plzen)にあるウルケルの醸造所へ。つまりウルケルの本拠地だ。
プラハ中央駅から Západní expres で2時間。日本で言えば在来線特急: 東京〜伊東といった位置づけの電車だろうか。ドア付きの6人部屋が並んだ内部構造になっている。自由席と指定席の区別はなく、席が予約されているか否かで区別する。道中の車窓からは田舎の風景が見える。広い一軒家、牧場、古い工場、山、草原。すぐに退屈になった。この文章はそういうときに書いている。
11:30、ピルゼン駅に到着。醸造所の場所は駅から歩いて5分かかるかくらいの近くだった。早速ウルケルを1杯…うまい。この味にも慣れてきた。見学予約時刻は13:00なので周辺を散歩。プラハと違って近代的なビルもある。といってもここも昔ながらの石造りの建物の方が多い。市庁舎でさえそうだ。
広場には鳩の群れがいる。首振りのしぐさ、人がパンくずをあげるところなど、日本と同じだ。色がちょっと違って、緑とピンクが見られない。種類が違うのだろうか。
公園のような場所を歩いているとviareality というQRコードが描かれている看板を見つけた。おそらく専用アプリのカメラで読むと何かが浮かびあがるのではないか。
いよいよ醸造所の見学だ。我々を含め25人ほどの集団に1人の引率者がついた。解説は英語。見た目や聞こえてくる言葉からして、皆の国籍は多様なのだろう。東洋人らしき人は10人ほど。この見学では醸造所の歴史と設備を知ることができた。
醸造所は1800年代中ばに誕生。それ以前は酒屋ごとに醸造所があり、同じ町の同じ種類のビールといっても味はそれぞれ異なった。また、同じ店であっても品質にはばらつきがあった。発芽、発酵、材料や在庫の貯蔵など、多くの工程において温度管理が重要となる。昔は、冷やす際に雪をかきあつめて地下の専用部屋に放りこみ、そこに大樽を並べた冷蔵室を作った。現在ではより大量のビールを効率的に作るための設備を備えている。量産、管理、再利用のためのテクノロジーは大きく進歩したが、材料や温度などのレシピは昔から変わっていない。…とのこと。
実際の新旧の設備を見学者用の通路から見ることができた。
現在の工場。これはビンを再利用するための工程かな。
近代の設備。
現在の設備。
最後に、冷蔵室…というか地下洞窟のような場所を進むと、樽から無濾過のビールを振る舞われた。樽製の立ち飲み用テーブルまで用意されている。これがうまい！店で飲む樽生や缶のものとは別物だ。うまいが…ここはとても寒い。マイナス何度なのだろう。味わう余裕があんまりない。引率者は「このビールには豊富なビタミンが含まれています。アルコール度数は4.4パーセント。1日1杯までにしてくださいね。」と、高橋名人のようなことを言っていた。しかしこれは2杯目だ。見学はここまで。冷蔵庫から解放された。
時刻は15:00。醸造所併設の店で昼食をとる。アヒル料理を注文。うまい。1皿で満腹に。ホテルに戻って21時を過ぎても全く腹はすかず、2日連続で夕食を抜くことになった。
4日目: ドイツ - ドレスデン
プラハ中央駅から Euro City に乗ってドレスデン(ドイツ)へ。電車で別の国へ行くのは初めてのこと。パスポートはチェックされなかった。 ドレスデンはドイツの東部、チェコとの国境近くに位置する街だ。 これまでにチェコで見た光景とは全く異なり、ショッピングモールやビルが並んでいる。街だ。
ドイツの通貨はユーロだ。もはやコルナは不要。コルナの時と同じくクレジットカードを入れるとユーロの現金を出してくれる機械を使う。
言わずもがな、ドイツもビールの国だ。早速一杯。これにて、ドイツでドイツビールを飲むという実績を達成した。
メニューを見るとチェコとは明らかに物価が異なる。このとき、1ユーロは約130円。
日本円の感覚でいえば、日本と物価はあまり変わらないという印象だった。
連日のパーティ行軍で疲れているのと、この日はさしたる予定も無かったのもあって単独行動することにした。
散歩をしていると馬が目に入る。ファイアーエムブレムのパラディンだな、くらいしか感想が出てこない。
川がある。エルベ川という名だそうだ。
水が流れている様というのはいい。心が洗われる。
河原にはタンポポがたくさん咲いていた。西洋に生えているのだからセイヨウタンポポだろう。
河原に生えている雑草は日本とは異なる。具体的に言うと、この河原には笹、ドクダミ、ヨモギ、セイタカアワダチソウが存在しない。
河原ではこのような積まれた石が見られた。
ほか、平たい石を手首のスナップを効かせて投げ、水面を跳ねさせる子供、ピクニックをする人々、釣り人、泳ぐ人が見られた。
河原でやることは日本と変わらない。
河原をあてもなく歩いているとビアガーデンが目に留まった。
ざっと100席はあるだろうか。パラソルと共にテーブルと椅子が並んでいる。
平日の18時ごろ、客は全部で20人ほどだった。
ホフブロイヴァイス500mlで6ユーロを注文。うちデポジットが2.5ユーロ。
飲み終えてグラスを返却すると2.5ユーロ戻ってくるということだ。このルールは日本のオクトーバーフェストで習った。
晩ごはん。
おっぱいのような炭水化物が添えられた肉料理だ。
圧巻のビール売り場。この5倍はある。
こうして初めてのドイツを過ごした。
5日目: ドイツ - ドレスデン
この日の予定はエルベ川の船に乗った後、ザクセンのスイスと呼ばれる切り立った崖に登り、プラハに戻るというものだ。
エルベ川の船には水上バスに相当する交通手段と、一定の距離を周る遊覧船の2種類がある。
当初の予定ではザクセンのスイス(上流)まで船で行く予定であった。 しかし、この日は水位が足りないため上流へ行く便が出ていないという。 仕方ないので、遊覧船に乗って船気分を補充してから電車でザクセンのスイスまで行くことにした。
遊覧船を待つ中、すずめのような鳥が目に留まった。
私が座っているすぐ目の前に降り立ち、砂浴びをしている。日本のすずめよりも警戒心が薄いようだ。
ドレスデンから出発し、上流へ向かう遊覧船からの風景は時が過ぎるごとに郊外の様相を表す。
遊覧船の乗船時間は90分。ある程度上流へ行ったらドレスデンへ戻る。
乗客数は座席数に対して8割ほどだっただろうか。まぁまぁにぎわっていた。
上流の川岸ではこのような作物を育てている様が見られた。何の作物なのだろうか。
遊覧船の90分を終え、ドレスデン駅からチェコ方面へ電車で移動。Kurort Rathen (クラウト・ラーテン)という駅へ。
ここがザクセンのスイスに登る玄関となる駅だ。見ての通り、田舎の駅。
駅から登山口に辿り着くためにはエルベ川の渡し船に乗る。乗船料は往復で2ユーロだったか？…忘れた。
渡った光景がこの画像だ。まるで御殿場の時の栖のように見えた。御殿場高原ビールもドイツスタイルのビールだからか、リゾート地の見た目まで似せているのだろうか。
ドイツにある時の栖には BASTEI と書かれた看板があった。日本人の私にはバス停に見える。
こんなドイツの田舎に、しかも山にバス停があるのだろうか？という疑問が浮かぶが好奇心のもとに信じて進むことにする。
看板の通りに進むと登山口に辿り着き、その登山口を登ってゆくと再び BASTEI の看板があった。
30分ほど登ると Bastei-Jubelfeier と書かれた岩が見えた。
そして、ここがザクセンのスイスと呼ばれる場所のようだ。着いた。
実は、この岩山に掛かる石橋を前日の車窓から見ていた。これに違いない。ようやく着いたのだ。
ようやくというのは…ここに着くまでにかなり疲れているからだ。登山口から石橋に着くまでにはおよそ40分かかった。
気温は約30度。猛暑の日本からヨーロッパに来たというのに避暑は失敗である。しかも、道中の傾斜はきつい。
道は石や木で整備されており、軽装で登れるとはいえ、きつい。
苦労して登ったザクセンのスイスからエルベ川を見下ろす。美しい。そして恐ろしい光景だ。とても高い。
そして、この日はプラハへ戻る。Kuraut Rathen 駅からプラハ中央駅…ではなく Bad Shandau 駅へ。 Bad Shandau は特急が止まる駅だ。次の特急が来るまで1時間以上あるが、それでも各駅停車でプラハに行くよりは早い。 ここで特急に乗り換えることにした。 特急が止まる駅ならば何かしら楽しめるものはあるだろう…と踏んだのだが、何も無かった。 結局、駅の中にあるカフェで時間をつぶした。時間が過ぎるのが遅い。 カフェではエーデルピルス(ビール)飲んだ。日本でも飲んだことのあるビールだ。 苦味の強いビールのはずなのだが、このときは優しい味に感じた。
そして、プラハ行きの特急に乗った。
プラハに到着するまで心は無であった。
希望は夕食のみ。 ホテルにチェックインして少々休憩した後、ウ・フレクというレストランに入った。
メニューには肉料理が並ぶ。150g, 200g という量の数字が見える中、600g という文字が目に留まった。 pork knuckle と書かれていた。豚足だ。骨まで含んでいるから 600g なのだろう。 「チェコに来て豚足か？」という気持ちと「ただの豚足ではない！チェコの豚足だ！」という気持ちがせめぎ合う。
迷った結果、豚足を注文した。皮はムチムチ、肉はホロホロ。付け合わせの西洋わさび、ペコロス、唐辛子のようなパプリカもいい。
黒いビールは4種類の麦芽を使った店ならではのものだそうな。旅の中でこれが一番おいしかった。
6日目: フィンランド - ヘルシンキ
残りの日はフィンランドで過ごす。プラハ空港からヘルシンキへ。 入国審査が無かった。
ヘルシンキ空港からヘルシンキ中央駅へ電車で向かう。
HSL というモバイルアプリで電車のチケットを買うことができる。
空港に着いてから Google Play でアプリをインストールし、クレジットカード情報を登録すると、すぐ使えるようになった。
このチケットは一定の地域内、一定の時間内に電車に乗る権利を示す。
例えば、ヘルシンキ内の電車に80分間乗るチケットというものがある。この80分間は何回でも乗ることができる。
そして、この国の電車にも改札というものは無いようだ。
駅員にチケットを提示するよう求められたら、このようなアプリの画面を出せばよい。
有効時間内であればカラフルなアニメーションが表示される。期限が過ぎるとその旨と共に新しいチケット買うボタンが表示される。
アプリの他に券売機もある。が、アプリの方が安い。https://www.hsl.fi/en/tickets-and-fares
さて、この旅行で行った3か国ともに改札が無いので、日本の方が珍しいのか？とも思えてきた。 なぜ改札が無いのだろう？と疑問に思ったところ、もしかして犬と自転車が理由ではないかと浮かんできた。 これらの3か国の電車では犬を連れていたり、自転車を持ち込む乗客が日本に比べて多いように見えた。 犬や自転車と一緒に電車に乗るには改札というものは邪魔でしかないのだ。
ヘルシンキ空港には Lentoasema という駅があり、そこからヘルシンキ中央駅 (Helsingin päärautatieasema) へ向かう。 そして、HSL のアプリで選ぶ地域名は Helsinki ではなく Regional だ。 なぜなら、ヘルシンキ空港のある地域はこのアプリの選択肢にある Helsinki ではなく Vantaa だからだ。 そして、Vantaa 地域と Helsinki 地域の両方に乗ることのできるチケットを買う際の地域の選択肢が Regional なのだ。 ということを同行した友人が教えてくれた。事前に調べていたのだろう。 私だったら「ヘルシンキ空港からヘルシンキ駅なんだから地域名も Helsinki だろ！」という風に間違えるだろう。 むしろ初めての人は絶対間違えるんじゃないのか？
ヘルシンキ中央駅から外に出ると太陽が輝いていた。暑い。30度だ。
ちょうどこのとき日本では地域によっては40度もある猛暑だったので、私は北欧に避暑しに来たと思ったのだが、間違いだったようだ。
暑さに加え、連日の飲酒、前日の登山、そしてフライトで体は疲れていた。
なのでこの日は特に観光せず休むことにした。ホテルチェックイン時点で16:00。
部屋に Chromecast 機能のあるテレビがあったので、いつも見ている YouTube チャンネルを見た。
そして夕食。肉が続いたので魚料理を食べることにした。 レストランまでは路面電車で行く。そう、ヘルシンキにも路面電車があった。 路面電車が珍しい日本からすると、プラハ、ドレスデン、ヘルシンキ、3都市3か国全てに路面電車があるというのは新鮮だ。 Google マップで経路を調べることもできる。路面電車のチケットは電車と共通であり、HSLのアプリで買うことができる。いいね。
"パイクパーチのマンネルヘイム元帥風" を注文。パイクパーチというのは白身の淡水魚らしい。
きのこの香りがするしつこくないホワイトソースは揚げた白身にとても合っていた。
マンネルヘイム元帥風とは何なのかはわからない。日本語のメニューにそう書いてあるのだ。
お店のサイトにも日本語のメニューが載っている。
レストランに日本語のメニューがあるのはこの旅で初めてのことだ。日本人の客が多いのだろうか。
量が多かったので、腹ごなしのためにホテルまで歩いて帰ることにした。
途中、それなりの広さの公園があり、芝生に座って本を読んだり、お酒？を飲んだりする様子が見られた。
この写真は 21:00 ごろに撮影したものだ。明るい。明るさだけは旅の間ずっと慣れなかった。
この日の最後の楽しみはサウナだ。 フィンランドと言えばサウナ。サウナはフィンランド発祥、フィンランド語なのだ。 ホテルの上の階に宿泊客用のサウナがあり、性別ごとに部屋が分かれている。 サウナのある階に着き、うろうろしていると、扉からホカホカになったおばさんが出てきた。 私を見るなり「Sauna～？ :)」と話しかけてきた。とても機嫌がよさそうだ。 男性用のサウナの場所を聞くと親切に教えてくれた。サウナは人を優しくするのか。
サウナの扉を開くと誰もいない。私だけだ。 6畳ほどの脱衣所があり、すぐ隣に4畳ほどのシャワー室があり、一番奥に2畳ほどのサウナがある。 はて、サウナのマナーは何なのか…日本の大浴場とは異なり水着で入るのではないか…と思い、シャワーを浴びた後にバスタオルを巻いてサウナに入った。 そのすぐ後、フルチンのおっさんが豪快にシャワーを浴びてサウナに入ってきたので、マナーのことはどうでもよくなった。
7日目: フィンランド - ヘルシンキ
旅の終盤。丸一日観光できるのはこの日が最後だ。 パロラ戦車博物館へ行った後、街のサウナへ行くことにした。
この日も晴れ。暑い。道中は水が必要だ。 フィンランドの物価は日本からすると高く感じる。特に飲み物は高い。500mlの水やジュールは2～2.5ユーロだ。 そして地球の歩き方によるとフィンランドの水道水は飲むことができておいしい。 なので、ホテルで空のペットボトルに水道水を入れて持っていくことにした。 実際、飲んでみるとおいしい部類だった。
まずはヘルシンキ中央駅からハメーンリンナ駅(Hämeenlinna) へ特急列車 Inter City で向かう。
この電車は HSL の管轄ではなく VR の管轄だ。
日本に JR があるように、フィンランドには VR があるのだ。
といっても、V なんとか Railway ではなく、Valtionrautatiet らしい。
ヘルシンキ中央駅から発車して間もなく電車が止まってしまい、フィンランド語のアナウンスが流れた。 英語のアナウンスは流れない。何が起こったのかわからずボーッとしていると、 トラブルがあったので乗り換える必要があることを近くのおばさんが教えてくれた。 サウナは人を優しくするのか。
結局、ハメーンリンナ駅までは1時間半ほどかかった。 そこから戦車博物館まではタクシーで20分ほど。
そういえばフィンランドのタクシーアプリってのもあるんだろうかと思って探したところ、 Valopilkku というものがあることがわかった。 でも利用するには SMS メッセージを受け取る必要があり、海外旅行用のデータ通信 SIM ではできないようだ。がっかり。
それにしても、ヘルシンキに泊まっているのに2時間かかる場所へ観光に行くとは何かおかしいのではないか。 日本で例えるなら、羽田に着いて、品川に泊まって、伊東に日帰りで行こうってところだと思う。 そんな旅行者はいるのだろうか。
戦車博物館には戦車がいっぱいある。30台以上あったのではないか。
博物館とはいっても屋内だけではない。半分以上は屋外にある。戦車は外で乗るものなのだ。
戦車によっては中に入ったり、上に乗ったりすることができる。
中はとても狭い。上に乗ると結構高い。
戦車の横には解説文が書かれている。全長、速度、砲弾、乗員数などのスペック、製造国、使用された年代など。
ハメーンリンナ駅から博物館まで運んでくれたタクシーの運転手は「多くはロシアからの借り物さ」と言っていたが、
確かにソビエト製と書かれたものがほとんどだ。
解説文にはQRコードが書いてある。これをスマホで読むと、その戦車が動いている YouTube の映像を見ることができる。
Keycode というサービスであり、Ebax というフィンランドの会社が運営しているらしい。
こちらは外にある戦車の一つ。教養のない日本人なら「マジ卍」とでも言ってしまうのではないか。私はうっかり心の中で言ってしまった。
戦車の次はサウナ。パロラからヘルシンキまで2時間近くかけて戻る。 Löyly という施設だ。 ロウリュと言えば日本人でも聞き覚えのある方もいるのではないか。 サウナ内にある熱された石に水をかけると、水蒸気がサウナ内にたちこめる。あれのことだ。
Löyly はヘルシンキ南部の海に面した場所にある新しい施設だ。
レストランが併設されており、海辺で食事やお酒を楽しむことができる。
この日は (いつも？) DJ がいて、ゆったり目のハウスが流れていた。
サウナは2時間の予約制。今回は20:00-22:00の枠に入ることにした。 脱衣所で水着に着替える。水着はレンタルすることもできる。このときは6ユーロでレンタルした。 中は幾つかの部屋に分かれている。全ての部屋は性別によらず共通だ。 1つ目の部屋は中央のたき火を囲んでゆっくり座れる場所。無料で水を飲むことができる。 その奥にシャワーのある部屋がある。バケツから冷水をかぶることもできる。
シャワーと冷水の部屋からは2つのサウナにつながっている。1つは明るく、もう1つは暗い。 どちらも最大で15人くらい入れるほどの大きさだ。 どちらの部屋でもサウナストーンに水をかけてロウリュを楽しむことができる。 水をかけると部屋はたちまち熱くなる。これまで日本で体験したどのサウナよりも熱かった。 暗い方のサウナでロウリュをやった後に階段を降りるときは慎重になる必要がある。
水をかける回数について "One or two?" "Three !?" "OKAY!!" といった会話がなされていた。フィンランド語ではなく英語。 外国人観光客も多いであろう施設だから英語なのだろうか。 実際、聞こえてくる言語は様々だった。 エモさあふれるリア充施設というためか比較的若い客が多かった。20～40歳といったところだろうか。
この施設からは海に入ることができる。プールにあるようなステップも設置されている。 冬でも入るらしい。夏の今なら楽勝ッッ！！！！…これにて、フィンランド湾で泳ぐ実績を解除した。 特にきれいな海とは言えないが気持ちいい。仰向けで浮かぶと心が落ち着く。 ステップを降りて海に入った瞬間からもう足がつかないので注意。泳げない人がうっかり入るとあぶないかも。
サウナで熱くなった後に海に入る。サウナで熱くなった後に冷水をかぶる。 水を補給してたき火を眺める。またサウナに入る…。 これはものすごくくせになる。この文を書いている今でも再び行きたい気持ちが高まってくるくらいだ。
サウナをあがり、海を見ながらビールを一杯。22時前は夕日が出ている。 リーチ、一発、フィンランド、サウナ、海水浴、海辺、パラソル、夕日、ビール、ハウスDJのダブル役満だ。 こうして Löyly では2時間ほど過ごした。
まだ夕食はとっていないので、23:00 まで営業している Juuri へ行った。 生のトラウトがものすごくおいしかった。それしか覚えていない。 サウナで優勝したのにまだ優勝できるのかと思った。
帰り道。23時過ぎだっただろうか。エモすぎる。もしデートだったら即落ちだろう。
8日目: 帰国
船で日本に帰ります。
といきたい気分だが帰りは飛行機だ。 離陸時刻は17時台なので少しだけ観光する。 行先はスオメンリンナ要塞。ヘルシンキの港から船ですぐの島だ。 この乗船チケットも HSL のアプリで買うことができる。地下鉄、路面電車、船、全部共通チケットだ。
島に着くとパンフレットが置いてある。日本語のもあった。
要塞というだけあって大砲が置いてある。この岸からも撃ったのだろうか。
要塞とはいっても、島を歩いてみた感想としては兵器も散在しているリゾート地という印象だ。
要塞全体をじっくり観光する時間は無いのでヘルシンキ港に戻ってきた。たくさんの露店があり、にぎわっている。
空港への電車。NULL発、NULL行きだ。
空港で旅行最後の一杯。
こうして初めてのヨーロッパ旅行を終えた。 思い切って行くことにして本当によかった。
NUC6i7KYK
およそ9か月、プライベートではMacbook Airのみを使っていましたが、スペックの良いWindowsマシンが欲しくなり、NUC6i7KYKを買いました。4コアのCPUが乗っていて、メモリとSSDを自分で足すというベアボーン形式のPCです。メモリは32GB、SSDは512GBのものを2つ使ってRaid1にしています。ティッシュ箱よりも小さい筐体ですが、まぁまぁのスペックです。組み立てはとても簡単で、ふたを開けて、メモリとSSDを刺して、ふたを閉めるだけです。*1
最初は NUC7i7BNH にしようかと思っていましたが、意外にもCPUの性能はこちらの方が高そうだと判断して決めました。
以前のデスクトップマシンも小型のベアボーンでした。もうデスクトップPCのためにタワー型のケースを使うことは二度と無いという感覚を持っています。 スマートフォンやRaspberry Pi 3のスペックを考えるとなおさらそう感じます。
Windows 10 はクラシカルなパッケージ版を買いました。USBメモリに入っているものです。 無線LANはWindowsのインストール中につながり、USBサウンドデバイスとして使っているRoland Octa-Capture のドライバもUSB接続したら自動的に入りました。 Raidで少しつまづきましたが(後述)他は楽なものでした。
冷却するためのファンの音は小さいとは言えません。筐体が小さい分、静音ではないのでしょう。
あんまり気にしてませんがベンチマークもとってみました。描画性能は弱いかもと思いましたがDQXは快適に遊べるようです。*2
Raid
Raid を使うには Windows をインストールする前に BIOS の設定をする必要があります。 また、WindowsのRaidドライバーのインストールが必要です。Intel NUCの公式サイトに手順が書いてあります。
ところが、最初はRaid用ドライバーの入手方法がわかりませんでした。上記サイトには2017年7月5日時点で以下のように書いてあります。
Where do you want to install Windows?(参考訳:Windows のインストール場所を選択してください) 画面に以下が表示されたら。 USB フラッシュデバイスの、インテル®ラピッド・ストレージ・テクノロジー・ドライバー: rst_f6floppy_win7_8.1_10_64_14.8.0.1042.zip です。
ドライバーのダウンロード先へのリンクが貼ってあればよいのですが、ありません。
rst_f6floppy_win7_8.1_10_64_14.8.0.1042.zip というファイル名でIntel公式サイトを検索しても、Googleで検索しても出てきません。
Intel のサポートページからドライバーとソフトウェアのページに行き、製品名の入力フォームに NUC6i7KYK を入力すると、この製品のドライバー一覧が出てきます。
そこで “Raid” で検索すると目的のRaidドライバーが見つかります。2017年7月5日時点のパッケージ名は RST_Win7_8.1_10_15.2.0.1020_f6flpy-x64.zip です。
あとは手順通りです。
転職：2017
新卒で入社した車載システムの大企業に10年近く勤め、3つの職種を経験し、退職しました。最初はプログラマーで、次に企画職を少し、最後は複数のソフトウェア開発チームに対して技術支援をする職種でした。退職してから転職活動をし、巨大企業で研究開発をすることになりました。前職のキャリアと転職活動を振り返り、記すことにします。
自分にとってのキャリアの整理のために書くのですが、もしかすると似た境遇の人が参考になるかもしれないですし、公開する文章にした方が本腰を入れて書けるので、ここに書きます。時折見られる華々しい転職エントリとは異なり、凡人のキャリアについての文章です。社名は本旨には関係しないので載せていませんが、いくらか調べれば出てくるでしょう。
駆け出し：2007〜2008
私は大学で情報工学を学んでいました。学業では周囲に比べると劣等生で、あまり研究は好きではありませんでした。その代わりといっては何ですがDTMを何年か続けていて、音楽とコンピューター技術に関する仕事に就きたいと考えていました。といっても、それは漠然としたもので、特にやりたいことが明確になっていたわけではなく、「シンセサイザーやDJ機器を作るのがいいかなぁ」程度の気持ちで楽器メーカーやオーディオメーカーを受けました。確か5社くらい受けて、2社から内定を得て、1社は最終面接で不採用と判定されました。その不採用となった最終面接では、面接官から「あなたの希望する職に就けない可能性もあるが、それでもよいか？」と問われて『絶対にダメです。何のために応募したと思っているんですか。』と答えました。きっとそれが不採用の原因だと思います。
結局、入った会社でも第一希望の部署には配属されず、車載デジタルテレビの開発部門にてソフトウェア開発に5年半従事することになりました。この5年半で組込みソフトウェア開発の基礎を習得し、電機メーカーにおける企画・調達・開発・生産・市場投入・市場調査という流れも理解しました。学生時代には全く知らなかった調達部門・生産部門・品質保証部門の存在・役割も知ることができました。
ソフトウェア開発メンバーとして配属されたのですが、最初のタスクは意外にもテスト用のハードウェアの開発でした。その辺に転がっている水晶発振子と分周ICを使ってパルスを生むものでした。ユニバーサル基板上に実装し、ケースも作りました。これはハードウェア開発を行う会社らしいところですね。
ソフトウェアの開発では大学時代に学んだ知識が役立ちました。例えば、情報工学の知識は、マルチプロセスにおける同期処理の仕組み、デバッガ上に見えるレジスタの意味、論理回路の理解に役立ちました。また、ディジタル無線の知識も、性能測定やフィールドテストの際に役立ちました。
あまり自信がなかったのがプログラミングです。というのも、学生時代に書いたコードといえば、演習課題を除けば一番大きくて1000行程度のJavaアプリケーションしか開発したことがなく、ソフトウェア工学らしい知識も幾つかのUML図と簡単なユニットテストくらいしか知らなかったからです。ところが、プログラマーとして働くことは思ったより難しくなかったというのが開発に携わって間もない当時の感想でした。テクニック、ライブラリ、ツールの知識がさほど無くても仕事をすることはできました。むしろ職歴5年10年の先人が書いたソースコードを見て、「プロって意外と大したことないな」と思っていました。実際に先輩に対して「何年やってるんですか」と大人気なく煽ってしまったこともありました。
仕事にもある程度慣れてきた頃、あまり勉強せずとも周囲の開発者と同様に仕事ができることに疑問を感じました。というのも、学生時代に比べて本を読んで勉強しなくなったからです。「書店には沢山の技術書が並んでいるのに、それらを全く読まずとも仕事ができているのはなぜか？」「さすがに学部レベルの知識で仕事ができるのはおかしいのではないか？」と思いました。また、学生時代に周囲にいた人々の中には、フリーソフトウェアを開発したり、技術書を翻訳したり、国際プログラミングコンテストに出場するなどの能力のある人々がいました。そうした人々と自分たちを比べると「プロが大した事ないのではなく、周囲の多くのプロはプロレベルに達していないまま仕事をしているのではないか？自分もプロレベルに達していないのに気づかなかったのではないか？」という疑問がわいてきました。今振り返ると周囲の実力も自分の実力も適切に評価できていなかったと思いますが、当時はそう疑問に思ったのです。
駆け出しの頃を振り返ってみると、機能追加やバグ修正などの個々のタスクをこなすことはできていましたが、より良い設計をしたり、より快適な開発環境を整えたりすることはできていませんでしたし、ユーザーの利便性を考える機会も乏しいものでした。また、担当している範囲でしかシステムを理解していませんでした。特に2年目はほとんど成長できていなかった気がして、「このまま過ごしてゆくと技術が身につかず、仕事を選べなくなったり、楽しめなくなってゆくのではないか？」と危機感を覚えました。
プロを目指して学習：2009
それから、以下の目標を立てて学習することにしました。
- (1) 開発対象のソフトウェアがどのような仕組みで動いているのかを自身の担当範囲にとどまらず全体的に理解し、時間さえあれば一人で全てを開発できるだけの技術を身につける。
- (2) 組込みシステム開発、ソフトウェア開発に関する基礎的な公知技術を身につける。
- (3) 身につけた技術は仕事で実践する。
といっても、あまり気合を入れて学習したわけではありません。学習のほとんどは業務時間中に担当業務の延長線上の活動として行いました。読んだのは、規格書、他の開発者が担当する部位のソースコードや設計書、ハードウェアの設計書、開発ツールのマニュアルです。読む中で知らないことが出てくると逐一検索して調べました。ほか、プライベートの時間でやる気があるときだけ技術書を読むようになりました。平均すると2ヶ月に1冊程度のペースだったと思います。1冊あたり2ヶ月かけて読んだのではなく、2ヶ月に1回程度読む気が出たということです。
また、この頃には既にIT勉強会文化があり、IT勉強会カレンダーのおかげで存在も知っていたのですが、独学で困らなかった、自分に合った勉強会を探すのは面倒だったという理由で行きませんでした。
実践：2010〜2012
システム全体の理解が進んだので、要求同士の整合性を考慮したり、不要になるコードを見つけて削除するなど、全体最適を目指した変更ができるようになりました。他の開発者の仕事を助けたり、全体的な指示をすることもできるようになりました。全てのソースコードの詳細を理解していたわけではありませんが、各コンポーネントの重要なAPIや変数は大体覚えており、全てのソースコードと要求仕様の対応は多少の時間があれば調べることはできる程度には理解していました。
また、ハイブリッドアジャイルに近いイテレーティブな開発プロセスを組み立てて、アーキテクトのような立場で開発をリードする経験を積むこともできました。誰もアジャイルという言葉を使っておらず、私もアジャイルを目標としていたわけではありませんでしたが、今振り返ると中身はまぁまぁそれらしかったと思います。
ほか、幾つかのツールの導入や浸透に関わり、積極的に使う経験ができました。私が新規導入を提案したものも、他者が提案して私が浸透に関わったものもあります。
公知の知識を仕入れて実務で応用する機会には、社内では比較的恵まれたのではないかと思います。ソフトウェアの規模があまりに巨大であれば (1)+(3) の目標は達成できなかったでしょうし、ツールや手法を実践する機会が無ければ (2)+(3) の目標も達成できなかったでしょう*1。技術によっては実践する機会に恵まれない場合もあり、最初は反対されましたが数ヶ月の実験と説得の末に実践できたこともありました。
大企業において複数の開発チームへ並列的に関わることができた最後の職種になって思うのですが、所属組織によって成長できる経験を積みやすいか否かが大きく異なるのではないかと思います。あのチームならもっと成長できたかもしれない、あのチームだったら成長できずに腐っていったかもしれない、といったように。得られた知識を仕事で活かせるかどうかは、自分たちの状況に当てはめて利点や必然性を見出す応用能力と、具体的な実施方法・コスト・評価方法などもまとめて計画を立てて提案する能力が必要なのですが、それが受け入れられるかどうかの因子は自分がコントロールできることばかりではなく、運もそれなりに関係するというのが実感です。
「勉強しても実践するのが難しい」「教科書と現場は違う」という意見を言う方々に時々出会いますが、私はそれらの意見とは真逆の経験をすることができました。エンジニアリングを勉強して得られた知識は、応用能力・提案能力・運があれば、会社組織のビジネスで実践することができると考えています。
思い返すと、ハードウェアを扱う領域ならではの面白さがありました。スマートフォンやPCなどの汎用的ではないデバイスで動くものを作るというだけでも心が踊りますし、おかしな映像が出てしまったり電源に異常が出てしまったりしたときもなぜか笑えましたし、故障品を調べていてアドレスバスのパターンが切れていたことに気づいたときは「そういうのもあるのか*2」と思いましたし、フィールドテストにて後部座席でデバッガを見つめながらおかしな挙動を見つけてその場でコードを書いて「さっきのところもう一回曲がってください」と指示して「またかよｗｗ」という会話をしたのも楽しい思い出でした。
次の道を模索：2012
開発職を5年続ける中で技術は向上したものの、プロダクトにも環境にも飽きてきました。そうした日々の中で、仕事の4分類：成長・支援・維持・再生 という文章を思い出しました。そして、「今の仕事は維持の仕事だ。成長の仕事をしよう。」と考えました。それまでの仕事はどう作るのかを考える仕事だったのですが、何を作るのかを考える仕事、更にはその自分で考えた企画に対してプロトタイプを作る仕事をやってみたいと考えました。今思うと、自分が主役になる実感を得られる成果を出したかったのだと思います。
そして、企画部門に異動しました。ここでの仕事は商品戦略に関わるため機密事項が多く、書けることはほとんど無いのですが、私は主に先端応用技術の動向を調査していました。内容によっては機能立案をしたり、商品戦略に反映させる仕事をしていました。英文を読む機会が多かったので良い訓練になりました。しかし、この部門にて自分の望むやり方で仕事をするには、複数の部署をまたいだ大幅な体制変更をする必要があり、それは自分にとっては到底マネージできない問題であり、そこに時間を費やすのはもったいないと判断して、1年足らずで企画部門を去ることにしました。事前の内情調査不足だったと反省しています。
転職か、異動か：2013
このとき転職を考えました。転職するかどうかは決めていませんでしたが、自分の市場価値を測るために何社か受けてみて、良い条件であれば転職しようと考えました。結果、数社の他業界の会社を受けて、1社から内定を得られました。同時に、社内で異動する話も進めており、迷っていました。業務内容、残せそうな成果、得られるスキル、給与、勤務時間、居住地、ビジネスモデル、財務状況などの条件を比較して考えると、転職するメリットはそれほどないと判断して、異動することにしました。この選択が妥当だったのかは今でもわかりません。どちらの選択肢にも、満足/不満足どちらの可能性も相応にあったと思います。
Software Engineering Consultant：2013〜2016
異動先、つまり前職の最後の所属部署は、複数のソフトウェア開発部署の技術を向上させる責任を持っています。この分野のスキルに関してはプログラマー時代にある程度身につけており、組織的な技術向上の実績もあったため、即戦力人材としてリーダーシップをとって遂行してゆくことになりました。特定の製品・特定の開発チームに所属せず、複数の製品・複数の開発チームに対して技術支援・問題解決をしてゆくのは新鮮でした。この職種は Software Engineering Consultant と呼ぶのが適切でしょう。*3
大きく分けて、1.コード解析ツールの全社的普及、2.テスト分析・設計手法の確立と普及、3.開発環境刷新、4.教育 という4つのことを行ってきました。多くは自分で立ち上げた仕事です(他にお蔵入りになったプロジェクトもありましたが)。この部署には3年在籍し、そして退職しました。実績を振り返ると「3年でこれだけか」とも思いますし、「まぁまぁできたかな」とも思います。自分にもっと能力があればできたことは他にもあっただろうなとも思いますし、能力があったとしても結果は変わらなかったかもしれないとも思います。
Software Engineering という技術に向き合う仕事柄、より多くの公知の知見を仕入れる必要が出てきました。以前よりも本を読むようになったり、学会やシンポジウムなどでの発表資料や論文を読んだり、JSTQB Foundation Level というソフトウェアテストの基礎的な資格を取ってみたりしました。
他社の方々と交流する機会を増やし、自身のレベル、自社のレベルを測るようにもなりました。いくらか発表する機会もありました。
そこそこ合っていた仕事かなと思います。
退職
退職した理由はいくつかあります。
- 人生は一度なので、他の世界も身をもって知りたい。(長く居すぎたと思った)
- もっと興味のあるプロダクト、未来を担うプロダクトを作りたい (そういうプロダクトばかりではなかった)
- 開発する機会を増やしたい (技術と知識の幅は広がったが、根幹となる作る力が落ちてしまった。)
- 自分の伸ばしたい能力に関して、自分よりも秀でた人が沢山いる環境に身を置きたい。(そういう人は少なかった。それぞれ長所はあるが方向性が違う。)
- 収入をのばしたい。(成果に見合った額はもっと高いと思った)
- もっと海の近くに住んで気軽に釣りに行けるようにしたい。(そうするには微妙な地域だった)
全てを満たせる選択肢があるかはわかりませんが、前職では多くを満たせないと判断しました。
入社当時は10年近くも働くとは思っていませんでした。1つの部署だけでなく、自分で希望して3つの部署・職種を経験できたのは他の社員と比べて恵まれたと思います。社内という内輪の中とはいえ、自分の能力を売り込んで異動して、経験・実績を積むことができました。特に、IT・ソフトウェアという好きな分野を基軸にして楽しめる仕事ができたのは喜ばしいことでした。
転職
在職中に次の職を決めるのがセオリーらしいのですが、ものぐさな私はなかなか本腰を入れて活動できず、転職せざるを得ない状況にするために、先に退職することにしました。
希望条件は退職理由から導いた条件が中心ですが、転職活動をする中で明らかになっていった条件もあります。大まかには以下に分けられます。
| 条件種別 | 例 |
|---|---|
| プロダクト | 自分が使いたいと思えるプロダクトか？未来を担うプロダクトか？ |
| 実績 | 成したいことができるか？公開できるか？ |
| スキル | 身につけたいスキルを習得できそうか？既に身についているスキルを活かせるか？ |
| 労働環境 | 労働時間が許容範囲か？便利なグループウェアがあるか？服装などの非合理な規定が無いか？自分が改善してゆけるのか？ |
| 勤務地 | 周辺の家賃相場は？家族や既存の友人に会いに行ける距離か？ |
| 収入 | 希望額以上か？上記条件の充足具合によって変動。 |
これらの条件種別ごとに詳細な条件を設け、希望・前職・応募先企業を比べる表を作りました。また、前職の方が良かった条件というのは気づきにくく、応募先企業について調べる中でわかってきました。私は複数の条件のバランスを考えたので結構迷ってしまいました。「金だよ金！」みたいに1つの条件だけで選べるなら楽だなぁと。結果、前職よりも複数の条件について改善するポジションのオファーを得られました。
企業・ポジションを探すにあたり、いくつかのサービスと転職エージェントに頼りました。以下、それぞれについて感想を書きます。他の方には当てはまらないところもあるでしょう。
- Wantedly
- 国内新興企業が多く、自分が知らない企業を知るのに役立ちました。
- メッセージもそれらの企業から来ます。プロフィールを読んでいると思われるものばかりでした。
- 転職エージェントからのメッセージが一切無かったのは好印象でした。
- メッセージの数は LinkedIn に比べるとかなり少なく10分の1程度ではないかと思います。
- LinkedIn と同じ使い方をすることもできますが、話を聞きに行きたいボタン、社員個人に焦点を当てた文章があるなど、別の価値があると思いました。
- リアルウォンテッドリーにも1回行ってみました。参加企業の方から「サーバーですか〜？フロントですか〜？」と開口一番に話しかけられ、ウェブしか見てない視野の狭い人達がいるものだと落胆したのを覚えています。 イベント自体は良い機会を得られるものだと思います。
- ビズリーチ
- メッセージの8割は転職エージェントからです。
- LinkedIn とは対象的に全て国内企業の紹介でした。
- 大手が多いですが、中にはスタートアップもありました。
- LinkedIn が日本に普及できていない部分を埋めるようなサービスで、存在価値を感じませんでした。ビズリーチを利用している企業は全部 LinkedIn に乗り換えて欲しいと思いました。
- 転職エージェント
- エージェントとの最初の接点はLinkedIn かビズリーチである場合と、私のメールアドレスに直接連絡してきた場合がありました。
- 転職あっせん会社/エージェント個人によって扱っている業界が異なることがわかりました。
- 業界/企業によっては転職エージェントに頼らないと知り得ない非公開求人があることがわかりました。
- どのような企業/ポジションを探しているのか、詳細に伝えた方が良いです。「詳細な条件を書くと該当する求人が無かったりわがままと思われるのではないか？」などと尻込みをする必要はありません。でないと全く興味のわかない企業/ポジションを紹介される可能性が増えます。
- レジュメの書式についてアドバイスを頂くことはありましたが、スキルと求人要項を照らし合わせて合いそうか否かについてコメントして頂けることはありませんでした。
- 転職エージェントはあくまで転職のあっせんをする役割で、キャリアアドバイザーではないと思いました。
選考方法はそれぞれです。レジュメについて深掘りする質問をされたり、技術の筆記試験があったり、ソースコードを書いたり、プレゼンテーションをしたり、その事業の・部署の現実の問題について「あなたならどうする？」と相談されるなど。印象に残っている質問は「○○(技術名)についてあなたが複数回経験した技術的な問題と、その対策を教えてください。」というものです。「その技術の実務経験があるならそれ特有の問題を経験しているでしょ？その問題に複数回ぶちあたっているならば対策も考えますよね？」という意図なのでしょう。ほか、基礎知識を問う質問に答えられずに落ち込むこともありましたが、復習の良い機会ととらえることにしました。
転職活動をして強く感じたことは2つあります。
1つは、業界や企業によって求人情報や社員個人が発信する情報への辿り着きやすさが異なることです。ここ10年で誕生した/台頭した企業や一般向けウェブサービスを手がける企業では、公式採用ページに Job Description が書かれていて、Wantedly にも載っていて、技術ブログが運営されており、SlideShare などで発表資料が公開されている傾向があります。また、社員のブログやTwitterアカウントも探しやすかったです。対して、それ以外の国内の大手企業、特にtoB事業が中心の企業になると、転職エージェントに頼らないと求人情報に辿り着けず、Job Description が曖昧という場合が多かったです。大手やtoB事業中心の企業でも外資になると、LinkedIn がある分いくらかオープンであり、Job Description もはっきりしていますが、それでも転職エージェントに頼らないと知り得ない情報があると思いました。*4
もう1つは、自分の居る業界/企業でスキルを高めても他の業界/企業では通用するとは限らないことです。と言うと当たり前なのですが、私は本業で即必要となるスキルと、少し先で必要となりそうなスキルしか得ておらず、それを何度も感じることになりました。また、業界を問わなさそうな共通スキルについても、面接の場で直接言われたわけではないのですが「我々は、あなたが解決してきた課題を既にクリアできている。それ以上の進歩を生み出してゆけるか？」と問われたと感じることが何回かありました。これについては、これからのキャリアでなんとかする必要性を感じました。*5
これから
これまでの組込みシステム中心のキャリアから一転し、主にサーバーサイドを相手をすることになる予定です。 ちょうど別の開発経験を積みたいと考えていたところであり、プロダクトも挑戦的なものです。 また、学会・シンポジウムでの発表やOSSなどで、公開できる成果を出していきたいですね。 最初のうちは要素技術と向き合うことに多くの時間を費やすことになりそうですが、ユーザーとプロダクトのことも意識的に考えてゆきたいと思います。
前職よりも複数の条件について改善するポジションのオファーを得られたと先述しましたが、それはつまり改善されないことも中にはありそうだということです。また、新たな希望や悩みを抱くかもしれません。なので、長くやってゆけるかはわかりませんが、まともな成果を出すまでは続けようと思います。
不安はあります。でも、まずは変化を楽しんでゆくつもりです。
