一応、動作はTiStorekit1.4、Titanium Mobile SDK 1.8.1、非消費型コンテンツで確認しています。

iOSの場合、課金の手続きは

• In App Purchaseが有効になっているかを確認する
• 正しいProduct IDかを確認する
• 購入開始
• 成功ならレシートを受信してチェック、キャンセルやエラーならエラー処理

となります。ここではAppcelerator社から公開されているTiStorekitを使った実装の例で説明します。以前に実装したものを参考にざっと書いた関係で、細かい条件は検証していませんのであしからず。CoffeeScriptだけどいいよね？

事前にiTunes ConnectでIn App Purchaseの設定が完了していることが前提になります。iTunes Connectの使い方は割愛しますが、支払い関連の設定が完了していないとIn App Purchaseは有効になりません。またProvisioning Portalで設定を確認して、正しいProvisioning Profileでビルドしましょう。iOS5からシミュレータからも利用できるようになったようですが、必ず実機で動作確認してください。

そうそう、下のコードではコンストラクタで@SANDBOXをtrueにしていますが、リリース時には変更しましょう！

class InAppPurchase
  constructor:()->
    @ERROR_PRODUCT_ID = {type:'product_id', message:L('inapp_error_product_id')}
    @ERROR_CANMAKEPAYMENT = {type:'canmakepayment', message:L('inapp_error_settings')}
    @ERROR_UNKNOWN = {type:'unknown', message:L('inapp_error_unknown')}
    @SANDBOX = true

  start:(data, success, error)->
    ###
    args  dataは課金対象の商品オブジェクト（{product_id:プロダクトID}）
          sccess、errorはそれぞれcallback関数
    ###

    storekit = require 'ti.storekit'
    if data.product_id == '' || data.product_id == null || data.product_id == undefined
      # なんて防衛的なコード！ #
      error(@ERROR_PRODUCT_ID)
    else if !storekit.canMakePayments
      # AppStoreが有効になっていない #
      error(@ERROR_CANMAKEPAYMENT)
    else
      # 正しいProduct IDかどうかチェック #
      storekit.requestProducts([data.product_id], (e)=>
        if e.success
          product = e.products[0]
          if product != null
            _success = success
            _error = error
            storekit.purchase(product, (elem)->
              if elem.state == storekit.FAILED
                error(@ERROR_PRODUCT_ID)
              else if elem.state == storekit.PURCHASED
                callback = (response)=>
                  if response.success && response.valid
                    _success()
                  else
                    _error(@ERROR_UNKNOWN)

                # subscriptionの場合は下のオブジェクトにsharedSecretプロパティを追加 #
                args = {
                  receipt:elem.receipt
                  sandbox:@SANDBOX
                  callback:callback
                }
                storekit.verifyReceipt(args)
              else if elem.state == storekit.RESTORED
                storekit.restoreCompletedTransactions()
                success()
              else
                Ti.API.info "purchasing..."
            )
          else
            error(@ERROR_UNKNOWN)
        else
          error(@ERROR_PRODUCT_ID)
      )
TiStorekit = new InAppPurchase()
TiStorekit.start(product, success, error)

canMakePaymentsは定数でiOSの設定画面でAppStoreが有効になっていないのでそもそもアプリ内で課金ができない場合はfalseになります。requestProductsでProduct IDが正しいかどうかを確認し、purchaseで購入処理を開始します。successが返ればveryfyReceiptで確認して完了処理を実行します。

レシートの確認まで実装しましたが、ここは迷うところですね。通信に時間がかかったり、またはこのタイミングで処理が中断してしまった場合、利用者にとってはお金を払ったのに購入が正常に完了しないように見えてしまいます。時間がかかるようならキューに入れてレシートは後で確認し、いったん完了処理をしてから、不正があったらそれなりの処理をする、といったような手段で対応するしかないでしょう。かといってレシートを確認しないと、不正な利用を完全に防ぐことができなくなります。

男子バレーボールが世界的にお世辞にも強いチームとはいえない状態が20年くらい続いているのはご存知の通り。オリンピックでは1992年の6位を最後に上位入賞どころか予選敗退が半分以上になっている。日本に極端に有利な条件で実施されるワールドカップですら、出場が12カ国となった92年以降の成績だけみても95年の5位を最高に後は9位か10位だ。ちなみにワールドカップというのは、4年に一度、常に日本で開催される大会で、オリンピックと世界選手権と合わせて一応「世界三大大会」のひとつなのだが、ジャニーズとフジテレビが派手なキャンペーンを繰り広げ、耳をつんざくような黄色い声でひたすら日本を応援するジャニーズのファンが押し掛ける異空間だ。日本チームの出場は必ずテレビの放映時間に合わせて日程が組まれるのでコンディショニングでも非常に有利になっている。さすがに試合前のジャニーズのショーは国際バレーボール連盟の要請で中止になったらしいが。

かつて、といっても1970年代だが、日本はオリンピックで金メダルを獲得したこともあり、何度も上位入賞を果たした強豪国だった。当時の監督で先頃亡くなった松平康隆のPRマンとしての手腕もあり、80年代までは人気の上では絶頂期だったといえる。だが、その頃から徐々に坂を転げ落ちるように国際大会での成績も下降して、人気も凋落していった。近頃は小学校でのバレーボール人気が復活しつつあるそうだが、それもこの年代にファンだったりプレーしていた人たちが親になって自分たちの子供に教えているからだそうだ。

さて、ではなぜ日本代表が弱くなってしまったのか。その理由として最も多く挙げられるのが、身長の問題である。リベロ制度やサービスエリアの撤廃、ラリーポイント制で、とにかく背が高く攻撃力のあるチームが有利になったために日本が活躍できない、というわけだ。実際、身長を比較してみると、確かに世界ランク1位の常連国ブラジルが平均身長197.8cm、中央値197.5cmのチームであるのに対して日本代表の平均身長は7cm程度低い190.6cmとなっている。両チームからリベロを抜いたり、中央値をみてもさほど変わらないので傑出して足を引っ張っている選手もいないようだ。伝統的に身長の高い選手が多いロシア（ロシアではブロックは「壁」ではなく「屋根」という、と昔教えられていましたが本当でしょうか？）もおそらく同じような結果になるだろう。確かに、これもひとつの理由はありそうだ。

だが、それで疑問は全て解決するわけではない。なぜ、背が低いのだろうか。平成20年度の日本人男性の平均身長は25歳から29歳で172.11cm、標準偏差が5.59となっている。サンプル数もそれなりに多い(380万人くらいらしい)ので信頼できる数字だと仮定すると、統計的にはおよそ全体の70%くらいの人たちが166.52cmから177.7cmの範囲内に収まっていることになる。また95%が160.93cmから183.29cmの範囲内にいることも予想される。つまり、チームに入れそうな年齢の男性の5%しかこの範囲から外れる人はおらず、その中でも半数以上（おそらくhydeとか）は下の方にはみ出しているので、下手をすると2%や1%の人材から選手を調達しない限りは高さで世界各国と対抗することは出来ない。

というとなんだか絶望的に聞こえるかもしれないが、日本の人口はとても多いので、25歳から29歳までの男性は380万人もいるのだから、この2%なら実は7万数千人も候補者がいることになる。世界ランク5位のセルビアの総人口は1,000万人に満たず、成人男性の平均身長は178cmだ。200cmの人口は日本より少ないと予想される。つまり、日本は単純に背の高い人材を確保できていないか、育成できていないだけなのではないか。

では、それはコーチングの問題なのだろうか。そう単純な話であれば、外国の指導者を連れてくるだけで事態は改善されるだろう。しかし、状況をみるにそうではないように見える。なぜなら、バレーボールの周辺環境は非常に厳しいものだからだ。

ここからが結論になるのだが、なぜ男子バレーボールが弱いのか（そして、なぜ女子はまあまあなのか）は、手っ取り早くいえば男性の平均年収と女性の平均年収の違いが原因だ。バレーボールは一日6時間以上練習することが出来るので実業団の選手は午前中だけ勤務して練習するか、朝から練習している。このような生活を30歳くらいまで続けるとどうなるか。同じ企業チームでもラグビーではそんなことをしたらみんな死んでしまうので、基本的には定時で上がってから練習をする。曲がりなりにも定時までは仕事をしているので、ラグビーの選手なら引退後もなんとかなるかもしれない。実際、早めに引退して仕事の方で本格的なキャリアを積むケースが多い。でも、バレーボールの他には何もせず、ほとんど業務経験もないまま過ごしてきた30歳に出来る仕事なんかあるだろうか。指導者として残る人などごくわずかであり、大半はとりあえず物流など力仕事中心の部署で自分よりずっと年下の人たちに混じって再スタートすることになるか、そのような環境にも居づらくて退職して連絡がつかなくなる。ましてや、プロ契約など結んでしまっては引退後の身分保証はほとんどない。給与をもらっている男性の平均年収は533万円くらいだが、このレベルになるためにはいつまでも選手を続けていては無理なのだ。男子バレーボールに人材が集まらない理由は、食えないからである。

一方、同じく女性の平均はそれよりずっと低く271万円なので、正社員であれば定時上がりの仕事であってもこのレベルに到達するのはさほど難しくはない。そのため、選手を続けてそのまま会社に残ったとしても、一部の専門職を除けばとりわけ同世代と比較しても待遇が悪いこともない。ましてやこの不景気に実業団に属してプレーすることができればかなりいい身分であるともいえる。

以上が男子バレーボールが強くならない理由だ。細かいところを見れば他にもいろいろあるだろうが、ここが根本的に対策されない限りは、このスポーツに未来はない。

以上のような状況を鑑みるに、もしあなたがObjective-CやJavaでの開発に不安が残る状態であるなら、迷わず後者の方を選択するべきでしょう。その上で、自分の開発しているプラットフォームについて知ることは重要であり、そうであればいずれはネイティブな言語での理解が必須になるでしょうから、得られる知見を最大限に活かしてObjective-CやJavaでの開発について学んでいくのが理想です。例えば、PHPを使って開発をしていても、それだけしか知ろうとせず、ウェブサーバやPHP自体の実装といった抽象化されて隠された部分に分け入って進もうとしない人が、筆者の経験ではありますが、競争に耐えうる優秀な人材であった試しはありません。幸いにもサードパーティーのツールにはソースコードにアクセスできるものもあるので、良い手本になることがたくさん見つかるでしょう。

では、数あるサードパーティーのツールの中で、一体どれを選べばいいのでしょうか。

もちろん、おみくじで決めたとしても、それは当人の責任の範疇ですから、全く構いません。しかし、それでもやはり、いくらなんでももう少し真面目に考えないと不安になるかもしれません。なので、そうですね、それぞれのツールの特徴を掴んだ上で判断する方がいいでしょう。私自身も決定的な答えを用意しているわけではないので、知っている範囲で自分の意見を述べたいと思います。情報は最新とは限りませんので、ここは違う、いや今はこうなっている、などなどご意見あれば是非聞かせてください。いずれにせよ、現段階ではちょっとした宗派の争いみたいになりがちな話題なので、リラックスしてお読みくださいね。

サードパーティーのツール、と上ではひとくくりにしましたが、大きく分けるとこれも二種類に分かれます。ひとつはPhoneGapやRhodesのようにHTMLとJavaScriptで作ったUIをWebView（UIWebView）を使って表示させる、ウェブアプリとネイティブアプリが合体したようなもの、もうひとつはTitanium MobileのようにネイティブなAPIを叩いてJavascriptで記述しながらネイティブアプリとして動作するものです。ここでは実際に使ったことのあるPhoneGapとTitanium Mobileを比較します。

私見では、PhoneGapのいいところは第一にそれがシンプルであることです。例えば生成されるJavaのクラスは非常にシンプルで、実際に使ってみたところカスタマイズも容易でした。APIも数えるほどしかなく、プラグインの作成もそれほど難しいものではありません。また、UIはHTMLとJavascriptで作るので、ウェブ開発者やデザイナのこれまでに培った技術を活用することができそうです。

それに、例えばFacebookアプリは現在PC向けのものはHTMLで作られていますが、モバイル向けも今後は同じくHTML5を利用して記述され、Facebookのモバイル用アプリ内で動作するといったものになっていくことが予想されます。クロスプラットフォームでの開発が容易なのはHTMLの強みですから、こうした流れにソーシャルゲームのプラットフォームも追随していくのではないかと思います。

しかし、欠点もないわけではありません。jQuery MobileやSencha Touchといったツールを使ってなるべくネイティブアプリに似せることは出来ますが、それでもUIはネイティブなものではありません。これらのツールキットはまだ開発されてから日も浅くベストプラクティスも少ないので、開発はお世辞にも快適とはいえないのですが、それなのに特にiOSではHTMLとCSSででっち上げた「ネイティブっぽい」UIの「偽物」っぽさが際立ちます。動作もまだまだ快適とはいえません。またネイティブな機能への橋渡しをしてくれるAPIも豊富とは言い難いので、少しでも複雑なことに挑戦すると結局Objective-CやJavaでプログラムを作成する必要が生じます。UIレベルの話ならまだしも、例えばiCloudへの対応といった要求にはツール側での対応を待つかそれなりの工数を費やしてプラグインを作成することになってしまうでしょう。それに、これは年月が解消してくれる問題なのかもしれませんが、例えばSnapdoragonの第1世代のIS03のような貧弱なハードウェアではWebViewのようなリソースを消費するものはどうしても動作が遅くなります。オリエンテーションの変更の際にレイアウトが酷く崩れるといったユーザに不安を与えるような現象が発生することもあります。

最近、PhoneGapの開発元がAdobeに買収されることが発表されましたが、資金的には大きな後ろ盾を得たと同時に、大企業であり、これまで数々のプロダクトをディスコンにしてきたAdobeにその命運を握られてしまったともいえます。

以上、駆け足ですが個人的に思うところを述べてみました。先ほども書きました通り、ここは違う、いや現在はこうなっているといったご意見などございましたらお知らせください。

さて、その一方でTitanium Mobileの場合、Javascriptで記述した内容は評価された後にプロキシを通じてiOSやAndroidのAPIに渡されて実行されるため、実際に動作するのは通常のアプリと同じものなので外観は全くネイティブなアプリと変わりません。と同時に、Titanium.UI.WebViewというものが用意されているので、やろうと思えばHTMLとJSでUIを作ってしまうことも可能です。またこのJSとネイティブな機能を繋ぐのも非常に容易なので、この点でも大きなアドバンテージがあります。動作速度はネイティブアプリと比較すれば、インタプリタとコンパイル言語ほどではなくても、まあある程度の差はあります。しかし、シビアな反応が求められるゲームや電子書籍リーダといった特定用途のアプリでなければ実際に問題になるほどではありません。ネットワーク越しにデータをやり取りするアプリ、ウェブサービスのフロントエンド用アプリとして利用するには十分といえます。それに、驚くべきことに、最近ではQuickTiGame2dのような高速で動作するゲームエンジンも開発されていますので、ゲームの開発に利用されるようになる日も近いでしょう。また、このようなサードパーティーのモジュール開発も盛んで、Open Mobile Marketplaceで有料、無料を問わずたくさんの機能拡張用モジュールが公開されています。Githubにソースコードが公開されているものも少なくありません。

それから、jQuery MobileやSencha Touch(Ext.JS)といった一種独特なJavascriptよりも、commonJSといったモダンなJavascriptで記述することが推奨されているのもポイントです。最近ではNode.jsのようなサーバサイドのJavascriptもありますが、Titanium MobileのJavascriptもCoffeeScriptやcommonJSのような今時の技術を習得する近道となるでしょう。というのも、Titanium Mobileは基本的にはよくあるイベント駆動型のGUIのプログラミングなので、Node.jsのようなコールバックにつぐコールバックの連続にも面食らうことはありません。

と、いいことばかり並べましたが、もちろん問題もないわけではありません。Aptanaを買収してEclipseベースの独自のIDEがリリースされましたが、Eclipseがそうであるように人によってはあまり快適とはいえないものです。もちろん使わないで開発することも可能ですが、最初はやはり公式なツールを使いたくなる方も多いでしょうから、そこら辺で面食らうこともあるかもしれません。またビルドスクリプト内部にビルドにかかる時間短縮のため高速化する工夫があるのですが、何度も繰り返してビルドするうちにそれが邪魔をしてアプリの挙動がおかしくなることがありますので、ときどきCleanしてあげる必要があるといった癖のあるところも見受けられます。また海外製品にありがちなことですが、Pythonを使ったビルドスクリプトはUTF-8のMac OS Xで日本語の処理に問題がある箇所が多数ありますのでアプリ名称やプロジェクト名、ソースコードのフルパスに日本語が含まれていると辛い目に遭います。その辺りは、日本語でも有志によるサポートコミュニティがありますので、活用してください。

これらは今後改善されるべきことではありますが、一方で大半は公開されたソースコードから追いかけることも可能なことであり、ついでにいえばパッチを送って直してしまうことだって出来ます。個人的には、いつか大金持ちになって暇を持て余すようになったら、面倒の多いPythonの部分を全部Rubyにしてしまいたいと思っています。また、Titanium Mobileを入り口としていろいろと学びましたが、逆にネイティブな言語で開発しなくてもいいやという気にもなってきました。やっぱりDelegateとかってうんざりますよね？

以上、駆け足で比較していきましたので粗雑な部分、間違いなどもあるかもしれません。上にも何回か申し上げましたように、これは違うぞ、といったところがあればどしどしご指摘ください。よろしくお願いします。

例えば、ここになんともいえず愛らしい息子の写真があるとします。縦横サイズは1536 × 2048ピクセルです。ちょっと大きいのでここでは縮小して表示しますね。

これを半分（768 x 1024）にリサイズします。大きいので表示は縮小します。

全く問題ありません。

じゃあ、1/8にしてみましょう（192 x 256）。こちらは実物大。

全然問題ありません。パパは萌え死にそうです。

ですが、これを1/10（153.6 x 204.8）にしようとすると、おかしなことになります。

あれ？切れてるよ！？まめちゃん切れてる！許せない、もう絶対許せない！

思わずモンスターペアレントになってしまいました。なぜこんな現象が起きるかというと、このモジュールはAndroidのBitmapクラスを利用しているのですが、こいつがbitmapデータの作成時に縦横サイズとしてintegerしか受け付けてくれないからです。1/10に縮小しようとして縦横サイズをfloatで指定しても途中でキャストされてしまいます。そうなった場合、縦横比もおかしいのでうまくリサイズされなくなります。モジュールは内部的にはメモリ節約のためいったん近似値までリサイズするようになっているのですが、どうやらそこから先はこの状態だと細かいリサイズをしてくれないで画像を切り取って処理してしまうようなのです（この辺の理解は適当）。

元々、このモジュールは同時期に作ったCropImageモジュールと併用して、縦横サイズが前もって予測できた上で使うことを前提としていたので、その辺りは細かい調整をしていませんでした。で、今日ちょっと質問されたので眺めてみましたが、上のような事情でうまくいきませんでした。何かうまい手はないでしょうか。例えば縮小する際に縦横サイズを指定するときは最大公約数を計算してどちらもちゃんとintegerになるようなヘルパーを用意するとかですかね。

来年からどうやっていこうか、考えてみました。別に好きでひとりでやってるわけではないので、どうしてもフリーランスを続けたいわけではありませんが、ここまでボッチだと我が人徳の無さはもはや人類史に足跡を残すほどであると考えるのが妥当だと思います。かの偉大なるポール・グレアムもこんなことを書いています：

創業者が1人であるのは何が問題なのだろう? まず何より、それが不信任投票だということがある。それはおそらく、その創業者が一緒に会社を始めてくれる友達を誰も見つけられなかったということを意味する。これはすごく憂慮すべきことであり、彼の友達は彼のことを一番よく知っている人たちだからだ。

実に身につまされる話です。これだけハッキリと不信任決議を突きつけられているのですから、いい加減に目を覚まして、どこかしっかりしたところで落ち着いて勤め人をやるのが筋というものです。そんなわけで、2012年は勤め先を探す年にすることにしよう。それまでには、いくつか考えていたプログラムを作って発表しておきたいので、頑張ります。

ぐっどうぃる博士の音ライブラリ

今回はリモートの音声データをストリーミング再生、またはダウンロードして保存するアプリを作成しました。音声データは今後どんどん追加されていきますが、新着データがあればトップ画面を表示中にTwitterクライアントみたいに勝手に追加されていきます。

TEDみたいな感じで、回線状況に関係なく再生したい方はダウンロード、ちょっと聴いてみたい方はストリーミングを選べるようになっています。ダウンロードしたデータはプレーヤー画面のスライダーを操作して好きなところから再生することができます。

再生画面

Titanium Mobileで苦労したところはこの再生画面で、最終的にはTitanium Mobile自体に手を入れてしまいました。プラグインにしてもよかったのですが、それは今後の課題です。簡単な変更で動画プレーヤーの実装が楽になるので、これは実装してほしいんですけどねえ。

Titanium Mobile側の変更は以下の通り：

diff --git a/iphone/Classes/TiMediaVideoPlayerProxy.m b/iphone/Classes/TiMediaVideoPlayerProxy.m
index 93cd37c1..3ad7116 100644
--- a/iphone/Classes/TiMediaVideoPlayerProxy.m
+++ b/iphone/Classes/TiMediaVideoPlayerProxy.m
@@ -660,6 +660,11 @@ NSArray* moviePlayerKeys = nil;
        }
 }

+-(void)setCurrentPlaybackTime:(NSNumber*)time
+{
+  [movie setCurrentPlaybackTime:[time doubleValue]];
+}
+
 -(NSNumber*)currentPlaybackTime
 {
        ONLY_IN_3_2_OR_GREATER(currentPlaybackTime)
@@ -1172,4 +1177,4 @@ NSArray* moviePlayerKeys = nil;

 @end

これでスライダー付きの動画プレーヤーが簡単にできちゃうんですが、実は困ったことに1.8系からは現在の再生時間をこれまでと1,000倍も違うミリ秒単位で返すようになったので、スライダ部分は今後は更新が必要になります。地味に嫌な仕様変更です。

音声再生中にsetIntervalしたobserverが再生状況をみてスライダーを同期させるので、手で触ってスライダーを動かしたのと区別する必要があります。そこでtouchstartイベントを取得して、終わったらtouchendで解放するようにしました。

###
playerはTi.Media.createVideoPlayerしたオブジェクト
progressはTi.UI.createProgressBarしたオブジェクト
###

moved_by_user = false

progress.addEventListener('touchstart', (e)->
  moved_by_user = true
  return
)
progress.addEventListener('touchend', (e)->
  slider_value = e.value
  if player.duration
    to = parseInt(player.duration * (slider_value / 100))
    player.setCurrentPlaybackTime(to)
  moved_by_user = false
  return
)

observer = ()->
  if moved_by_user == false
    if player.currentPlaybackTime > 0
      current_time = player.currentPlaybackTime
      val = current_time / player.duration * 100
      progress.value = val
      return
timer = setInterval(observer, 1000)

こんな感じで実装しました。フォーワンファースト社のみなさん、辛抱強くお付き合い頂きありがとうございました。

4月中に夢を砕いてくれたのは、せめてもの優しさだったのだろうか。蓋を開ければ、キャリア最低の成績に終わった松井とデヘスス、あまりにお粗末な成績に最終的には放出されたジャクソン、トリプルA送りとなったバートンとクーズマノフと死屍累々たる有様。とうとう開幕戦に出ていた内野手はシーズン途中にはペニントンだけとなってしまった。スウィーニーはパワーの無さだけが目立ち、ココ・クリスプはやることがないからだろうか、ひたすら盗塁し続けた。おまけにシーズン途中で監督もクビになった。それだけではない。ピッチャーにしても、長期契約を結んだ途端に1年以上リハビリが必要な怪我をしたブレット・アンダーソン、同じくシーズンを棒に振ってしまった昨年の完全試合男ダラス・ブレイデン、相変わらず2ヶ月くらい怪我で休むクローザーのアンドリュー・ベイリー、中継ぎで8敗という前半戦最強の壊し屋っぷりを見せつけたブライアン・フエンテス、もう何の怪我か忘れたけどとにかく離脱した先発のタイソン・ロスなどなど、たぶん呪いとかの超自然的現象でいいんじゃないかと思うほどの惨状だ。

もちろん、悪いことばかりではない。ウィリンガムは前半こそひどい成績だったが、ただでさえバッターに不利なことで有名な広い球場をホームグランドにして、終わってみればキャリアハイの29ホームランだったのだから立派なものだ。これでサラリーが跳ね上がり再契約できなくなって他所のチームにかっ攫われることになる（2012年からはミネソタで長期契約となった）のを考えなければ、とても素晴らしい。そして怪我ばかりの兄リッキー・ウィークスと同じくずっと怪我に苦しんでいたジェマイル・ウィークスが華々しくデビューを飾り、そのまま好成績で年間を通した活躍した（その結果チーム在籍年数が最も長かったマーク・エリスが放出されてしまった…）のも明るい話題だ。もっとも、負け続けて起用されるようになった若手が増える中、この数年で最も期待されているクリス・カーターやマイケル・テイラーが全くメジャーでは通用しないことも分かったのだが。まあ、他にもトリプルAで素晴らしい成績を叩き出したギレルモ・モスコソがメジャーでも十分活躍できることもわかり、それから遂に公開された映画『マネーボール』は批評家ウケもいい手堅い出来だった。

オークランドの迷走の原因といわれているのが、本拠地の移転問題が解決していないことだ。数十キロ離れたサンノゼにシスコシステムズから提供された土地があり、そこに球場を建設して移転する計画が持ち上がってからもう何年かになるが、2012年の1月まで決着がついていない。サンフランシスコ・ジャイアンツのフランチャイズでもあるので、その辺りの問題が解決していないせいだというが、どうやら今年結論が出るという噂である。そうなると、移転は2014年ということになり、その時点までに強いチームを作るという本当の再建モードになるわけだが、この冬の大胆なトレードをみるにつれ、どうやら本当に今月には移転問題の決着がつきそうな感じだ。

というわけで、2012年からのオークランド・アスレティックスは、今年と同じかそれ以下の期待しか出来そうもない。噂はあったが、本当にオールスターに選出された経験のあるピッチャーを全て放出してしまい、放出した選手もみんなまだ若かったが、それよりさらに若い選手ばかり揃えたところなど、むしろトリプルAやダブルAの試合の方が面白いんじゃないかと思わせるくらいだ。

といいつつ、でもそんなトレードで獲得したジャレッド・パーカーは実は次のダン・ヘイレンになるんじゃないか、トム・ミローンはダラス・ブレイデンあるいはもっと凄くてトム・グラヴィンみたいになっちゃうんじゃないか、などと妄想をたくましくしてしまうのが、ファンというものでもある。

———————————————————————–
ランチ

いつもランチのときはどうしてる？どこで食べる？誰と？

毎日ランチを一緒に食べるチームと過ごしたことがあるけど、素晴らしいものだった。そうしないチームと過ごしたこともあるけど、毎日のランチの時間はひどく寂しいものだった。

大きなハイテク起業にはたいていカフェテリアがあって、無料（Google）だったり有料（マイクロソフト）だったりする。こういう会社にだって毎日食事を一緒にしようと努めているチームもあるけど、ほとんどのチームはそんなことはしない。ランチタイムにこの手の場所をうろついてみると、「ランチミーティング」をスケジュールに入れていた2人組をたくさん見かけることになるわけだけど、同時にひとりぼっちで食事している寂しい人たちも悲しいくらい大勢見る羽目になる。きっとその手の人たちは食べながら本を読んだりメールをチェックしたりしているから悲しんでいるようには見えないだろう。自分の机にランチを持って行って食べるからカフェテリアに独りで座ることもないかもしれない。きっと本当に人が嫌いで独りで食事する方が幸せなのかもしれない。あるいは、口でそう言っているだけなのかもしれない。

GoogleやMicrosoftでは、カフェテリアはとても混雑するので、ボッチの人は他のグループと一緒に座らなければいけない。というのも、テーブルを自分だけで専有するだけの余裕がないからだ。ときどき、一緒に座ったグループの人たちがボッチを会話に引き込もうとすることがある。でも大抵の場合、ボッチは社交的コンタクトの必要性を回避するためにスマートフォンでFarmbookをプレイするのに完全に没頭しているふりをするよう強いられている。すいません、自己紹介したいのはやまやまですが、キャベツのアップデートが忙しくて。

ランチをどこで誰と食べるのかはみんなが考えているよりもずっと大きな問題だ。心理学者の意見は決まっている。子供の頃を思い返せば、特に学校時代、それも中学生の頃は、どこで誰と食べるのかは記念碑的重要事項だったのはいうまでもない。どんな集団に入っても、たとえそれがヲタ連中であっても、ひとりぼっちで食事するよりずっとましだ。ボッチとギークにとって、学校のカフェテリアで一緒に食事する相手を探すのは多大なストレスの原因となり得るのだ。

私にいわせれば、仕事の同僚と一緒に食事をすることの重要性には議論の余地はない。運まかせにするには重要すぎることだ。だから私たちは、小さい丸テーブルたくさんではなく、長いテーブルで一緒に食事することにしている。そのため、新しくこの会社で働くことになった人が隅っこで独りで座るなんてことはあり得ない。お客さんが居れば、みんなで一緒に食事する。

Stack ExchangeとFog Creekは完全に分離した会社組織だけれど、それぞれのオフィスが同じビルにある利点を活かして毎日一緒に食事している。多くの人たちが仲間になって毎日同じ面子で固まっているが、それでもこれが実現できてとてもよかったと思っている。

Fog CreekにもStack Exchangeにも行き当たりばったりなことはたくさんあるけれど、ランチは違う。10年前、マイケルと私は最高の仕事場を作るというかなり野心的な目標を立てた。一緒に食事するというのは人間であること、人間らしい職場を持つことにとって重要な意味があり、初日からそれは私たちの持っている価値の一部であったわけだ。

Gimpで5分、モダニズム風クリスマスカード。

もっとも、貴方がよっぽどのエンタープライズ系の仕事をしているのでなければ、そんなにすごい大物な人に出会うことはありません。筆者のような零細の技術者であれば、巡り会うのはせいぜいケチな小悪党くらいのものです。こんなのに手こずるとは余っ程ダメ人間なんだなと笑われそうですが、これから同じような目に遭うかもしれない人たちのために、フリーランスになって出会った困った人たちについてまとめておこうと思います。ちなみに筆者は自分でコンテンツを立ち上げてそれで食べているわけではなく、受託案件で生活をまかなっているので、企業や企業の担当者との話に限定されます。

正直、恥をさらすようなものですが、それでも何かの教訓になればいいと思うので書いていきます。それにしても、トラブルのほとんどが「受注／発注処理があいまいである」ことが原因だったのがなんともいえません。

（1）受発注処理がきちんとしていない隙を狙う

営業と開発を同時にこなすのはなかなか大変なので、どちらかがおろそかになりがちです。通常、受託案件は見積りから営業の交渉があり、金額が決まって案件の発注、受注という流れになりますが、例えば知人やクライアントの紹介などで担当者同士で話がまとまり、正式な手続きなしで仕事が始まることもあります。そんな場合でも、見積りを出すこと無しに仕事が始まることは経験上一度もありませんでしたが、逆に受注と発注の処理は省略されるか後回しになることが結構ありました。

しかし、残念なことに、この手のケースは大抵後で問題が起きました。

例えば、ある開発案件では、新規案件のために200万の見積りを提出しました。B2Bのサイト構築で、内容はオーソドックスなウェブサイトなのですが、短期間での開発が求められるためRuby on Railsでの構築を提案したところ、特に問題ないとのご回答を頂き、何度か打ち合わせた後、スケジュールや素材が届いたので初期開発まで完了しました。正式な発注処理はなかったのですが、前に同じクライアントの別案件を請け負っていたこともあり、その流れで他とコンペになってもいなかったので、その辺りの処理は相手方にお任せ状態でした。開発は特に滞りなく進み、期日にも間に合ってめでたしめでたし、となるはずでした。

ところが、その後案件は二転三転します。サイト規模から事業計画まで、クライアント側で次々と変更が発生し、サイト自体がオープンしません。途中大きな変更が入り、結局、4ヶ月後になってやっと検収が完了したのですが、ほぼ同内容のものを二度構築するような目に遭いました。それでも、終わってしまえばまあよしとしましょう。残るは請求などの事務処理だけです。200万の案件ですから、以前会社に所属していた頃はなんでもないような金額ですが、フリーランスにとっては大金です。さらに、来年早々に出産を控える家庭にとってはありがたい話です。トータルで二ヶ月くらいは働いたので、報酬としては悪くありません。

しかし、この段になって急に呼び出しをくらいました。一次受けと筆者の間に入っていた業者が金額の調整がしたいというのです。なるほど、実はこの案件、最後になって要件の追加があり、その分については後日開発となっていました。しかし追加分については、当初の見積りの金額でカバーしても問題ない規模だったため、特に追加請求はしないことにしました。そのため、総額が支払われなくても追加分を除いた分でいったん清算する方が、追加分の検収を待ってまた支払いが延び延びになってしまうより余っ程ありがたいくらいだったのです。ところが、待ち合わせ場所で聞いたのは意外な話ばかりでした。開口一番、この案件の見積りは幾らだったのかと質問されました。見積りを提出したのはもう何ヶ月も前のことです。しかし出したことには変わりはないのですから、それを忘れたというのは幾らなんでも失礼です。何かあるぞと、今は手元にないので確認したいと返答したところ、その場で実際の稼働状況について聞き取り調査をされました。おおまかなところを答えたのですが、先方の担当者は渋い顔をしています。そして、おもむろに紙を取り出して計算を始めると、顔を上げて「これじゃ厳しいですね」と言い出しました。「あなたの日当が3万円として、総額にすると約70万円、でもこれだと予算を越えちゃうんだよね」「予算？予算って幾らなんですか？」「30万円」

驚きました。まず、なぜこの人がこちらの日当を勝手に決めて計算しているのかがわかりません。業界の相場というものがあるのかもしれませんが、それはそれ、こちらの見積りは見積りです。だいたいバイトじゃあるまいし、そんな日当で仕事をするつもりなど毛頭ありません。それから、なぜ今頃予算の話になるのでしょう。それに納品してから金額を調整するというのはいったいどういうことでしょうか。もう、わけがわかりません。業務の中にはサーバ構築など技術料をプログラム開発とは別にしたい項目も含まれるので、単純に日雇いの計算などされるいわれはありません。そもそも見積りと全く関係のない、しかも恐ろしいほど低い金額で話を進めようとする意図が理解できません。

「ちょっと待ってください、最初にこちらから提出した見積りがありますよね？その金額は200万円です。それでOKというお話だったので作業を進めたんですよ。そこに交渉の余地なんかありません。そもそもこの金額は案件の費用の総額の何パーセント分なんですか？」

「それは確認していない」

「だいたい、この金額の案件なら、最初から受注なんかしていませんよ。もちろん、信用していたからといって受発注をきちんとしなかったこちらにも非があります。なので、まずあなたのおっしゃる金額というのは、お客様が開発は何パーセント納品／検収済みで、それに対して総額の何パーセントをお支払いするとお考えなのか確認してください」

「確認しましょう」

「それもわからないということなんですね。これが総額という可能性もあるということですか？」

「確認しましょう」

「（絶望して）今後の開発については、正式な受発注手続き無しには一切進めません。それはご理解ください」

こんな不毛なやり取りだけで打ち合わせは終了しました。この規模の案件ですから、それなりの準備や他のクライアント様とのスケジュールの調整も必要になります。年間で受注する仕事の量もこの見積りをベースにしているわけですから、それが大きく計画と異なることになってしまいます。言い方は悪いですが、これは立派な詐欺です。ソースコードの引き上げも含めて現在いろいろ検討しているところです。

というわけで教訓。大人は信用なんかで仕事を進めてはいけません。営業職には基本中の基本でしょうが、開発の人は忘れがちなので書いておきます。受注、発注は双方でハンコを押した書類が揃って初めて完了です。それまでは開発に着手してはいけません。

（2）業務内容が全て記載されていないのにつけ込む

見積りが複雑になり、案件が当初の規模からころころと変わって何度も見積りを出し直すことになった経験はあるでしょうか。ここに問題が発生する隙が生じることがあります。何度目かのやり取りを経て「では、最後にAndroidとiPhoneのアプリ開発、両方の見積りをください」そんな依頼で提出した二通の見積りで開発が開始された案件で、開発終了後に請求を送ったところ、いや、片方の分しか発注していないと突き返されたことがありました。そういうつもりじゃなかった、とは担当者の弁ですが、意図がどうこうという問題ではありません。しかし、確かに見積書には「スマートフォン向けアプリ開発」と書かれているので、完全に間違っているとはいえませんでした。それはそれで、こちらのミスではあります。片方分の支払いは滞り無く、また担当者に謝罪はされましたが、それでもこちらとしては大損しただけなので非常にがっかりしました。

要件が完全に定まっていない場合、変更要求にどこまで応じられるかの案分も大事です。営業の人は仕事を取ることに必死ですから無茶な要件をねじ込むことも珍しくはありません。携帯サイトを開発していたつもりが、いつの間にかPCに対応し、スマートフォンに対応し、挙げ句の果てには店舗据え置き機器からFelicaで認証する機能まで実装せざるを得なくなった案件がありましたが、この手の話はザラにあります。いくつかの機能は別途費用を請求できましたが、他は営業に押し切られました。別の案件では管理画面の機能がいくつか後になって追加されてしまい、別途請求しようとしても「いや、みんな頑張ってるんですから」と妙な説教をされる始末。

さらに難しいのが、社会人は他人に親切をするのは決して正しいことではないという問題があります。何かトラブルを起こした人がいたとして、親切心から対応してあげるとします。例えば要件定義が下手で必要な機能が含まれていなかった場合、仕方がないので追加費用無しで開発してあげると、その人もきっと喜んでくれるでしょう。ところが、社会人というのは親切を親切で返していたら上司に怒られてしまいますので、こちらのミスで何か実装が抜けていたりなんかした場合には、途端に手のひらを返して責めてくるのが普通です。社畜たるもの「上司＞＞＞＞＞＞＞＞＞＞客＞＞＞越えられない壁＞＞＞＞下請け」という序列を骨の髄にまでインプットしているのが当たり前なのですから。また、そもそもトラブルを起こす人というのは、それなりの理由（無能、怠惰、口に出すのもはばかられるほどの悲しい理由など）があるのですから、この次もまた何かやらかす可能性は高いはずです。今回はたまたまそれがこちらが親切にすれば収束するものであったとしても、この次はそうはいかないかもしれません。そのとき、この人が言い訳として問題をあなたのせいにしてしまうことはあり得ないでしょうか。下請け業者のせいにすることは社会人にとってアリを踏みつぶすくらいの良心の呵責しか感じられない行為だということを理解しておく必要があります。

（3）損失を弁済させようとする

企業間の取引であれば、基本契約やNDAなどは事務型の基本的な作業ですが、フリーランスのプログラマの場合、その手の作業はクライアント側で用意してもらうことも多いかと思います。または、そもそもそんなやり取りもなく開発して納品するケースもあるでしょう。

しかし、基本契約を結ばずに業務を請け負うと、トラブルが発生した場合に面倒なことになります。例えば、よくある契約にはソフトウェアのトラブルが原因で発生した損失については受注金額を補償の上限とする、みたいな条項が含まれています。これがないとどこまで責任を負うべきか不明確になり、裁判になると個人はどうしても弱いので負けることになります。また裁判にはならなくても、下請け業者というのは弱い立場なので無理な要求を飲まされることになってしまいます。クライアントとの間に別の業者が挟まっていたりすると余計にそうなることが多いでしょう。

というわけで、フリーランスの開発者には、ガチガチな契約か、損をしても知らんぷりする余裕のどちらかが求められます。