Hatena::ブログ(Diary)

TECH-moratorium : テクモラトリアム このページをアンテナに追加 RSSフィード

2008-12-28

[]ダイアリーで振り返る2008年

はやいもので、2008年も終わろうとしています。

今年は例年以上に色々なイベントに参加し、たくさんの人と交流することができました。そして例年以上、色々な経験から学ぶことができた1年でした。

こんな充実した1年を、ダイアリーを読み返すことで振り返ってみます。

管理職としての1年

今年は、エンジニアというより、管理職としての自分を意識したエントリが多かったです。もちろん、今でもこれからもエンジニアではありますが、私が「今一番すべきこと」に関する話題が多くなっていますね。

面談と35歳定年説

http://d.hatena.ne.jp/HappymanOkajima/20080301/1204429019

「不機嫌」というメッセージ 『不機嫌な職場〜なぜ社員同士で協力できないのか』を読んで

http://d.hatena.ne.jp/HappymanOkajima/20080522/1211468343

35歳で定年を迎えて学んだ5つのこと

http://d.hatena.ne.jp/HappymanOkajima/20080903/1220445957

『受託開発の極意』 執筆の1年

そして、課外活動で一番大きいのは『受託開発の極意』の出版です。2007年の秋から執筆を開始し、2008年の春に出版されました。執筆はかなりしんどかったですが、おかげさまで、なかなかの売り上げと、いろいろなフィードバック、そして何より、これをきっかけとした様々な出会いがありました。本当にありがたいことです。

そして、今もいくつかネタを仕込んでいます。来年も今年以上に課外活動に力を入れる予定ですから、ご期待ください!

『受託開発の極意』amazonで予約開始!

http://d.hatena.ne.jp/HappymanOkajima/20080325/1206413781

増刷御礼!『受託開発の極意』

http://d.hatena.ne.jp/HappymanOkajima/20080606/1212727268

ディベートから花見まで。イベントの1年

2月のO-Oneディベートを皮切りに、いろんなイベントに参加し、話をさせていただきました。どれも楽しく印象深いのですが、一番緊張したのは日経コンピュータフォーラムです。人にちゃんと伝えることのむずかしさと素晴らしさを再認識できました。

ディベートプロレスだ!

http://d.hatena.ne.jp/HappymanOkajima/20080214/1202921485

お花見勉強会大阪

http://d.hatena.ne.jp/HappymanOkajima/20080414/1208166654

『受託開発の極意』刊行記念トークショー

http://d.hatena.ne.jp/HappymanOkajima/20080502/1209712020

7月1日オブジェクト倶楽部夏イベント

http://d.hatena.ne.jp/HappymanOkajima/20080605/1212677969

日経コンピュータフォーラム2008で講演しました

http://d.hatena.ne.jp/HappymanOkajima/20081108/1226103059

オブラブ忘年会2008

http://d.hatena.ne.jp/HappymanOkajima/20081210/1228836255

今年もお世話になりました

今年もTECH-moratoriumを読んでいただき、ありがとうございました。来年もよろしくお願いします。

2008-03-01

[][]面談と35歳定年説

私も現在、面談期間中です。

面談の良いところは、個人個人の問題について深く考える機会があることだ。

3ヶ月面談 - jkondoの日記

数年前までは、自分の問題だけ考えて生きていました。しかし面談をする立場になった今、メンバー達の問題をいっしょに考えるのが私の役割です。

面談の悪いところは、この期間中話を続けていると、どんどん視点が会社の社内に向いていってしまうことだ。あれこれ話をすれば、社内の課題なども見えてくるし、見えてきたものに対して対処をしなくてはいけないと思う。

3ヶ月面談 - jkondoの日記

こちらの話にも共感します。面談をする管理職は内向き(社内の視点)の課題を、外向き(お客さま視点)の課題に変換してやらなくてはいけませんが、私はまだそれが十分できていません。母性的な組織運営に偏りすぎなのかもしれません。(一年前はひとごとのように書いていたのですが)

逆に、組織に分かりやすく納得できる経営ビジョンがある時は「俺について来い」状態となり、父性的・狩猟的な「狩の獲物は皆で山分け」戦略が取れる。

どちらが良い悪いではなくて、中小SI企業は母性的な性格になりやすくなるんじゃないか、と考えていて、だとすればそのような組織で働く人間の行動も以下のようになると思われる。

1. 父親になろうとする。つまり、自分でビジョンを描き出し、組織から次第に距離を置きたがる。

2. 子供のままでいようとする。つまり、モラトリアム

ただし、母親の後を継ごうとする人は少ないだろう。母親とは組織(実際にはその組織を構成する管理職群)そのものであり、すでにたくさん存在するからだ。

母性的な中小SIer? - TECH-moratorium : テクモラトリアム

今回の面談で気がついた自分の一番の課題は、「自分は母親でなくてはいけない」という思い込みが、自分に迷いというか、中途半端さをもたらしているところにあります。

面談を振り返ってみると、なんだかんだ私がメンバーに期待するのは「父親的」な行動と自立です。つまり、成長し自分のキャラを確立することで自己実現をし、その力で会社に貢献して欲しいと思う。

そんな自分はやっぱり「母親的」です。自分が父親になろうとする意欲とインセンティブが弱まっている。組織に貢献することで満たされる欲求と得られる対価が、自分の成長欲求を上回ったと感じられるポイントがある。

これが「35歳定年説」なのかもしれません。そして、この境地を自分の成長の飽和点だと感じ、さらに悦に入ったとき、エンジニアとしては終わってしまうのでしょう。

気をつけることにします。

2007-04-22

[][][]JavaからRubyへ

JavaからRubyへ ―マネージャのための実践移行ガイド

JavaからRubyへ ―マネージャのための実践移行ガイド

思えば角谷さんと最後に仕事をしたのは3年前になる。あの時ほどJava(EJB+XML)の非本質的複雑さに悩まされたことはない。WebSphereの設定にハマリまくって、「今日本にMartin Fowlerが来てるので今日はもう帰っていいですか?」と角谷さんに聞かれたのも記憶に新しい。(念のため、もちろんOKしましたよw)そんな角谷さんがこの本を訳すのは運命だったに違いない。

今のぼくは一括Web案件に携わることが多く、主にJavaを採用している。軽量コンテナ(Seasar2)と、高機能IDE、豊富なCPUとメモリパワーを使うので、技術リスクはほとんど感じていない。(もちろん、3年前に初めて自社でS2を採用するに当たってはリスクを取りましたよ)

そんな状況で現場リーダーやプロマネをしてると、プロジェクトのリスクを言語やプラットフォームではなく、コミュニケーションやプロセス、政治などに求めがちになる。

しかし、この本を読んでると、生産性の高さ(やりたいことをより短いコード量、時間で実現する)は根本的なパワーだということに改めて気がつかされる。「生産性が高けりゃ、人が少なくてすむのでコミュニケーションがシンプルになる」当たり前の話なんだけど、最近は上流に意識が行き過ぎて注意を払えてなかった。

Rubyは、プログラミングが楽しいという。ツールのインストール方法や設定ファイルの書き方覚えるより、ビジネスそのものを表現するコードの書き方を覚えるほうが楽しいし、効率がいいに決まってる。

JavaからRubyへ、この本は私のようにコードを書かなくなりつつあるリーダー・マネージャにこそ読んで欲しい。組織にどのようにRubyを取り込むかといった政治的な戦略にまで触れているのが素敵だ。参考になる。

だけど本当に重要なのはRubyは10年に一度やってくる大きな波だということに気がつくこと。そして、今度の波は今までのより楽しそうだ、ということ。Rubyなら、バージョンを重ねるごとに遅くなるEclipseの起動時間を待つ間に真っ白なエディタにコードを書き始める気持ちよさが味わえるに違いない。

なにやら、ぼくのプログラマ感覚の残滓に訴えかけるのだ。

ビッグウェーブに見事に飛び乗った角谷さんに軽いうらやましさを覚えつつ、GoodJobと言いたい!

久しぶりに伝家の宝刀抜きたくなったよ。いや、ホントに。

2006-07-13

[]「やりたいこと」、と「やらなくちゃいけないこと」

技術ディベートコミュニティ、Object-1でご縁があり、ぼくの知り合いの中でもっとも頻繁にラーメンを食される、「大企業でベンチャ担当として働いていた者」さんのブログより。

http://www.doblog.com/weblog/myblog/46470/2616199#2616199

「やりたいこと」を1ヶ月か2ヶ月先に置いて、「やらなきゃいけないこと」は、「やれること」の中でやりくりしてこなしてしまい、日々「やれること」の範囲を拡げようと意識する。

ぼくも心の片隅では、「やりたいことを意識しなくちゃいけないよなぁ。」とは思ってはいるものの、具体的に1ヶ月とか2ヶ月先を意識することを忘れる日々でして、この一言にハッとさせられました。TODOリストは、やらなくちゃいけないことリストであって、そこには「やりたいこと」は自然と出てこなくなるんだよなぁ。スケジュールが埋まることで安心しかけてた自分に反省。次の一手は「やりたいこと」ベースで考えなくちゃ。

2006-06-27

[]AJAXとの付き合い方

確かにAJAXは技術者(特にプログラマ)としては面白いと思う。ぼくも含めてずっと前からWebをやってる人達にとっては、自前でFRAMEなどを使って実現してきた機能(というよりはブラウザを使った非同期通信という仕組み)がやっと大手を振って使えるようになったという感覚なんだろうな。

でも、中島さんも次のように書かれている通り、AJAXという技術自体はビジネス面から(特にSIというビジネス領域において)「コミットする」という意味あいのスケールではないと感じる。ユーザーの視点で考えてもAJAXでぼくたちの住む世界が大きく変わるとも思えないし、開発者の視点に立ったとしても、「これからはAJAXだけで食っていける!」という勘違いすら起こせない。

社会心理学では、そんな心理状態を「多元的無知」と呼ぶが、そんな時に遠慮せずに、自身を持って「AJAXって本当に必要なの?」と問いかける姿勢はとても大切である。

 ちなみに、上の質問に対する私の答えは「たぶん無いでしょう。アマゾンがAJAX化しないのは理由があると思います。AJAX化したとしても売り上げが上がるとは私には思えません」である。

http://blog.japan.cnet.com/nakajima/archives/002943.html

また、このように「速くて、軽い」技術をプロジェクトに適用する場合は、取り入れ方のバランスが肝要だと感じる。つまり単純には、既存の技術で書いたコードの量と、新しい技術で書いたコードの量だ。AJAXの場合は、JavaScriptのコード量がかなり増大することになるが、それがプロジェクトの性質、特にメンバーのスキルやマインドセットとマッチするかどうかを判断材料にすべきだと思う。誰も彼もが最新技術LOVEな人ではないが、かといっていつまでも古い技術にしがみつくのも問題だ。

理想的には、新しい技術を適用するプロジェクトでは、重要な(その技術がないと実現できない)ユースケース(や画面)でのみ採用すると良いと思う。業務系のWebアプリの場合、1画面くらいはお客さまのこだわりの強い「キラー画面」があるもので、そのような機能にのみ集中してAJAXを適用することで、お客さま価値(この場合は使い勝手)の向上を実現する。そして、次に適用するプロジェクトでは、前回プロジェクトの評価を踏まえながら新技術を全面的に採用し、生産性の向上を図る。このような順序を踏まえればバランスが良く、失敗することは少ないと思う。