無料ブログはココログ

« 2013年4月 | トップページ | 2013年6月 »

巨人の肩に乗る - アカデミアとの壁・その2 -

前回の「言葉の定義」でも書きましたが、 私が最初に(人格)指導されたのは「謙虚になりなはれ」でした。

この指導、生意気な若者や、腕に自信を持つ現場の人間が良く注意される様です。なぜなら、わかったつもりになっているからです。

プロとして仕事をしているの以上、みんな一人前ですし、技術に自信を持って構いません。しかし、実際にはその技術の多くは既存技術から成り立っています。また、技術者が苦労して開発したものの多くは、既に誰かの発見した技術の再発明であることも多いでしょう。

研究成果を論文にする場合は、利用した技術や再発明した技術ではなくオリジナルの成果が必要です。そのためには、既存の技術はどのようなもので、どこまでを利用していて、何を実践して、 何を新しく発見したか、そして過去の発表とどのように違うかを明確にしなければいけません。

これは「巨人の肩に乗る」(はてな)と言われているもので、過去の偉大な成果を忘れずに謙虚に示す事で、自分の成果を際立たせる事ができるのだと思います。

「巨人の肩に乗る」には3つの方法に分けることができます。これは研究が、問題設定、手法、評価からなっているからです。

(1) 問題設定で過去の研究を否定する。これは過去の研究の少し乱暴な使い方です。XXXな観点からYYYが成果を上げているが、ZZZは考慮されていない。として、新たな問題設定をする。

(2) 問題設定はそのままで、手法を提案する。一般に「巨人の肩に乗る」というと、これをさす事が多い様です。新しい手法を提案し、なぜ優れているかと、どの程度優れているかを示します。

(3) 新たに評価します。これにはさらに3つの乗り方があります。

  • 新しい技術は評価が不十分なことが多いので、評価実験を追加してその技術の特性や限界を示します。
  • 評価方法を提案します。同じ手法でも新たな評価によって、結果が代わる事があります。この場合、評価の精度や特性がオリジナルな点になります。
  • 開発現場で実践した結果とノウハウを示します。現場の技術者が貢献しやすい方法です。事例の数を揃えるとインパクトのある報告になります。

このように分けると、現場の技術者ならではのアピール方法は(3)だけですが、実は(1)と(2)も日常的に行っています。しかし、どこまでが既存技術であるかを把握していないので、そのアピールができていないと思っています。

全てを自分の発見の様に言うのではなく、過去の技術をきちんと説明し、どこがすごいかを説明できれば、技術を積み上げ可能にできると思います。

言葉の定義 - アカデミアとの壁・その1 -

私が最初に研究指導されたのは、言葉の定義でした(ちなみに人格指導の最初は「謙虚になりなはれ」)。言葉の定義は、論文を書く場合だけでなく、より多くの人に技術的な内容を正確に伝える際には大切な事だと思います。

開発現場の人間は、その現場で通じる言葉を話します。しかし、論文などの研究成果は多くの人に理解してもらうものですので、誤解のないように伝えないといけません。誤解がないようにというのは、厳密と言うよりは「ここでは」の意味を定義して、制限して使うということです。

たとえば、「バグ」似た言葉は、欠陥、障害、故障、など色々な意味があり、学会によってもそれぞれの意味が異なる言葉です。プログラムの誤りの数なら英語で言う fault で、正常に動かなかったテストの数なら failure になります。一つのソフトウェアの誤りで、複数のテストが不合格になりますので、同じ数値でも単純に比較できません。

論文ではバグではなく障害と呼ぶ事が多いですが、本文中の障害が fault なのか failure を示すのか明確にしてから議論します。

バグの定義などは専門的ですが、これ以外にも工程や作業の名称、工数を「稼働」と呼んでも伝わらないですし、「1人月」といっても時間数にすると違うほか、見積もりと計画、実作業、で1人月の扱いが異なる事も多いでしょう。

アカデミアでは、一般に使われている定義であるだけなく、議論の前提として使える様に定義します。その際には経験的に示されたものを引用する事で無駄な議論を避けて、いわば定理として用いて、そこから演繹した世界で研究成果を説明します。

難しいのは、その議論を聞く人が「できる人」もいる事です。できる人は、頭の中で知識の構造を常にリファクタリングしています。曖昧な定義のままで説明しても混乱を招くだけで、わかってもらう事はできません。内容の説明にどのような用語が必要で、どのように定義すれば、既存技術との違いを説明できるかが明確になっていないといけません。

このように、自分の言いたい事を伝えるには豊かな表現やイメージではなく、伝えたい事の構造を整理しておかなければ、うまく伝わらない場合があります。言葉の定義は、より多くの人に技術的な情報を正しく伝えたい場合には、意識しておかないといけない事の一つだと思います。

技術者には「場」が必要 - 勉強会に行く理由 -

大学の研究室は「場」

先日、大阪電通大でお世話になった先生の退職記念パーティがありました。その先生は、大阪電通大卒業後にそのまま研究員になられ、その後教員になられたので半世紀もの間、大阪電通大に関わられました。

研究室の卒業生は三百数十名です。同時期に退職された先生が100人を超えたので、それを超えるように言われた幹事役の先輩の努力もあってか、200名を超える卒業生が集まりました。ほとんどが1年しか在籍していない学部卒である事を考えると、驚異的な人数が集まりました。

パーティの挨拶ではその事に触れられ、「教師にできる事は『場』を作る事、これだけ集まってもらって、その事はできていたようです」と言われました。

先日のブログで、この先生の「職人になるな。勉強を続けなさい!」という言葉を書いた「社内勉強会より社外の勉強会」およびその続編「社内内弁慶を社外勉強会に参加させる方法」を書いたところ、多くの方に読んでいただいて驚いています。

色々なコメントを読ませていただいて、まだ本質が語れていなかったように思えましたので、記事の背景についてまとめておこうと思います。

技術者の「場」

このつぶやきで引用させていただいた記事には大賛成です。それは「場」を作られているからです。

技術者にとって、新しい知識を得たり、議論をして考えをより深めたり、実践する事はとても重要で、必要に応じてその「場」を選べば良いと思います。

深堀りするには、つぶやいた研究室のようなアプローチが有効です。また、新しい分野への理解や技術全体の体系的な理解を図るなら専門家や実践者、つまり本物に直接聞くのが早道でしょう。

独学の難しさ

場合に応じて本を読んだり、バーチャルプロジェクトをするのも良いですが、つらい時もあります(というか、私はなかなか続きません)。

最近は読書会形式の勉強会があって、大学の輪講のように読んで来た所の説明や意見交換をされている様です。一人で読んでいると、難しい本は続かないのですよね。

バーチャルプロジェクトを個人でやるのも、途中でネタが尽きるので苦しいです。研究のための Toy poject や Thesis Software のように、良い所で煮詰まってしまい、やる気が続きません。

オープンソース開発をするか、mrubyの@masuidriveさんのように「仕事でやらないと分からない」と思います。

社外勉強会という「場」

社外勉強会はとにかく「楽ちん」です。興味のあるテーマや自分の都合で選んで参加します。1週間とか1ヶ月かかりそうな本でも、ほんの数時間でそのエッセンスがわかりますし、読んだ本ならさらに理解が深まります。

また、個人で最新の動向を知るのは大変ですが、勉強会で知り合った人とTwitterやFacebookのIDを交換すれば、同じ分野に興味を持つ人の最新情報が入ってきます。いわゆるアンテナを張る事ができます。

そして何より、楽しいという事が一番でしょう。他の技術者とのコミュニケーションは共感できる事が多いですし、直接会って話するとネットワークでは得られない刺激的なお話が聞けます。

一人で勉強していたなら長時間かかる「答え」を教えてもらえます。例えば、Rubyは以前から愛用していますが、その良さを「思った通りにプログラムが作れる」と一言であらわしたり、オブジェクト指向に詳しい人とDDDや要求開発の話をしていて、実はアジャイル開発と同じ様に「モデリングは設計の時点では遅すぎる」がポイントだとか、詳しい人からでないと聞けない視点を聞く事ができます。

つまり、「勉強会」そのものだけでなく、様々な出会いが勉強になります。技術の全体像がわかり、個々の技術の位置付けがわかりますし、具体的なお話や業界の動向を感じ取れます。

何年かごとにお客さんが代わるとしても、一生の間に経験できる業務は限られています。しかし、少なくとも出会った人数だけのプロジェクトで得た知識を交換する事ができるのです。

仕事にも生かせる

もちろん勉強会で得られるのは知識です。ワークショップやハッカソンで実践しても 業務経験は得られません。

でも、以前からクラウドに興味があり、お客様に経験を聞かれた時の事を想像してみてください。あなたは「私は経験がありませんが、会社に経験者がいます」と誰か連れてきますか?

そこで、「経験はないですけど、一緒にやらせてください。アマゾンのGlacierとか、今の業務にも向いていると思うんですよね。」と言えたなら、同僚やライバル企業にチャンスを奪われないかもしれません。

すでにお客様の仕事をしていたなら、業務に関する知識があるはずです。その経験を生かして、やりたかった仕事ができるのです。お客様にとっても業務知識のある人ならリスクも少ないですし、専門知識が重視されるなら増員や協業も選択できるでしょう。

興味を持たないと成長できない

勉強と言うのは興味を持たないとできません。社内・社外を問わず無理矢理に勉強会に送り込んでも身に付きません。義務感や強迫観念ではなく、本人が興味を持ち、楽をする、楽しむ、といったポジティブな姿勢にならないと、必要最小限の情報を得たらそこで終わりになります。

モンテッソーリ教育のように、敏感期を活かしてとことん勉強することが成長につながると思います。 仕事のためとか、技術者として、ではなく、豊かな人生を送るための勉強でないと続かないからです。

IIJのCEO 鈴木幸一さんに本田宗一郎さんが贈った「濡れぞうきんは絞るな!」というガチガチの管理を戒める言葉があります。不景気な時代が続いたので、世の中には乾いた雑巾を絞るような雰囲気が蔓延しています。しかし、ぞうきんも湿らさないと機能を果たせない様に、技術者は新しい知識を得なければ未来を築く事はできないのです。

技術者は状況を判断して適切な技術を適用するのが仕事です。仕事だけでなく、技術の獲得の際も適切な「場」を選びたいですね。

このエントリーをはてなブックマークに追加

社内内弁慶を社外勉強会に参加させる方法

社内勉強会をする様に言われて拒否する(社内勉強会より社外の勉強会)のは私だけではないようです。ただ、結論が異なるので、私が社内の人向けに社外の勉強会をすすめている方法を説明しましょう。

社内内弁慶

そもそも社内勉強会をする様に言われるのは、社内内弁慶がいるからです。それなりに技術力があって、社内では威張るのに、社外に出て新しい知識を得ようとしない人たちです。

「この人たちをなんとかしたい」ということで、社外で活動している人たちに依頼がくる訳です。この「なんとかしたい」には2つあって、

  • 今のままでは使い物にならなくなるので、何でも良いので技術を身につける様にしたい。
     =>社内なら勉強会に参加するのでは
  • そろそろ技術的に賞味期限を迎えそうなので、次のステップに進ませたい。
     =>特定の技術力を身につけさせたい

後者の場合は@agnozingdaysさんの様に研修にすると言うのは良い方法です。仕事なので出てくれるはずです。

問題は前者です。みんな疲れていて、未来への希望を失いかけている。そこまでは行かなくとも、社内に活気がないのでなんとかしたい。お前は社外でも色々やってるから、社内でも勉強会ぐらいできるだろう。そんな感じです。

社内勉強会

そこで、社内をなんとかしたいと思う人から依頼がくることになります。社内勉強会で社外の人に依頼できる事はまずないので、社内の人が聞いた内容や、本で読んだ内容を話したり、議論したりすることになります。

このような情報は、時間の経過した、間違いを含む可能性のある、表層的な知識なので突っ込んだ質問や議論ができません。

もちろん講師になれば、人に説明する訓練になりますし、知識も身に付きます。また、社員同士でないと話せない議論もできるでしょう。

少し工夫して、論文や英語の書籍を読めば、それなりのアドバンテージも得られるでしょうし、意識の高い人同士であれば続くかもしれません。

しかし、本来の目的である。閉塞感を感じつつも打開できないエンジニアは、そんな時間はない、必要なことはすでにやっていると思うでしょう。

なぜ、時間がないと考えるのか?

そう言う人に社外の勉強会を勧めても、「時間がない」と言って参加しないでしょう。なぜ、そう思うのか、そこがポイントです。

逆に勉強会に行く人は暇かと言うと、忙しい人の方が多いでしょう。でも、勉強会の参加に必要な数時間を捻出しても良いぐらいに、勉強会が必要だと考えているから、何とか調整して参加するのです。

それは、純粋にそのテーマに興味があるのかもしれませんし、講師に興味があるのかもしれません。また、参加者でワイワイとお話しするのが好きなだけかもしれません。

実際に、勉強会にくる人は勉強目的の人だけではなく、講師のカリスマ性への憧れ、あるいは、仕事にストレスを感じていたり、世の中の動向に興味のある人が多い様に思います。

そのような人と比べて、社内内弁慶の人は勉強会の優先度が低いのです。それは、意識が低いと言うよりも、勉強会そのものを知らないからです。

もちろん、家庭の事情や、大切な趣味、仕事に対する考え方もあるでしょう。では、こんな事は知っているでしょうか?

  • 勉強会がどのようなものか?発表させられたらとかおもっていませんか。懇親会に愚痴を言いに来ている人なんて想像できないでしょう。
  • どんな勉強会があるか?ITカレンダーなんて知らないでしょう。
  • 最近のブームは?雑誌やWebの記事を読む人でも、どのイベントにどの程度来ているかはあまり知らないでしょう。
  • その技術が世間でどの程度理解され、実践されているか?勉強会の発表や質問を聞いていれば、自分のポジションがわかるでしょう。

このように、社内内弁慶に知らない事を伝えれば、氷山の一角だった社外勉強会への参加者を増やす事ができると考えて、実践しています。

参加者も応援する人も楽しもう

社内への勉強会の案内は、以前にもした事があります。SEA関西の世話人をしているので「こんな 分科会 があります。よかったら、どうぞ!」と言ったビジネスでも違和感のない感じです。しかし、たまに参加する人がある程度で、それほど効果はありませんでした。

そこで、今回はカジュアルに、技術者の仲間としてメールする事にしました。私自身も少し抵抗があったのですが、勉強会の雰囲気を伝えたかったのです。何しろ上司から社内のMLを使う様に言われたので、何でもありだと考えました。

表面的な説明だけでなく、 他の技術と絡めて個人的にどう考えているか、講師のすごいと思う所、技術者としてこうありたいから勉強している、といった思いをアツく説明しています。

そんなこんなで、少しずつですが、社外勉強会の参加者が増えています。そして、社内勉強会をする様にと言った上司もついに参加する様です。

やはり、社内内弁慶は食わず嫌いの状況で、みんな知らないから勉強会の優先順位が低かったののだと思いました。

社内勉強会だと、講師も参加者もどことなく義務的になりがちです。でも、社外の勉強会なら、興味のあるテーマを選び、都合の良い時に、最先端の情報を得る事ができます。

また、他の技術者とお話しすれば、それぞれに苦労をしていることや、先駆者のノウハウ、楽をする方法も知る事ができるでしょう。社内への情報提供も親しい友人としてお話しすれば、ワイワイできる仲間が増えると思います。

まだまだ始めたばかりですが、既に良い感触を得ています。タイミングや状況、社内の雰囲気に合わせて、仲間を増やしてみてください。

そうそう、うちの会社の人が参加したら、よろしくお願いします。

(続編を書きました。「技術者には「場」が必要 - 勉強会に行く理由 -」)

このエントリーをはてなブックマークに追加

オプションを維持するためのアソビ - CCPMのバッファを考える -

リーンソフトウェア開発には決定を遅らせるというプラクティスがあります。拙速に物事を決定するのではなく、最終責任時点と呼ばれる、それ以上遅らせると問題が生じるタイミングまで決定を遅らせて、オプション(選択肢)を残しておきます。

Leanとは贅肉がなく引き締まった様子を表す言葉ですが、オプションを維持するにはアソビが必要だと考えています。しかし、それはリーンやその元となったトヨタ生産方式ではどのように考えられているのだろうと、ずっと疑問でした。

CCPMとの出会い

最近CCPMを知って、というか簡単には知っていたのですがTOC/TOCfEの勉強会に出るようになって、CCPMでは理想時間で見積もって計画を立てておいて、全体のバッファを管理するというイメージがなんとなくわかりました。そこで、CCPMもトヨタ生産方式の流れなので、リーンのプラクティスと合わせて考えてみました。

考えてみて気づいたのは、実はバッファは予想外の問題に対処する余裕でなく、プロセス設計上のアソビなのではないかということです。オプションを維持する目的で、個々のタスクにバッファを取らせず、バッファをまとめておくのではないかということです。

CCPMでは、普通に計画すると人間は各作業にバッファを取りながら見積もってしまうので、それらを取り払ってまとめておく事で効率的に作業できる。と説明されることが多い様ですが、実はそれだけではなく、もっと理論的な面があると思います。

従来の見積もり

リスクの定義を考えると

  リスク=発生時の影響 × 発生確率

とされていて、これを各作業と共に積み上げて見積もるというのが、従来の方法です。

問題が発生しないなら、早く作業が完成するはずです。しかし、滅多にそのような事はありません。

もしかすると、よく言われる様に人間は楽な方に流れがちなので、問題が起きない場合もリスク込みの計画でゆっくり作業をしてしまうのかもしれません。あるいは、仕様変更など本来は計画にない作業を、別の問題用のバッファの工数で実施してしまうのかもしれません。

問題が発生した場合を考えてみます。リスク用の工数から作業を実施しますが、リスクには1以下の発生確率が掛けられていますので、これだけでは不十分です。そこで、残業やスケジュールの延長によってこの工数を確保する事になります。

このように、従来のリスク見積もりを各作業に割り当てる方法では、うまくいかないのです。

バッファをまとめる

そこで、各作業でリスクを見積もってもそれを各作業に積み上げるのではなく、プロジェクト全体のバッファに積み上げます。このようにすると、以下のようなメリットがあります。

  • 理想時間に合わせて作業するので、問題が生じない場合には理想時間で開発できる
  • 理想時間を超える理由が示されるので、問題解決や仕様変更の工数が明確になる
  • リスクの見積もりが正しければ、複数のリスクが統計的に扱える様になって、問題の発生時にバッファの工数で解決できる可能性が高くなる

つまり、CCPMは理想時間で見積もられる本来の作業と、関連するリスクの見積もりを分離し、リスクを統計的に扱う手法だと思います。

CCPMのバッファを試算する

たとえば、25%の確率で発生する問題の解決に4人日が必要なリスクが4つあるとします。それぞれのリスクを単独で見積もるなら1人日なので、作業の見積もり誤差の解消や細かな仕様変更によってすぐに消えてしまうでしょう。

もし、見積もり通りに4つのうちの一つの問題が発生しても、確保できるのは1人日しかないので、3人日の工数があふれてしまうことになります。

しかし、リスクをまとめておくならば、全体で4人日を確保できます。もし、見積もり通りに1つだけ問題が発生すれば、バッファの工数で問題を解決できますので、計画通りに作業が完了します。

このように、リスクの定義からバッファの取り方を考えると、CCPMがなぜうまくいくかが説明できると思います。

オプションの確保を考える

ここで、オプションを確保する事を考えてみます。オプションを確保する場合もリスクと同様に考える事ができます。

まず、計画を立てる場合には最も少ない工数ですむ場合の工数で計画を立てておきます。そして、最も多くかかる場合の工数との差分をバッファに積んでおきます。

こうすると、必要に応じてバッファを取り崩して全てのオプション(選択肢)を実現できる様になります。リスクではないので複数を集めて統計的に扱う必要はありません。

ここで大切なのは、オプションを問題にしてしまわないことです。最終責任時点よりも前に決定して作業を開始すればバッファ工数内で納まりますが、仮決定で進めると手戻りが発生します。このような場合はオプションとしてではなく、予めリスクとして見積もるべきでしょう。

アソビは設計するもの

アソビはただの余裕ではありません。鉄道のレールとレールの隙間や、橋脚と橋桁隙間、などの様に熱による膨張や地震の揺れを計算して設計するものです。

開発の見積もりではリスクやオプションを計算して積み上げていました。しかし、それを計画する際のバッファの取り方や最終責任時点の考慮が足りず、うまく実践できなかったのです。

これは人生でも同じです。計画的にアソビを作って勉強をしていれば、多くのオプションを確保できます。しかし、アソビを余裕と考えて無駄に過ごしたり、アソビは要らないと仕事ばかりしているなら、未来はないでしょう。

リーンやCCPMなどトヨタ生産方式につながるもの、それは技術者が本来知っておくべきものかもしれません。

このエントリーをはてなブックマークに追加

[#TiDD] 時計を選ぶなら - チケットシステムがスプレッドシートより優れている点 -

針のある時計は便利

私は針のある時計を好みます。高級な時計ではないので、針の動きが荒いかもしれませんが、デジタル表示よりは針の方が使い易いと思っています。

ぱっと見た際にだいたいの時刻がわかりますし、(この頃は滅多にありませんが)誰かに「今、何時?」と聞かれて、30秒を過ぎているから繰り上げて言おう、などと考える必要もないのです。

これは本来の機能は同じでも、その実現の方法によって価値が代わる事を示していると思います。

チケットシステムの利点

これまで、スプレッドシートのファイル共有で開発の管理してきた人は、機能だけを考えていると、チケット駆動に移行できません。チケットシステムに存在する以下のような利点を考慮する必要があります。

  • 分散かつリアルタイムで更新できる
  • メール、RSS、Eclipse等とも連携できる
  • 議論や経緯が残る
  • 結論が出る前に状況を共有できる
  • 様々な条件で検索できる(チームの視点、個人の視点、リリースの視点、etc)
  • 新しい帳票を作るのは大変だが、チケットの種類やレポートは簡単に増やせる
  • 複数の参照形式(レポート)を共有できる
  • 双方向リンクが容易に実現できる(wiki、ITS、VCS、その他ツールのハイパーテキスト)
  • ファイル共有に特有のトラブルがない

デジアナ好き

私が買うのはいわゆるデジアナで、針の表示だけでなく、デジタル表示のあるものです。アナログ表示の良さは認めるものの厳密な表示やストップウォッチなど、デジタルでないと実現できない事があるからです。

もしものための環境構築で書いた様に、ソフトウェア開発では常に「もしも」を意識して行動する事が求められます。

アジャイル開発ではいわゆる「貼りもの」が好まれる傾向があります。貼りものには、自然と目に入る、アナログ時計の様に状況を大まかに把握できる、という利点があります。その反面、貼りものは後から探す事が難しく、その点はチケットシステムに負けるでしょう。

そこで、写真を撮る、デジタル入力も行うなどして、記録を残すことも行われている様です。逆にチケットの欠点を補う目的で、チケットを印刷して貼っている方もおられます。

アジャイル開発が普及している海外では、ソフトウェア開発はユーザ企業で行われている事から、開発者がそのまま継続して運用・保守することで、自然とDevOpsが実現されているのかもしれません。

そのような場合、それが開発会社の瑕疵であるかどうかはもちろんの事、人が代わってわからないので、どのような経緯でそうなったかを確認することが重視されないのかもしれません。人の入れ替わりが少ないなら、担当者はだいたいの経緯や構造がわかっているので、経緯の確認よりもこれからを検討することが重視されているのでしょう。

これから開発するソフトウェアがどのようなもので、どのような体制で開発されるかなど、様々な状況を考慮して必要なものを選ばないといけないと思います。

おしゃれな人にはおしゃれな日常生活防水の時計で良いかもしれませんが、ダイバーにはダイビングにふさわしい時計があります。プロには仕事に必要とされるプロの道具が必要なのです。食わず嫌いではなく、きちんと理解した上で、ふさわしい道具を使いましょう。


[#TiDD] アジャイルラジオでチケット駆動開発とスクラムを語りました #agileradio

先日のXP祭り関西2013LTをされていたミウラさんがディレクターをされているアジャイルラジオ

アジャイルラジオは、アジャイル開発を中心にソフトウェア開発のあれこれを、インターネット・ラジオ(Padcast)で流すという、斬新な活動です。XPJUG関西などアジャイル界隈では有名な、土屋さん、山根さん、西さん、東さんが2人ずつ担当されて、毎週水曜日に配信しています。

いざ出演

さて、以前ゲストで登場(初回2回目)した壁の魔術師の田口さんからのリクエストで、私、@sakaba37がアジャイルラジオに出演しました。

聞いている人は予想がつくと思いますが、2本録りです。初回の放送では自己紹介のほか、書籍「アジャイル開発とスクラム」の紹介、そしてチケット駆動開発を少し話して終わっています。

2回目の放送はチケット駆動開発の話が中心で田口さんの質問にも答えています。その流れで、書籍「SCRUM BOOT CAMP THE BOOK」のお話もしています。

裏話

元々は東・西さんコンビのゲストの依頼だったのですが、当日になって東さんの都合が付かず、西さんと2人でラジオをしました。折角なので(というか、しめしめと)オープニングコールもさせていただきました。

いつもと違うスタジオ(?)で、 いつもと違う機材。若干音が悪いですがおゆるしください。写真は収録語の西さん、後ろに見えるのは綿密な(?)打ち合わせ内容です。

Agileradio

普段の東・西さんでは、どちらかというと西さんが中心にお話をされ、東さんが柔らかく突っ込んだり、フォローしたりと言う感じの番組です。今回はその西さんが鼻をグスグスさせながら突っ込みに回られたので、その切れ味の鋭い事!言葉に詰まってしまい「ナンセンス!」という昭和な言葉を生まれて初めて使ってしまいました。

でもそんな感じが、なかなか面白い風合いを醸し出しています。見られていたら面白かったかもしれません。

ちなみに、番組中の音楽は侍塊’sの「Dear XP」でXP祭りなどのほか、海外のアジャイルイベントでも公演されています。

終わってみての感想

アジャイルラジオが始まってそろそろ半年です。ラジオを始めると聞いた時は、どうして今時ラジオなのかと思いましたが、アジャイルあり、TOCあり、なかにはメイドさんのお話まで出て来て、なかなか楽しめます。

いつも電車の中で聞いてるアジャイラジオに出させていただいて、とても喜んでいます。しかも、色々な方からコメントなどをいただけました。ラジオはなかなか面白いメディアだと思いました。@gaujin_jpさんのコメントを紹介しておきます。

ソフトウェア開発をしていると、ちょっとしたアイデアが商品の価値を高めたり、作業を大きく改善する事があります。アジャイルラジオはちょっとしたアイデアだったのかもしれませんが、大きな可能性を秘めていると思います。

もし、聞かれた事がなければ、ぜひ一度聞いてみてください(最近のiOSでは再表示で戻ってしまいますが、Podcastで聞くと快適です。iTunes shopやPodcast shopで「アジャイルラジオ」「阪井」などで検索してみてください)。


社内勉強会より社外の勉強会

先日、上司から社内勉強会をして欲しいと言われました。しかし、うまくいくと思えなかったので、社外の勉強会の紹介を始めました。その理由は、、、

社内勉強会の利点

  • 事例の詳細が紹介できる
  • 業務に合わせてテーマを選べる
  • 時間調整が容易

社内勉強会の欠点

  • 発表者が限られる
  • 内容が偏りがち
  • 義務的になり易い

社内勉強会の微妙な点

  • 残業手当が出るのか、出ないのになんでと思う
  • 一部の人間に負担がかかる
  • 継続的な勉強には向いているが、様々なトレンドは追いにくい

社外勉強会の利点

  • 著名な発表者( ほんまもんに会える!)
  • 最新トレンドが選べる
  • 自由意志で参加できる

社外勉強会の欠点

  • イベントに合わせて仕事の調整が必要
  • イベント情報を得られるアンテナが必要
  • 具体性に乏しい場合がある

社外勉強会の微妙な点

  • 基本は自己負担
  • 移動しないといけないので、時間調整が必要
  • ビジネスにつながるか微妙

勉強会として比較すると、こんなところでしょうか。しかし、社外勉強会にはもっと重要な事があります。

外に出る利点

  • 世の中の動向がわかり、刺激が受けられる
  • 自分の会社の長所・短所がわかる
  • 同じ興味を持つ仲間が増える

狙うと失敗するもの

  • 商売のネタをさがしに勉強会に出ると、本音で話せる人脈ができない
  • 格好を付けても、本物でなければすぐにばれる
  • 知ったかぶりをしていては、教えてもらえないので知識が得られない

若者も年長者も外に出て刺激を受けるべきです。広い視野をもてば、苦しいプロジェクトを客観視でき、新しい展開も見えてくるでしょう。

先日、卒業した大学の恩師の退職記念パーティがありました。そこで友人が、未だに忘れられない恩師の言葉としてこう言いました。

「職人になるな。勉強を続けなさい!」

技術者は常に勉強が必要です。引きこもって勉強していては続きません。外に出て、仲間と楽しく勉強しましょう。

社内内弁慶を社外勉強会に参加させる方法につづく

このエントリーをはてなブックマークに追加

« 2013年4月 | トップページ | 2013年6月 »