無料ブログはココログ

Redmineが得意なプロジェクト

Redmineの機能を考えると、どのようなプロジェクトに向いているかがわかります。

プロダクトライン

Redmineのチケットは全てのプロジェクトで通番になっています。他のプロジェクトのチケットを容易に参照できますので、プロダクトラインの開発時の様に過去のプロジェクトの参照が必要な場合に有利です。
参考:『Redmine実践ガイド』に書き忘れた事 - 管理を容易にするチケット番号の一意性 -

System of Systems あるいは トップダウンに分解できる

Redmineのプロジェクトとチケットは、それぞれの親子関係を持つ事ができます。 System of Systems と呼ばれるような、複数のプロジェクトから構成されるシステムも小さな単位に分割して管理できます。
参考:[#TiDD] チケットによる情報の関連付け(チートシート)

多様なコミュニケーションが必要な大規模システム

Redmineには他のITSにもあるWikiのほか、フォーラムやニュースなどの情報共有の仕組みがあります。また、ガントチャートによる可視化やREST APIなどシステム連携機能もあります。大規模システムにも対応できる多様な機能が標準で用意されています。(大規模な開発が多いので参考にある様に「説明会を開くべし」と言う意見が多いのでしょうね)
参考:[#redmine] Remineを活かしたプロセス支援 - 失敗しないプロセス支援 - #rxtstudy

作者のJPL(Redmine.jpブログ)は、このような開発をしているのかも知れませんね。

ちなみに上記に当てはまらない、一度限りのプロジェクト、単独システムあるいは構成が変わり易いシステム、チケットで十分あるいは小規模な場合は、Redmineにこだわらなくて良いプロジェクトと言えるでしょう。

なお、Redmineの特徴を説明しましたが、ITSの導入には知見者あるいは導入意欲を持った人の存在が必要になります。また、過去の資産をどうするかということも、ITSを選択する際の重要なポイントの一つでしょう。

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


[#UAS] Ultimate Agile Stories の寄稿5本を一挙公開!

Ultimate Agile Stories (UAS)は全5册からなるアジャイル同人誌です。

この本は、アジャイルのコミュニティの人達の熱い思いを綴った記事をまとめたものです。頒布による利益は、東北の震災の年から5年間寄付されてきました(まだ在庫があるので、寄付したぐらいの赤字だそうです)。

私もアジャイル関係のコミュニティに出入りしていましたし、日本XPユーザー会関西支部(XPJUG関西)でチケット駆動開発の分科会があったことなどから、全ての本に寄稿させていただきました。

これまで、次の本が出る度に1年前の寄稿を公開してきました。しかし昨年、とうとう最終号になってしまいましたので、これまでの寄稿をまとめて公開します。

UASには、アジャイル放談という飲みながらそれぞれの思いを熱く語り合った記事があります。そろそろ若い人に任せた方が良いのではないか、などと思いながら、なぜか全てに参加させていただきました。

この他にも有名な方々の記事がたくさん載っていますので、機会を見つけてぜひ購入してください(トップのリンク参照)。



UAS5の寄稿

<UAS5の紹介>
[#UAS] アジャイル開発とフィードバックそしてリスク - Ultimate Agile Stories Iteration 5 -



UAS4の寄稿



UAS3の寄稿

<UAS3の紹介>
[#Agile] 自己組織化あるいは自律的組織 #UAS3



UAS2の寄稿

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



UAS1の寄稿

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


そりゃそやろ! - 「アジャイルがダメだと思う7つの理由」について議論して -

「アジャイルがダメだと思う7つの理由」について議論する会を大阪でに参加しました。3年前の元ネタと最近の様子に関する鈴木雄介さんの講演のあと、グループ毎に議論しました。

元ネタについてはすでに書いています(アジャイルがダメだと思う7つの理由を前向きに考えてみる)が、今回はこれまでの経験を踏まえて議論をしてきました。

講演内容

まず、「アジャイルがダメだと思う7つの理由」についてのお話がありました。そして、当時はアーキテクチャとアジャイルのコミュニティが対立していたことからアーキテクトである鈴木さんがアジャイルをあまり良く思っていない事、最近はアジャイル風の繰り返し開発をされている事、をお話しされました。

私も、アジャイル開発の「考え方」と「やり方」を学べ[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -で同じような開発方法を書いてます。

ウォーターフォール開発をベースにアジャイル開発を参考にすると言う話は昔から書いてますが、最近はウォーターフォールがベースに開発する多くの人が工夫しているのでしょうね。

変化ヲ抱擁スルために固定化している

講演の後は7つの理由のグループに分かれて2回の議論しました。というか、賛成と反対の意見に分かれてディベートをしました。1回目は「 変化ヲ抱擁スルために固定化している」です。

元記事では暗黙知の事を書かれていますが、アジャイル宣言の背後にある原則

動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

を取り上げて、プロセスを固定化として、最適化できないとの議論を展開しました。関連するシステムがあり、期限が限られているので、定期的なリリースにあわせる事はできません。

反対意見では、スプリント中にリリースするタスクを作って実施しているとのお話がありました。実務的にはそうでしょうけど、それは原則に従っているのか、1週間ごとのリリースや1日に何度もリリースして、アジャイルというのと同じではないかと言いました。

この他にも2ヶ月ほどの短期開発では、タイムボックスごとのふりかえりなどもあまり効果的でなく、期間内で最適化する方がうまくいくのではというお話をしました。

どこまで原則を守らないとアジャイルと言えないかとの議論はありましたが、それ以外の反論はありませんでした。

なお、そういったシステム間の連携があったり、短期間のプロジェクトが一部の例外と呼べる組織なら、アジャイル開発を標準とすることもアリだと思います。

アジリティはアジャイルだけのものではない

2回目の議論ではグループの全員が「そりゃそうだ」と賛同しましたので、議論というよりは意見交換になりました。

アジャイル開発はアダプティブ(適応型)であるのが基本で、アジャイル(機敏)というのは風呂敷が大きすぎるのではないかと言いました。機敏を実現するには高速開発等の環境やツールなどもあるからです。

ただ、アジャイル開発があったからリーンスタートアップが生まれたんだよね。という意見には賛同しました。そういう意味では、「 アジリティはアジャイルだけのものではないが、アジリティの本家だ」ということだと思います。

おわりに

この記事を書き出してからゆっくり考えました。

私自身はアジャイルに反対している訳でなく、向いている所で実施すべきものだと思っています。

そもそもアジャイルソフトウェア開発宣言は、当時のソフトウェア開発の解決すべき問題点を示しており、誰もが考慮すべき事であると思っています。

しかし、厳密な定義を元せずアジャイル開発の議論をすると、きちんとした技術論にならず、いつもながら不毛になりがちだと思いました。

アジャイル開発であるかどうかは開発者の関心事ではなく、顧客に価値を提供するより良いソフトウェアの実現が関心事です。アジャイル開発に対する議論はもう終わりにして、どのような現場の問題をどのように改善したかを議論したい思いました。

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


iPad mini 2(Retina) 充電不可(Lightning コネクタ故障)顛末記

iPad mini Retina(3が出たので2と呼ばれています。以下 iPad mini2 )で電子書籍を読む(電車でPDFが読める! iPad mini retinaモデル WiFi C?)だけではもったいないので、「ひかりTVどこでも」を見たり、「アマゾンプライムビデオ」をTVで見る際にも使っています。

トラブル発覚

先日、プライムビデオを見ようとHDMIアダプタを接続すると、反応がありません。他のケーブルをつないでみたりしましたが、反応がありません。

同じケーブルにiPhoneをつなげると反応しますので、どうもiPad mini2のコネクタが壊れた様です。

修理価格を調査

AppleCare+に入っていませんし、入っていても2年以上経っていますので、全額自費になります。調べてみると、iPad mini2 の修理費が表示されているのは、大阪市内のお店が12,000〜15,000円、東京なら郵送ですが1万円弱でありそうでした。

地元の京都は表記が無かったですし、会社が大阪なので大阪でも構わないのですが、すでに買い取り価格が 1万5千円程度なのに、郵送したり1万円以上かけるなら、中古のAirかKindleでも買った方が新しい経験ができて楽しいかも、と考えていました。

Smart Doctor PROFESSIONAL

たまたまスマートドクタープロ 京都河原町店の前を通ったので、冷やかし半分で聞いてみると9,800円。ただし、半田作業になるので、(これまではないが)最悪の場合は壊れることがあり、その際は使えなくなるが無料とのこと。

修理費が高いから捨てようとしていたので、それだったらと持ち込みました。1時間半ほどたって修理完了の電話で伝えられたのは、「クラック」だったので部品交換せずに済んだので、7,800円とのこと。予想外に安くつきました。

ただし、部品交換していないこと、コネクタは使い方次第なので修理後の保証期間はないとのこと。ただし、なにかあればチェックはしてくれるとの事ですので、良心的だと思います。

原因の考察

クラックということで、たぶん半田が浮いてきたのでしょう。思い当たるのは、アマゾンプライム再生機としてHDMIアダプタをずっと付けていた事です。

少しぶら下がるような状態だったので、負担になったのでしょう。今後は気をつけたいと思います。

おわりに

1万円以上も出すのだったらと捨てるつもりでしたが、現状なら中古で売っても差し引き7,000円のプラス。元々、気に入って買ったものですし、色々と使い道もありますので、本当に壊れるまで使っていきたいと思います。

今回、勉強になったのは、金額が表示されていなくても修理できる事があるという事です。部品の在庫まであったので不思議な感じがしますが、全国展開しているので難しい修理は相談してください。という事なのでしょう。

ということで、動く様になりました。よかった、よかった。

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

『Redmine実践ガイド』に書き忘れた事 - 管理を容易にするチケット番号の一意性 -

Redmine実践ガイドの5章の終わりに「Tracユーザーから見たRedmine」というコラムを書きました。先日のRxTstudyに参加して、Redmineのチケット番号の一意性の優位点について書き忘れている事に気付きました。

具体的には、あきぴーさんの発表のスライドの「PJ分割ルールの効果」のところで、

「そんなの、1プロジェクトにバージョン管理ツールの1リポジトリがあたりまえじゃん!」(なぜか浜っ子風)と、思った時に気付きました。

Tracは1プロジェクトに1リポジトリが基本です。複数プロジェクトでリポジトリを共有する際は、リポジトリからTracへの参照にプトジェクトを示すプレフィックスが必要になります。

でも、Redmineではそんなのお構いなしで、一つのリポジトリを、親子であろうと無かろうと、複数のプロジェクトから参照できます。

このような違いが出るのは、Tracのチケット番号がプロジェクト毎に0から始まるのに対して、Redmineのチケット番号は全てのプロジェクトで通し番号になっているからです。常にチケット番号が一意に決まるので、リポジトリからの参照にプロジェクトのプレフィックスが不要になります。

機能的には同じですしツールを使っているなら大きな違いはありません。でも、Tracの場合はあらかじめプレフィックッスを付けて運用を始めないといけないので、同じプロジェクトでずっと運用する事になりがちです。

一方、Redmineの場合はとりあえず始めておくことができます。そして、予算等の管理単位や派生開発等で構成メンバーが異なるなど、1つのプロジェクトでやりにくくなった場合に別のプロジェクトや子プロジェクトに分ける事ができます。

Redmineはチケット番号が通し番号なので、見ていないチケットがあるかどうかがわかりにくいという面もありますが、プロジェクトが長期にわたったり、大きくなると有利な面があるのですね。

追記:

このような理解ができて、ようやく赤羽根さんが努力されている価値がわかりました。Redmineを複数立てない事がRedmineの活用につながると思います。

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


標準化やタイムボックス管理ではできない具体的な支援をするプロジェクトランゲージ - カレーの作り方から考える -

第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」で発表しました。

プロセスはモデリングすることで知識を 伝達、理解、改善、管理、 支援、自動化できますが、現状の扱われ方はカレーの作り方で言うなら、重量やカットした結果を測定したエビデンスを求める。あるいは、分担を決めたり、定期的な味見をする事が決められているだけです。



たとえば顧客向けのデモを実施する必要があった時も現場が考えることが求められるだけで、過去の経験を参照したり応用する方法は支援されていません([#TiDD] パタンランゲージで経験を活かしたプロセスを構築する)。

建築分野などで用いられるパタンランゲージはそのドメインで解決が求められている(要求されている)問題とその解決策等を整理したカタログです。

プロジェクトランゲージはパタンランゲージを元に、ワーキングマスタープランを用いて、顧客と共に段階的なプロジェクトを構成していきます。そのドメインで求められているパタンを具体的な制約を踏まえて組み合わせるので、ノウハウを活用する事ができます。

このような方法をとるには、まずDDDのユビキタス言語にも似たパタン(=対象ドメインで求められているもの)の素(言葉)を集めないといけません。そこで、過去のチケットを分類して、チケットを活用できないかを考察してみました。

なお、スライド中の航空写真は奈良先端大(NAIST)付近の北大和住宅にある地区センター付近のものです。パタンランゲージとプロジェクトランゲージは当時の様子を回想して独自に考えたものです。

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

巨人の肩に乗るBABYMETALを輸入版ブルーレイでチープに楽しむ

BABYMETAL(リンク先はWikipedia)は、なぜこんなに人気なのでしょう。自分が好きな事を置いておいて、輸入版ブルーレイディスク(BD)を見ながら考えていました。

1枚目:武道館ライブx2

もともと、YoutubeとアマゾンのPrime Musicで楽しんでいましたが(BABYMETAL :「ブルーオーシャンは闇の中」あるいは「デカルチャー」)、やはりライブの雰囲気が知りたくなりました。

最初に買ったのは「LIVE AT BUDOKAN 〜RED NIGHT & BLACK NIGHT APOCALYPSE〜」です。アマゾンのimport盤には曲数が半分だけ載っていますが、コメントにある様に日本版と同じ28曲は言っています。

輸入版は国内・国外があります(輸入版販売リスト)。この時は、早く見たかったので国内で買いました。

このBDは2日連続で行われた RED NIGHT と BLACK NIGHT のコンサートの内容を収録したものです。 RED NIGHTの方はCDになっているからか、ちょっと音が良い気がします。

中身はバッチリです!1枚目の通常版アルバム曲+2曲を、日本らしい丁寧なライブ映像です。

2枚目:ロンドンライブx2

1枚目が良かったので、もう一枚買いました。

2枚目は「LIVE IN LONDON -BABYMETAL WORLD TOUR 2014-」で、1枚目の前にヨーロッパで武者修行した際の初めと終わりのライブです。ストーリーがこの後の武道館のライブに繋がっています。

さすがバリライトを初めて使ったジェネシスの国です。照明が激しく動き、点滅します。

会場もノリノリで観客の上を転がったり、持ち上げられたり、走り回ったりします。1本目の後半はちょっと多過ぎかと思うぐらいカメラが切り替わり、ライブ感がたっぷりです。2本目はカメラがやや引き気味ですが、3人の様子が良く分かって、これはこれで楽しめました。

驚くのは観客が日本語の歌詞で歌うことです。特に1本目は女性も含めたコアなファンが多いのか、意味が分からないと盛り上がれないのねだり大作戦の「天使の顔した悪魔のささやき」のところで、一部で盛り上がっているのにはびっくりしました。

このBDは輸入版販売リストで安いお店を探して買いました。発送が早かったのですが、中継が多いのか2週間以上かかりました。

なぜこんなに人気があるのか?

初めて見た時は「なぜこんなに人気があるのか?」と驚きました。でも、見ている間にお気に入りになりました。それには、いくつかのポイントがあると思います。

◎ 巨人の肩に乗る

論文を書く際に言われる「巨人の肩に乗る」という言葉がありますが、BABYMETALはこれを見事にやっています。アイドルの基本、パントマイム風のダンス、世界的に評価されている神バンド、など、基本を押さえた上でアイドルとヘビーメタルを融合した新しい世界を構築しています。

本格的だからこそ、安心してヘビーメタル好きも楽しめ、ヘビーメタルに興味の無かった人も興味を持てる様になるのでしょう。

◎ 遊び心

本格的とはいえ、遊び心もあります。コミカルなダンスのほか、なぜかレゲエが入っていたり、父親におねだりする歌があったり、「1たす1は2」等という歌詞があったりと、色々と楽しめます。初めは何をふざけているんだろうと思いましたが、海外でみんながノリノリで、走ったり、持ち上げられたり、転がったりしているのを見て、もっと単純に楽しめば良いと思い、より楽しめる様になりました。

ヘビーメタルの世界にはメロイック・サインというものがあります(ハルクホーガンのウィーの指サイン)。これをBABYMETALが教わった際に「キツネさんだー♪」と遊んでいたら、それが採用されたそうです。このユルさは、元々ユニットだったこともあるのでしょうけど、面白いですね。

◎ ピボット

元々は成長期限定アイドルグループさくら学院のクラブ活動である「重音部」として始まったそうで、最初の頃は学生服姿で歌っていたり、エレキギターを持たされたりしていた様です。しかし、どんどんピボット(方向転換)して、尖っていきました。海外で注目される様になってからは、能の舞台や日本的な節回しやかけ声、外人が好きそうなカッコいいコスチュームなど、どんどんピボットしています。

ももクロ(リーンを考える - 無駄と必要なアソビ -)もそうでしたが、マーケットや状況にあわせてピボットする事が、未来につながるのでしょう。

おわりに

本格的なファンならWeb会員になって独占販売の高価なBDも買うのでしょうけど、チープに楽しむのも良いかとまとめてみました。いかがでしょう。

今週末にWOWOWでもライブをする様です(BABYMETAL WORLD TOUR 2016 kicks off at THE SSE ARENA WEMBLEY)。WOWOWは1ヶ月2,300円しますが、ひかりTVの無料視聴ができたので、こちらもチープに楽しむ予定です。

「アチャチャチャ」ってなんやねん!と思われる方も、一度じっくり見てください。思いのほか楽しめると思います。

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


アジャイルのレフトウィングには壁がある - 自律的組織実現への考慮点 -

アジャイルには開発環境のライトウィングとチーム環境のレフトウィングがあると言われます(アジャイルの「ライトウィング」と「レフトウィング」:An Agile Way:オルタナティブ・ブログ)。

この中でも難しいのがレフトウィング、特に自己組織化されたチームです。アジャイル開発を始めたからといっても簡単には実現できません。自己組織化されたチームを実現するにはチームのメンバーの価値観を変える必要があるからです。

注:筆者はすでにイテレーションの実現あきらめていますが(ミーティングに同期するタイミングはあります)、それ以外のアジャイル開発の要素には重要な内容が含まれていてなるべく実現しています。特に自己組織化はマネージメントの重点であり、20世紀からネットワーク組織とか新しいリーダーシップ(支援者としてのリーダー - 「リーダーシップ3.0」を読んで -)として語られている重要成功要因です。

すでにアジャイル開発への壁は価値観の壁で、基本的な考えを書きましたが、今回は具体的にどう言う点に注意しているかを欠きたいと思います。

自己組織化され他チームは自律的であり、従順ではいけません。それぞれが考え、能力を発揮し、貢献することが求められています。そういったチームの実現には3点への考慮が必要です。

  • オープンな議論ができる
  • 互いにリスペクトできる
  • 話が噛み合うこと

それぞれにどのような注意点があり、どのように対応しているかを整理したいと思います。

オープンな議論ができる

基本は序列を気にしないで技術論を戦わせる事ができることでしょう。上の人はサーバントリーダーシップを心がけて、対等な関係を築かないといけません。

ピラミッド型の組織を経験した人は従順で自分の意見を言おうとしません。なぜそう考えるか、どうやると良いと思うか、と聞いてみると良いかも知れません。

時には最終判断を迫ってくるかもしれません。「聞いて答えたらそうするの?」と言った事もあります。まずは考えてもらい、議論する事が大事だと思います。

やらないとわからない事はやってみたら良いと思いますし、考えてないなら考える様にアプローチしないといけません。それは上に従うのではなくてチームで考え、みんなでゴールを達成し、共に喜ぶために必要な道のりです。

互いにリスペクトできる

偏差値教育の弊害でしょうか、それとも頑張れば神や仏になれるという宗教の影響でしょうか、日本では一つの基準で人が評価されがちです。立身出世という言葉からは昇進する事が成功で、できない人はダメという印象を受けます。

しかし、人それぞれに特長があり、存在価値があります。能力が低くても努力して貢献した人は賞賛すべきですし、能力があっても協調せず、貢献しない人は評価されるべきではありません。

アジャイル開発では多能工、いわゆるフルスタックなエンジニアが揃うとうまく回し易いでしょう。しかし、それぞれの特徴的な能力が生かせる環境も大切だと思います。

書籍SCRUM BOOT CAMP THE BOOKでは、それまで目立たなかったバッチ君が後から活躍します(日本でスクラムを実践するなら読んでおきたい本(SCRUM BOOT CAMP THE BOOK))。このバッチ君のように自分の能力を生かして貢献し、能力を生かせたことを共に喜ぶような価値観の焼き直しが必要だと思います(日本文化に仕立て直した実践書 - SCRUM BOOT CAMP THE BOOK の意義 -)。

人それぞれ、多様な価値感や経験、事情があります。それらを考慮してプロジェクトを運営し評価する必要があります。その多様な評価が、互いのリスペクトに繋がり、対等に議論できる環境の実現すると思います。

話が噛み合うこと

チームで意見を交換するには、全体のゴールを共有できている必要があります。もちろん個人の目的は違っうでしょうが、全体としては同じ方向を向かないと議論ができません。

時間精算だからサボったほうが売上が増えるとか、時間精算がないから変更はなるべく受けない、など自分勝手な基準ではなく、ゴールを把握した上で互いのビジネスモデルも理解してWin-Winになれないといけません(アジャイルかWFかの議論はやめよう。大切なのはWin-Winの実現)。

おわりに

アジャイル開発宣言はソフトウェア開発に必要な要素をまとめたものです([#Agile] アジャイル宣言と原則の私的まとめ)。なかでも自律的な組織に関してはソフトウェア開発だけでなく、変化の激しいビジネスでも必要とされているものです。

かつての追いつけ追い越せの時代は進む方向が明確でしたから、トップダウンにコマンドコントロールする事が効率的でした。しかし、すでにトップグループに入ってしまった日本は、変化する状況に追いつくだけでなく、日常的にイノベーションを起こせる自律的な組織が求められています。

今回は自律的組織の実現に必要な考慮点と取り組んでいる内容をまとめました。少しでも皆様の参考になれば幸いです(他に良い方法があれば教えてください)。

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


[#TiDD] パタンランゲージで経験を活かしたプロセスを構築する

プロセスが好きだと言うと若い人は怪訝そうに見られる。品質保証の人からは「SEPG(標準プロセスを制定するグループ)とかですか?」と聞かれる。アジャイルな人達は「プロセスやツールよりも個人と対話を」と言われる。

そんなことは無いはずです。一般に「プロセスはタスクの集合」と定義されるからです。つまり、ソフトウェア開発をしている人は皆、プロセスを実行しているからです。

モデリングの失敗

このようにプロセスが他人事の様に語られるのは、プロセスのモデリングに失敗しているからです。「ソフトウェアプロセスもソフトウェアである」と言われていますが、これまでのプロセスのモデルはプロセス特徴を表現できなかったからです。

そもそもプロセスモデリングは、プロセスの知識を伝達、理解、改善、管理、 支援、自動化するものです(参考:[#TiDD]失敗しないチケット駆動開発 - プロセスモデリングの視点から+告知 -)。しかし、ウォーターフォール(WF)の標準プロセスやスクラムは、メタなプロセスと汎用的なプラクティスを示したもので、過去の具体的な経験を伝え、そのノウハウをソフトウェア開発として活かす仕組みは、肥大化し易い標準プロセスによる管理や開発チームの習熟に依存しています。

例えばユーザデモ

たとえば「段取り8分」といわれるように段取りは重要ですが、例えばユーザデモをどのように調整するかといった基本的な事もうまく支援できません。

【標準プロセス】
仮に標準プロセスに実施方法を書いたなら、「うちはこのやり方です」と顧客に言ったり、何らかの事情でテーラリングしたくても制約を受けてしまう事があるでしょう。
逆に詳しく定義しなかった場合は、それぞれのプロジェクトでWBSなり線表に落としますが、どのような条件があってその計画にしたかがわかりません。このため、前回は顧客が用意してくれたので、デモ用のデータや会場の準備を忘れるかもしれません。
経験の少ないマネージャーなら、マイルストーンの設定だけで必要なタスクが漏れているかも知れません。

【スクラム】
スクラムではタスクの依存関係や期限をうまく管理しないいけませんが、タイムボックスからあふれて間に合わないなんてことが起きるかも知れません。
ベテラン揃いなら色々な工夫や調整を行うのでしょうが、それはプロセスで支援されるのではなく、開発に関わる人達の習熟に任されています。勉強会やコーチが必要な訳です。

どんなモデルなら支援できるか

これらのプロセスモデルをソフトウェアの概念に当てはめてみると、クラスや機能であって、段取りに必要な関連や状態概念が不足している様です。

【クラス指向】
WFの標準プロセスは抽象クラスの責務でモデル化されています。WBSに代表される様に細かな構造に分解してプロセスを定義します。インスタンスに相当する内容は自由だが責務だけは果たす様に求められています。CMMを提唱したハンフリー氏らはプロセスのスキップが最も大きな問題と考えていて、抜け漏れチェックが重視されています。ただし、このモデルに基づいてもインスタンス化する際に考慮が必要な内容は直接は支援されず、組織内で定義し、訓練によって実現しないといけません。

【機能指向】
スクラムのロールモデルは機能で分割され、ロール間やロール相互のコミュニケーションに必要なアーキテクチャ、具体的には外部との連絡、コンセンサスの共有、などの仕組みを持ちます。実現する順序はバックログで管理されますが、バックログの調整はオブジェクトである人に依存しています

このように プロマネ、リーダ、プロダクトオーナは苦労しています。それは具体的なプロセスで考えないといけない段取り、つまり状態があまり支援されていないからです。

【状態指向】
実際にプロジェクトを実施する際には、具体的な開発対象の状態が考慮されます。具体的には、いつまでに何を作るかを考えてそれに至る道筋を考えています。これがいわゆる段取りです。上記2つのモデルでは具体的な開発対象を直接扱いませんので支援が行えないのです。そこで開発対象の状態を考慮したプロセスが必要になります。

パタンランゲージ

そこでパタンランゲージです。開発の計画を立てる際は、ゴールや制約に合わせて、過去の経験した作業を当てはめ、必要に応じて作業を組み立て直します。まさにマネージャがしてる事です。

パタンランゲージを利用する際は、この工程をパタンランゲージとプロジェクトランゲージ2段階で行います。関係者からのインタビューで良いと思ったものをパタンランゲージとして整理し、制約を考慮して組み合わせてプロジェクトを段階的に構成していきます。

パタンランゲージはどのような問題(フォース)をどのように解決するかを集めた、いわゆるパターンの集合です。誤解を恐れずに言うと、そのドメインに特化したDDDのユビキタス言語に相当するものだと思います。

プロジェクトランゲージでは パタンランゲージを構造化・洗練したものを表の縦軸に、プロジェクト横軸に取った表を作成します。実施する交点につける印が多くなる様に、制約を考慮してプロジェクトの実施順序を決めます。ちょうどユーザーストーリーマッピングを左に回転させたようなイメージです。

(参考:本橋、中埜、羽生田、懸田、江渡、パタンランゲージからプロジェクトランゲージへ共創のプロセス(PDF),AsianPLoP 2011)

パタンランゲージで経験を活かしたプロセスを構築する

ここで先ほどのユーザデモを考えてみましょう。ユーザデモはパタンの一つですので、パタンランゲージに加えられるでしょう。

それだったら従来のプロセスでユーザデモを追加したのとあまり変わらないのではないかと思われるでしょう。実はこの時点で他のパタンと同列に並んでいる所が後で効いてきます。

プロジェクトランゲージを作成する際はセンターと呼ぶ概念や対象物を明確にします。ユーザデモがより重視されるならレビュー作業を中心的なものにするかも知れませんし、逆にユーザデモをキーマンに対してだけ実施するかも知れません。

従来だとユーザデモのような作業は足し算でしかなく、標準プロセスや元のフレームワークを変更する事はできません。パタンランゲージは関係者で協議して方向性を決める(センタリング)しますので、バランスの良いプロセスを再構築できるのです。

どこから始めるか

パタンランゲージのやり方は、小規模プロジェクトでよくやっている事です。示された制約と使えそうな経験を思い浮かべ、依存関係のあるまとまりでその実施順序を決めていきます。

ソフトウェア開発の規模が小さくなると実施できる事が限られます。関係者で議論する事でバランスの良いプロセスを構築して、顧客の要望に応えていたのです。

経験を集めてパタンランゲージを構築する方法は、チケット駆動開発で作成した過去の履歴を分類して活用できると考えています。

まずはチケットにどのような経験が蓄積されているかを調べ、その結果を次回のSEA関西&RxTstudyの勉強会で紹介するつもりです。

まとめ

具体的な計画をする際に現れる制約をモデル化せずにクラスを作ったり、枠組みを作っても上手くいきません。その状態で頑張れば頑張るほど、大事な事が個人に閉じてしまいます。

今回紹介したパタンランゲージのアイデアは、過去の経験を元にプロセスを構築する方法です。チケットをうまく利用する事で、プロジェクトに適したプロセスを構築できると思います。

【告知】
すでに募集している次回のRxTstudyの講演内容を変更し、上記のような考え方とチケットの関係を説明するつもりです。ぜひ、ご参加ください。

第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」 (07月30日) https://rxtstudy.doorkeeper.jp/events/44608

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

日本は遅れているのではなくやられている - いつ追いつくねん! -

古くから日本は米国に5〜10年遅れていると言われていました。現在もその差は縮まった様には思えません。しかし、よく考えると遅れてるのではなくて負けている、いや、やられているのではないでしょうか?

日本は遅れているか

ここ20年ぐらいを振り返ってみると、CMMブームやアジャイルブームなどがありましたが、CMMが出てきた時は日本のある企業がだいたいレベル3だと記事を書かれていましたし、スクラムやリーン等は日本の技術を参考にしたと言われています。

日本ではそれぞれの企業文化があったにも拘らず、まじめにレベルを1つずつ2−3年かけて上がろうとして、いわゆるレベル3の壁にぶちあたり、企業文化もつぶしてしまいました。

その間にインドは数年でレベル5を達成し、オフショアビジネスが成功しました。アジャイルの源流になった日本の技術や、アジャイルとの向き合い方も同じようにやられている感じがします。

むかしは国際会議でも日本企業の品質管理は高い評価を得ていました。ただ、日本の技術は企業内での技術にとどまり、世界に向けてアピールや標準化、技術をビジネスに活かすのが下手だったと思います。

「ソフトを他人に作らせる日本、 自分で作る米国」を読んでという記事のスライドにあるように、 ハンフリーさんの「ソフトウェアでビジネスに勝つ 」にはリリース済みのソフトウェアが、20欠陥/KLOCだったとされています。50行ごとにバグがあるソフトをリリースするなんて日本ではあり得ないと思います。

アジャイル開発の比率が低いのは遅れているのか

アジャイル開発しか考えられない人には遅れている様に感じるかも知れませんが、

米国IT業界に過去あった多重下請構造、それが破壊された理由 - プロマネブログ

にあるように、英語圏ではCMMブームの後にオフショアブームがあって、プロセスの品質が保証できる海外に従来型のビジネスが流れました。結果的にオフショアが困難なビジネス直結型の開発が残ったと言えるでしょう。

遅れているとすればオフショアですね。

なぜやられているのか?

CMMの時はこれまでのやり方は古い、標準プロセスで組織全体を改善してレベル達成だ!と頑張った企業も多かったので、すぐにカイゼン文化を捨ててしまいました。そうこうするうちにCMMIになって段階的でなくて良いなどと言われ、仕切り直し。ブームには良い点もありましたが、日本の企業はかなり疲弊した様に思います。

真面目に頑張っても、オリンピックのようにルールを変えられます。スクラムガイドも初めは優先順で、書籍「アジャイルと規律」にある他のアジャイル開発法のようにリスクベースでないと使えないと思っていたら、次の版では表現が変わりました。どうやって優先順で開発するのか頑張らなくて良かったと思いました。

日本人は真面目なので、良いものと言われると「守破離」よろしく、まずは完全に実施しようとします。でも、ビジネスにレベル5が必要だからそれを達成すると割り切れば、インドよりも早くレベル5を達成できたのではないかと思います。

このように振り回されない方法は、ルールを決める側に立つことです。すでに多くの日本企業が規格委員会に入るなどされていますが、もっと多方面でアピールする必要があると思います。

可能な戦略

とはいえ、多勢に無勢だったり、ビジネスとのつながりや、リソースの問題もあって正攻法が正解とは限りません。やられないには工夫が必要です。

【別の道を進む】
同じ土俵にたたない方法です。遅れていると言われようがビジネスが成り立つなら、それはそれで勝者です。トコトン極めて最後に残れば、誰にも負けない存在に慣れるでしょう。希少価値が出るかも知れません。今さらCOBOLと言われていたのに、2000年問題ではかなり儲けた方もおられるのではないでしょうか。

【使えそうなところを取り込む】
技術には想定する対象がありますので、そのままでは使えないなら、必要な所だけを取り込めば良いと思います。デザインパターンや組織パターンでさえもパタンランゲージ([#agileto2014] コーディネートは全体で - Agile Tour Osaka 2014「パタン特集」 -)の考え方の一部を利用したものである事を知ってから、特にそう思う様になりました。

【追いつき追い越せ】
とはいえ流行りの技術には、最新の技術が集まります。そのまま適用できるなら部分的でなくしっかり使うのも良いでしょう。ただし、受け身にならないで得意分野だけでも貢献すべきだと思います。情報発信すれば情報は集まります(情報を得るには Give & Give - 発表のモチベーション -)。いずれ追い越す事も可能でしょう。

おわりに

遅れているからやらないといけない。なぜなんでしょうね。変わらないといけないのは問題がある時です。そうでなければ、少しずつ改善すれば良いのではないでしょうか。

人が存在価値を発揮するは、その人の能力を発揮した時です。ブームに乗っても能力が発揮できないなら、意味がありません。社会貢献(ビジネスを含む)ができる得意分野があるなら、そこで能力を発揮して楽しめば良いと思います。

これ以上やられちゃったら嫌なので、、

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


«WFかアジャイルではなく、将来のソフトウェア開発を考えてみた