当初、Javaでアプリケーションが開発できると聞き、「PDAにJ2MEを載せてアプリケーションを実行することと大差ないプラットホームではないか」とみくびっていました1。
ところが、顧客の担当者から、Zaurusに載せて実際に動作するAndroidを見せてもらって、いい意味で裏切られました。そしてAndroidに興味を持つようになり、お蔵入りが決定していたプロトタイプをAndroidへ移植して、Android Developer Challengeに出場できないか、顧客の担当者に相談したこともありました。結局、出場しませんでしたが、いつかAndroidで動作するアプリケーションを作成するプロジェクトに加わりたいと思うようになりました2。
昨年、ようやくAndroidでソフトウェアを製造するプロジェクトを担当することになり、実際にプログラミングする機会を得られました。特に JITコンパイラが追加されてパフォーマンスが向上した2.2がリリースされてからは、携帯電話やスマートフォンに興味のないわたしでも、所有してもいいかなと思うようになってきました。
そこで、わたしがAndroidを気に入っている理由は次のとおりです。
Symbian向けのアプリケーションをC++で作成したことがあります。当時、コンパイラとしては、Visual C++、C++ BuilderX、または、CodeWarrior for Symbian OSのいずれかが必要でした。たまたま、別件でわたしの作業用PCにVisual C++ 6.0をインストールしてあったので、新たにコンパイラを購入することはありませんでしたが、個人でアプリケーションを開発することを考えた場合、SDKと最も親和性の高いCodeWarrior for Symbian OSはとても高価ですし、すでに.NET Frameworkでシステム開発が行われていましたので、いまさらVisual C++ 6.0を購入するのは無駄な投資のように見え、とても敷居が高いと感じました。
Androidの場合はインターネットに接続できる環境があれば、無償で開発環境が入手できます。アプリケーションを作成するためのハードルがとても低いことは魅力的です。
従来の携帯電話向けJavaアプリケーションは、CLDCと採用するプロファイルで提供されるAPIを呼び出すことしかできませんでした。何か新しいことを始めるとき、独自にAPIを拡張できないことが足枷になってしまいます。また、VMで実行するとボトルネックになる部分をネイティブ化することもできませんでした。
AndroidではAndroid NDKが用意されていて、これらを解決できます。多少は制限があると思いますが、従来の携帯電話向けJavaアプリケーションの開発に比べると、自由度が高いことがうれしいです。
携帯電話向けJavaアプリケーションを作成していた当時は、movaとFOMAが混在していて、アプリケーションはどちらの端末でも動作できなければなりませんでした。特にmova機はアプリケーションサイズが最大で30Kbyteでしたので、ソースコードレビューで無駄なコードを取り除いた上でさらに難読化ツールを利用し、アプリケーションサイズを削る作業が必要でした。
今まで、何気なくAndroidアプリケーションを作ってきましたが、アプリケーションサイズに悩まされたことはありません。もっとも、これはAndroidがリソースに余裕のあるスマートフォンをターゲットにしたOSだからかもしれません。
SymbianのAPIに不具合（だと思う）3を発見したことがあったのですが、当時はソースコードが公開されておらず、原因の特定（呼び出し方の問題か、APIのバグなのか）ができず、対症療法的な対応で回避せざるを得ませんでした。顧客への報告もなんとも煮え切らない内容となりましたし、歯がゆい思いをしました。
Androidはソースコードが公開されていて、環境さえ整えられればビルドすることもできます。実装方法を調査したり、もし、不備があれば修正できるのは魅力的です。Android 1.5のブラウザのソースコードを調査して、WebView上で文字列選択を開始するときに呼び出すWebView.emulateShiftHeld ()4を見つけられて、実装できないと思っていた機能を実現することができました。
さらに、公開されているほとんどのソースコードがApache Licenseなので、改修してもソースコードの公開をする必要がありません。携帯端末メーカーはAndroidを採用しやすいと思います。
学生時代からUNIX処理系に慣れていましたし、就職してからもLinuxをターゲットにしたアプリケーション開発していたので、それなりに知識があります。AndroidがカーネルにLinuxを採用しているおかげでノウハウが流用できることが、怠惰なわたしにはうれしいところです。
Androidは携帯端末向けにカスタマイズしてあるにせよ、Linuxなので、オープンソースで公開されているソフトウェアを移植できるため、いろいろな可能性を感じます。
この夏、Android VNC ServerをNexus Oneで実行できるようにする作業を行いましたが、このAndroid VNC ServerはLibVNCServerを利用して実装されていましたし、期待どおり動作しない問題をLinux Input Subsystemで解決できました。
かつて、わたしがLinuxを搭載した携帯電話向けにネイティブ・アプリケーションを作成していたとき、GUIを実装するために利用できるライブラリは、Xlib、ひと昔前のGTK+（1.2ぐらいだったかな）でした。実験にはあまり本質的ではないアプリケーションの作成でしたので、ササッと作ってしまいたかったのですが、かなり苦労しました。
当時でもVisual Basic 6.0や.NET Frameworkを使って、比較的簡単にGUIを持つアプリケーションを作成することができていましたので、通常、フレームワークが隠してくれる煩わらわしさを自分で実装する必要があり、うんざりしてしまいました。
Androidでは使い慣れたJavaでプログラムを書くことができるし、VMのおかげでメモリに対して神経質になりすぎずに済みます。また、AWTやSwingを使わずにGUIを作成できることも気に入っています。
今のように簡単にLinuxがPCにインストールできなかったころは、Linuxがわたしのおもちゃでした……。動作実績リストを見ながらPCを自作したり、カーネルを最適化したり、ウインドウマネージャに凝ってみたり……簡単にインストールできるようになってしまって冷めてしまいましたが、Androidで再びおもちゃを手に入れた心境です。
現在、顧客から借用しているNexus Oneはルート化してあって、権限を気にせずアプリケーションを実行できるのですが、電波法の問題で3Gが利用できません。残念です。日本でも3Gが使える開発端末……Android Dev Phone 2の後継機が出ることを期待しているのですが、いつになることやら……当面、職場のNexus Oneでガマンです。
1 当時、携帯電話向けJavaアプリケーションの性能問題に手を焼いていたので、Javaに偏見を持っていました。
2 自宅のPCは、当時も今もEclipseやエミュレータを動かすには非力なので、自宅でのアプリケーション開発は諦めています。そろそろ買い換えたいのですけど、他の誘惑に負けてしまい、いまだに買い換えられていません。
3 Symbian OS 7.0でTUriParser16::Parse（）の引数にhttp://][のような不正なURLを与えたときKUriUtilsErrInvalidUriが返却することを期待していたのですが、パニックUSER 10が発生しました。
4 API Level 8から公開されました。
わたしはうまいドライバーではありませんでしたし、MR2も（過給器なしでは）戦闘力のある車両ではないので、主にクローズドクラスのイベントに参加していました2。最近は車も乗り換えて、練習会すらご無沙汰な状態ですが、ジムカーナからいろいろなことを学びました。仕事をしているときに、以下の4つの力が培われたと実感しています。
練習会や競技会のエントリーフィー、燃料代、車両のメンテナンス代に消耗品代……とにかくお金が必要でした。うまいドライバーはメーカーやチューニングショップのスカラシップやスポンサー費用を足しにできるのですが、下手なわたしがそのような費用が得られるはずもなく、基本的に趣味の範ちゅうで活動していました。
そのため、限りある予算（＝ 給料）を効果的に配分しなければなりません。自分の技量、車両の状態から、『いつ、何に注力するのか』優先順位を考えながら活動していました。車好きな人なら、エアロパーツや車高調サスペンション、大口径マフラーとかを付けたくなるところですが、グッと我慢して運転技術の向上を目指しました。
このような経験のおかげで、作業の優先順位の決定や必須要件の見極めができるようになり、ずっと視野が広くなった気がします。
練習走行中、車両の中で必死に運転していますので、ハンドルやペダル操作や体感したGなどの主観的な情報は得られるのですが、客観的に車両がどのような挙動しているのか知ることができません。そこで、多くのドライバーはビデオカメラで仲間に自身の走行を撮影してもらって、ドライビングの分析を行っています3。
わたしは予算上、ビデオカメラを持っていませんでしたので、同じ駆動形式の車両の挙動を観察しながら、自分が走行しているときの挙動を想像したり、ビデオが入手可能な場合4は、自分が走行している部分を何度も見直して、走行時の操作（の記憶）と車両の挙動を結合してドライビングの分析を行っていました。
これは、想像力を鍛えるいいトレーニングになった気がします。顧客から要求を聞いただけで、実装するシステムをイメージできることが多くなりました。
実は、ジムカーナをしていて「楽しい」と思ったことはほとんどありません。競技会で初優勝したときは楽しかったですが、走れば走るたびに課題が増えていきます。しかも、同じ駆動形式の車両に乗るドライバーがいとも簡単にやってのけてしまうと、悔しいやら情けないやら……。こうしてジムカーナにのめり込むようになりました。
仕事をしていて、「これ、君にはできないだろうから、ほかの人に任せた」と言われると悔しくて仕方ありません。「見返してやろう」と思って日々の作業をこなした結果、同じ派遣先に10年以上も居座ることになってしまいました。
わたしのまわりにモータースポーツをしている人がいませんでした。ジムカーナを始めるために何をすればいいのか、アドバイスがもらえる環境がありませんでしたので、モータースポーツ誌のクラブ員募集に応募して、JAF登録クラブに入会しました。
また、わたしの車両だけ駆動方式がMR（ほぼRR）だったせいもあって、クラブ内に師匠がいませんでしたので、練習会などでうまいドライバーにお願いしてアドバイスしてもらったり、同乗走行してもらいました。とにかく、自分で行動を起こさないと何も進展しない状況でした。
このような経験から、進展しない状況においても他人より先に自分のできることを探して行動に移していることが多いように思います。きっと、派遣先の正社員には「でしゃばりすぎ」と思われているでしょう。けれど、空気を読んで停滞を甘受する気はありません。
わたしは、仕事かそうでないかにかかわらず「経験したことに無駄なことはない」と思っています。何かしらの糧になっているはずです。わたしの場合はジムカーナというマイナーな趣味でしたが、真剣に取り組んで得られた経験は、何らかの形で仕事に良い効果をもたらしてくれるでしょう。「草食系」なんて決め付けずに、真剣に趣味に興じてみてはどうでしょうか。
最近はジムカーナをしていませんが、全日本選手権に出場していたドライバーに混じって所属クラブ内イベントのカート大会に出場しています。いまはまだ圧倒的な実力差を見せつけられている状態ですが、あと2秒削って対等に勝負できるようになりたいと思っています。
1 親父と漫画「バリバリ伝説」の影響をもろに受けていました。
2 よく参加していた筑波サーキットビギナーズ・ジムカーナシリーズが今シーズンをもって休止することになったようです。残念です。
3 思いのほかIT業界の人が多く、動画比較ツールや光電管を使った計時システムを自作されるドライバーもいらっしゃいます。
4 練習会では、たまに走行風景をビデオ撮影してくれる主催者がいます。有料ですけどダビングしてくれたりします。
運が悪いだけなのか、わたしの立ち回りが下手なのか、ウォーターフォールを採用するプロジェクトではろくなことがありませんでした。このため、ウォーターフォールを採用するプロジェクトを担当させられるのが好きではありません。
わたしがウォーターフォールを採用するプロジェクトが嫌いな主な理由は、次のとおりです。
前工程の進ちょくが遅れていても、当初のスケジュールどおり開発を進めるため、やむをえず前工程の作業完了を待たずに次工程の作業を開始します。後戻り作業を減らすためにブレの少なそうな箇所から作業を始めますが、少なからず後戻り作業は発生します。
厳密にウォーターフォール・モデルに従うなら、前工程の作業が完了するまで次工程に着手すべきではないと思います。それが守れないならウォーターフォール・モデルにこだわる必要が分かりません。
じかに顧客から要求を聞き、定期的にプロトタイプを見せて顧客と一緒に仕様を決めながらシステムを開発することに慣れているので、最終工程まで顧客に成果物を見せる機会がないと、それが顧客の要求を満たしているか、とても心配になります。
特に、下流工程を担当していてユースケースが想像できない仕様があると「本当にこれでいいのか？」と不安になるので、上流工程の担当者に質問したり、使えるコネを駆使して顧客の要求の真意を尋ねたりします。必要であれば（余計なお世話かもしれませんが）別の仕様を上流工程の担当者に提案することもあります。
これだけ確認しても、要求を満たすことができないことがありました。そのプロジェクトでは、詳細設計（もちろん、査閲・承認済）どおり実装したアプリケーションがシステムテスト時に顧客の要求を満たさないことが判明し、リリース物件から除外することになってしまいました。
わたしはいままで、ウォーターフォールを採用するプロジェクトのリーダーを務めたことがないため、ガントチャートを作成したことはありませんし、他のプロジェクトでも進ちょく状況を数値（パーセント）で報告させたことはありません。このため、わたしはプロジェクトリーダーに担当する工程の進ちょく状況を数値で報告しなければならないとき、進ちょく率を算出方法が分からずに困ってしまいます。
テスト工程のように、比較的算出しやすい（実施項目数／全項目数で算出できそう）場合はよいのですが、設計や製造の工程では難易度を考慮しなければならず、進ちょく率を算出する式や難易度をあらわす係数を用意しないと、正確な値を得ることができないと思うのです。
けれど、悩むわたしをよそに、若手技術者でも堂々と「80％完了です！！」などと報告しますが、わたしには何をもって80％完了したと判断したのかが分かりません。きっと、わたしの知らない暗黙の算出式というものが存在するのでしょう。
ウォーターフォール・モデルは、コンピュータでプログラムを実行するコストが高かった（パンチカードを作成してバッチ実行していた？）時代では効率的な開発モデルだったのではないかと想像します。担当者1人に少なくとも1台のPCが与えられる現在では、アジャイル開発や反復型開発など、試行錯誤しながら進められる開発モデル、手法のほうが効率的な場合が多いのではないでしょうか。
少し前にスラッシュ・ドットで話題になっていました。コメントを見る限り、「次工程が見切り発車する」で述べたように、ウォーターフォールの原則をないがしろにして開発を進めているプロジェクトが多いようです。いったい何のためにウォーターフォール・モデルを採用するのでしょうか……。プロジェクトメンバーにスケジュールを遵守させるためのプロジェクト・マネージャのエゴかと勘繰りたくなります。
]]>振り返って考えると、この「炎上プロジェクト」には、必ず共通する特徴がありました。ここでは、その3つの共通点を紹介します。
■♯1 うそをつく
うそをつく……いったい、プロジェクトにかかわる誰にメリットがあるのでしょうか？
わたしが長年お世話になっている顧客からの要請で、直接関係のないA事業部が外注したプロジェクトの手伝いを行うことになりました。作業に着手した時点（＝プレス・リリース前日）で、サーバがSIGSEGV（セグメンテーション違反シグナル）でダウンする状況でした。サーバのダウン状況を再現してほしいと依頼されたものの、サーバの実行形式ファイルは次々に更新。再現できるはずもなく、結局、何の役にも立てずに引き上げることになりました。
このプロジェクトの手伝いを行う前にA事業部から状況を聞かされていたのですが、丸投げした下請けの（うその）進ちょく報告を信じて、外注先がA事業部に対して「来週には完成します」と報告し続けていたようです。報告を疑ってA事業部が外注先に乗り込んだときには手遅れで、結局、プレス・リリース前日になってもろくにサービスを提供できない状況になってしまったようです。
わたしは早々に引き上げましたが、他の技術者の努力で無事サービスインできたようです。
■♯2 増員の受け入れに時間がかかる
手伝いに行くのは構わないのですが、大抵「作業環境が準備できていない」とか「忙しいから」と手伝いに来た増員を待たせます。いったい何のために呼び出したのか……
あるとき、顧客のソリューション製品を採用してもらった経緯があり、B事業部のプロジェクトへ手伝いに行きました。3稼働日（5日）後に製品のプレス・リリースを控えており、即、作業に着手できると想定していたのです。しかし、まずは3時間の放置プレイ。やっと不具合対応に着手できると思いきや、今度は彼らが製造しているシステムの素晴らしさの説明が始まります。さすがに業を煮やしたわたしは説明をやめさせ、発生した不具合の状況と作業手順を確認しました。
休憩時間中に顧客から進ちょく状況を尋ねられたので、ありのままを報告したところ、顧客責任者がB事業部に乗り込み、顧客とB事業部の大ゲンカに発展してしまいました。わたしが作業場所に到着してから8時間、このうち実際に作業できたのは、たった2時間でした。
帰り間際、プロジェクト責任者に「君は徹夜や休出はできるのか？」と尋ねられました。「契約上、派遣先の責任者の指示が必要です」と逃げました……。そんなこと尋ねるよりまず、作業場所に到着した時点から作業をさせろ（怒）。
B事業部では、この不具合は3日あっても解消できないと大騒ぎしていましたが、結局、1.5日で完了でき、無事プレスリリースに間に合いました。
プロジェクトが炎上し始めると、プロジェクト・リーダーは、対処方法などを決めかねていて作業量を見積もることができなくても、とにかく人員を補給したがりますが、確保した人員を効率的に作業をさせる環境ができていないことが多いです。
■♯3 責任を転嫁する
どんな状況下でも保身を図ることに注力する人がいます。そんな状況ではないことは、その人自身も十分に承知しているはずなのですが……
顧客とB事業部との間で喧嘩が勃発した、プロジェクトでの（上記の）不具合。顧客が提供したフレームワーク（わたしが実装しました）の仕様に従ってB事業部がメタデータを作成していないことに起因していました。もちろん、仕様が変更になるたびに顧客担当者がB事業部へ出向き、説明していたはずなのです。
しかしながら、B事業部は一貫して「いままで動いていたのに動かなくなったのはお前たちのせいだ」と主張しました。挙句、問題解決が進まない状況を指摘した顧客に対して「非協力的な奴は出て行け！！」とわめき散らしました。
彼らはようやく始まったデバッグ作業にも消極的で「俺たちは被害者だ」オーラ全開。わたしとペアプログラミングを行っていたB事業部の社員は、「面倒くさいなぁ、（この作業を）代わってくれない？」と、わたしにあてつけるように近くを通りかかった同僚に話しかけます。
メタデータの修正作業のほとんどがテキスト置換なので、正規表現によるテキスト置換機能をもつテキストエディタの使用を提案しましたが、かたくなにメモ帳（Notepad.exe）で作業していました。このときばかりは sedコマンドの便利さを痛感させられました。
■おわりに……
派遣先では、これまでに例示した（＝わたしが経験した）プロジェクトよりもひどいプロジェクトの支援を行っていました。おかげで、問題プロジェクトの状況を自分なりに分析したり、支援活動を行う技術者から話を聞くための貴重な機会を得ることができました。
プロジェクトが炎上するきっかけは何でしょうか。うそをついたり、隠し事をしたり、ごまかしたり……プロジェクト・マネージャやプロジェクト・リーダーの不誠実な行動が原因となることが多いようです。何が彼らにそのような行動にかきたてるのか……わたしには分かりません。しかし、プロジェクトを運営する立場にある技術者はいつでも誠実でいられるように心がけるべきだと思います。
わたしはいま、担当するプロジェクトにおいて誠実でいることができているのだろうか……。
]]>そこで、Google App Engine for Javaを使ったアプリケーション開発でわたしがはまってしまったポイントを紹介します。これらの中には、最新のSDKや実行環境において解消されているものもあると思いますが、それでも何かの役に立てば幸いです。
XMLファイルの解析にDOM Level 3 Load and Saveを使用して実装しました。開発用サーバでは期待どおりXMLファイルを解析することができましたが、App Engineにアップロードしてみたところ、
org.w3c.dom.bootstrap.DOMImplementationRegistry.newInstance()
を呼び出した時点で、内部の実装で使用するDOMXSImplementationSourceImplクラスが見つからないというエラーが発生しました。
JREホワイトリストにDOMImplementationRegistryが載っていたので、App Engine上でも期待どおり動作してくれてもよさそうなものですが、うまくいきませんでした。ただ、幸いにしてJAXPを使った実装に切り替えたところ、App Engine上で期待どおりの結果を得ることができました。
JREホワイトリストに利用する予定のAPIが掲載されていても、念のためApp Engine上で動作確認しておくことをお勧めします。
Java版ではデータストアへのアクセスにJDO APIが使用できます。SQLライクなクエリ（JDOQL）が利用できてしまうせいか、エンティティをRDBのテーブルのように設計してしまいがちです。例えば、所有関係を使用しなかったり、複数のフィールドの組み合わせでエンティティを識別しようとしたり……データストアをRDBの代替と考えるとはまってしまいます。
わたしが担当したアプリケーションは、1回のリクエストでデータストアに永続化した大量のデータにアクセスする必要があり、このようなエンティティ設計がボトルネックになってしまいました。このため、作業期間の大半を性能測定とエンティティの再設計に費やすことになりました。最終的に、エンティティ間に適切な所有関係を設定し、永続化するデータの見直しを行い、なんとか使用に耐える程度の性能向上を実現できました。
また、エンティティ・グループ単位でしかトランザクション操作を行えないこともエンティティの設計を難しくする要因だと思います。
アイドル状態のサーブレットがアンロードされる時間が、一般的なWebアプリケーションサーバのそれよりも短いようで、想像よりも頻繁にサーブレットがロードされてしまいます。このとき、リクエストの処理時間のほかにサーブレットをロードする時間を必要としますが、Google App Engineの30秒ルール（リクエストを処理し、レスポンスを返すまでの制限時間）にこのロード時間が含まれてしまいます。
このため、同じ条件でサーブレットを呼び出しても、ロードされている場合には期待どおりの動作をしますが、アンロードされている状態から呼び出したとき、DeadlineExceededExceptionが発生してしまう場合があります。
処理時間が長くて1回のリクエストで処理しきれない場合、処理を分割して複数のリクエストで実行することになりますが、安易に「20秒経過したら処理を中止し、次回のリクエストで処理を継続する」といった経過時間に依存する処理分割は、サーブレットのロード時間のせいで30秒ルールの餌食になる可能性があります。
わたしが担当したアプリケーションでは時間のかかる処理を細分化し、タスクキューを使用してバックグラウンドで実行するように実装しました。
わたしが担当したアプリケーションでは、前述のとおり性能問題が発生したために性能測定とエンティティの再設計を目標とする性能が得られるまで何度も繰り返しました。その結果、管理コンソールのDatabase Indexesに、使用されなくなったインデックスがずらりと列挙されてしまいました。
インデックスの総数は、割り当て制限がかかっています。無料のデフォルト割り当てでもそうそう消費し尽くすことはありませんが、気分的に不要なインデックスは取り除きたいと思うものです。しかしながら、Google App Engine SDK for Javaには、App Engine上に配置されたアプリケーションのインデックスを削除する方法がありません。
このため、インデックスを削除するためには、Google App Engine SDK for Pythonの開発環境を構築し、appcfg.pyのvaccume_indexesコマンドを使用するしかありません。たとえば、myApp というアプリケーションでは、ダミーの myApp というアプリケーションのプロジェクトを作成したのち、次のようなコマンドを実行します。
> python appcfg.py vaccume_indexes myApp本来ならば、これで不要なインデックスを削除できるのですが、わたしの作業環境ではインターネットへ直接接続することができません。当然、プロキシサーバを経由する必要がありますので、しかるべき設定を行ったのち、上記のコマンドを実行しました。ところが、プロキシサーバがネットワークエラーを返送してしまい、App Engineに接続できませんでした。
仕方なく、DMZにアクセス権限を持つ研究員にお願いして不要なインデックスを削除してもらいましたが、もっと楽に削除できないものでしょうか。
Google App Engineには日本語のホームページがあります。ドキュメントやFAQなど、日本語のリソースが整理されているのですが、翻訳ミスとはいえない、明らかな誤植をたまに見かけます。わたしがはまったのは、割り当てのページです。CPU時間について、無料のデフォルト割り当てで 1日あたりの限度が日本語のページでは「46CPU時間」、英語のページでは「6.5CPU-hours」となっていますが……。これは6.5CPU-hoursが正解です。
アプリケーションの性能測定のとき、大量の測定用データを投入する必要があったのですが、1日の割り当てが 46CPU時間あると信じ込んで何気なくデータを投入したところ、15％ 程度のCPU時間を消費した時点でサーブレットが503（Service Unavailable）を返送しはじめ、管理コンソールのDatastore Viewerが使用不能……慌ててドキュメントを読み直すことになってしまいました。
このほか、日本語のホームページは最新の情報に追従できていないようです。貴重な日本語の情報なのに……残念です。
Google App Engineでアプリケーションを作成していて最もやっかいだったのは、やはり30秒ルールです。ブロードバンドが普及した今日において「制限時間 30秒」というのは妥当だと思いますが、実際にアプリケーションを実装してみるとかなり厳しい制約です。
30秒以内に応答が返せなければ、負荷を最適に分散してくれようとも、どんなにデータストアがスケールしてくれてもDeadlineExceededException……サービス不能です。1リクエストの処理時間を減らして、いかに有益なアプリケーションを作成するか……センスが問われるプラットホームのようです。
地元企業の募集要項を見ていて気付かされるのは、「どんな仕事でも取り組む」つもりでいても「最新の技術を実践する機会」を望んでしまうということです。飽きっぽくて新しいもの好きとしては、やはり最新の技術や概念に触れていたいという願望がありますが、経験上、実際に使わない技術を学んでも身につくことはありませんでした。研修制度をうたう企業もありますが、それだけでは不十分です。責任ある状況で学び、実践し、フィードバックを得る……こうしてはじめて技術として身につくと思うのです。
幸いにして、現在の主業務ではこのような機会があります。新しい技術を得て、それを生かしたアプリケーションを作ることができる……日ごろ考えたこともありませんが、これがわたしの「仕事のやりがい」なのかもしれません。
ちなみに、わたしの派遣先には、事業部が必要な人材を公募する制度があります。正社員は希望する事業部が人材を公募していれば（上司など異動を阻害する人に許可を得ることなく）自由に応募することができます。
もし、あなたがやりたい仕事のために転職するつもりなら、転職する前にこのような制度を利用してみてはどうでしょうか？ 残念ながらわたしの会社にはありませんが、比較的規模の大きい企業では類似する制度があるのではないでしょうか？
この制度を利用して異動した方を何人が知っていますが、ほとんどの方が「社会に貢献する仕事がしたい」という理由で応募されたそうです。わたしの場合、担当した業務で数本のソリューション製品の製造にかかわることができましたので、彼らに言わせれば、社会に貢献する仕事をしていることになります。楽しみながらプロトタイプを製造し、うち数本が製品へと昇華する……わたしは技術屋として幸せなほうかもしれません。
]]>仕事が楽しみなら人生は極楽だ。
仕事が義務なら人生は地獄だ。
実家で農作業を手伝う（戦力になっていたかどうかは別として……）ぐらいで、仕事をしたことがない時は気にも留めなかった格言ですが、この年になって実感しています。
わたしは、運良く「デスマーチ」と称されるような過酷なプロジェクトを担当したことがありません。「火消し部隊」と揶揄されていた派遣先において、召集令状が配られるタイミングに別プロジェクトを担当していて、デスマーチから逃れ続けてきました。
過酷なプロジェクトを経験したことのないわたしが言っても説得力に欠けるかもしれませんが、創造的な一面を持つITの仕事は、思ったより遊べます1。同じ仕事をするなら、楽しまなければ損です。すべての仕事で遊べるとは思っていませんが、わたしが仕事を楽しむための心得を紹介します。
初めて経験する作業というのは、わたしの好奇心を掻き立てる絶好のネタです。経験がないために不安になることがありますが、そういうときは、
「世界中には、自分と同じ作業をしようとしている人が必ずいたはずだ」
と自分自身に言い聞かせ、彼らが残してくれた作業ログを掘り出すべく、キーワードを駆使してインターネット検索を行います。
時間が許す限り、好奇心を満たすために調べ尽くしましょう。ただし、引き際も肝心です。成果もなく延々と調査してしまうのはただの進ちょく遅れですので、行き詰まったら「実現が困難な理由」を報告して切り上げましょう。代替案が添えられればベターです。
注意すべきは、インターネット上で公開された情報が必ずしも自分たちにとって有益とは限らないことです。意図的に失敗へ誘導するようなWebサイトは少ないと思いますが、プラットホームの違いやバージョンの違い、作業ログの欠落などによって、期待する現象を再現できないかもしれません。
話半分、自分でちゃんと確証を取りましょう。
作業をしていると「面倒くさい」「煩わしい」と思うことがあります。わたしは真面目な性格ではないので、「仕事だから仕方がない」としぶしぶ作業をする気はありません。こういう場合、「面倒くさい」や「煩わしい」と感じる作業には、必ず「楽（らく）」する方法があるはずだと考え、徹底的に「楽」する方法を探します。
例えば、
プラットフォームやプログラミング言語の違いのせいで、日ごろから使い慣れたツールが使用できない場合に、代替手段を探すことから始めてみるといいと思います。
楽する方法を探していると、「無知が煩雑さを生んでいる」ことに驚かされるのではないでしょうか。わたしは、いまだに「あのプロジェクトのときに知っていれば……」と後悔することがあります。
他チームから提供されたプログラムやOSSを活用する場合、期待どおり機能してくれればよいですが、そうでないことがあります。他チームのプログラムであれば、現象を報告して改善されるまで待機……でもよいのですが、せっかくなので他人のプログラムをデバッグしてみましょう。ソースコードがあれば、簡単にデバッグできるはずです。
現象のほかに原因と思われる箇所を一緒に報告すると早急に対応してくれるはずですし、副次的に他チームの技術力を知ることもできます。
これは、わたしがはじめてJavaプログラミングを行ったプロジェクトのリーダーが行っていたことです。他チームに問い合わせると時間がかかるからプログラムをコード・リバースして仕様を調べたり、不具合を特定したり……。当時、わたしは「ここまでやるか、普通」と思いましたが、顧客がそこまで調べるなら軽々しく質問できないので、わたしも他人のプログラムを調べるようになりました。
どうしてもソースコードが入手できない場合は、やむをえずコード・リバースもしていましたが、最近はライセンス上、コード・リバースできないものもありますので、気を付けてください。
他人のプログラムを読むことは、特にプログラミング初級者には重要だと思います。自分に課せられた課題に対して他人がどのようなアプローチで解決しているか、なぜこのアプローチを採用したのか、自分のアプローチとどう違うのかなど、参考になることが多いはずです。
作業の対価として給料をもらっている以上、過酷でつまらないプロジェクトは不可避です。経験上、複数プロジェクトを担当させられるとき、少なくとも1つはつまらないプロジェクトでしたし、今も副業務として担当するプロジェクトはつまらないプロジェクトです2。それでも「仕事だから仕方がない」と義務感から取り組むより、「プロジェクト自体をハックしてやる」気持ちで取り組んだほうが楽しめるのではないかと思います。
主業務だけ担当させてもらえれば、わたしの技術屋人生は極楽……なんですけどね、たぶん。
1 最近、SIMロックフリーのNexus Oneを研究所から借用したのですが、「コレで遊んでください」と主任研究員に言われてしまいました……。
2 わたしは仕事嫌いなので、無駄な抵抗とは分かっていても、大人気ない行為と分かっていても、最後まで「担当したくない」ことを猛烈にアピールします……。何度か派遣先の主任（当時）と怒鳴りあいの喧嘩にまで発展してしまいました（苦笑）。
受託開発を主業務とする会社に就職してから、ずっと派遣先へ丁稚奉公に出されたまま13年目になってしまいました。幸か不幸か、派遣先での主な作業は、製品プロトタイプや実証実験用のアプリケーションの開発で、業務システム系の作業に携わったことがなく、「わたしは○○の業務知識があります」とアピールできるほど、業務知識の蓄積がありません。
そのせいか、同僚や友人と話をしていても納得しえない「価値観のズレ」を感じることがあります。このコラムでは、わたしが見聞きしたことや実際に経験したことを紹介していくつもりです。きっと「価値観のズレ」がよいネタになってくれると思います。皆さん、よろしくお願い致します。
では、自己紹介を兼ねて「わたしがこの職業を選ぶきっかけとなった 5つのものごと」です。
SONYやCASIOなど各メーカーがMSX機を発売していたころ、日立が発売したテープレコーダ一体型のMSX機です。小学生だった時分、同級生の間ではファミリーコンピュータが定番でしたが、わたしは……エポック社のカセットビジョンでした。
友達とゲームの貸し借りできないし、ファミリーコンピュータのゲームの方が魅力的だったので、両親にクリスマスプレゼントとしてねだったところ、父が買ってきたのがH2でした。
当時はガッカリしましたが、プログラミングをする機会を与えてくれたわたしにとっての名機です。ちなみに、はじめてのプログラミング2は父と一緒にMSXのムック本に掲載されていた「タマリン」というゲームでした。
親戚の兄ちゃん（母の従兄弟）が工業高校を卒業して、某老舗ゲーム会社に入社しました。工業高校を卒業してゲーム会社に就職……兄ちゃんはプログラマだろうと思い込み、BASICを教えてもらおうと帰省していた兄ちゃんを質問攻めにしたのですが、
「俺、音楽担当だから……」
教えてもらえませんでした。
しかたなく、母にお願いして通信講座の「パソコン入門」を受講しました。この講座の主な内容はBASICプログラミングの解説で、テストの平均点を算出するプログラムや単純なシューティングゲームを作成する課題が与えられる程度でした。
小学生のころ、何度かPTAの行事として廃品回収が行われました。学校のグラウンドに回収してきた瓶や古新聞、古雑誌などが集められてきました。その回収品の山の中から見つけたのが、電波新聞社が発刊していたベーマガことマイコンBASICマガジンでした。ゲームのプログラムがたくさん掲載されていましたので、頑張れば無料でゲームができると思って、こっそり持ち帰りました。
当時の発売されていたパソコン、ポケコン向けのプログラムが1機種あたり1～2本ずつ掲載されていました。小学生だったわたしには、掲載されたゲームプログラムを入力して遊ぶのが精一杯で、とても自分でゲームを作って投稿する力はありませんでしたし、Dr.Dのコメントはちょっと難しすぎました。
掲載されたプログラムは1～2ページにぎっしり印刷されているので現在入力している行を見失いやすく、プログラムを入力し終えてもエラーを多発させてました。特にIllegal Function Call というエラーは指示された行にバグがないことが多く、デバッグにひと苦労でした。
中学1年生のとき、成績がどんどん悪くなるわたしに対して、父が成績が良くならないだろうと、
「もし、入学当時の成績（30位）より良くなったら、好きなもの買ってやる」
と馬鹿にするので、ムカッときたわたしは、買ってもらえないであろうPC-8801 MHを要求しました。そして、母に頼み込んで全教科の参考書を買ってもらい、猛勉強。そのおかげで、ギリギリ条件をクリアできて、PC-8801 MHを父に買ってもらいました。付属ディスクに収録されたデモアニメーションは、いまでも忘れられません。
ベーマガに掲載された「源平討魔伝 エンディングテーマ」を演奏するプログラムを何気なく入力して実行すると、PC-8801とは思えないほど素晴らしい演奏で感動しました。とてもFM音源3音+PSG3音3で演奏していると思えませんでした。このプログラムの作者がYK-2（古代祐三さん）でした。
高校生になったころ、ちょうどベーマガにゲーム音楽の楽譜が載るようになったこともあって、彼のコードを真似てゲーム音楽を演奏するプログラムを自作するようになりました。FM音源の知識も音源チップの癖もマシン語も分からないわたしには当然、彼ほどスゴイ音楽プログラムを作ることができませんでした。
その後、大学へ進学して情報工学を勉強し、卒業後に現在勤めている会社に就職しました。きっと彼のプログラムに出合っていなければ、別の進路……学校の先生4になることを選んでいたのではないかと思います。
1 実家の屋号をペンネームにしました。
2 本に掲載されたソースを打ち込んだだけでプログラミングとは呼べませんが……
3 PC-8801シリーズに搭載されたYM2203はあわせて6重和音しか出せませんでした
4 一応、高等学校教諭第一種免許状（工業）を持ってます。宝の持ち腐れですが……