昨日、久々に歯の治療に行ってきました。処置歯の詰め物が取れてしまったのです。年末というのもあって、仕事もバタバタ・・。行けずに、昨日、やっと行ってきました。なんとなく、嫌な予感がしていたのです。素人ながら、詰め物の中がちょっと怪しい・・。元の詰め物をそのままかぶせるのでは処置できないことが分かりました。「保険の範囲だとコレですが、こっちの方が良いんですよ・・」と当時お勧めされたのが「金」の詰め物。歯の形にフィットする。長い時間持つのだ・・という先生のご説明どおり、ずいぶん長いこと、その詰め物は取れませんでした。はい、忘れるぐらいずっと前に治療した歯です。20年ぐらい経ってるかもしれません。何箇所か治療してもらいました。この歯科医は実家の近くなので今は通えません。今日行ったのは別の歯科医です。今日も、お決まりの会話になりました。今はセラミックを使うようになっています。今はセラミックが一番。数枚の写真をコンピューターで3次元映像に展開し、そこからセラミックの詰め物を自動生成(?)するとかで、かなり正確に自分の歯の形になるという話を図や写真、模型も見せてくれて説明してくださいました。1つ5万円ぐらいします。あろうことか、今回詰め物が取れたとなりの歯の端っこが、すこーし虫歯になりかかっており、2つ分の歯の金額がかかるとか。計10万!先生の説明は分かりました。「先生、保険が効くやつと、このセラミックの中間どころの詰め物はないんですか?」ああ、これこそエンド・ユーザーの気持ち私の質問はド素人の質問かもしれません。「中間どころ」という曖昧な表現が、いかにも素人っぽいというか、この金額、どうにかならないの?という心情を訴えているわけで。何かに似ている・・と感じたのです。ええ、それは、システム開発時のユーザーさんと開発者の会話です。「それが良いってことは分かったよ。なんでそんなに高いの?」という話なわけです。技術者側に悪意はありません。その時代のより良いものをユーザーさん/患者さんのためにお勧めしているのです。時として、ユーザーは、何か肩透かしを食らったような気分になります。前も高額なものを買った。別の高いものに変えなければならない。このいたちごっこに終わりが無いことは明白でしょう。次の治療日の予約は既に入っています。保険で治療できる所謂「銀歯」にするのか選ばなければなりません。数本まとめて治療しなおしたときの事を思い出しました。その先生の最初の言葉を今でも覚えています。「私は火事の最中に家を建てるようなことはしません。多くの方は歯の磨き方がちゃんと出来ていない。正しい歯磨きの仕方を教わったことがないとその先生はおっしゃるのです。高額な歯の治療をしても、すぐにダメになってしまう・・と。その歯科医では歯ブラシのレッスンから始まります。歯磨きができると合格点がもらえてからやっと治療開始。将来においてお口の中の状態が快適、健全であることが保たれることを目指している姿勢が最初から伝わってきていました。「数本まとめて」でもやってもらおう!と私は決意できたのです。最新の治療ができそうな雰囲気は漂っています。先生の説明は、セラミックの歯をどのように作るのかとか、その仕様、値段・・だけ。私はその治療費にどうしても意識がいきます。これは「お買い物」の意識状態になっているのですね。「私」という人間のパーツである「歯」がどうであると、「私」がハッピーか。前にかかった歯科医の先生は、それを診てくれていたのです。IT業界に置き換えるとどんなことが言えるのでしょう。それを使う「人」が現在から将来に渡ってどのようにハッピーになるのか。そこを考えた上での提案であるかどうかが、ユーザー側にはおのずと伝わるのかもしれません。’10」がサンフランシスコで開かれています。同時に、ギークの皆様向けのこんなイベントも・・。アドミニストレーター。どちらの役割も、人の間に入って日々ストレスと戦っている事、よーくよーく知っています。この両ポジションの方のそばに、話をちゃんと聞いてくれる人が居てくれることを心から望みます。今、あるプロジェクトを進めていく中で、「心が折れない様に支えたい」と言ってくださった方がいました。この一言で、どんなに気持ちが楽になったことでしょう。私も、コーチとして、ITに関わる方々が前を向いて歩いて行けるよう、サポートしていきたい・・。業務改革アプリここしばらく、週1ペースでのミーティングを行っているプロジェクトがあります。ミーティングと言っても、メンバーの一人が栃木在住ですし、各々別の事務所がある身分。使ってのミーティングです。進行が難しかったりします。アジェンダや議事録をオンラインで共有できるものが欲しいなーと思ってググったところ、最初に出てきたのがこちらでした。MindMesiterこれが予想以上の製品で非常に快適に使っています。ちなみに、私の使い方をご紹介すると、こんな感じです。ミーティングの前日までに議題を作成し、参加者全員と共有。マップには、議題の他に、参加者名、当日の議事録を書くブランチ、次のアクションを書くブランチをあらかじめ用意しておきます。後は、当日会議をしながら、議事録のブランチを書き加えていきます。ミーティングの参加者は、皆、マップを見ながら進行しますので(編集内容はリアルタイムで共有者の画面上でも反映されます)、会議室でホワイトボードを見ながら会議をしている雰囲気にかなり近くなります。最後に次のアクションを決めて終了。ミーティング後、PDFに出力して、所定のリポジトリにアップします。マインドマップの良いところは、後から閲覧した時に、文章を1つ1つ追わなくても、当時のミーティングの内容が非常によく思い出せること。それぞれの話のつながりも分かることですね。無料の「ベーシック」プランでは、マップ3つまで使用できます。UIやヘルプはローカライズされていますが、サポートはどうやら英語のみの様です。すると、その点不安に感じられる方がいらっしゃるかもしれませんが、私の問い合わせにはきちんと対応してくれました。1私は社内政治より、コードを書きたかった。ITプロジェクトコミュニケーション「いきなり」なタイトルですが、以前、某企業内で社内SEの様なシステム・アドミニストレーターの様な・・IT関連なんでも屋をしていたころ、私が感じた正直なところです。ある業務に関するシステムを構築する話が持ち上がりました。私は「何でも屋」として各担当部署のヒアリングからスタートすることにしました。ヒアリング・・それは、業務フローを見直すと同時に、「社内政治」をどうまとめあげるかという事でした。いうものの、相手にするのは、みな私より上のポジションにいる人ばかり。平社員の私が、課長、部長クラスを相手になんとかまとめていかなければなりません。このプロジェクトは本当に多くのことを学ばさせてくれました。後になって、人を動かす「コミュニケーション」というキーワードと、当時のプロジェクトが頭の中で結びつきました。その後、ベンダー側での開発を経験しましたが、うまくいくプロジェクトと、何かしら問題があるプロジェクトがありました。これも、キーとなっていたのは対エンドユーザー、またはベンダー内での「コミュニケーション」でした。「CIOの育成」といった言葉をよく聞きます。企業側に素晴らしいCIOが居れば、企業のIT化は格段に進むのでしょうか?私は依然としてコミュニケーションがキーだと思っています。それも、社内の人間でもなく、ベンダー側の人間でもなく、中立な立場で公平にものを見ることの出来る人、コミュニケーションを下支えする人・・。コードを書きたかった私は、あれから随分たくさんのコードを書くことができました。今は、コミュニケーションのプロとして、プロジェクトの進行を支えて行きたいと思っています。ベンダーに問い合わせる前の段階での話し合いのファシリテーション(司会・進行)も承っています。お気軽にお問合せ下さい。ITプロジェクトコーチング前回の記事で、相手の考えていることを「引き出す」質問と、自分たちが知りたいと思って問いかける質問には、違いがあるということに気づいたことを書きました。これにはっきりと気づかされたのは、私のコーチからのフィードバックでした。コーチ・トレーニング・プログラムというのを現在も受講中ですが(1年半で31課程を受講するプログラム)、それ以外にも、周期的に自分のコーチにクライアント役をやってもらい自分のコーチングに対してフィードバックをもらっています。その日は、初めてコーチにクライアント役となってもらい、フィードバックをもらう日でした。実は、この日まで「何か釈然としない、コーチングは本当に機能するのか。」という漠然とした疑問が心の中にあり、少々モチベーションが下がってきていました。次の一言で開眼した気持ちになったのをはっきりと覚えています。私は、吉田さんの質問に答えていただけで、自分の考えを深められなかった。話し手は、考えたことを話してもいますが、自分の言葉を聞きながら、更に考えを深めているのです。その為、相手から何かを引き出そうという事ばかりに注力して、あれこれ質問をとっかえひっかえしていると、相手は考えを深めることが出来ず、引き出せたであろう言葉の前の通過してしまうことになる。私は、答えを引き出したいがために、あれこれ質問するばかりで、相手が何を考えているのか、何を知りたいと思っているのか、どこへ向かおうとしているのかが全く耳に入っていなかったのです。この日から、相手が答えを持っているということを常に意識し、「質問」よりも「聴く」方の能力を上げることに注力するようになりました。行間を読むと言いますが、会話においても言葉の間にある本当の意味をキャッチする必要があるからです。相手に考えてもらう出てきた選択肢をまとめるそしてまた考えてもらうそんな繰り返しを経てエンドユーザーが十分に思考した後に出てきた答え、これはゆるぎない軸になるはずです。コーチングというコミュニケーションにご興味をもたれたら、無料のオリエンテーションをご用意しています。お気軽にお問い合わせフォームよりお問合せ下さい。コーチングシステムを作る側、発注する側、両方を経験した後、コーチという人とのコミュニケーションを専門に行う仕事も始めて、とても強く感じることがあります。それは、エンドユーザーさんから話を聞いて要件を定義していく際、私たちは「自分の聞きたい事を聞いていた」と。言い換えると、「自分の知りたい事を聞くために質問していた」のです。どこもおかしくない・・と思われますか?確かに、私もコーチングを学んでコーチとして仕事を開始するまでは、こんな事には気づきませんでした。ベンダー側が要件定義の際に、最初から自分の聞きたい事を質問していくと何が起こるのでしょう?エンドユーザー側の担当者の方は、その質問に答えます。このどこに問題があると思いますか?要件定義の後、開発に入って「仕様変更」というプログラマーやSEにとって最も聞きたくない話を、私たちはどのくらい聞かされてきたでしょう。「この時、こういいましたよね。「仕様書にはこう書いてあります。言ったの言わないの、あの時はこうだったとか、気が付かなかったとか、忘れていたとか・・いろんな話が飛び交いますが、変更しなくちゃどうにもならないのであれば、それに従うしか道はありません。してこんなに仕様変更は多いのでしょう?ちゃんと考えて進めているはずなのに・・。尚弘さんの講演をお聞きすることができました。古川電工さんで行った人事業務を刷新する大プロジェクトについて等身大で書かれたこちらの書籍は、「どこか別の世界の偉業」ではなく、「当たり前のことを、当たり前でないレベルでやりきる」と文中で関さんが書かれている通り、非常に地道に、丁寧なコミュニケーションを重ねていく様が描かれています。学ぶことが沢山あるこの本を、私は度々読み返していたのですが、講演の終わりの方で関さんがおっしゃられた次の一言が様々な事柄を集約したように感じられ、とても腑に落ちた気持ちでした。僕たちは考えることに専念できた。このプロジェクトは、ケンブリッジ・リサーチさんというコンサルティング会社が入って進められていったのですが、そのファシリテーションがすばらしく、関さんを始め、エンドユーザー企業側のメンバーの方は、とにかく「考えることに専念した」とおっしゃっていました。私は、ITベンダー側でプロジェクトを進めていく際、この点が欠落していたと今、強く感じています。システム構築のために、エンドユーザーから必要な情報を「引き出す」という表現を時々目にします。この「引き出す」とは相手に「考えてもらう」ことに他なりません。コーチングは、まさに相手から「引き出す」コミュニケーション。普通の質問と何が違うのか・・。長くなってしまいますので、次回その点について書こうと思います。「スタッフの本当の力を発揮させる、話しの聞き方」開催しました。コーチングバンク様主催の勉強会で講師をさせていただきました。「スタッフの言動が理解できない本当の理由」開催しました。高知で2つのセミナーの講師をさせていただきます。