無料ブログはココログ

« 2013年1月 | トップページ | 2013年3月 »

XPやアジャイル開発の「価値」 -「価値観」でお願いします - #devsumi

「XPには5つの価値が存在します。」「コミュニケーションはXPの価値です。」
と聞くと、XPを実践するとコミュニケーションが良くなるとか、コミュニケーションを良くする事がXPの存在価値のように聞こえます。少なくとも私はそう思っていました。

この話のはじまりは@akipiiさんのブログ記事「XPやScrum、PFにおける価値はどんな効用を持つのか?」です。ここでは価値と原則の理解の内容を元に「価値とは、行動の善し悪しを決める判断基準、価値観である。」とされました。これは日本語の価値ではありません。

その後のチケット駆動開発の議論などを通じて、これは「価値観」とすべきではないかと思いました。@akipiiiさんにも合意していただき、デブサミの講演では、価値観とされています。

デブサミの講演の中でも和智さんの講演「人が作るソフトウェア 〜今組織パターンを読む意味〜」でも「組織の価値観」という言葉が23ページ目に出ていて、やはりXPやアジャイル開発で大切にするのは「価値観」なのだと思いました。

そこで、英語のwikipediaを見ると、XPの価値にあたるところで

Extreme Programming initially recognized four values in 1999

とされていて、「価値を認めた」とあります。つまり、その価値が大切だ、それを指針に行動しよう、という事なのでしょう。これは、日本語でわかり易く言うとそれは

「価値観」

です。つまり

XPはコミュニケーションを価値観としている

と言う事なのです。元の英語が”Value”なので「価値」なのですが、説明される際は、ぜひ意味がわかりやすい「価値観」でお願いしたいと思っています。

[#TiDD]ウォータースクラムフォールよりも五月雨WFの方が変化に強い!(かも)

ウォータースクラムフォールは「アジャイル風」

第15回アジャイルラジオによると、ウォータースクラムフォールと言うものがあり、ソフトウェア開発のプロセス全体はウォーターフォール(以下WF)で、製造工程だけスクラムで実施するプロセスがあるそうです。

この方法は上流で仕様を固定する、あるいは、一定の予備工数を取っておいて、仕様変更に対応するようです。製造工程は繰り返し開発なので、フレームワークやOSに想定していなかった問題が生じれば対応できると思われます。

しかし、それは製造時(コーディング&単体テスト)のリスクであり、スコープは変更されないと思われます。予備工数がある場合は、その範囲で仕様変更に対応できますが、それは追加するだけで(交渉の余地があるものの)当初の仕様は全て実装されるのでしょう。

これを「アジャイル風」と言うらしいです。確かに私がUAS2で私が書いた「アジャイル風」と同じ様にアジャイルプラクティスの一部を実施したものですが、アジャイル開発の価値観を求めるものかどうか大いに疑問があります。

アジャイル風ウォーターフォール開発の比較

 

そこでアジャイル風と思われるWFを比較してみました。ここでいうWFとは(工程を進めるかを判定する会議があるなど)厳密な意味ではなく、仕様をドキュメントで定義して開発開始後の仕様変更は管理されるという意味で使っています。

Agilelikewf

典型的なウォーターフォール
仕様決定は1回、リリースも1回です。プロジェクトの終盤になって、開発や実行の環境や仕様、ユーサーインタフェース(UI)の問題が発覚します。優れたユーザ体験(UX)の実現は実現が困難だと思います。プロトタイピングのほか、リスクが問題化した際の手戻り作業を予め見込んでおく必要があります。

複数リリース
仕様は予め決められているものの複数回のリリースによって、ある程度リスクを低減できます。基本的な動作や多システムとの連携、ベースとなるUIを早期に確認することで、ある程度リスクを低減する事が可能です。この場合も典型的な場合に比べて工数が減りますが、手戻り作業を見込んでおかなければいけません。チケット駆動ならアダプタブルWFを実現可能。

五月雨(さみだれ)発注
複数リリースと同じくなるべく早く動作を確認したい部分を早期に発注し、仕様が固まらない部分や決定を遅らせたい部分を後から発注します。手戻りは次回の発注分に含める事も可能ですので、多くのリスクに対応する事ができます。リリース時期に合わせて、後期に発注する仕様のスコープを変更できますが、タイムボックス管理はされません。チケット駆動ならアダプタブルWFを実現可能。

ウォータースクラムフォール
厳密な定義は不明です。いわゆるV字あるいはW字モデルの製造部分をスクラムで開発します。リリースが複数であれば複数リリースとほぼ同じリスクへの対応が可能です。製造工程ではスクラムなので、継続的な改善や良好なコミュニケーションが基本的に導入されると考えられます。

アジャイル開発
アジャイル開発ではタイムボックスに合わせてスコープ(仕様の範囲)を変更しますので、様々なリスクに対応可能です。リスクを考慮してプロジェクトのロードマップを決めれば、より効果的でしょう。UXの向上は文書化が困難なので早期に実装を始めるアジャイル開発に向いていますし、開発と運用が連続しているので、予算の範囲内で発生した問題に対応できます。

コミュニケーションの考慮

アジャイル開発では、XP祭り2009の土屋さんの講演にある「同じ人の所に仕事が来るというモデル」が基本なので、コミュニケーションの問題が生じにくいという特徴があります。

しかしアジャイル開発でも 、配員が増減するとコミュニケーションを取る事が難しくなるようです(commの事例)。どのような開発をする場合でも、作業をなるべく前倒しにするなど配員を平準化して、早めにチームを立ち上げる工夫が必要です。

配員の増減によるコミュニケーションロスは生産性に大きく影響しますので、発注側が作業量を調整するなどの考慮をすることで、より良い関係が築けると思います。

どこがどのようにおいしいのか?

アジャイル風開発はナポリタンとかトルコライスのような、名前だけそれらしくしたものでしょうか?それとも同じ方向を目指したバリエーションの一つなのでしょうか?かつて日本のカレーライスをインドの大統領が食べた際に「おいしいですね。なんと言う料理ですか?」と言われたそうです。本人が本物のつもりでも、全くの本物以外はすべて偽物なのかもしれません。

とはいえ「おいしいから良いでしょう」という意見もあるでしょう。でもそれが、どのようにおいしいのか?本物とどう違うのか?ということをきちんと理解しておけば、本物を選ぶ事もできますし、本物でない事を理解した上でよりおいしくいただけると思います。

これらの開発法が問題発生時にどのように対応できるかをラフシミュレーションしてみた記事を書きました。ぜひ、ご覧ください。


リーダーに求められる大切な事 - 100人のプロが選んだソフトウェア開発の名著 -

今回、公開するのは「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」という本に寄稿させていただいたハンフリーさんの「TSPガイドブック:リーダー編 (IT Architects'Archive)」という本の紹介文の全文です。

これまで、[#devsumibook] 誰もが本を読んで学んできた「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」と言う記事で本を紹介し、アジャイル開発への壁は価値観の壁という記事で一部を抜粋して思うところを書いてきました。

最近、アジャイル開発やチケット駆動開発について考えています。その中で、私の考えのベースはやはりこの本だと思いましたので、全文を公開します(構成前の原文を元に体裁を整えました)。

みなさまのご参考になれば幸いです。

ちなみに「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」に関してしては、shimashimaさんのslashdotの書評(その1その2)が興味深いです。取り上げていただいてありがとうございました。


[#TiDD] キャズムを超えつつある!? チケット駆動開発 - デブサミ2013発表を終えて - #devsumi #devsumiB

キャズム(@IT情報マネジメント用語辞典)というと大げさかもしれませんが、チケット駆動開発が当たり前になりつつある、今回のデブサミに参加してそう思いました。

デブサミ

デブサミ(Developers Summit 2013)は、東京の目黒雅叙園で毎年行われているイベントです。タイムテーブルでわかる様に、300人超2部屋、100人超3部屋の5トラック並行の同時1000人規模の大イベントです。メイントラック以外にも同時開催のイベントがあり、入れ替えを考えると数千人規模になると思います。しかも有名人の講演も多く、関西からも毎年、多くの方が参加されています。

今回のデブサミでは、セッションのタイトルを「チケット駆動開発の本質」(リンクは概要)と題して、阪井が「挑戦の道具としてのチケット駆動開発」(下のスライド)、小川さんが「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」(プログラマの思索:スライドあり)を発表させていただきました。

発表時の反応

うわさによると、このセッションは初日では2番目に参加者が多かった(1番はまつもとゆきひろさん)らしいです。この中で小川さんがチケット駆動開発をしている方に手を上げていただいたところ、なんと9割ほどの方が手を挙げられました。

しかも、発表後のAskTheSpeakerという質問コーナーにも、質問される方が5名以上並ばれました。内容も実際のプロジェクトで困っている事や、Wikiの使い方に気づかなかったといった感想など、より実践的な内容が多かったです。

2年前に講演した際は質問される方もパラパラで、ご挨拶や感想が多かった事と比べると大きな違いです。当時は、チケット駆動開発と言う言葉も一般にはまだまだしられておらず、一部の先進的な技術者が実践している感じでした。

発表中のつぶやきを見ても、実践されている方が多い様に感じられます。既に本で知っているという感想がある反面、実践する際の方向付けとして必要となるより抽象度の高い議論へのコメントが多いと思います。

チケット駆動開発に求められるもの

実はデブサミだけでなく、関西のコミュニティでも変化が現れています。これまでは、新しい勉強会があれば、必ずおられる方たちが驚くほど大勢来られていました。しかし、最近は普通の勉強会程度に人数が減る反面、実践されている方が中心になってきたと思います。

 

上のスライド(第6回 RxTstudy(Redmineやタスク管理を考える@大阪)発表資料)に示す様に、これまで小川さんと共著で、Redmineを用いた実践的な内容で チケット駆動開発の良さを説明し、チケット駆動開発の本質を踏まえた様々な面を説明してきました。その結果、それぞれの現場で、それぞれが工夫しつつチ ケット駆動開発を実践されたのでしょう。

そして、幅拾い利用者が増えて、より実践に近い本質的な議論に踏み込む時がきたようです。プロジェクトに大切なものはなにかを意識した、より良いプロジェクトの実践にチケット駆動開発が利用されるように、協力していきたいと思います。

おまけ

ちなみに上のスライドにある様に、入門の書籍が抜けています。かんばん!~もし女子高生がRedmineで「スクラム」開発をしたらのようなわかりやすい文献が出版されないかと期待しています。


光プレミアムからフレッツ光 隼(はやぶさ)への移行

NTT西日本で工事費無料、料金が同じままで光プレミアムからネクスト(NGN)の1Gbpsサービスのフレッツ光 隼への移行キャンペーンをやっていたので、移行しました。

なぜフレッツか

  • 関西ではeoがお得なのですが、@niftyを使っているので別途費用がかかる。メールだけ残して移るのが王道ですが、家族のメアドやココログがあるので面倒
  • ひかりTVが、ほどほどのチャンネル数でまあまあ安い
  • 携帯がauなのでauひかりなら安くなるが、@niftyにつながる戸建てサービスは対象外地域
  • 特に遅いとも感じてなかったが、同じ値段ならひかりTVを使っているので帯域に余裕がある方が良いと考えた
  • 良くも悪くもIPv6の可能性

事前調査・準備

  • ルータ用の無線LANカードは100円でレンタルできるが5GHz帯はない。auの無料レンタル無線LANを継続利用にした
  • 終端装置、ルータ、光電話アダプタが一つになる。LANで光電話アダプタを離れたところにおいていたので、LANを電話線代わりにして、3つの機器を1カ所に集めた(ホームセンターでELPA ADSL用変換アダプタ8極ー6極 TEA-076を購入。サンワサプライやエレコムのRJ45-RJ11変換アダプタより安かった)
  • 直前に届く郵便を残しておく(設定に用いるIDとパスワードがある。IDはひかりTVでも使う)
  • @niftyなどのプロバイダのIDパスワードが必要

工事

  • 1時間かかっていなかった
  • 機器を順番に外し、光ケーブルの終端を再処理して、ルータ接続、動作確認をされ多用す
  • 通話確認までしてもらえた
  • たまたま営業の方が手が空いていたようで、工事担当者とともにこられた。工事は電話開通までだが、お年寄りなどでわかられない場合は設定を手伝う事もあるらしい

設定

  • ルータのIPv4アドレスが変わったので、無線ルータを再起動した。自動判定でアクセスポイントモードになったもよう
  • 簡単設定のマニュアルを見てMacで手動設定しようとした。パスワード設定後、ユーザを聞かれてMacでの設定をあきらめた(ルータのマニュアルにユーザ名が書いてありました)
  • 無線ルータにつながったPCで設定しようとしたが、光電話通話中なPC(OS?)によって異なるエラーが出た
  • 無線ルータを外してLANでPCを接続、メールの設定はSKIPして簡単設定終了
  • セキュリティソフトのインストールエラーは、別のPCで設定済みだから?

ひかりTV

  • 通信ができなくなり、電源をOFF/ONする。
  • NTTのID設定後、西日本は24時間以内に使える様になる旨表示される。
  • 1時間ほど待っても表示が変わらないので、再びOFF/ONすると、正常動作する様になった。

感想

  • 速くなった気もするが、新しいPCは無線LANがメインなので、体感速度は変化なし
  • ルータのLANポートが1Ghzになった(これがうれしい)
  • 機器は1つになってすっきり。S社のゲーム機のような大きさです
  • IPv6(リンク先はWikipedia)への期待と不安

と言ったところです。設定でトラブらない様にWindows PCをルータにLAN接続するのが安全だと思います(短いLANケーブルが1本ついてきました)。

フレッツは他社よりも割高感があるので、品質向上につながるキャンペーンはドンドンして欲しいと思います。

常識を集めたアジャイル - 動くソフトウェアこそが進捗の最も重要な尺度 -

アジャイル開発は常識だ」(プログラマの思索:元ネタはオブジェクトの広場)を読んで思った事。それは、これまでの開発が非常識でアジャイルが常識なのか、それとも既にあるある常識をまとめたのがアジャイルなのか?ということです。

多くの非常識なプロジェクトは実在し、アジャイル開発はあるべき姿なのだと思います。ただ、アジャイル開発でなくても良識的なプロジェクトは存在します。開発者の能力を最大限に活かし、ビジネスの変化に対応しつつ、顧客と協力して確認しながら動くソフトウェアを開発するプロジェクトです(注1)。

そのようなプロジェクトは従来型のプロジェクトであってもウォーターフォールモデルの開発ではないでしょう。しかし、何度もリリースする場合でも、「アジャイル開発とスクラム」にある様にケーキを縦にカットしていないのでアジャイル開発とは呼べないものも存在します。

そこで、アジャイルソフトウェア開発宣言を読み直してみました。ここにある価値は、上にあるような開発で実現できる事です。さらにアジャイル宣言の背後にある原則を読むと、以下の言葉が書かれていました。

動くソフトウェアこそが進捗の最も重要な尺度です。
Working software is the primary measure of progress.

たぶん、これがアジャイル開発の本質である繰り返し開発の本質なのだと思いました。「動くソフトウェア」を大切にし、アメーバ経営のようにゴールに応じた尺度(メトリクス)を設定する。ゴールに向かって、直接コントロールする事がアジャイル開発の特徴なのだと思いました。

以前、従来法の限界に書いたように、従来の開発法には色々な問題があります。それらはアジャイルプラクティスの導入によってある程度は緩和できますが、最後に残る壁があります。これは、ルールだからと使われないメトリクスを集めていては、超えられない壁なのだと思いました。

注1
良識的なプロジェクトは開発者だけの努力によるものではなく、発注側が開発に協力し、仕様変更に対して適切に費用を出す事で実現できます。

アジャイル開発であっても、顧客の協力が得られない場合や、請け負い開発を盾にスコープの変更が受け入れられない場合は、アジャイル開発の価値を提供できないので不幸な結果が待っていると思われます。


認定制度の功罪 - 成功のイメージが浮かぶまで考えていますか - #agileradio

いつも楽しく聞かせていただいているアジャイルラジオの第13回では、認定制度が話題になっていました。難しいテーマですが、少し考えてみたいと思います。

資格を考えてみる

これは、 採用面談での資格を考えるとわかり易いと思います。学生さんがある資格を持っていた時、どう評価するでしょうか?

たとえば、その資格がないとある作業が許されない場合なら、それを理由に採用する事もあるでしょう。でも、その資格がなくても作業が許されるなら、どう評価するでしょうか?

まず、やる気のある事は評価できます。簡単な資格であってもある程度の勉強が必要ですし、少なくとも試験あるいは講習の会場に行っているからです(社会人になってからですが、寝坊して情報処理試験を受けられなかった事があります:-)。

次に考えられるのは、少なくとも一定の知識を持っている事です。資格が得られる試験や講習を受けている事は、資格のない人よりは多くの知識があると考えられるでしょう。習得が困難な資格なら、なおさら評価に値するでしょう。

アジャイルラジオで言われていた教育の側面を考えると、このような底上げとしてのプラス面と、そこで満足して停まってしまうマイナス面があると思います。

ポイントはその資格が活かせるかどうかです。その資格を得る際に学んだ事を仕事の中でどのように活かし、さらに成長できるかどうかでしょう。

認定制度の落とし穴

認定制度の難しさは、難易度が低過ぎては底上げになしませんし、逆に難易度が高過ぎるとあきらめてしまう事です。CMMブームのときもレベル3で止まってしまう組織が多かったそうです。

これは努力すれば定義されたプロセスのレベル3は達成できるものの、定量化されたプロセスであるレベル4を達成するには、収集されたメトリクスを活用する仕組みがなければ長期にわたるプロセス改善のモチベーションが維持できないからだと思います。

CMMのレベルを達成する事は本来の目的ではありません。プロセスの問題を解消する目的でCMMのプラクティを導入していたはずが、いつの間にか手段であるレベル達成が目的になり、開発現場は仕方なしに実施する。そんな事が続いている間にやる気をなくし、プロセスを最適化するレベル5ではなく、定義されたプロセスをどのようにこなしていくかを考えてしまうのでしょう。

より高い目標がなくなると、プロセスは形骸化します。もっと頑張れるのに努力しない、「やったらできる子なのに」そんな聞き覚えのある状況に陥ってしまうのです。

イメージできますか?

CMMで有名だったオムロンの故坂本さんによれば、社内のプロセス標準を充実させなかったそうです。部下には「考えて開発しろ」と言われていたそうです。考えて開発する事がより良い開発につながるからでしょう。

ソフトウェア開発は、世の中に存在しない新しいシステムを生み出す作業です。全く同じソフトウェアを開発する事はありません。新しい条件で、新しいソフトウェアを生み出す際に、全く同じことだけで良い訳がありません。

新しい開発対象や動作環境を考慮して、チームで協力して開発しなければなりません。手順を守るだけでなく、プロジェクトがどのような状態になるかを考えて、具体的な成功のイメージを浮かべておかなければうなくいかないでしょう。常に成長が求められているのです。

まとめ

新しいものを生み出す作業の中で、認定制度は必要な知識を提供する事しかできません。得た知識を体にしみ込ませ、利用し、より良く洗練する事は、認定を受けた側の責任です。

プロセス改善には形骸化の罠が少なくとも2つあります。導入時の形骸化と経年劣化で生じる形骸化です。認定制度は一定の水準を目標とすることで、底上げを実現する反面、これらの形骸化を促進する触媒にもなってしまいます。

やらされ感から現場の問題を見失い、手段が目的になり認定だけを目指してしまうパターン。そして、実施している間に認定で学んだ事がおろそかになり、顧客や組織でなく、自分の事を中心に考えるパターンです。

このような形骸化に陥らず、日々の活動の中で、認定を通じて得ようとしたものがなぜ必要だったか、目的を見失わず、目指している事を実現しないといけません。

開発作業をいつものようにこなしてしまう前に、具体的な成功のイメージが浮かぶまでじっくりと考えて、さらに考えて、実践を通じて成長することがとても重要な事だと思います。

一人でモチベーションを維持するのは大変かもしれません。でも、あなたは一人で苦しむ必要はありません。プロジェクトの仲間は共に考えてくれる協力者ですし、この業界には同じ様に苦しんでいる仲間がきっと助けてくれるでしょう。

おまけ

書籍「チケット駆動開発」は、こうすれば良いという書き方をあまりしていません。どちらかと言うと、テーラリングガイドをはじめとして、こんな事や、あんな事がある、という選択肢を示すと共に、選択する際の大切な考え方を示しています。これは、じっくりと考えた上で、実践して欲しいからです。


ソフトウェア力が抜けてプロセス改善は形骸化した - 「アジャイル勘違い集」を読んで -

オブラブの「アジャイル勘違い集」を見ると、こんな事が書かれていました。

「あなたが用いているのはアジャイルではなく、アジャイルプロセスではありませんか?…(略)…優れたプラクティスを忠実に実践すれば効果を生むこともありますが、その価値と原則を知らなければ、本来の力を発揮することはできません。」

言いたい事はわかるのですが、少し違和感を覚えました。確かに、ここで書かれているプロセスとは、@IT情報マネジメント用語事典にある「ソフトウェア開発や保守などの業務を構成する一連の作業のこと」だと思えばその通りです。でも、昔は違ったのです。

ハンフリー氏のプロセスの定義

CMM/CMMIで有名なハンフリーさんの「ソフトウェアプロセス成熟度の改善」によれば、ソフトウェアプロセスとは「ソフトウェアの生産および進化の中で使用されている活動、手法、および慣習の集合」(p.268)とされていて、入力から成果物(プロダクト)を生成する間の過程のことで、そこには作業以外のものも含まれています。(その他の定義はIPAセミナー1番目のPDF資料に載っていますので参考にしてください)

かつて、SEA SPIN(ソフトウェア技術者協会のSoftware Process Improvement Network)の人たちが、CMMを訳した際には、「プロセス成熟度」ではなく「プロセス能力成熟度」とCMMのC(capability)が意識されていました。

また、巻頭の「日本語版へのメッセージ」にはこうあります。

「ソフトウェア力のいかんが、企業の収益性と長期競争の生き残りに影響を与える事を、多くの組織が認識している」

このようなソフトウェア力を高める目的でプロセス改善が行われます。ソフトウェアプロセスの改善と題した節(p.4)では、こう書かれています。

「プロセスを『正しく実行すれば、望ましい結果を作り出してくれる作業(task)の集合』と定義している」

つまり、ソフトウェア力を高めることでプロセスは成熟する。そのために正しく実行する事で、必要なものが実現できればプロセス、そうでなければプロセスでなかったのです。

ソフトウェア力はどこに行った

では、なぜプロセスの定義が望ましい結果と関係が薄くなり、ソフトウェア力の向上があまり注目されにくくなったかを考えてみます。それには、2つの理由があると思います。

一つは、改善の目的とされていたQCD(品質、コスト、納期)が偏っていたからです。CMMのスポンサーはDoD(米国防総省)なので、信頼性(バグが少ない事)が重視されていたからでしょう。品質と言えば主に信頼性(バグが少ない事)を指していたほか、日本ではコストや納期の改善は品質の改善によって達成されるとまで言われていました(他の品質特性を固定すればあながち嘘ではないのですが、そうとは言えないアプリケーションが増えています)。

もう一つは、プロセスを数値や実施の有無で評価していたからです。良いプロセスを実現するためのベストプラクティスがあって、その通りであれば問題がないと考えられたのです。しかし、それは「修身」や「しつけ」の様なものであり、顧客のビジネスがソフトウェアがいつどのような価値を提供できるかによって成否が分かれる事や、開発者の自由な発想や集中できる環境がより良いソフトウェアを開発する上で大切なものであるといった観点が抜けていました。

実は以前にも紹介した様に、ハンフリー氏は人間的な側面も重視されています。特にチームのプロセスを扱ったTSPの書籍では、サーバントリーダーシップと同じ事を説明されています。

しかし、組織のプロセスをまとめたCMMのレベル争いが流行ってしまいました。多くの組織でレベル達成が目的になる事でプロセス改善の形骸化が進み、大切なソフトウェア力の向上への取り組みが抜け落ちてしまったのだと思います。

スクラムは標準による形骸化から逃れられる可能性がある

第2次アジャイルブームの中でスクラムが本格的に普及しつつあります。きっと日本でもスクラムは、アジャイルの標準になると思われます。

そのような中で、スクラムも形骸化するのでしょうか?そうなって欲しくないですが、どうなるかはわかりません。実はCMMブームの時もレベル争いになってはいけないと多くの方が努力され、より良い形で進んだ組織もたくさんありました。しかし、そうでないところもあったのです(やらないよりはましという声も多くありましたが、、)。

さて、スクラムの特徴はCMMで成し遂げられなかったソフトウェア力向上の仕組みが入っていることです。目指している方向性がゆがめられなければ、うまくいく可能性があります。

もちろん標準化されたものですから、そのままで全ての組織に最適ではなく、ある程度カスタマイズが必要かもしれません(アダプタブルウォータフォール(事例)やCCPMなどがふさわしい場合もあるでしょう)。そのように標準からそれる際に方向性を見失わないようにするには、知恵や経験が必要になります。

幸いスクラムなどアジャイル開発には多くのコミュニティやイベントがあります。公式なイベントだけでなく、スクラムブートキャンプ、スクラム道、XPJUG、XP祭り、アジャイルジャパン、アジャイルツアー、デブサミなど、一般の方も参加できる情報収集の機会がたくさんあります。これらが活用されれば方向を見失う事も減るでしょう。

そして、今年はたくさんのスクラムやアジャイル開発の書籍が出版される様です。去年までは「スクラムを活用したアジャイルなプロダクト管理 」のような翻訳書が多かったですが、今年は和書が多く出版される様です。
直近では「アジャイル開発とスクラム 」、「SCRUM BOOT CAMP THE BOOK」があり、この他にも出版予定がある様に聞いていて、大いに期待できます。

これらの活動や書籍によって、ソフトウェア力を備えたより良いプロセスが広まる事を楽しみにしています。


ソフトウェアの仕様はバージョン管理ツールに従う!?

先日、IE8で開発したアプリを、MS社が配布しているVirtualPCイメージを使ってInternet Explorer 10 Release Previewでの動作を確認していました。変な動作をするものがあるので色々試していると、IE10のIE8レンダリングモードで動かすとIE8やIE9のIE8レンダリングモードと挙動が異なっていて、IE10のIE9レンダリングモードにするとなぜか動くというような経験をしていました(RP晩だからかもしれません)。

そんなこんなで苦労している中、互換性を維持する目的でモードをドンドン増やすのはなぜだろうと、職場の仲間と話をしました。そのときの勝手な想像を書いてみます。

最初に気づいたのはメルヴィン・コンウェイの「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」(リンク先はWikipedia)
といういわゆるコンウェイの法則です。新しいバージョンを開発するチームと既存のチームが分かれていて、それに合わせたアーキテクチャになっているのかと思いました。

次に考えたのは構成管理に使っているツールの影響ではないかということです。集中型のバージョン管理ツールを使う事で、マージが困難になり全体をうまく統合できないのではないかと考えました。

確かに多くのオープンソースの開発は分散バージョーン管理ツール(DVCS)が使われています。そこでは、複数ユーザが特定機能の開発をして、それらを徐々に統合すると言うパッチを中心とした開発が行われていると思います。

もちろんこの他にも想定する顧客が固定されていて、互換性を保ち易いモードの方が喜ばれると考えているのかもしれませんし、モードを嫌っているユーザの声が届いていないのかもしれません。

しかし、バージョン管理の影響の可能性は捨てがたいです。特に集中型のバージョン管理ツールでは、マージを避けるためにブランチをきることが億劫になりがちです。無理な使い方をすると、かえって混乱を招いてしまうからです。

そんな、勝手な想像をしていると、「Microsoft、Visual StudioおよびTFSでのGitサポートを発表。CTP版のプラグインもリリース」というニュースが入ってきました。今後のIEがどのように発展していくのか、興味深く見守っていきたいと思います。

【告知】第7回RxTstudy(Redmineやタスク管理を考える勉強会@大阪)

来る2月16日(土)の第7回RxTstudyでは、「道具としてのDVCS」というタイトルで@irofさんに講演していただきます。DVCSについての考え方を知りたい方には良いお話だと思います。この他にも、アジャイル開発への移行やチケット駆動開発でのEVMのお話、グループディスカッションもありますので、ぜひご参加ください(ご案内・申し込み)。

体年齢というメトリクスを考える - omron KaradaScan 214 -

クレジットカードのポイントがたまっていたので omron KaradaScan 214 (HBF-214)というヘルスメーターに交換しました。

Karadascan214

とても薄い形状で、ガスレンジのようなガラストップのおしゃれなデザインです。類似のデザインが出れば、裁判で争いたくなるのもわかります。

いわゆる体重計なのですが、箱には体重体組成計と書かれていて、多くのメトリクス(尺度)が計測できます。個人データとして年齢、性別、身長を入力(設定は4人、毎回入力するゲストもあります)すると、体重だけでなく、BMI、基礎代謝、体年齢骨格筋率、内臓脂肪レベル、体脂肪率が測れます。

この中で面白かったのは、体年齢です。体のメトリクスは体重や体脂肪率の様に、性別によって基準が異なるものですが、体年齢は個人データで補正した値を表示するので単純に比較できます。

測定のやり直しで1歳の変動がありましたので厳密な値ではない様ですが、家族と比較できるのは面白いです。我が家は既に息子が独立していて、これまで家族と比較する事はなかったのですが、これなら妻や娘と比較できます。

体年齢は、アメーバ経営のメトリクスの様に、共通のメトリクスで、共通の価値観による比較が可能であることが特徴です。個人や小さな組織ごとのメトリクスではなく、家族や会社全体で比較可能なメトリクスは、問題点の見える化を実現しますので、改善を支援するものです。

実際に体年齢は、問題点を明らかにし、改善の必要性を示してくれました。具体的には同じ学年の妻が若くて、私が老けていると言う残念な結果でした。この値を見る事で、問題は明らかになり、改善の必要性を確認する事ができました。

ソフトウェアの世界でこのように開発言語や業務を超えて比較できるものの代表と言えば、ファンクションポイントでしょう。ただ、難点は正確な測定には標準化が必要で、調整に時間のかかる事でしょう。

それに比べると、体年齢は年齢と体重で定められている基礎代謝をに基づくもので、個人データを設定してヘルスメーターに乗るだけで表示されます。このように

  • 問題を示す
  • 比較が容易
  • 収集が容易

という良いメトリクスなのでしょうね。

メトリクスは体験するとよくわかるものです。これまでは何とも思わない数値しかなかったのに、把握できる様になる事で、値を気にする様になりますし、比較して競争する様になります。

ただし、改善を行うのは人間です。若い数値が表示された妻は喜んでいましたので、今後も健康を維持する様に行動する事でしょう。老けた年齢が示された私は、すでに認識している結果が示されて、気にはするもののすでにあきらめ状態になりまいました。

良いメトリクスを使えば問題を意識し、改善に役立てる事は可能です。課題はメトリクスを活かして、互いに協力しながら改善に向けて努力できるモチベーションをどのように維持するかのようです。

« 2013年1月 | トップページ | 2013年3月 »