プログラマの思索

AdobeAirでスマートフォン向けアプリ開発をやっていて、アジャイル開発に向いているなあと思った。
考えたことをメモ。

【元ネタ】
アジャイル開発のボトルネック - Social Change!

資料公開：「納品のない受託開発」にみるソフトウェア受託開発の未来～IT投資に対するソフトウェアの価値を最大化できるビジネスモデルとは - Social Change!

Twitter / @akipii: 最近のシステム営業では紙や画面だけでは客の反応がなくスマートフォンのアプリのように動く物でないと客が食い付かないと聞いた。だから苦労してるらしい。SIの外側はアジャイルを受け入れる環境があるのに変化に付いていけてない。

Twitter / @akipii: 製品発表時のインパクトは小さくとも同じプラットフォームをユーザーが長期間使い続けられるようにデザインされた製品が着実にユーザーへの浸透を果たしている。

Twitter / @akipii: iPhoneシリーズは2009年に発売されたiPhone 3GSが、今でもiOSの最新版を搭載できる。iPhoneは買い時を迷う製品だが、逆に言えば、どの年の製品を買っても長い期間使い続けられる。そうした安心感の積み重ねが、iPhone 4Sの売れ行きにつながっているのだろう

【1】最近の受託開発の営業は、不況のせいもあろうが、文字だけの提案書や画面がついたパワポだけでは顧客の食い付きが悪いらしい。
スマートフォンのアプリのように、動くアプリを見せると興味を持ってくれるそうだ。
実際に動くものを見せないと、顧客の反応が今一つらしい。
だから、客の目が肥えてきているね、という話が出ているらしい。

B2Bの業務システムならばいきなり動くアプリを作るのは難しいだろうが、B2C向けのWebシステムやクライアントアプリの場合、実際に動くものがあった方が営業もやりやすい。
しかも昨今はSNSが大流行しているので、フロント側のWebシステム開発でも、単なるHP作成だけでは顧客も目を引かない。

従来の提案や営業では、システム提案書やら要件定義書やら膨大な資料を作って顧客と打合せする開発スタイルが主流だった。
でも動かないドキュメントや仕様書は、顧客自身も興味が無くなってきている風潮があるのだろう。
SIを取り巻く環境はアジャイル開発に変わっているのに、SI自身がその変化に付いていけてない状況が今の日本のIT業界の現状なのだろう。

【2】スマートフォン向けアプリ開発をやっていると、アジャイル開発にとても向いているなあ、と実感する。
スマートフォン向けアプリ開発の前提条件は、短納期でプロトタイプ重視がとても多い。
3ヶ月や1年間も開発を待ってくれない。いきなり1ヶ月後に動く物を見せることを要求される。

だから、プロトタイプを作って頻繁にVerUpしながら機能拡張していく開発スタイルになる。
無駄なドキュメントそのものを作る余裕もないから、最低限の仕様書を残すだけ。
動かない設計書よりも動くプロトタイプを重視する顧客の姿勢は、アジャイル開発ととても相性はよい。

しかし、アジャイル開発に慣れていない開発チーム、設計書に書かれた仕様を実装する開発スタイルしか知らない開発者にとって、短納期でプロトタイプ重視の開発はとても苦痛だ。
要求や仕様がそもそも確定していないし、コロコロ変わるのが前提だから、変化を受け入れるマインドがなければとてもやってられない。

アジャイル開発ならば、イテレーション単位で変化を受け入れて制御しようとする。
その中で重要なポイントは、どんな仕様に不明点や質問があるのか、という課題管理だと思う。
そういう課題を毎日洗い出しては顧客に回答してもらい、回答をもらったら即座にアプリへ反映していく。
昨日の課題は今日の課題とはステータスも違うし、明日の課題はそもそも今日の課題とは違うかもしれない。
そういう課題の変化を逐一追跡する仕組みが必要だろうと思う。
何故なら、最小限の設計書しかないので、開発者が設計者の役割を兼ねるので、実装上の観点から分かった仕様漏れや仕様の不整合がポロポロ出てきやすいからだ。

そんな状況ではチケット駆動開発はとても役立つ。特に、タスク管理も重要だが課題管理で威力を発揮するだろう。
メンバーがアプリの開発で生じた課題が生じたら、課題のチケットを起票して、リーダーへ投げる。
リーダーは発生した課題をあらゆる手段を使って方針や回答を得て、メンバーにフィードバックする。
メンバーは、回答された課題の方針に従って、ソースへ反映し、コミットする時点でチケットもCloseする。
つまり、No Ticket, No Commitの運用ルールに従うことによって、どの課題がどのソースに反映されたのか、が分かるから、ソースの変化を追跡しやすくなる。
この課題管理の管理手法は、ITS(Issue Tracking System)の本来の使い方だろうと思う。

【3】短納期でプロトタイプ重視の開発では、XPのオンサイト顧客、Scrumのプロダクトオーナーのような役割を持つ人が開発チームにいることが重要だ。
実際の開発では、顧客が常に開発チームに常駐するとは限らないので、プロジェクトリーダーが顧客プロキシとなって、顧客の代わりにプロダクトバックログからストーリに優先順位を付ける。

オンサイト顧客が暗示したもの～プロダクトオーナーとアーキテクトの役割: プログラマの思索

DevLove道場で感じたことだが、プロダクトオーナーが開発チームにいないと開発そのものが停滞してしまう。
@kuranukiさんが言っているように、開発チームがいくらアジャイルで開発速度が早くてもじきに、プロダクトオーナーの意思決定の速度が開発のボトルネックになってしまうのだ。
特に、スマートフォン向けアプリ開発のように、旬の時期にリリースしないとそもそも使ってもらえない制約条件の場合、プロダクトオーナーの役割はより重要になってくる。

DevLove道場の感想 #agilesamurai #devlove: プログラマの思索

アジャイル開発のボトルネック - Social Change!

マネジメントのスピードが開発のスピードに直結する: プログラマの思索

だから、ユーザ企業が外部SIにシステム開発をアウトソーシングするのではなく、ユーザ企業自身が開発部隊を持ってシステム開発するスタイルが多くなっているのだろうと思う。
そうすれば、開発チーム自身が開発者であり、プロダクトオーナーでもあるから、自分たちで開発の支障や課題を取り除けていける。

最近、ソフトウェアテストやアジャイル開発のイベントでSNSやゲーム業界の事例が良く出てくるけれども、その理由は、SNSやゲーム企業の開発チーム自身が開発者でありプロダクトオーナーゆえに、アジャイル開発がとてもやりやすい環境が揃ってきていて、実際の開発で試行錯誤したアジャイル開発のノウハウや品質管理のノウハウが色々たまってきているからだろうと思う。

【4】スマートフォン向けアプリ開発のアーキテクチャもそろってきた感触もある。
スマートフォン向けアプリのプログラミングスタイルは昔のVBやC#のデスクトップアプリの開発とすごく似ている。
iPhone/iPadやAndroidで動くアプリは所詮はクライアントアプリ。
ユーザが画面に触れた時のイベントに応じて、処理を実装するだけ。

デスクトップアプリ開発のベストプラクティスであるObserverパターン、Multicastパターン、Commandパターン、Stateパターン、Starategyパターン、Singletonパターンなどがスマフォ向けのアプリのフレームワークに揃っている。

ObserverパターンとMulticastパターン: プログラマの思索

デザインパターン再考: プログラマの思索

昔のデスクトップアプリと違うのは、配布方法がiTunesのような仕組みで全クライアントへアプリを最新版へダウンロードできることと、アプリ内部でsqlite3のような軽量RDBを保持していること。
iPhone/iPadやAndroidの各端末にクライアントアプリを配布する場合、iTunesのような仕掛けでアプリを一括配布する仕組みになっている。

デスクトップアプリの開発で嫌なのはユーザへ最新版を届ける仕組みがバラバラのために、CDRで配布したり、専用回線で各クライアントへログインして手作業でアプリを配置するしかなかったこと。
つまり、デプロイという作業は昔はとても大変だったのだ。

HTML5が流行するかもと言われているのは、HTML5がsqlite3を持つクライアントアプリであり、Webサーバー上でクライアントアプリそのものを自動生成してiTunesのように配布できる仕組みが整いつつあるからだろう。
この発想は、本番リリース・本番デプロイ作業をより高速に自動化していく方向、すなわちContinuous Deliveryへ進化するだろう。

Continuous Delivery～TDDとCIの次に現れた自動化の概念: プログラマの思索

継続的インテグレーションを再考: プログラマの思索

また、内部にsqlite3という軽量RDBがあるので、マスタデータだけでなく、ちょっとしたトランザクションデータも保持できる。
だから、昔VBやAccessで作っていたアプリは全てスマフォ向けに作り直すことができるだろう。

AirのActionScriptは、C#のDelegateみたいに関数ポインタが使えるので、Javaのようにインナークラスを多用せずに書けるのが楽に感じる。
とは言え、ActionScriptはJavaっぽくてRubyほどの軽量さがなくて面倒。
Railsに慣れてしまうと、DaoやCRUD画面を手作業で逐一作るのが面倒だ。自動生成すればいいのに。
又、FlashBuilderはJavaのEclipseに比べるると、import追加・リファクタリング・デバッグ時のインスペクションが非力なので正直使いづらい。

Eclipseリファクタリング・メモ: プログラマの思索

【5】スマートフォン向けアプリ開発で思うのは、プラットフォームの重要性だ。
iPhoneシリーズは2009年に発売されたが、今でもOSやアプリをVerUpすれば普通に使える。自分用にカスタマイズされたiPhoneをずっと持ち続けられるのだ。

昨今は携帯やスマートフォンならば、ソフトウェアアップデート機能が必ず付いているので、アプリの最新化だけでなくOSそのものをVerUpすることも可能。
この意味は、コンテンツはいつも最新化できることでハードの寿命がどんどん長くなり、ハードの価値そのものがそれほど意味が無いこと。
つまり、従来の製造業の発想では、ハードを買った時点で価値の減価償却が始まり、5年で価値は殆どゼロになるのが普通だったが、iPhoneなどの場合は、買った後にコンテンツをどんどん最新化したり増やしたりしながら使い込んでいくほど価値が上がっていくスタイル。

これは、@kuranukiさんが話している「Point of SalesからPoint of Use」の話を連想させる。
スマートフォンのビジネスは、従来の製造業やソフトウェア開発に対するビジネスモデルのパラダイムシフトでもあるのだろう。

資料公開：「納品のない受託開発」にみるソフトウェア受託開発の未来～IT投資に対するソフトウェアの価値を最大化できるビジネスモデルとは - Social Change!

このプラットフォームビジネスで重要な点は、ファンや開発者を増やすこと。
iPhoneのようにファンを増やせばクチコミで購入者が広がっていく。
プラグインやアプリの開発者が増えることで、コンテンツが増えたり使い勝手が上がることによって、プラットフォームの価値が上がっていく。
この手法は多分、MicrosoftがVBやC#のような開発言語、VisualStudioの開発環境をプラットフォームとして提供して大成功させた手法だったが、今はAppleやGoogleにお株を奪われているように思える。

GTDとチケット管理が似ている: プログラマの思索

スマートフォンの開発やビジネスは従来のWebビジネスとはかなり違った新しいビジネスモデル、開発スタイルであると改めて実感している。
そこはアジャイル開発、アジャイルなビジネスを実現しやすい要素が多分かなりあると思っている。