無料ブログはココログ

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

Shibuya.trac 第10回勉強会 #shibutra

実はtracもけっこう使っているので、デブサミ後のShibuya.trac 第10回勉強会はとても楽しみにしていました。なんと60人も集まった勉強会は期待を裏切らないものでした。

特にOかもとさんの発表は、デスノートがその語源のtrac lightning後継のKANONの発表という、ホットなものでした。このKANONは、ベースをLinuxにし、アジャイル開発を意識し、MS Project互換のOpenProjectと連携するというなかなか期待できる内容でした。

懇親会では、OかもとさんからWindows上では改行コードの問題で開発しにくかったこと、ユーザの方からは社外の協力会社に使ってもらうにはセキュリティ上Linuxの方がうれしいというお話が聞け、それぞれなるほどと、思いました。

名古屋から来られたこくぼさんは、Redmineでブイブイ言わせているとの触れ込みでしたが、「本物」でした。小規模アジャイル開発ならBacklogsプラグインは、とても便利だと思いました。

すでに、発表資料とお試しRedmineまで用意されています(背景のかわいい赤ちゃんがないのが残念!)。

この他にも、充実したLTあり、ネットでしか知らなかった多くの方々や、初めての方々との出会いと語らいがあり、非常に充実した勉強会でした。

スタッフの皆様、会場をお貸しいただいたニフティの皆様、発表者ならびに参加者の皆様、本当にありがとうございました。

詳しい内容はWikiからたどれると思いますので、ぜひご覧ください。

時代の変化を体感! - デブサミ2011 その4 - #devsumi

Developers Summit 2011に初めて参加・発表しました。200人あるいは300人の5つの部屋で同時にセッションが行われるような催しは初めてで、その迫力に圧倒されました。

私の経験したシンポジウムではプログラム委員を決めて、その人たちの合議制で決めていました。とはいえ、民主主義は時間がかかるので、委員長がたたき台を用意して、あーだこーだいうのがせいぜいでした。

デブサミの詳細な方法は知る由がありませんが、少なくともコーディネータを複数決めて、その人たちが発表者に依頼・調整するという方法をとっているようです。なるほど、この方式なら、少なくとも並列度のコーディネータがいれば何とかなりますね。デブサミでは,
このコ-ディネータの選別が秀逸なので、多くの方が来られるのでしょうね。

さて、今回のデブサミでは時代の変化を体感しました。 それはTwitterと若手です。

1.Twitter

スタッフのみなさん、ソフトバンクの皆様のおかげで、これまでは電波の届かなかった会場にアンテナが設置されました

私と小川さんの発表においても、多くのコメントが寄せられ、自分たちの発表がどのように思われたかが良くわかりました。

また、及川卓也さんのMS時代のお話(Webで公開されている)が興味深くてつぶやきましたが、内容に間違いがあり、ご本人からご指摘いただけました。これも、社会の上下関係を希薄にするインターネットらしい出来事だと思いました。

2.まとめサイト

デブサミ中からツギャザーが始まり、デブサミが終わるとすぐにまとめサイトができました。

この他にも、多くの方がブログにコメントをされており、協力によって分散処理を実現するチケット駆動開発のような作業分担が、実現されていることに感動しました。

素晴らしいまとめサイトをありがとうございました。

3.若手

デブサミは現場の開発者のお祭りです。私より若い人がたくさんおられ、元気よく発表されていました。その中でも、14歳の矢倉さんの発表は感動モノでした。しかもLTの短い間に、笑いもきちんととるという素晴らしい発表でした。

日本の未来も大丈夫だと思うと共に、会社の若い人たちにもぜひ外に出てほしいと思いました。

4.最後に

あれだけのイベントを開催するのはとても大変なことだと思います。スタッフのみなさん、ボランティアのみなさん、本当にありがとうございました。また、Softbankのアンテナ設置に努力していただいたスタッフのみなさん、雅叙園のみなさん、Sofybankのみなさん、ありがとうございました。

[#TiDD]チケット管理システム大決戦 JIRA vs Redmine vs Trac - デブサミ2011 その3 - #itsjp #devsumi

サブタイトルを含めると

「チケット管理システム大決戦 JIRA vs Redmine vs Trac ~ユーザーが語る、なぜ私はこのツールを使うのか」

というこのパネル、初めて聞いた時には時間が短いこともあり、「そんなパネルで大丈夫か?」といまどきの言葉で心配していました。しかし、皆さん紳士的でそれぞれの特徴を述べながら「チケット管理システム(BTS)を使いましょう!」との共通の思いを語られていたのが印象的でした。

逆に言うと、もう少しバンバンやってもらっても面白いかとも思いましたが、あきぴーさんが書かれているように最終日に別の場所であったShibuya.Tracで、Web上で続けられることになりました。楽しみです。

私個人は、条件を付けずにいうならデフォルトでガントチャートと親子チケット(サブタスキング)が可能なRedmine(あるいはChiliProject)かと思いますが、多くの意見を取り入れて手になじむTracも良いと思います。

BTSの議論を聞いていると、パソコンの前のマイコン時代の議論を思い出します。あのころもそれぞれに特徴があって、多くの議論が行われたのですが、個人的な結論は詳しい知り合いがいるなど「情報が得られるものを選べ」でした。

Redmineでも、Tracでも、それぞれの機能の差よりも、入れてからの使いこなしが重要なので、自分に合った情報源のあるものを選べばよいかと思っています。そういう意味では、(使ったことはありませんが)有償のJIRAなども有効な選択肢ではないかと思っています。

そういう考えですから、この新しいWeb上の大決戦のような活動で、どの程度アピールできるかが、仲間(ユーザ)を増やすポイントになるんだろうと思います(とあおっておきます)。。

(更新)プログラマが知るべき、たったひとつの大事なことがら - デブサミ2011 その2 - #devsumi

Developers Summit 2011の講演で最も印象的だったのが、和田卓人さんの講演でした(j7400157さんのブログ記事が詳しいので、詳細はぜひそちらを見てください)。

2011/2/25追記:スライドが公開されましたので追加しました。

このお話に惹かれたのは、以前からエンジニアはどう生きるかということが気になっていたからです。

1.手配師になるか技術屋で生き残るか

一緒にチケット駆動開発の本を書いたあきぴーさんのブログを、何かの時に見ようと思って検索したとき、
手配師になるか技術屋で生き残るか

というエントリーが目につきました。これは「コンサルタントのつれづれ公開日記」の2つの記事

をもとに書かれています。最近の大手ベンダーのSEは、「手配師」っぽくなっているという話です。元記事には

「ひとつポイントとなるは、「手配師」をよしとするか、否かだ。ここの価値判断が問われそうだ。」

とありますが、そんなものなのかと思って、手配師をWikipediaで調べてみると

「手数料を取って人材を周旋する者」

とありました。たしかに、ソフトウェアの仕事は、そんな風に見える局面もありますが、どちらかというとそのあとの、

「請負師といった場合は、仕事を請け負い、自らは労働や作業をすることなく、必要な人材(職人)や材料を手配し、かかった手間賃や材料費に利益を上乗せして稼ぐ者のことも指す。」

の方がまだ近いように思います。そこで、「請負師」で検索すると「建設の陰と陽」というサイトに

大手請負師とは、現在のゼネコンのことです。

とありました。そこまで行くと技術をするか管理をするかという一般論になってしまうようにも思えます。その観点で考えると、確かに二者択一のようではありますが、どうも違うような、少なくとも自分はそんな生き方はできないように思っていました。

2.和田さんの講演

そのようなことを考える中で、和田さんの講演「プログラマが知るべき、たったひとつの大事なことがら」は、思いめぐらしていたことをすっきりさせてくれました。

和田さんはTDDで有名な方ですが、「プログラマが知るべき97のこと」という本の監修をされています。この本は、原著の97人+日本の10人が少しずつ書かれた本なので、その内容をすべて話すことはできず、色々な方と相談されたようです。その結果、本をベースに「自分にしか話せないこと」を話そうと決められました。

そして、和田さんは人生を語られました。

a)脱完璧主義

元々はオブジェクト指向の完璧主義だったそうです。それが、TDDを知ることで、

 失敗(Red)=>動くコード(Green) =>リファクタリング=>失敗

という黄金の回転によって、いきなり完璧を目指すのではなく、まずは動くように開発して、徐々に開発するというようになったそうです。

b)出会い

TDDを学んだのは、まさーる(石井勝)さんからだそうです。とても親切に教えてくださったそうです。このまさーるさんとTDDによって完璧主義の呪いから救われたそうです。

その後、石井さんは福知山線の事故で亡くなられました(石井さんはSEA関西やXPJUG関西にもよく出られていたそうです。残念ながら私はあまり記憶がないのですが、当時、周りの人は大きなショックを受けていました)。

c)情報発信

その後、和田さんは教わったことを情報発信される様になりました。

「アウトプットするとインプットが増える。ブログや講演をするとさらにインプットが増える。オファーがきたりする。」

この言葉、パソコン通信の時代から「情報を得るにはGIVE&GIVEだ!」という様な言葉で言われていますが、実際に実践されている方の言葉だと重みが違います。人に情報提供することで、関心を持つ人が集まって、情報が集まるのです。

d)僕がどういう事ができるか?

講演の中で最も私の心に響いたのは、どうしてアジャイルでなくTDDかというお話で出た

「僕がどういう事ができるか?」

という言葉でした。はやりの技術やこだわりではなく、自分の立ち位置をどういう事ができるかから考えることは、とても重要だと思いました。

3.自分の人生を生きていく

この講演を聞いて、最初にあげた

「手配師になるか技術屋で生き残るか」

という問題で、ひっかかっていたことがわかったような気がします。自分が「どのように生きたいか」というこだわりは誰しもあると思います。しかし、技術志向で生きていこうと思っても、思っているようなプロジェクトに当たるかどうかはわかりませんし、担当作業の割り当てて自分だけおいしい仕事をするわけにもいきません。自分が技術力を向上できる仕事が好きなだけに、ついつい

「おいしい仕事は若い人に」

と思ってしまいます(それを、ややこしいところだけ任せられると思われてショックを受けることもありますが、、、)。

無理にこだわるよりも、チケット駆動開発のBTSみたいにプロジェクトに大切な人になって、プロジェクトを成功させたいと思ってしまいます。結局、

「手配師でもなく、請負師でもなく、コンサルでもなく、研究者でもなく、プロジェクトを成功させる人でありたい」

と思います。より、一般化するならば、何かにこだわって生きるのではなく、

「手配師でもなく技術屋でおなく、自分の人生を生きていく」

ことが大事なのだなぁ~、と思いました。


[#TiDD] チケット駆動開発  タスクマネジメントからAgile開発へ part1 - デブサミ2011 その1 - #devsumi

デベロッパーズ サミット2011であきぴーさんと共にチケット駆動開発の講演ました。

Twitterに多くのコメントをいただき、Togetterもしていただきました。ご参加いただいた皆様、そして発表の機会をいただいた和田さんに感謝してします。発表のスライドを公開いたしますので、よかったら見てください。後半の小川さんの記事はこちらです。
(2011/2/15 小川さんのスライドを追加しました)

【17-B-3】 チケット駆動開発 タスクマネジメントからAgile開発へpart1
View more presentations from Makoto SAKAI.

やっぱり枝雀さん!「落語 昭和の名人完結編(1) 桂枝雀(壱)」

私が桂枝雀師匠の落語に出会ったのは、友人に教えられた「枝雀寄席」のようなタイトルの番組でした。小学生のころは親に隠れて深夜ラジオで落語を聞いていたものの、あまり聞かなくなっていた落語。独特の攻め口に、独特の話法、変な顔、絶妙な間、こんなに落語家で変わるものかと驚きました。

最近、TVのCMで「落語 昭和の名人完結編」なるCD付マガジンの第1巻が「桂枝雀(壱)」で490円とのこと。思わず書店に向かいました。1軒目は売り切れで2軒目で最後の1冊をGETしました。

CDなので画面がないのは残念ですが、往年の枝雀さんの姿がよみがえります。第5巻がまた枝雀さんのようなので、また聞くつもりです。

落語 昭和の名人完結編(1) 桂枝雀(壱) 私が桂枝雀師匠の落語に出会ったのは、友人に教えられた「枝雀寄席」のようなタイトルの番組でした。小学生のころは親に隠れて深夜ラジオで落語を聞いていたものの、あまり聞かなくなっていた落語。独特の攻め口に、独特の話法、変な顔、絶妙な間、こんなに落語家で変わるものかと驚きました。 最近、TVのCMで「落語 昭和の名人完結編」なるCD付マガジンの第1巻が「桂枝雀(壱)」で490円とのこと。思わず書店に向かいました。1軒目は売り切れで2軒目で最後の1冊をGETしました。 CDなので画面がないのは残念ですが、往年の枝雀さんの姿がよみがえります。第5巻がまた枝雀さんのようなので、また聞くつもりです。

[#TiDD] yaXPでXPのハードルを下げ、自律的な組織を実現する

先日の説明では、詳細をXP祭り関西のライトニングトークスのスライドに振っていましたが、やはりネタはネタなので、yaXPについてまとめておこうと思います。XP(eXtreme Programming)にTiDDを適用した事例は、小川さんと共著で書いたSQiPの論文(PDF)にあり、今度のデブサミ2011でも小川さんが語られる予定です。ここでは、私の経験からyaXPの可能性について語ってみたいと思います。

1. yaXPとは

yaXPはBTSを用いたXP(eXtreme Programming)です。XP版のチケット駆動開発と言ってもよいでしょう。

  • タスクカードをBTSのチケットにする
  • タスクボードをBTSのチケット一覧(レポート)にする
  • イテレーションのタイムボックスをマイルストーン(バージョン)で管理する
  • スタンドアップミーティングではなく座ってBTSを使って朝会をする

というものです。それ以外は、XPと同じです。

2. XPのハードルとyaXPのメリット

XPにはいくつものハードルがありますが、yaXPと関係するものは以下の3つです。

a) タスクボード

ホワイトボードや掲示板を新たに用意することは困難です。先日の説明のようにエクセルを使ってしまった場合の問題のほか、購入などの決済が必要になることからトップダウンでXPを始めてしまい、XP自体が目的となってしまう可能性のあることが、自律的な活動を妨げます。

エクセルで仕事がトップダウンに与えられるなら、それは作業指示であり、進捗報告のまとめにすぎません。最初に見て、時々誰かが更新するだけです。それによって自分の作業は管理されません。

yaXPなら場所の問題がないだけでなく、より自律的に運用することができます。メンバーがメンバー自身のチケット一覧を表示することができるからです。チケットはチームのスケジュールを管理するものであるだけではなく、個人の作業も管理するものです。

yaXPでは、チケットはコミットされた計画です。担当者が見積もり、約束した結果がチケットなのです。チケットの運営方針によっては、チケットはリーダが作成するかもしれませんし、オープンに誰でも登録できるのかもしれません。いずれの場合でも、担当するチケットを一覧して実現不可能なら、不可能であることを宣言してチーム内で調整する必要があります。

このようにタスクボードを用いなくても、担当するチケットへのコミット(約束)によって自律的な行動が行われます。コミットされたチケットは、妥当な見積もりに基づき、約束されています。無理な計画をやらされるのではなく、自ら約束したスケジュールをメンバー自身が守ることで、安定した開発が行われるのです。

b) トップダウン文化のベテラン

ベーム先生の「アジャイルと規律」では、アジャイルには技術力が必要とされていますが、ベテランが良いとも限りません。トップダウンの組織に慣れている場合があるからです。トップダウンの文化ベテランは、任せられたことはきっちりこなしますが、言われていないことに口を出しません。作業指示をしなければ、何も始まりません。

そこで、リーダーがすべての権限を掌握するのではなく、プロジェクトの特性や状況、メンバーの能力に合わせて権限を委譲します。

yaXPでは、チケットの運用を徐々にオープンにすることで自律的なプロジェクトを目指します。仕様の管理にかかわることは専任者が行うとしても、個人の作業は個人が管理し、抜けている作業があれば自主的に追加するようにします。すると、プロジェクトの雰囲気は大きく変わるでしょう。

オープンな運用により、メンバーはよりチケットを中心に作業するようになります。チケットは管理に都合の良い粒度のものだけでなく、担当者によって作業の重要度によって細かな作業も登録されるようになります。やがて、必要な作業がすべてチケットに登録されるようになります。

チケット一覧はチーム全体の一覧だけでなく、メンバーごとに担当するチケット一覧が使えます。プロジェクトが、チケットの優先順位によってリリースのスコープを変更するように、個人もその日のスコープ(ゴール)を変更しながら、担当作業に集中することができます。メンバーは担当するチケット一覧に基づいて、(1)ゴールを決める、(2)作業を実施する、(3)進捗を登録する、という個人のリズムに集中できるようになります。

このようにして、XPにあるタイムボックスというチームのリズムのほか、個人の日々のリズムという2重構造のリズムが形成されます。与えられた作業がリーダにより管理されるものではなく、個々人の作業を本人が管理するものとしてチケットが用いられるようになります。こうして、プロジェクトはより自律的に運用されるようになります。

c) 構成管理

SQiPの論文(PDF)にあるように、リリースを行いながら開発をすることは、構成管理を難しくします。すでにリリースしたコードに不具合があると、リリースされているのコードだけでなく、開発中のコードにも修正が間違いなく行われなければならないからです。

yaXPで用いるBTSは構成管理ツールと連携して、不具合の履歴や修正に関する議論なども残されるほか、チケットのワークフローによって作業が管理されますので、作業の抜けを防ぐことが可能です。

3. まとめ

yaXPならXPの問題を解決するだけでなく、組織をより自律的にすることが可能です。ただし、それは可能性があるだけです。リーダーが自律的な組織をめざし、そのメッセージをメンバーに伝えることができないなら、実現できないでしょう。

これは従来法にTiDDを適用したとしても、SCRUMにTiDDを適用しても(yaCRUM)、KANBANにTiDDを適用しても(yaKANBAN)同じです。リーダの強い意志とメンバーへのアプローチが必要なのです。

4.補足説明

先日のLTに関して2点補足説明があります。

・タスクカードが剥がれてなくなる

その経験はありません。でも、わかりやすいように並べ替えたり、進捗に応じて貼りなおせば、きっと剥がれることもあるだろうと思って、ネタとして入れました。実際には、セロテープで補強するなり、掲示板なら押しピンでとめておけば問題ないでしょう。それよりも、まずは場所があるかどうかだと思いますので、剥がれるかどうかは本質的な問題ではないでしょう。

・やってみなければいけません

これは私の本心とは違います。あの構成はいわゆる「天丼」というもので、天丼にエビが2本あるように同じことを繰り返すことで、笑いを誘っています。参考文献を紹介する導入としてうまくつながらなかったので「やってみなければいけません」と入れました。本心としては、先日の記事のように実証するか、確信がなければ実施すべきではないと思います。プロジェクトの実施には説明責任があり、私物化は許されないからです。

[#TiDD] ちょっとまじめにyaXP(yet another eXtreme Programming)

先日のXP祭り関西のライトニングトークでお話しした「yaXP: もう一つのXP」は、お祭りの雰囲気を盛り上げるためのネタでした。しかし、本の宣伝を除いた部分は、体験に基づくプロセス改善の提案です。ここではちょっと真面目に背景を説明してみたいと思います。

XPのむずかしさ

それは第1次アジャイルブームの頃でした。「アジャイル=XP」のような時代で、これは良さそうだと、担当していた研究開発プロジェクトで実践したことがあります。

しかし、XPで効果をあげることはできませんでした。今から振り返ると以下のような問題がありました。

(1) 場所の確保

タスクボードを確保しようとするとホワイトボードを占有してしまい、打ち合わせに支障が出てしまいました。仕方がないので、エクセルシートをタスクボードに、1行をタスクカードに見立てて管理しました。これが以下のような問題をのベースにありました。

(2) 進捗管理が難しい

XPではタスクボードで進捗を管理します。タスクボードには3段階の進捗があるだけです。プロジェクトの進捗を管理するには、従来の管理単位よりも粒度の細かい作業に分割する必要があります。しかし、エクセルをタスクボードにしたために、新しいタスクの登録が億劫になってしまい、これまでの線表レベルのタスクに分割しただけでした。結果的に進捗が%で表されないので細かな進捗がわからず、管理が困難になっただけでした。

(3) 自律的でない

エクセルというツールの特性から、タスクのたたき台はリーダの私が作成し、その後にチーム内で確認しました。しかし、各担当者は従来の開発どおりに、与えられた作業を実施するという感覚のままでした。担当の作業を確認し、詳細化し、コミットする、といった感覚はありませんでした。

(4) 情報共有

全体のスケジュールは全員で共有していましたが、問題の発生を共有できていませんでした。誰かの作業に問題が発生しても即座に対応できず、結果的に問題が発生してもずるずるとスケジュールが遅れるだけでした。

結局、XPを意識した形だけの開発はうまくいきませんでした。

プロセス改善のキモ

今から考えるとXPやアジャイルを形で捕らえていたのが敗因でした。仕様や開発方針の決定権が開発チームにあり、ホワイトボーの件を除くとアジャイル開発に有利な環境でした。しかし、なぜそのような活動をするか、何が目的であるか、そのことを抜きにして安易にプロセスを「まねた」ので、うまく行かなかったのです。

当時「良いプロダクトは良いプロセスから生まれる」と言われていましたが、その良いプロセスとは、人のものまねではないのでしょう。よく考えられ、一貫性があり、組織的なものなのでしょう。

たとえばレビューを考えても、ベテランのレビュアなら何もしなくてもうまくいくでしょう。しかし、レビュアによっては教育が必要で、チェックリストやレビュー時間の基準なども必要でしょう。人を見て、開発対象を見て、どこにリスクがあり、どう攻め込むか、そんなイメージがはっきりしていなければ、どんなに良いプロセスをまねてもうまくいきません。

良いプロジェクト

私の考える良いプロジェクトは以下のようなイメージです。

  • トップダウンでなく、自律的、協調的
  • コミットメントによる見積もり精度向上
  • もれなくタスクが実施される
  • 問題が常に見える化される
  • 混乱のすくないテンポの良いプロセス

リーダーの役目はメンバーの能力を引き出すことです。やってみたいではダメで、きちんと目論見があって実施すべきです。問題をきちんと見極めたなら、その問題を解決できる方策を考えます。それが仕事です。結果的にアジャイルや何かに近いかもしれませんが、アジャイルが目的でなく、プロジェクトを通じて関係者をより幸せにすることが仕事です。

チケット駆動開発がもたらすもの

上に書いた良いプロジェクトを目指す中で、私はチケット駆動開発を導入しました。そのプロジェクトはStrutsベースのパッケージをカスタマイズするという従来型の開発でした。多くの問題がある中で私が解決しようと思ったのは、システムテストに向けての環境構築などの細かな作業を管理することでした。

それまで閉塞感を感じていたプロジェクトの雰囲気は、目の前の問題が解決されることで少しずつ改善しました。そしてチケット駆動開発による、ワークフローやトレーサビリティによる安心感のほか、見える化によるコミュニケーションの改善、スコープの変更による想定外の問題への対処など、多くの効果がありました。

その効果の多くは目指したものではありませんでした。チケット駆動開発でプロジェクトのもっとも大きな問題を解決することで得られた副次効果です。あれもこれもと欲張らずポイントを絞ることで、メンバーに受け入れられてうまくいったのです。

いわゆる2割8割の法則、パレートの法則では、2割の問題が8割の負担を与えると言われます。もっとも大きな問題に注目することが最も効率が良いのです。チケット駆動開発はおまけの多い開発法ですので、大きな問題に注目することだけで十分なのです。

yaXP

さて、話をXPに戻します。yaXPはチケット駆動開発によるXPです。すでにXPを実践されていて、問題がないならそのままでよいでしょう。従来開発でうまくいっている場合も、そのままで良いでしょう。

ただ、現状の開発に問題があり、それがYaXPで解決できるものなら、一度検討してください。その問題についてだけ検討してください。もし、その問題を解決するもっと良い方法があったなら、それを採用してください。

次に具体的なイメージを思い浮かべてください。想像できなかったり、メンバーの個性を考えると難しそうなら、あきらめてください。イメージできないプロセス改善がうまくいくはずありません。

そして、メンバーに大切なことだけ伝えてください。一度に多くの支持を受けてもうまくいくはずがありません。なるべくポイントを絞ることで理解度が上がります。理解してもらえたなら、それだけは実践されるでしょう。

もし、反対意見が出たならよく話し合ってください。そして、より良い方法を見つけてください。あなたの考えたプロセスを実践することが目的ではなく、メンバーの能力を最大限に発揮させるのがあなたの仕事なのですから。

このようにyaXPを実践されたなら、きっとうまくいくはずです。もし途中で問題が出たなら、どんどん改善してください。「ふりかえり」が大きな力になるでしょう。

おわりに

もう一つのXP(yaXP)と言いながら、ほとんど説明しませんでした。それは、あなたが考えるものだからです。基本的なアイデアはスライドにあります。これをもとに現在の問題が解決できるかどうかを考えてください。そしてより良いプロセスで、メンバーの能力を最大限に引き出してください。論文のPDFのほか、良い参考文献はあります(^_^;

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