はてブ経由で知ったプログラマー面接時の技術的な質問事項(アプレッソ版) というエントリが自分の仕事にも通じる箇所があったのと参考になる記述があったのでいくつか触れてみようかと思います。

■ 開発実績編
まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。
ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。

これはたしかに自分の経験上でもとっても実感あってよくわかりますね。

自分の場合は、こういう人がもっている情報（Infomation）ではなく知恵（Intelligence）のようなものがどこまであるのかを知りたいから、本人が考える過去のプロジェクトの失敗例についてお尋ねすることが多いかなぁ。

折角なので、普段の私の仕事の場面において、技術的なところ以外についてもお尋ねするようにしてて、特にリーダやPMという肩書きの人には

「ｘｘのプロジェクトではメンバーとしての役割で、△△以降のプロジェクトはリーダー（もしくはPM）としてご経験されていますがリーダー（PM）ならではの役割で苦労されたことは何ですか？」

というのを基本的な質問として行うようにしています。

そもそもメンバーとリーダーとそれぞれに期待される内容が異なるはずなので、そこの差分が何かをきちんと把握したいですし、肩書きだけのリーダーという場合もあるだろからそのあたりを確認する意味ではこの質問でおおまかな感覚は掴めると思います。

 

今までの私が対応してきた感覚では、「苦労したことがないですねー」という回答をした場合の人の場合には本当にそれなりのことをしているのかちょっと疑ってしまいます。

■ デザインパターン編
デザインパターンは基本的にはコミュニケーションツール(一言で説明できてすぐ伝わる)としての位置づけが重要だと思っているので、すべて知っていないと NG、ということはまったくないが、普段普通に使っている、という人の場合には、お互いのレベルを見るのにもってこいのディスカッション材料なので、よく 面接の時に話題に上る。

• Singletonパターンとオブジェクト生成コスト、Singletonパターンのマルチスレッド対応について、注意すべき点を説明してください
  
• Observerパターンでイベント発火順序が重要な理由を説明してください
  
• Mediatorパターンでメソッドが多くなりすぎてきたときにどのような工夫をしますか
  
• Visitorパターンを使うべき場合と、再帰的ループで対処する場合とを、どのように使い分けますか
  
• Compositeパターンが時として「オブジェクト指向的に気持ち悪く」なるのは何故ですか

私自身は上記質問に対しては現時点で答えるほどのスキル(*)は持ち合わせていないですが、今後こういう質問はぜひやってみたいと思います。

「技術的な正しさがわからない人が上記のような質問をするのは意味がないんじゃないの？」

という突っ込みがあるかもしれませんが、この類のことで大切なのは、技術的な正しさを確認するのではなく、「なぜxxxと思いますか？」とか「どのようにxxですか？」という問いに対して、相手の方の根拠が何かを確認することかなぁと思います。

ここまでの専門性のある質問は現状できていませんが、回答が何通りもでるようなこのようなオープンクエッションは面談のような場面では特に有効かと思います。

ついでに言うと「○○○○○は出来ますか？」というYes/No式のクローズドクエッションは話題が膨らまないし、出来るの基準は人によって様々なので、技術面の確認においては価値は低いかなと思います。

(*)とはいってもわかるようになりたいので、勉強は欠かさずやっているのと、個人的に仕事上で使うツールを色々な制約があるWindows環境下で一番使い勝手の良いJScript＋Prototype.jsで作っているうちに、デザパタをどのように適用していくのかというセンスの良し悪しみたいなものがあることがよくわかってきた。

 

 

たまには、真面目なエントリを。

2009年1月号の月刊コンピューターワールドによると、平均的なITエンジニアとは違った特徴が未踏ソフトウェア創業事業の天才プログラマー（スーパークリエイターでは？）に選出された人との間に、大きな隔たりがあるそうです。

記事中で

・オープンソース・コミュニティに積極的に参加している
・大企業への就職にまったく魅力を感じていない
・プログラミングをはじめとする好きなことに没頭できる環境を望んでいる、もしくは子供のころからそのような環境を与えられてきた
・長時間のプログラミングは苦にならないが、自分の時間を自由に使えることへの要求が非常に高い

またキャリア意識にも違いが感じられた。天才プログラマーたちには、将来の仕事に対して「このまま好きな仕事を続けたい」「自分が開発したプログラムを海外も含めてもっと多くの人に使ってもらいたい」「時間を自分の好きなように使える環境で仕事をしたい」という回答が多く、自らのキャリア・プランについてはさほど強い関心を持っていないように思える。６人とも大企業への就職活動を行った経験がないという事実は、これを裏付けるものだろう。（P.55より）

と書かれていたのですが、気になったのは、「キャリアプランについて強い関心を持っていない」という所。

日頃私がキャリアカウンセリングという場を通じて接してきた人の中で、仕事を通じて得たいモノとして

・他人から感謝されたい気持ち
・（特定の個人に限らず、オープンソースのようなコミュニティも含めた）他者への貢献とか役に立ちたい

というケースの方が半数以上という感覚をもっています。（※）

この感覚って上記引用した、自分が開発したプログラムをもっと多くの人に使ってもらいたいっていう感覚と通じるものがあるように思います。

ちょっと話がそれますが、最近以下の本を読んでます。

この本の趣旨としては

・労働と収入とが従来は一帯になっていたが、これを一度別けて考えましょう。
・国がどのような国民に対しても一定の金額を一律支給しましょう。（これが本書のタイトルになっているベーシックインカムっていうやつ）
・モノやサービスを購入する時点に対して税負担をかけてそこから税金を徴収しましょう。

という感じと理解しているのですが、仮に日本においても、ベーシックインカム的なものが導入されたとすると、日々の生活を維持するために必死に働かなければいけないということから解放される人が出てきたり、他者のために自分が貢献出来る事が無いかということを前提にして働く人が増えるんじゃないでしょうか。

個人的には「働く」ことによって得られる対価として従来だと金銭っていうのが一番わかりやすかったし、それが前提としてキャリアプランを考えるという状況だったのかと思いますが、昔に比べて急激な成長ということもはまずなく成熟していく世の中においては、「働いた結果得られる対価」として相応しいものが何なのかということを根本的に見つめ直す時期に来てしまっているのではないかなぁーと最近考えてしまっています。

（※）私がお会いしているのはIT技術者に該当する人達です。他の意見としてはスキルアップあたりがよくある話で、収入のアップはそこまで多くはないです

スーツや靴はお直しでカッコ良くというエントリで

ブリフトアッシュ

記事中では、こちらのお店を使って、靴磨き、補修、等々の作業で総額１万円超で、劇的に変わっていました。

記事では、上記以外にもマーシ目黒という所に、履き込んだ靴を数足持ち込んで、実際にどれだけリニューアルされているかというのがあったのですが、こちらの仕上がりもかなりのものでした。

と取り上げたブリフトアッシュで靴の修理をお願いして、先週修理から戻って来ました。

 

まず修理前はこんな↓感じ。

雨シミのために黒ずんでしまっている箇所が目立ってしまってこれをどうにかして直せないかなぁと思ったのと、写真ではわかりませんが、靴の裏側のダメージも結構ひどかったので予算次第ではついでに直してしまおうと思ってお店に持ち込みました。

お店のWebサイト見てもらうとわかりますが、なんとなく格調高いサロンっぽいイメージを持っていた事も会って、お店に行く前はもの凄く緊張していたのですが、その日に接客してくださったお２人ともとても感じが良い人で、そのうちの１人は、前職はC言語で組込みの開発をされていたらしく、なんだかそんな話を聴いているうちにとてもリラックスできました。

で、接客してくださった方のアドバイスを聞いて、細かい所で色々と修理が必要なほどダメージをおっている重傷状態ということで、全部直すと普通に新品の靴が買えてしまう値段になることがわかり、予算との兼ね合いで

「あと１年くらい履いて、その後はご臨終になっても良いので、とりあえず表面の黒い部分が目立たなくなるような形でお願い出来ますか？」

という形で、あとは水洗いフルコースと多少の修理という形で8000円ほどの出費をして、こんな感じに生まれ変わりました！！

お店に靴の引き取りに行った時に、

「かなりいい感じに仕上がったので、想像以上の出来映えですよー」

って言われて上記の仕上がりを見た時には、正直感動したのと、センスの良さにやられました

前からこんな感じのアンティークっぽい仕上がりの靴が欲しかったので、なんか新しい靴を手に入れた感じになってものすごくお得な気分になりました。

自分の仕事上で、前からずっとやりたかった、あるデータとデータの相関関係を調べるための手段として、今よりももう少しプログラミングのスキルを伸ばしたいなぁーと思ってて、今年の個人的な目標に加えているのですが、最近はPrototype & script.aculo.us JavaScriptライブラリによるAjaxアプリケーション開発の本と、モダンPerl入門を買って読んでいます。

Perlという良くも悪くも様々な書き方ができる柔軟な言語において、Perlの達人達の中で良しとされるノウハウについてまとめてくれており、こういう先人達の知恵をうまく活用して質の良いコードを書いて、業務を楽にしたいと思うような実際にPerlを業務で利用している人に取ってはとても役立つ本であるのは当然のことながら、個人的に読んでいて感じたのは、

• 何らかシステム管理の作業をしているけどプログラミングに苦手意識を 持ちつつどうにかそのカベを超えたい
• VBAとかPHPで単独開発をしているけど、もっとスキルアップをしたいので何か勉強をしたい

と考えている人に、この本＋初めてのPerlとセットで読み進めてみることで、自分のスキルの幅が広がるのではないでしょうか。 

自分は前職でちょっとだけプログラミング（VBScript）の経験ありますが、正直独学だし、その当時は、自分のやり方が良いのか悪いのかすらわからない状況でした。

今はキャリアカウンセラーという仕事に就いて色々な方の話を聴く立場になりましたが、昔の自分と同じような状況の人って意外といることに気付いたのと、自分との共通項で考えると、コードを書くための周辺知識が不足しているように思います。

その周辺知識の１つの例として、テストの部分において、他の言語でも同様にその重要性は書かれていますが、じゃ実際にどうやったら効率的に（というよりは気持ちよく）テストが行えるかということについては、単独開発している人だったり、すごく小さい会社だったりすると、先輩のやり方が全てみたいなことがもしかしたらあるかもしれず、この本で書かれていたような気持ちよくテストが行える仕組みってのはなかなか身に付くことが無いのではないでしょうか。

本書は当然のことながらPerlを題材にしているけれど、こういう周辺知識に該当するような事がテスト以外にもデザインパターンについての話だったり、DB処理のSQL文をどのように管理するか...というあたりの考え方については、Perlに限定しない話だと思うので、そういう部分だけつまみ食い的に読むだけでも買う価値はあるのではないでしょうか。

個人的にはPerlは前から勉強したいと思っていた反面、どうしてもPerl独特の記法に慣れず、特にPerlでのオブジェクト指向プログラミングはソース読んでいても頭の中で？？？という文字が行き交う事が多かったのですが、今回のモダンPerl入門で取り上げられていたMooseのサンプル読む限りこれだったら違和感なさそうなので、Prototype & script.aculo.us JavaScriptライブラリによるAjaxアプリケーション開発の本と交互に読み進めてみようかと思ってます。