History

68073708_83

PiyoCastの開発史をご紹介します。もっと詳しい開発日記もあります。

0001: 黎明期

2005/9

iTunesにPodcasting対応機能が追加され、iTunes Music Storeがオープンして1か月ほどたった頃にPiyoCastの原型となるプログラムを開発し、初台のアップルで行われた「Apple Users Group Meeting/Tokyo」でデモを行いました。

Podcastingの番組から楽曲にリンク。再生中にリンクをクリックすることで、楽曲を呼び出せることを実証。「不可能」と言われた楽曲の呼び出しが「可能」になった瞬間でした。

0002.1: Piyocast.com

バージョン1.0系のPiyoCastの完成度が高まる一方で、1.0のテーマとしていた各種機能を有効にするために、専用のWebサイトが必要なことが明らかになりました。そのために、急遽「piyocast.com」ドメインを取得しレンタルサーバーの契約をすることに。

もしも、さる筋から難癖を付けられ不測の事態に陥った時に、機能を一括停止させることでユーザーを争いごとに巻き込まないための「リモート自爆スイッチ」の広域作動実験など、サイトだけを用意しても試すことができず……機能テストを行うためだけにソフトを1本でっちあげる必要があるなど、なかなか一筋縄ではいきませんでした。

そんなこんなでv1.0系の開発がなかなか思うように進まない中、piyocast.comドメインのトップには長らく予告のためのページが1枚置かれるにとどまり、「ぴよまるソフトウェア」Webの「piyo.piyocast.com」のみの存在が国内外に認知されていたのでした。

0002: 第一次集中開発期

2005/10...2006/7

当時のPiyoCastは、iTunes上のリンクをクリックする必要があるものでしたが、たしかにPodcastingの番組中で楽曲を再生できるものでした。

データ作成アプリケーション「PiyoCast Maker」など周辺アプリケーションも充実し、ドメイン「PiyoCast.com」も取得し、「ぴよまるソフトウェアWeb」を立ち上げるも、仕事が忙しくなったり、転居にともない個人の時間がなくなったりで、途中で頓挫してしまいました。

0003: 職場で開発できないか?

2007/2

日中仕事で、定時後に喫茶店や自宅で開発……というわけにもいかず、職場で開発できるようにならないかと社内でプレゼンしてみたりもしたものの、再生時にクリックが必要といったあたりで「これがラジオ放送の代わり、と主張するにはユーザビリティが低い」と判断され、その話はお流れに。

そもそも、内容そのものについて理解できない上司も多く、会社の性格とは合わないものでもあるようで。

ここから、プロジェクト自体の規模は小さいままで進める必要があることと、機能をある程度そぎ落としてリリースする必要のあること、失敗しようが成功しようが職場は一切関係ない(悪) といったことが決まりました。

0004: PiyoCast 2.0構想

2007/5

地道に研究開発を続ける一方で、PiyoCastの開発の進め方を従来のものから大幅に変えることになりました。

(1)開発のステージを細かく分け、そのステージ内の技術目標をクリアしていく

(2)α版、β版ソフトウェアを途中で公開し、サンプルのPodcastも一緒に公開。開発途上のβ版であってもDJ番組を楽しんでもらえるものとする

(3)何から何まで最初に揃えようとせず、徐々にソフトウェア/サンプルのラインナップを充実させていく

(4)PiyoCastの機能を本質的な「楽曲再生機能」にしぼり、まずは中心となる機能の充実をめざす

(5)機能を再生関連に限定する一方で、従来は「Podcast再生中にクリックを行う必要がある」というクリック再生が必要だったものを、クリックレスのハンズフリー再生が行えるようにする

この「PiyoCast 2.0構想」に基づいて開発が進められています。

0005: 第二次集中開発期

2007/5〜6

v2.0系の開発を5月半ばに再開してから3週間あまり。

仕事帰りに奥方様と待ち合わせをしつつ、飯田橋の喫茶店で実証実験用のAppleScriptコードを書いたり、Pen-IT NOTESで紙のノートにアイデアをまとめてはBluetoothでMacBookに転送したり……トム・デマルコのプロジェクト管理の書籍を買っては休み時間に読んでいたり。

v1.0の開発時のように毎日がむしゃらにコードを書くというスタイルではなく、タイミングチャートを紙に書き、MacBookに転送してKeynoteで清書。ふたたびそれで動くかどうかを検討し、フラグのステータスが妥当かどうか確認してみたり……と、机上シミュレーションにずいぶん時間をかけました。

仕事のプログラムだと、打ち合わせて仕様書を作り、仕様書に基づいてコードを書くわけですが、自分で企画して自分でコードを書いて自分で評価するという個人ベースの「俺プロジェクト」だと効率が最優先。通常の数倍のスピードでコードを書いて、機能モジュールが出来次第すぐに実装していくので……プロジェクトの成長過程がいびつになることに気付きました。

つまり、「俺プロジェクト」ではコード作成を重視するあまり、プロジェクトが失敗するリスクが通常のプロジェクトよりも高くなるというわけです。「俺プロジェクト」を成功させるためには、コード実装優先主義を抑える必要がありました。

「俺プロジェクト」でも、それぞれのマイルストーンで十分な検証や評価を行ってから次に進むべきで、十分に検証されない機能を大量に寄せ集めると、それは単なるコードの寄せ集めではなく、まったく別の「何か」として有機的に動きはじめ、各種条件によって予想外の動きをすることも……。

Copyright by Piyomaru Software, all rights reserved.