無料ブログはココログ

« 2012年10月 | トップページ | 2012年12月 »

[#TiDD] チャレンジ基盤としてのチケット駆動開発

来る12月1日(土)はSEA関西プロセス分科会です。今回は第50回記念という事で、前半は「チケット駆動開発」、後半はかつてSEA関西では恒例だった「年末放談会」になっています。年末放談会は参加者全員で自由な議論をする時間で、今回のテーマは「ソフトウェアビジネスのパラダイムシフト」です。

ソフトウェア業界は常に変化し続けていて、プロセス分科会の世話人会でもその変化について色々な議論が出ました。皆さんも変化を感じる事はないでしょうか?

前半の私の発表も、放談会のテーマに合わせて大きく見直しました。この発表をベースに放談会では、より多くの方と深い議論をしたいと思っています。資料を先に公開しておきますので、ぜひ一読の上、ご参加ください(発表までにしゅうせいしました。最新版)。



おぉ、モンブランか! - ソフトウェア・グラフィティ -

特にケーキが食べたい訳でもないのに、ふと見かけたモンブラン。「おぉ、モンブランか!」おいしそうなので、口の中はすでにモンブランのイメージでいっぱいになります。お店に入ると、他の商品と比較する事もなくモンブランを買ってしまいます。それが特別な味でなくても、期待通りの味であれば「これ、これ!」満足して、そのモンブランがお気に入りになるのでしょう。

ほかにも色々な買い方があるでしょう。最近はロールケーキがブームだからと買う時もあるでしょう。そんな時は、「まあ、こんなものかなぁ」で、終わるでしょう。

とにかくケーキが食べたいと言う時もあります。そんな時はお店に入って一番おいしいのはどれかと選びます。そんな時は、それがとてもおいしいケーキだったとしても「今度はどれにしようか」などと考えて、次は別のケーキを選んでしまいます。

ソフトウェア業界に入って28年、自社・他社共に転職された方を多く見ましたし、チャンスもありましたが、私自身はなぜか会社を辞めようと思った事がありません。その事が自分自身でも説明ができず、失礼とは思いながらも会社を辞める人に理由を何度か聞いた事があります。

そこで気づいたのが、上のたとえ話です。情報系出身でなかった私は、別の業種は検討したもののIT系の他社を見ずに会社を決めました。それが、とても面白い会社だったからです。

求人案内用の新聞のようなチラシがあって、そこに似顔絵とともにユニークな社員のコメントが載っていました。そして、そこにこんな文章もありました。

「SRAは船です。同じ方向に行きたい人は乗ってください。いつでも降りられます。」

いやぁ、面白かった。年功序列が中心の時代に、既に先を言っていたのです。他にも読み進めると、商用では国内最初のUNIX導入とか、ソフトウェア工学とか、門外漢には意味不明ながら面白そうな言葉が並んでいました。

それは、私にとってモンブランでした。「おぉ、モンブランか!」と思いました。卒業研究のプログラミングに苦しんでいた私が「ソフトウェア開発をもっと知りたい」そんな思いでSRAを選びました。他社と見比べていないので、ベストな選択かはわかりませんが「これ、これ!」と思うような味でした。

そんな私が、入社1年目か2年目の事でした。当時の大阪営業所の社員の前で専務(当時)がISPW(International Software Process Workshop)への海外出張のお話をしてくださいました。

「プロセスというのがあってね。オスターワイルというのが『プロセスもソフトウェアだ』とか言うんだ」

ソフトウェア工学を大きく変えたこの言葉の意味が、当時はよくわかりませんでした。しかし「タバコを吸いにいったら、ダイクストラが煙草を吸っているので『タバコはGOTO文より有害ですよ!』と言った」というお話と共に、なぜか鮮明に覚えています。

そんな当時の専務が本を書かれました。まだパラパラと読んだ程度ですが、モンブランがどんな味かが書かれている様です。ご興味を持たれましたら、ぜひお読みください。ソフトウェア業界の歴史もよくわかると思います。


さかば流・論文作法 その3 - 良い技術 -

論文の構成注意点に続く、論文作法の第3弾です。

論文に限らず、技術というのは使われてなんぼです。再利用が可能で応用が利くという技術が良い技術です。良い技術であるには、結果を示すだけでなく、方法が示されて、「なぜ」が説明できて、その限界が示されている必要があります。

方法が示されている

「魚を与えないで釣り方を教える」という言葉があります。同じ結果を得るには、どのようにそれを実施すれば良いか、方法を示す事で技術は利用可能になります。

「なぜ」が示されている

しかし、その漁法がなぜ効果があるかが示されなければ、多くの間違いを犯してしまいます。鮎の漁法に「友釣り」(リンク先はWikipedia)というのがあります。鮎の縄張り意識を利用した物ですので、ライバル心を起こすような鮎が必要なはずです。しかし、その理解がなければ、別の魚をつけて、釣るべき鮎を逃してしまうかもしれません。また、理由を理解していれば、応用する事ができるかも知れません。実際、Wikipediaには、類似の魚に応用可能な事が書かれています。

限界が示されている

Wikipediaには、友釣りは鮎を捕るための漁法であるのにボウズハゼが釣れてしまう事、稚魚の放流が原因と思われる縄張りを持たない鮎が増えているとの問題点が書かれています。その技法の精度や問題点を明らかにする事で、過度の期待をしてしまわない安心な技術になっているのです。

「謙虚になりなはれ」

私が大学院に行った時、恩師に最初に注意された言葉が「謙虚になりなはれ」でした。教わるという姿勢がなっておらず、生意気だったのでしょう。この言葉は発表にもつながります。「既存の技術と比べれば小さな進歩だが、ここまでならできる」と謙虚に、しかも客観的に説明するだけで技術の議論はできます。

最近は技術的な発表で、ジョブズ風のプレゼンテーションが増えています。わかり易く、楽しい発表が多くなりました。それはとても良い事です。しかし、営業的なプレゼンテーションになっていて、技術のプレゼンテーションではないモノが多い様に感じています(もちろん良い発表もたくさんあります)。

ライトニングトークなら面白いのでどんどんやって良いと思いますが、技術者として発表するなら客観的に課題や弱点も示すべきだと思います。面白い人でも構いませんが、信頼できる技術者でもありたいですね。

技術の質を高めよう!

もう15年近く前にとある中国の会社を訪ねた時の事です。そこには開発部門にも関わらず、多くの博士がいました。博士だからといって必ずしも博識ではないですし、専門分野が仕事に生かせているかどうかもわかりません。

しかし、技術を整理して再利用可能にする事は学んだはずです。新しい技術が入ってきた時に、これまでの技術とどこが異なり、どの様な長所があるかを理解して、説明することも早いでしょう。

一方、日本ではオーバードクターと言われながらも、博士はソフトウェア開発の現場に増えず、開発現場では魚の取り方の議論が盛んに行われています。中国の発展と日本の衰退を考えると、少子高齢化や政治・経済の問題が大きく関わっているでしょう。しかし、技術的な積み上げが少なかった事も一員ではないかと思っています。

論文を書く事はそれがどのような物で、どのように書けば良いかがわかれば、決して難しくありません。せっかく色々な勉強会ができて技術発表が増えているのですから、現場の経験を生かしてより良い技術に仕上げれることができれば、日本はまだまだ発展できる。と思った次第です。

技術発表のポイントも合わせてお読みください。

さかば流・論文作法 その2 - 論文を書く上での注意点 -

さかば流・論文作法 その1 - 論文の構成 -」の続きです。

論文を書く際のポイントは、いかに誤解なく内容を理解してもらうか、いかに興味を持ってもらうか、を考えないと行けません。その実現のためには、論文の構造が大切です。

論文は、関連情報を提供するものでも、書きたい事を書くものでもありません。提案する技術の内容を新規性、有効性、信憑性の視点で示す物です。余分な事を書かない様にして、主張する事を中心に肉付けして膨らませるものです。

それは全体に無駄のないクリーンルームで書かれたような文章です。定義された用語によって既存の問題が示され、それを提案する技術がどのように解決して、どのような効果があり、課題と可能性が示されます。しかし、そのような文章を書くにはテクニックが必要です。

テクニック

前の記事で引用したつぶやきにほとんど詰め込まれています。少しずつ説明します。

1) まずは論文で主張したい点を3つにまとめて

もちろん1でも5でも良いのですが、説明する上でわかり易いのは3つの項目です。この3という数字は複数の大学の先生から聞いたことがあるので、一般的な数値だと思います。2段組みの論文だと、バランスよく1ページに書けるのはだいたい5−6段落です。このうち、導入とまとめに各1段落、必要なら後続の章へのつなぎの段落を書きますので、各項目に段落を割り当てるなら3というのは合理的な数字でしょう。

2) それを裏返して問題設定すると論文の概要ができます。

前の記事に書いた様にソフトウェア工学の論文では、問題設定が重要です。議論の土俵固めなくしては議論できないからです。1で挙げた3つの項目に対して、現状の問題点を考えます。もし、他にもその問題を解決する方法があれば、その項目をあきらめるか、従来の方法との違いを明確にして、項目を見直すとともに問題設定を再考します。

3) それを端的に表現すればタイトル。

3つのことによって実現することはいったい何か、世の中にどのように役立つかを考えます。前の記事に書いた「提案手法名:xxを目的としたyyの提案」というのはベストとは限りませんが、方向性を見失わない様にひとまず決めておくには良いでしょう。

4) 用語を説明すれば背景になります。

タイトルに出ている用語や、新規性、有効性、信憑性を示すための議論に必要な用語を説明します。この後に述べる構造を意識して配置すれば、「はじめに」に書くべき背景になります。

5) 各段落を一行で表した箇条書きを作ってから書き出すと綺麗な構造になりますよ。

次に述べる構造の作り方です。段落ごとに独立した文章にして、段落の並びで論理的な説明をするので、各段落を代表するような文章を段落の数の箇条書きを作成してから、全体を書き出します。きれいな論理展開なら、接続詞がなくても意味が読み取れるようになります(もちろん、読み易さを考慮して入れます)。

文章の構造

論文はいわば報告書ですので、全体の見通しを良くして理解し易くします。

まずは、トップダウンに書くことを意識してください。全体から詳細に、広い内容から狭い内容に、抽象的な議論から具体的な議論に進めます。

予想外の結末は基本的に必要ありません(経験してわかったちょっと良い事は、結果や考察に少しだけ入れると良いでしょう)。「概要」と同じ様に、基本的に結果から書きます。概要、章の最初の段落、各段落の最初、などで結果や構成を示して、見通しを良くします。

論文の面白さは、円蔵さんの落語や、刑事コロンボのストーリー展開に似ています。はじめにオチや犯人を見せておいて、どのように攻めていくかを楽しみます。

多くの大学では輪講と言って、論文や本を分担して読みます。これは最新の技術を容易に入手する方法であるとともに、論文の構造について議論して、面白い論文を知ってテクニックを盗む場でもあります。

書く順序

色々な方法があると思いますが、さかば流の方法を説明します。

始め方には文献始動と実験始動があります。とはいっても、闇雲に初めても何が新しいかわからずにうまくいかないので、最低限の文献調査は必要ですので、文献を調べてから実験するという感じですね。

文献があって、実験あるいは事例がそろって、それなりに新規性、有効性、信憑性があると思われたら、論文を書き出します。

全体のページ数と各章のページ数を決めます。全体が8ページなら、タイトルと概要で0.5ページ、はじめにが1-1.5ページ、関連研究が1ページ、提案手法2ページ、評価方法0.5-1ページ、結果と考察1ページ、おわりに0.5-1ページと言った感じです。参考文献の一覧や、図表、などもページ数に入りますし、最終的には著者紹介もページ数に入ります。

まずは、仮のタイトルと仮の概要を考えて、イメージを膨らませます。次にはじめにの段落構成を引用とともに考えます。引用がほとんどないのは信憑性や新規性が示せませんし、具体的な文章や内容の引用でなく関連してるだけの引用も書きたい事を書いているだけで、あり得ません。

以前、シンポジウムの査読をした際に面白い論文があり、その問題設定として知らない文献が引用されていました。その文献はその論文の大切なポイントとなる物でしたので、大阪府立図書館まで出向いてコピーしてきました。ところが、それは引用内容と全く違う物で、一気にその論文の信憑性はなくなってしまい、不採録にしました。論文を書くからには通ってほしいですが、内容が使い物になる「良い技術」でなければ意味がありません。

閑話休題。

関連研究移行は最初から真剣に書きます。書き進めながら、全体の一貫性を考えて修正しながら書き進めます。書き進めているうちに「はじめに」は大きく変貌しているかもしれません。

当然、概要やタイトルも一貫性のない違和感のあるモノになっている事が多いです。しかし、その都度修正していると時間がかかりすぎますので、ほぼ完成状態になってから見直す様にしています。

ある程度書き進めた後は、査読者がタイトル、概要、おわりに、はじめに、関連研究、その他と読み進める事を意識して見直します。査読社はこの順に読んで、気になるところがあればそれだけを探して読まれます。論理的な矛盾や説明不足がない様に気をつけます。

全体で気をつける事

技術文書ですので用語は統一されていなければいけません。一つの事は一つの言葉で表現します。翻訳の際に役立ちますので、メモや用語集を作りながら進めても良いかもしれません。

何事もゴールに向けて作業をする事が、効果的にゴールを達成するシンプルな方法です。論文も評価基準に合わせて、内容を書きましょう。

論文が実証を伴う物であるなら、その経験は貴重な情報です。論文の価値を高めるために、経験者でないとわからない事を書きましょう。

おわりに

より読み易く、うならせるような、さらに上級の論文もありますが、私が理由を説明できるのはこのレベルです。このレベルの書き方でも、技術を整理し、他の人に伝達して、評価してもらうための最低限は満たしていると思います。

ぜひ、身の回りの技術を整理して、提案する内容で勝負してください。

次回は「良い技術」について書く予定です。

さかば流・論文作法 その1 - 論文の構成 -

先日は技術発表のポイントを書きましたが、論文の書き方についても触れておきましょう。

論文の書き方は分野によって色々違うと思います。ここでは、ソフトウェア工学の論文を意識した論文の書き方を説明します。今回は論文の構成です。

先日、こんなつぶやきをしました。

私が大学院で5年かかった内容を140文字にまとめるとこうなりますが、あまりにもシンプルなのでもう少し説明する事にします。すごい論文には、まだまだ先があると思いますが、伝えたい事が伝わる様になると思います。

論文の構成は「まえがき・あとがき」「はじめに・おわりに」などのようにバリエーションがあります。基本は、投稿先の基準に合わせて、書式、章の構成、文献と引用の方法をそろえます。

一例として、手法の提案での論文の構成例を示します。

タイトル

査読に大きく影響を与えます。タイトルと概要で査読結果の半分近くが決まります。査読の際はタイトル、概要、はじめに、結果、その他の内容と読み進めると思いますが、イメージを膨らませながら読まれるので、最初のとっかかりが重要です。一通り書き終わったら、タイトルと概要だけは誰か(できれば論文を書慣れた人)に見てもらった方が良いでしょう。

書き終えるまでには、何度か書き直す事になると思います。ひとまず、「提案手法名:xxを目的としたyyの提案」などとして、書き終わってから、よりアピールできる名称を考えると良いと思います。

概要

曖昧な内容ではなく具体的な内容を書いて、読者を読む気にさせます。色々なパターンがありますが、さかば流では結果を書いてから内容を説明します。「本稿ではxxするyyを提案する。提案する方法を用いると〇〇が△△になる。従来の▼▼手法では△△できなかったが、提案手法を用いた結果〇〇の□□がZ%改善し、△△である事が確認された。」といった感じです。

ポイントは数値あるいは具体的な内容で示す事です。定性的な情報しかなくてもモデル化などによって、定量的な結果やより具体的な結果を示します。

はじめに

提案する事の問題設定と用語の定義を書きます。他の分野、たとえばアルゴリズムなどの分野では、問題や用語が明確になっていて引用する事で問題設定できる場合があるかも知れません。

しかし、ソフトウェア工学では生産性とか品質といった大枠の課題はあっても、その手法が解決する具体的な問題、たとえば「レビュー時の漏れをなくす」といった限定された問題がなぜ必要かはあまり示されていません。

詳細で具体的な問題設定を通じて、提案手法で解決する問題が一般的に重要な問題である事を示します。そして、提案する手法の価値を高めます。

その背景には、議論する範囲を限定して議論し易くすること、また、そんな大した事が一度にできるわけない、という暗黙の前提があります。もちろん、すごい研究は存在しますが、その正当性を示すには、抜けのない、つまり、議論の余地のない評価方法や結果の示し方が必要になります。

問題を設定する犀は過去の文献を引用して、徐々に外堀を埋めていきます。社会的な要求に近い大きな問題から、徐々に小さな問題に迫っていき、類似の研究の成果と問題点を説明します。この問題点は提案する手法で解決できた事でないといけません。

用語の定義も文献を引用しながら行います。いかにも定義という表現でもかまいませんが、問題設定の中で関連研究の説明とすれば読み易いでしょう。少なくともタイトルに含まれる用語はすべて説明しないといけません。

関連研究

「はじめに」でも関連研究を引用しますが、それは用語の説明と問題設定のための物です。提案手法と直接関わるものを章にします。章のタイトルは、より具体的な関連研究の名前を含めたり総称でもかまいません。

この章では、提案手法の理論的な裏付けや新規性につながる研究や技術を説明します。必要に応じて、具体的な内容に踏み込んで有効性や限界を説明します。

ページ数の少ない論文では省略する場合があります。その場合は、「はじめに」や提案手法のところで引用すべき関連研究を示します。

提案手法

章の名前は具体的な提案手法の名前を書きます。

すでに説明に必要な用語は説明されているはずですので、それらを使って提案手法の詳細を説明します。すでに引用された文献であっても重要な物は再度引用します。

技術を公開するのですから、その手法を実施できる様に前提や制約なども含めて具体的に書きます。

評価(実験)方法

追試ができるならより提案手法の結果の信憑性が増すでしょう。興味を持った人が再現できる様に具体的に書きましょう。定性的なデータよりも定量的なデータの方が客観的な議論ができます。

もし、可能なら検定など統計的な手法で評価しましょう。不可能なら結果の分類、モデル化、などを行います。

結果と考察

評価の結果を示して、提案手法がどの程度優れているかを示します。また、結果から論理的に言える事を説明して、提案手法の有効性や可能性、課題を述べます。

注意点としては、事実と考えを分けることです。ページ数余裕のある場合は、結果と考察にわけます。それができない場合は、少なくとも段落単位で事実と考えを分けます。

おわりに

概要と同様の内容をまず書いて、考察の結果や、課題、今後の可能性を欠きます。

論文には提案手法の新規性、有効性、信憑性に関わる事以外の思いを書く場所はほとんどありません。もし、キャッチーな言葉をかいたり、大風呂敷を広げたいなら、はじめにの最初か、終わりにの最後です。提案手法から離れすぎない範囲でイメージできる内容を書きましょう(研究会などでは、具体的にどう考えているかを質問される事がありますので、ほどほどに)。

以上、論文の構成を説明しました。これ以外にも考察で関連文献を引用して新規性を議論するというパターンなどもありますが、上のような構成でまずは書いてみてはいかがでしょう。

次回は論文を書く上での注意点を書く予定です。

このエントリーをはてなブックマークに追加

[#TiDD] パッチはコア資産 - DVCSの考察 -

“No Ticket, No Commit!” の誤解

チケット駆動開発の基本ルールである“No Ticket, No Commit!”の誤解の一つは、コミットに1対1のチケットが必要であると言う考え方です。この反例として、「Redmineによるタスクマネージメント実践技法」の事例があります。

この事例では、Redmineのワークフロー機能を利用して、リリース後のコードと開発中のコードの更新抜けをなくすというものです。

具体的には、チケットをクローズする権限を特定の担当者に与えておき、修正が全ての関連プロダクトでコミットされていることを確認することで、修正の漏れをなくしています。

この例では、一つのチケットに2つのコミットがありますが、効果的なチケットの使い方になります。

DVCS(分散バージョン管理システム)

この事例では、DVCSを用いると作業が容易になります。バグ修正を行うトピックブランチを作成して、その修正(パッチ)を2つのブランチに反映すれば良いのです。

このやり方を考えてみると、パッチがコア資産であることがわかります。コア資産とは、複数系列のソフトウェア製品を開発するソフトウェアプロダクトラインの用語で、ある製品を開発する際に再利用されるものです。仕様書、ソースコード、試験項目、開発標準など、再利用しやすい形で整備されます。

バグ修正の事例で、ある製品を開発するのに使われた共通な資産は、本体のソースコードではなく、修正差分であるパッチです。このようなパッチの蓄積がソフトウェア開発を進めていきます。

昔のオープンソース開発

かつてnewsシステムという、バケツリレー式に情報を伝播する世界規模の掲示板のようなものがありました。誰かが記事やコメントなどの情報を書くと、それがサーバー間で転送されて共有されます。今のインターネットの祖先の仕組みで、自分のサイト内で世界中の情報を得ることができました。

当時は、これがオープンソース開発に利用されていました。さまざまな技術的な議論のほか、ソースコードのリリースや、バージョンアップ時の修正差分も世界中に配信されていました(ちなみに、私はnewsでrubyを知りました)。

ブランチ

オープンソースの配信は色々なものがありました。

1) 全ソースコード
2) 日本語対応パッチ
3) 新バージョンとの差分パッチ
4) バグ修正パッチ

ここでいうパッチとは修正の差分ファイルで、元のソースとパッチからpatchコマンドで修正後のファイルを作成する事ができました。

これらは、「サルでもわかるGit入門」で紹介されている「A successful Git branching model」のブランチに当てはめると、それぞれ

1) メインブランチ
2) フィーチャーブランチ(トピックブランチ)
3) リリースブランチ
4) ホットフィックスブランチ

に相当します。オープンソースは単純でシーケンシャルな開発ではなく、多くの修正がそれぞれのサイトで分散して行われ、その結果が共有されていました。

パッチを使う際は、その順序が問題になりました。たとえば、あるバージョンに日本語パッチをあてるとバグフィックスのパッチは適用できてもバージョンアップのパッチが適用できなくなって、まず、バグフィックスして、バージョンアップして、日本語パッチを適用するなどという順序で解決されることや、パッチのマージが行われたりしました。

これらの様子は、DVCSのブランチ処理によく似ています。オープンソースの開発から生まれたので、当然と言えば当然ですが、、。

身近な複数系列の開発

かつて複数系列の開発は、プロダクトライン呼ばれるような大規模な開発が中心でした。

しかし、考えてみると英語版、日本語版、特殊機能追加版など、オープンソースの開発も複数系列の開発になります。また、最初に挙げた事例の様にリリース後にも開発を継続していれば、自然と複数系列の開発になります。

開発対象が複数系列になると、追加機能開発は特定の系列に修正した後に他の系列に同じ修正をするよりは、オープンソースのように機能追加の修正パッチを作成して各系列に適用する方が作業が簡単になります。

従来のバージョン管理システムは中央集権的にメインライン(trunc)を中心に管理する必要があり、複数系列の同時開発になると、その管理が面倒でした。DVCSは分散開発が前提なので、複数管理が容易になっています。

パッチ単位の開発へ

SVNや前の世代のCVSでは、CIを実現する目的でバージョン管理のリポジトリにはビルド可能なコードだけをコミットする、ということが常識化していました。そこで、開発中のコードをとりあえずコミットすることが許されなくなりました。

しかし、DVCSならブランチを容易に作ってマージできますので、CIや他の人に迷惑をかけることを気にせずにコミットできます。

実はCVSのさらに前の世代のRCSは、ファイル単位のバージョン管理でした。当時はビルド(というかmake)するための共通ディレクトリを作っておいて、作業が完了する毎に共通ディレクトリのファイルを更新するという使い方をしていました。

DVCSを見ていると、RCSでの開発や昔のオープンソース開発を思い出させます。単純な構成管理を中心に考えると、VCSによる統制の取れたメインラインの管理が向いていました。しかし、複数の系列やスピーディな開発が求められることによって、個人を中心とした開発が復活しようとしているのかもしれません。

ソフトウェアはどう作るべきか、一気に作る時代は終わりを迎えようとしています。ブランチ毎のパッチ単位に開発する事を繰り返す事が、ソフトウェ開発の基本になる時が近づいていると思います。

MobiRubyはオープンソース! - 秋の京都で MobiRuby をつつく会 in はてな その2 -

秋の京都で MobiRuby をつつく会 in はてなの参加レポートの続きです(レポートその1)。

後半は増井雄一郎(@masuidrive)さんによる「解剖!MobiRuby!」でした。そういえば@masuidriveさんがMobiRubyをされているとの噂を聞いていましたが、すっかり忘れていました。@masuidriveさんといえば、以前、@kanu_さんからうかがった「チケット駆動開発のはじまり」からたどれる「masuidrive的プロジェクトの方針」の増井さんでした。今もお風呂でプログラミングされているそうです。

MobiRuby

MobiRubyは組み込み用rubyであるmruby(eMbeddable Ruby)の上に構築されたiPhone向けの環境です。将来的にAndroid向けにも対応されるであろうmobiruby-cfuncが、iPhone向けのmobiruby-cocoa、mrubyでサポートしていない機能など支援するmobiruby-common、ビルドやブートストラップ、Xcodeを支援するmobiruby-ios、から構成されています。

現状ではRubyから受け取った呼び出したいAPIの文字列は、dlopenで名前解決する仕組みになっている様です。なお、Rubyソースはバイトコードに変換され、それを".c"に取り込み、コンパイルして.o、実行プログラムになるようです。

開発のきっかけは、まつもと(@yukihiro_matz)さんにやりたいと相談したところ「いいよ!」と返事があったからだそうです。人のつながりからはじまる、いかにもオープンソースな始まり方ですね。

ちなみに、MobiRubyは現在3000行ぐらいで、多くなっても5000-8000行ぐらいで納まるだろうとのことで、ブームになりだした頃のLinuxのように、多くの研究が行われる様になると良いですね。

2013年1Q(4月まで)にバージョン1がリリースされる予定で、Androidの対応はそれ以降になるそうです。

mruby

MobiRubyで苦労されているところは、下位層であるmrubyに起因するところが多い様です。

mrubyは組み込み向けに軽量化されています。なんとコードはcruby(普通のruby)との比較で1/10だそうです。あまり使われないライブラリの削減のほか、Smalltalk風に無限の長さを持てるはずの数値が、整数、float、doubleと一方向に変化する様になったそうです。

このほか、mrubyはPOSIXでなくC99をベースにしているので、ファイル、ソケット、スレッドなどはサポートされていないので、必要な物は環境に合わせて実装しないと行けない様です。

なによりもmrubyが開発中であることが、実装方法や順序に制限を与えているようです。実装の変更が予定されていると聞いているため、デバッグトレースが実装できない、ガベージコレクションの連携方式が限定される、と言った問題がある様です。

ガベージコレクション

Rubyはmark&sweepというガベージコレクション(オブジェクトの参照ツリーをたどってマークし、それ以外を破棄する)方式ですが、Objective-Cはリファレンスカウンタ(オブジェクトごとにカウンタを持って参照ごとに加算・減算する)方式なので、それを解決する必要があります。

本来ならmrubyのガベージコレクションのタイミングでリファレンスカウンタを減産する方法も考えられるのですが、今後の修正が見込まれるので、今はObjective-Cのreleaseメソッドを書き換えて、解放するタイミングでチェックするという遅い方式で実装されている様です。

この辺りの難しさに対して、「動く物がないと話に乗ってくれない」のでやっていると、あきらめよりは当然の事として受け入れられておられる様でした。また、mrubyやObjective-cあるいはCocoaの実装の変更に対しては、「マンパワーと気合いと根性」で乗り切られるとの事。

サラリーマンとしてならブラックなお話ですが、オープンソースの開発なので、多くの協力者と共に積極的に取り組むイメージが感じられ、能力があるなら協力したいと思いました。

Objective-Cがいつかガベージコレクションになれば良いのですが、方式の違いという事で仕方ないと思います。反面、Objective-Cが良くできているので、相互に継承可能にできるというメリットがあるそうです。

@masuidraiveスタイル

踊られた訳じゃないですw。

まつもとさんとの「いいよ!」という関係性もそうですが、「動く物がないと話に乗ってくれない」「マンパワーと気合いと根性」という言葉もMobiRubyがオープンソースとして、世の中に貢献するという熱い思いを感じました。

また、技術者としてのスタイルでは、様々な技術を持たれている事に対して、

「仕事でやらないと分からない」

と言われていたのが印象的です。これは私も昔悩んだ事のある問題です。どんなに本を読んでも、小さな仮想プロジェクトをしても、真剣に作らなければ、身に付きません。それを新しい仕事で経験を積むという方法で解決されていました。また、MobiRubyの今後に対しても「Androidもやらないと面白くない」とさらに技術を得て向上しようとされている様でした。

私の場合は、コミュニティで聞く、今ある仕事をきっかけに勉強する、という解決法を取っていますので、増井さんのより積極的な方法に清々しさを覚えました。技術者として、ちょっとうらやましいと思いました。

おわりに

MobiRubyはまだ正式版でなく、メモリーリークもあるそうです。そこで、今すぐ使うなら200ドルなのでRubyMotionを使う方が良いと謙虚&率直に言われていました。

とはいえ、オープンソースであることや、今後、結構大変そうですがAndroidにも対応されること、メタプログラミング的な記述ができる様になる、といったことからMobiRubyの今後には大いに期待しています。

最後に、今回の企画をしていただいたiPhone プログラミング勉強会京都とCocoa勉強会関西のみなさま、ありがとうございました。

リーンスタートアップなiPhone開発はPhoneGap! - 秋の京都で MobiRuby をつつく会 in はてな その1 -

秋の京都で MobiRuby をつつく会 in はてなに参加してきました。この会はiPhone プログラミング勉強会京都とCocoa勉強会関西の番外編として実施されたそうです。先日のKOF2012で知り、面白そうなので参加しました。

はじめの講演は、はてなの浅野慧さん(@ninjinkun)による「iOSアプリ新サービス開発 ネイティブ、HTML5、PhoneGap」でした。

はてなでは、広告収入がいつなくなるかわからない、という危機感から、ディレクター、エンジニア、社長、それぞれから常に新しい収入源となるサービスを開発されているそうです。

そのような中で、サービスには「匿名ダイアリーのように」いつの間にか出ているものと、「はてなアルバム」のように完成度を上げてから公開される物があるそうです。

新しいサービスを提供する場合、完成度が高いに超した事はないのですが、失敗するリスクもありますので、リーンスタートアップを参考にMVP(必要最小限のサービス提供)やvalidated learning(仮説検証)の考え方を導入し、必要に応じてピボット(方向転換)をされているそうです。

しかし「はてなアルバム」のようにiPhoneのネイティブアプリの場合は、Apple社の審査を受ける必要があり、普通は3ヶ月程度で終わるはずの開発が長期化してしまったそうです。

もちろん、サーバーサイドからHTML5で配信すれば問題ないですが、やはりAppStoreの宣伝効果は大きいですし、HTML5では使えない機能もあるので、ネイティブアプリを使う必要があるそうです。

そこで、サーバーから変更可能なHTML5とネイティブコードを連携させる事になるのですが、ネイティブ側からHTML側を呼ぶのはjs文字列を渡すだけですが、HTML側からネイティブ側を呼ぶにはリクエストをフックしてURLで振り分ける事が必要で、これがつらいとのこと。

PhoneGapを使うとこのつらいところを、コマンドキュー、JavaScript、ネイティブ、プラグインと連携して動作して、吸収してくれるそうです。PhoneGapは元々ローカルのHTMLを実行する様になっていますので、PhoneGapには手を入れず、メソッドとプラグインを追加して、Apple社の審査なしにサーバーからコードを入れ替えるられるようにしたそうです。

これは、外部からのプログラム更新許さない審査基準ぎりぎりのやり方の様です。とはいえ、iTunesやAppStoreなどもHTML表示を外部から変更している様ですので、判定が難しいところなのでしょうね。

ちなみに、怖くない2ちゃんねると呼ばれている「はてなスペース」がPhoneGapを使っているそうです。デザイナーのHTMLをそのままWebかして、UXが固まってからネイティブ化するそうです。

リーンスタートアップを実現するには、どのように開発するかもしっかり考えないといけないということなのでしょう。

後半のレポートもご覧ください

技術発表のポイント

技術発表には色々あります。ここでは、その種類と評価基準を説明して、そこから大切なポイントを説明し、最後にエンピリカルソフトウェア高額についてもふれます。

技術発表の種類

私的なものとしては、Twitterのようなつぶやきをはじめとして、ブログ、メールマガジン、雑誌、書籍などがあります。これらは、基本的に個人が勝手に書いている物です。

オープンなものでは、勉強会、分科会、研究会、ワークショップ、シンポジウム、国際会議、論文誌(ジャーナル)などがあります。形式的な確認だけで審査なしに発表できる物もありますが、概要やスライド、論文などを査読して合否を決める場合があります。

発表の種類としては、研究論文、事例報告、経験論文などがあります。

評価基準

これらを査読する場合は評価基準が決められていて、

研究論文: 新規性、有用性、信ぴょう性 
事例報告・経験論文: 有用性、信ぴょう性、一般性

などが多い様です。このほか、読者や参加者との適合度が評価される場合があります。実際に発表する場合にもこれらを説明する事が必要です。

研究の場合は、新しく、役に立ち、それが定量的なデータなどで正しい事がしめされている事が求められます。

事例報告や経験論文では必ずしも新しくなくても良いのですが、役に立つことが示され、それが信頼でき、広く活用できる事が求められます。研究論文のような斬新さは求められませんが、まったく同じ発表を評価するわけには行きませんので、過去に発表された技術・研究とのちがいを説明する事は必要です。

また、解決する問題とはどのようなものか説明する必要があります(問題設定)。また、同じ事ができる様に実施方法の説明が必要ですし、結果の評価方法や評価結果の説明が必要です。また、課題や今後の応用の可能性の説明も期待されています。

大切なポイント

あなたが技術者なら「論文を書くわけではないのに」と思われるかもしれません。しかし、どのような発表であれ技術発表なら、それがどのような技術で他の技術とそのような関係であるかの説明は必要です。また、今までなぜうまくいかなかったか、なぜうまくいったかの説明は必要でしょう。

特に事例発表や経験論文の場合は、その事例特有の前提を示すと、どのような時にその技術が有効か、どの程度汎用的な技術であるかを示す事になり、発表の価値を高める事になります。

このように、その発表を聞く人が、理解し、活用できる様に、その技術に対する「なんでか?」を示す事が大切です。それが、その技術を活かす事になるのです。

もちろん、技術発表であっても技術的な面白さのほか、発表のわかりやすさや面白さなど、聞く人のためにすべき大切な事はあります。しかし、それは技術を技術として説明した上で、より良くするための物です。そこで、それらは最優秀発表賞などのような形で総合的に評価されることが多いようです。

エンピリカルソフトウェア工学

かつて、ソフトウェア工学がブームのとき、様々な方法論が発表されました。しかし、多くはどのような効果があるのかが示されず、いわば「言いっぱなし」のモノがたくさんあったそうです。そこで、定量的な議論が必要であると言われるようになり、やがて実証する事が求められ、「エンピリカルソフトウェア工学」が生まれました。

定量的に示す事は難しいですし、それを統計的に示す事はさらに困難です。しかし、結果をうまく整理してモデル化できれば、現場の事例を数値で示す事も可能になります。ご参考までに、ソフトウェア工学の国際会議では最も難しいと言われているICSEで発表した研究の日本語版のスライドを公開しておきます。

プラクティスの経験を蓄積すれば、もっと導入が楽になるよね。事例を公開しようよ。という事でしたが、その思いをきっかけに、@agilekawabataさんの協力を得て、論文にまとめました。データが少ないのでそれほど信頼性は高くない情報ですが、これからプラクティスを導入する方には有効な情報をまとめられたと思います。

ちなみにICSEは一般に10-20倍の難関ですが、これはfar east tracという6倍倍程度の倍率のセッションでした(一般のシンポジウムは2−3倍ですので、ラッキーだったのは間違いないようです)。


このエントリーをはてなブックマークに追加

[#TiDD] ソフトウェア業界の流れと波

ソフトウェア業界には昔から繰り返される波がありました。

1) 機能とデータあるいはトップダウンとボトムアップ
プッログラム法、設計法、アーキテクチャ、組織など多くの物がこの波を繰り返しています。

2) 自動化のカスタマイズと簡易化
自動化は多くのパラメーターによって多くのカスタマイズが可能なツールに始まり、やがてユースケースが安定すると簡易なシステムになります。そして他のツールの統合などで機能が増えて、新たな波が繰り返されてきました。

3) 集中と分散
ハードウェアを例にとると、ホスト+ダム端末、PCへの分散、ワークステーション+X端末、サーバークライアント、webサーバ+クライアント、HTML5オフライン処理などがあります。ソフトウェアのアーキテクチャも1の波とともに集中と分散を繰り返しました。

このような繰り返される波は、砂浜に押しては寄せる波が砂山にあたるたびに平らにする様に面倒な事がビジネスチャンスになり、やがて簡単な仕組みになっていきました。簡単になると価格競争が始まり、やがてビジネスのうまみがなくなりました。

そして、ビジネスの規模を維持するためにソフトだけだったものが、SIという名前でハードウェア・ソフトを組み入れ、やがて運用を取り込んできました。アジャイル開発によるリスク低減の結果、資本参加が進む( [#TiDD] アジャイル開発が注目される理由)と考えているのは、そのような流れがあるからです。

このような波を考えると、今後のビジネス開拓につながる発展が期待できる分野はこのような感じでしょうか?

  • 今しばらくはビッグデータ、特に今後の法律を意識したアーキテクチャが求められるでしょう。また、ビッグデータを利用するための分析アルゴリズムが必要でしょう
  • クラウドで多くの複雑な事が少なくなりましたが、状態により変化するアルゴリズム・アーキテクチャによってより自動化が進むでしょう。すでに実用化されつつありますが、しきい値設定も不要なより高度なシステムが求められるでしょう
  • ネットワークだけでなく、オフラインでの利用を考慮したUX。どこでもネットワークが使える便利な世の中ですが、通信の障害やトラフィックに対する考慮、情報の保護への考慮からオフライン処理が必要になるでしょう

閑話休題。ソフトウェア業界ははじめに述べたような波を繰り返しながら、設計・構築法、ハードウェア、通信、が進化してきました。そのような流れが明確になってきたのは、1990年代でした。当時の発表スライドを公開しておきます(論文)。

ダウンサイジング時代のプロセス改善モデル(OHP) from Makoto SAKAI

このころから垣間見える流れは、以下ようになります。
  • 多機能なソフトウェアが少人数で作れるようになり、管理単位が小さくなる
  • 組み合わせや実現方法などが多様になり自由度が増す
  • その結果、リスクが高くなり、知識を集約してリスクを避ける開発法が必要になる
この流れで求められる技術は「チケット駆動開発」であると考えています。チケット駆動開発なら開発中に気づいた新たな発見や作業の履歴を蓄積・利用する事ができますし、遠隔地とのコミュニケーションによって多くの知見を活用する事ができます。

クラウド、ビッグデータ、モバイル、といった新しい技術が導入される中で、開発方法や品質管理が変わろうとしています。

第50回 SEA関西プロセス分科会

では、この記事を踏まえて「チャレンジ基盤としてのチケット駆動開発」と題した発表をさせていただきます。そして書籍チケット駆動開発の書評を踏まえて小川(@akipii)さんが「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」と題した講演をされます。その後に、「ソフトウェアビジネスのパラダイムシフト」と題してフリーディスカッションを行います。ご興味のある方は、ぜひご参加ください。

得意分野、広範な知識、最先端の実践方法 - KOF2012: HTML5の現状と変わるウエブ制作 -

関西オープンフォーラム2012に参加してきました。関西オープンフォーラムは、

「オープンソースならびに、コミュニティが元気に交流できる場を、関西でも作ろう」という目的のもとに集った有志により、2002年に活動を開始いたしました。

というもので、ソフトウェア技術者協会(SEA)を含む関西の多くの団体が共催や協賛して開催されています。今回のオープニングでは、私のつぶやき

をネタにしていただいた「コミュニティの世代交代」についても触れてられました。つぶやきのように、KOFは、中野先生のサーバントリーダーシップの下で、多くのボランティアの個性を活かして開催され、常にオープンで新鮮な情報交換の場が提供されています。

今回も、ビッグデータの知的所有権、iPhoneアプリの開発、Androidのセキュリティ、Google App Script、WAKANDAなど、様々な講演を聴く事ができました。

そのような中で、最も考えさせられたのが、村岡さんの「HTML5の現状と変わるウエブ制作」でした。

2014年の第4四半期に正式化予定で5.1が2014年の第4四半期に正式化する予定であるHTML5が、すでにブラウザに搭載されているお話から始まり、Canvas, SVG, WebGLのデモ、オフライン機能などの紹介の後、Flashとの棲み分けの話になりました。そして、HTML5の開発者に求められることというお話しになりました。私なりの理解で書くと

  • 何かあれば訪ねられるような得意分野を持つこと
  • 正しい判断ができるように広範な知識を持つこと
  • 変化する仕様を追いかけて最先端の情報を得ておくこと

このように突きでた存在であり、何でも知っていて、さらに最新情報を常に得るという事が必要になります。とはいえ、そんなスーパーマンにはなれないので、プロジェクト内で手分けする事やコミュニティに参加する事が必要だという事でした。

アジャイル開発では多能工が望ましいと言われますが、だからといって全ての人がスーパーマンである必要はなく、各自が得意分野を持って協力し合えば良いと思います。コミュニケーションの基本は相手を尊重する事から始まると思いますし、助け合いの心はプロジェクトの大きな力になるからです。

このお話を聞いて、チケット駆動開発がチャレンジ基盤であった事を再認識しました。

ソフトウェア開発とは、これまでに無かった事を実現することで顧客に価値を提供する仕事です。チケット駆動開発を活かせば、新しい技術にチャレンジすることが支援されます。チケット駆動開発は開発中の新たな発見や作業の履歴を蓄積しますし、遠隔地とのコミュニケーションを可能にして、開発者の知見を活かす事が可能だからです。

そこで次回のSEA関西での発表内容を変更します。タイトルも

「チャレンジ基盤としてのチケット駆動開発」

です(現在、案内の変更をお願いしています)。ぜひ、皆さんご参加ください。

第50回 SEA関西プロセス分科会のご案内

  *ソフトウェア技術者協会(SEA) 入会の案内

[#agileto2012] 『チェンジ!』の考え方 ~マネしやんと!~

私がチケット駆動開発を導入した際には、人、プロセス、ツールなどを考慮しました。しかし、のほか「戦略」の側面を考慮しました。チームの問題を見つけて、改善を進めるには戦略が必要です。

今回の Agile Tour Osaka 2012 のライトニングトークでは、チケット駆動開発を導入時にも、人、プロセス、ツールなどのほか「戦略」の側面を考慮しました。その際の5つの「チェンジ!」の考え方を紹介しました。

今回のAgile Tour Osaka 2012 はアジャイル王子こと牛尾さんのソクラテスの産婆術のような質問によるPOの技術、藤原さんによる合理的で無駄の無い仕事のすすめかた、国際的な視点の長瀬さんのお話という豪華メンバーの講演が聞けました。講演者の皆さん、スタッフの皆さん、ありがとうございました。

このエントリーをはてなブックマークに追加

« 2012年10月 | トップページ | 2012年12月 »