無料ブログはココログ

« 2016年6月 | トップページ | 2016年8月 »

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

第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

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

« 2016年6月 | トップページ | 2016年8月 »