コスモ・マップ基礎講座#2、無事終了

前の日曜日に、インストラクタとして2回目の基礎講座を、無事終了しました。
ちょっと遅くなりましたが、ざっと振り返り。

  • 受講生構成
    • 新規1名、再受講2名、インストラクタ1名
  • 良かったところ:
    • 時間は09:45-12:30で計画通り。我ながら素晴らしい時間管理w
    • 今回アレンジした内容:
      • スライドをプロジェクタ投影して説明を補足。
        ※なかなか好評でした。夜更かしして作った甲斐があった…夜更かししたのは私の計画ミスですが…。
      • "3つの概念"の説明を、各エレメントの説明に織り込んだ。
      • 陰陽五行論は、名前の紹介だけにして、全エレメント間のバランス・チェック方法を具体的に例示。
      • コスモ・マップの書き方レクチャ→書く→シェア→使い方レクチャ という流れ
      • 基本の説明+コスモマップ初めて数ヶ月の人向けのトピックも盛り込んだ。
        • 結果、ボリュームが倍近くになったものの、スライドを使うことで受講生の理解スピードを倍増していたため、新規の人にも普通に付いてきてもらえた感じ。
    • 早速、再受講の依頼を頂きました。感謝!
  • 反省点:
    • 声が小さい→ボイストレーニング、どうすれば続くだろう?
    • 自分のテンション制御→何かスィッチを作る。型を作る。
    • 姿勢が悪い→背筋を筋トレメニューに追加?変わりに何か減らす?
    • フィードバック→進行に気を取られすぎ。キャッチボールを促進する技術は、自分のテンションも高くできるので必ず身に着けたい。要練習。

仕事に誇りを持つには、他人からの承認と、それを受け取れるだけの自信が必要:[映画]ティンカーベル

観に行くのが遅くなり、吹き替えしかなかったけど観た。
警告:ネタバレです。

要約すると、

  1. 自分が持っている才能は、地味なものだった。でも華やかな仕事がしたい。転職するために職業訓練する。
  2. 華やかな仕事をするための才能が無いので上手くいかず、悲嘆する。
  3. 自分のもっている才能は、地味だけど、とても凄いモノだという事を人から繰り返し言われるが、受け入れられない。。
  4. 地味ながらも人の役に立つ仕事で成果をあげて、承認される。
  5. 他のことが都合よく廻りだして、(最初に思ってたのとはちょっと違うけど)華やかな仕事を任される。

という話だった。もちろん作り話なので、都合による新ルール登場とかあるけれど、納得させるだけの「現実らしさ」があった。

その1:才能について

  • 才能とは、他の人がやりたがらない何かを、苦しまずに自ら出来ること。
  • 仕事に誇りを持つには、他人からの承認と、それを受け取れるだけの自分の才能への自信が必要。

私が尊敬する任天堂の岩田社長も言ってます。『たとえば、絵を描く人は、誰に頼まれるでもなく絵を描いて、それをまわりの人がほめてくれる。そういうくり返しのなかで、どんどんうまくなる。…(中略)…この循環を成立させられることこそが おそらくその人の才能だと思うんです。』(ほぼ日刊いとい新聞より)

その2:セレンディピティ

ザ・シークレット/コスモ・マップ的に言うところの「引き寄せの法則」。あるいはワタシ的に言うところの「人脈による奇跡的進展」。
夢について人に語ること・努力している姿を観ている人が居ること、というのは夢の実現にとって大きな力になる、という事です。
だからといって"これみよがしに"やるのではなく、隠れてやるのは損だ、くらいに思った。

余談1:実は最初の方で「思ってた以上に子供向けだなー、ちょっと退屈だなー」と思った。横を見ると、妻は寝ていたw その後は、ちゃんと起きていた。たぶん。

余談2:そういえば「仕事に誇りを持とう」というメッセージは、ウロオボエだけど、魔女の宅急便もそういう話だっけ?

余談3:世界観がよく作りこまれているなーと思った。夢があって良い。どうやってディズニーランドのアトラクションに落とし込むのか、勝手に色々アイディアを考えてしまった。

  • ネズミ(チーズという名前)にのってレースをする3Dシアター(ぐわんぐわん動くゴンドラに乗った状態で3Dムービーを見るやつ)。途中で"なんとかアザミ"(名前忘れた)が出てきてパニックになったりとか、意地悪な他の妖精が妨害してくる、とか。
  • いろいろな道具を作って遊ぶワークショップ。
  • 四季の森?をゴンドラで巡るツアー。

EffectiveJava読書会終了、次はデザインパターン本

火曜日に無事、最終回を終えました。

参加者は、最終回にして初の社外メンバーteradaさんを含めて5人。
次回からは「京都プログラマ読書会」(KPRC:Kyoto Programmer Reading Circle)と名称を変更します。そして、KPRCとしての最初のタネ本は、「増補改訂版Java言語で学ぶデザインパターン入門」となりました。

今後は隔週火曜日の夜19時〜21時に、四条烏丸でやります。
第一回は、2月10日。

参加受付は
http://sites.google.com/site/kyoutoprogrammersrc/
にて。

XP祭

土曜にはXP祭in関西いってきました。
以前から行きたかったんだけど、予定があわず、今年やっと参加できた…けど寝不足&コスモ・マップ基礎講座の準備のため、最後まで参加できなかったのが心残り。

個人的に気になったところ(手帳に書き付けたメモに加筆):

  • 全権を持っているとは言えないマネジャ、なんとなく決まっているゴール(スコープ)、とりあえず決まっている期限(納期)、一応プロということになっているメンバー…我々の業務は「プロジェクト型」業務ではないんじゃないか? → PMという手法でソフトウェア開発をマネジメントしても上手くいかないのではないか? という問題提起があった。
    • 受託開発をやっている私には、確かにプロジェクトだという実感は無い。便宜上それを「プロジェクト」と呼ぶことはあるけれど、時々使う「案件」という言葉のほうが、しっくり来る感覚がある。
    • プロジェクト型でなければ何なのか?という私の問いに対して、定義からいうと(プロジェクト型業務でないとすれば)定常型業務だと、会場の方から回答があった。私が携わっている受託開発業務は、定常型業務というイメージに近い。例えばオーダーメイドのスーツか何かを作っているような感覚だ。1つして同じものはないが、どれもスーツであることに変わりは無い。ボタンの数や、丈の長さが違うだけだ。
    • プロジェクトという感じがもてないのは、顧客のビジネス目標に無頓着な立場に居るからだ。そういうやり方が顧客にとって必ずしも効率的ないというのは承知しているものの、私には発注側・受注側の双方が現状のリスク配分に満足しているように見える。具体的には、発注側は
      • 最初に決めた要件を満たすためのコストが、最初に決めたコストを上回るかもしれないリスクよりも、
      • 最初に決めた要件がビジネス目標を損なうかもしれないリスクを
    • 取っているように見える。逆に受注側(私の側)は、
      • 最初に決めた要件がビジネス目標を損なうかもしれないリスクよりも

         

      • 最初に決めた要件を満たすためのコストが、最初に決めたコストを上回るかもしれないリスクを、
    • 取っている。発注側は「自分達の業務は自分達が一番良く知っているから、要件に問題があることは無いと思うけど、それを最初に決めたコストでやりとおす事は難しい」と思っているし、受注側は「発注側が考えた要件がビジネス的にどうかというのは難しい問題で責任もてないけど、スコープがはっきりしていればコストを最初に見切ることは、おおよそ可能だ」と思っている。その業務の仕組みで他社との差別化を測っているような業務で無いほとんどの業務系アプリでは、実際、それで問題のないことがほとんどだ。
    • このことは、それをオーダーメイドで作らなければならないほど特殊ではないということの裏返しな気がする。私達からパッケージ製品導入とカスタマイズを提案することは無かったけど、そういうサービスのほうが付加価値が高いのかな。どうなんだろう?
  • タスクカードを使うと(タスクの)ゴールを明確にできるという話について:
    それが仕様書でないなら、果たしてゴールを明確にできるのだろうか? と今思った。かえってタスク間の真空地帯が出来やすいのではないかと考えたけど、そこはどんな風にカバーしているのだろう。
  • An Agile Way 2007/11/22 より、セレンディピティについての平鍋さんの言葉を引用:『「思う」、ことがまず決定的に重要で、それが出来事を産み、行動を生む。』:とても興味深い話。出来事と行動の順番が逆に思えるのだけど、どういうことなんだろう?
  • ちょっと調べてみたいツール:
    • Hudson
    • statSVN
    • TestLink
    • infoQ ※ツールじゃないけど、面白い話が一杯のサイト。

変なプログラマの作り方#5で発表

# すでに週が変わっていますが気にせずレポート

Diskmap
先週末1/23(fri)に「変なプログラマの作り方#5」に行ってきました。
予告どおり、今回は発表しました。

発表したのは「ディレクトリ地図0.1」です。
ディレクトリを再帰的に辿って、ファイル・ディレクトリ名を地図状(の予定だったのが花火状)に描画した画像を、SWTのキャンバスで画面表示しました。上の画像は、WindowsマシンのMyDocumentを、このプログラムで描画したものです。
画像のインパクトがあったのか、#5の「最も変なプログラマ」に選ばれてしまいました。光栄です。ありがとうございます。今後も「変な」道を邁進したいと思います。

期待を裏切らなかったフレームワーク : Wicket

安心感だと思う。

Javaでプログラムを書いているとき、私が重視している"気持ち"は、安心感だ。

Wicketフレームワークについてのエントリを書こうとして最初、その「Javaらしさ」を褒め称えようと考えた。でも、Java"らしい"とはどういうことか? というのを書こうとすると、XMLを書かなくていいからだ、とか、そういう他のフレームワークをけなすような書き方になってしまう。それはしたくなかった(書いちゃったけど)。

そこで、自分の感情に注目してみた。つまり、Javaらしいプログラムを書いていると、どんな気持ちがするのか?

Javaはコンパイラ言語で、少しのプリミティブを除いた全てがClassとして表現される。変数の参照型は厳密にチェックされ、やろうと思えば、かなりのエラーをコンパイル時に検知することができる。実行時に付きまとう不安感を減らせる。これはプログラミング時の安心感につながっている。これが"Javaらしさ"だと思う。

WicketほどJavaで書けるWEBアプリフレームワークというのを、他には知らない。

Wicketでは、XMLに書かないといけないのは、サーブレットマッピングくらいだ。それ以外の設定事項は全部、Javaに書く。

JSPだって書かなくて良い。JSPほとんどJavaみたいなもんだけど(コンパイルもできるし)…。MVCモデルだからViewModelクラスを作って…なんて当たり前のようにしていたけど、その冗長さが今では鼻につく。Wicketでは、JSPどころかテンプレートですらない。XHTMLで十分だ。wicketネームスペースのid属性だけは必要だけれど、本当にそれだけだ。JSPならjavascriptでやっていたことも、Wicketなら大体Javaで書けてしまう。
MVCアーキテクチャをStrutsで知った、なんて言う人が多いと思うけど、そのStrutsでも、Vのところはせいぜい半分くらいしかJavaじゃなかった。Wicketでは少なくとも80%くらいはJavaだ。

私がWicketフレームワークのことを知ったのは、2年くらい前だと思う。どんどん立ち上がるJavaのWEBアプリ向フレームワークを追いかけるのが少し食傷気味になっていた頃だ。
その時から色々なところで「WicketはJavaらしいフレームワークだ」という話を読んだいた。私は"Javaらしい"フレームワークがきっと性に合うだろうと思っていたけれど、なかなか実際に触ることをしなかった。雑誌でチラっと読んだりしただけだ。
他のフレームワークでは、ちょっとがっかりすることが多かったから、どうせまた期待を裏切られるのだろうな…という諦めのようなものがあったのかもしれない(単に面倒だっただけかもしれないけど)。

でも、触ってみたら、ビビっと来た!

こんなに「かぶせたくなるところが少ない」フレームワークは始めてだ。拡張したくない、というのとは違う。むしろ、拡張はしたい。でもそれは、あくまでも拡張するのであって「隠す」のとは違う。これまで、特に、業務で使っていたフレームワークでは、隠したくなるところが本当に多かった。何でこんなに変なモデルなのか? 中途半端な拡張ポイントばかりあるのか? 無駄に自由度が高そうに見せるのか? 気に入らないところが沢山あった。

Wicketには、そういうところが無い。まだ見えていないだけかもしれないけれど、かなり惚れこんでいる事は確かだ。

赤裸々な技術書 :楽々ERDレッスン

10年早く読みたかった。

そうすれば、不合理なコード体系に振り回されて工数を空費することもなかったし、DAOの粒度を無意味な大きさに統一することもなかった。まだ記憶に新しいアノ不具合も作りこまなかった。後悔しきりだ。奥付を見ると2006年の出版とある。となると最短で読んだとしても、あの不具合とアレくらいしか救えなかったかな…それでも結構大きいぞ…と胸算用してしまった。

そのくらい生々しいノウハウが、書かれている。

著者が失敗から学んだことだろう。私も似た失敗をして学んだことが多く書かれていた。だから技術書なのに"赤裸々"な感じがするのだ。

勘定系システム開発とは切っても切れないデータベース設計での失敗、落とし穴、そして肝心の回避策が多く書かれている。そんじょそこらの先輩・研修講師には決して教えてもらえないような質・量だ。1年生には難しすぎるけど、2年生なら十分に読みこなせるだろう説明の仕方もすばらしい。

ビジネス選書読書会

今日はビジネス選書読書会に参加してきました。
企業を目指されている方のためのコミュニティというだけあって、勉強熱心・独立心旺盛な皆さんから刺激を受けまくりの2時間でした。

かなり古い本らしいですが「一分間マネジャー」、ベストセラー7冊分のエッセンスを凝縮した「ビジネス理論一夜漬け」、著名な著者5人の英知をつまみ食いできる「5つの仕事力」など、面白そうな本が多数紹介され、またまた私のウィッシュリストが長くなってしまいました。



さて。ためてたブログもこれで一段落…。
次回は最近いじっているWicketフレームワークの話を少し書きたいと思います。

ファシリテーター的、論理力の使途(FAJ定例会)

これまた数日前の話ですが、ファシリテーションの勉強会に参加してきました。FAJ関西支部の1月定例会です。先月、協会員になったばかりで、初めての定例会参加でした。定例会は、毎回2つくらい準備されるテーマから、1個を選んでワークショップに参加するという方式らしいです。今回は「笑い」と「論理力」の2つのうち、論理力のほうを選択してみました。

以下、ワークの感想です。

論理力とは何か?というところから始めて、論理力を使ってみるワークをいくつかやったのですが、ファシリテーターの立場で論理力を使うというところが、とても新鮮でした。

私の場合、論理力というと、論理でもって自論を有利に展開するというような使い方を真っ先に想像するのですが、ファシリテーターは、他の会議参加者の意見
を吸い上げて整理するために論理力を使います。具体的には、発言内容を論理的な視点からチェックすることで見えてくる飛躍、矛盾、偏りなどを、やんわりと
指摘することによって真意を引き出したり、有用な論点を見つけたりします。そこまでするのか、ファシリテーターは…という驚きが収穫となりました。

変なプログラマの作り方#4

先週、久しぶりに「変なプログラマの作り方」勉強会に参加してきました。
第一回、第二回、一回とばして、第四回の3回目の参加です。

内容を、要約(うろ覚えですが)してみました。

  • 勉強会直前になってHDDを初期化する羽目になってしまったモリモトさんによる「こんなのもスライドっぽく使えますよねソフト紹介」
  • 発表者が少なく、ピンチヒッターとなったid:fujioka0729さんによる「むかし作ったアプリのスライドっぽい機能を実現しているJavascriptコードの解説」

さすがにちょっと苦しい感じですw。

発表後、次回テーマ「地図」のアイディア出しをやりました。
私もそろそろ発表せなあかんやろ…ということで、次回発表させていただきます。

2月に開催されるFlex京都勉強会#1でも、うっかり発表することになりそうでしたが、思いとどまりました。Flexは、もうちょっと勉強してから発表したいと思います。触ったことないし…。