ネガティブな日本のIT産業

日本のSI産業が疲弊しきってて人気が無いらしい。
http://d.hatena.ne.jp/itoyosuke/20071101/1193932945

常々感じているけど、たしかにITの現場では正当に技術力が評価されているような気がしない。
この業界の将来を本当に考えるなら、もう少し仕組みを考えないといけない。営業が中間搾取して、質の低いシステムを作るのが目的じゃないはず。開発者の技術力が向上し、顧客は質の高いサービスを手に入れられるようなそんなまっとうな仕組みが無いと、結局は日本が海外に負けちゃうだけな気がする。それって結局長期的には、良くない結果に終わるんじゃないだろか。

自分としては、研究開発部門こそ、うまく業界全体が幸せになるような方向、少なくとも自分達だけでもわざわざ疲弊している競合と疲弊競争へ向かわないような方向へみんなを導くことをしないといけないんじゃないかと思う。

最近のオープンな世界の話は、まさにそれを救うかもしれない新しい仕組みなんじゃないかと思う。本当に良いものを評価したり、見つけたりしやすい世の中になりつつあるんだから、同じような仕組みが企業向けに働く人たちにもうまく適用できなかどうかを考えることは、意味があると思う。そして、意味があることには、なにかついて来るはず。今すぐビジネスとして見えてこなくても、あきらめずに続けることで大きなリターンがきっとあるはず。

明日からもがんばろうっと。

研究開発とアウトソーシングとLL

変化のスピードがやたら速い今日この頃、ソフトウェア研究開発において、世の中ざっくり２つのアプローチで乗り切ろうとしてるのかなと思う。

1. 安いところにアウトソーシング
2. 変化に対応できるような高速軽量開発

アウトソーシングによるコスト削減と、研究所内でLL開発のチームを作ってどんどん生産性を挙げるという２つのアプローチがありえる。

『アウトソーシング＋管理コスト』　ｖｓ　『LL開発のチームの醸成』

という構図。最近、ソフトウェア開発においてこの力関係に変化がおきてるのは、あちこちで言われてる。
まさに研究開発アウトソーシングの真っ只中にいるので、とりあえずもう少し深く考察してみる。

研究よりのアウトソーシングの場合、一番大変なのが、研究機関の利益と委託もとの会社の利益が異なること。
会社のいろいろなしがらみを委託先の研究機関に理解してもらうことは、非常に難しい。
会社の事情を理解した上でのビジネスの芽と研究機関の研究成果の違いは大きい。
管理担当者は、会社という顧客とその先のエンドユーザ（たぶん）を見据えてアウトソーシング先をマネージメントしないといけない。（理想的には）
結局、根気よくコミュニケーションを続けつつ、うまくwin-win-winな解へ収束させていくしかないわけです。（妥協ともいう）
あと、ソフトウェアハウスへの開発委託と違って、研究委託の場合は会社の利益に結びつくようなコアの創造を求めるわけで、一段要求が高い。
なので、創造性を阻害しないように注意しながら、会社の事情を知った人がうまくコントロールする必要がある。

人件費の視点でよい組み合わせとしては、

• 比較的大きめなプロジェクト：　比較的成熟した実績のある研究機関＋比較的大規模なプロジェクトをまわせて会社の事情を理解したコミュニケーション能力の高いマネージャ
• コアに絞った小規模：　超トップクラスの研究者＋会社の事情を理解した専門家（＋|兼）マネージャ

ということで、管理コストを数で薄めるか、超トップクラスを求めるか。ちなみに、前者は、一度に大量の投資をするといい人もアサインされやすいという特典がついている。
前者は、少しでも安い人件費のお手ごろな研究機関がいいだろうし、後者はターゲットが明確ならその分野の世界トップレベルの研究者（？）を捕まえるのがいいかもしれない。
ただ、ここにも一つ落とし穴があると思う。研究機関は基本的に広さより深さを求める傾向がある。なので、平気で４年くらい前の技術を使ってたりする。
寿命の長い要素技術研究の場合は、まぁ許容範囲かもしれないが、流行に左右されやすいアプリケーション研究の場合は致命傷になりかねない。
2年とかで大きく変化するソフトウェア業界特有の状況を考慮して、そのあたりに振り回されないようなところをうまく委託しないといけない。
何がしたいかを十分吟味した上で、適切なところを適切な予算を組んであたらないといけない気がする。

んで、2年で変化するようなものを扱う場合はどうすればいいか？
コアを持つベンチャーと組むのはありだと思う。もちろん、ベンチャーの利益を理解したうえで、win-win関係を構築する必要があって、うちみたいな研究所の場合、実は非常に難しいと思う。

というわけで、LLプロト開発ができるチームを自部署内作るのはありだと思われ。会社の事情はある程度分かってもらえているし、技術の蓄積にもなるし、そのスピード自体がコアになるかもしれない。
いまどき、それなりに使えるレベルのプロトがあっちゅう間にできちゃうのは、RoRあたりを体験した人は分かると思うけど、昔に比べると明らかにすごいコスト削減効果があると思う。なにより楽しいし。＾＾
お客さんに近いソリューション研究とかアプリケーション研究あたりには、特に効果的な気がする。まわせるサイクル数が違うし。

まとめ
まとめると、こんな感じか。
長期、大規模、比較的流行に左右されない先進的なもの、いきなりパラダイムシフトを狙う
『アウトソーシング＋管理コスト』　～　『LL開発のチームの醸成』

短期、小規模、流行に左右されやすい、お客様に近い、継続的なサービス提供によるイノベーション狙い
『アウトソーシング＋管理コスト』　＜　『LL開発のチームの醸成』

ただ、ソフトウェア研究において、長期というのがどれほどあるのかは疑問。
ただ、異なる組織で異なる価値観に触れるとそこから生まれるものがあるかもしれない。
コミュニケーションを根気強く続けないとそのあたりの価値観の違いまで見えてこないかもしれないと思えば、アウトソーシングとか共同研究というのもいいかもしれない。
そのときにすぐに結果が出なくても、将来的にいろんな価値観に触れたことで生み出される可能性もあるし。
ああ、でもそのあたりもWebの発達のおかげで、安価で出来るようになってるのか。
きっと、あと3年もするとこの傾向は加速的に高まるかもしれない。

変化に強い何かを見つけるか、イノベーション生成機としてアイデアをすぐ実現する力を身につけるか。
難しい世の中だと思う。

へたな研修より転職面接

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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