6日目
本日は最後のダイビング。
明日の7時にフライトなので、PADIが定めている24時間以内というと、早朝ダイビングしかできるタイミングはなかった。
ダイビングをしなければいいので、その後の2本はスキューバーダイビングを行った。
スキューバーであれば、GoProを使えるので、GoProを使って写真をとった。実際海面付近だとウツボやウミガメ等が生息しており、太陽光も当たっているので、写真とるなら海面のほうがよかったりする。
スキューバーでサンゴ礁のところにいると、カリカリと音がうるさいのだが、ちょうどそのタイミングで魚がサンゴを食べているためそのような音がするみたい。食べている様子は可愛かった。
スキューバーが終わった後は、船にのってケアンズへ。ケアンズについた後は、ホテルで準備を行った後、淳美がケアンズにいるとのことで、おすすめのハンバーグ屋にて合流した。
彼女はスキューバーを結構やっており、スキューバー仲間が増えて嬉しそうだった。残念ながらケアンズでは一緒にダイビングできなかったが、日本のスクールは家から近いところにあるらしいので、日本でダイビングしようと話をした。
食事が終わったあとは、翌朝が早かったので、そのまま就寝。
5日目
本日はダイビングの海上二日目。
朝一で、ダイビングのスキル認定試験があった。
認定試験は、普通にバディを組んで、自分たちで安全にダイビングをするというもの。
特に問題は発生しなかったが、流れの確認を潜水後に確認しなかったため、流れの向かう方向に進んでしまい、あいにく帰ってこれない状態になりそうだった。
まぁでも、その後のフィードバックのおかげで、無事資格は取得できた。
カードは3ヶ月後に届くらしく、それまでは紙ペラでダイビングのライセンスを証明するらしい。これでアイスランドにいってもダイビングができる!
その後は午前に一本ダイビングを行った。バディはドイツ人の女性。彼女はアドバンスのライセンス取得後初のダイビングだったらしい。最初ということで、オープンウォーターの自分に深度をあわせてくれた。
ブリーフィングをちゃんと行わなかったので、帰りのタイミングをあわせられなかった。空気が結構ギリギリで帰ってきてしまった。
昼をとったあと、午後のダイビング。午後はおじいちゃんとバディを組んだ。おじいちゃんは潜降場所に辿りついたタイミングで息切れしてしまったらしく、ひとまず休憩。
無事潜降はでき、ルートの右側を進み、指定された海溝のところで戻ってきた。彼もオープンウォーターだったが、注意された18mよりも深く潜ってしまっていたので、引き上げた。
夕食後は一本ナイトダイブをおこなった。ナイトダイブでは、ガイド引率のもと、懐中電灯をもってダイビングを行う。
前のひとについていき、暗い海を進んでいく。ナイトダイブは普通のダイブと違い、探検している感があり面白かったが、面白い魚は見れなかったのが残念だった。
4日目
今日から2泊3日でグレートバリアリーフでの海上生活。
出発時間は8:30と前日より早かったので、早く就寝しており、時間には間に合った。
まずは車でショップまで行き、スーツケース等の大きい荷物を置いた後、ボートに乗った。
このボートは、海上宿泊のボートと陸をつなげるボートらしく、日帰りのひとはこのボートに乗って帰るとのこと。
まず乗船して、自分のBCD等の機材をTakaからうけとりセットアップ。
その後はダイビングスポットまで時間があったので、ルーフトップにて日焼けをしていた。
肩のあたりと腕に日焼け止めを塗り忘れていたため、後に後悔することになる。
行きのボート上で2本のダイビングを行った。それぞれ海でのスキルとなったため、プールで行ったスキルを繰り返し行うこととなった。演習となるため、GoProは持っていけなかった。
スキルが比較的早く終わったので、余った時間はTakaがいろんな魚を紹介してくれた。
最初のダイビングは、Saxon Reaf Sandras。ニセクロナマコ・イバラカンザシ・グレートバリアリーフアネモネフィッシュが見られた。
次のダイビングは、Saxon Reaf Reaf Magic。 オオシャコガイ・カニハゼ・イロブダイ・ナポレオンフィッシュ・エラヤガラの幼魚が見られた。
ボートが宿泊ボートに到着後、乗り換えを行った。この船では、この乗換から一日が始まるとのこと。
乗り換え後は1本ダイビングがあるとのことで、準備を行った。
このダイブは、Saxon Reaf Atlantic Clipper。 タコ・ハゼとエビの共生・チョウチョコショウダイ・サラサハダ・クラウンアネモネフィッシュが見られた。
このダイブも演習の一貫で、翌朝のダイブが認定ダイブとなるため、ナイトダイブはできなかった。
その代わり、船に集まってくる魚をシュノーケルをつけて観察するというのは出来た。
船の飛び込み台でうつ伏せで見る形だったが、ダイビングしたほうがおもしろいだろうなとは思った
3日目
今日はプール教習2日目。
プールでの実習では、実技での200m水泳と、10min浮遊のテストを行った後、水中でのスキルを行った。
CESAなどの緊急浮上の練習や、オクトパスを使った、バディとのコミュニケーションを行った。今回のバディは、教官のTaka。
終了後、近くのタイ料理屋に行き、レッドカレーを食べた。結構辛かった。
その後、ショップにて買うものを物色。Takaが"マスクだけは買っておいたほうがいい"と言っていたので、まずはマスクを購入した。
その後、HirokiとNaokiがショップの名前の入った海水パンツに興味を持ち、Taka、自分ふくめ4人で買うことに。明日からの海上生活で履いていこうと話し合った。
ショッピングを満喫した後、残り2つの座学を行った。これはレスキューや、実際のハンドシグナル等を行った。座学終了後、試験が開始された。50問中75%正解で合格とのこと。無事3問ミス(?)でライセンスは取得出来た。
終了後は、ご飯を食べに出かけた。今日はオーストラリアっぽいものを食べたかったので、ハンバーグ+オーストラリアワイン+ ラグビーの3セットを満喫した。
相席した人と軽く話をした後、ホテルに帰り、就寝
2日目
本日はスキューバーライセンス取得1日目。
取得するには3日必要で、4日目はフリーで泳ぐことになるらしい。3,4日目は海上泊。
今日はその初日ということで、動画を見ながらの座学と、プールでのスキル学習を行った。
練習中は写真撮影できる感じではなかったので、あんまり写真は取っていない。
座学では、動画をみつつ、教科書の問題を埋めていく形式で、同時並行の作業が求められ、そこが難しかった。水圧と体内の空気の関係やトラブル防止のためのルール等知っておかないとまずいなぁということが多いので、ちゃんと復習は必要。
座学が2/4おわったところで、近場のマックへ。注文のところに、クレジットカードの挿入口があり、このタッチパネルで操作するだけで、注文が出来てしまうらしい。すごい!
テイクアウトで教室に戻り、こんどは食べながら座学となり、ハードルが上がった。
3/4の座学終了後、プールへと入り、スキル学習。ここでは、BCDの装着方法から背負い方、膝立ちの練習、レギュレーターの水中での脱着、ゴーグルに水が入ったときの対処、潜降・浮上の練習、バディとの連携等を行った。
実際にプールでやることで、やっぱり思い通りに動かなかったりするが、慣れてくると自然とできるようになってきたので、引き続き練習していきたいと思う。
練習中突然の豪雨が降ってきたが、この時期はよくあるらしい。室内でよかった。
レッスン終了後、肉を食べたかったので、こちらへ。
リブの250gを食べたのだが、見た目ボリューミーで満足。
食事中相席した人が声をかけてくれ、これからの旅のこととかを話し合った。
帰り道にドリンクを買っておきたいなぁと思ってコンビニみたいなところに立ち寄ったところ、FROZENコーラなるものが売っていて、水と一緒に買ってしまった。
本日はこれでおわり。
一日目
今回の旅行はケアンズ→ウルル→サンフランシスコ→ラスベガス→ニューヨーク→レイキャビク→ロンドン→韓国→日本 という旅程で、今日はケアンズ初日。
https://photos.google.com/photo/AF1QipPuOwBtOyE1dcgAuRLRBo_SSCnuxhrg-CWaHCyi
機内食はチャーハンみたいなのを注文。
https://photos.google.com/photo/AF1QipPaCzHApUIuj_vUEnQLK7RIt00fwhtVrYA52Goh
飛行機内では爆睡していた。
05:00ころ到着
到着後、まずはネット環境を確保する必要があるので、空港内のコンビニみたいなところでSIMカードを購入。おばちゃんいわくアクティベートに30分かかるとのことで、コーヒーを注文。ここでかうSIMはいくつか地雷があるので注意。
購入後、SIMを挿入すればoptus.com.auだけには接続できるので、案内通りに情報を入力するのだが、ここで滞在先の住所が必要なので控えておくこと。また、iPhoneなどで接続する場合は設定後、APNの設定が必要なのでサイトのAPN一覧を参考に設定する。短期滞在の場合はプリペイドだと思うのでpreconnectになるはず。
本日は早速08:00からキュランダで1日観光があるため、タクシーに乗ってホテルへ。バンみたいなのに乗せてもらったが、ちっちゃいタクシーと値段一緒らしい。Uberは使えなかった。
ホテルで荷物を預けた後、身支度をしてロビーで待つ。雨が強すぎて若干萎えてたが、雨のほうがキュランダはいいとのことだったので期待して待つ。
バスが到着し、まず先に向かったのがSkyRail。これはキュランダに向かうためのゴンドラで、上空から熱帯雨林が見られる。
そして、途中に2つ駅があり、そこでは熱帯雨林を歩いて観光できる。
崖スポットとかもあり、まぁまぁ楽しめた。
走行しているうちにキュランダに到着。駅から村まではちょっと歩く。
村は全体的に観光地化しており、お土産屋さんが多かった。
奥のほうに進んでいくと、マーケットがあり、そこにはこじんまりとした飲食店がならんでいた。 その中でもレビューが高かったカフェへ、
クレープ生地で肉とかサーモンとかを載せて焼く店で、ここでは、サーモン・チーズ・葉っぱ・あとその他が載っているやつと自家製レモネードを注文。朝から何も食べてなかったのでとても美味しく感じたが、ちょっと物足りない感じはした。
時間があったので、動物園へ。ここでは、カンガルーやワラビー、コアラなどが飼育されている。コアラだっこ体験もここでできる。
一通り満喫した後は、アーミードックと呼ばれる、戦争中に使われた水陸両用車に乗る体験があり、そちらに乗ってみた。
ガイドのおっちゃんがノンストップで解説をしていたが、自分のリスニング能力ではあんまり聞き取れなかった。。
終了後、またちょっと時間があったので、ジェラートをたべに村散策。両替をしていなかったので\$3のアイスをクレジットカードで買おうとしたところ、\$10からと言われ、途方にくれていたら、店員のおばちゃんが"Take it! Enjoy Australia!“といって渡してくれた。
その後30分くらい時間があったので、蝶の動物園に行った。すごい量の蝶がいるので、蝶好きにはたまらないかもしれない。僕はどちらかというと、幼虫、蛹に興味がもてたw https://photos.google.com/photo/AF1QipPgm_IfU_9KhZXG-cejC1qX3l02fhmD_vpsbh2q
帰りは電車に乗って。レトロな感じで雰囲気良かった。
アップグレードしたおかげで、ドリンクが飲み放題だった。ただ、これまでの疲れであんまり飲めず、途中爆睡。。
途中の経由地点でも写真スポットがあった。
おやつもついてくる。
無事ケアンズについた後は、夕飯を食べに。 Grill'dという店でハンバーガーをたべた、フォークが無く、ナイフがあったので、刺さってる楊枝を支えにナイフで切って食べたw
この日は疲れていたので、そのままホテルに帰って就寝。
その「エンジニア採用」が不幸を生む を読んだ
その「エンジニア採用」が不幸を生む ?良い人材を見つけ、活躍してもらうには何が必要か?
- 作者: 正道寺雅信
- 出版社/メーカー: 技術評論社
- 発売日: 2016/12/07
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
この本のおそらく対象読者は経営者、人事担当であり、背景としてエンジニア出身ではない人たちなのだろうと感じた。
業務で普通にコーディングしている自分のような人だと、「まぁそうだよね」っていう要素が多分に含まれている為、響いた要素はそんなに多くなかったのかもしれないけど、「もし自分が採用側に立ったら」という視点で幾つか気になった点をまとめていきたいと思う。
エンジニアを採用する目的
ソフトウェア外注の内製化は、コストをかけてでも質の高いものを作るか、社内の余剰人員を稼動させ、キャッシュフローの社外への流出を防ぐのが基本です。
僕はベトナムでのオフショア回していた経験があるので、ここには非常に同感している。 やっぱり、外に投げるほうが、日本で開発する分にはコスト減になるというところは同意する。 ここでいう「質」っていうのはいろんな意味があると思うけど、自分の経験上の感覚だと「目的に対して最適なものを作る」という意味だと思っていて、外注だとそのプロジェクトが生まれた背景を骨の髄まで理解できないという意味で質が低い物ができるのではないかと思う。
経験則的に上記の質は非常に大事。とくに今までなかったようなシステムを創る場合は。
人事担当
成功したエンジニアが人事部門にいることは企業にとって大きなプラスですが、エンジニアとしての能力不足が原因で配置転換もしくはキャリアチェンジした元エンジニアは、自分で「人事業務にキャリアチェンジし、人事採用業務に徹する」と決意した者以外、現職のエンジニアにとって大きなマイナスになります。もちろん、自身より優秀な人を採用することは極めて困難でしょう。
採用担当者に必要なのは、自社の開発の特性を理解し、必要なエンジニア像をイメージし、社内で調整力があって、良い採用プロセスを構築・運用できることです。
まぁそうですね。ただ、この本で挙げられている特性という部分に関して、toBなのかtoCなのかやベンチャーなのかみたいな例が上がっていたけど、それがわかっていない採用担当がいるっていうのが衝撃だった。
エンジニア市場の特性
人材紹介会社にとって、エンジニアは転職市場において希少価値があり、採用希望企業数も圧倒的に多く、エンジニアの給与水準もほかの職種より高く、高額の成果報酬が期待できるので、最も激しい主戦場となっています。
最近では、社外での勉強会やSNSを通じて、エンジニア同士やCTOの方のところへ転職の打診があるケースが増加しています。
良いエンジニアに出会うためには、現実には地道な採用活動がメインになります。ハニートラップなどではなく、FacebookなどのSNSでエンジニア同士がつながり、勉強会などを通じて人間関係ができ、エンジニアの転職のきっかけになることのほうが、よっぽどリアルで、考えるべき採用ルートです。
人材紹介会社に来るエンジニアと来ないで転職するエンジニアという住み分け?があることが、エンジニア界隈であることかなぁ。 ようは"人材紹介会社にとって"というところがミソであり、希少価値があるっていうのは、そこで探そうとするからかなぁと。
CTOは採用の前面にたとう
CTOは、次のようなことを真摯に説明するのが重要です。 - 「技術開発のポリシーや開発現場のカルチャーはどのようなものか」 - 「どのような技術、どのような開発手法で、開発・運用をおこなっているのか」 - 「エンジニアのキャリアに関して、どのようなビジョンと制度があるか」 - 「どのような考えで、開発部門をマネジメントしているか」
たしかにこういうの気になるなぁ。結構この辺でミスマッチ起こりそう。 それこそ、今どういう技術を使っているかっていうより、どういう方針で技術を取捨選択し、どれくらい現場に任せているのかみたいなところを見る人は多そうな気がする。
エンジニアのおちんぎん
エンジニア職の賃金テーブルを、年功序列カーブから、20代半ばから実力に応じて一気に上昇し、30代の前半で一度ピークをつける賃金カーブで設計してみてはいかがでしょうか。30代の後半以降は、マネージャー職やシニアエンジニア職を選択してもらい、選択時にいったん給与は下がるものの、ゼネラリストもしくはスペシャリストそれぞれのレベルに応じて再び給与が上がっていく、フタコブラクダのような賃金カーブです。
そういう発想はなかった。でも確かにそうですね。とは言え、賃金テーブルに関しても、年齢が本質なのではなく、職種やスペシャリティーに対して給与を決めるみたいなところが必要なんでしょう。 30代後半じゃなくても、優秀なマネージャーだったら給与は下げなくてもいいし。
評価システム
「感性を生かした評価システム」を具体的に構築し、客観的に運用することでミッションが明確に実現され、それが会社の個性としてクライアントや転職する意向のあるエンジニアに認知されるようになったことは、大きな成果といえるでしょう。
評価するときに、やっぱり会社として向かっている方向に向かった人を評価したいっていうのは経営側はある気がするんだけど、大体それってふわっとしているから、具体的に落とし込むっていう作業は非常に大事なんだろうなぁ。 そもそも会社として向かっている方向が無いのはあれだけどw
研修
細分化された目標の技術・スキルを確実に身につける教育環境の整備も重要ですが、最も優れた研修は、開発の最前線にいる最も優秀なPM・エンジニアによる実践的な研修でしょう。エース級のエンジニアによる研修だからこそ、価値があるのです。しかし、これができる企業はあまり多くありません。
そうね。これできる会社は強いでしょう。そもそも誰がエースなんですかねってところから考える必要はあるけども。
マネージャーとエンジニア
米国の場合、ITプロジェクトのマネージャーは、MBAを持ち、最初からマネジメントの教育を受けた方であるケースが多く、「プログラマがシステムエンジニアになり、ある年齢になるとマネージャーになる」といったキャリアパスはあまり見かけません。プログラマも、システムエンジニアも、プロジェクトマネージャーも、縦割りの職種なのです。
なるほどなぁ。やっぱり違うんだよなぁ。こういう文化の企業だと、おそらくやんなきゃいけないことも明確なので、自殺しちゃったり鬱になっちゃったりっていうのも少ないんだろうな。その分縦割りだから実力云々をフラットに評価されるんでしょう。一回はこういう環境で働いてみたいものですね。
最大の敵は社内にいる
これまで、良いエンジニアに働いてもらうためのいろいろなプランを見てきましたが、実現には多くのハードルがあることでしょう。最大の敵は、社内にいます。ハードルとなる第1要因は、「コスト削減優先」「エンジニアは原価だ」と考える、ITに理解のない経営者です。
ねー。
まとめ
エンジニアは特殊な人たちみたいな感じで、経営者は苦労するみたいだけど、多分ちゃんとマッチングするスキームが一般化していないから、ようわからんで終わっちゃってるんだろうなぁ。 採用段階ではちゃんとマッチングするためのエンジニア、仕事双方の性質の正規化が求められ、採用後では双方が相互に理解する努力は必要なんだろう。