無料ブログはココログ

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

[#47Redmine]ユーザコミュニティが盛り上がってきた - 第5回 品川Redmine -

品川Redmine 第5回勉強会で基調講演をさせていただきました(つぶやきのまとめ:togetter@akipiiさんの感想)。

講演は「チケットシステムの可能性 - 開発から業務まで -」と言うタイトルで、チケットシステムの可能性をメタに説明した後に、社内の業務改善例を紹介しました。

業務系の若い方達はモジュール間結合度を知らなくとも、オブジェクト指向なので引数をきちんと使われると思います。しかし、組み込み系だと諸般の事情で外部変数を使う事もあるので、身近に感じられた方もおられたかと思います。業務形の方は年配の上司の方への説明などの参考にしていただければと思います。

社内業務の例はエクセルシートをメールで配って行っているPCの資産管理業務をRedmineで行いつつある例で、200回繰り返していた庶務の方の作業をそれぞれ1回ずつに改善した例です。

勉強会はワークショップが中心でしたが、LTの「Yggdrasil(ゆぐどらしる) ~ サーバ運用のNo Ticket, No Work ~」が興味深かったので紹介しておきます。Yggdrasilは運用管理の構成管理ツールとでもいうべきです。チケットと構成管理を関連づけている点など興味深く聞かせていただきました。

今回、初めて参加させていただいて驚いたのは、皆さんがRedmineのユーザである事です。ワークショップの議論も、それぞれの会社の様子やRedmineの運用方法など、お互いの具体的なノウハウや悩み事を共有する事ができました。

大阪のRxTstudyもRedmineの勉強会ですが、Redmineとタスクマネジメントの勉強会なので、Redmine以外のユーザーの方も含まれていますが、品川はRedmineが標準のユーザコミュニティの様に感じました。

同じような環境は学会の研究会でもあって、ソフトウェア工学研究会から独立していった人工知能やオブジェクト指向の研究会などが同じような感じなのではないかと思います。

これらの研究をされている方は、ソフトウェア工学研究会でも発表されますが、その時は基礎的な専門用語から説明されると思います。しかし、それぞれの専門家ばかりの研究会なら、基本的な説明も程々により深い議論をされるでしょう。

そのような深い議論が品川では本編の勉強会の初めから行われました。もちろん、RxTstudyでも深い話もありますし、2次会になると負けていない議論もしています。でも、それが品川ではほぼ全員なのです。今回はテーマ設定の影響か、どちらかというとRxTstudyが開発者が多い感じで、品川は運用者が多い感じがしました。

今回、品川Redmineに参加させていただいて、興味深いお話をたくさん聞く事ができました。そして「いよいよRedmineが本格普及を始めた!」と思いました。


自転車の教え方 - トレーニングのあり方の考察 -

以前「[#TiDD] SECIモデルから朝会という「場」を考える - 平鍋さん@SEA関西 -」にも書きましたが、自転車の教え方は形式知が先にあるべきと思っています。

通常の方法

通常は暗黙知を経験を通じて教える方法がとられます。自転車の後ろを押さえて一緒に走ってあげて、慣れてきたらそっと手を離すという方法です。これは親子関係を良好にするかもしれませんが、あまり効率的とは言えないと思います。

このバリエーションとして、半日で乗れる様にする方法があるそうです。それは、ヘルメットや膝当て、肘当てなどのプロテクターをつけて、けがをしない様にすれば、怖がらなくて済むのですぐに乗れるという方法だそうです。

さて、自転車を乗る際に覚えることは何でしょうか?自転車の乗り方もちろんですが、上のような方法ではそれ以外にも覚えてしまわないでしょうか?

親の愛情と共に、親はけがをしない様に用意してくれる事、理屈がわからなくて怖い時はガードする事、とにかく経験する事が大切という事、でしょうか?

形式知を活かす方法

さて、もっと早く乗れる方法をお教えしましょう。それは、自転車を乗る際に必要な二つの事を教えるという方法です。

  • ペダルを漕げばこけない
  • ブレーキをにぎれば自転車は止まる

この二つを実践すれば、自転車はすぐに乗れます(直進だけですが、、)。自転車を立てて、初めだけ持って「思いっきりペダルを漕げ!」とさけびます。

仕事が忙しくてなかなか遊んでやれない時に考えた方法ですが、あっという間に乗れました(直進だけですが、、)。

この方法は、いくつかの特徴があります。

  • 自分でできる事
  • 押さえてもらったり、ガードをしないで、いきなり本物に乗っている
  • 原理を知ることで、世の中が変わる事

この方法の背景にある考え方を説明します。

Toy programとThesis ware、あるいは、in vivo

大学におけるソフトウェア工学実験を表現する言葉には、色々あります。

Toy program というのは、実社会のソフトウェアの規模に比べて非常に小規模である事を示しています。小規模なプログラムにおける問題は大規模なプログラムで発生する問題と異なると言う批判です。

Thesis ware というのは、学位を取るためのソフトウェアと言う事です。素晴らしいソフトウェアを開発したという論文を書いて入るものの、バグだらけで使い物にならない、一般利用に耐えない限定された条件でないと動作しない、そもそも公開されない、といった批判です。

批判ではなく、特性を表す言葉として、試験管の中のと言う意味の in vivo があります。これは、本来の場所を示す in situ と対比して述べられます。試験管内ではノイズ(外乱)が少ないので、特定のパラメータだけを変更してその違いを明確にしやすいと言う長所があります。その反面、複数の要素が絡み合う、現実的な実験結果とは異なる可能性があります。

医学の世界

このように得た理論を医学の世界ではどのように使うのでしょうか?以前、聞いたお話では、理論的な学習だけでは教えられない暗黙知にあたる部分の教育法が色々工夫されている様です。

医学の世界も、かつては徒弟制度のように先輩の大先生が背中を見せて後進を育てていた様ですが、それではなかなか育たない事や初めて本物の患者を相手にする時のリスクが高い事から、本物に近いロボットを使う、ロールプレイする、ビデオなどの教材を使うということが行われています。

テレビで心臓マッサージのロボットを見られた方も多いと思います。心臓マッサージでは人工呼吸とマッサージの組み合わせのタイミングや力の入れ具合など、特定の動作をトレーニングするロボットがあり、うまくやらないと回復が遅れたり、死んでしまうことがシミュレーションされます。

心臓マッサージの様に同じ状態を作り出す事が困難で、失敗すると命に関わるようなことであれば、理論的な知識を予め与えた上で本物に近い経験で補うことで、本番に向けたトレーニングが行われます。

緊急医療ではチーム活動が重要だそうです。海外ドラマのERなどの緊急医療を扱うドラマでもその一部が垣間見れますが、患者を運ぶ時や手術の際の立ち位置と役目は、あらかじめ決まっているそうです。

たしかに、患者に声をかける役や脈を測る役、服装を切り裂く役、などかなり手慣れた感じに見えます。これは、それぞれの役が決まっていて、どのような時に誰が何をするかが明確で、何度も練習しているからこそできるプロの技です。しかも技術は進歩しますから、外で実習を受けた人はそれを院内で同じ様に広めて技術レベルを維持しているそうです。

そして、様々なトレーニングは知識学習とセットになっています。教科書的な学習だけでなく、まるでERのようなビデオを見ながら、それぞれの担当者の問題点などを説明して知識を得ていきます。

体系的な知識の必要性

上に書いた内容は、OJTは人体実験 - 池上先生@SS2008 - に書いた講演を思い出しながら書きました。この記事はOJTでなくきちんとトレーニングしましょうという講演の主旨にそった感想を書いています。しかし、最近はその前にすべき事があるのではないかと思っています。

それは、知識の体系化です。医学の世界では、それまでにわかっている知識を体系づけて理論的に説明され、教育されている事が前提です。その上で、実践が必要な所に関してはOJTではなくOff-JT(Off the Job Training)でしましょうと言う主張なのです。

形式知として整理すべき所は整理して、暗黙知でないと得られない所はより現実的に近いトレーニングをすると言う事が必要だと思います。しかし、ソフトウェアの世界は技術の変化が激しく、現実的なトレーニング教材を作ってもすぐに陳腐化してしまいます。そこでOff-JTでは、どうしても基本的なトレーニングが中心になります。それが有効なのは初心者だけですので、OJTを減らすことを目指すなら形式知の教育が中心にならざるを得ないでしょう。

それを補うのは経験者の知識とフォローだと思います。私が勉強会という場アジャイルラジオに大きな価値を感じるのは、そのような背景からかも知れません。

まとめ

さて、みなさんは技術者はどのように勉強すべきだと思われますか?あるいは、自転車はどのように教えるべきと考えられるでしょうか?とにかく自転車に乗せて支えてやりますか?それともプロテクターを着けてけがをしない様にますか?

私なら、必要な理論に基づく知識を与えて、思い切ってペダルを漕いて、理論の実践に集中する様に教えます。もちろん、なるべく大きなけがをしない様に土のある公園で、外に飛び出さない様に見守ることは忘れません。

[#agileradio] アジャイルラジオはメディアミックスの力を持つ!

以前、出演させていただいたアジャイルラジオは、アジャイル専門(たまに違う!?)のPodcastしている放送局で、ラジオとしての特徴、コミュニティとしての特徴と、メディアミックスとしての特徴、があります。

ラジオとしての特徴

関西人の私にとって、良く知っている人たちの会話ですが、なぜが聞き入ってしまいます。もちろん話の内容は打ち合わせされていて、その後のお話なので聞きやすいと言うのはあると思うのですが、顔が見えないからか声から表情をイメージしようとするようです。

また、いかにもラジオ的な構成も秀逸です。毎週水曜に更新される30分番組の中に、オープニングとエンディング、CMなど、集中力が切れないような構成が、聞きやすくしていると思います。

ラジオという媒体は音声というアナログの媒体で文字では表現できない多くの情報が提供されます。インフォーマルな会話によって、飲み屋で離しているような深みのある内容が伝わります。アナログの特徴である豊富な情報によって、SECIモデルの暗黙知の共同化にも役立っていると思います。

コミュニティの特徴

最近のラジオらしく、Twitterを活用しています(ハッシュタグは#agileradio)。公式アカウントや中の人が広報に利用しているほか、聴取者のコメントもTwitterで集められています。番組の収録前にはTwitterがチェックされていて、つぶやかれた意見や感想を番組内で紹介されています。

また、最近のマスコミの様に、ラジオ以外での活動もされています。XP祭り関西ではコーナーを作られていましたし、ET-WESTではUstreamで動画配信するなど、ラジオを中心としたコミュニティを形成されています。

メディアミックス

Twitterの利用はラジオから見るとメディアミックスですが、アジャイル開発という大きなコミュニティから見るとアジャイルラジオがメディアミックスの媒体となっています。

ラジオは書籍やネットワークなど同じ様に言語情報ですので、抑揚などの情報はあるものの形式知とも考えられます。形式知はデジタル情報ですから標本化定理(wikipedia)に従います。

標本化定理ではそのサンプリング周波数によって、表現できる情報量はきまります。しかし、それは昔のボーレートと言っていた時代の話で、複数の次元を用いれば大量の情報を通信できます(昔でいうとトレイルブレーザーの様に、って若い人は知りませんよね)。

メディアミックスは、特定のメディアだけでは伝えきれないものを、別のメディアによって多次元的な広がりを持たせてくれるものです。アジャイル開発の新しい媒体としてラジオが増える事で、今後のアジャイル関連技術はもっとひろがると期待しています。

[#TiDD] チケット駆動開発の「ライトウィング」と「レフトウィング」

チケット駆動開発で考慮すべきバランスと視点を書きましたが、実際に進める場合には2つの戦略を意識すると良いと思います(平鍋さんのアジャイルの「ライトウィング」と「レフトウィング」(An Agile Way)を参考にまとめてみました)。

Tidd_left_right_2


チケット駆動開発ではプロジェクトの透明化を高めて、業務を効率化し、顧客の満足とチームの仕事への満足感を得る事が目的と考えています。しかし、現状から一気に完成されたプロセスに移行できませんので、いわゆる「巨人の肩に乗る」事が必要です。

チケット駆動開発の巨人は2人います。一人はツールの設計思想で、もう一つは社内文化です。

ライトウィング(設計思想に乗る)

ツールによる自動化などで環境を整えて業務を効率化する「ライトウィング」では、ツールを導入する事でツールの背景にある設計思想を実現します。

No Ticket, No Commit!は、チケットのないコミット(構成管理上の更新)は禁止するというチケット駆動開発のプラクティスです。導入によってチケットに全ての情報を紐づけるという文化ができていきます。

継続的統合・テストを行えば、常に動作可能なコードが維持され、その動作が保証される様になります。テストコードを常に書く文化が根付きますし、 継続的デリバリー も導入すれば「現地・現物」が実現されます。

継続的統合ツールやチケットの情報を利用してメトリクスの収集をすれば、定量的なデータが常に得られる様になり、リファクタリングする際の参考情報や、プロジェクトの異常な状態の検出にも役立つでしょう。

レフトウィング(社内文化に乗る)

一方、人が能力を最大限に発揮できる様にチーム作りをするのが、ライトウィングです。現状の社内文化を見極めて、少しずつモグラたたきをしていきます。

チケット駆動開発によって自主的なコミュニケーションが支援される様になると、トップダウンな管理をやめてサーバントリーダーシップを発揮すれば、自律的組織を目指せます。近年のソフトウェア開発では、すでに一人で全ての技術要素の詳細を把握する事は困難ですので、チーム内の気付きや懸念、アイデアを共有して、チームで挑戦しなければいけません。

また、アジャイル開発のタイムボックス管理によるスコープの変更や、TOCのCCPM(CCPMのグッときた話 - TOC/TOCfE関西分科会 -) におけるバッファ管理など、これまでのプロジェクトの管理方法を変更する場合も、現状の文化を考慮した上で、何を固定して何を変化させるかを明確にした上で、新しい方法を導入しないといけないでしょう。

このほか、顧客と同じ方向を向くことも大切です。要望を満たせば納期が遅れても良いと誤解したり、形だけの営業トークだけでは意味がありません。お互いの業務と利益構造を理解した上で、提案し、助け合えるような関係は、単純にチケットのやり取りだけでは構築できません。互いの担当者の個性や契約上の利益相反もありますので、互いを認め合う事から時間をかけてはじめないといけないでしょう。

ツール導入

ライトウィング・レフトウィングに関わらず、これらの大元になるのはツールの導入です。チケットシステムで何ができるか、どのように運用するかをイメージできなければ、チケット駆動によるプロセス改善は始まりません。

まずは、障害管理から初め、備忘録的なタスク管理をし、必要に応じて進捗なども管理すると良いでしょう。

さらに、wikiなどを含め、チケットシステムをコミュニケーションの基盤として使い、社内のワークフローを見直すと、チケット駆動開発の可能性も徐々に見えてくるでしょう。

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

【告知】大阪/東京のRedmineの勉強会

6/22 第8回RxTstudy Redmineやタスク管理を考える勉強会@大阪

6/29 第5回 shinagawa.redmine勉強会

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


[#TiDD] チケット駆動開発で考慮すべきバランスと視点

RedmineやTracなど、チケットシステムを導入して、プロセスを改善する際にはバランスと改善の視点が重要です。チケットシステムは様々な利用方法がありますので、思いつきで導入すると特定の問題は解決できても、使いづらいものになるからです。

1. バランス

バランスを取るべきものには以下の3つがあります。

  • パラダイムシフト・効率化
  • 暗黙知・形式知
  • ツールによる自動化・ 人中心の支援

これらを順に説明しましょう。

1.1 パラダイムシフト・効率化

改善の方法にはto beからはじめる方法と、as isからはじめる方法があります。to beとはあるべき姿のことで、理想に向けて大きく舵を取る方法です。as isとはありのままの姿のことで、現状をモデル化してそこに現れる問題点を解決していく方法です。完全型チケット駆動開発はto be、 アダプタブル・ウォーターフォールなどの補完型チケット駆動開発はas isと言えるでしょう。

改善する際に大切なのは、それが パラダイムシフトなのか、効率化であるかを考える事です。パラダイムシフトとは考え方を大きく変えるもので、一つずつでないと実施できません。一方の効率化は作業者の負担を減らす目的で行うものですので、全体の一貫性や連携が考慮されていれば、複数の改善も可能です。

ここで気をつけないといけないのは、完全型であっても複数の効率化ができますが、補完型であったとしてもそれがパラダイムシフトであれば一つ一つ導入しなければいけないと言う事です。たとえば、サーバントリーダーシップを実践して自律的な組織を実現して、難局を乗り切る事が目標なら、それだけに集中してパラダイムシフトを成功させないといけません。成功しなければ改善ではありませんし、成功体験がなければ組織は変われません。

1.2 暗黙知・形式知

チケットは文字や関連で表されたものですので、形式知です。暗黙知の交換(共同化)をどのように補ってバランスを取るかを考えないといけません。

アジャイル開発でタスクボードなどの貼りものを用いる場合は、貼りものの前での雑談やペアプログラミングなど、暗黙知を交換する場がありますので、朝会や振り返りなど、形式知に(表出化)する場を用意して、暗黙知と形式知のバランスを取る必要があります。

これに対して、チケット駆動開発では形式知を扱いますので、暗黙知を交換する場を積極的に作って、暗黙知と形式知のバランスを取らないといけません。一般に朝会では、実績、予定、課題を話し、課題には深入りせず、全体を15分以内で終える様にすべきだと言われます。しかし、チケット駆動開発ではすでに形式知(チケット)化された進捗の確認を中心にするのではなく、これからの見込みの共有や、 課題に対する共通認識を持つ様にするなど、うまく形式知化されていない知識(暗黙知)を引き出す様にした方が良いでしょう。

1.3 ツールによる自動化・ 人中心の支援

アジャイルの「ライトウィング」と「レフトウィング」(An Agile Way)と呼ばれている考え方のバランスを取ります。ツールによる自動化などで環境を整えて業務を効率化する「ライトウィング」は、ついついツール中心の発想になりがちで、手段と目的が入れ替わる事も多い様です。トヨタ生産方式(TPS)では、自働化と呼んで、異常が生じた際には人間がラインを止められる仕組みが入れられていました。プロセス改善においても、おかしいと感じた場合はその流れを止められないといけないと思います。

一方、「レフトウィング」のように人が能力を最大限に発揮できる様にチーム作りをすると、ツールを使えば簡潔な環境が容易に実現できる場合でも、必要以上に作業時間を使ってしまう可能性があります。改善はトータルで人が楽になる事が目標です。人が高度な仕事をって能力を発揮できるにはどの様にすれば良いか、ムダな単純作業や間違えやすい複雑な作業を見極めてバランスよく自動化しないといけないでしょう。

2. 視点

チケット駆動で業務を改善する場合に、必要な視点には以下の3つがあります。

  • 平準化とリズム
  • 能力発揮:負担軽減・情報共有
  • ジャストインタイム

これらは1のバランスを考える際の優先順位や、問題を見つけ出す際にも役立つでしょう。

2.1 平準化とリズム

平準化とは、負荷の大きな作業を見つけて改善します。一時的に増える作業を減らせば、ムダな配員が要らなくなり、 効率的な情報共有がおこなえるようになります。

また、安定した作業の繰り返しは作業のリズムを生みますので、習熟や効率が向上します。また、繰り返し可能なプロセスは改善が容易になります。

チケット駆動開発は、朝会で課題の議論も行う事が多いので、ふりかえりの効果が得られます。タイムボックス管理でない場合でも、改善のタイミングになりえるのです。

2.2 能力発揮

改善が能力の発揮につながるかどうかの視点です。負担の軽減して、より高度な作業にあたれる様にします。たとえば、間違えやすい作業に権限やワークフローによる制約を与えて、信頼性を高めたり、安心感を得ます。また、チケットや履歴を用いて、時間を超えた情報共有や助け合いを支援などもこれにあたります。

この際に忘れていけないのは、完璧を目指すのではなく、ムダを生まないことです。信頼性を高めようと確認のステータスをむやみに増やすと、作業にボトルネックが生じます。負担にならない程度の運用で実現できる事を、厳密なワークフローで実現する事は、ムダな場合が多いでしょう。

2.3 ジャストインタイム

リアルタイムなだけではありませんし、インタイムでもありません。

情報は、必要な時になければいけませんが、不要な時にあってもいけません。情報があると管理対象が増えますので、レポートで一覧する際にムダな作業が生じます。

必要な情報はリアルタイムに参照でき、不要な場合には参照しなくて良い仕組みを目指す視点が必要になります。

3.【告知】東京と大阪のRedmineの勉強会

ここにあげた内容と社内業務の事例を 6/29 のshinagawa.redmineで基調講演する予定です。関西の方はRxTstudyに参加します。ぜひ、勉強会でお会いしましょう。

3.1 shinagawa.redmine勉強会(6/29)

第5回 shinagawa.redmine勉強会
フリーのプロジェクト管理ツール Redmine について語り合いましょう!

3.2 第8回RxTstudy(6/22)

第8回RxTstudy
Redmineやタスク管理を考える勉強会@大阪


[#TiDD] SECIモデルから朝会という「場」を考える - 平鍋さん@SEA関西 -

以前ご紹介した平鍋さんと野中先生の書籍「アジャイル開発とスクラム」は私のお気に入りの1冊です。アジャイル開発とはどのようなものであるかだけでなく、モノ作りはどうあるべきか、人が知的な存在として関わるにはどうすれば良いかが書かれているからです。

アジャイルスクラムが完成する際に必要だった最後のパーツが野中先生の実践知とSECIモデルです。今回のSEA関西プロセス分科会での講演は「アジャイル開発とスクラム」の内容ということでざっくりとお願いしました。そして、お話の中心は実践知とSECIモデルで、この本でとても大切な内容の一つだと思いました。

アジャイル開発(というかXP)が日本に入って来た時、その背景にある「なにか」に気づいて、我々は興奮しました。その「なにか」は、人が知恵を出し合い、助け合い、より良いモノ作りを目指す事だったのかもしれません。

SECIモデル

書籍に載っているSECIモデル(情報システム用語事典)では、暗黙知と形式知の間で行われる以下の4つの変換の繰り返しからなる知識想像活動のモデルです。

  • 共同化(暗黙知→暗黙知):言葉になっていない知識や感情を体験によって共有します
  • 表出化(暗黙知→形式知):暗黙知を図や文書によって伝達が容易な形式知に変換します
  • 連結化(形式知→形式知):形式知の組み合わせや編集によって体系化し新しい知識を生み出します
  • 内面化( 形式知→暗黙知):実践を通じて体で理解学習していく

理論だけでも、実践するだけでもだめで、SECIモデルの繰り返しによって、イノベーションが生まれます。

このモデルはスクラムに組み込まれている大切なポイントなのですが、内容を理解できても腑に落ちるというか、応用が利く所までは言っていませんでした。しかし、今回の講演を聴いて、ようやくわかったように思いました。

SECIモデルの私的解説

この「わかる」とは、以前「できる人を観察して勝負する」に書いた知識が整理された状態です。自分なりに説明できるほどに整理できましたので、私なりにまとめておきます。

共同化(暗黙知→暗黙知)の経験

私が新人の頃の最初の仕事で用いた環境は、OSのバージョンが1に満たない不安定なものでした。プログラムを書き終えたものの、どうしてもコンパイルできない部分がありました。何度見直してもうまくいかず、上司に「動きません」と言いました。すると、上司がペアプロのように横について原因追及を手伝ってくれました。

「馬鹿者!少しずつ確認して、どこが原因か突き止めろ!」と言えば良いだけの状況でしたが、新人であったからか作業の仕方をナビゲートしてくれたのです。まずは、全体をコメントアウトしてコンパイル。次に上半分をコメントアウトしてコンパイル、、とバイナリサーチの要領で部分を特定していきました。原因の場所を突き止めれば、書き方を工夫するだけでした。

この経験で私は多くの事を学びました。仕事はあきらめては行けない事、頑張れば原因は突き止められる事、知識を応用して作業は工夫できる事、原因が分かれば問題解決につながること、、。

実際のところ、上司がたまたま暇だったからか、面白そうだから一緒にやってみたかっただけなのかもしれません。しかし、同じ場所で体験を共有する事で暗黙知が得られたのです

表出化( 暗黙知→形式知)

平鍋さんの講演で印象深かったお話の一つがPanasonicのホームベーカリーの話です。機械を作ったもののパンをこねてもうまくいかず、大阪の国際ホテルに弟子入りして暗黙知を取得し、そこで得たヒントを実践し、試作を繰り返して形式知を得て、製品化したそうです。

ここで、思い出されるのは、エンピリカルソフトウェア工学のコースで「エンピリカルソフトウェア工学において観察は基本だが、鳥をいくら観察しても空は飛べない」と教わったことです。そういえば飛行機の歴史は、鳥人間コンテストのような真似事からはじまり、様々な模型を作り、理論的基礎を整えて、さらに試作を繰り返して飛行機ができました。

このようにして「実践知(後述)からイノベーションが生まれる」のだと思いました。

連結化(形式知→形式知)

チケット駆動開発で用いるチケットは「形式知」です。それらは単独で存在するのではなく、構成管理と紐づいたり、作業間で関連や順序があり、個人や優先順位、全体のロードマップといった様々な視点で確認する事で、やるべき事を見出します。

ビジネスの世界では様々なデータマイニングによって進むべき道を探ります。ソフトウェア開発において、開発に関連するデータをリポジトリから抽出しマイニングすることが、チケット駆動開発の一つの方向だと思っています(プロセスモデリングにおけるチケット駆動開発の可能性Jenkinsの特長 - メトリクス収集サーバの視点から -)。

内面化( 形式知→暗黙知)

講演では自転車の乗り方について、 共同化(暗黙知→暗黙知)の文脈で出てきました。まずは自転車を支えてあげて、慣れてきたら黙って手を離すというやり方です。多くの方が、この方法で教えられていると思います。

私が長男に教えた時は、ペダルを漕げば(車輪が回り)自転車は倒れないという形式知を実践させる方法です。自転車に慣れる必要はありません。後ろを押さえておいて「漕げ!」といってすぐに離す、というのを繰り返しました。

子供にすれば「怖いから押さえて欲しい」と思ったかもしれませんが、伝えたいのは「慣れ」ではなく「漕げは倒れない」なので思いっきり漕ぐ事だけを指導しました。なれるまで直進しかできませんでしたが、すぐに乗れる様になりました。

実践知(フロネシス)

実践知は「目に見える事象と、その背後にある関係性までを読み、その場で適切な判断を下し実行する」もので、実践知を持ったリーダーが実践知リーダーです。

この実践知リーダーに求められる事の一つが「『場』をタイムリーに作る能力」です。

知識を創造し、それを共有、成長させるための「場」

このブログでも「技術者には「場」が必要」と書いていましたが、ここでいう「場」とは、知識を流通させる時空間です(場[Ba]というのは、米国ではFieldになるがそれでは意味が通じない。英国ではBarになると説明すると笑いが取れて意味が通じるそうです)。

この「場」で思い出すのは、「先駆者の集まりから、プロセス・チャンピオンの集まりに - XP祭り関西2012 -」で書いた田口さんの「壁」です。壁にタスクボードを並べることで、チーム間のコミュニケーションの「場」ができたというお話です。まさに実践知リーダーですね。

チケット駆動開発で朝会に求めるもの

「朝会」ですることについては、以前からアナログ派の方と意見が合いませんでした。わたしは進捗と課題だけでなく質問や簡単な課題の解決の場にしても良いと思っているのに対して、みなさん進捗と課題のみで15分を守れと言われます。これが、いくら聞いても納得できないのです。

SECIのお話を聞いてこの理由がわかった様に思います。結論を書くと

  • アナログアジャイルでは暗黙知を中心にプロジェクトが進むので、朝会を個人の予定を形式知にする「場」にしてバランスを取っている
  • チケット駆動開発では形式知であるチケットを中心にプロジェクトを回すので、朝会を暗黙知を共有するための「場」 として利用している

という違いがあると思いました。

アナログアジャイルにおいて、タスクボードに貼るタスクカードに担当者の名前やマークがつけられる事も多いでしょうけど、個人の作業単位でタスクボードを見る事は困難です。そこで、朝会で確認する事で、チーム全体の状況を見える化しているのでしょう。

一方のチケット駆動開発では、チケットに形式知化された情報があり、個人の予定は簡単に確認できます。朝会で進捗だけを確認していたのでは、新たな情報がほとんど得られません。そこで、朝会は自然と課題中心の報告になり、細かな課題の解決とノウハウの情報共有の場になります。

チケット駆動開発では形式化された情報が中心になりますので、形式化されにくい情報をいかに拾い上げるかがポイントになります。そのためには、サーバントリーダーシップ(アジャイル開発への壁は価値観の壁)を心がけ、開発者の能力を最大限に発揮できる様にします。そして、拾いにくいものが形式知として蓄積できたとき、チケット駆動開発が挑戦の道具として大きな成果を出すのだと思います。


勉強会のバリエーションで考える社内勉強会の難しさ

社内勉強会が難しい理由は色々あると思いますが、長く続かない理由の一つはバリエーションが少ない事だと思います。私の知る範囲で社外の勉強会をざっくり分けると以下の様になります(かなり主観的です)。

総合型、ジャンル型

どのような勉強会も、そのコミュニティの興味の持つ範囲で様々な内容をしています。しかし興味の範囲の幅によって、比較的広く色々なジャンルの内容をする総合的なものから、特定の狭いジャンルの勉強会があります(総合的かどうかは比較の問題ですので、知っている勉強会によって分類が異なるでしょう)。

研究会、講演、ワークショップ、ハッカソン、ハンズオン、読書会、ワールドカフェ

開催の形式によって比較的アカデミックな研究会、第一人者による講演、やってみました的な経験談の講演、グループディスカッションや何らかの作業などを伴うワークショップ、などがあります。

ワークショップにあたるものの中でも、特定の作業を強調した勉強会もあります。プログラミング中心のハッカソン(ハッキングとマラソンの合成語)、体験学習のハンズオン、本の内容を話し合う読書会、オープンな話し合いをするワールドカフェ、など、色々あります。

団体型、独立コミュニティ型、ボス型

勉強会の運営形態によって母体となる団体のあるもの、勉強会のみの独立したコミュニティを持つもの、一人あるいは複数のボスが中心になるものがあります。

ボスだけが頑張っても難しく、参加者を含めたコミュニティを形成している場合が多いと思います(オープンソースと似てますね)。また、コミュニティが団体になったり、団体から独立して勉強会のコミュニティができている場合もあります。

年代

コミュニティによって年代が分かれます。おおまかに20−30歳台、30-40歳台、50-60歳台、のような分類ができると思います。

若い人の多いコミュニティに年配の人や管理職、経営者などが参加している事もあります。しかし逆に50歳以上が中心のコミュニティは、管理や上流などの視点のものが多いのか、若い人の参加は少ない様に思います。

バリエーションで考える社内勉強会の難しさ

社外の勉強会を見ていると、コミュニティによってこれらのバランスが取れています。やはり、母集団が多いのでうまくいくのだと思います。スタッフも参加者もフィーリングのあうコミュニティを見つけられるので、継続的に活動・参加するのでしょう(社内に情報提供する際はなるべく上記のような情報を伝える様にしています)。

これに対して、社内勉強会では母集団が小さいのでバランスが取る事が難しく、継続するにはクラブ活動のような強い方向性がないと難しいと思います(うちの会社にも1980年代にはマイコンクラブとかUNIXの勉強会などが自然発生的にありました)。

社内勉強会の場合、どちらかというと新しい技術が話題になった際に、経験者を中心に単発的に行うとうまくいくと思います。個人的な興味では、Erlangとか、Qtとか、開発環境周りのツールとか、社内で勉強会をやると聞けば間違いなく参加しますが、強制したり無理に継続的なコミュニティにしなくても良いと思っています(続いたら続いたで良いですし)。

優秀な技術者でも社内に引っ込もっていては干上がってしまいますが、楽しくなければ続かないと思います。

誰だって豊かな人生を歩みたいのですから「こんな楽しい事もあるんだよ」と楽しみながら伝えていれば良いのだと思っています。

イン・タイムではなくジャスト・イン・タイム - 大野耐一氏 トヨタ生産方式 その1 -

大野耐一氏の「トヨタ生産方式」をぼちぼちと読んでいます。ムダを徹底的に排除する事で生産性を向上させようとする試みは、ジャスト・イン・タイムを実現する事で在庫をなくして倉庫のムダな費用を発生させないようにします。

これは、期限までに作れば良いという「イン・タイム」では実現できません。アメーバ経営で、仕掛品を評価しない事と通じます。

トヨタ生産方式の議論で多いのは、ソフトウェア開発に置いて在庫とは何かです。上記を踏まえると、倉庫代や税金などによって存在が負担になるものです。ソフトウェア開発で考えると価値を提供しないソフトウェア、技術的負債を与えるソフトウェアになるでしょう。

大切な点は、ムダが何であるかではなく、ムダをいかに減らす事ができるかと言う事です。つまり、価値を提供しないソフトウェアを減らすには、一度に開発するのではなく段階的に開発する事ですし、技術的負債を貯めないには評価されないままに横展開を進める事だと思います。

ソフトウェア開発では、常に本物を確認して、常に石橋を叩きながら開発を進める事だと思いました。


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