発見コーチ このページをアンテナに追加 RSSフィード

2016-12-02 そろそろ対話もしくは傾聴について聴きあってみようか改め、インタビ このエントリーを含むブックマーク

ガオリュウです。

2016年アドベントカレンダーが始まりましたね。

今年は3つのテーマで登録させてもらいましたが、今日は「インタビューしあう」Advent Calendar 2016の2日目です。

1日目のたけのしたさんとは知り合いで、この「インタビューしあう」という試みに共感して、私も数人にインタビューさせてもらいましたし、私自身についてもインタビューしてもらいました。今回は自分がインタビューされた時のことを書きます。

「インタビューしあう」

 テーマ:学びについて

 聞き手:大首領

 話し手:ガオリュウ

 時間:15分

 場所:シェアオフィス

首領さんとはとあるIT仮面ライダー部なるもので知り合い、そこから私が主催する場に何度か足を運んでいただいているありがたい方でして、普段は私がインタビューする側だったりファシリテーションする側なので、インタビューされること自体がすごく新鮮でした。文字で起こすかもと思って録音したのですが、後で聞いたら、自分の声が高くなっていて、完全によそ行きの声になっていました。緊張してたんだなぁと思いました。

さて、この「インタビューをしあう」というものは、インタビュー前と後でお互いの印象が変わっているかどうか?という比較を取るように推奨されているので、取ってみたのですが、ものの見事に印象が変わっていました。印象が変わるというのは少し違うか…。さらに違う面が見えたという感じでした。

インタビューの形式は基本的には何にも記載せずに口頭のみで聴かれるという形で受けました。時々、私の方が整理のためにメモを取りましたが、何にも縛られない自由な感じで答えていきました。インタビューされているのにメモを取るというのは、ブログで言葉にするとなんか違和感のある書き方ですが、答えるのにも整理が必要だったので、インタビューされる側のひともメモの用意をして臨んだ方がよいと思います。

インタビューしあってみた感想としては、インタビューというもの自体が対象者に興味を持ち、聞き出すのにポジティブに関わろうとしている分、単なるおしゃべりとは違って建設的な関係性を作るのに向いていると思いました。ダイアログという双方向の場になるとしたら、さらに大変になるという印象が残りましたが、何かを試してみるという意味では刺激になる1日でした。

さて、3日目はYoshitsugu Miyazakiさんです。ご自分がインタビューされた時の話を書くようで、楽しみです!

2016-10-17

ココナラに出店してみました

11:03 | ココナラに出店してみましたを含むブックマーク

フリーランスが試しておくとよいサイトやサービスについて検討しようとしていて、実際に自分でその中の1つのサービスココナラに出店してみました。ユーザーの登録はFacebookのIDでの登録があるので、さくっと登録できましたが、実施に1つの提供内容を出品しようと思うと、割と大雑把な記載項目なので、どう書けばいいかは結構悩みました。報酬についてはレベルがあるので、最初はまさにワンコイン(500円)からです。ひとつのアウトプットととして利用するのが良いのかもしれないという現在の見解ですが、この後、どう展開、扱われていくかを検証していってみたいと思います。まずは自分でPRをするという意味でFacebookTwitter拡散をしてみました。

特にアクセス状況とかはないので、正直投稿して「シーン」という感じは否めないですね。

ネットでの発信は「反応」をどう得られるかが大事なのだなと。その辺、Facebookのイベントやページだと結構Facebook側から、反応ありますよ〜という情報を通知してくるので、「おっ」となります。

ちなみに同日にTime Ticketも作ってみたので、そちらとも対比しながら追っていきます。



社内研修を作るのに困っている方へ、企画から実施まで並走します。

f:id:DiscoveryCoach:20161017110629j:image:w640

99044

2016-09-22 エンジニアの企業での学びについての話 このエントリーを含むブックマーク

今年は企業の中での「学び」についてずっと考えているのですが、業務からの学びが減っているかもしれないという考えを少し前から持つようになりました。業務を「作業・行為」として捉えていると「同じこと」か「類似していること」のみができる範疇になるかなというような感じで捉えています。これは業務を行っている本人が「できるようになった」ということを「成長」という感じでは受け止めていないかもしれないという仮説でもあり、業務実行時には応用とか、新しいことへの適応を想定していないので同じことしかできない可能性もあります。「教えてもらってません」という言葉をどこかで聞いたような記憶が…。よく言われたりするのは理解していることと、できることは別という話ですが、与えられた仕事に「未知の領域」が出た時や、実は分かっていないとズレてしまうという時に経験則での対応ができないというのはそういう場合となるのかなと思いました。

私自身のエンジニアのスタートは昼間にエンジニアが組んだプログラムを夜間にデバックして、結果を伝える役目から入ったので、そもそも基礎がないので、応用というかだましだましというか、類似からいろいろ探っていくしかない環境でした。バグ再現条件を明確にするために色んな「当たり」をつけること、分からないなりにエラーメッセージに向き合うことをして、どうしたら昼間のエンジニアさんに正しく伝えれるかから始まりました。なので恥ずかしい話ですが、実装における「引数」という存在を理解したのは働いて3年目くらいでした。学び方とか、学びへの「飢え」が今の自分のスタンスを作り出したのかもしれません。これは一長一短で、最初から「独学」の強さもありますが、体系的に学んでない、いつまでも「ざっくり」な理解と、本当は理解できないかも...という不安から学び尽くすよりは学び散らかすことにもつながりました。

さて、そんな私ですが今は、インターンとかインターンをフォローする人たちにも同じように「学び」についての考え方を伝えたい…というような仕事もしています。伝えたいといういい方は、決して上から目線とかでなくて、できている人は良くて、できていないと感じている悩んでいる人たちが、今までにない視点に対して見えていないがゆえに悩んで気持ちがつらくなっていくのなら、そこに届けたいという感覚です。

人ひとりが人生の中で「知れる」「見える」範囲なんてそんなに広くはないんだと思うのと、一度マイナスやネガティブを実体験して得ないといけないものでもないと思っています。学びで悩んでいるなら、今、学んでいる人に聴くと一番よくて、出来ている人に聴くのなら分からないのは何がわからないのかを考えてから聞くとよいかと。

そもそもがこのエンジニアというかITの領域が「学んでいるもの」の全体が見えずらというのも原因のひとつだと考えています。先日「エンジニアの学ぶ領域」について可視化を試みたけど、どこまでいっても粒度や全方位的視点というのが難しくて独りよがりな図になってしまいました…。エンジニアの学びの話ではWEBシステムでの開発が多くなったので、言語のお作法を学んだ次にフレームワークを使わせているケースが多くなっていますが、フレームワークには「構築思想」が入っていて、設計を一度経由してからでないと理解して使うという道が難しくなっている気がします。逆にそこまで理解しなくても、チュートリアルや例で実装はできるし、システムもできあがると思いますので。しかして実はそれが現場の正道だとしても、その先に待っている現実コードは、オレオレフレームワークになっていることがあり、そこにチュートリアルレベルで参画した人にとってはチュートリアルで知った世界と「かい離」していて、「こ、これは同じものなのでしょうか…」となることがあるようです。

IT業界における学びの対象について

少し話はずれますが、新卒後に入った会社でSES契約から他社に常駐でのエンジニア業を始めている人たちは、受け入れ先の体制によって、初めの1歩が違ってしまっています。当たり前かもしれませんが、他社の人を育てる義務はない。というスタンスも正しいでしょうし、チームだから学びの提供(配属への教育コストも含みます)するというスタンスも正しいと思います。私は前者のところが多かったので、月に1度の帰社日に期待している余裕もなく、企業の危うさも事務所閉鎖業務などからも危機感を持っていたので社外のコミュニティに眼を向けましたが、初めて常駐した企業で、新卒でできる範囲の作業を割り当てて、エンジニアとしての成長を見据えた感覚を持って接してもらっていないと、新卒でも配属してもらっていることに感謝こそすれ、それ以上の成長の道に進むのは精神的には難しいかもしれません。成長の方向(目指したいエンジニア像)も見えないままでは、与えられる成長は今出来ないことをやるという失敗のリスクを含んでいるからです。常駐先での失敗は返されるのでは...となりますから。まずは与えられたできる範囲の仕事をこなす。こなす方法を工夫するよりは分かるやり方でやるのが早いし...。

なにが言いたいかというと、「入門の位置づけの研修」は、それやってみたい!ってなるようにしたいなと思っているということです。もっと知りたいとなるのもありかなと思ったけど、何をなすのか…とかがないと受講側の目がキラキラしてこない…感じ。キラキラさせるには受講側の期待値とか、好奇心とか、集中方向みたいなものを見て合わせていく必要はありますが…。それだけちゃんと向き合って関わりたいと…。とはいえ、私の場合は根っからのファシリテーターなので、グループ学習が基本となってきてますが、反転学習とかの話の時にも感じた、そもそもの元になる知識や土台がなさ過ぎると厳しいなというかもったいないなところもあったりして、最近では独習というのはどういうことか…というのを考えながらこの本を進めた時にいろいろ考えることはあったので、興味がでてきていたりもします。もちろんゼロからのグループ学習の効果もあるので、おもしろいんですけどね。

ただ、自分の価値原則は学びの形は人の数だけある…なので、「箱モノ」にならないように注意したいと考える今日この頃です。

98269

2016-09-09

企業における対話の育て方

08:47 | 企業における対話の育て方を含むブックマーク

【走り書き】

最近、いろいろなチーム開発の話を聞いていて確かに対話の量が増えることで物事に変化が起きているのを感じます。対話コミュニケーションの1つに含まれます。よくコミュニケーション能力の向上が望まれると仕事上のスキルで取り出されることがありますが、そのコミュニケーションは一方通行ではなく相手側の状態に影響されますし、場の雰囲気にも影響されます。ゆえにコミュニケーションは人と人との関係性が大事な要素になり、対話自体は仕事上での話し方講座ではなく、ふりかえりや朝会の中で「いい感じの会話」をすることで対話の質が上がります。いい感じの会話を体験すると、悪い感じに成りたい人がいなければ、対話と関係性の質は良くなります。

言いたいことは仕事上の…という中では、急に1人だけが話し方を変えても「どうしたの?熱でもある?」と違和感と、やんわりとした拒否感がでるということです。コミュニケーションを変えることは変化に敏感な人には怖いことです。しかしふりかえりや朝会といったツールや仕組みにはそれを越えさせる要素が入っています。それはルールです。そしてファシリテーションです。ルールだけでは違和感が明確になりやすいですが、ファシリテーションによって、そのツールを使う人々に擦り合わせることが起きます。ファシリテーションもまた体感によって伝播するものです。ファシリテーションから起きた「行為」を「ルール」と勘違いすると形骸化が始まりますが、「雰囲気」として捉えると伝播していきます。おそらくはその人々の「場」となって。

2016-08-05 エンジニアの学びについての話 このエントリーを含むブックマーク

牛尾さんがアメリカで出会った人と日本人の学びについての違いについてブログを書かれたのを読んで、いろいろ自分についても整理してみたくなり書きました。

新技術導入の遅さの一端はラーニングモデルの違いかもしれない

『アメリカの人は概念の説明の段階でも質問しまくるし、日本人の人は、概念ではなく具体的なものや事例を求めようとするのだ』(本文より)

自分の講師スタイルが「教え方」から「学び方」に変わったのは、この「違い」というか、「理解の仕方の差」を調整したいからだと思いました。概念で捉えられるようになるには、何かの構造(仕組み)を理解できた経験も必要であるし、その理解するプロセス暗黙知のままだて、「感覚」で処理してしまいます。もちろん、掴んだ感覚は他のモノを理解する時も同じように「振る舞う」ことでその人は理解できますが、「振る舞い」を他の人が真似しても、同じような理解にたどり着く保証はないです。なぜなら、他の人もまた自分の「理解の仕方」をもっているからと推測します。また別の視点からだと「理解すること」と「同じようにできること」は別だと考えます。そこで体感を理解につなげる「ふりかえり」と「理解にかえる」ための「ふりかえり」について知っている必要があります。昨夜ちょうどエンジニアの学び方について議論をしたのですが、ある方はそこは反復による訓練というような話をされていました。おそらくは繰り返されることによって、パターンというか「勘どころ」として身に付いていくのではないかと。その意味でエンジニアがよく「パターン・ランゲージ」という形式で学ぶのも分かる気がしました。そしてそれは「応用力」として使えるものになっているのではないかと。

先日登壇した事例発表では、発表の前に事例紹介の聞き方を先に話して、発表の間あいだで持ち帰ってもらうためのファシリテートしました。


学び方は気づいていないだけとか、知らないだけなことが多いと思っているので、「理解してないね」の前を少し見てあげてみてはどうでしょうか?

96244