プログラミング”センス”の伝承

ファシグラ・ワークショップin名古屋からの帰り道、新幹線で西河さんと話していたこと。

プログラミングのスキルは「知識」と「センス」に分けられる。

「知識」のほうは割と簡単に身につけてもらうことが出来る。"簡単に"というのは、身につける本人ではなく、教える方にとってラクだ、という意味だ。

いっぽうで「スキル」の方は、(少なくとも簡単には)身につけてもらうことが出来ない。どうすれば身につけてもらえるのだろうか?

私の過去およそ10年くらいの経験の中で、それなりの期間をとって直接指導したのは4人しかいない。一般論とか語るには全然キャリアが足りないだろう。それでも最近になってようやく分かってきたことが1つある。

それは、「センス」は自分一人で磨くのが大変な分、人に伝えるのも大変だということだ。裏返して言うと、教える方が大変なエネルギーをかければ、ちゃんと伝わるものだということだ。
つまり、効率よく伝える方法なんて無いけれど、地道に積み上げるのを手伝ってあげることは決して不可能ではないのだ。

教える方だってなかなか綺麗に体系化できていないから、それはそれは地道なレクチャになるし、何回も同じことを喋っている気がしてウンザリしたりとか大変だ。でも、放っておいて、本人が本を読んだり壁にぶつかったり、しばらく諦めてまた勉強を再開したりするのに任せているよりは、エネルギーを注いで地道にレクチャすることで、かなり効率が良くなる。僕の感覚では、自分が達するのに要した半分以下の期間があれば、十分に納得できるレベルまで、伝えることが出来る。

しばらく教えてみて向上しないとすぐに「あいつは素質が無かった」とか「ヤル気が無かった」と考えたくなるけど、まぁだいたいは自分が注いだエネルギーが不足していただけの事、小っ恥ずかしい言い方をすれば、愛が足りなかったんだな、と最近気がついたので、書いてみました。

ファシリテーショングラフィック体験

ファシグラ・ワークショップ at 名古屋アジャイル勉強会 に行ってきました。
講師は「すだち師匠」こと、mnishikawaさん

「もっとも表現力の高いツール」"プロッキー"を使っての基礎ライティング練習の後、60分の模擬会議中、一人15分くらいのグラフィッカ体験をしました。
想像はしていましたが、リアルタイム要約しながら"見える化"するのは、かなり難しいことを実感しました。「余裕やん」と思っていた基礎ライティングも、簡単にトビました…。本にのっている加藤さんのファシグラとか、改めて見るとカミワザとしか思えません。すごいなー。

というわけで、実践は以外と難しかった基礎ライティングのまとめ。
(個人的に難しかった順)

  • 丁寧に、四角く書く。
  • 漢字は大きく、ひらがなは小さく書く。
  • 縦線は太く、横線は細く。

PFPワークショップでやったアイスブレイクから2つ

今日はPFP関西主催のワークショップに行ってきました。
テーマは「アイスブレイク」でした。

ちょっと面白かったのを2つ紹介します。

財布の中身

  1. 各人、自分の財布を用意する
  2. 三人でグループになる
  3. 財布の中身を取り出しながら、それにからめて自分の普段の生活や性格などを自己紹介します。

    ※見せたくないものは、もちろん見せなくても構いません。

このワークの面白いところは、「すでにある程度見知った間柄」でも以外と知らなかったような一面を、自然に開示できるところです。職場やお馴染みの面子でのアイスブレイクなんかに良いかもしれません。

褒めあう

  1. 広めの場所を確保して立ってやります。
  2. 同数ずつの2グループに分けます(グループA,B)
  3. グループA,Bをそれぞれ内側、外側にした同心円状に並びます
  4. グループAの人は、目の前にいるグループBの人と名前だけの自己紹介と握手をして、あとは2分間ひたすら相手のことを褒めます。
    合ってても外れてても構いません。外見だけでなく直感で褒めても良いです。
  5. 終わったら逆にBの人からAの人を褒めてもらいます。
  6. AもしくはBの輪を適当に回転して、みんなが良い気分になるまで繰り返します。

このワークでは全く自己開示しません。しないのに良い気分になるというところが、ちょっと面白いです。自己開示するのも難しいくらい緊張しているときに効果的かもしれません。

テストデータをどっさり作るのに便利なSQL-Tip

テストデータをどっさり作るのに便利なSQL-Tipを紹介。

こんな感じで30万件のデータを作れます。

create table n ( v number(1) primary key ); … (1)
insert into n (v) values (0);
insert into n (v) values (1);
insert into n (v) values (2);
insert into n (v) values (3);
insert into n (v) values (4);
insert into n (v) values (5);
insert into n (v) values (6);
insert into n (v) values (7);
insert into n (v) values (8);
insert into n (v) values (9); … (2)

insert into TESTDATA(
    CUSTOMER_ID
) select
    n1.v || n2.v || n3.v || n4.v || n5.v || n6.v   … (5)
from
    n n1, n n2, n n3, n n4, n n5, n n6   … (3)
where
    n1.v < 3;   … (4)

drop table n;
commit;
exit

簡単に説明。

(1).テーブル n を作成。

(2).作ったテーブル n に数字の0~9(10件)をinsert。

(3).テーブル n を6回、直接結合(結合条件無し)して、10^6 = 100万件にする。
  1,000万件にしたければn n7を追加すればOK。

(4).テーブル n 1個だけを0~2に絞り込むことで、30万件にする。
  もっと半端な行数にしたい場合は、いったんキリの良い件数を作ってから
  不要な分だけdeleteすればOK。

(5).CUSTOMER_IDとして、000000~299999の30万件を得られる。

ちょっとアクティブモード

久々に忙しくなってしまったプロジェクト(お仕事)も終わり、息抜きしつつのインプットモードの期間を経て、最近アクティブモードになってきた。
10日間に2日間のセミナー受講、3時間のセミナー受講、勉強会参加×2というハードスケジュールの予定を消化中…。
筋トレもしちゃったりして、今までになく頑張っていると思う。ノっている間に色々チャレンジしていこうと思う。

OOコード養成ギプスを読んで

OOコード養成ギプス (少し親切な解説)を読んで。
9つの制限を守りつつ1,000行のプログラムを書けば、コードがオブジェクト指向になるそうです。

一見OOとは関係の無さそうな、CheckStyleとかMetrics系のルール付けが目立つのを見て、ベストキッド(原題:The Karate
Kid)という映画を思い出しました。主人公の少年が師匠からカラテを教えてもらって色々と成長してハッピーエンドという映画です。その師匠(日本人の老
人)は少年にカラテの技術を普通に教えずに、ペンキ塗りをやらせたりするのですが、そのペンキ塗りのハケさばきが実はカラテの基本動作の
練習になっていたのだ!というエピソードからの連想です。

OO
コード養成ギプスでは、目的を説明せずに練習させるような教え方はしていないのですが、なんか回りくどいというか、こういうのも"頭のフェイント"というのでしょうか。ベストキッドみたいに師匠がチェックしてくれれば問題ないでしょうが、このギプスだけを渡して放置しておくとヘンテコなコードを書くように育ってしまいそうな気がしました。ちょっと危険な感じですね。"取り扱い注意"です。

それにしても、かなりキツいのではないかと思います。1000行も書けば、本当に新たな世界が見えそうです。

追記:

(内容とはまったく関係ないですが)カラテカ繋がりで。 via idea * idea 

XDDPやってみた感想

5月のエントリ"「派生開発を成功させるプロセス改善の技術と極意」読んだ" に書いたとおり、XDDPを使ったプロジェクトがやっと終わったので、まとめておきます。

私が試したプロジェクトの条件:
ベテランメンバ2人、中堅メンバ2人、入社半年1人。
変更設計~画面テスト8人月分くらいを2ヶ月で。

良かったところ:

  • 残念ながらあまりメリットを感じられませんでした。
  • 後半かなり苦しくなってしまったものの、何とか納品できた、という感じです。まだ発注者様にて検収中なので品質の方は未確定ですが、感触としては悪くない感じです。ただ、メンバーが豪華だったのでXDDPのお陰と言うよりはメンバーのお陰…という感じ。

ツラかったところ:
変更設計書を書くのは思っていたより大変でした。変更設計書なしのPG工数を1として、

  • 変更設計書記述:1.2
  • 変更設計書使ってPG:0.5
  • 合計:1.7

という感じで見積もっていたのですが、結局2.0くらい費やしました。
見積オーバー分の内訳は、

  • 変更設計書記述:0.1
    • どうやって日本語で書くか、という表現を考えるのに結構時間を食いました。慣れの問題もあるでしょうが、日本語で書くとかなり冗長になってしまうのは変わらないと思います。
    • それと今回は、変更設計書をExcelで書いたのですが、やっぱりWordにしとけば良かった…と反省しました。プレーンテキストかWikiで書くべきだと思いました。
  • 変更設計書使ってPG:0.2
    • 変更設計書を結構頑張ってレビューしていたにも関わらず、PGして動作確認して初めて気づく不具合というのもかなり残っていました。だから「変更設計書の通りに書くだけ~♪」という状態にはならず、普通にPGするのとあんまり変わりませんでした。
    • 普通のPGだけなら回避するようなミスが増えました。同じ関数を2回書いていたとか、メソッドを書く場所を間違えていた、とか。

です。

次回試したいこと:

次回、変更設計書を書くときは以下を試したいと思います。

  • 変更設計書を書くときのストレスを減らす。WordもしくはTextを真剣に検討する。
  • 変更設計書の記述を概要レベルに留め、概要レベルの事柄をキッチリ書く。
  • あのフォーマットに惑わされて「設計書」であることを忘れかけていたので、普通の設計書のフォーマットで書いてみる。