Think Big, Make Simple, Move Fast

なんで、日本人は中級レベルの英語も話せないのに、大学卒業できちゃうの？

2009-01-16T01:08:00.008+09:00

「なんで、日本人は中級レベルの英語も話せないのに、大学卒業できちゃうの？」

これは、最近こっちハンガリーの研究所の同僚に言われた言葉です。

はてさて、ハンガリーに駐在してぼちぼち1年半がすぎ、周りは全員ハンガリー人とはいえ、仕事は英語なわけなので、さすがに来た当初にくらべるとなんとかコミュニケーションはとれるようになっては来ました。

が、当初思ってたように1年半もいればペラペラ話せるようになるだろうという幻想は余裕で打ち砕かれ、やっぱり留学した気でまじめにそろそろ勉強しないと、せっかくの環境がもったいないかも、と思い始めました。ちなみに、英語が苦手な日本人として扱ってもらわないととても会話になりません。ハンガリー人も英語は苦手な人たちなんですが。。

というわけで、はじめてTOEFLなるものを受けてみることにしました。勉強なしで初見でトライして、ショックを受けてから勉強して点数を上げていくという戦略。
いや、TOEFLはすごいですね。難しいですが、すごい実践的です。聞けて読んで整理して話すみたいなテストで、実際に仕事を遂行したりするには、TOEICよりこっちのテストで高得点を取れるようにしたほうが確実にいいと思いました。というか、会社も駐在させる前に、このテストで80点以上とかを基準にしたほうがいいのでわと思った次第です。。。

駐在を始めた頃には、うちの会社ではそれなりに高いほうだったので、一人で駐在してもなんとかなるのではと思っていたんですが、いや、甘かった。駐在先が日本人が何人もいて、直接英語を使うことがクリティカルじゃない場合には、とりあえずよかったのかもしれないですが、交渉ごともする必要があるとなると、TOEICに特化した勉強をしててもさっぱり通用しないんで困ったもんだ。

なんて、話をハンガリーの研究所のメンバーとしていたら、
「なんで、日本人は中級レベルの英語も話せないのに、大学卒業できちゃうの？」
って言われました。。たしかに、スーパーのレジのおばちゃんは英語話せないけど、研究所の連中はみんな話せます。（レベルはまちまちだと思うのですが、私から見るとはるかにペラペラ。）

ちなみに、中級レベルの英語といっても、みんなペラペラです。演劇とか映画にでてくるようなネイティブのイカした英語じゃないってことです。（たぶん。そこまで達していないので、自信はないですが。。）

やっぱり、もうちょっと大学卒業っていう資格に意味を持たせたほうがいいのかもしれないなぁという気がしました。どれくらいの国がそうなのかは不明ですが、ハンガリーの場合は、大学は高等教育という意味で、出来る人をさらに鍛える場として設けられているようですが、日本の場合は、そのあり方があいまいになっている気がします。少なくとも、自分はそうでした。ただ、自分の成績で入れる良さそうな大学で、比較的好きな科目を勉強する場所。受験は大変だったけど、終わったから、しばらく我慢してたことを目一杯やって羽を伸ばそうとか。
周りをみても、感覚的には、将来の目標を持って何かを目指していた人は２０％くらいで、半分近くは同じような感じだったと思います。（残りの３０％はしりません。）

おそらく英語を中級クラスで話せるようになるためには、高校卒業時に英語が得意な人でも、適度なペースで勉強する場合３～４年くらいはトレーニングを積む必要があると思うので、だ大学でちゃんと課題として課せば、なんとか大学在籍期間でおさまります。まぁ、日本人は内需だけで結構やっていけましたし、海外人員でなければ必要がないような仕組みになっているのかもしれないですが、今後、本当にグローバル化が進む前に少しでも手を打っておいたほうがいいような気もしたこの頃です。

ちなみに、ハンガリーはテレビ番組なども少ないし、英語が分かるとまわりの国の番組も楽しめるということで小さい頃から日常的に生の英語に触れる機会も多いようです。（最近は、日本のアニメも人気なので、日本語も結構人気みたいです。）

とはいえ、まぁ、日本語は英語と文法的にも離れてるし、音的にも聞けないし発音できないものが多いので、トレーニングが大変だっていうのもあり、一概にヨーロッパみたいにしようぜ！！とは言えないのかもしれないですが。

SAKURA にgit をインストール、しかし上手くSAKURA更新できない

2008-08-11T09:23:00.014+09:00

だいぶまえからローカルのMACBOOKでは、subversionからgitに移行してたんですが、ぼちぼちgitの恩恵にあずかるべく他のPCでも分散開発したいなということで、借り殺ししているSAKURAのサーバにgitを導入してみました。

サクラのレンタルサーバーでgitを使うを参考にインストール。

サーバへのインストールと動作確認

% wget http://kernel.org/pub/software/scm/git/git-1.5.5.6.tar.bz2
% tar -xjvf git-1.5.5.6.tar.bz2
% cd git-1.5.5.6
% ./configure --prefix=$HOME/local
% gmake 
% gmake install
% cd 
% mkdir ~/work/app.git
% cd ~/work.git
% git init

とりあえず、gmakeで一発でさくっとインストール成功。
ローカルですでに作成済みのプロジェクトをインポートするため受け入れようのからプロジェクトを作っときました。ちなみに、$HOME/local/binにpathが通ってる必要があります。

ローカルのプロジェクトをpush

%cd ~/work/app.git
%git remote add origin ssh://yourname@hoge.sakura.ne.jp/home/yourname/work/app.git
%git push origin master

という感じで、remoteを設定してSAKURA側へpush。
ここまではいい感じです。

しかっし、サーバ側で更新を確認してみると。。。

%git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
# deleted:    README
# deleted:    Rakefile
# deleted:    Rakefile~
# deleted:    app/controllers/application.rb
# deleted:    app/controllers/application.rb~
# deleted:    app/controllers/pages_controller.rb
# deleted:    app/controllers/pages_controller.rb~
# deleted:    app/controllers/slides_controller.rb
# deleted:    app/controllers/slides_controller.rb~
# deleted:    app/helpers/application_helper.rb
# deleted:    app/helpers/application_helper.rb~
# deleted:    app/helpers/pages_helper.rb
# deleted:    app/helpers/slides_helper.rb

みたいな感じでdeleteの嵐。ディレクトリを確認してみると確かに更新されてない。でも、git logでは、正常にcommitログが更新されている様子。
どうやら、git initした直後のような変更を加えたように誤認されている様子。ハンガリーのMACBOOKから日本のSAKURAにpushしたから？
とりあえず原因は不明なわけですが、対策は簡単。

ローカルからpushした状態にもどす

%git reset --hard HEAD
HEAD is now at a0d75fc for sure

とすると無事にローカル側でコミットした状態にもどせます。しかし、現状、毎回これしないといけないのがめんどくさい。gitの使い方間違えているんだろうか？
もう少しまじめに勉強しないといけないっすね。

技術力の進歩は、世の中に真の平和を生み出すか？

2008-08-09T05:14:00.004+09:00

いろいろなWeb上でいろいろなサービスを無料で利用でき、情報はものすごく安く手に入るようになってきたけど、そのうちあらゆる物が無料で手に入るような方向に進んでいくのだろうか？

"a world's clearly a better place. individuals can now do things that only large groups of people with lots of money could do before -- Steve Jobs"

大昔、自然からの恵みを享受してきた僕たちだけど、いつかお互いが助け合いそれを享受しあうような社会になっていくのかもしれない。と、「ウェブ時代の５つの定理」のなかのスティーブジョブズの言葉を読んで思った。

物の価値の偏り、貧富の差、世の中は偏ってるけど、それは、物の価値の局所的な偏りをうまく利益に結びつけることによって得た偏りなんだと思う。もし、世の中が本当にフラットになったときに、その偏りはどんどん得にくくなって、利益の分配もフラットになっていくのだろうか？

現状は、世の中がフラットになる過程で急速に流れたマスの流れをつかんだ人たちが莫大な利益を得ているわけで、偏りはより大きくなってる。その利益に群がる形で、フラット化の波はきっと進んでいくんだろうと思う。その次は何が起こるだろう？フラット化してお互いが与えあう基盤が確立すれば、フラット化の基盤を押さえた者とその他のお互いに与えあうものの２つに収束していくのかもしれない。

とはいえ、たとえばエネルギーが無料になるためには、イノベーションがまだまだ必要なわけで、きっとあらゆるものがフラット化するためにはあらゆる分野においてイノベーションがまだまだ必要なんだろう。そして、フラット化を阻む既得権益者とも戦わなきゃ行けないだろう。でも、そのフラット化が人々に取って幸せをもたらすものなら、きっとその方向に進んでいく力は止まらない。そこに技術があれば。ミクロに見れば、同じように膨らむマスから利益を得ることができるからかもしれないけど。

ITは、情報流通、コミュニケーションという面でフラット化を進めたのかもしれない。本来人間の人間たるゆえんは、情報処理能力の高さであって、その力をさらに飛躍的に向上させるという点でITは進むべくして進歩して来たんだと思う。ただ、この情報のフラット化の先にはなにがあるんだろう。単に便利になった世の中と基盤をもつ企業が安定して存在するのだろうか。

ITだけじゃなくその他の分野でもフラット化を目指すといいのかなと言う気はしてきた。そこに次の大きなチャンスはあるのかもしれない。結局世の中の幸せを追求することが、大きな何かにつながるのかもしれない。

TODO管理とメモと同期：howm

2008-06-02T09:32:00.004+09:00

最近のハマりものは、howmっていうメモ＋TODO管理用のemacsアプリなんですが、
これが、自分の好みにバッチリ。（いまさらかしら。）

仕事上のPCと私生活用のPCが別だけどTODOとメモを共有したいなぁと思ってたわけですが、
Gmailを使ったり、RememberTheMilk(RTM)使ったり、GoogleNote使ったり、ブログ使ったり、いろいろ試してきたわけですが、なんかいまいちしっくり来なかったところ、ついに見つけたって感じです。

詳細はまた書きますが、unisonっていう同期ソフトを使って、職場のXPと自宅のMac Bookと外部の私用サーバで同期して使ってます。（こちらを参考に構築）いま一ヶ月くらいになりますが、かなり上手く回ってる感じ。

よいところは、
+ いつも開いてるemacsからラグなしで使える。
+ メモ中に思いついたら、そのまま自然言語でTODOが書ける。
+ 一つのメモに複数のTODOが書ける。
+ 適当に書いたTODOもあとでメニューでちゃんと適切に管理できる。
+ 締め切り、予定、覚え書き、TODOなんかの優先度をつけると、あとで一覧時の並び方が絶妙。
+ メモ間のリンクも超簡単に貼れる。
いまいちなところは、
- 操作を覚えるのに、２時間くらいかかる。
- emacs環境ないと使えない。
- メニューがちょっとごちゃごちゃしてるので、カスタマイズ必要。
くらいでしょか。まぁ、emacsだからしょうがないか。

書き散らしタイプの私にはかなり良い感じ。思いついたら、Todoに落として、さっさと頭から追い出して仕事に集中できるのがいいところかもしれない。

あとは、携帯から使えれば最強だな。

beautiful and original product designs

2008-05-31T03:04:00.002+09:00

beautiful-and-original-product-designsという記事を見た。これすごいね。クリエイティビティを刺激された。
なんか仕事を管理するだけのつまらないシステムを作っていてはだめだ。

これを見ると、数年後にはマルチタッチのマウスレスな新しい操作デバイスが本当にトレンドになってきそうな予感がする。世の中は、そうしたいと本当に思う人が多くなればなるほど、その方向に向かうから面白い。

あと、ピーナツバターのジャーなんかも感動した。

とりあえず思ったのは、もっと、おもしろいわくわくするようなものを作らないと！！ってことです。

enjoy life and work!!

Engneer vs Manager

2008-05-30T23:37:00.003+09:00

これ笑った。
http://www.poeticexpressions.co.uk/POEMS/Engineer%20v%20Manager.htm

しかし、マネジャーも大変なんだと思うけど、結果的に本末転倒になることが多いのかも。

熊とワルツをを読んだ

2008-01-30T05:04:00.001+09:00

最近、プロジェクト管理本にはまっている。
というのも、なんとかアジャイルな感じでプロジェクト管理ができないかなぁと思っている訳で、
まずは、世の中の最近の常識をサーベイしようと言う試みだったりする。

今の部署では、リスク管理とかスケジュールのバッファとかが完全に個人のノウハウとして使われているので、その上のマネージャからは見えていない。マネージャ側から見ても、人によってどれくらいバッファをとるかを知った上でマネージメントしているという具合。

今後、プロジェクトをもっと定量的に分析したり、振り返ったりするならもう少しちゃんと管理しないと度しようもない。プロジェクト管理を個人のノウハウのかたまりにしていては、いつまでたっても安定しないし、人間依存になってしまう。

というわけで、熊とワルツ。
まずは、リスク管理とバッファの取り方をある程度根拠に基づいて示しましょうということをわかりやすく説いている良書だと思う。もし、部署のマネージャがリスク管理って何？そんなのいいからやれ！という方、ぜひ読んでもらったらいいと思う。読みやすいから、どんな人でも１週間もあれば十分かな。

しかし、リスクを見積もるにも、ある程度似たようなデータがないとうまくいかない。開発チームならいいけど、研究部門の場合は結構むずかしいかもしれない。

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

2007-11-06T07:20:00.000+09:00

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

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

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

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

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

2007-08-08T09:32:00.000+09:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

へたな研修より転職面接

2007-07-26T03:19:00.000+09:00

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

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

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

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

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

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

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

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

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

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

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

2007-07-23T04:58:00.000+09:00

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

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

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

2007-07-22T10:56:00.000+09:00

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

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

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

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

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

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

2007-07-12T17:58:00.000+09:00

テスト
テスト