今日は事あってid:higayasuoさんの奥様とお会いすることができました。お忙しい中本当にありがとうございました。豊洲駅の温野菜で、普段の仕事内容から知られざる（？）夫婦生活まで聞かせて頂きました。すみません。おわびにカピバラさんの写真を貼ります。

もふっとカピバラさんぬいぐるみ A カピバラさん

• 出版社/メーカー: バンプレスト
• 発売日: 2007/03/26
• メディア: おもちゃ＆ホビー
• 購入: 2人 クリック: 8回
• この商品を含むブログ (2件) を見る

最も重要なことを一つ書いておくと、印象的な質問は会社内での立ち位置でした。システム開発（SI）で売上が立つのに対して、プロダクト開発はコストセンタと位置づけられがちです。SI業界ではプロダクトを導入する案件があって初めて売上が立つため、SIをやってる人がメインストリームという傾向が強いと思います。

私は今までSIとプロダクト開発の両者を経験していますが、どちらも面白いし学ぶことはたくさんあります。たぶん両者をやらないと人は成長しないんだと思います。私はプロダクト開発の方が好きですが、今の立場では手を動かすことは不可能です。それはパートナーさんの仕事です。

会社の規模が大きくなるほど、お役所のルールは増えます。昼飯の時に別の方とも話しましたが、お客様の求める要件より高い品質基準を設定してコストと時間を掛けることは多々あります。そうなるのはルールがあるからです。ルールがある以上は、いくら偉くなっても自分の裁量は大きくなりません。だから自分に合った場所に移る方がよりよい人生を楽しめるんじゃないか、というのが私の現時点の認識です。

こうやって自重せずにブログを書き続けて、色んな人とお会いする機会を作れれば、いつか結論にたどり着ける気がします。ちなみに今は炎上案件をえんじょいしています。

NullPointerExceptionが発生するバグを修正しました。

OpenSocialコンテナからのリクエストを検証するサーブレットフィルタを作っています。Javaでmixiアプリを作るのが少し楽になるライブラリです。

opensocial-oauth-filter - Project Hosting on Google Code

というのを実証してしまったわけです。

先日、opensocial-oauth-filter-0.5をリリースしたわけですが、時間がない言い訳をいいことに試験をサボっていたらバグ報告を受けました。ぬるぽが出るとか恥ずかしいです。穴があったら入りたい。

帰ったらfixします。会社でExcelじゃなくてEclipseなんか開いてたら怪しいので。今日も帰ったら日付が変わるぐらいかorz

以下自分用のTODO

ExtensionRegistry#getExtensions()で指定されたExtensionPointを実装するExtensionが見つからない場合は、nullではなく、空のリストを返すこと。リクエストごとにgetExtensions()が数回呼ばれるので、メソッド内でnewすると実行効率が悪い。空のリストはあらかじめフィールド定数として持っておく。

ExtensionRegistry#getExtensions()が返すリストに対する変更は許容しないことを明記すること。

ExtensionRegistryFactoryTestのテストケースに、extensions要素が空の場合を追加すること。

OpenSocialコンテナからのリクエストを検証するサーブレットフィルタを作っています。Javaでmixiアプリを作るのが少し楽になるライブラリです。

バージョン0.4からの変更点は以下です。

• XMLファイルに設定を書くようにしました。
• jarファイルが1つになりました。依存するライブラリはjar内に同梱しています。
• OpenSocialリクエストのapp_id, app_urlを検証するようにしました。同一コンテナの異なるガジェットからのアクセスを拒否し、セキュリティが向上しました。
• ExtensionPoint?の実装により機能拡張できるようにしました。
• JRE 1.5以上で動作するようにしました。

詳しくは opensocial-oauth-filter - Project Hosting on Google Codeをご覧ください。

納品する立場では意識することが少ないですが、システムは機械設備と同様に固定資産となります。私は社内システムの開発に一時期関わっていましたが、システムを勝手に作ることはできず、投資計画に基づいて資産化する手続きが必要になります。システムを勝手に作ったとしても、そのシステムを作った人の給料をどこから支払うかが問題で、他の名目で支払えない以上は資産化する必要が出てきます。

システムの償却期間ごとに更改案件が発生することが多いと思います。これは、一度作ったソフトウェアやハードウェアは一定期間を経ると価値が下がるという考え方に基づいています。ハードウェアに対してソフトウェアは変更が容易なので、一度作ったものを大きく変更しないという考え方は現実に即していないといえます。

ここまで書いたことは教科書的な話で、実際は維持費でやり繰りするとか次期開発に混ぜるとか怪しげな話はたくさんあると思います。特に、ソフトウェア開発は研究開発や保守との区切りが曖昧なので、試験研究費、開発費、維持費を正確に計上するのは難しいです。

ソフトウェアが固定資産である以上、ビジネスプロセスの変化に対応してソフトウェアが変化していくことは困難です。ソフトウェアの大がかりな変更にかかるコストを維持費として計上すると、金額的にも理屈的にも説明がつかないためです。

そういった「考え直し」を拒んでいる最大の理由は、現行システムという「資産」の存在である。償却期間が存在する以上、安易にシステムに手をいれるわけには行かない。結果として、その「資産」となった現行システムの設計に着手した時点における「誤った判断」は放置されたまま、「高い〜　高い〜　高いからコスト下げろ〜」とシステム担当が詰められる。システム担当はGoogleでクラウドでコスト削減等と検索して、目先のシステムコスト削減にやっきになる。

こんなところなんだろうね。

クラウドを使えば、データセンターに置く機器を資産化しなくて済むようになる。後はその上で動かすソフトウェア「も」資産ではなくサービスとして使えるようにすれば、上記のような「誤った判断」に対する軌道修正が可能になる。

http://d.hatena.ne.jp/masayang/20100129/1264723519

ここで書かれているように、ソフトウェアを資産化せずに商売に使うことは可能なのでしょうか。クラウド上にソフトウェアを置くだけでは、資産ではないと言い切れない気がします。自前の設備とクラウドの違いを教えてください、偉い人。

商売に使うソフトウェアの大きな変更にかかったコストが費用になればいいのかな。

相方が風邪を引いたので、食べやすいスープを作ってみました。

材料（2人分）

調味料

• ごま油
• 鶏ガラスープの素
• 砂糖
• 塩
• こしょう

作り方

切って煮込むだけでOKです。

下準備

1. たまねぎを薄切りにします。
2. ベーコンは5〜10mmぐらいに切ります。
3. しめじは食べやすい大きさに切っておきます。
4. しょうがは千切りにします。
5. 長ねぎは小口切り。

煮込む

1. 小鍋にたっぷりとごま油を引いて、下準備で用意した材料をすべて入れます。中火で焦げない程度に炒めます。
2. 野菜がしんなりしてきたら、水を注いで中火で煮ます。
3. 煮立ってきたら鶏ガラスープの素を入れます。砂糖、塩、こしょうで味を調えます。入れすぎないように注意します。
4. 弱火で5〜10分ぐらい煮込んだら完成。

ポイント

濃い味が好きな人は醤油で味付けしてもよいと思います。ご飯を入れれば雑炊になります。