海外出張（チェコ、ドイツ）

久々の海外ネタですが今回は社用です。

来週火曜日の午前の便で日本を発ち、フランクフルト経由でチェコのプラハに入ります。この日は移動だけで終わり。翌日に1日打ち合わせして、その次の日には朝の便でフランクフルトに戻ります。翌週の火曜日までフランクフルトでの打ち合わせが続き、水曜日の午後の便で帰国というスケジュール。

チェコに1日しか滞在できないのは非常に残念ですが、フランクフルトで週末を過ごすことになるのでここでプライベートな活動をしようと思います。

ただ問題は出張の準備が全然できてないことですねえ。今日も会社に行ってたのですが、他のトラブル対応などもあってなかなか進まず。帰って来たのは午前2時でしたが、まだやる事が山ほど残っている状況です。

おまけに帰国翌日には研修の発表があり、そっちの資料も作らないといけない。出来る限り明日のうちに進めておかないと！（でもちょっとゆっくり寝たいな・・・）

アーキテクト育成研修

いま会社でアーキテクト育成研修というのを受けている。組み込みソフトウェアの構造設計をやる人材を育成するという研修で、カリキュラムは講義と演習が半分ずつという感じ。3日間の講習＆1日の成果発表の4日間構成だ。

「費用は会社が負担するから受けたい人は言って下さい」という事だったので脊髄反射的に手を挙げたのだが（大阪人なので）、毎回出る課題がかなりヘビーだ。現在担当している業務に落とし込んで構造図を作れとかいう課題なのだが、うちのソフトは巨大で自分の知らない領域もたくさんあるため調べながら書く事になる。この短期間で全部書くのは不可能なのでターゲットを絞って書くわけだが、それでもやっぱり知らないところはたくさんある。

というわけで研修で習った手法を実際の業務に適用するというのは確かに有意義なのだが、そのために調べものが山ほどあってなかなか先に進まないという状況である。先日の日本vsカメルーン戦の最中もずっと構造図を書いてたし、ヨメさんの実家でも内職していた。だいたい要領悪いくせに後先考えずに無謀な挑戦をするというのは昔からの悪いクセだが、おっさんになってくると肉体的にも精神的にもダメージ大である。しかし、ここを乗り越えればグレイトなひろきちになれるはず、ということでがんばってみるかもしれないのでした。

応援、ファンレターは随時募集中です。

今年の取り組み目標

うちの会社では毎年この時期に個人の年間目標設定と上司面談がある。1年のチャレンジ目標を設定し、年度末に効果面談が実施され、そして翌年の給料が決まるという仕組みだ。この4月は大きな組織変更があり前にいた部署は発展的解消ということで消滅した。ということで新しい部署で新しい上司との面談となった。

大筋は合意してもらったのだが、一点だけ「去年と比較して今年はこれをやります、という新しい何かが欲しいな」と言われ、しばし考えた結果次のことを追加することにした。

「各開発要件について設計視点で検討し、設計リスクの低い仕様に落とし込む」

つまり、実装がシンプルになるような仕様を考えることで品質リスクを低減しなおかつ開発工数を減らすのが狙いだ。人件費削減、ワークライフバランスが求められる中での「働き方革新」の取り組みだ。上司も気に入ってくれた。ここで注意が必要なのは、開発者よがりの仕様になってはいけないということ。あくまでもユーザーの使い勝手を考えながらも、設計も簡単になるように仕様を決めるというのがポイント。相反するように思うかもしれませんが、そんな事も無いのですよ。先日パイロット的にやってみて実証済み。やってみせます。

ちなみに、今年から目標設定の帳票に「働き方革新」という項目が新設された。ここにはまた別の取り組みを書いた。

「リーダー業務の見直しと役割分担の最適化で業務量を削減する」

オーバーワークでてんてこ舞いになっているリーダーの業務にメスを入れ、やる事とやらない事を明確にし、やり方を変え、仕事量を減らし、早く帰るというすばらしい取り組みなのだ。4月からずっと検討を進めて来て、明日いよいよ上司に発表する予定。

今年はなかなか面白い年になりそうである。発展的解消バンザイ。

Yes-Butの法則

法則なんて書くとタイソウだが、今日はコミュニケーションについて書いてみようと思う。

先週から今週にかけてある品質問題に対する再発防止策検討会なるものが数回行われている。それに向けてわがソフト開発部署内においても事前検討会が何度か実施された。基本的にはひろきちを含めた3人のソフト技術者があーだこーだと議論する訳だが、ある程度まとまったところで上司へ報告する事になる。そしてその上司への報告の場でA氏と上司がバトルを始めたのだ。

バトルと言っても当然殴り合いを始める訳ではなくちょっとはげしい言い合い程度のものなのだが、これがディベートとかディスカッションの類いではなく単なる自己主張の応酬なのだ。お互い相手の言った事に対して「そうじゃなくて」と自分の意見でもって反論するのである。その言葉の裏には「こいつ、わかってないな」という意識がある。お互いがお互いの事を否定しながら自分の意見を言い合っているだけなので、ボルテージはどんどん上がって行くのに一向に話は収束方向に向かわない。

ひろきちは不毛な時間を過ごすのが嫌なので、しばらくこの自己主張の嵐に巻き込まれているだけですっかり気持ちが沈んでしまった。なので、上司が興奮して言い放った後にこう言ってみた。

「いや、全くその通りです」

すると何が起こったか。

「そうやろ」

と言って、すっかり静かになったのだ。上司が落ち着きを取り戻したところで、

「で、われわれの考えとしましては、こういった事も原因の一つであり（以下省略）」

とA氏の反論(＝われわれの意見)を説明した。すると、

「ま、確かにそれもあるな」

と一定の理解を示したのだ。

この後も何度かバトルに発展しそうになったが、その度に

「分かります、そうだと思います」

と言うと沸騰した鍋に水を差した時のようにスーッと穏やかになるのだ。

Yes-Butの法則。

それは相手の意見を認めた上で自分の良い分を言うという、一見ごく当たり前の事を言っているに過ぎない。しかし相手の意見を受け入れずに自分の意見を投げ返すシーンに何度出会った事か。言うは易し行うは難し、である。

とそんな訳で、議論が一向に前に進まないとき、自分の意見が全く理解されていないと感じたときはYes-Butの法則を実践してみる事をおすすめする。

「そうですね」

は

「私たちの考えは・・・」

を繋ぐ接続詞。

では、ごきげんよう。

満足な一日

今日は連休中にも関わらず会社に行ってましたが、普段は余裕がなくて
できなかったことがたくさん出来たので満足です。

そんなわけで、お気に入りのYouTubeを貼っておきます。



この声、欲しい。

5連休ですが

世間は5連休ですが、ひろきちは月曜日は会社に行きます。いわゆる休日出勤です。

まだそんなに大忙しな状況ではないのですが、今年はやらないといけないことが多過ぎて、やりたい事が全然できてないので休日にやることにしたのです。メンバーたちには「使ってみろ」と言っておきながら使ったことがないテストツールを使ってみるとか、新しく導入した開発マシンをチューニングするとか、出来てないのに出来たことにしているドキュメントの更新とか。

注）やらないといけないこととは、中身はどうであれ一応やったことにしないといけない物事のことで、やりたい事とはそれをちゃんと価値あるものに仕上げる作業や、さらに仕事の質を上げるための作業のことです。なぜ後者が「やらなければならないこと」に入らずに「やりたいこと」に入っているかというところはまあいろいろあるので聞かないで下さい。

ひろきちチームのメンバーには出勤しろとかは行ってないし、そんなやばい状態（スケジュール遅れまくってるとか）ではないのですが、

「出るなという訳でないなら出させて下さい」

と3名が自ら名乗り出るという事態に。

ん～熱心である。そこまでせんでもいいのに。しかしやる気のある者にやるなとは言えないので、まあどうぞということにしました。

でも分かります。これは納期に対する恐怖です。期日までに絶対終わらせなければいけないというプレッシャーが、早いうちからやれるだけやっておきたいという気持ちにさせるのです。平気で遅れる奴がたくさんいる中で大変感心な心構えではあるのですが、プロとして限られた時間でやりきるという姿勢も見せて欲しいなとも思います。

同じように休日出勤するお前が言うな、ではありますが。

オフサイト・ミーティング

昨日、オフサイト・ミーティングというのをひろきちが発起人となって開催しました。たいそうなネーミングですが、職場のリーダークラスの人を集めて、酒を飲みながら懇談しましょうというものです。

19:30開始にちょっと遅れてまずは4人でスタート。間もなく一人が駆けつけて、5人で飲み会が始まりました。さらに1時間ほど遅れてもう一人参加、最後に22時過ぎに最後の一人が合流しました。

そもそもひろきちがこういう会を開こうと思ったのは、職場ではなかなか今後の体制のこととか人材育成のこととか、要するに将来に向けてどうして行こうかというような話をじっくりする機会もないので、職場を離れてビールでも飲みながらざっくばらんに話せればいいなと思ったからです。

実際やってみると、仕事に関係ない話がほとんどで(隣に座ったK氏はシモネタ連発でした)、今後のことなんかもちょっとは話したのですが、まあ普通～の飲み会という感じでした。でも「こうやって集まるのって初めてなんちゃう？」とこういう機会を持てたことにはみんな満足しているようでした。もちろん飲み会は年に数回ありますが、「現場リーダーたちの集い」という場はこれまでなかったそうです。ひろきちは別の部署から異動して来た人ということもあり、今の部署の人たちにとっては普段からユニークなキャラクターに映っているようですが、でもまあ今回のことも含めて割と好評のようでよかったです。

ひろきち的にはもうちょっと実のある話をしたかったところですが、飲む時は楽しみたいという感じなんでしょうかね。やっぱり職場のことは職場できっちり時間を取って話した方がいいかなと思いました。酒を飲みながらやる場合はトピックを決めておくか、人間関係修復などに利用するのがよいのかも。

しかし非リーダー系社員でいろいろ言いたいことがある人が何人かいるので、今度は大ボスのI氏だけ連れてオフサイトミーティング2をやろうと目論でます。

アジャイル開発についての論争

Info QにSpolsky vs Uncle Bobという記事がUPされました。アジャイル開発に関する熱い論争です。

面白かったので訳してみます（適当ですが）。

**********

ここ何週間か、Joel SpolskyとUncle Bobの愛称で知られるRobert C Martinの間である論争が続いている。事の発端はJeff AtwoodとJoel Spolskyが提供する"Stack Overflow podcast"の第38回目の配信で、Joelが自身の提唱する"The Joel Test:より良いコードのための12のステップ"の13個目のステップにユニットテストを追加するようたびたび提案を受けているが、それには同意できないと発言したことだった。Joelが言うには、

「テスト駆動開発に関する議論があるよね、・・・なんでもかんでもユニットテストをするべきかってやつ、・・・たくさんの人が僕の書いた"The Joel Test"を読んで、こう言うんだよ『13個目のステップとしてユニットテストを加えるべきだ、自分の書いたコードに対する100%のユニットテストを実施するべき』ってね。これを聞くと、必ずしも必要でないことにちょっと固執しすぎているように感じるんだよね。ほら、アジャイルの思想って今必要でないことはするな、ってことじゃない。必要に応じてやれって。時間をかけてなんでもかんでも自動的にテストしたって、役に立たないんじゃないかって感じるんだよ」

「もし本当に100%のユニットテストやったとしたら、そこにはいくつかの問題が生じると思う。ひとつは、テスト仕様書を書くのに膨大な時間を費やすということ。品質を改善するためにそんなコストをかけなくてもいいにもかかわらず。いや、もちろん品質は改善するかもしれないよ。自信を持って副作用の無い修正ができるかもしれないし。でも、それだけだよね。」

「でも僕が発見したユニットテストの本当の問題は、プログラムが進化していくにしたがってコードに施される修正がある一定の割合でテスト仕様をだめにしていくってことなんだ。コードを修正するとするだろ、そうするとユニットテストの10%はもう役に立たないんだよ。だって、デザインを変更したら、例えば、メニューを別の場所に移動したら、そのメニューに関連していたすべてのもの、そしてメニュー自身はもう別のところにある。そうすると関連テストはすべてもう台無し。で、新しいコードに即してもう一回テストを書き直さなきゃならない。」

議論はUncle Bobの"SOLID principles of object-oriented design"へと移っていく。

「あれはオブジェクト指向設計のことだろ、なのに彼らはアジャイルだって言う。ぜんっぜん違うし。あれはクラスをどう設計するか、どう動くべきかについての哲学じゃないか。それにあれを聞いてると、ぶっちゃけろくにコードも書いたことのない輩の思い付きによる、極めて官僚的なプログラミング手法に聞こえるんだよね」

しかしJeffとJoelはUncle Bobの経験とアジャイルとの関係について予習不足だった。Uncle Bobはアジャイルマニフェストへと発展した会議の発起人であり、JeffとJoelが生まれた頃からずっとコードを書き続けているのだ。また、彼は公にも膨大な量のコードを書いている。そしてBobはpodcastでの発言に関して言及した。

「僕はTDDの信奉者じゃない。採用する価値のある一つのやり方だと考えている。すべてのテストを最初に書くわけじゃないし、コードを書いた後に書いたほうが都合がいい場合もある。価値が無ければテストをまったく書かない場合さえある。でもそれは例外だ。ほとんどのケースでは最初にテストを書く。（そしてJoel、これは時間の無駄なんかじゃないんだよ）」


また、Bobは"機敏さ"についてもJoelの意見を覆した。

「Joelは"SOLID principle"はアジャイルじゃないと言った。（ため息）。みんな自分はアジャイルという言葉が何を意味するか知っていると思っているが、"アジャイル"という名のついた会議を招集したのはこの僕だ。僕はアジャイル開発という言葉が生まれてからずっとアジャイルについて書いてるんだよ。僕は何がアジャイルで、何がアジャイルじゃないか知ってるつもりだ。だからこの点で僕にはJoelの意見を却下する権限があると思っている。」

コードを変更した場合、だいたいテストの10%がダメになるというJoelの経験について、Uncle Bobは書く。

「Joelはさらにテストのもろさ、つまりコードを変更したらテストのいくつかは自然に崩壊するということについて不満を言っている。Joelは10%という数値を出している。お笑いだ。これはJoelがTDDについて表面的に理解する以上のことをしてこなかったことを示している（ビジネスガリ勉の失敗の典型だ）。もし君が一つの修正をしたがためにテストの10%がダメになるのであれば、職を変えたほうがいい。テストの設計というのはソフトウェアの他の設計と同じで、いかに結合性を弱めるかということなんだよ。」

議論が続く中、Jeffは"The Ferengi Programmer"という記事を自身のブログにアップした。そこで彼は、"SOLID principles"が表面的には問題がないことは認めるが、規則に強く依存することには危険が伴うのだと言った。

「ルール、ガイドライン、思想は経験によって醸成された宝石であり、それらは研究され尊重されるべきものだ。しかし、それらをもって自分たちの仕事について批判的に考えることの代用にすることは出来ない。」

Jeffの書いたことに議論の余地はない。自身の行動について批判的に考えることなしに良いソフトウェアは生まれないし、本やガイドライン、または手法などについて書いている人はたいてい、自分の考えの本当の意味を理解せずただ盲目的にそのアドバイスに従ってくる人がいるというリスクがあることを知っているし、そしてそれを回避することが簡単なことではないということも理解している。これらはすべてドレイファスの技能獲得モデルに尽きる。彼らがアドバイスを読んだとき、その技能のどのレベルにまで到達したのか、ということなのだ。Jeffのアドバイスに従えば、あるスキルに関してドレイファスの尺度で言うところのAdvanced BeginnerあるいはProficientからCompetentレベルへ移動したいかどうかはあなた自身が決めることだ、ということだ。その典型的な移動はあなた自身が意図的に起こさなければならないもので、年が過ぎるに従って自然に起こりうるものではないと考えられている。

**********

長いのでここまで。

この後さらに論争があり、最終的に3人はいくつかの点で合意します。そのあたりは上のリンクで確認してください。

いやあしかし、アツいなこの人たち。基本的にソフトウェアを愛してるというのは伝わってきますが、アメリカ人ってやっぱり議論好きなんでしょうか？

おかげで参考になりましたけどね。

XP祭り関西2009 もうちょっとだけ報告

さて、XP祭り関西2009についてもう少しだけ感想を書いておこうと思います。

今回の感想を一言でいうと、「視覚効果」。視覚情報が人間の認知に与える効果を上手く利用しているなと思った。いくつか例を挙げてみます。

●スライド
　普段会社なんかで目にするようなグラフや文字だらけの、パッと見て何が書いてあるか分からないようなものではなく、大きな文字とイメージ、写真などをふんだんに用いて楽しくかつ分かりやすいスライドが多かった。例えば文字の場合は5～15文字程度がスライドいっぱいに書かれています。それより多くの文字情報をスライドに出したい場合は、例えば30文字を15秒間表示するのではなく、10文字ずつ3枚のスライドに分けてそれらを5秒ずつ表示する、というような感じ。非常に理解しやすい。グラフはあまり出て来ませんでしたが、出る時は大きくて分かりやすいものがドンと。これぞマルチモーダル・コミュニケーションの好例です。いいものを見せてもらいました。

追記　木下さんのスライドを発見。
追記2　木下さんその2。
追記３　平鍋さんのスライドゲット！

●絵はがきをアイコンに
　平鍋さんの講演の中で紹介されていたのですが、Agile 2008の確かUser Experience Stageの案内板だったと思うのですが、プログラムの各セッションのところに絵はがきが貼ってあったそうです。User Experience Stageのセッションに参加する人は受け付けで自分が参加するセッションの絵はがきが渡されて、会場に行くと案内板に同じ絵はがきが貼ってあるので「あ、ここだ」と分かるというもの。つまり絵はがきをアイコンに使って、参加者に「ここですよ」と知らせる仕組みなのです。ん～これはナイスだ。UX（ユーザ・エクスペリエンス）の分野で最近Agileが認知されていて（Water Fall開発ではいいUXは提供できない！と言われている）、UXに携わる人の参加が増えているためだとのこと。

●小道具
　タスクかんばん、マインドマップなどがソフト開発では有用だというのは以前から認識していたのですが、今回初めてバグレゴという言葉を聞いて、何じゃそれはと帰って来てから調べました。要するにLEGOを使ってバグを管理するという試みだそうですが、こちらにスライドがありました。必ずしも成功という訳でもなかったようですが、今後につながる意義のある取り組みなのではないでしょうか？これをヒントにまた新しいツールが登場するかもしれません。あと、べつやくメソッドやTRICHORDという新しいツールにも出会いました。TRICHORDはまさにひろきちが求めていたツール。ここ最近の情報セキュリティの厳しさから、タスクかんばんが職場で禁止されてしまい、プロジェクト管理をどうやっていこうか悩んでいたところでした。明日さっそく試用してみようと思います。

●視覚情報による思わぬ副作用
　クリエイトシステムの太田さんがLT（ライトニングトーク）で紹介したToDo管理ツールですが、プレゼンがおもしろ過ぎて何の話だったか忘れてしまいそうになりました。5分の発表なのですが、その約7割はドッカンドッカンにウケてて、ひろきちも「この人相変わらずおもしろいなー」と笑いながら見ていたのですが、えーと、何の話だっけ、と本題を忘れそうになりました。たぶん混乱したのは、某有名テレビCMのおっさんのアップが何度も出て来たことで、あまりのインパクトの強さにビジュアルイメージの方が先行してしまい、言語情報の方が吹っ飛んでしまったのだと思います。よくテレビCM自体はよく覚えているのに何のCMか思い出せないことがあるという、あれと同じだと思います。マルチモーダル・インタフェースの記事で「人同士のコミュニケーションにおけるノンバーバルな要素が占める割合は90%以上」と書きましたが、バランスがとても重要だということですね。いや、でもおっさんの顔を除けば、かなり秀逸なプレゼンだったと思います。第一、あのプレゼンを見た人は絶対太田さんのことは忘れないと思います。

このように、視覚効果について深く考えさせられる今回の祭りでした。この他、韓国のLG電子ではアジャイルが浸透していてSONYはまだまだ（Agile 2008でのSONY社員とLG社員の情報から）という話は「やはりそうか」という感じでした。最近韓国勢がんばってるんですよね。ヨーロッパなんかでは日本メーカーはまったく韓国メーカーには歯が立たない状況らしいです。色んなところで少しずつ韓国が先行しつつあるのでしょう。日本メーカーもがんばらねば。

他にも初めて聞いたツールや概念など多数あったので、少しずつ調べて、また面白いのがあれば紹介したいと思います。

XP祭り関西2009に行って来ました

今日はXP祭り関西2009に行って来ました。伊丹市のラスタホールというところまではるばる行って、塚口の「居酒屋万」で懇親会。さっき帰って来て一杯やり直してるところです。

（注）XPというのはExtreme Programmingのことでソフトウェア開発手法の一つです。特に要件が途中で何度も変わるような不安定なプロジェクトにおいて有効と言われ、注目されています。今日は祭りということで、この分野で活躍されている方々の講演やワークショップが行われたのでした。

平鍋健児さんの基調講演では昨年8月にカナダのトロントで開かれたAgile 2008について、日本勢の活躍ぶりを中心に報告がありました。日本は欧米人にとって今でも東洋の離れ小島で、遠い存在らしい。しかし科学技術やトヨタのカンバン方式などのマネージメント手法に関しては注目度が高く、それらをソフトウェアにおけるAgile開発にどう活かしていくかというネタはかなりウケるんだそうです。平鍋さんの次に登場した永和システムマネジメントの木下さんも同じくAgile2008のついて話されてました。

午後は講演と同時開催のワークショップが2つあり、そのうちのひとつの「ファシリテーション入門」に参加して来ました。ファシリテーションはPFPのワークショップなどには何度か参加してるのですが、今回もいつくかネタを仕入れたのでまた職場で活用したいと思います。

今日はひろきちの高校時代の同級生も一緒に行くはずだったのですが、急遽出張でフィリピンまで行くことになってしまい不参加。「またレポートするわ」とは言ったものの、こういうのはやっぱり参加してナンボですわ。言葉では説明できかねます。

また後日メモを見ながらちょいちょいアップしますが、とりあえず今日はこの辺で。

2009/1/25
　祭りの記事追加しました

「雅楽型」のプロジェクト

「PMのためのヒューマンスキル」研修のレポートが滞っているのですが、テキストを友達に貸してしまったのでもうしばらく更新できません。代わりと言っては何ですが、その時の講師がPM学会のカンファレンスで発表すると言っていた論文からちょっとネタを拝借して書いてみます。

論文のタイトルは"Gagaku (Japanese traditional court music) type Project team building vs Orchestra type Project team building"。日本の雅楽とオーケストラを比較しながら「雅楽型」プロジェクトの有効性について考察していくというものです。

雅楽ではオーケストラにおける指揮者のようなリーダーがいなくてもそれぞれの奏者はちゃんと他の奏者と調和しながら演奏することができます。ここからヒントを得て、一人のマネージャが強力にメンバーを引っ張って行く「オーケストラ型」ではなく、一人一人りが全体における自分の役割を常に理解しながら進める「雅楽型」のプロジェクトチームというのが、今後のプロジェクト管理手法として有効なのではないか、という提案をしているわけです。「雅楽型」ではそれぞれの役割の隙間に生じる「グレーゾーン」を適切な人が埋めるという協力体制を築くことが可能になるので、問題を現場レベルで解決することができる。そしてリーダーは「指揮者」ではなく、あくまでチームの一員として役割を果たす、とこういう訳です。

この論文の中にひとつ面白いトリビアがありました。それは「打ち合わせ」という言葉についてなのですが、もともと雅楽の言葉でリズム合わせのことだったそうです。インターネットで調べてみると、雅楽では管楽器、弦楽器、打楽器などの楽器が使われるのですが、それらのリズムを合わせるために「打ち合わせ」を行っていたということでした。これが転じて「物事が上手く合うようにする」という意味になり、さらに転じて現在使われているような意味になったということです。へえ～。どうやら現在の日本の組織はそもそも「雅楽型」がそのベースになっているようですね。

ソフトウェア業界ではすでに一人のリーダーが開発全体を引っ張っていくスタイルは破綻をきたしているので、「雅楽型」を新しいプロジェクトマネジメント手法として導入していくのは意義ある取り組みかもしれません。でも外国人にも同じことが出来るかと言うとかなり疑問ですね。「雅楽型」で重要になるのはあくまでも「全体の中の個人」であり、いってみれば「頑丈な歯車」です。個人の能力はあくまでも組織のために発揮されるべきで、各メンバーの調和が大事なのです。日本人は幼稚園児の頃からこういった組織内でどう振舞うべきかを叩き込まれているので、組織の一構成員として振舞うのは割りと得意です。でも個人が尊重され、「規律」や「協調性」、「調和」といったことを徹底的に叩き込まれていない外国人はどうでしょうねえ。ふだん外国人と一緒に仕事をしていて、やつらに出来るとはちょっと思えませんねえ。

逆に日本の組織では個人を殺し過ぎることで弊害も発生していると思います。付き合い残業とか、もたれあいとかもそうですが、これからの「雅楽型」においてはそういった非合理な習慣を改善していくことも重要だと思います。

マルチモーダル・インタフェース

マルチモーダル・インタフェースという言葉があります。modalityとは知覚を意味する言葉で、これが複数あるインタフェースという意味です。つまり視覚・聴覚・触覚など複数の知覚チャンネルを利用したインタフェースのことを指しています。

人間対人間の場合、例えば視線や身振り手振りなどの言葉以外の要素がコミュニケーションにおいて重要な役割を担っていて（これをノンバーバルコミュニケーションと言います）、実は人とのコミュニケーションにおいて90％を占めるとも言われています。これをコンピュータなどのヒューマン・インタフェースへ応用することでユーザビリティ（使い勝手）を向上しようというのがマルチモーダル・インタフェースの狙いです。

とは言え、人と人とのコミュニケーションにおけるノンバーバルな表現というのは人間には理解可能でもコンピュータに理解させるのは非常に難しい。"察する"とか"汲み取る"とか、あるいは"行間を読む"などという「情報の裏に隠された意味」を理解できる機械は今のところありません。なので機械と人とのコミュニケーションの場合は"サイン"に近いものになってしまうのですが、これを取り入れた身ぶり手ぶりテレビというのが去年発表されました。



機械には"察する"能力がないので、例えば誰かとテレビを見ながら話をしている時に何か身ぶり手ぶりをした場合にこれをテレビへの指示だと誤解してしまう場合があります。これを避けるためにはサインをある程度定型化しなければなりません。例えば画面をスクロールさせる場合は、人差し指を軽く上下に振るというのではなく、手のひらを向けて上から下へ10cm以上移動し、1秒以上間隔をあけてからまた上から下へ、という面倒くさいことをしなければならないわけです。（日立製作所のこの身ぶり手ぶりテレビの場合は「片手を上げて軽く振る」という動作を認識開始のキーとして、一定時間は人からの指示しか受け付けないという方法で“混線”を防ぐ、とありますが「片手を上げて軽く振る」のような決して特殊でない動作を開始のトリガーにしてしまうと誤動作する可能性が高いでしょう）

そして結局は人間が機械に合わせて何らかの操作を学習しなければならなくなるわけで、こうなってくると本末転倒です。ユーザビリティの原則は人間の負担を軽減することであり、そのためには学習が容易であり、新たに学習しなければならないことが少ないことが求められます（年配の女性がビデオでの録画の仕方をいつまでたっても覚えられないのは、その操作方法が分かりにくく記憶しにくいためです）。そういう意味では"身ぶり手ぶりテレビ"のような現在のマルチモーダル・インタフェースは興味深いものではあるけれども人間にとっての使い勝手を向上することは期待できそうにありません。しかし決して今のテレビやパソコンのままでいいという事にはならないので、マルチモーダル・インタフェースの取り組みは続けていかなければいけません。ただし、「使い勝手を向上する」という目的を見失わないことが重要ですね。

と、デジタル家電のヒューマンインタフェースを設計する立場としてそんなことを考えたりするわけです。

※今年からはこういう仕事に関係する専門的な話題もメモ代わりに書いていこうと思っています

PMのためのヒューマンスキル

先日、会社の研修センターで「PMのためのヒューマンスキル」という研修を受けました。本当は別の研修を受けたかったんですが、

「そういう勉強は個人でやれ」

と却下されたので（ケチ！）仕方なくこの研修に変更。（しかも予算がないので「別に無理に受けんでもええぞ」と言われながら無理矢理申請）

ところが実際受けてみるとこれがなかなかよかった。PM＝プロジェクトマネージャが身につけておくべきスキルのうち特にヒューマンスキルに焦点を当てたもので、2日間の研修でした。

それぞれのスキルは奥が深くとても2日間でマスターできるようなものではないのですが、プロジェクトマネージメントに必要なスキルの概要を理解することができるので、今後必要に応じてピックアップして掘り下げるということができます。まずはどんな入口があるかを知るということは大事なことです。

というわけで、復習をかねて要点をメモしておきます。

●プロジェクトとプロジェクトマネジメント

ふだんプロジェクトという言葉を何気に使っているが、その定義は一体何だろう。PMBOK（ピンボックと発音する）によれば、

「独自の成果物、サービスもしくは所産を創造するために実施される有期的な業務」

であり、ISO10006によれば、

「一連の調整され管理された、開始日と終了日のある活動からなり、時間、コストおよび経営資源の制約を含む特定の要求事項に適合する目標を達成するために実施する特有のプロセス」

である。またP2Mでは、

「特定使命を受けて、始まりと終わりのある特定期間に、資源、状況などの特定の制約条件のもとで達成を目指す、将来に向けた価値創造事業」

と定義されている。なんだか難しい書き方だが要するに、

「ある目的を達成するために、様々な制約条件のもと一定期間活動すること」

と言い換えていいようだ。

そしてプロジェクトマネジメントとはプロジェクトを成功させるために行われる活動のことであり、知識、スキル、ツールおよび技法を適用しながらプロジェクトを管理していくことと言える。

PMBOKでは8つのマネジメント項目とそれらを統合的に管理する「統合マネジメント」を合わせた9つの知識エリアを定義し、プロジェクトを統合的に管理するためのガイドラインを定めている。

[8つのマネジメント項目]
1. スコープ（開発の目的とその範囲）
2. タイムスケジュール
3. コスト管理
4. 品質管理
5. 人的リソースの管理
6. コミュニケーション
7. リスク管理
8. 調達管理


PMに求められるスキルとはこれらのマネジメント項目を統合的に管理するためのスキルなのである。

つづく。

次回はプロジェクトマネージャのスキルについて

PFP関西ワークショップ＃15 参加報告

8/22（金）にPFP関西ワークショップ＃15に参加してきました。

PFPとはProject Facilitation Project＝プロジェクトファシリテーションを推進する会のことで、今回はPFP関西地区の第15回目のワークショップへの参加です。

PFPとは
　→http://projectfacilitationproject.go2.jp/

PFとは
　→http://www.objectclub.jp/community/pf/

PFP関西によるワークショップ#15のレポートは
　→http://projectfacilitationproject.go2.jp/wiki/index.php?%B4%D8%C0%BE%A5%EF%A1%BC%A5%AF%A5%B7%A5%E7%A5%C3%A5%D7%A1%F415

今回のタイトルは「チームビルディング入門」で、アイスブレイクを中心にいろいろ使えるツールを紹介するということだったのですが・・・

いやいや、これは既存の組織でやってもぜんぜんOKでしょう。

いくつかピックアップしてみます。

●聴き合う

1)2人ずつペアになる
2)聞き手と話し手を決める
3)話し手は、以下のトピックから話しやすいものを選び、3分間ひたすら
自分の考えを語る。聴き手は、余計なことを言わずに、ひたすらじっくり聴く。

　「小学校の英語教育」「ゆとり教育」「北京オリンピック」「星野ジャパン」
　「毒入りギョーザ」「食品偽装　一連の事件」「社会保険壊滅」「消費税」
　「プロジェクトリーダーの心構え」「職場でうつ病増加？」「今年の阪神」
　「崖の上のポニョ」「1時間あったら本を読むか、新聞を読むか」

4)終わったら、聴き手は、話し手の話した内容を要約する。
5)交代して同じことをやる

3分間もひたすら語るという経験もあまりありませんが、3分間ひたすら語るのを聞くというのもまあない経験。

さらにトピックをもっと身近なものに変えて、自分の部署やプロジェクトでやってみるのもデンジャラスでおもしろそう。たとえば、

　「人材育成について」「プロジェクトのあるべき姿」「リーダーのあるべき姿」
　「自己実現について」「自分にとっての成功とは」「自分にとっての仕事とは」
　「派遣法について」

おもいっきり共感できないケースも出てきそうで怖いが、それ以上に面白そうです。一回やってみたい。

●「それはいい！」

1.5～6人でグループになる
　椅子を丸く並べて向きあって座る
2.一人リーダーを決める
3.リーダー以外の人は、普段のプロジェクトで困っていることを思い浮かべ、
　その問題を一人ずつリーダーに訴える
　例）「大変です！また○○君が遅刻しました」
4.リーダーは間髪いれずに「それはいい！」と返す。
　続けて何か一言、即興で付け加える
　例）「それはいい！彼抜きで話し合っておきたいことがあったんだ」

これは実際にやってみないと実感がないと思うけど、どんなに悪いことでもとにかく「それはいい！」と肯定することによって思考が前向きになります。

例えば、突然サーバーが落ちたことに関して、「それはいい！ちょうどシステムを停止してやりたい作業があったんだ」と返すと、予期せずサーバーがダウンして明らかに作業に悪影響が出ていたとしても、それを逆に利用できたというポジティブな感情が残ります。人間は気分や雰囲気に左右されがちなので、常に物事を前向きに捉えるように訓練することで、プロジェクトが難航した時に遭難してしまうのを回避できると思います。ポジティブに考えることの威力を体験できました。


●私らしさ

1.３～４人でグループになる
　一人ずつA4の白紙とペンを手に取る
2.「私は○○○な×××である」という形の自己紹介文を3つ考えて紙に書き出す。
3.それを順番に紹介する
　一人終わるたびに残りのメンバーが「あなたってこんな感じの人だね」と
　「その人らしさ」を表現するコメントを返してあげる

これは相手に自分のことを知ってもらうというより、逆に自己分析に使えそう。やってみたらわかりますが、短い時間で自己紹介文を3つも出すのはなかなか難しい。普段自分自身がどういう人間なのかなんて考える習慣がないので当たり前だけど、やってみるとあまりに分かってないのでちょっといかんなあと。

文章にするとまあそれなりなんですが、実際にやってみると面白いんですよ。こういうのは案ずるより産むが易しと言うか百聞は一見にしかずというか、やってみるに限る。

別にエンジニアの集まりじゃなくて、いろんな職業の人もいるので仕事をうまく回したいとか、コミュニケーションをうまくできるようにするにはどうしたらいいかと考えている人は参加してみてはどうでしょうか。ひろきちも毎回参加しようと思ってます。

認知科学とユーザビリティ

少し前から認知科学といわれる分野についていろいろと調べています。というのも、いま仕事でデジタルAV機器のユーザーインタフェースの設計をやっていて、より使いやすく、誰でも簡単に使えるようにするにはどうしたらいいかという問題に日々直面しているからです。

ビデオの録画の仕方が分からないのはオカンが機械音痴だから、ということで放置されるような傾向がありますが、やはり技術が進歩するに従って機械はより便利にならなければいけないと思うのです。機械が使う人を選んでいて何がユビキタスだ、と思うのです。

D.A. ノーマンの「誰のためのデザイン？」という本で認知科学という学際的領域の研究分野があることを知りました。

誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書) ドナルド・A. ノーマン,D.A. ノーマン 新曜社 このアイテムの詳細を見る

認知科学は心理学から人工知能、脳科学、哲学などかなり広い領域にわたっているのですが、この分野について学ぶことはユーザビリティの改善に大いに役立つだろうと思います。で、いまその手の本を読み漁っているわけです。

中でも、アフォーダンスという概念を理解してそれを応用することはとても有用だと思います。佐々木正人氏の「知覚はおわらない」にはアフォーダンスを理解する上で助けになるであろう多くの例が登場します。

知覚はおわらない―アフォーダンスへの招待 佐々木 正人 青土社 このアイテムの詳細を見る

失明した人が何を頼りに町の中を歩いて目的地に到達するのか、両足を失った人がどのようにして義足を自分のものにしていくのか。こうした例が、普段われわれが当たり前のように利用していて気づかないでいるアフォーダンスというものを理解する助けになります。

そしてアフォーダンスを理解し、制約や対応付けなどとうまく組み合わせて応用することで、誰でも簡単に使える便利な機器を実現することが出来るのではないかと期待しています。そうすればユビキタスというものがもっと身近になりますよね。

で、勢い余って「ヒューマンインタフェース学会」というのにも入会しました。年会費を１万円も払うのですが、きっと有用な情報が手に入るだろうと思っています。だめだったら退会すればいいだけのことです。まずはやってみましょうということで。シンポジウムに参加する場合は別途参加費が必要だったり、書籍代なども含めて結構な投資になるのでちゃんと回収できるようしっかり勉強したいと思います。