無料ブログはココログ

« 2013年7月 | トップページ | 2013年9月 »

[#TiDD] チケット駆動開発をプロジェクト管理の視点だけで考えてはいけない #gxptech

グロースエクスパートナーズ株式会社(GxP)様の無料セミナーにお招きいただいて、「チケット駆動開発の大切なこと」と題した講演をさせていただきました。

のどの調子が悪かったり、盛り込みすぎて時間が足りなかったりと、ご参加いただいた方には申し訳なかったですが、資料の方はお楽しみいただけると思います。

今回のセミナーで興味深かったことは、チケットシステム(ITS)を理由なくプロジェクト管理ツールとして考えてはいけない、という合意ができたことだと思います。

これには2つの見方があって、鈴木 雄介さんはガントチャートのツールとして使わないこと、私は管理的な視点で使わないこと、それぞれ別の考え方ではありましたが、同じ結論であった訳です。

鈴木さんいわく、作業の依存関係の管理や日程変更がうまくいかないとのこと。これは、チケットシステムの関連や日程はチケットの属性に過ぎないことです。

MS Projectなどガントチャートを書くことが重要な機能であるツールでは、画面上でスケジュールを関連づけたり、変更することができますので、そのような操作がプロジェクトを進める上で重要な場合はチケットシステムを使うことはあまりお勧めできないと言う意味です。

これには私も合意ですが、遠隔地で最新の情報を共有することが重要な場合や、多くの計画変更を効率よく管理したい場合には有効だと思っています。Redmineのユーザでスケジュール変更する際に、一旦excelに出力してマクロで一括変更するということをされている方もおられます。

一方、私の考えは世の中のパラダイムシフトに対応していくには、自律的な組織でないとうまくいかない、ということがベースにあります。管理の視点だけでチケットシステムを使うのではなく、現場の能力を最大限に発揮するという視点で利用すべきと言う主張です。

自律的なチームという視点でチケット駆動開発(TiDD)を実施する場合、チケットシステムはプロジェクト管理ツールとしてではなく、いわば

  「カンバン、黒板、グループウェア」

として考える方が良いと思います。もちろん、ワークフローを用いてプロジェクトの規律を支援するツールとしても使えますが、自律という視点ではと言うことです。

カンバンというのは、ガントチャートのように日付ではなく、ある期間に実施するタスクのリストをステータスで管理するカンバンです。黒板というのは人工知能の黒板モデルにおける分散協調のための情報共有基盤で、メンバーの「気付き」に必要な物です。グループウェアというのはCSCW(computer supported cooperative work) に必要なコミュニケーション基盤という意味です。

このように意見は異なりますが、「チケット駆動開発」も銀の弾丸ではなく、しっかりと考えて実践してください、ということです。

過去の著作では、チケット駆動開発を銀の弾丸のように書いていないのですが、ちまたの方法論のようにある特定の方法を示す物だと思われていた、と思われる方もおられることを知ったのは驚きと共に大きな発見でした。

チケット駆動開発とは、問題に応じて様々な対応のできる経験値の集合のようなものです。書いてある通りにやればうまくいく物ではなく、状況に合わせて選択・応用するものだと考えています。

これまで、書籍「チケット駆動開発」の評価の低いレビューが理解できなかったのですが、「銀の弾丸」を見つけるつもりで読まれていれば、その期待には沿っていないかもしれないと思いました。

このほか、パネルディスカッションでは「組織パターン」を訳された和智 右桂さんも参加され、組織パターンも組み合わせて実装するためのパターンであることを確認できました。これは,、以前からスクラムに関して感じている危惧とつながる大切な確認ですので、いずれ、まとめたいと思います。

【告知】今回と同様の内容をベースにさらに洗練し、さらに事例を追加して、9月12日(木)午後のSRA関西セミナーでお話しします。書籍「チケット駆動開発」「Redmineによるタスクマネジメント実践技法」の第一筆者の@akipiiさんにも講演していただきますので、関西方面の方は、ぜひ、ご参加ください。

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


[映画] 正義の難しさ - Star Trek Into Darkness -

先行上映を見てきました。ネタバレしない範囲(のつもり)で感想をまとめます。

スタートレックシリーズはまんが宇宙大作戦を除くドラマ・映画は全て見てきました。特にドラマシリーズには、宇宙大作戦は社会風刺、新スタートレックは感情、ディープスペースなインは正義など、ただのSFでない大人も楽しめるストーリーが背景にあるところが気に入っています(あまりないシリーズや複数のストーリーを持つ物もあります。まとめて見るとよくわかりますw)。

これに比べて映画は、ファンサービス用の良くできた1話を作ったようなイメージがあって、あまり好きではありませんでした。しかし、1周回って宇宙大作戦の前の時代に戻った、前作のスタートレックは、カークとスポックの友情を中心に描いた、きちんとした映画になっていて、新しいスタートレック映画を予感させるカッコいい映画でした。

今回のスター・トレック イントゥ・ダークネス(公式サイト)は、CMを見てるだけでも映画として期待を抱かせる物で、生まれて初めて先行上映を見てきました。

前作以上にすごい映像で、迫力満点です。SFアクション映画としても楽しめます。先行上映では2Dしかなかったのですが、3Dで見直したい場面もたくさんありました。

お話はカークとスポックの友情も描かれて、ドンドン盛り上がっていきました。でも、その中で、ふと「見たいスタートレックはこれだったのか?」という疑問を抱きました。

単純に楽しめるだけではなく、背景にメッセージ性があるのが「スタートレック」ではないのか?そう思うと、素直に楽しめない気持ちになりました。

しかし、話が進むと色々とややこしくなって「これがスタートレックだ!」と言うべき、ストーリーが見えてきました。タイトルの「ダークネス」でわかるように正義についてです。

スタートレックの描く正義は複雑です。普通のSFの様に、悪者が居てヒーローが倒すだけではありません。スタートレックDS9のロミュラン人(Wikipedia)、エンタープライズの第3の性(U.S.S Kyusyu)、(ウルトラマンで言うとジャミラ)のような、視点によって正義は変わるというメッセージです。

世の中は単純な視点で善悪を決めがちですが、立場によって別の見方があること。これはソフトウェア開発でも、ビジネスでも、人生でも、意識しなければいけない大切なことだと思いました。

おまけ

パンフレットを見ていると、前作から別の時間軸が始まったように書かれています。次回作を期待してしまいますね。


【告知】チケット駆動開発の知っておくべき大切な事 - 講演の構造 - #TiDD

前の記事に技術発表の構造を書きましたが、講演の場合は若干異なります。

技術発表の場合、通常15分か20分、長くても30分ぐらいでしょう。1時間前後の講演の場合、技術発表と同じ比率では、前フリが長くなりすぎて聞く方が飽きてしまうと思います。

そこで、よくあるのは、

  • 複数の技術発表を組み合わせる
  • 技術発表に事例を追加する

という構造です。

複数の発表を組み合わせるというのは博士論文で良くあるパターンですが、話が発散しがちです。でも、うまくまとめられないと聞きにくいと思います(参考:博士論文公聴会<-スライドは二個一ですが論文は三個一でした)。

事例を追加するというのは、無難な選択肢です。単純に技術発表と事例発表を加えると40分ぐらいにはなります。さらに少し肉付けしたり、時間の関係で我慢していた話を加えるなどすると、それなりの時間になります(参考:挑戦の道具としてのチケット駆動開発)。

(8/13追記:これ以外にも汎用的なスライドをたくさん用意して、飛ばしながら説明するパターンもあります。この方法はスライドの利用効率に優れます。その反面、良く聞いておかないと話の筋がわからなくなってしまいます。話を聞いてもらえるのは嬉しいのですが、情報の多いスライドの文字を読んでいる人が置いてけぼりになりますので、間違いなく伝えるという点ではあまり良くないと思います。)

さて、8月24日(土)にJIRAエキスパートであるグロースエクスパートナーズ株式会社(GxP社)のセミナーで、チケット駆動開発の講演をさせていただきます。

【告知】 2013/8/24(土)
GxP社「SIの現場で使えるチケット駆動開発」セミナー

「チケット駆動開発の知っておくべき大切な事」(阪井)
2007年に開発現場で生まれたチケット駆動開発は、ITSのチケット(issue)を使ってタスクを管理するというシンプルさから広く普及しています。 ワークフロー管理も可能で、チケットには、計画、作業の状態、議論、関連チケット、構成管理との関連、ビルド結果など、開発に関連する多くの情報が集約さ れます。チケット駆動開発ではこれらの情報の共有と再利用が可能で、プロジェクトの諸問題を改善できます。
講演では、チケット駆動開発の概要と事例、そしてチケット駆動開発の考え方、勘所、注意点など、実施する際に知っておくべき大切な事を説明します。

チケット駆動開発はITSを選びません。それぞれのITSごとに長所・短所があり、現場の課題にあわせてうまく使うと良いと思い、講演させていただくことにしました。

この講演では、上に挙げた過去の組合せでも事例の追加でもなく、新たに全体を再構成するつもりです。これまでの簡単な背景ではなく、背景からしっかりとお話しするつもりです。

チケット駆動開発が生まれてきた時代背景を知ることで、どのようにバランスを取るべきかのヒントになると考えたからです。

  • 全体を大きなテーマで包み、それぞれをしっかり語る

そんな発表をしたいと思っています。

関東方面の方は、ぜひご参加ください(ご案内ページ)。

9月12日(木)午後にSRA関西事業部でプライベートショーを計画しています。阪井と@akipiiさんが講演します。関西の方は、こちらにご期待ください。



構造化された技術発表 - アカデミアとの壁・その3 -

少し間があきましたが、アカデミアとの壁(言葉の定義巨人の肩に乗る)の第3回です。

技術発表には、読み易いバランスの比率がある

さかば流・論文作法 その1 - 論文の構成 -でまとめた各項目は、おおよそ以下の比率で書いています。

  • タイトル・概要:5%
  • はじめに:10%
  • 関連研究:15%
  • 提案手法:20%
  • 評価(実験)方法・結果と考察:25%
  • おわりに:10%

論文10ページなら10%が1ページになります。 これは口頭発表でもあまり変わらず、 20分の発表でスライド20枚なら5%で1枚です。内容によって分類を変えたり、比率を変えるなどします。

言葉の定義をしてから使う

仕様書の用語集のような書き方ではなく、「はじめに」や「関連研究」の説明の中で、説明に必要な用語を文献からの引用と共に示します。

前提やコンテキストが不明な用語で議論すると、イメージする言葉の意味は百者百様になってしまい、話が通じなくなるからです。

インパクトは不要。先に答えと内容を言う

上述のような構造に分けて説明することが前提なので、インパクトのある写真を入れると構造を乱すかもしれません(技術発表はわかってもらうことが目的です)。

技術発表では、先に答えを示すことで論理的な構成をわかり易くします。円蔵さんの落語、刑事コロンボ、偉人伝、の様な構成と言えば良いでしょうか。驚かせるのではなく、「なるほど」と味あわせる構成です。

内容は一つに絞る

上に書いたように本筋の話は半分ほどの時間しかありません。何とか時間におさめるようとすると、内容は必然的に限定されます。

巨人の肩に乗ることで、オリジナルの所だけに集中して説明できます。この方法は合理的で、いわば技術の差分プログラミングのような表現法です。余分な事は言わず、言いたい事と言わないといけない事を切り分けて、必要なことだけを説明します。

その反面、関連研究まで知らないと理解が困難になります。畑違いの研究会では、聞く場合も苦痛ですし、話す場合も基本的な内容から説明しないといけません。このようにして、色々な研究会ができたのだと思います。技術者がわからないと思うのも無理はないのです。

おわりに

このような技術発表は、技術の前提(あるいはコンテキスト)と限界を示しつつ、有効性と信憑性を示します。その内容がぴったりと当てはまる範囲はそれほど広くなく、自分の役に立たないと感じる方もおられるでしょう。でも、それが積み上げ可能な技術だと思います。

勉強会の増加に伴って、技術の敷居を下げる発表や、新しいムーブメントを紹介する発表が増えてきました。それらは、技術者のコミュニティを作り、参考になる情報の共有を促進しています。しかし、情報共有でとどまっていたのでは、技術力は向上しません。

色々な人に響くモノがあるスライドは、参加者の満足度を高めます。サービス精神に敬服するものもありますが、発言に裏付けがない場合は安心して使えません。

また、これからは「XXだ!」とブームを作ろうとする発表は、モチベーションを高める効果があります。その一方で、発表が一面的であったなら、多くの失敗プロジェクトを生み出してしまうでしょう。

巷には言いっぱなしの発表が満ちあふれています。これだけでは、様々な方法論が生まれては消えていった1980年代のソフトウェア工学ブームの二の舞です。技術は積み上げ可能にしないといけないのです。

今やチェスやオセロなどボードゲームは計算機にとっては難しくない分野になりつつあるのかもしれません。しかし、総当たりの単純なアルゴリズムでは時間がかかりすぎることが知られるまでは難しい研究分野だったと思います。

それが今のように進化できたのは、(私には難しかった)計算量の研究によって限界が示されてアルゴリズムの研究が進んだからでしょう。技術の前提や限界を示すことで、他の人が適用分野を広げてくれるのです。

全ての技術者が必ずしもアカデミアを意識する必要はないと思いますし、高度で複雑な実践をしているのは技術者でしょう。しかし、技術者同士のコミュニケーションが仲間内でとどまって発展性が無いのなら、それは国家的、いや世界的な損失だと思います。けっして、大げさな話ではないと思います。

CCPMから考えるボスのあり方 - マイクロマネージメントより親分肌 -

リーダーに求められる大切な事 - 100人のプロが選んだソフトウェア開発の名著 -で紹介したハンフリー氏の「TSPガイドブック:リーダー編」は、上に立つ人(ボス)がどのようにすべきかという事がたくさん書かれています。

その内容を考えていると、CCPMとよく似ている事に気付きました。

ハンフリー氏は、「TSPガイドブック:リーダー編」でアイアコッカの言葉を引用して「ボスのスピードがチームのスピードだ」(p.9)と書かれています。これは、ボスがCCPMでいうクリティカルチェーンになり易いという事です。

このような場合、CCPMではリーソースの競合を解消します。ハンフリー氏の表現でなら、管理するのではなくリードしてメンバーの能力が発揮できる「自律的なチーム」を構築せよ。という意味だと思いました。

また、ハンフリー氏は「その最大限の能力を最大限発揮できるようメンバーを動機付け、コーチし、後押しする」と言われています。これは、CCPMのバッファコントロールにつながると思います。

上の人が細かく口を出して、マイクロマネージメントすると、それぞれの担当者は身を守ろうとしてバッファを持とうとします。それよりは、どっしりと構えて「責任は俺が取るから、任せたぞ!」と親分肌でいる方が良いということでしょう。

CCPMでは、各作業を理想見積もりで計画して、全体でバッファを取ります。つまり、親分肌の全体バッファはボスが持っておいて、メンバーは自律的に最善を尽くすことで、全体最適ができるのです。

さらに、ハンフリー氏は「チーム全体を巻き込み、チームを働きがいがある楽しいところに」と言われていますが、これはCCPMが、プロジェクトを見える化して、効率的にプロジェクトを運営することとつながるでしょう。

このようにハンフリー氏が考える上の人のあるべき姿と、CCPMにつながる点があるのは、共にサーバントリーダーシップを目指しているからだと思います。TOC/TOCfEの東さん(@oyukun)が、「ザ・ゴール」を読んでTOCに惹かれたというのは、このような事なのかと思いました。

私もいつか読んでみたいと思います。


[#TiDD] チケットが放置される理由

[#TiDD] チケット駆動による理想的なプロセス改善 #JaSST_Kansai」にいただいた、たなかさんのコメントで「チケットが放置」されるとのご相談がありましたので、放置される理由を整理しました。

チケット駆動開発の基本的な内容を書いた「チケット駆動開発の背景にある思い」「チケット駆動開発がもたらすプロセス」(ポイントプロセスの変化チケット管理形式化リズム現場力)」「チケット駆動開発の落とし穴 - ベカラズとベシ -」とあわせてお読みください

あいまい

  • 担当が設定されないチケット:起票された後、担当が決められないままに放置されているとクローズされなくなります。予めデフォルトの担当者を決める、棚卸しをする、等の運用ルールが必要です
  • Done(タスクのゴール)の定義がない:クローズする条件が明確でないとクローズされません。チケットのゴールを明確にし、複数の内容があれば分割しましょう。
  • ツールの導入が目的になっている:導入さえできれば良いと思い、使われなくなります。また、詳しい人がいない場合や、不親切な場合も活用の意欲が出ないでしょう。チケットシステムを導入する際は機能の比較だけでなく、詳しい人や情報にアクセスできるかどうかも検討してください。

面倒

  • 情報共有できていない:Wikiで情報共有する際に、初めに作ることが多いのはチケットシステムのTIPS(やや古い)や関連情報のリンクです。協力しながら面倒さへらしましょう。
  • 必要なカスタムクエリがない:よく使うカスタムクエリ(あるいはレポート)を準備しておくと、日常的な活動が大きく効率化できます。
  • 義務があっても効果がない:管理の都合だけで運用ルールを決めると、現場にとって面倒なだけです。管理情報は適切にフィードバックすると共に、実作業を効率化して現場力を向上しましょう。
  • チケットに依存していない:チケット駆動開発に心地よいリズムが生まれるのは、チケット中心にプロジェクトが回りだすからです。チケットがないとうまくまわらないと思えるほどに依存する事が、最初の一歩です。
  • チケットの粒度が大きい:依存を阻害する物に粒度の大きいチケットがあります。チケットを見なくても作業できるので、見る事が億劫になります。

運用の問題

  • 基本ルールがない、または不正:チケットの基本ルールを決めましょう。たとえば、担当がクローズするのか、依頼者が確認してクローズするのか、チケットの種類(トラッカー)ごとに決めると良いでしょう。
  • ワークフローが厳密過ぎてボトルネック発生:誰がチケットの状態を変更できるのかは、ワークフローで変更できます。しかし、あまり厳密に決めてしまうと、権限を持つ人がボトルネックになりがちです。なるべく柔軟に変更できるようにしておく、権限が必要なチケットの一覧を確認できるようにする、などの工夫をしましょう。
  • 棚卸しがない:チケットにうまく依存できていると、チケットの放置は少なくなりますが、人間ですからミスはつきものです。週に一度ぐらいは棚卸しをしましょう。

チケットの放置は、チケット駆動開発がうまくいっていないサインです。そのままにすると、そんなやり方でも良いのだと思ってしまい、改善する事はありません。

上に挙げたような適切な対応をとるだけでなく、賛同する仲間を増やす、不満点を拾い上げて対策をとるといった、プロセス改善活動としての視点(CMM/Iがいつか来た道)も必要です。

チケット駆動開発の本質は任せる(楽をする)ことです。タイミングを見極めて、プロジェクト改善仕組みを活かし、ちょうど良いプロジェクトを実現してください。

【告知】 2013/8/24(土)
GxP社「SIの現場で使えるチケット駆動開発」セミナー
「チケット駆動開発の知っておくべき大切な事」と題して講演させていただきます。チケット駆動開発の勘所などもお話しする予定です。


[#TiDD] チケット駆動による理想的なプロセス改善 #JaSST_Kansai

JaSST関西2013togetter私的まとめ)で基調講演と共に聞きたかったのは、 赤羽根さんの「ソフトウェアの品質向上に資する、開発・運用現場の情報管理」でした。

この発表では、システム障害と重大(サービス)停止に苦しむ現場にITS(Redmine)を導入して、7年間でシステム障害を1/10、重大停止を1/20にされた事例発表です。

プロセス改善の難しさ

90年代にCMMと共にプロセス改善はブームになりました。当時の反応は多様で、ソフトウェア工学の成果を能力成熟度の視点で体系的にまとめたという評価の一方で、「修身」だとの批判的な意見も聞かれました。

CMMに賛同する人の反応も色々で、中には変に利用されないようにと、進んで組織的なプロセス改善を推進するSEPG(software engineering process group)に志願された方もおられました。

SEPGが素晴らしい標準プロセスを作っても、現場がやらされ感を感じていい加減な開発をしていては改善は進みません。現場と組織が一緒になって積極的に改善を進めることが求められます(その方策として開催された社内ワークショップが評価され、SRAの発表が2003年のSEPG Japanで表彰されるなどしました)。

プロセス改善をどう考えるか?

CMMはDoDなどがカーネギーメロン大学と共に、高品質なソフトウェアを調達すべく考えられたソフトウェア開発組織の能力の成熟度を示す段階モデルで、「業者を識別するツール」です。

いわば認証のような物ですが、能力が成熟するとレベルが上がるので「達成」と呼ばれます。アセッサ(アプレイザ)の資格を持つ人に「ここまでできた様ですね」とお墨付きをもらいます。

つまり、発注側が「それぐらいはしておいてもらわないと」という組織のプロセスが実施されるようにする「底上げ」の仕組みです。実際に「レベル5でこの品質か」と当初言われていた海外の企業でも、何年後かに「レベル5だけのことはある」と言われるようになったと聞いた事があります。

しかし、これを「属人性を排除するツール」と考えてしまうと、結果を安定させる必要が生まれます。標準プロセスの置き換えは出来ても削減ができなくなって、標準プロセスはドンドン膨張して減らせなくなります。

重いプロセスは開発者の負担が大きく、開発者はやらされ感を感じてしまいます。するとプロセスモデルの持つ、伝達、教育、ディスカッション、改善といった特徴ではなく、まさに修身のような強制と重圧から、ごまかす事を考える様になってしまいます。

CMMの誕生の経緯のように、標準プロセスは底上げの道具して用いるべきだと思います。そうすると必須でないものも見えてきて、よりふさわしいプロセスが見えてくると思います。

赤羽根さんの事例

赤羽根さんの事例では、まずそこにシステム障害という課題がありました。毎日のようにトラブル対応に追われ、残業も多かったそうです。

その原因は年間3万件を超える多くの変更要求によるもので、コミットも年間2万回もあるそうです。それをエクセルで管理していたのでファイルを開くのに3分もかかっていた様です。赤羽根さんいわく「エクセル、素晴らしいですよ!」とのことなので、適材適所でなかったということでしょう。

このような背景から、管理しきれないバラバラの情報をRedmineのチケットでまとめて管理する事を考えられて、組織内に広げられました。

理想的なプロセス改善

赤羽根さんのIRedmine導入はプロセス改善としては、とても理想的です。

◎導入時にメリットを説明して合意を得ている

情報交換会でおうかがいしたところ、オフィス文書の更新差分が確認できるなど、現場の担当者にとって、理解しやすいメリットを説明されたそうです。わかりやすいメリットを説明して、改善に向けて前向きになってもらえたのはやらされ感がなく、とても理想的です。

CMMブームの頃、信頼性が上がれば、障害が減って、利益が増えて、給料も上がる、との説明を聞いた事があります。「情けは人の為ならず、巡り巡って我がのため」のような、わからなくはなくても、今ひとつ乗り切れないような、気がしました。

◎現場と組織にメリットがあった

直接的なメリットだけでなく、本来の目的である「障害と残業の削減」という現場と組織の共通のゴールが設定され、しかも、達成されました。現場のわがままでも、管理の都合でもないwin-winの改善です。

作業の効率化によって楽をする事は大切です。それと共に仕事ですので、会社に利益がないといけません。

◎結果を公開して次につなげている

改善の結果を数値にまとめて公開する事で、管理者と現場にフィードバックされています。改善の効果が見える事で、今後も継続できると思います。

進捗報告などで、たまにほめたり、支援するなど、作業の意義をさりげなく伝えることは、活動を維持する上で大切な事だと思います。

◎必要な規律を守っている

サブ・タイトルに「現場主導によるITS導入」とあるように、現場手動で改善を進められました。このような場合、組織内でバラバラになってしまいがちです。

しかし、管理者としてポイントを絞って、Redmineの環境を維持されました。カスタムフィールドはドンドン増えてしまい易いので、必要な物だけに制限されているそうです。全体をよりよい状態に保つ事は、組織的な活動として重要な事だと思います。

まとめ

組織的にプロセス改善を進める事は大切です。しかし、それが現場の負担になって、身動きが取れなくなるようでは問題です。改善の効果が得られないだけでなく、状況が不透明になるなど、様々な弊害を生むようになるでしょう。

赤羽根さんの事例は現場主導で底上げとして改善を進めつつも、組織として守るべき事は守るという理想的な改善活動でした。ITSおよびチケット駆動は現場にもメリットが多いので、よく考えて導入すれることで大きな効果が得られたのだと思います。

以上、期待を裏切らない講演で、充実した1日を過ごさせていただきました。

【告知1】 2013/8/24(土)
GxP社「SIの現場で使えるチケット駆動開発」セミナー
「チケット駆動開発の知っておくべき大切な事」と題して講演させていただきます。

【告知2】 2013/ 10/16(水)-10/18 (金) 
SPI Japan 2013 - ソフトウェアプロセス改善カンファレンス 2013 -
「チケット駆動開発によるプロセス改善 -現場重視、管理重視、それとも情報共有重視 - 」と題して事例発表させていただきます。


[#Agile] 組織的改善から現場改善へ #JaSST_Kansai

JaSST関西2013に参加しました(togetter(私的まとめ))。このところ考えていた事に、最もフィットしたのが細谷さんの基調セッション「実験的アプローチによる現場改善」です(資料はこちらで公開されています)。

組織的改善

従来の組織的なプロセス改善では、パイロットプロジェクトを実施して評価した上で、標準プロセスを変更して、組織全体を改善していました。

そこには、情報収集の開始から実プロジェクトへの適用までにかかる時間とコストが大きい、撤退の 選択をしずらくなる、という問題がありました。また、最初のパイロットで、未経験の手法を実践しながら自 分たちのコンテキストに合うように適用して、良い結 果を出さなければならない。という難しさもありました。

実験的アプローチによる現場改善

細谷さんの実験的現場改善のアプローチでは、以下の3つの原則を重視します。

  • 改善のスコープをきわめて小さくする
  • 実践の結果を素早く得る

  • 結果を評価して、(やめる事を含めて)軌道修正する

講演を聴いてイメージしたのは「リーンスタートアップ」です。リーンを考える - 無駄と必要なアソビ -に書いた必要なアソビを設けると共に、組織全体で行動するというムダをなくしているのだと思いました。

現場主義、実践主義、全体最適

この方法は3つの特長があると思いました。

一つ目は、従来の改善方法は組織の視点が中心でしたが、現場から改善を進めていく点です。これは「プロジェクト改善」やQCサークルにつながると思いました。

2つ目は、技術を知識としてだけでなく実践している事です。これはSECIモデル
で示されるように、形式知と暗黙知の両方が必要だという事だと思います。

最後は、全体主義でなく全体最適を目指している事です。従来の祖式的改善では管理の視点から見ると組織全体で共通のプロセスある事が望ましく、全体主義的な面があります。

しかし、部分最適である現場の改善を他のプロジェクトにすりあわせながら展開して組織の改善につなげます。これはて素早くムダなく改善する、いわば全体最適といえる方法だと思います。

このような方法が必要になってきたのは、従来の組織的改善法の前提が崩れたからだと思います。

前提の変化

従来の組織的改善法は、多くのソフトウェア開発は(少なくとも組織内では)共通部分が多いので標準プロセスを構築でき、プロジェクトによる違いは小規模なテーラリングでカバーできると考えられていました。

標準プロセスは、以下の考え方がベースにあります。

  • 標準プロセスは安定しているので、 訓練の繰り返しによる長期的な改善活動が可能
  • 収益を低下させるのは、ソフトウェアの品質(信頼性)低下による手戻り工数増加
  • ソフトウェアの信頼性を低下させる最も大きな問題は、必要な作業を実施しない(ショートカットする)こと

しかし、この前提は以下のように変化しました。

  • パラダイムシフトによって多様性が増加した
  • ビジネスのスピードアップによってソフトウェアの信頼性よりも適時性が求収益向上につながるようになった
  • 繰り返し開発、テスト駆動開発や自動化など、逐次的に信頼性を向上させる事で、信頼性低下に伴うビッグバンを押さられるようになった

まとめ

上で述べたように、細谷さんの方法は現場主義、実践主義、全体最適という特長があると思います。そのうち全体最適は、リーンスタートアップを思い浮かべさせるものでした。

20世紀末から「いかに抜けなく作業するか」という視点の改善が続きました。そろそろ「いかにムダなく成長させるか」という視点で、改善活動を見直す時期になっているのではないかと思いました。


[#Agile] アジャイル開発の課題と対策 その3 - チケットコミュニケーション - #TiDD

全てのことを全員が熟知する事は、規模が大きくなると難しくなります。10人、100人、1000人、あるいはやや多い人数で、組織の壁があると思います。専門性の度合いによっては、より小規模なところに組織規模の壁があります。

組織を分けざるを得ない場合、アナログ媒体でもうまく開発を進める事ができます。しかし、専門性が高くなればなるほど、チケットシステムが有効に活用できます。

この記事ではアナログ媒体のスケール方法とその限界をしめします。そして、チケットシステムでのコミュニケーションと運用のポイントを説明します。

アナログ媒体でのスケール方法

アジャイル開発では多能工が良いとされていますが、専門性が高い場合は、多能工を維持する事が難しくなります。「その2」で書いたようにチームをある程度担当ごとに分けざるを得ない場合、そのコミュニケーションの方法によって、プロジェクトの成否が分かれます。

タスクボードやカンバンなど、アナログの媒体を使ってもスケールは可能です。田口さんの事例のように複数チームのボードを近くに並べれば、他チームの情報が入手できるようにできます。また、ボードや朝会を階層的にして、スクラム・オブ・スクラムのように全体を構成する事もできます。ストーリーカードやタスクカードの情報量が少なければ、 カードの色やシールなどで補う事が可能です。

アナログ媒体の限界とチケットシステムの利点

しかし、アナログ媒体での情報交換には限界もあります。

  • 外部との会議に参加する人の能力でチームの情報量が制約される
  • 専門性が高くても担当者同士で情報交換されると、情報が隠蔽される
  • 過去の情報の検索が困難で、経緯がわかりにくい

このような懸念がある場合、以下のような特徴を持つチケットシステムを中心としたコミュニケーションを検討すべきだと思います。

  • 電子化された情報なので、いつでも誰でも見る事ができる
  • 専門的な議論が隠蔽されないように管理と公開が可能
  • 様々な情報を関連づける事が可能で、検索も容易

運用のポイント

(1) 情報インデックスの一元化
 全てをチケットにするのではなく、チケットシステムから情報を辿れるようにします。チケットに限定せずに多様なコミュニケーションを必要に応じて活用しましょう。メールはチケットに内容をコピーしておき、電話は要点をチケットにまとめておきます。

(2) 形式知と暗黙知のバランス
 「[#TiDD] SECIモデルから朝会という「場」を考える - 平鍋さん@SEA関西 -」に書いたように形式知だけでなく、暗黙知も活用します。アナログコミュニケーションは情報量が多いですが、スケールが困難です。逆に形式知は規模の拡大には強いですが、情報量は限定的です。チケット(形式知)を活かして情報交換を効率化しつつ、微妙な情報を失わないように、打ち合わせや電話などの様々な方法を活用します。

(3) 紙おむつ的防護
 紙おむつというのは、中身は守って湿気(情報)は外へ出します。特定の担当者をインタフェースにする事は、自己組織化に向けたチームの防護壁としては効果的ですが、情報のボトルネックを生む可能性があります。チケットなら承認の必要なものは厳密なワークフローで管理できますし、担当者間の詳細な情報交換も他のメンバーや外部から見える状態で情報交換できます。

まとめ

ソフトウェア開発は、特定の方法に限定されるものではありません。それぞれの方法には向き不向きがあり、開発対象やチームの経験なども考慮して、様々な工夫が必要です。

アジャイル開発やDOA、もちろんチケット駆動開発も同じです。「いける!」という感触と迷惑をかけない自信があるならばそれで進めれば良いでしょう。しかし、少しでも不安を感じるならば、何らかの方法で補わなう必要があります。

ここまで書いてきた事は、特定の前提でのみ成り立つ事です。現実はここに書いたほど単純ではなく、さらに複雑です。プロセスをプログラミングするときアジャイル開発と同じです。常に全体のゴールを意識しつつ、緻密に考え、必要な時は素早くやり方を変更する必要があるでしょう。

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


« 2013年7月 | トップページ | 2013年9月 »