チェコ、ドイツ、フィンランド旅行記

チェコ(プラハ, ピルゼン)、ドイツ(ドレスデン)、フィンランド(ヘルシンキ) の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の性能はこちらの方が高そうだと判断して決めました。

f:id:masskaneko:20170709221829j:plain

以前のデスクトップマシンも小型のベアボーンでした。もうデスクトップPCのためにタワー型のケースを使うことは二度と無いという感覚を持っています。 スマートフォンRaspberry Pi 3のスペックを考えるとなおさらそう感じます。

Windows 10 はクラシカルなパッケージ版を買いました。USBメモリに入っているものです。 無線LANWindowsのインストール中につながり、USBサウンドデバイスとして使っているRoland Octa-Capture のドライバもUSB接続したら自動的に入りました。 Raidで少しつまづきましたが(後述)他は楽なものでした。

冷却するためのファンの音は小さいとは言えません。筐体が小さい分、静音ではないのでしょう。

あんまり気にしてませんがベンチマークもとってみました。描画性能は弱いかもと思いましたがDQXは快適に遊べるようです。*2

f:id:masskaneko:20170706235550p:plain

f:id:masskaneko:20170706235542p:plain

Raid

Raid を使うには Windows をインストールする前に BIOS の設定をする必要があります。 また、WindowsRaidドライバーのインストールが必要です。Intel NUCの公式サイトに手順が書いてあります。

www.intel.co.jp

ところが、最初は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 です。

downloadcenter.intel.com

あとは手順通りです。

*1:Corei7-6770HQ, Intel SSD 600p Series SSDPEKKW512G7X1 512GBx2(Raid1), Crucial CT2K16G4SFD8213 16GBx2

*2:1920x1080, 標準画質で測定

転職: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」と思いましたし、フィールドテストにて後部座席でデバッガを見つめながらおかしな挙動を見つけてその場でコードを書いて「さっきのところもう一回曲がってください」と指示して「またかよww」という会話をしたのも楽しい思い出でした。

次の道を模索: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つの条件だけで選べるなら楽だなぁと。結果、前職よりも複数の条件について改善するポジションのオファーを得られました。

企業・ポジションを探すにあたり、いくつかのサービスと転職エージェントに頼りました。以下、それぞれについて感想を書きます。他の方には当てはまらないところもあるでしょう。

  • LinkedIn
    • 外資企業を探すのに役立ちました。Job Description が明確に示されている場合がほとんどで、選びやすかったです。
    • メッセージの9割は転職エージェントから。全て大手外資系企業における前職同業のポジションの紹介で、異業種へのお誘いは皆無でした。
    • 国内大手企業も中にはありますが、自分が探している業種・職種についてはほとんどが外資でした。
  • 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などで、公開できる成果を出していきたいですね。 最初のうちは要素技術と向き合うことに多くの時間を費やすことになりそうですが、ユーザーとプロダクトのことも意識的に考えてゆきたいと思います。

前職よりも複数の条件について改善するポジションのオファーを得られたと先述しましたが、それはつまり改善されないことも中にはありそうだということです。また、新たな希望や悩みを抱くかもしれません。なので、長くやってゆけるかはわかりませんが、まともな成果を出すまでは続けようと思います。

不安はあります。でも、まずは変化を楽しんでゆくつもりです。

*1:目標(1)(2)についてはもっと突き詰める余地はありましたが(3)はできたので良しとしています。自分に甘いスタイル。

*2:漫画"孤独のグルメ"の名台詞。

*3:SEPG: Software Engineering Process Group という呼称もありますが、Group というのは職種ではないというのと、日本においてはSE, PGが職種を指すのでわかりにくい呼称だと思います。

*4:Qiitaも同じように書き手や技術分野に業界の偏りを感じる。というのは別の話。

*5:「IT業界」なんて、ないんだよ。 を思い出しました

モダンなチーム開発環境を追求しよう : SQiPシンポジウム2016 SIG8

SQiPシンポジウム2016に参加し、SIG(special interest group)と呼ばれる特定のテーマについて議論やワークショップなどを開く場の一つを主催しました。テーマは ダンなチーム開発環境を追求しよう というものです。 www.juse.jp

開催の動機

チーム開発 とはソフトウェア開発における技術分野の呼び名であり、"チーム開発実践入門(技術評論社, 2014)"*1 の発刊を機に日本で普及している技術分野名だと思います。バージョン管理・課題管理・継続的インテグレーションなどの技術分野をひとまとめにしているのが特徴で、組織的におけるソフトウェア開発のワークスタイルを大きく決定づける技術分野だと考えています。国際的に "チーム開発" と同義の用語が存在するか確認が取れていませんが、ソフトウェアライフサイクルプロセスの規格である ISO/IEC 12207 におけるサポートプロセスと多くの技術領域が重なります。

ここ5年くらいの国内のチーム開発分野におけるトレンドを振り返ると、チケット駆動開発, Pull Request, 継続的インテグレーション, ChatOps が思い浮かびます。例えば2012〜2013年には国内大手/有名サービス企業においてGitHub Enterprise の導入事例が報告され*2SlideShare にてツールの名前で検索すると、カンファレンスや勉強会における企業からの発表資料が多くヒットします。

一方、SQiPシンポジウムはソフトウェア品質を扱うシンポジウムであり、企業での事例が毎年20件以上報告されるのですが、チーム開発技術にフォーカスをあてた発表は何年か振り返っても多くは見当たりません。本文執筆時点で公式ウェブサイトでは2009年からの発表資料・論文が公開されていますが、それらのうち私から見てチーム開発技術にフォーカスをあてている、またはチーム開発のツールが発表内容に大きく関係していると判断できるものは5件でした。

私は経験上、チーム開発技術は品質向上に大きく寄与し、数あるソフトウェア工学技術の中でも優先的に取り組むべきものと考えておりますので*3、なぜSQiPシンポジウムではチーム開発の発表が少ないのだろうと疑問を持ちました。理由として "もう当たり前で語ることが少ない" ということも考えられますが、「いや、絶対そのようなことは無いし需要はあるはずだ。」と信じてSIGを主催することにしました。

SIGの内容

SIG開催の動機はSQiPシンポジウムでの発表数が少ないことでした。それを確かめるため、数名ごとのグループディスカッションで参加者の抱える問題・関心と、サーベイによって参加者の所属組織の状況を明らかにすることにしました。また、それらを行うにあたり、技術の概要や用語の認識を共通化すべく、簡単な講義をしました。

SIGの時間は100分です。ほとんど余裕はなく、議論が問題の解決方法にまで踏み込む時間はありません。それでも参加者にとって価値があるだろうか?と考えたところ、新しい知識や複数の会社組織のことを断片的にでも知る機会には価値があるだろうと考えました。また、サーベイやグループディスカッションの結果をSlideShareやこのブログで公開したり、次回のSQiPシンポジウムでの発表を奨めれば貢献の幅も少しは広がるだろうと考えました。

講義

最初の講義ではチーム開発とは何か、何のために行うのか、どのような問題がよくあるのか、モダンとは何を指すのかについて説明しました。

まず、何のために行うのかの理解を得ることが重要なのですが、私は 快適さと正確さを両立したワークスタイルを実現するため だと考えています。その結果、ソフトウェア品質に寄与するという考えです。定型的な連絡や作業はできるだけコンピューターに任せることで開発者も管理者も快適さを得られます。作業内容や作業間の整合性を記録するのにもツールを使えば正確に行うことができます。その結果、知的作業に割り当てられる時間が増え、保守するための情報が得られ、価値あるソフトウェアを迅速かつ継続的に行えるようになると考えています。

欠かせないツールについても説明しました。個々のツールを揃えるだけでは不足で、連携させることが重要ということを説明したつもりですが、もう少し強調すれば良かったなと思います。ツールがどういう変遷を辿り、2016年におけるモダンとは何か、なぜモダンに焦点を当てるのか、それらの情報はどこから入手するのかについても説明しました。単に新しいツールを使おうと言っているのではなく、どういう解決の選択肢があって、それらがどのように・どのくらいのスピードで進化しているのかを把握し、選択することが重要というのが"モダンな"というところの主旨です。

チーム開発環境が無いとどのような問題があるのか、モダンなツールがあったとしてもどのような問題があるのかについても説明しました。ソースコードの上書き・Issueの未クローズ・Pull Requestのレビューがザルなどのお馴染みの問題に加え、ウェブアプリケーションとインフラの運用問題についても触れました。ここは知る限りあまり触れられていなかったところだと思います。

こうして次のサーベイとグループディスカッションのための知識を整理しました。

サーベイ

参加者の職場の状況を調べるサーベイは7問3択の形式です。設問と回答は上記スライドの後半にあります。以下、設問ごとに問う意図と回答に対する感想を書きます。

Q1はバージョン管理システム(VCS)に関する設問です。集中型が2/3と多数派、分散型が1/3という結果になりました。何ヶ月か前に参加したアトラシアン主催のイベント*4では100名以上の参加者数に対して「GitHubを使っている方?」「Bitbucketを使っている方?」という挙手を問う質問に対し、パッと見で6割以上の方がどちらかに手を挙げました。そことはだいぶ違うなというのが率直な感想です。

Q2は課題管理システム(ITS)に関する設問です。16名中7名の方が「ITSを使用しているがVCSとは連携させていない」と回答しました。ここをクリアするだけでもかなり改善の余地がありそうです。

Q3はGitHubなどのリポジトリホスティングツールに関する設問です。評価も含めて使用していると回答したのは16名中5名でした。Q1で分散型VCSを使用していると回答したのは5名なので同じ5名なのでしょう。つまりリポジトリホスティングツールを使わずに分散型VCSを使用している方はこの中にはいないということが推測できます。一方、「よく知らない」と回答した方も5名いて、VCS/VCS hostingについては各人(各社)の開きを感じます。

Q4は運用環境(自社オンプレのみ or クラウドも含めて検討)に関する設問です。自社オンプレのみという方が圧倒的多数でした。総務省の調査によると日本ではクラウドサービスを利用する企業は少数派のようですが*5、ここにもそれが表れたのかと思います。特にクラウドを推奨する意図がある設門ではありませんので、選択肢cは「クラウドを含めて選択」としています。それでも自社オンプレに偏っているところを見ると、クラウドを利用した方が良いケースでも利用できていないのではないことが懸念されます。

Q5はユーザーアカウント管理について、個別管理かLDAPなどを使用しているかを問う設問です。地味ながら効いてくるところと考えて設問に加えました。結果は半々です。できないのか、知らないのか、やらないのかは、後のグループディスカッションでも明らかにはなっていませんが、「システムは色々立ち上がっているが管理が全部個別で面倒なことになっている」という意見がありました。

Q6は運用人員に関する設問です。小さなチームであれば開発者が開発業務と兼任するすることも考えられますが、人員数が増えて開発環境のシステム数も増えると開発の片手間ではできなくなってきます。保守だけでなく教育のコストも増えていきますし、そこがかさむと拡張・新規導入に支障が出てきます。16名中4名が「専任の人員を割り当てている」と回答しました。

Q7は開発環境のトレンドを把握する情報源に関する設問です。知ることは改善のきっかけなので、最も重要な設問だと考えています。半数の方が書籍やウェブから能動的に情報収集していることがわかりました。特にチーム開発ツールについてはOSSも多いですし、商用ツールでもGitHub EnterpriseやJIRAの情報も結構ありますし*6、少しずつ進化してゆくものなので能動的に追ってゆくのが良いと思います。

グループディスカッション

講義とサーベイを踏まえ、参加者それぞれの組織で抱えている問題をポストイットに書いて分類することを、4人x4グループで行いました。 問題の解決策を議論する時間はありませんでしたが、参加者それぞれの組織ではどうしているかなどをざっくばらんに話しました。

以下にポストイットに書かれた問題を列挙し、私が聞いた議論の内容と合わせた所感を書きます。文面はできるだけポストイットに書かれたものをそのまま書き起こしています。チーム開発の技術分野ごとに分類しています。

課題管理(ITS)に関する問題

  • BTSが内製で他のサービスと連携できない
  • バグトラッキングGoogle spread sheet
  • Redmine, Mantis... と複数のBTSがあり、情報が分散している。
  • BTSのカスタマイズが非常に難しい
  • Redmine スキル. 使いこなせてない
  • ようやくJIRA導入。→どう運用しよう?
  • ITSでレビューが止まってボトルネックになることが時々ある
  • BTSで不具合がクローズされないままになってしまう

サーベイQ2の結果と同じく、導入をしているがうまく使えない、VCSと連携できない、導入していない、という状況に分かれているようでした。 カスタマイズやワークフローの話が多く出ましたが、ここはそれぞれ問題が異なりそうなので、1つ1つ掘り下げることができそうです。 "BTSが内製で他のサービスと連携できない" 問題については他所でも聞いたことがあります。よくあるのかもしれません。

バージョン管理, リポジトリホスティング, コードレビューに関する問題

  • コードレビューする文化がない
  • プロジェクトマネージャーがC++コードを読めない
  • VCSを使ったことがない開発者がいる
  • バージョン管理システムが複数ある(VSS, Integrity, SVN)
  • SVNからGitへの移行が進まない。
  • リポジトリホスティングツール(GitBucket)の利用が進まない
  • 社内に集中型VCS, 分散型VCSが混在していて統一できていない
  • GitLabを導入したがまだ活用できていない
  • レビューの基準が?
  • ドキュメント管理がリリースバージョンと連携していない
  • SVNのブランチ構造がプロジェクト毎にバラバラ
  • SVN, merge 戦略
  • 集中型VCSのためグローバル開発でsyncに時間がかかる
  • SVNで設計書が管理できてない(一部電子化されていない)

この分類では最も多く挙げられました。SVN, Gitが主流のようですが、VSS, Integrity という名前も挙がりました。Pull Request を使ったワークフローを回している方はかなりの少数派に見受けられました。ソースコードだけでなく、文書のバージョン管理も話題になりました。

CIに関する問題

  • JUnit が定着しない
  • テストを自動化していないのでCIツールをのせるメリットがない

CI そのものについては問題が挙がらず、CIのジョブである自動テストに関する2件のみとなりました。 CI以前に問題があると考えている方が多かったのかもしれません。

Chat, コミュニケーションに関する問題

  • 開発さんとどのように情報を共有するとやりやすいのか知りたい
  • 営業部門の書くWikiが汚すぎる
  • ChatOps できていない

開発以外のチームとのコミュニケーションに関する問題が出ました。 何を共有すれば良いのかはツールでは解決できませんが、素早く正確に伝える、いつでも聞けることについてはツールが役立つと思います。 Wikiについては、所定の形式でテキストを書いて別途レンダリングするという点がWordなどと異なりますので、トレーニングが必要なのだと思います。

テスト管理に関する問題

  • テストケース一覧がExcelで、バージョンごとにExcelファイルのコピーが増殖していく。
  • テストケースの実行結果がExcel管理なので集計が面倒。

私は事前に全く想定していませんでしたがテスト管理に関する問題が挙げられました。TestLink や Quality Center の領域なのでしょうか。 経験がないのでわかりませんが、ウェブアプリで他ツールとの連携もできるようなのでテスト管理もチーム開発の一部とするのが良いかと感じます。

インフラに関する問題

  • 運用が大変で導入できない。(インフラ的に)
  • シェフとか?環境構築
  • アカウント管理がバラバラ
  • 運用がボランティアベース
  • クラウドのセキュリティ
  • オンプレの運用
  • 国内に全サーバーがあるので海外からのアクセスが遅い
  • 開発環境の管理をソフト開発者が兼任しているので時間が見積もれない

インフラの問題は多く挙げられました。 無償のOSSツールを使えば構築は簡単なのですが、継続的に運用してゆくには課題があるようです。 SQiPシンポジウムでは製造業(組込み)の方々が比較的多いので、ウェブアプリケーションのためのインフラについては あまり強くないという背景がありそうな気がします。(本SIG参加者の所属企業・業界は把握しておりません)

ツールや技術分野によらない問題

  • 品質保証としてソースコード管理などに踏み込めていない
  • どのような状況で開発が行なわれているのか知りたい
  • 社内とプロジェクト(顧客先)で同じツールが使えない
  • 直近の開発業務を優先するため、改善の工数をなかなか確保できない。
  • ブログなど外部情報のアクセスが制限されている。
  • 運用ルールが決められず導入以前。(チーム内/プロジェクト内で)
  • 使用するツールの選定方法
  • 新しいツールに移行するとしてどうやって
  • 新しいものを導入しようとしても権限がないのでインストールできない
  • ツールがカオス:GitHub vs GitLab vs SVN, Redmine vs JIRA (ボトムアップでいろいろ")
  • エクセルから離れられない
  • 新メンバーの学習時間
  • 運用ルールの定義
  • メトリクスは可視化されているが技術的負債が増えていく

その他、チーム開発に限らず、新規技術の導入方法、情報収集、改善の問題が挙げられました。

特に「どうやって浸透させて行くのか」については関心が高いようで、個別に質問を受けました。 ボトムアップであれば、まず環境を立ち上げて動かす→新しもの好きの数人に利便性を実感してもらう→チームとしてトライアルすることに合意し、ルールであれば使う層(多い)に拡大する→最後に、合わない・移行したくない層を何とかする…というのがパターンかなと思います。 トップダウンでチームの公式ルールとする場合は浸透は早いのですが、利便性を体感できるような運用ルールを早く備えないと反発を招いて一気に下火になったり、使用しても効果が上がらない恐れもあると思います。

総括

SQiPシンポジウムの参加者層においても、チーム開発技術の需要・改善の余地はかなりあるという実感を得られました。参加者の方々にとっては、解決策を得る場ではなかったものの、ヒントが得られたり、関心が高まったのではないかと思います。

私はこの分野のエキスパートというわけではなく、参加者層の所属組織での関心・採用している技術にもバラつきがあることを想定しましたので、どこに照準を合わせて本SIGのプログラムや講義内容を組むかを迷いました。結果的にはこれで良かったかと思います。また、サブタイトルにある "快適さと正確さを両立したワークスタイルの実現に向けて" というメッセージはもう少し伝えられる余地があったかと感じます。

私のSQiPシンポジウム参加回数はこれで3回です。2014年は一般聴講、2015年に論文発表、そして2016年はSIG主催となりました。SIG主催は論文発表とは違って100分を自由に使って価値を提供することを考えることになり、良い経験ができました。来年は何をするか、何もしないかは未定です。

最後に次回シンポジウムでの発表をお勧めしておきました。これで発表者が出れば本SIGは大成功です。

参加者の皆さん、シンポジウム事務局の方々、ちょっと強引な誘いにも関わらず引き受けてくれたサブリーダーの三浦さん、ありがとうございました。

*1:http://gihyo.jp/book/2014/978-4-7741-6428-1

*2:http://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=002372

*3:何に取り組むのかはもちろん組織やプロダクトのコンテキストやエンジニアの興味によるが、私ならSQiPシンポジウムで投稿数の多いテーマである "テスト", "メトリクス", "欠陥分析" よりもチーム開発を優先する。といっても私は2015年にテスト分析手法の論文を書いているので説得力がない。

*4:http://atlassian.connpass.com/event/31664/

*5:http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h26/html/nc254110.html

*6:対して、IntegrityやCoverityやEnterprise Architectなどのいかにもな商用ツールの情報は、カンファレンスやベンダー/代理店からでないと手に入らない。

私がコンピューターで文書を書く方法の変遷

最近になってMarkdown形式で文書を書くことが増えたのですが、改めて考えるとコンピューターを使って文書を書く方法は多様であって、それらの方法をどれだけ経験しているかも人によって様々ではないかなと考えることがあります。

例えば、PC上のMicrosoft Officeなどのアプリケーションで書くのか、Google Docsなどのウェブアプリケーションで書くのか、見たまま編集なのか、何らかの書式に従ったテキストを別途レンダリングするのか、といった方法の違いがありますが、どういった方法に慣れ親しんでいるのかは人によって異なるのではないかと思います。知っているのは1つの方法だけという方々もいるでしょうし、複数の方法は知っているけど特定の方法は肌に合わないという人々も、「肌に合わない」という人々をなんとか矯正したい複数の方法をマスターしている人々もいることでしょう。

一昔前はワープロという言葉があり、それが文書作成のスタンダードだったのかもしれませんが、現在ではそれが揺らいでいるのではないかと考えます。コンピューターを使った文書作成の方法をどこで学ぶかというと、学校の "コンピューターリテラシー" などの授業で学んだり、就職してから同僚から学ぶというケースが思いつきますが、そういった場で多様な文書作成の方法を学べるかというと多分必ずしもそうではないのでは?と思います。

私の観測範囲では、方法を問わず書ける人々もいれば、「Google Docs?初めて聞いたよ」「ローカルのOfficeで書いてdocxとかをDriveに置く方が合ってる」「Wikiみたいなのは記法を覚えるのが面倒くさい。」という人々もいます。私はどちらかというと前者の方法を問わず書ける人に属します。

そして、文書作成方法が多様化した現代では、組織によっては上述の文書作成リテラシーの違いによる問題が起きているのではないかと推測します。

本エントリでは、私の考える現状に問題提起をする前に、私自身がコンピューターで文書を書く方法の変遷を振り返ります。

最初はプレーンテキストとTeXだった

初めてコンピューターを使って文書を書いたのは大学1年生のときです。初めて買ったパソコンのOSはWindows98SEでした。また、コンピューターリテラシーという授業があり、そこでもテキストエディタで文書を作成する演習がありました。

コンピューターリテラシーの授業が少し進むと、TeX(てふ)という文書作成アプリケーションを使用して、章や節の見出しをつけたり、画像を貼りつけたり、数式を書いたりする演習が行われました。入学してしばらくすると紙でのレポート提出が必要な授業が増え、TeXでレポートを作成するようになりました。図はTgifというドローツールで描きました。表計算が必要な状況は無かったので、スプレッドシートというものを知らずに過ごしました。

TeXはWordと異なり、決まった形式でテキストファイルを書き、それを別途レンダリングします。TeXを使用できる環境は自宅のPCには無く、大学のコンピューター演習室か、サークルの部室で作業していました。演習室の環境はSolarisワークステーションで、部室の環境はFreeBSDでした。部室にMS Officeの入ったWindows機もあったのですが、体裁のある文書はTeXで作るものと覚えていたので、結局学生時代はMS Officeを使わずに過ごしました。もちろん論文もTeXで書きました。

HTMLで日記を書いた

2000年代初頭ではホームページを作成するのが流行しており、私もそれに乗って作りました。WordPressのような contents management system は存在せず、エディタでHTMLやCSSを書いていました。「TeXとは書式が違うんだな」「リンクが便利だな」「章番号や図表番号を参照するような文書には向かないな」と感じた覚えがあります。ホームページでは日記を書いていました。「授業が面倒」だの、「カレーを作った」だの、取るに足らない内容を書いていた覚えがあります。Twitter と同じですね。

ブログに移行、そしてmixiへ、Wiki

2003年ごろだったでしょうか。日本で幾つかのブログサービスが始まりました。この頃になるとウェブ上で論説文やエッセイなど、それなりの量があって、構造や論理展開がある文章を見るようになりました。そして、多感な大学生らしく「自分もそうした文章を書きたい」と考えるようになり、それまでホームページで続けていた日記をブログに移行しました。ブログ時代は2年くらいは続いたと思います。今はもう残っていません。

ほどなくして日本発SNSの代名詞であるmixiが登場しました。mixiはどちらかというと友人などとクローズドなコミュニケーションを取るために使用し、mixi日記には日常を書き、ブログには長めで一般向けの文章を書いていました。

趣味の活動でWikiも使用しました。簡単な書式でテキストを書くとHTMLに変換されるというのは便利だと感じました。確か、PukiWikiだったと思います。

OpenOffice.org でプレゼンテーション

大学の研究室に入るとプレゼンテーションをする機会が増えました。その研究室では原則的にWindowsが禁止されていたので、Debian GNU/LinuxにてOpenOffice.orgを使っていました。いわゆるOffice系アプリを使用したのはこれが初めてでした。見たままを編集するというのはなかなか軽快で良かった覚えがあります。一応TeXでスライドを作成することもできましたが、見栄えを練るのには向いていないと判断しました。

一方でメモをとるならテキストで十分ですし、レポートや論文を書くならTeXしかないと考え、ワードプロセッサー機能は全く使いませんでした。また、数値計算Pythonなどを使用しており、スプレッドシートも使いませんでした。

就職して初めて Microsoft Office を使った

こうして、大学に入学して初めてコンピューターを使用してから卒業するまで、Microsoft Office に触れないまま過ごしてきましたが、就職して初めて使うことになりました。

初めてWordとExcelを使用したときは新鮮だった覚えがあります。Wordについては「目次はどうやって作るのか?」「なぜ勝手に字下げをするのか?」、Excelについては「セル内でどうやって改行をするのか?」「countifって何だ?」などの疑問に当たり、機能やtipsをググりながら覚えていきました。見出しや図のある文書を作成したり、簡単な表計算をすることは、実務をこなしながら自然とできるようになりました。

そうした中で、Excelで書かれた見出しや構造のある文章、画像を貼りつけただけのシート、全ての行・列の幅を等しく揃えた後にセルの結合機能を使用して表を書いてあるシート、Excelは使用できるがWordは使用できない人々に出会うことがあり、「これは悪い見本なので参考にしてはいけない」と感じたのを覚えています。

Trac の記法や、Redmine の Textile を使うこともありました。

少しだけ Sphinx を使ったこともあります。章や節のある長めの文章は全部 reST になればいいのに、GitHub なんかもサポートすればいいのに、と思いました。

そして現在

現在では GitLab や Qiita:Team などでの Markdown, Word, PowerPoint, Excel, Google Docs などを使用しています。

振り返り、周囲をみると、こういった経験のある人は実はそんなにいないのではないかと思わされます。それぞれは大した経験ではありません。少しトレーニングすればすぐに覚えられることばかりです。ですが、特定の文書作成方法のみ経験している人々がいて、方法が多様化した現在ではついていけない個人がいたり、組織においては支障が出ていたりしないでしょうか?…というのは次の話。

カメをウサギには変えられないことの認識が技術支援のスタートなのではないか

www.slideshare.net

※スライドの技術的内容とは関係ない文章です

 

スライドの13枚目

"人は自分の速度でしか成長できない"
"プロジェクトもプロジェクトの速度でしか成長できない"
"まわりはもうみんなやっていますよは劇薬"
とのこと。t_wada が言うのならソフトウェア開発に関してはそうなのかもしれない。

 

成長速度を上げるにはどうすればいいのだろうか。

 

ウサギとカメの話で言うと、まじめに走るカメの相手がまじめに走るウサギだったら、カメはウサギには勝てない。カメをウサギにすることはできるのだろうか。

 

「相手はウサギだよ」と伝えても、たぶんカメはウサギにはならない。トップダウンで「ウサギになれ!」と鞭を打てばウサギになる人・プロジェクトもいるのかもしれない。しかし、場合によってはウサギになるどころか鬱になって歩けなくなる懸念もある。死んでしまうかもしれない。劇薬だというのはそういう意味だと思う。

 

まじめに走るウサギが沢山いる世界を知っている者は、カメを見ると「そんなんだからダメなんだ」と思うこともあるのだろう。私もそう思うときがある。だが、人やプロジェクトがその速度でしか成長できないのであれば、それを受け止めた上で自身の成長や相手への支援を考えなければならないのではないかと考えるようになった。カメをウサギには変えられないことの認識が技術支援のスタートなのではないかと思う。

 

カメをウサギには変えられないが、成長速度が上がることはあると思う。上げるではなく、上がるである。私は楽しむことが不可欠なのだと感じている。だから、支援をする立場からは、その職能分野のことだけでなく、楽しみを伝えることが成長速度の向上につながるのではないかと考える。ほかに何ができるのかはわからない。案外楽しむだけで良いのかもしれない。

SQuBOKから経営の世界へ, マーケットの世界へ

はじめに

SQuBOK V2読破会アドベントカレンダー20日目のブログエントリーです。 www.adventar.org

SQuBOKというのはこれです。ソフトウェア品質知識体系ガイド。 Google Books で一部を読むことができます。

books.google.co.jp

SQuBOK V2の章構成は2章のマネジメントが中心

SQuBOK V2読破会では文字通りSQuBOK V2を全て読みました。 理解が不十分な知識領域も多くありますが、少なくともソフトウェア品質に関係する知識領域が 何なのかを広く認識できるようになりました。

そこで、改めてSQuBOKの構成を全体的に見つめなおしてみることにしました。 各知識領域について知っているかどうかは、以前のエントリー SQuBOKによる無知の知の体験 - MassKaneko.Out で書きましたので、もっとメタに捉えてみることにしました。

  • 第1章:ソフトウェア品質の基本概念
    • 良い品質とは何なのかは製品や時代によって変わる
    • ソフトウェアの品質には色々な側面がある
    • 良い仕事の仕方が良い品質を生む
  • 第2章:ソフトウェア品質マネジメント
    • ソフトウェア品質マネジメントとは品質管理ではなく、manage本来の意味である"なんとかしてやる"という意味である。つまり、なんとかして目標とするレベルの品質に押し上げる・持続的に改善するための活動である。
    • 開発やテストだけでなく間接的なもの含めてあらゆるアクティビティがソフトウェア品質に関わるため、それらはソフトウェア品質向上のためのマネジメントの対象となる。
    • プロジェクト固有のマネジメント、プロジェクトに依らない共通のマネジメント、プロジェクトレベルを超えた組織レベルのソフトウェア品質マネジメントがある。ソフトウェア品質技術者だけが努力すれば良いわけではない。
  • 第3章:ソフトウェア品質技術
    • 品質を作りこんだり確認するためのテクニックやツールが色々ある

できるだけ短く書いてみました。 こうして考えてみると、第2章が中心の本なのだなと思います。 プログラマーやテスターからすると、品質を向上するためには第3章の内容が中心となって見えます。 それは開発技術やテスト技術ですから、それはそれで閉じているわけです。

しかし品質を上げるために"なんとかできること"とは開発とテストだけではないわけで、マネジメントという概念を持ち出した時点で第3章は主役ではなくなるのです。 そして、ソフトウェア品質マネジメントのことを書こうとすると必然的に「ソフトウェア品質とは」という第1章を書かざるを得なくなる。 だから、この順番の章構成なのだと考えます。SQuBOKを読む前は「はぁあああ??2章がマネジメントぉぉぉ???なんだよ結局品質管理屋のための本かよー。一生マネジメントでもプロセス改善(笑)でもやってればいいじゃん。そんなことしてる間にテクノロジーで遅れを取っていくんだよ。」と思っていましたが、1年前に比べればだいぶ考えがニュートラルに是正されてきたことを実感しています。もちろん直接的にソフトウェアの品質を決めるのはコードですし、欠陥を見つけるのはテストですが、それらの活動を満足に行うためにできることが沢山あるということです。

品質から経営の世界へ

ソフトウェア品質を真正面に考えるのであれば経営やマーケットの世界に足を踏み入れる必要がある。最近、そう思います。

一つは先ほど書いたマネジメントの話の延長線上にあることで、技術職以外の努力が必要となる領域を考えると次に管理職の努力が必要となる領域が思いつきますが、 第2章にあるマネジメントを考えるとなるとプロジェクトマネージャー・プロダクトマネージャーよりも更に上位のレベルのマネジメントが必要となることが考えられます。 例えば、会社組織における品質マネジメントシステムを構築したり、プロダクトのライフサイクル全体を考えたり、ソフトウェアプロダクトラインを考えたりといったことは、 一定以上の規模の会社組織においては一管理職にはできることではなく、経営者の努力が必要となる領域だと思うのです。 経営となるとソフトウェア品質だけに思慮を巡らせるわけにはいかなくなり、経済的合理性という側面からソフトウェア品質を考えることになります。

そうなるとソフトウェアやコンピューターの世界から経営の世界に足を踏み入れざるを得ないわけです。 会社組織ぐるみでないと行えない品質マネジメント活動に一体どのような経済的合理性があるのかを考えないといけなくなります。 しかもそれらの活動は本質的には投資であり、金銭的価値に換算することは難しいのです。 かといって技術者に「投資対効果を示せ」と言ったのではその経営者は無能であることを自白しているに等しくなります。 言い方を変えれば「私には品質マネジメント活動の価値がわからないから小学生でもわかる不等式で説明してくれ」と言っているに等しいのですから。

SQuBOKの巻頭にある"本書の利用方法"には、利用者層ごとのSQuBOKの利用方法について書かれています。 開発者・品質保証・管理者などの職種別に書かれていますが、実は最初に述べられている利用者は 経営層 なのです。 ソフトウェアがプロダクト・サービスの価値を大きく決める事業を行う経営層といっても必ずしもソフトウェアの専門家ではないでしょうし、 専門家でなければならないということは無いと思います。しかし、少なくともどのようなトップマネジメントがソフトウェアの品質向上のために効くか ということは、ソフトウェアがプロダクト・サービスの価値を大きく決める事業を行うのであれば…技術者のように論理立てて説明できなくとも、 直感的に適切な選択肢を選ぶことができる必要があると思うのです。論理立てて説明できなくとも、概ね正しい直感を信じて迅速な意思決定ができる権限があるのは経営者だけだと思うのです。 そして、ソフトウェア品質の専門家はそうしたトップマネジメントができるように経営層を技術面で支えたり、意思決定の根拠となる新鮮で正確な情報を集めたりできることが望ましい協力関係ではないかと思います。

品質からマーケットの世界へ

ソフトウェア品質と経済的合理性の関係は、欠陥や工数が少なくなること以外に、売り上げに対する関係も考えられます。 すなわち、ソフトウェア品質を正面から考えるのであれば、いいものを作れば売れるのかどうかの問いに辿り着くということです。 しかし、このブログを書いてる現在、"いいものを作れば売れる" でググると、そうではないという旨の文章が複数ヒットします。 私はまだその答えを出せるほど品質の知識もマーケットの知識も無いのですが、思うに、"いいものを作れば売れるわけではない" かどうかの話は、 "いい" とは何なのかに踏み込みが浅いのではないでしょうか。

高機能・高性能・高信頼な製品が売れる時代は過ぎ去り、モノづくりからコトづくりの時代に変わったという論旨を、ここ数年で経済誌や講演で見かけるようになりました。 昨年のソフトウェア品質シンポジウムでも触れられていました。 ビジネスが変わればソフトウェアの品質も変わる。ソフトウェアがビジネスの鍵を握る時代の新しい品質とは。ソフトウェア品質シンポジウム 2014 - Publickey

これは "いい" とは何かが変わったということです。 もう少し言うと、機能・性能・信頼性という製品の品質から、UXや安全性といった利用時の品質にユーザーの関心が移ったということなのだと思います。

もし "いいものを作れば売れるわけではない" という論旨における "いい" というのが高機能・高性能・高信頼のことであり、 そう主張する人々がマーケターで、"良さ" を追い求めていたのが技術者だとしたら、 マーケターと技術者が合わせて "いい" とは何なのかを共有する場が足りていないのではないでしょうか。

製品・サービスの "良さ" を考える(決める)ということはすなわち半分くらいは商品企画をするということだと思います。 これまでは、商品企画というのは今まではマーケターの仕事というイメージがあったと思います。 そしてこれからは、ソフトウェアが価値を大きく決める製品においては、品質に関する知識のあるソフトウェア技術者が商品企画の領域に切り込んでゆく余地があるのではないでしょうか。 そうすれば "いいものを作れば売れるわけではない" から "ユーザーにとって価値があるものを作ることが売れることの第一条件だ" に進歩できるはずです。 そう、売りたいマーケターと技術に触れたい技術者の間を取り持つのはユーザーに価値を届けることだと思うのです。そこだけは両職種に共通するところだと思います。 今のソフトウェア品質体系は、良さとは何かをマーケターと共に決めることができるくらいに成熟していると思います。 だから、もし良さとマーケターが中心となって決めているのであれば、そこにソフトウェア技術者が協力できることがあると思うのです。 また、ユーザーに価値を届けずに売り上げを立てようと企てるマーケターや、ユーザーに届ける価値を考えずに提示された要求仕様を実現することだけしか考えないプログラマーを是正して、 ユーザーに届ける価値を中心に仕事をする啓蒙活動を行う役割も必要となり、それを品質のわかるソフトウェア技術者やマーケターが担う可能性もあるでしょう。 そういう意味で、ソフトウェア品質に携わる技術者はソフトウェア品質という技術の世界からマーケットの世界に足を踏み入れる余地があるのだと思います。