本日は、名古屋でSEC主催のワークショップにチューターとして参加しています。

まだ始まったばかりなので、ご参加いただいたみなさんに楽しんで何かを持って帰っていただけるように、これからがんばりたいと思います。


ところで。


今日は準備のため午前中から会場にいるのですが、着いた途端に数人がわさわさと動き出し、何らかの準備がはじまりました。

でもわたしは今までSEC主催のワークショップには参加したことがなく、どう動いていいかわからないままほぼ午前中が終わってしまいました。


なんかモヤモヤしたまま、ワークショップは始まり、30分ほどの担当プレゼンも終わらせました。(今ココ)


なんだろう、このモヤモヤ感。


そうだ。朝会がないからだ。


今日誰が何をして、どういうアウトカムを求めるか。毎朝それを確認しながら仕事するから、最初からキビキビと動けるのだろうに、それがないまま作業が始まっちゃうと、やっぱりなんかウロウロする。それでも何とかできちゃうから、これを見直そうという気持ちにならないんだろうなー。やっぱり日々の仕事を「見える化」してから動くのと、そうでないのとでは作業の成果にマイナスイメージのフィルタをかけてしまいそうだ。


なんてこと、今考えていたら「見える化」が大切なことを知るために「見えない化」をやるワークショップとかすればいいような気がした。例えば、わざと空中戦やって、一度結論だけのプレゼンしてもらって、再度討議をして他の人が発表してみる。さて、討議したメンバーは本当にその中身を理解していたでしょうか?


ワークショップというより、実験だけしてみるのもいいかもしれない。



まー、それにしても、SEC主催のワークショップなんだから、やっぱり朝会やりましょうよ。(毒)

今、カンブリア宮殿を観ていました。今日は「星野リゾート」でした。

経営破綻した宿泊施設でさえ、人気のリゾート施設に再生する「リゾート運営の達人」のお話。


この中で、ホテルのスタッフがリピータのお客様を迎えるまでに、数人のメンバーで編成されたチームが徹底的に顧客の過去情報を分析して、どのようなおもてなしをするかという作戦を練っていました。


この過去情報とは「気づき情報」という名で、その顧客が以前宿泊したときに、とても細かいことでもスタッフの目線で気づいたことをコンピュータ上の情報共有ツールに入力しておくもの。

それを利用して、今度おもてなしをするスタッフは具体的なおもてなし戦略を作るのです。


これをみて、はたと気づいたことがありました。

わたしたちも、生産性やバグ率などのメトリクスは収集しています。面倒くさいと思いながらも。


一体、このメトリクスは何のために蓄積しているのか?


理屈ではわかっていても、どこか腑に落ちない部分を抱えていることが多かったように思います。では、その違和感は何か?品質や生産性の指標は、顧客に対して自分たちが「精一杯やっていますから認めてください!」と、ある意味では言い訳の材料にしようとしていたからではないか?揉めたときの交渉の材料にするため、と思ってはいないか?


「説明責任」のための材料ということは、全面的に否定するのもではありません。必要なこともあると思います。しかし、それが最初から前提でメトリクスを収集するというのは、最初から顧客を「仮想の敵」として考えているように思えてなりません。


話の最初に戻ります。

何のためにメトリクスを蓄積するのか?それは、最終的に「顧客満足を得るため」とすることが必要なのではないでしょうか。


そこに至るプロセスとして、説明責任としてのメトリクスという考え方は“あり”だと思います。

でも、本来は「お客様が満足して対価を支払ってもらうための資料なんだ」と、言葉を変えて「想う」だけで、そのメトリクスを収集することへのモチベーションは劇的に変わるのではないでしょうか?


わたしの以前の役割である「プロセス改善推進担当(SEPG)」としてそこに役割があるとすれば、やはり「顧客満足を得るためにメトリクスを収集するんだ」という思いを、もっともっと伝えていく必要があると思います。


なぜソフトウェア工学を使って顧客の理解を得ようとするのか。顧客が理解してくれる、ということはそのまま「顧客満足を得られた」と考えてよいのではないでしょうか。


自分たちの言い訳をするためと、顧客に満足・納得してもらう、ということの目指すゴールは異なっても「メトリクスを収集し分析する」というプラクティスは変わりません。しかし、そのアウトプットの質は大いに異なるように思います。


計測やプロジェクト運営に仕組みを作っていくこと。そしてそれを例外なく守っていくこと。それらの意義を説明する言葉に「顧客満足」が必ず繋がるように説明しつづけること。


大事なことなので2回書きます。


メトリクスは顧客満足獲得のためのツール


それはメトリクスに限ったことではないと思う。その他様々な「開発には直接関係ない、諸々の面倒なこと」と思われがちな活動に、魂を吹き込めるかどうかは、SEPGが如何に顧客満足と繋げてその必要性を伝えらるのか、ということにあるんじゃないかと、星野リゾートのスタッフの、生き生きとした働きぶりが教えてくれました。


いつか、星野リゾートのホテルに泊まってみたい。

あけましておめでとうございます。
今年最初の投稿になります。今年もよろしくお願いいたします。

さて、弊社も昨日から業務を開始いたしました。さすがに初日は少々お正月気分でしたが、今朝はもうしっかりと仕事モードです。

前回も書きましたが、現在稼働している2プロジェクトの、バックログ一覧やバーンダウンチャートを更新するのがわたしのファシリテータとしての仕事の1つです。

そのうち1プロジェクトは、昨年末に第1フェーズを終えて、今日からは新しいかんばんで作業を開始します。
この新しいかんばんを作成するのも、わたしの仕事としてもいいのですが、気が付いたらもうメンバーが自分たちで作っていました。

壁に貼っているかんばん以外に、個々のリクエスト単位にA4の紙1枚を使って「作業表」というものを作成しています。これさえあればプログラマは作業することはできます。必要最低限のツールはこの1つだけでいいはずです。

それでも、自分たちの作業全体を見えるようにしておきたいという「欲求」が、作業の上では必要以上かもしれないけれど、自分たちを駆動するものとしてかんばんを自ら作ったのではないかと思います。

アジャイルの価値を確実にするものはリーンの思想だと思います。しかし、それだけではなくエンジニアがオプションを考えて可能な範囲でやり方を広げる余裕を許容することも、アジャイルのひとつの姿勢なのかもしれないと思いました。
弊社では、Excelを使ってバックログ管理と同時にバーンダウンチャートを出すようにしています。

なんかアジャイルのプラクティスに、どっか反してるように思えるでしょ?
ところが、面倒なんですけど、毎日残ログ一覧とバーンダウンチャートは印刷して、壁に貼っているのです。

全リクエストの進行状況は、リクエストを処理するプロセス毎に星取表を作って、1プロセスが終わる度にドットシールを貼っています。

というのが弊社の「かんばん」実践状況なのですが、このうち残ログ一覧とバーンダウンチャートを更新するのがわたしの仕事になっています。

年明けから次フェーズを迎えるプロジェクトのために、Excel表を更新していたのですが、それに伴って表の使い勝手をあれこれと直してみたのです。

今まではその日の進捗であるデータを2、3か所入力していたのですが、1か所入れれば関連するシートのデータがすべて更新されるようにしました。

しかし、途中で気づきました。あまりにシート間に関連をつけると、後の変更に融通が効かなくなる。
これはプログラム間の結合度と同じことのように感じます。

前職でSEPGをやっていたときも、同じような仕事をしました。しかし、そのときはどこまでも自動化による便利さを追求して、マクロを作りまくっていました。

なぜ、こんなふうに意識が違うのだろうか?

正直なところ、SEPGとしての自分の仕事を誇示するため、というか自分の仕事への正義感なんじゃないかと思います。それは悪いことではないのですが、やはり「本当に必要なこと、十分な程度」ということについて、実際にそれらのツールを使う現場の目線に立ててなかったのではないかと思います。

自分の仕事を遂行することで、現場に良くなってもらいたい。それは意識として正しいことと思います。この一文で大切なことは「自分の仕事」じゃなくて「現場に良くなってもらう」なんですね。
つまり、SEPGが気付かぬうちに「金メッキ」を施してしまうということも、改善の推進を阻害する一因になっているのではないでしょうか。

使い勝手のよいツールとはなにか。何度か考えてきたことですが、まだまだ気付かされることが多いテーマです。
G.M.Weinbergをご存知でしょうか?

わたしは大概のソフトウェアエンジニアなら知っていて、1冊は彼の著作を読んでいるものだと思っていたですが、そうでもないんですね。わたしより年長の方でも知らないという方もいました。

ワインバーグはコンピュータがビジネスとして用いられるようになった黎明期から、エンジニアとして、その後コンサルタントとして第一線で活躍してきた人です。
ソフトウェア開発において最も重要なことは「人」である、ということを早くから論じていて、その著書は多くの人に愛されています。

今、彼は癌のため闘病中です。その彼を少しでも励ますことはできないだろうか。そんな思いからこのカンファレンスを開催することになりました。

《まったりと、濃厚なイベント》
参加者は最終的に10名と、ごく少人数となりました。
実のところ、予想よりは少なくなってしまったのですが、結果としてはこの少人数がよかったと感じています。
参加者全員が、5分は発表の形でワインバーグの著作に対する思いを語り、またセッション中にもいろいろな意見を出しても、進行には支障なく、その上コンテンツの内容をより濃くしてくれるものとなりました。

最近は参加人数が多めのイベントに多く出ているので、このような濃厚なディスカッションができる人数というのも悪くないな、と思いました。

セッションの内容ですが、諸事情により当初予定していたものとはかなり違うものとなってしまいました。それもまた善しといえる“まったり”した雰囲気で、カンファレンスは進みました。

用意していて、きちんとできたのは平鍋さんによるワインバーグのインタビュー紹介ぐらいで。内容は平鍋さんのブログをご参照ください。

参加者のみなさんは、それぞれワインバーグへの思いがとても強く、暑く、濃い方ばかりでした。たぶん最も薄いのが主催者側のわたしたちだったかもしれません。べーっだ!

特に印象に残ったのは、某有名検索企業G社でプログラマをされているまだ27歳という若い方。学生の頃にワインバーグに出会い、傾倒。彼の考え方がいつも自分の仕事を成功に引っ張ってくれる、と言っていたことです。
わたしの知る限り、ワインバーグの本が好きだという方は「つらいときにワインバーグの言葉に励まされた」という、つまり“痛い”経験をした人がほとんどなのですが、そうではなく成功のための行動指針として存在しているといのが、単純に「すごいっ!」と思いました。彼にはぜひ将来ワインバーグを大いに語る著書を執筆していただきたい。


カンファレンスでわたしがやったことといえば、現在この本を翻訳中の伊豆原弓さんからのメッセージを代読したぐらいでしょうか。
Perfect Software: And Other Illusions About Tes.../Gerald M. Weinberg

¥1,840
Amazon.co.jp

新しい著作が読める。とても楽しみです。


《ワインバーグとわたし》
わたしがワインバーグの著作と出会ったのは、プログラマの仕事を始める前の学生のときでした。学校は情報処理系の学科だったので、図書館には数多くのコンピュータサイエンスやソフトウェア工学の本が所蔵してあります。その中にワインバーグの本もありました。
なんとなく読んでみようと思ったのですが、正直難しくて読めませんでした。いつかはこの本を読めるようなエンジニアになりたい。そう思ったものです。

たぶん、この辺の本だと思います。
ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉/G.M.ワインバーグ

¥3,360
Amazon.co.jp

その後、この本を読み、初めてワインバーグの言葉に、ダイレクトに感銘を受けました。
ライト、ついてますか―問題発見の人間学/ドナルド・C・ゴース

¥2,100
Amazon.co.jp

そしてわたしがワインバーグに助けられたのは、プロセス改善の推進担当者をしていたときです。
現場やその上司に、カイゼンを受け入れてもらえずに対立してしまうようなとき、何が自分の言葉に足りなかったのかを教えてくれました。

それは、この本の「粒のあるイチゴジャムならどこまで塗っても薄くならない」という言葉です。

相手に印象づけられる言葉、つまり説得力のある言葉がない。そこから「相手に伝わる」ということはどういうことなのか?それを常に問い続けていたら、いつか対立は少しずつ解消できるようになりました。

コンサルタントの道具箱/ジェラルド・M・ワインバーグ

¥2,310
Amazon.co.jp

その他にも、改善推進担当者として心がけるとよいと思われる知恵が満載の本です。ぜひご一読を。





このカンファレンスの模様は、短いビデオにしてワインバーグへ届けることになっています。動画は平鍋さんに公開していただいているので、ここにも貼り付けておきます。


ワインバーグ氏が回復されることを、心からお祈りして…。

I wish your Merry Christmas.

ふりかえりツールとしてKPTは広く使われるようになりました。わたしもKPTを使ったワークショップを前川さんとSPES2007で やったこともありました。

KPTの良さは「次にやること」を挙げていくことだと、自分では思っています。プロセス改善のモデルのPDCAにおけるActionに相当することのプラクティスとしてはとても有効です。

しかし、今日社内で議論した中でKPTにもまだ弱点がある、という話が出てきました。

KPTによって新たなチャレンジとしてのプラクティスを挙げても、実際にはフェードアウトしてしまったりすることがある。それはなぜだろうか?

次にやることを考えるときに「なぜそれをやらなければいけないのか」ということが、KPTの上には書かれないということが1つの要因になっているのではないでしょうか。

KeepやProblemで挙がる、チームで起こったことやそれに対するメンバーの感情。そこからTryを導いているのですが、そこに「なぜ」があるはずなのに、KPTにはそれを書くスペースが用意されていないのです。

おそらく、KPTを効果的に活用している現場では、この「なぜ」もどこかに記入するという、独自の方法を使っているのかもしれません。紹介されているプラクティスはあくまでモデルであって、それを自分たちの使いやすいように、より効果的に工夫することが必要です。

弊社でもそうで、いろいろTryを挙げていっても、どうもそれが効果的に見えないケースが多い。そこにはメンバーが「本質を理解する」という部分がない、もしくはそのようなディスカッションは含まれていても、見える形で残さないと印象に残らないのかもしれません。

そこで、まだ名前は考えてないのですが、NewKPTが提案されました。


How to make a smiling face ~笑顔の作り方~
この利用方法は以下の通りです。プロジェクト終了時のふりかえりを例にしたいと思います。

1)プロジェクトの活動を通して、自分が感じたことを「自分の感情」エリアに挙げる。これは良いことも悪いことも一緒に。
2)プロジェクトの中で起きた事実を挙げる。例えば「仕様の誤理解で手戻りが発生した」とか「見積よりも思ったより早くタスクが終了した」など。
3)先に挙げた感情や事実について「何がそうさせたか?」を挙げます。すべての事実にはその原因があり、それを探ることで、本当の解決策を考える手助けをします。

簡単に手順を説明しましたが、これを挙げていくうちにも新しいアイデアが出てきました。
ここの「何がそうさせたか?」という問いは、トヨタ式で使われる「なぜなぜ分析」にとても近いものです。なので、この項目も3段階ぐらいやってみてはどうか、というアイデア。

また、従来のKPTを踏襲すると、やはり「次にどうするか」を挙げると思います。しかし弊社はそこをチームのふりかえりでやらなくていいのではないか、という結論になりました。

その理由は「自分で考えるエンジニアを育てたい」という会社の方針によります。

エンジニアにとって大切なことは、自ら考えチャレンジすること。そこに自らの工夫を持ち込むこと。
その場を提供するために、あえて結論を出すことルールにせず、各自で考えてもらうことをルールにします。

もちろん、やり方を決めようということがチームの決定であれば問題ありません。それはふりかえりを自分たちのルールで実施するという「エンジニアの工夫」であると解釈します。


ふりかえりのツールはKPTに限らず、まだまだあります。前回の記事でも紹介したこの本に、様々な方法とその効果が紹介されています。

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き/Esther Derby
¥2,520
Amazon.co.jp
これらを参考にして、自分たちの状況や目的に適ったふりかえり方法を模索することをお勧めします。楽しいですよ。

あたらしいこの方法に名前がついたら、またご紹介しますね。

しかしまー。twitterってすごいツールになってきましたね。

「12日に金沢へ行きます!」の、わたしのつぶやきがどうしたことか「TDD読書会+北陸エンジニアグループ2009ふりかえり」へお呼ばれするきっかけになりました。

場所は金沢市の郊外にある、金沢大学キャンパスの施設で「角間の里」というところです。

http://www.adm.kanazawa-u.ac.jp/ad_chiiki/kakusato/kaku-top.html

どうですか?とても素敵なところでしょう。
$How to make a smiling face ~笑顔の作り方~

前半のTDD勉強会はKentBeckの書籍である「テスト駆動開発入門」を参考に、数人の方がデモをしたりしながらTDDについて勉強されていたようです。

テスト駆動開発入門/ケント ベック

¥3,150
Amazon.co.jp


このセッションでは、わたしはまだ会場に到着していなかったので、他の方のブログをご参考ください。

http://d.hatena.ne.jp/shozzy/20091215/1260857308
http://prepro.wordpress.com/2009/12/14/tdd%E8%AA%AD%E6%9B%B8%E4%BC%9A3%E5%8C%97%E9%99%B8%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%972009%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E4%BC%9A%E3%81%AB%E8%A1%8C/
http://d.hatena.ne.jp/masayan_kazu/20091213
http://d.hatena.ne.jp/yuuitiro/20091212
http://d.hatena.ne.jp/shozzy/20091213/1260694997
http://d.hatena.ne.jp/katzchang/20091213/p1
http://blog.livedoor.jp/mitukiii/archives/929612.html
http://d.hatena.ne.jp/indication/20091212
http://blog.air-life.net/2009/12/hokuriku-engineer-group-retrospective.html


後半のふりかえりでは、僭越ながらファシリテータを務めさせていただきました。
というか、わたしTDDについてはまったくわからないし、北陸エンジニアグループのみなさんともほとんど初対面だったので、これぐらいしかお手伝いできなかったのですがね。

なのに、なんで金沢まで行って勉強会に参加したの?

なんて野暮なことは聞かないでください。わたしなんだから仕方ないですよ、はい。

ふりかえりはタイムラインを使って行いました。
わたしを呼んでくださった@katzchangさんも、「アジャイルレトロスペクティブス」を参考にしてタイムラインをやろうと思っていたとか。要求も合致していたのでわたしもこの本に従って。

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き/Esther Derby

¥2,520
Amazon.co.jp

6、7人で1チームになり、全部で3チームのふりかえりになりました。
中には初参加の方もいらっしゃったようですが、全体としてとても盛り上がっている状況が続きました。時間を区切っても、再三延長を望まれていたのがその証拠かと思います。

タイムラインを拝見して驚いたのは、実にたくさんのイベントを開催されていたこと。こういう場をみなさんが渇望しているのかな、ということをタイムラインから感じました。

それがどのような理由であるかは、みなさんからお聞きするチャンスをもてませんでしたが、北陸のみなさんの実に旺盛な学習意欲はよくわかりました。
そのあたりの理由や、みなさんの勉強会へのモチベーションなどはできれば懇親会でじっくりお聞きしたかったのですが、残念なことにご一緒できませんでしたので、次の機会に。

$How to make a smiling face ~笑顔の作り方~

みなさんの勉強会に対する思いが強いので、ふりかえりのファシリテータといっても大したことはできませんでした。逆にわたしがみなさんのエネルギーを感じて、また何かできることを探したいな、というモチベーションを頂戴しました。

そしてモチベーションだけじゃなく、名物の「とり野菜みそ」まで頂戴しました。

まつや とり野菜みそケース売りとり野菜みそ6袋&ピリ辛とり野菜みそ6袋

¥2,898
楽天
※モバイル非対応

スタッフの@katzchangさんはじめ、北陸エンジニアグループのみなさん、ありがとうございました。
短い時間でしたがとても有意義でした。よかったら、また呼んでください。今度は懇親会にも参加させてください。

本物の“懇親会女王”クオリティを、お見せしますよ!
ただいま、帰路の新幹線の中から書いております。N700サイコー!電源横のA席サイコー!

と、どうでもいいですね。

さて。今日は朝から「PFP関西ワークショップ」に参加してきました。記念すべき20回です。
午前と午後に2セッションずつ企画され、セッションの最後は全員でのふりかえりです。
なので、ひとりでは全部のセッションに参加できないので、レポートが十分できなくてすいません。

セッションの選択は、他に参加されるみなさんの競争率が高くならないよう、募集人数の多いほうを選択させていただきました。その結果、何度かご一緒したことのある前川さんや、平鍋さんの100回記念講演など、もうよく聞いたお話をまた拝聴する、ということになったのですが、今回はちょっと違う感覚の感想を得ました。これは「気づき」というほどのものではありませんが、自分なりの「進化」だと思ったので書いておきます。

PFを理解する人の共通認識として「モチベーションの向上のためのツール」ということが挙げられます。わたしもこれまではこのツールを「個人」を対象として用いて、「個人」のモチベーションを高めるために有効だと思っていました。そこにあるのは「個々の人は向上したいという思いがある」ということが前提だったと思います。

しかし、最近は人事の仕事などをしていると、そうでもないと思うようになりました。

個人は自分や家族の幸せを追求するのですが、その「幸せの定義」はそれぞれで異なるということ。

例えば、ある人の幸せは「仕事で認められ、ある程度の地位を得ること」かもしれません。その一方で「家族と自分が生活するのに十分な収入を得ることができれば、仕事での地位はそこそこでいい。」と考える人もたくさんいるのです。

これはどちらが正しくて、どちらが間違っているというものではありません。どちらも自分の思う幸せです。

このように、異なる価値観のある人が同じチームで仕事をするとき、モチベーションの定義も同じでいいのでしょうか?
わたしは、モチベーションというのは「個人」が持てなくても、「チーム」にモチベーションが見えていればよいのではないかと思います。

具体的にどのような状態かというと、あるメンバーはどうしてもそのチームの仕事が好きになれない。例えば、本当はwebのような仕事をしたいのに、テストの仕事ばかりやっているようなケースなど。

やらされ感のある人はいるけれど、その人がチームの「お荷物」にならないような仕掛けをする。

例えば、どんなにやらされ感たっぷりで仕事をしていても、少しでも成果が出せているのであれば、それをきちんと褒めること。それも他のメンバーの前で。そうすることで、他のチームメンバーは「あの人も仕事をしているんだな」ということが理解できて、お荷物にはならないでしょう。

以前にも属人性の排除ということに対する考え方を書いています。


このような活動において、個人もモチベーションを高めるきっかけになることもあるでしょうが、わたしが思うもっと強い効果は「個人の状況をチームが受容する」ことだと思うのです。人には感情があり、それに対する波もある。それを否定したり改造したりすることを考えるのではなく、いろんな人がいてもなんとかやっていけるからチームなんだ、という共通理解がPFの中にもあるように、わたしは感じました。

そしてセッション終了後の懇親会では、クリエイトシステムの太田さんから急なご指名でLTまでしてきました。

先日、弊社社長から紹介された動画を紹介しました。



この動画を見て、どのように感じるかはそれぞれの感性かと思います。
わたしが感じたのは、これはプロジェクトそのものなんじゃないかということです。

1個1個の動画は解像度も低く、動きもプロとは違い粗雑なものです。
しかし、これが何枚も集まり、ある1つのものを表現するときに、見る人に強いインパクトを与える。
プロジェクトも、個々の能力は高くなくても、それぞれが全体に対する自分の役割を把握して個々の動作を展開すれば、プロジェクトとしての成功を見出すことができる。

なんてことをLTで伝えてみようと思いました。
いかがでしたでしょうか?

毎回記念イベントにはお声がけいただくPFP関西スタッフのみなさん。そして同じ時間を共有していただいた参加者のみなさん。ありがとうございました。
また次の機会も、呼んでくださいね。ティアラは関西に常設することにしました。

追記:
PFP関西スタッフの西河さんがPSPを使ったLT(?)をされていました。
かの有名なソフト「モンスターハンターポータブル2G」の中の、強いことで知られている「リオレウス」を5分以内に倒す!というLTです。
見事、5分以内に倒しました!

と、わかる人にしかわからないのですが、今度はぜひご一緒にLTさせてください。
10月30日(金)東大安田講堂にて開催された「ワークプレイスラーニング2009」に参加してきました。

ワークプレイスラーニング2009
http://www.educetech.org/wpl2009/index.html

当初の参加上限数は800人だったのですが、盛況につき最終的には申込者が1450人にもなったそうです。おそらく全員はいらっしゃらなかったと思いますが、1000人は軽く超えていると思います。その状況は貼り付けてある動画をご覧ください。

《概要》
このイベントは、企業における人材育成の事例を企業の担当者自らが紹介し、それをアカデミアの代表として4人の教授陣がそれぞれの専門分野の側面から事例からの知見を解説するという内容です。1つの事例はこのような構成で発表されます。

1.ケーススタディ(企業の人材育成担当者による自社事例発表)
2.解説・コメント(4人の先生による事例への解説とコメント)
3.参加者のペアディスカッション(近い席数人で事例に対してディスカッションする)
4.質疑(1.および2.の間に携帯電話で会場から送った質問に答える)

先生方の専門分野は「経営学」「心理学」「社会学」「教育学」とバラエティに富んでいますが、企業の実践においてはそれぞれの知見が均等に参考になるものだと思います。

《事例からの気づき》

個々の事例について細かい気づきはあるのですが、少々長くなりそうなので今回は割愛します。またこれらがプロセス改善と近づくものに昇華したとき、引用したいと思います。

3つの事例それぞれに共通した言葉が「自主性」でした。自分の仕事を自分で決めていく、自分のキャリアを自分で決めていく。そのような場をどうやって作っていくか、ということが事例全てに共通した内容でした。
人材育成とは、企業が牽引して人を「引き上げる」ことではなく、自ら学びたい、育ちたい人に対して如何に適切な環境を提供するか、ということがテーマになってきているのだとわかりました。

わたしは、プロセス改善という取り組みは、人に自主性を提供できるよい教育環境だと思っています。ですから、プロセス改善を教育の機会として企業が利用して、多くの「得」を得て欲しいと思っています。人材教育の核を知り、知見を持ち込むことで、プロセス改善がより価値の高い活動にできそうだと感じました。

《全体に対する気づき》
1)アカデミアの解説が「事例の皮をむく」
よく事例発表で聞かれることが「あれはこの会社だからできたこと」とか「自分の会社では同じことはできない」といった意見です。それは確かですが、事例はそのまま自社に持ち込むことが目的で聴くものではありません。そこから自分たちに置き換えられる何かを見つけることが目的なのです。
しかし、事例発表を聴く機会が多くない方には、このような目的であることを理解すること自体が知識としてないのでしょう。

そこで、事例に対してアカデミアの見地から様々な解説がされることで、事例の核が見える形で提示されます。(各先生方はちゃんと説明用のスライドを準備されていました)

わたしたちIT業界では、コミュニティ活用やカンファレンスの開催が活発なので事例を聴く機会はとても多いので、これらの「電波の受け方」をよく心得ているのだと思います。しかしこのような人材育成担当の方などは、社員を研修に出す機会は多くても、自分が研修を受ける機会は少なく、咀嚼の仕方がよくわからないようなのです。そういう方には「これが核です」という提示までされるこの方法は、カンファレンスの出席者満足度を非常に押し上げるものだと感じました。そして、初参加者にはとても優しい仕組みでもありますね。このホスピタリティはわたしたちもお大いに学ぶべきかと思います。「常連向けイベント」抑止とか。

2)イベントの反芻「リアルタイムドキュメンテーション」
イベントの開始前から終了直前に至るまで、夥しい数の写真と動画が撮影されており、それをイベント最後に5分程度の動画としてまとめられ、会場に流されました。
「リアルタイムドキュメンテーション」自体の詳しい解説は、中原先生のブログをご参照ください。
NAKAHARA-LAB.NET
http://www.nakahara-lab.net/blog/2009/10/2009_10.html



この動画をイベントの最後に見ることで、わたしもイベント全体を自分の中に刷り込むことができたように思います。10時から17時という、とても長い時間のイベントは、最初のほうにあったことがなんとなく薄れてしまったり、最後のほうは疲れもあって見落とすところがあったりと。しかし、それは意識的に記憶できる部分であって、人間の体というのは「無意識」といううまい機能が補ってくれている記憶もあるものです。
それをこのリアルタイムドキュメンテーションが引き出してくれて、意識できる記憶に持ち込んでくれたように感じます。これは大変な作業だと思いますが、どこかで実践できるとおもしろいですね!動画作成好きの方、いかがですか?

ということで、最も多く出没している「IT関連イベント」ではなく、自分の違うレイヤーで様々なことを学ぶことができました。人材育成担当という自分の新しい側面を、少しステップアップさせることのできた、いい機会でした。
「標準は現場が作るもの」という大野耐一の教えがあります。この考えにはメアリーポッペンディーク女史も感銘を受けていました。(Agile2007 資料参照)

じゃあ、実際、できますか?
ここに挑戦しようと思います。

自分たちに既存のプロセスがあったのですが、その考え方だけでは十分ではないプロジェクトがありました。稼働中はある意味「いきあたりばったり」だったと思います。

しかしこのプロジェクトが終わって「あれはあれでいい部分があった」という気づきが出てきました。

ここまでは何度か経験しています。今度はここからが違います。

その気づきを「文書化」をしようと思っています。そして新しい「標準」にしようと。

文書化や標準化という言葉は、現場への新たな「枷」のように受け取られることも少なくありませんが、他者にどう思われようと、自分たちが今必要なのは「文書化と標準化だ」と思えるまで、気づきを掘り下げてきました。

文書化をする意味は「情報の共有」ではなく「外化」だと思っています。自分たちの気づきを文書にすることで、個々の内側に持っている暗黙的な知識を整理するところまでで十分なのです。

「その文書を見れば誰でもプロセスは再現可能である」なんて、ちょっと怪しいと思っています。それは料理を作るのに似ていて、料理本を読めばだれでもその料理が作れるかといえば、そうでもない。ある程度の経験を経た人の作るものと、料理が下手といわれる人の作ったものはどこか違うものです。

標準なんて、現場のメモ書き程度に考えればいい。チームが「これは何だっけ?」と指をさして確認しあえる程度で。

それがないと仕事ができない、というものではないけれど、毎日それをみんなで確認するための文書。この辺が今回の目指すところかな。

大野先生、こんな感じでいかがでしょうか?