エンジニアの独り言

突然ですがプログラミングは好きですか？
プログラミングする際、少し難しくても効率の良いAPIを使ったり、オブジェクト指向言語を利用している場合に効率化のためにパターンなどを積極的に取り入れてプログラムを作ったり･･･なんていうことは、ありませんか？私もプログラミングは好きですし、（であるが故に）以前はよく、そういうプログラミングをしていました。
でも、一度自分が作ったプログラムを見直してみてください。

そのプログラム見やすいですか？

例えば、他の人が開発したアプリケーションの拡張や修正をしなければならない場合で、設計書など仕様を把握できるものがほとんど無く、プログラムを解析する以外に仕様が確認できないというような状況を経験したことはありませんか？

私は何度もそういった状況で、必死にプログラムとにらめっこした経験があります。
そういう時、冒頭に書いたようなプログラムだと作った人間以外には難しく感じてしまい、プログラム解析に時間がかかって対応が遅れたり、対応したとしても実は見落としがあって修正した以外の箇所で障害を発生させてしまう･･･といったことが多々あります

対応するのが熟練プログラマーの場合はそれでもなんとかなるかもしれませんが、経験の浅いプログラマーの場合にはどうなるでしょうか？分析に手間取り、いつまでたっても対応が出来ない･･･なんてことも、平気でありえます。

作った本人にとっては見やすく効率の良いプログラムかもしれませんが、他の人にとっては難しいだけの見づらいプログラムになってしまっているかもしれません。

自分はそんなことはしない！と思っている人（こそ）は、下記をチェックしてみてください

・IF分岐などの条件文が長すぎる
・プログラム中のコメントがなさ過ぎる、もしくは細かく書きすぎている
・プログラム（クラス）の分割を細かくやりすぎている
・Javaなどオブジェクト指向言語の場合に、積極的にインターフェースや継承を使っている
・難しく実装していて、一見すると効率よくみえるが、よく見ると非常に単純かつ簡単に実装ができる

これは私の今までの経験から、見づらいと感じたプログラムに共通したことです。
思い当たるところはありませんか？

プログラマーとして熟練してくると、効率よく簡素に作ろうとして逆に難しく考えすぎてしまうことがよくあります。
プログラムは作ったら終わりではなく、その後何年も使われ続けるものです。難しいプログラムは保守性が下がり、その後何年も苦しむ元凶（？）の元になります。特に、保守担当が新人の場合は、その悲劇たるや想像するだけで悲惨なものあがります。

プログラミングをする時は誰が見てもわかりやすい物を作る！という（当たり前のようで、意外に実践されていない）意識を、プログラマーは持たなければいけないのではないでしょうか。

林田宏介

こんにちわ。アクセンチュア・テクノロジー・ソリューションズの鉾之原です。


いよいよ発表になりましたね、iPhone 3G。サンフランシスコで行われたWWDCのスティーブ・ジョブスの基調講演を日本時間の午前2時から4時までがっつり、ストリーミングによる音声配信で、聞いていました。そこまで英語が得意でないのでスピーチを完全に理解できないのですが、会場に訪れている日本人の方がIRCチャットで会場の雰囲気を伝えてくれたり、海外のWWDCの実況ブログにアップされるステージ上の写真を見ながら十分に楽しめた2時間でした。飛行機で行っても10 時間くらい離れた先で行われていることが、ほぼリアルタイムで聞けるのはすごいことですね。

数日前にSoftBankが先行して日本でiPhoneを販売することを発表し、3GのiPhoneの存在がほぼ確定しましたが、販売開始時期が「今年中」となっていたので7月11日販売開始という発表にはかなり興奮しました。実はWWDCの講演でも、3Gが発表されたのは終盤。会場内でもかなりあきらめムードになっていた最後の最後での発表は、かなり盛り上がりました。しかも、販売国が「イッツ・ア・スモールワールド」のメロディに乗せて、順番に赤く塗られていくという粋な演出で会場を沸かせていたようです。日本は71ヶ国中70ヶ国目と、かなり焦らされようで、IRCチャットや実況掲示板の熱気はすごいものがありました。


さて、肝心のiPhone 3Gですが、個人的な注目ポイントは2点。（もちろん日本での販売も重要なのですが）それは同時に発表された「iPhone 2.0」と「MobileMe」です。

「iPhone 2.0」は、iPhoneにのっているファームウェアのバージョンがこれまでの1.xから、このタイミングで2.0にアップデートされるものです。2.0 の最大のポイントはiPhone SDKによるサードパーティや個人によるアプリケーション開発が可能になることです。これまでのiPhone(もしくはiPod tocuh)ではユーザが独自にアプリケーションを開発することができず、基本的にAppleが提供するアプリケーションしか実行できませんでした。「jailbreak」と呼ばれる非公式な手段で独自にアプリケーションを動かすことは可能でしたが、今回は公式なSDKでの開発が可能になり、しかもiTuneの「App Store」を通して配布もしくは販売することが可能になります。作ったものがヒットするかどうかは別として、個人レベルでワールドワイドな販売チャネルが提供されるのは 開発者として非常に魅力的です。

また、2.0のファームウェアを、これまでのiPhone、iPod touchにも入れられることも重要ではないでしょうか。他のメーカーの携帯は機種そのものを買い換えることでしかバージョンアップはできません。それが、ソフトウェアの更新だけで後継機とほぼ同等の機能を実現できるようになるのです(もちろん今回追加されたGPSなどの物理的な機能は無理として)。


もう一点目は、「MobileMe」です。「MobileMe」は、「.mac」という写真などのデータ保存や共有を提供していたアップルのインターネットサービスに変わるサービスです。「MobileMe」では、「クラウド」とよばれるオンライン上のストレージにメール、カレンダー、アドレス帳を保存して、Mac、PC、iPhoneの同期をとります。ここでの最大のポイントは「プッシュ型」によるデータの同期です。これまでのWindowsMobile機のようなデバイスと、PC(母艦)とのデータ連係は、USBで物理的に接続してActiveSyncによってデータを同期させていました。いわゆる「プル型」によるデータの同期ですね。これが「プッシュ型」になることで各デバイスのデータ更新が自動的に行われるようになります（例えば、PC上で追加したアドレス帳が自動的にiPhoneのアドレスに反映されます。またその逆も然り）。

私はPDAとしてWILLCOMのAdvanced/W-ZERO3 [es]を使ってスケジュールを管理していますが、これに頼り切っているとうっかりデータの同期を忘れ、ミーティングの存在に突然気づいて慌てることもあります（個人的な問題という気もしますが(笑))。この煩わしい手動操作によるデータ更新から解放され、デバイス間のデータ同期がシームレスに行われるようになるのは、かなりのインパクトではないでしょうか。
(先ほどの記述では「MobileMe」サービスに入らないとプッシュ型のデータ同期が取れないような書き方をしていますが、入らなくてもiPhoneが直接Exchangeサーバなどに接続してデータを取得する事も可能です。）

このことをアップルのプレゼンテータが「Push Notification Service」と言い表していましたが、まさにモバイル端末に重要なのはこの概念だと思います。iPodがここまでヒットしたのは、iTunesに曲を入れてから(取り込んだり、iTMS(iTunes Music Store)から曲を購入して）ipodで音楽を聴くまでの過程が、それまでの他のポータブル機器に比べて格別にシンプルだったからだと思います。このiPodに電話、フルブラウザが乗っかった上にスケジュールや、アドレス帳、写真といった身近な情報までもがシンプルに同期してしまう環境がiPhone です。このことを想像しただけでiPhoneを一度持ったら二度と離れられなくなってしまう気がします。


世間的にも大注目なiPhone 3G。日本でどれだけヒットするかは分かりませんが、とりあえず無事発売日に入手できるように頑張りたいと思います。

ブログは林田と交互で掲載する予定でしたが、iPhone発表につい興奮して連続で書いてしまいました。今後もそのようなことがあると思いますが、ご容赦ください・・・。


では、鉾之原でした。

こんにちわ。ATSことアクセンチュア・テクノロジー・ソリューションズの鉾之原です。
このブログでは前回の投稿者である林田と共に、ATSのテクニカル・スペシャリストの私たちがIT業界のことを中心に現場からの声を発信していきたいと思います。

私、鉾之原はパッケージ開発、販売を行うベンチャー企業、Webシステムの開発を中心に行うベンチャー企業を経て、ATSに入社してから3年が経ちます。 C/C++からは離れてしばらく経ちますのですっかり忘れていますが、Javaや、JavaScript、Flashといったここしばらくの支流である Webアプリケーションに関わる技術に興味を持っています。

さて、私の最初のブログになるので、まず自身のことを知ってもらうために、所属するATSと、そこでのユニークなキャリアパスについて紹介します。

ATS （アクセンチュア・テクノロジー・ソリューションズ）は、アクセンチュアの関連会社で、主にシステム開発を行っています。ユニークなキャリアパスと書きましたが、実はATSには二つのキャリアパスがあるのです。一つは、技術を学んだ後に管理者としてのスキルを身につけていく通常（？）のパス。もう一つは、特定技術分野を徹底的にトコトン極めていく技術特化型キャリアパスです（今期新設され、私と林田はこれに属する初期メンバーです）。

なぜ技術特化型キャリアパスが新設されたのか？新しいキャリアパスに異動するにあたって、自分なりの解釈をしてみました。
IT業界におけるエンジニアという職種は、新人としてプログラマから入り、キャリアを積みマネジャーになると管理業務がメインになるのが殆どのケースではないでしょうか。しかし、システムについて高い知識や、高度なプログラミングスキルをもっている人が、必ずしもマネジャーとしてそれと同等かそれ以上のパフォーマンスを発揮できるわけではない。むしろ、管理業務にシフトする中で「だめ」になってしまうことすらあります。
また、エンジニアにも「プログラムが得意だけど、管理業務はイマイチ」、その逆もまた然りで得手不得手があって当然ですし、将来的にマネジャーの道に進むより、開発作業をメインとして活躍し続けていきたい人も多いのではないでしょうか。

技術特化型キャリアパスは、プロジェクトマネジャーが主にスケジュールやコスト管理でプロジェクトを管理するのに対して、メンバーが各自の得意とする技術や、開発方法論を以てプロダクトを管理するプロダクトマネジャーとしてプロジェクトに関わることになります。
昨今のオープンソースソフトウェアの広がりや、SOAなどの疎結合によって生じる利用される技術(プログラミング言語など)の多様化など、一つのプロジェクトでも今まで以上 に広範囲にわたる技術が要求されることが増えていくと、ある技術を極め、そのプロダクト全体を管理する能力を育成する技術特化型キャリアパスのような考え方は、どこでも必要となってくると思っています。

さて、話は変わりますが、いよいよWWDCの開催が近づいてきましたね。いよいよ登場が噂される3G iPhoneに期待せざるを得ません。特に日本の市場への参入は多くの人が注目していることでしょう。私はマニアとまではいきませんが、かなりのガジェッ ト好きなので純粋に今回のWWDCの開催を楽しみたいと思います。

はじめに

本ブログは、アクセンチュア・テクノロジー・ソリューションズのテクニカルスペシャリストの林田と鉾之原が、技術的に難易度の高いプロジェクトに携わる現場のエンジニアという立場からの生の声を書いていきます。
連載は林田・鉾之原が交互に書いていく方式とし、第一回である今回は林田が担当します。
技術専門のエンジニアからの声ですので、何かのお役に立てれば幸いです。　

林田・鉾之原


模倣中心のベンチマーク指向

Web 2.0という言葉をGoogleの日本語サイト検索で行うと、90万件以上がヒットする。
イメージがわきづらいかもしれないが、例えば"Java"や"マイクロソフト"を検索するのと大体同じくらいというとイメージつきやすいだろうか。

そのくらいWeb 2.0という言葉が日本に根付いたといえる。しかし、検索にヒットしたサイトを見てみると、Web2.0を解説し導入方法について記載したWeb2.0企業を目指そうといった趣旨のサイトや、現在のWeb2.0企業の動向といったまるでトレンドを扱うようなサイトが多く目に付く。

中でも面白いのは、Web2.0という名前の会社や（将来Web3.0や4.0というのが出たらどうするのだろうか？）、Web2.0を何かのソフトウェアのように勘違いし”インストール方法”について質問したQAが記載されたサイトだ。

何が問題なのか？

そもそもWeb2.0は、先進的な企業がWebが持つ特性を上手く利用してきた結果、新しい発想で使い始めたことをバージョンアップになぞらえたものに過ぎないので、正確な定義をつけること自体にあまり意義はないし、名称自体にも大きな意味はないはずだ。

しかし、日本は今まで何かを模倣することによって成長してきた背景もあり、常にベンチマークとなるべき具象化された何かを必要とし、模倣しようとする。
あまり意義の無いことであったとしても、目指すべきモノ自体に意味を持たせようとする傾向が強い。だから、思想色が強く、抽象的な概念を持ったWeb2.0のような技術的なトピックに対しても、その言葉自体に意味を持たせようとする。

その結果・・・「Web2.0を導入したい」という曖昧な要件が発生し、エンジニアは「Web2.0とは何だ？」という定義づけから行わなければならないという事態が発生し現場は混乱する。

どうすればいいのか？

模倣を目的としたベンチマーク的な考え方は、モノ自体の進化を生み出す事もあるので悪いことだとは思わないし、非難するつもりもない。
しかし、模倣を中心にベンチマークを考えすぎてしまうと、本来考えなければいけないことを無視した本末転倒な結果を生み出してしまう。

例えば前述の「Web2.0を導入したい」というケースでは、本来企業としての目標とそれを達成するためのベンチマークがあるはずで、それに対してエンジニアはそのベンチマークをクリアする為の手段としてWeb2.0的な思想を導入するという姿になるはずが、手段であるはずのWeb2.0が目標になってしまっているために現場は混乱してしまう。

それを回避するためには、ベンチマークを何かから見つけ出すという模倣中心の考え方だけではなく、ベンチマークを自分たちで創造するというよう考え方も持たなければならない。
そうならなければ、現場のエンジニアはいつまでも混乱から解放されない。

林田 宏介