へたな研修より転職面接

数年前に社会勉強のために、おためし転職面接をしたことがあるっす。

たまたま機会があったので、とりあえず経験して損は無いかなと思って中途採用面接に行ってきました。こういうことって書かないべきなのかな？あえて書いちゃいます。でも、むしろ本当にキャリアに関する意識を高めるつもりなら、社内基準で考えろって言われてもピンと来ないような・・・。

ほんで、結果から言うと、やっぱり経験してみるのが一番いい。そのへんの研修よりいいのでは？市場価値という広い観点で自分の経歴やアピールできるスキル（もちろん技術だけじゃない）を本気で振り返る羽目になるので。あと、今回は会社の分析と技術的な調査もかぶっていたので１石２鳥でした。

今、面接での質問の内容を振り返ってみると、
・即戦力を求めているというよりは、仕事を高い品質でやり遂げるための資質があるか？たぶん、若手だからかな？マネージャクラスのキャリアアップに求められるものを考えると空恐ろしい。ガクブル。
・仕事において常にゴールとポイントと解決方法を意識して取り組んでいるか？
・頭の反射神経があるか？
・答えの無い問題でも、仮説を立てて論理的に解決策を提案ができるか？
などなどを確かめたかったんだと思われます。さすが、いい面接だわ。

そもそも今まで携わってきたプロジェクトに関して、
・自分なりにどういうゴールを設定して
・どの部分が成功のための鍵になる部分で、
・そのためにどういう解決策を取ってきたのか、
をちゃんと考えながら進めたり振り返ったりしたことが無かったので、それらのポイントを明確に整理して説明しなかったなぁと反省。質問を文字通り受け取って、文字通り回答しちゃってた。天然だわ。

技術や英語は、解決策の一つでしかないし、差別化項目でしかない。もちろん、解決策の正確さを高めたり、幅を広げるために必要なので、そこは戦略的に徐々に伸ばしていくとして、それに関しては時代の流れと運と嗜好によるのでまぁそれはそれ。
今回の教訓として一番大きかったのは、ベースの部分がやっぱり大事で、仕事への取り組み方みたいなものをもっと意識的に明確にする必要があるなぁということ。
あと、難しい仕事をしないと”やり遂げる能力”みたいなものは伸ばせない。英語に関しても同じ。本当にnativeの人とディスカッションできるかなんて、やってみて恥かかないとそこまで行こうとも思わない。実際、英語能力で何をアピールすればいいのか分からなかった。外資系の会社で、なんとかしゃべれます！じゃ、なんのアピールにもならないことを痛感。技術面と一緒で現状中途半端。

たぶん、就職活動の頃もいろいろ考えていたような気がするけど、5年も経つと忘れちゃうんでしょうね。人は悲しいほど忘れる生き物だから。そう考えると、他にも大事な能力の一部が退化してて、それに気づいていない可能性があると思う。大きな会社だから、あんまり考えなくていい部分は考えないことに慣れてしまって、その能力を退化させてしまう。それでいい時代もあったかもしれないけど、変化が激しい時代に適応しすぎることは、危険を伴うかも。技術職は文系職と違って、技術に逃げ込めるところが成長を阻害しているのかも。

完全にじっくり開発する部署なら深いスキル自体が身に付くのでいいかもしれない。けど、研究部門にいる限り、実開発が少ないから開発力も中途半端なまま。意識してベース能力を伸ばさないといかんですよ、こりゃ。思うに意識すれば伸ばせる部分だし、あたりまえっぽいだけに意識しないと伸びない部分でもある気がします。

あと、他の会社もあるんだなと思えれば、本当に意味があると思える仕事をしようというモチベーションにつながるはず。局所解にはまりたくない。

でも、こういうことを考える機会があるのも、周りの人たちの影響なんでしょう。一度しかない人生なので、それなりに楽しんで死にたいと思います。

研究アウトソーシングを考える

研究のアウトソーシングって何なんだろうか。
会社の興味や方向性をアウトソーシング先に理解してもらうのは難しい。
じゃあ、適当に研究機関の興味の向くままやってもらっていいわけではないので、
当然なんだか要求を出すわけです。
ほっとくとびっくりするほど中途半端なものができることがある。
もちろん、研究的には意味があるんだろうけど、その先のことまで考えるとどうした門だろうと思うことが多い。結局は、そこからうまく役に立つようなところを抽出しないといけない。
つまりは、結局コミュニケーションなんだろうなぁ。

難しいのは、その研究成果を実際の事業なりなんなりにするときなんだけど、
プロジェクトの規模や求められることが一気に変わるので、それなりのリソースを割り当ててもらわないとはまること間違いなし。当然、アウトソースばっかりやってる今日この頃、ドーナツ化現象により引き取れる人材もそんなに多くない。ほんとにアウトソーシングって、日本の企業に向いている手法なんだろうか。と最近思う。

プロジェクト運営スタイルのむずかしさを考える

プロジェクト運営スタイルのむずかしさ

最近感じるのは、プロジェクトの運営スタイルがいろいろあって難しいということ。
１、小規模システム、プロト開発、メンバーが十分コミュニケーションがとれる状況
２、大規模開発、超絶品質が求められ、メンバー間のコミュニケーションが簡単じゃないような状況
３、サービスをβ版として開発、とにかく柔軟性とスピードが求められる。
それぞれ採用するプロジェクトマネージメントが違いますよね。たぶん。

２は、ＰＩＭＢＯＫみたいなＳＥ業界ではやりのきっちりとした管理が必要かもしれない。
アジャイルでＬＬな開発は、１とか３に向いているかもしれない。
特に、最近は、Railsとかスクリプト言語、フレームワークの充実、ＯＳＳやらでライブラリの充実、さらに使い方までネットに情報がころがってるということで、
システム開発のスピードはアップしていて、昔より少人数で開発できちゃう範囲が広がっている。
しかも、人数がすくないとしがらみが少ないので柔軟性が高まるし、コミュニケーション効率も高いので、いろんなリスクを減らしつつクールなのものができる可能性が高い。
もちろん、その人数で開発できるものという絶対的な制限があるし、どうしても品質チェックのリソースが足りなくなってしまう。
なので、売り切りシステムを出すのは結構怖い。バグ対応で全国行脚するはめになるから。
というわけで、少人数だとサービスとして出すのは非常にリーズナブル。

逆に、基幹系システムとか売り切りシステムだとか、規模の大きいシステムになると、いくらチームを適切に分けても、チーム間のコミュニケーションやらなんやらが一番のネックになってしまうのはしょうがない。というわけで、きっちり管理するプロセスが必要になってくるわけです。とはいえ、なんだかきっちり管理されていると、モチベーションの維持はそれなりに手段が必要だと思う。自分のやりたいこととマッチしているうちはいいけど、どうしても分業が進むと楽しくない仕事に割り当てられる人がでてくるのは否めない。

枠はきっちり管理するけど、それぞれのサブチームのなかみはＬＬな感じでうまくやっていけたらいいんだろうけどな。
なんかそんなうまい話はないだろか？

あと、思ったけど研究所だと、比較的少人数でプロト開発ってパターンがおおい。
うまく進むと、そこから、
・自分たちで大規模に商品レベルのソフトを開発する場合。
・自分たちはコンサルとか、小さなモジュールを担当して、メインは事業部が作る場合。
・自分たちで、小さな商品レベルのものを作る場合。
・自分たちでSaaSみたいなサービスをつくる場合（たぶん、そのうち）
に分岐するわけだけど、まず、それぞれに合ったプロジェクトマネージメントを考える必要がある。
次に、そのマネージメント方法がちゃんとメンバーに浸透しないといけない。
みんながいろんな種類のプロジェクト管理の経験があるわけじゃないし、とくに研究所の場合は、大規模開発とかなかなか機会がない。
そうなると、慣れないもんだから、いろいろうまくいかない可能性があって、だからっていい方法があるわけじゃないからがんばるしかない。
大事なのは、プロジェクトの進め方はいろいろあって、過去の経験がすべてに適用できるわけじゃないってことを知っていることなのかもしれない。
フレームワークの進化とか、ハードの性能アップとか、ブロードバンド化とか、どんどん変わってるってことを認識しないといけないなぁと思う。
今は、経験が浅いうちは、いろんな変化への感度が高くいられるけど、これから先も忘れずにやっていけるのかがちょっと心配。
技術の前線でプログラムを書いたりシステムを作ったりしてれば、その辺の感覚が分かるかもしれないけど、そういう機会が少なくなっていた時に忘れたり、ずれたりしちゃいそうだ。
やっぱり、少しでも技術に触れることを心掛けないといけないなと思う。なんか比較的変化に強いコアがあればいいんだけど、どちらかというとインテグレーションとかプラットフォームよりなことをしているから、置いて行かれるわけにはいかないよなぁ。