どのプラットフォームが有望か？

読者の皆様、いつも読んで頂いてありがとうございます。

システムの開発プロジェクトには、Javaなどで実際にプログラムを書いたり、その設計を行う

業務アプリケーション開発チームと、そのプログラムが動く基盤（OS、ミドルウェア、ハードウェア及びその設定）

を整備する基盤チームとに分かれます。

プロジェクトによっては、もっと細かく枝分かれしていることもありますが、ざっくりまとめるとこの2つになります。

私は最近基盤チームに入ることが多いのですが、チームメンバー等と飲み会や昼飯を食べているときに、

これからはどのプラットフォームが良いか？という話になると、完全に意見が別れます。

マイクロソフトを扱っている人は、他社のグループウェアは、頑張らないとMSにのまれちゃうぜ」と言い、

IBMのメインフレーム技術者は、「これからは高信頼性のメインフレームで全てを統合するのが主流だ」と言い、

HPのUNIXサーバー技術者は「メインフレームなど過去の遺産、高いだけだし信頼性も、

もはや同じ」と言います。

色々聞いていると、なるほどなぁと思えることもあれば、ちょっとそれは偏見を持ちすぎと思われることもありますが、共通しているのは、自分が扱っているプラットフォームには将来性があると全員が思っていることです。

実際に有望なこともあるのかもしれませんが、会社のシバリなどからそのプラットフォームをしばらくやらざるを得ないために、そう思い込んでいることも多そうだなあと思います。

私自身も、疑いの目を持ちながら身につける技術を選択していきたいものです。

攻めと守りのプログラミング

読者の皆様、いつも読んでいただいてありがとうございます！

私は学生時代、情報系の学科にてガリガリとプログラムを書いていた。

入社して数年経つと、SEとしてのプログラミングと研究者としてのプログラミングの違いが相当鮮明になります。

まず、研究者のプログラミングは、例えるならば攻めのプログラミング。

論文に掲載するプログラムは例外処理なんて1個もなくてOK。なんちゃって実装でスパゲッティでもOK。

とにかく斬新なアイディアが実現できているものであれば良い。

つまり、デモ用の画面やデータ採取のための必要最低限だけできてれば良いのです。

しかし、SEとしてのプログラミングは、守りのプログラミング。

例外処理が命であって、テストに非常に膨大な時間を使います。

以前、某テストツールのセミナーに出た際に「、ある程度の規模のプロジェクトでは全工程の半分以上をテストに使います。」と言われそんなバカなと思いましたが、実際に大規模プロジェクトなんかだと余裕で半分以上の工程をテストに使います。

また、故にテストをいかにスムーズに乗り切るかがプロジェクトの鍵のために、要求定義の段階からテストの計画についても常に考えながら設計を進めていきます。

大規模な業務システムでなくとも、ちょっとした運用のためのツールを作成してお客様に使って頂くときも、結構頑張ってスタブを書くようになりました。期間が限られている場合、多少ユーザビリティや付加機能を制限してもテストに時間をかけます。

なぜなら、高機能で使いやすいツールを提供したときの得点よりも、期待通りに動かなかったときの失点の方が圧倒的に大きいからです。

どっちが良いか悪いかということではないのですが、最近改めて実感します。

仕事の評価

以前は比較的大きなプロジェクトのはしっこでお客様とは接せずにプロジェクトチーム内だけでコミュニケーションをとっていることが多かったのですが、最近お客様との距離がだいぶ近くなり、直接会話する機会が増えてきました。

お客様と直接会話していると、「あぁ、SEってサービス業なんだ」と思い出しますｗ

プロジェクトメンバー同士だけで会話していると、製造業と似たような気分になっていたけど…

そこでやっぱり痛感するのは、プロジェクトメンバー同士だと、どれだけ努力したかで評価してもらえることが多かったけども、お客様相手ではそれが比較的薄れるということ。

自分がどれだけ努力したかではなく、お客様にどれだけ価値があったかで評価されている感じがします。

こうやって文字で書くと、なんて当たり前なことなんだと思いますが、要はお客様にとって10の価値があるものを

こちらが5の努力で作ろうが10の努力で作ろうがお客様には関係がない。どれだけ省エネで価値を作れるか、そしていかにその価値を感じてもらう状況を作るか、そういうところが大事なんだなぁと痛烈に感じます。

なんというか、努力というのはあくまで良く見せるための要素、というか。こう書くと語弊があるかな…？