画面遷移するときに次のViewControllerに値を渡す

たびたび忘れるのでメモ

Segueが呼び出される前に実行されるのがこのprepareForSegueメソッド。

この時引数のSegueオブジェクトが、次に表示されるViewControllerのオブジェクトへの参照を保持しているので、そいつに値を渡してあげる。

不安に根ざしたキャリアの選択

寒いです。朝に強くなりたい。

今日のテーマはキャリアの選択と不安の関連性。

要するに、キャリアの選択に際して「不安」に根ざした選択をするせいで、より重大な決断を先延ばしにしない方がいいよって話。

君の両親は、大きな個人的リスクを冒して注目に値するキャリアを目指すよりも安全第一でやってほしいと思うだろう。だから両親の君への忠告は、他の誰の忠告よりも不安に根ざしたものとなるはずだ。不安に根ざした忠告では失わないことが重視される。でも、失わないようにしようと考えるのは勝利への道じゃない！勝利者はリスクを冒すものだ。彼らは他の人たちがいるところではなく、自分のいきたいところについて考えるのだ。

そうだ。僕の父親は特にそうだったな。僕は新卒で入社した会社に3年勤めて今の会社に転職したんだけど、僕が当時働いていたのは大きな会社の（事実的な）孫会社だったから、父親が転職に反対することは目に見えていた。だから僕は転職活動中も家族には相談せず、結果だけを報告した。父親は難色を示したが、親戚のおじさんにたしなめられて渋々納得してくれた。（ちなみにこのおじさんは、父親よりも遥かにビジネスで成功した人だった。つまり、僕の父親の価値観とはそういうことだ。）

とはいえ僕自身、いつでも不安から解放されたキャリアの選択ができているかというと、そんなことは無い。ということでやってみよう。

キャリアに関する君の最大の不安は何だろうか。君のこれまでのキャリア選択の中で新しいものを2つか3つ念頭に置いて考えてほしい。重大な決断である必要はない（なにしろ、君が不安に根ざした選択を行っているとすれば、重大な決断をしているとは考えにくいからね）。（中略）それらの選択のリストを作成し、それぞれについて正直に評価を下してほしい。その選択がどれくらい不安に左右されたか？

ちょいと表にしてみた

こうやって見ると、わりとサクサクキャリアに関する決断をしている感じもするけど、実は一つ一つの決断をするのにかなり時間がかかっていたんだよね。（特に転職の時にはキャリアコンサルタントに相当迷惑をかけてしまった。）

直近だと、1と2の選択に関しては迷いがけっこうありました。2.の打診を受けた自分は特に迷いもなくリーダー職に就くことに決めました。オファーの内容は半年後だったけど、比較的小さい規模のチームのリーダーを経験することは、今後のステップアップに向けて良い影響を及ぼすだろうと思ったのです。ところが、その少しあとに参加した社内の送別会で、話の流れが変わってきました。先輩と酔っぱらって色んな人に絡んでいたとき、ビジネス部門のマネージャーから「俺のとこで働けよ！」と声を掛けられたのです。そのときは酔っぱらった勢いで話していたこともあって、「是非是非！」とか言ってました。「まあ酔っぱらって話していたし、本気じゃないだろうな〜」なんて思っていたのすが、それから数週間すると、本当にそのマネージャから当時の自分のマネージャに異動オファーが来たのです。当時僕が所属していた開発チームのマネージャは、自分宛に来たオファーということを隠して、メンバー全員から異動の希望者を募りました。

その時に僕は開発チームのリーダー職に就くということと、ビジネス部門で働くことのどちらを取るべきかということで非常に悩みました。その時所属したチームのリーダーになることは確かに魅力的でした。エンジニアを束ねて、チームとして結果を求めれば、自分一人で出せる結果よりも大きな目標に向かうことができます。一方ビジネス部門に異動すれば、メンバーとして求められる働きが全く変わります。ビジネスが生み出すお金に対してコミットしていくことが求められるのです。悩む中で、僕はビジネス部門の先輩に相談したのですが、その時の言葉が決め手になりました。僕より10歳も年上＆子供が二人もいる方なのですが、「15年くらい社会人やってるけど、基本的に迷ったらやってみる方を選ぶようにしてるよ」とさらっと言ったのです。僕にとって、どちらの選択肢がよりチャレンジングであるかは明白でした。そのときの迷いの根本には、チャレンジに対する不安があったのです。そのままリーダーになることもある程度のチャレンジではあるものの、ビジネス部門に異動することの方が、遥かに大きな変化を自分に強いるものだと分かっていました。だからこそチャレンジすることに迷いを感じていたのです。その先輩と話す中で、チャレンジすることに対して、不安以上に期待が大きくなり、結果的によりチャレンジングな選択をすることができました。不安であることを認めて、それを乗り越えている人からアドバイスを貰えたことは、非常に幸運なことでした。

この選択が正しかったかどうかをしる術はありませんが、きちんと不安と向き合えば乗り越えることはできる、という自信を持つことができました。

とりとめも無くなってしまいましたが、今日はこのへんで。

コードの生み出す価値

4半期の締めが近づいて職場は変な緊張感に包まれてきました。

これも営業やマーケティング担当者と同じチームで仕事をしているからこそ味わえる緊張感だと思います。実際には僕の両隣にディレクターがいて、容赦なくWebサイトの改修依頼が降ってきてます。

ディ「1週間でこのABテストの結果出るから、そのタイミングで次の改修ね」

僕「あれ？スケジュールに実装の期間がとられてないんですけど…？」

ディ「あ…、」

こんな具合でいくつものサイトを回してます。なんだかんだ言いつつも、この状況が面白い理由がいくつかあります。

• 実装時にひらめいたアイデアに対して、ディレクターからソッコーでフィードバックをもらえる
• 自分の仕事がチーム（会社）の予算目標達成にどの程度寄与したか分かりやすい

一つ目がこれまでできなかった理由は、物理的に離れた場所にいることで、フワッと浮いたアイデアや、何となく試しに作ったものについて、フィードバックを受けにくかった、ということがあります。これはかなり大きいメリットで、アイデアって結構熱いうちに叩かないと消えてなくなっちゃうと思うのです。もちろんアイデアブックとかに書き溜めておくって手もあるんですけど、思いたったその瞬間の熱量でって維持できないんですよね。そういう意味でフィードバックを瞬時にもらえる環境ってとても重要だと感じています。

二つ目については、良い意味でカルチャーショックを受けました。僕は転職でSIerから社内SEに転身したんだけども、その時の変化以上に大きな変化をがありました。まず、自分が所属するチームの目標が全く異なるのです。

1. SIer：このプロジェクトを成功させよう
2. 社内システム部：お金稼ぎしてる部門からの要求を可能な限り実現しよう
3. 今：チームで粗利をあと○○万円積もう

求められる結果が全て数字（利益）なのです。1.と2.の違いは本質的にはそんなに無くて、顧客が社外の人か社内の人かの違いかな、と思います。要は顧客満足の最大化です。その顧客満足の先にあるものがまさに3.で、「顧客が儲かる▶︎顧客が満足する」ということになります。こうして整理してみると、案外2.と3.に違いが無いように思えます。しかし、現実にはこのワンクッションがあることでビジネスへの熱はかなり冷めてしまうのです。

3.の目標に対してコミットしようとしたとき、これまでの部署で仕事をしている時には無かった考えを常に念頭に置いています。それは、このプログラム一行が、いくらの価値を生み出すのか、を考えて提案、実装することです。プログラミングは僕のスキルのコアであることは間違いありません。しかし、今チームから求められていることはプログラミングをすることではなく、お金を稼ぐことなのです。もちろん必要に応じて今でもかなりの量のプログラムを書いていますし、プログラミングはとても面白いです。でも、そのプログラムが生み出す価値を知るためには、対象のビジネスの仕組みや、チームの強みと弱み、競合他社の状況、業務フローなど、様々なビジネスの要素を理解することが必要なのです。

この「ビジネスを知る」ということがとても面白いのです。お金の流れや、（システム部の、ではなく本当の意味での）顧客との生々しいやり取りの中で、会社としてどんな価値を出すのか、その中で自分が何をするのかということを考えるのです。（もちろんまだまだわからないことだらけですが）

たまには感じたことを書いてみようと思ったらだいぶ長くなってしまった。要は自分の書いたコードがどんな価値を生み出しているのかが分かると、とってもやりがいがあるってことです。

コーディング以外の武器

一つのまとまった文章を書くことが、どれほど大変かようやく分かった。

１時間もあれば記事の一つくらい書けるだろうと思っていたが、とんでもない。中身のある文章を書くのはとてつもないエネルギーと時間が必要なんですね。

今日は、コーディング以外のプログラマの武器について。

重要な人材であり続けたいなら、自分が十時しているビジネスの分野にもっと首を突っ込まなければ。

おお、今日のテーマは今の僕の状況からしたらやりやすい！

少しだけ今僕がおかれている状況を説明しておこうと思う。僕は今、システム部からビジネスをする部署に移動した。

2年半前、SIerからWeb業界に転職した僕は、この業界でスピードの早いビジネスを学べることを期待していた。しかし、イントラネット内で使われるWebアプリケーションしか開発したことの無かった僕にとって、まずはプログラマとして学ばなければならなかった。それはとても刺激的で面白かった。apache HTTPサーバの設定方法に始まり、tomcatへのJavaプログラムを動的デプロイするフレームワークを使ったり、2週間程度でPHPでのサイト構築をしたり（このときPHPは未経験だった）、自前のコーディングだけでシングルページWebアプリケーションを作ってみたり、いろいろなことを吸収していった。

ところが1年半を過ぎたあたりから、言い知れない停滞感を感じるようになった。振り返ってみると、自分のポジションに対して求められるものに、ある程度応えられるようになったことで、ある意味手を抜いて仕事に取り組むようになっていたのだと思う。それに、そもそもこの会社に入った目的を何も達成できていなかった。

そんな中で、社内でビジネスをしている部署（営業やプロモーションをやっている部署）が、部署内にプログラマを抱えたいって話が出てきた。（実は正式な話がシステム部にくる前に、その部署のトップがこっそり僕に話を持ちかけてくれていたんだが）僕は真っ先に手を挙げて、ビジネス屋が仕事をしている隣でプログラマとして仕事をすることになった。

　君だって、一緒に仕事をしなければならない全員がソフトウェア開発について熟知していたら仕事が楽になるって思うだろう？Webアプリケーションで1ページに30,000個のレコードを返すのがなぜ無謀なのか、開発サーバにリンクを渡すのがなぜいけないのか、いちいち説明しなくて済むんだから。顧客だって君に同じようなことを望むはずだ。いちいち噛み砕いて説明しなくても、このプログラマどもが私の要望を理解してくれたら、どれほど仕事が楽になることか！忘れちゃいけない。君の給料はビジネスから生み出されるんだ。

僕はビジネスをする部署に来たことで、この言葉に心底共感できるようになった。ビジネス屋にとって一番のリスクは、自分たちを取り巻く状況が刻一刻と変化している中で、自分たちだけが手をこまねいて何もしていないということだと感じた。一方のシステム屋にとっては、動いているシステムに手を入れることはリスクでしかないので、なるべくシステムに手を入れないようにしたいと考える。このビジネスとシステムのリスクのバランスをとることが、とても難しい。僕は難しいからこそやりがいもあるし、需要があるスキルだと思っている。

ビジネス屋の連中をランチに誘ってみよう。（中略）テクノロジがどういう風に仕事に役立っているか（あるいは逆に妨げになっているか）聞き出すんだ。彼らの立場から自分自身の仕事について考えてほしい。これを定期的に行うこと

ランチでは無いけれど、これは僕が毎日やっていることだ。セールスやプロモーションをしている人たちは、僕らエンジニアとテクノロジに対する考え方が全く違う。テクノロジを恐れている人や、魔法のように何でもできると期待している人、蔑む人など様々だ。ただみんなに共通しているのは、「なんとかしてこのよくわからないテクノロジと、気難しいエンジニアどもと付き合わなきゃならない」って思ってるってことだ。だからこそ、日常的にコミュニケーションをとって、信頼関係を構築することが大事で、そういうエンジニアが求められているんだ。

勤務先が属している業界の業界誌を読んでみよう。（中略）そして上司や顧客に訪ねても良さそうな質問のリストを作成してみる。たとえ馬鹿な質問かなと思っても、思い切って尋ねてみよう。相手は君の学ぼうとする態度を評価するだろう。

これも、今は回覧で業界の新聞や冊子が回ってくるので、ありがたいことに自分から探さなくても実践できている。

早速次の回覧で質問のリストを作ってみよう。

情熱プログラマー ソフトウェア開発者の幸せな生き方

プログラマの需要と供給

さて、早速前の記事を書くのに1週間もかかってしまった。危うく3日坊主にすらなれずに終わってしまうかと思った。

続いてはテクノロジに対する需要と供給についての話。

　.NETプログラマの場合、労働市場で張り合うことになる人たちが大勢いて、例えばPythonプログラマに比べると何万人も多いだろう。その結果.NETプログラマの平均コストは大幅に下がり、事によると需要が増加すす（つまり.NETの仕事が増える） かもしれない。だから職探しは楽になるかもしれないが、賃金はそれほど高くならないだろう。Pythonプログラマなら、需要に対する供給が.NETプログラマに比べてずっと少ないかもしれない。

　Pythonの労働市場で著しく高いプログラマあたりのコストが維持されるなら、この高値でサービスを供給しようとする人が増え、結果として競争が激化し、価格が下がるかもしれない。

 とっても分かりやすい！そりゃあそうだ！

何しろ自分がJavaエンジニアとして2年半前に転職活動をしたとき、年収の下限は300万円を切っていた。300万て、新卒ですよね。それでもその年収でも応募する人がいるんだから、実際のJavaエンジニアの年収の下限はもっと低いんだろうと思う。

なんだか書いてて腹がたってきた。

 　だとすると、労働市場のなかでもまだ需要が少ない分やで競争するという道が考えられる。直感ではわかりにくいかもしれないけど、君がオフショアに負けて職を失うことを心配しているなら、オフショア企業がやっているような仕事をさけるのも一つの手じゃないだろうか。オフショア企業は需要が多い分野の仕事をしている。それなら、ニッチなテクノロジに注力してみよう。需要が少ないから必ずしも競争が楽になる訳じゃないけど、競争のポイントを価格から能力に変えられるかもしれない。これこそ君に必要な戦略だ。価格で競争することはできなくても、能力でなら競争できる。

オフショアか。確かにこの間会社でiPhoneアプリを外注に見積もってもらったら、中国のエンジニアを使ってとんでもなく安い値段を提示されたな〜。

きっとこれが現実なんだろうと思う。でもニッチなテクノロジにしか活路はないのだろうか…？と不安に思って読み進めたら、そうでもなかった。

　主流技術のプログラマのほうも、平均価格が下降しているので需要は増加するだろう。例えばJavaプログラマに対する需要が全体として増加すれば、国内での仕事の中には、減らずに増える種類の仕事があるかもしれない。低コストのオフショア市場のっ拡大が総需要を増加させる可能性がある。その中には上層の開発者も含まれるという意味だ。

　この流れは現実に起きている。多くの企業が気づいていることだが、オフショアを成功させるためには、基準を設定し、品質を保証し、技術的な指導をするハイエンドなオフショア開発者を確保する必要がある。（中略）Javaの開発者においても、このレベルの仕事については、ニッチな労働市場と同じように競争のポイントが価格から能力へと変わるだろう。

 なにもオフショアに限った話じゃあない。自社開発の会社、派遣の会社だって、単純なプログラミングしかしていない人の単価は低く抑えられているけど、ビジネスレベルの問題発見、問題解決のフェーズまで踏み込めれば、相応の給与が期待できる（というか実際もらっている人がいる）。

実際、SIerで働いていた頃、50歳を超えても給料が新卒と大差ない人もいたが、確かにローエンドの仕事しかしていなかった。きっと、ハイエンドな仕事に向かう意思が無かったか、それをアピールするチャンスが無かったんだと思う。（しかも、一定の年齢を超えれば周りの人はチャレンジすることをその人に期待しなくなってしまう！）僕はそれを目の当たりにして、よりハイエンドな仕事にチャレンジしやすい環境としてWEB系の企業への転職を決断したと言っても過言ではない。

さて、ワークだ。

技術スキルに対する現在の需要を徹底調査してみよう。社内公募とキャリアのWebサイトを利用して、需要の多いスキルと需要の少ないスキルを調べ、リストにまとめる。そしてオフショアアウトソーシング企業のWebサイトを探す。そうした企業を使えば調達できるスキルと、リストしておいた需要の多いスキルとを比較してみてほしい。オフショアの進出が少なく、国内での需要が大きそうに見えるスキルを書き留めよう。次に、最先端のテクノロジと、オフショアアウトソーシング企業で調達できるスキルとの間で、同様の比較をする。オフショア企業がカバーしていない両方の技術スキル群に注目してほしい。オフショア企業がそうした穴を埋めるまでには、どれだけの時間が必要だろうか？それが市場の不均衡が続く期間の長さだ。

 こんなのできるのか…？と思いきや、ちょこっと検索してみると色んな記事が出てきた。

まずこれ。いわゆる、「需要の多いスキル」ってやつだと思う。（記事のタイトルにもある通り、「就職」をゴールにした場合には間違っていない戦略だ）

プログラマーの就職に有利な10のプログラミング言語 - Ameba News [アメーバニュース]

お次はこちら。これは年俸順なので、ある程度需要と供給のバランスが反映されているぽい。

【プログラミング言語別！】求人給与額ランキング | HRog

まとめるとこんな感じ

需要の多いスキルってのは「就職に有利」のランキングで、求人数は転職市場のモノだから若干ズレがあるのかもしれない。

僕の場合、ゴールは就職じゃない。プログラマとして市場価値の高い状態に居続けることが目標だ。となればとるべき戦略は、Chadの言うように市場の不均衡が起きている場所で勝負をしなくちゃならない。

何となく、やるべきことが見えてきた。

1.先んずるか、やられるか

現在の市場におけるテクノロジの年齢を若年、中年、老年に分類し、表にまとめてみよう。それらを紙の上に左から右へとマップしてほしい。左側に最先端のテクノロジが、右側に衰退しつつあるテクノロジが並ぶ。

『情熱プログラマ』より

うーん、テクノロジって幅が広すぎないか…？

言語？プラットフォーム？フレームワーク？…

ひとまずあまり深く考えずにやってみるか。

際限がないので、とりあえず思いついた言語とプラットフォームについてやってみた。やはりプラットフォームについてはweb関連のものしか思いつかなかったな…

考えつく限りのテクノロジを採用曲線にマップしたら、自分自身が良く知っていると思うテクノロジに印をつける。 それから、いくらか経験があるという程度のテクノロジに別の色して印を付ける。印をつけたテクノロジは採用曲線のどのあたりに多く存在するだろう？塊になっているだろうか？均等に分散しているだろうか？両端付近に、特に関心を持っているテクノロジはあるだろうか？

ほとんど中年にしかない…

これまでいかに所属する会社に流されてきたかがよく分かるな〜。きっと大学とかで勉強してきた連中は右から中央にかけてバランスよく習得しているんだろう。

両端付近の関心のあるテクノロジとしては

• node.js
• LISP

くらいかな？node.js、swiftあたりは会社の勉強会でやるとして、右端は自分でなんとかしないとな。あー、smalltalkも良いかもしれない。

でも現実的に考えて、勉強時間というコストに見合う費用対効果を出すには、まず左端▶︎右端で攻めていくべきかな。

まてよ？費用対効果？効果ってなんだ？

情熱プログラマー ソフトウェア開発者の幸せな生き方

イントロダクション

まずルールを決めようと思う。

• 半年以内にChadの「やってみよう」を全部やる
• できるだけ毎日記事を書く（過去の記事の手直しだけでも）
• 記事を書けない日は過去の記事の見直しをする（iPhoneから）

これくらいかな？

初日から寝坊して全く自信はないけども。

ひとまずイントロダクションに書かれている僕のお気に入りの一節を紹介したいと思う。

少なくとも駆け出しのミュージシャンにとって、音楽の世界における偉大さは二者択一だ。偉大になる（そして結果的に有名になる！）ことを望むか、そもそも初めから音楽をやらないか。 

『情熱プログラマー』イントロダクションより

Chadは元々ジャズのサックス奏者だったらしく、この超基本的な原則に従っていることで、プログラマの世界で名を成すことができたと語っている。

僕自身もアマチュアの演奏家なので、このフレーズがやたらしっくりきて、音大生相手に偉そうに語ってみたこともある。

でも自分は果たして偉大になるという目標を持っている？

その目標に向かっている？

そんな疑問、不安からこの企画がスタートするのです。

情熱プログラマー ソフトウェア開発者の幸せな生き方