Posts Tagged ‘DevLOVE’

なぜ実践なのかを考えた@ブレスト祭り

3月 4, 2012

2012/03/03にDevLOVEとhcdvalueが合同開催したブレスト祭りに参加した。
http://kokucheese.com/event/index/28198/

「学びの効果を実感するにはどうするか」ということをテーマに、デザイナーとプログラマが出会ってアイデア出しをしたらどうなるか、という主旨で行われた。

最近は特に勉強会を開催する身として、どれだけ自分を含めた参加者が効果的に学べるか、ということに悩んでいたので、このテーマには惹かれるものがあった。

学んだことの効果が実感できれば、たとえば、勉強会で得た知見を実際に会社でも活かしてみようと思える人たちが増えるだろうし、実践者が集まる場所は魅力的な場になるだろうからだ。

この会に参加してあらためて思ったのは、「フィードバックを得ることが学びの効果を実感するには大切だ」ということだ。

フィードバック重要。そのためのアウトプット

なぜフィードバックが重要だとおもったのか。
そのように思った理由は単純で9名?の人たちとブレストをする機会があったのだか、学んだことをアウトプットすることを学びの効果を実感するために重視していたからだ。

方法は、学んだことのリストを作る、とにかく実践、ブログを書く、人に教える、などのよく聞くものが多かった。
なので、方法について目新しい!と思ったのではなく、僕の気づきは、実践やブログ、人に教える、リストを作るという頭の中のものをアウトプットすること通じて「フィードバックを得る」という目的があるのだ、ということだった。

いままで、学んだことを実践する、ということが学習の効果を実感できる1番の方法だし、学んだことの価値を高める1番の方法だろうと漠然と思っていた。

でも、なんで「実践が1番なのか」という点について深く考えたことはなかった。

しかし、今回いろんな人達のお話を聞いてそれがようやく理解できた。(ような気がする)
実践は頭の中に入れた理論や知識、人の経験と再び出会う機会であり、フィードバックをつうじて理論や知識の再解釈が行う機会になるからだ。

たとえば、人に教えることが学びの実感につながるのも、その行為を通じたフィードバックがあるからだ。

人に教えるときに自分の学びの深さについて実感したり、学びが深まるのは、「何を教えるか」「どう教えるか」などを考えて教材を作っている時だ。

そして、教材を作っている時というのは、内的に自分の学びの深さについてフィードバックをかける効果がある。
たとえば、自分が知っていると思っていることに穴があって、教科書などを調べ直す、ということは結構ある。
もちろん、教えている最中に質問されて答えられない、ということで自分の無知に気づくこともある。

教えるという機会は、自分の知識に自身が能動的に問い直し、問いの結果を通じてフィードバックをかけること機会でもあり、第三者から学びのついてフィードバックを受ける機会でもある。

学びの効果を実感するためにはフィードバックが必要であり、フィードバックをうけるための1番の方法が頭の中にある知識や知見をアウトプットすることなのだ。
そして、実践にはその知識を自分の状況に合わせて再解釈する機会がある。

だから、実践が大事。

とはいえ、実践のハードルは高い。

なので、「すぶり」ができる場が必要だ。
すぶりは、模擬的な体験を通じて学びを活かす場だ。
そして、失敗をしても良い場所だ。
それは、Wikiでいうところのsandboxのようなものだ。

勉強会のワークショップなどはまさにそんな場だと思う。
ワークショップは準備は大変だけど得るものが大変多い。
なので、機会があったらどんどん参加したいし、参加してもらいたい。

今回の企画は、講師の石井力重さんに非常にお世話になりました。
懇親会でもずっと貴重なお話を聞かせて頂きました。
ありがとうございました。

広告

知らず知らずに内に自分の視点や行動は固まっているときづく@DevLOVE

11月 16, 2011

先日12日(土)にDevLOVE&yass合同勉強会「自力で海図を描きだせ!!」に参加した。
http://togetter.com/li/214190
http://kokucheese.com/event/index/19568/

講師の倉貫さん、梅野さんにお話を頂いたあと、「自分たちの10年後の明るい未来」というテーマでディスカッションを行った。

その際にエンジニアと経営者との視点や行動の違いが印象に残ったので、下記にまとめる。

ディスカッションで印象に残った指摘として、「エンジニアは自分を中心に将来を考え、経営者は外側にどのように影響を及ぼすかで将来を考える」というものがあった。

10年後の未来を考えるときエンジニアは「自分はアーキテクトになって」とか「プログラマとして現役でいたい」などのように、「自分がどうなっているか」を中心に未来を考えている。
一方で、経営者は「社会をこのようにしたい」とか「こういう問題を解決していたい」などのように、自分の事業や行いが「世界にたいしてどんな影響を及ぼしているか」を中心に未来を考えている。

こうした視点の違いから、現在の扱いも違ってくる。
10年後を考えるときにエンジニアは「googleはどのドメインで稼いでいるか」「メモリやCPUはどんな進化をしているか」など、現在の情報を集めて分析することで将来を考える。
いうなれば、現在の延長として未来を考えおり、現在は未来を構成するための材料だ。

他方、経営者はすでに自分の理想としての未来を思い描いている。
経営者が思い描く未来には、現在の事実や情報はあまり関係ない。
現在は理想の未来にたどり着くため過程であり、現在取り組むべき問題は理想の未来から逆算して取り出された課題だ。

経営者の未来は、現在の事実を積み上げた先にはなく、自分の思いや理想にあるのだ。

もう1つは、エンジニアは行動の前に情報を集めたがる、ということだ。
講師の一人は、「起業をしたいのですが、おすすめの本はありますか」という質問をされたというが、まさにそれがエンジニア的だ。
なにかをやるにつけそのことについて事前知識を持ちたがる、という姿勢は、冷静といえば冷静だが、行動力にかける。

一方、経営者は、起業をしたいと思っならまずは起業してしまう。
当然、前情報が少ない分失敗することもあるだろうが、その経験から学ぶ。
経験と共に学習し、学習した内容を実践投入することで、成功する確率を高めるのが経営者なのだ。

エンジニア的視点と経営者的視点のどちらが優れているか、ということは重要じゃない。
問題は、エンジニアや経営者として働いていると知らず知らずにのうちに視点や行動が固定されていることだ。

今回、エンジニア以外にも営業や経営者など立場や価値観が違う人たちが集まってはなしたことで、自分の考え方や行動が固定しがちなことに気づくことができた。

同じようなコンセプトで第2回も開催してみたい。

ピクト図解で先のビジネスモデルを考えた@DevLOVE

6月 14, 2011

2011/06/11にDevLOVE主催のピクト図解勉強会「世界の構造を描き出せ!!」に参加した。

もともとピクト図解については、本を読んで知っていたものの、読んだ当時はあまり魅力を感じていなかった。

「ふーん、なんかUMLっぽいなぁ」という印象で、「実際につかってみよう!」と思うまでには至っていなかった。

ところが、今回、講師をしてくださった@Akapon2010さんにお会いし、実際にピクト図を描くと実に面白かった。

4,5人の参加者がいれば、小さな新聞記事で、2,30分ぐらいはビジネスモデルについて盛り上がることができるからだ。

そして、DevLOVEのなかでも興味のある裏方さんが多かったため、勉強会を開いてみよう、と思い立った。

そんな経緯があり、今回は裏方チームとして少々コミットの量を増やし、ピクト図解勉強会を開くに至った。

ピクト図解を描くことの魅力は、「手軽に」コミュニケーションを整理しながら発展させられることだ。

システム開発においては、もともと図を使って思考や話を整理するUMLというツールがある。

そのため僕自身は、図を描くこと良さを実感している。

とはいえ、UMLは用途に合わせて使用する図自体が多く、それにともなって描き方のルールも多い。
そのため、コミュニケーションをとるための図を描き方を覚えるのにかなり訓練を要する。

なによりも、受託開発の場合には、UMLの図はお客さんとのコミュニケーションに使えない、という場面が多い。

UMLは開発者のためのものであり、お客さんがUMLの図をくもなく読めるという場合は、極めて少ない。

そのため、お客さんとその図を使ってコミュニケーションするためには、お客さんの訓練が必要になる。
その点、ピクト図解はおそらく1、2回ぐらい一緒に描けば、すぐに理解してもらえる図なのだ。

なぜ、ピクト図解は手軽で理解しやすいのか。

まず、ピクト図解には登場するエレメントとルールが少ないからだ。

どんなエレメントやルールがあるのか、というのは本を読んでご確認をいただくとして、UMLに比べたら雲泥の差がある。

それにはもちろん理由がある。

ピクト図解がビジネスにおける交換の形態を整理することフォーカスしているからだ。

ビジネスにおいて発生する交換を、誰が(Who)、誰に(Whoom)、なにを(What)、いくらで(Howmuch)、3W1Hという少ない要素で整理しているからだ。

ビジネスで発生する様々な事柄をすべて表現できない代わりに、ビジネスのモノ(サービス)とカネの交換にフォーカスをして思考と話を整理する手段を与えてくれる。

こうしたシンプルなルールだからこそ、誰にでも使える。
誰にでも使えるから、誰と話すときにでも役に立つ。

受託開発をしているとお客さんのビジネス、どのようにお客さんが稼いでいるか、にたいする理解は必須だ。

ピクト図解であれば、お客さんと話しながらビジネスへの理解を深めることができる、という期待がある。

ピクト図解でビジネスモデルを描くもう1つの利点は、論点が定まりやすいことだ。

モデルを書くとかならず、粒度が問題になる。

今回のワークでは、おもに会社間のものとお金の交換に注目した。
この視点は「社長」の視点だ。

ただ、この粒度でピクト図で交換のモデルを描いたとしても、自分の役に立つとは限らない。

たとえば、システム開発の場合であれば、システムを提供するユーザーの部門がどのような部門とつながっているか、どのような情報やモノやりとりされているか、が知りたくなる。

つまり、「ユーザーの視点」の視点での交換の情報が知りたくなる。
そのためピクト図にかぎらず、図を描くときには知りたい情報が表現できる視点を決める必要がある。

ピクト図でもこうした視点を定める必要がある点は、一緒だ。

そのため、今回は「社長の視点」で抽象的の高いビジネスモデルについてはなしましょう、などと話の前提を整えることができる。
また、図があるとその図を指し示しながら、この点のこのことについて話しています、と明示できる。

図も持たずに話ときよりも、視覚的に話している内容を表現できて話しやすくなるし、描くエレメントとルールが少なく使いやすいので、ちょっとした手間で済む。

ちょっとした手間で、論点を明示して話し合いができるので、意見の交換がしやすくなるのだ。

最後にピクト図解の中で1つの手法、ダイアグラム発想法により思考のフレームワークが提供されている点も便利だ。

なにより、自由に発想するという難しさから解放されるのが便利だ。

現状のビジネスモデルを考えた後、そのさきの理想のビジネスモデルを考えるのは難しい。
考える道具をもたず、考える道具から作り出す手間がなくなるのは、うれしいところだ。

なおかつ、その思考法がピクト図でも表現できるように紹介されているので、発想を図示できる。

現状のビジネスモデルをピクト図解で描いたあと、とりあえずフレームワークを当てはめて描いてみて、無理やり新しいことを考えることもできる。

考え方とその表現方法がセットになっている点が、非常に便利でコミュニケーションに役だつフレームワークになっている。

僕自身はまだ、ピクト図解が有効になる場面を把握できていない。

1人よりも複数人のコミュニケーションのために役立つような気もしているし、議論の発散よりも収束に適しているような気がしている。

なお、ピクト図解は板橋悟さんという方の『ピクト図解』という本で、その考え方や利点を学ぶことができる。

というか、この本の内容を実践する場が、ピクト図解勉強会という場だった。

興味をもっていただいた方は、本を手にとっていただきたいとおもう。

私は「月」を目指すことにしました。

12月 19, 2009

唐突ですが、月を目指すことにしました。
その月は、

「汎用機開発と美術について語れるスクラムマスターになる」

というものです。
そのために、

「次回の認定スクラムマスター研修を受ける」
「2010年11月の美術検定で3級を取得する」
「1年後にアジャイル開発・保守チームを社内につくる」

という目標を立てました。
やれるかどうかは、わかりません。
とくに、3番目は独力だけは絶対に無理です。相当、難しい試みだと思います。
でも、目指すべき場所は、はっきりしてきました。ですので、やりがいがある、と思っています。

さて、なぜいきなりそのようなことを書き始めたかといいますと、きっかけがあります。
それは、1冊の本との出会ったこと、2009/12/12(土)に「DevLOVE2009 FUSION」というシステム開発などに携わるエンジニアが集うイベントに参加したことです。

まず本の紹介です。その本とは、本田直之さんの『パーソナル・マーケティング』です。

この本を読んで、キャリアを築くに際して、マルチ・キャリア、そしてコントリビューション(貢献)という考え方を意識するようになりました。
マルチキャリアとは、自分の強みを掛け算することです。

ひとつの分野で抜きんでて実績を出すことは難しくても、いくつかの要素を組み合わせることで独自性を創りだすことが可能です。(p.141)

たとえば、汎用機開発に携わる人は、まだたくさんいます。しかし、汎用機開発に携わり、かつエクストリーム・スポーツをやっている人は、あまりいないはず。
さらに、その人がはやりの野菜ソムリエの資格を取得したら、その人の独自性はいっそう際立つでしょう。

では、掛け合わせることができる強み、とはどんなものでしょうか。
著者は、強みを「人に教えられるもの」と表現しています。

ところで、「強み」とは何でしょうか? 私はひとことで言って、「人に教えられることを持っている」ことだと考えます。
(中略)
ちなみに私は、自分がキャリアを積んだり、スキルを磨いたりするときにまず、「それを身につけることが、誰かの役に立つだろうか?」と自問するようにしています。(pp.88-89)

「人に教えられる」「人の役に立つ」という知識や経済の根源的な考え方にもとづいた、「強み」の表現が、わかりやすく、納得できました。
こうした、マルチ・キャリアとコントリビューションに基づいて、キャリアを形成しようと考えたときに、今度は別の疑問が浮かんできました。
それこそが、「今後、自分は何を目指すべきか」「今後、自分は何に取り組むべきか」という疑問です。

「独自性のあるキャリアを構築したい」
「そのキャリアを築くうえで何を強みとすべきか、何が人の役に立つか」
「キャリアを築くうえでプラスになるスキルを何か」

こうした質問がぐるぐると頭の中を回った状態で、私は「DevLOVE2009 FUSION」に参加したのです。
そして、とてもうれしい思いをしたのです。
それは、こんぴろさんのセッションで、

「汎用機開発に携われるのは、うらやましい」
「汎用機開発とオープンとの橋渡し的な技術を学んでみたら」

という言葉をいただけたことです。
汎用機開発でも学ぶべきことはあります。
しかし、これから先を見通したときに、汎用機の開発における知識だけではとても不安でした。
レガシー技術といわれ、これから火が消えてゆくような技術に業務でかかわることに、閉塞感を感じていました。

そんな私にとって、セッションいただいた2つのアドバイスは、目の前の扉を開く鍵のようでした。
汎用機開発に携わることそのものに、可能性を感じ始めることができたのです。

上記で紹介した『パーソナル・マーケティング』におけるマルチ・キャリアにおいても、「20代で汎用機開発に携わった」という事実はきっと独自性をだすためのひとつの要素になると感じることができたのです。

また、なによりも、

「生き残る、という戦略を考えてみたら」

という言葉いただいたときには、本当に心が洗われる思いでした。

「もっとチームを良くしたい」
「もっと役に立てる技術者になりたい」

と考えて、学んでいるうちに、ついつい独りよがりになり、

「もっと華々しい活躍をしたい」
「もっと褒められたい」

という的のはずれた欲求も生み出していたのではないか、と反省させられました。
華々しい活躍もすばらしいですが、今、それが望めないのであれば、「生き残る」という謙虚な姿勢から自分の仕事の価値やキャリアについて考えてみるのも良いかもしれない、と思えました。
何より、自分の能力を鍛えることは、自分自身が華々しい活躍をするためではないのです。
それは、仕事とはお客様とチーム、そして社会に貢献することが目的です。
その第一の原則を、「生き残る」という言葉に思い出させていただきました。

このほかにも、セッションやエンジニアの人との交流をつうじて、

「クラウドはバズワードじゃないっぽいな」
「今、アジャイルに参入することでアーリーマジョリティーにはなりえるかも」
「ドラゴンボール理論、ワンピース精神に準じるワンフレーズの原則をつくってみたいな」
「アジャイルを導入するに役立つビルディングタイプはあるなかな」

などと取り留めのないことを考えました。
まだまだ、まとめられる段階ではないので、記事にはできませんでした。
これから学びや経験を通じて、自分の思ったこれらのことをまとめて記事にしたいと思います。

何よりも楽しかった!
そして、とても大きな成果も得られました。
その成果が、自分の強みと信じる要素をFUSIONさせた、冒頭にある私の「月」です。

※「月」=目標。 これは、papandaさんのセッションからのパクリです。

【コミュニティ情報】
◆DevLOVE
・DevLOVE’Site
・DevLOVEメーリングリスト・サイト ※googlegroupへの参加が必要です。
【イベント情報】
◆「DevLOVE2009 FUSION」 ※すでに終了しています。
http://www.machoup.jp/devlove2009/index.html