気楽に生こうか

thrive on 「成長する、生きがいにする」

thrive on work 「仕事を楽しむ」

初めて見たときに、「これは！！」と思った熟語。「いつか使ってやろう」なんて感じで。
なんと言っても、「成長、生きがい」といった意味のものがそのまま「楽しむ」に直結してしまう感覚がいい。
英語って、時々ハっとするような意味や用法があるよね。言語マニアな人の気持ちが少しわかるｗ

1/30 THRIVE ON DEVELOPMENT という勉強会を、自分を含んだ有志メンバーによる開催というかたちで開いた。
いや、開けた、が正しいかな？

きっかけ

ことの発端は、TDD Bootcamp を受けて、今回の主催のひとり、友人のhtadaが「ペアプロさせてほしい」と言って来た事。
このときは、「一回ぐらいいいね、あの興奮が残っているうちに」ぐらいだった。
それを、もう一人の主催のtontonに話したところ、「面白いね、俺も参加していい？」
おお！と思って、「じゃあ、小さい勉強会に」と話を進めたんだけど、残念ながら時間が短すぎてお流れ。
けっきょくそのときは、htadaとは個人的に「McDonald's de TDD」をｗｗ
でもこのとき、tontonが「でも、勉強会は絶対にやろうよ！」という一言を付け加えてなかったら、たぶんそのあと突き動かされることもなかったんじゃないかな？
二人に後押しされたのか、二人を強引に巻き込んだのか不明だけど、自分の中にあった勉強会やりたい！が一気に高まったのは確か。

準備

やったことを簡単にまとめると、こんな感じ。

1. 打ち合わせ…ホントは顔を合わせてが理想なんだけど、お互いに働いていると難しいね。ということで、memememoというグループ共有できるメモサイトを使って、常時連絡状態を確立。（あんま活用できなかったかな？）
   
2. テキストの準備…今回は講師二人がそれぞれ自分の分担のスライドを準備。これが仕事の状態と相まって、なかなかしんどくも楽しい作業に。
   
3. 会場の準備と日時の決定…今回、めっちゃくちゃ迷走したー。けっきょくなんの工夫もなく、ルノアールの利用者の少ない店に。
   
4. 参加者集め…一番苦労して後輩たちを巻き込んだのは、何を隠そうhtada。自分は結局twitterでつぶやきまくるとか、地味ぃーな作戦orz まあ結果を見れば、11も集まったし！
   
5. 備品など、必要なものの準備…とにかく思いついたものは、即座に主催二人にメール！メール！
   

当日

いきなり名刺交換会

すまん、これは自分のミス。ちょっとマズかったー。
いきなりグダグダになって、結果的にスタートを遅らせることに。

朝会

みんなに立ってもらって、朝会タイム。簡単な自己紹介など。
呪いの人形を持ち出したのは、自分の常套手段。
あれで「今の発言権」がハッキリするし、場も和むし、朝会にはいいんだよね。

Start! Ruby

やばい！スライドがフォント違う！
フォーマット崩れてる！
やばい！！やばい！！

内心パニクったー…
Rubyの言語仕様やら思想やらを、小一時間でスプリントに説明。
けっこうボリュームもあるのに、一時間なんてムリあったかな、やっぱ。
スライドは文字ばっかだわ(反省点)
説明はやたら質難しい単語が出てくるわ(反省点)

じつは、一番伝えたかったのは、「開発はちゃんと"糊ツール"(自分呼称)をつくって整備してかないと、辛さを認めるだけだよ」ってとこ。Rubyは二の次で。
現場が大きくなるほど、こういったツール類は忌諱されて人力手当てをしがちだけど、それによる時間的損失や作業ミスで起こる損失は本来防がなきゃいけないものだ、と思うんだ。
こういう"糊ツール"が整備されて大きくなって、FWと一体化することで成功したのが、あのRoRの姿なんだと思ってる。

RSpecで宣言的なUnitTest!

RSpecについて、ひととおり。
ついでに、品質管理の方面でよく使われる、ブラックボックス・テスト、ステートボックス・テストの真髄をちょっと伝授。このあたりは設計思想の上達にも不可欠と考えたから、無理に盛り込んだ。

ただし、これ意識しすぎるとTDDのリズムを破壊しかねないから、ホント諸刃なんだよね。

TDDの紹介を先にやってからにすべきだったかなー。

TDDのご紹介

じつは本日の目玉は、この講義以降。
前段階なんてどーでもいい(ぉぃ)

htadaの講義は簡潔で的を射ていて、とてもわかりやすい！
これは見習わなきゃなー

TDDで何が変わるか！TDDの世界観みたいなものを掴んでもらうのに、ちょうど良かったと思う。

実践！RSpecでTDD！

課題を2つ準備、2チームに分かれてペアプロ＆TDDで「上司からのムチャな要求にこたえる」という想定でプログラミング開始！
ちょっと課題がRuby初心者にはとっつきにくかったのがマズかった。(反省点)
正直、"糊ツール"を実感して欲しい、という欲望が前面に出すぎたかも。

前準備で受け入れテストを書いてきたのは、色々と活用できたので高得点かな。
ただ、受け入れテストを書くのが遅すぎて、ちょこまかコーディング・ミスしてたのは失敗。(反省点)

ついでに、TDDでやることの難しさのひとつに、やっぱりロケット・スタートが難しいという部分があるなぁ、と思った。
今回はほぼ初心者が半数だったので、余計そうだったという面はあるけど。
このあたりはまあ、よっく考えると、"TDDだから"ってわけじゃないけど。第一人者に意見を聞いてみたいなあ。

今回の資料

当日やったテキストはここ。
Start! Ruby
ツッコミはこのblogに。

スライドは手直し中で、近日中にスライドシェアにUP予定。

もうひとつ、みんなから寄せられたKPTを含んだ、ToDev専用のWikiを作成する予定。

おまけ

色々な日程をかいくぐって参加してくれ、楽しんで帰ってくれたみんな、本当にありがとう！
おかげで、たくさん色んなことを喋り合えて、たくさんの勇気と元気をおすそ分けしてもらった。まるで元気玉だなぁ。
それと、今回ホント実感したけど、きちんと見てくれていて、きちんと批判してくれる友達の存在って、すごく大きい。
感動で涙が出そうになったよ(大げさ)
マニアな人たちがよくやる、愛の感じられない一方通行な批判は、正直好きじゃないけど…
自己批判と相互批判はとても大事だよね。

ちなみに、「第1回」が付いていないのは、「コケる方が大勝ちするより確率的に高い場合はあえて数字を入れない」という慣習に則っていたりなかったりｗ

勉強会を開催する手はずが、やっと整いました。
10名前後、身内を中心にしてやる、小さな勉強会です。

THRIVE ON DEVELOPMENT

あちこちの勉強会に参加して自分が色々なものを受け取るのはいいのですが、それに伴って「自分も伝えられるものはないのか？」というフラストレーションが高まり、重い、ほんっとに重い腰をやっと上げることができました。

年齢的にも、きちんと次の世代に色々なことを伝え残したい、という年齢にもなってきました。なにより、自分の直上の世代がそういう活動が手薄な世代だったので、強くそう思う傾向があるのかもしれません。

そして、いつかは働く開発者による働く開発者のためのGEEK Stationをつくってみたい、その思いへの、小さな小さな、ほんとに小さいけれども、第一歩じゃないかとも思っています。

コンセプトは、「手作り」と「技術も魂も」です。

テーマは

• Start! Ruby … Rubyの基礎講座
  
• RSpecで宣言的なUnitTest! … RSpecの基礎講座
  
• How To TDD … TDDの基本、そして実践
  

13:00から5時間、みっちりやる予定です。
Rubyは名前だけしってるけれど、実際どうなの？とか
UnitTest…めんどくせ！とか
でもでも、とにかく開発現場を楽しくしたい、仕事を面白くやりたい、という魂まではゆずれない。
そんな人が参加してくれたら嬉しいな、と思います。

ご参加をお待ちしています。

とあるビル。その一角。常に明かりが灯っていて、まるで不夜城の様。
「ちわーっす」俺はドアを開けて入った。「寒いっすねー、死ぬかと思った。」
「おー！○○クン！今日は早く上がれたのか」奥から佐倉さんがお茶を持って来てくれた。「ほら、とりあえず暖まれ」
佐倉さんはここの管理人だ。けっこういい歳をしている中年太りなオッサンだけど、この佐倉さんの事情通には誰も適わないんじゃないかな。
「シングルどっか空いてるかな？小一時間ぐらい集中してリファクタしたいんだ」
「今空いてるのはペアが1室だけだねぇ。んー、服部さんがあと30分ぐらいで帰宅時間じゃないかな？」佐倉さんはテーブルの煎餅をポリポリやり出した。また太るぞ。「それにしても、DexRouteだっけ。続くね。次の1.9.6はいつ出るんだい？」
「ん〜〜…」俺の手が勝手に壁一面の書棚からテキトーな技術書を抜いていた。「Jamesのやつがさー、わかってねえんだよ。『こっちの構造の方がイイ！』とかメール来てさ、forkもせずにpushしてきやがって。これが見たらヒドイんだわ…」
技術書に目を落とす俺。ここの品揃えは厳選されている。持ち込む人の張り合いもあんのかな？自分が『良書』と思った本を持ち込んでくる。そして俺みたいなのがチョッピリ得をする。
棚によっては「マネジメント」だとか「コーチング」だとかビジネス書っぽい本も並んでるけど、俺には今のところ興味がない分野だね。
お茶を飲みながら本に集中する俺。しばらく静寂の時間が流れる…。

「ふわ〜〜、ねみ」ガチャ、と部屋のドアが開いて、服部さんが出てきた。「やっぱ捗るわ、ここ。助かるねー」
「たまには早く帰らないと」佐倉さんがお茶を入れるためにそそくさと立ち上がった。「奥さんにアイソつかされるぞ」
「わかっちゃいるんだけどさ」服部さんはチョコレートに手を出した。だから太…まあいいや。「家に帰るとダメなんだよ、俺。一行も書けなくなるタイプ」
世の中そんな人もいるんだよね。とか言いながら、俺もアパートに帰る前にこっち寄っちまうクチだけど。
「今週のワークショップってなんだっけ？」
「金曜の夜に、M社さんとこのG言語教室2回目があるね」お茶を入れたきゅうすと一緒に…えっと、バカウケが増えてるんですけど？佐倉さん？「あとエーラブの人たちの『非同期協調とOOインタフェース』が土曜」
「エーラブやるのか…」ちょっと興味を持った。あとで申し込んでおこうかな。
「エーラブの方は、もう一杯じゃなかったかな」
チッ。

「Sakuさん、相談にのって！」もう一つのシングル部屋のドアが開いた。出てきたのは中井戸くんだ。「俺がメンテ続けてるアレさ、企業からオファー来ちゃったよ！」
中井戸くんは同い年なので、なんとなく意識してる存在だ。ライバル心？ちょっと違うか？
「そりゃめでたい！」佐倉さんが席を立った。「どんなトコが声かけて来たんだい？へー、bit社が…」二人で部屋に引っ込んでいった。
ここのサーバ環境はちょっとしたもので、M社とG社が協賛に入ってるおかげでバックボーンがけっこう豊かに使える。フリープランの足かせが少し軽くなる感じ。
それに、やろうと思えば小規模のデータセンターぐらいの設備が使える。
そのためか、署名入りアプリをここから発信している人も多い。
ネックは通信経路。ちょっと細めなので、人気アプリができるとアクセスを捌ききれなくなる。「N社をなんとか巻き込みたいんだよね」が佐倉さんの口癖だ。

それに、法律方面、会計方面と、各種方面が専門のボランティアの人たちがサポートしてくれるから、今みたいな時も対応が素早い。
彼らにしても、そこで独立法人化となるといいビジネスチャンスになるし、持ちつ持たれつなんだろう。
俺ら一般会員もいくらかの会費を払っているし、協賛企業からの寄付金もあるけれど、圧倒的な収入源はこのオファーがあった時に企業から入る紹介料、そしてボランティア有志で開発を続けてるシェアウェアツールの課金だ。
一応、企業ワークショップの時や会議利用の時は場所代をとる仕組みになってるけど、残念ながらさほどの額になってない。
こういった会計の面が全て公開されて運営されてるのも、俺がここを好きで利用している理由のひとつだ。

去年の夏はひどかった。ここからBotNetを広げようとしたバカがいたんだ。
気づくのが早かったから広まる前に対策を打てたんだけど、あの時偶然その場にいた俺は、正直ちょっと興奮した。
でもその後、犯人がじつは会員の一人だとわかった時の佐倉さんの落ち込み様は、見ていてつらかった。
あの時のみんなの頑張りがなくて、BotNetの根城化してしまっていたら…おそらくここは閉鎖していただろうな。
考えるとちょっと怖い。

今日はとくに何もせずにビルを出た。息が白い。
今年はどんな年になるんだろうか。また面白いヤツに出会えるといいな。
どうも男くさいのが玉に瑕だけどね…。
そして俺は明日のために、暗いアパートへと帰路を急ぐ。

---

はい、夢です。
自分的GeekStationの有り様です。
もちろん、こんな収入モデルじゃホントにやっていけるものじゃないでしょうねぇ、というのは承知の上(苦笑)
いいじゃん、正月なんだからさ！

「リーダーが必ず受け入れるべき3つの指針」(DIAMOND online) http://diamond.jp/series/sales_manager/10010/

ネットで偶然読んだ記事なんだけど、なんか「納得はできるけど賛成できないな、これ」と思ったので、ネットの片隅で勝手に反論。

【リーダーが受け入れる3つの指針】
　・部下はリーダーの30％しか仕事ができない
　・組織はリーダーの器以上に大きくならない
　・部下に決して弱みを見せてはならない

これ、それぞれ「と思うと、気が楽だ」って文言を入れるとしっくり来るよね。
読んでみて「そうそう、そう感じることはある」というのが納得できた部分。
「でも、それってそう言い切るのが良いことなの？」というのが賛成できない部分。
ということで、反論してみたい。
まあ、技術畑と営業畑とは全く別のものなので、お前が反論するな！という話はあると思うけどね。

ちなみに自分は、開発でリーダーにたった時は「自分はカレッジ型」であるということを最初に公言してしまう。性格的にも「親分・子分型」運営なんてできないし。

「部下はリーダーの30％しか仕事ができない」は「部下は自分の思っていることの30%ぐらいしか汲んでくれない」

仕事柄、営業の人とは付き合いがあるし、「どうして営業と現場とは理解し合えないのだろう」というのをいつも悩んでいる。
で、ある「人売りIT企業」の営業さんの話。

その営業さんは「とにかく人を売って案件数かせぐ」ことが得意で、いつも「営業の中で会議ばかりしてちっとも外回りをしない」人たちがいるのを不満に思っていた。
一方、不満に思われた方といえば、いつも「外回りして数を稼ぐだけで、きちんと技術者と案件とのマッチングをしていない」のを不満に思っていたらしい。
技術者的に頼りたいと思うのは、きっと後者だろうね。そこでその営業さんはずいぶんと悩み込んでいた。そのためにスランプになった。

ある日、その営業さんが社長と酒を飲んで、言われたらしい。「彼らのやり方は、技術者を幸せにさせようと努力している点で、とても正しい。そこは理解して欲しい。ただし、会社としてはそれでは回らないんだ。だからキミのような数を稼げる人も必要なんだ。会社としては両方とも居てもらわなければ、成り立たないんだよ」
身も蓋もなく言ってしまえば「キミは必要悪なんだよ」ってとこだろうけど、それでもこの営業さんはそれを聞いて元気になり、仕事へ前向きになった。

部下がリーダーの想定している(技術的/仕事量的/思想的)範囲と一致するのはマレだよ

そう、人は本当にそれぞれで、同じGoalをかざしても、そこへの立ち向かい方も色々なら、持っているモノも色々だ。まずそこをしっかり抑える必要がある。
技術の話になるともっと色々になる。ある人は設計は得意だけどコーディングで凡ミスをする、とか、ある人は環境設定周りは得意だけどなぜか設計能力はない、とか。
リーダーのやるべき事は、部下を30%しかできない人として扱うのではない。部下を一人ひとり見極めて、たとえ想定と違っていても適材適所に人をはめる事だ。できるなら本人にしっかり選択してもらった方が力になる。
そのために必要なのは、リーダーがGoalをしっかり見極めて全員の共通認識にしていることだ。それさえできていれば、チームはGoalへ向かえる形になる。(たとえイビツな形でも)
あとはもう、チームのハンドル捌きにかかっている。

へびの足。現場の人はもっと営業を頼りにし、営業をこき使うぐらいの勢いでいるべきだよ。

「組織はリーダーの器以上に大きくならない」ことなんてない

うむむ…部下を認めろ、は前の章でやってしまったな。では別の切り口で。

どれほどの現場で「このリーダー、使えねー」があることか。
けっこうこの体験をした人も多いんじゃないかな。自分もある。
そんな時にチームそのものがバラバラになった場合と、チームとしてはまとまってGoalできた場合とでは、いったい何が違うのか。

プロフェッショナルを自覚した部下をどれだけ囲い込めるかが、組織を成功に導くポイントだよ

チームとしてまとまった場合をよく見ると、プロフェッショナルの意識をつよく持つ人がいた、という事に尽きる。
こういう人が一人いると、その人が変わりのリーダー(影の支配者)となって取り仕切るようになる。複数いると、それぞれ協調し出して、なにか勝手に動いているようで全体としてはまとまっている、という面白い運動コラボレーションがおこる。

プロフェッショナルとそれ以外の違いはなんだろうか。
それはGoalを見出す選眼力、そしてGoalに到達するために有効ならどのような手でも手を尽くす貪欲さ、そして自己責任感の強さ、じゃないかと(個人的に)思う。

逆に、組織的に・リーダーの権限でキャップを設定してしまい、こういうプロフェッショナルな人の行動を制限するようになると、チームは勢いを落として減退する。大型開発でひじょうに多いのだが。

「部下に決して弱みを見せてはならない」で封じ込められるリアルな現状分析

叱咤激励で部下がシャキン！目標達成！すばらしい！！
でも違うんじゃね？
まあこれ、営業にありがちな典型的なノリだけどね。

でも、昔読んだ開発系のリーダー養成本でも同じことが書いてあった。
はっきり言おう。楽観主義と根性論で仕事する時代は終わったよ。

部下がリーダーの顔色を見て仕事をするのは、じつは「それ以外にGoalを見据える判断材料がないから」なんだ。

きちんと「見える化」しよう。そのうえで、GoalとVisionを持とう

さっきからGoalを持てと強調しているけれど、Goalを持つのはリーダーとしてではなく、チームとして持たなくてはいけない。
チーム全体が「Goalは何なのか」を見極めて、はじめて「Goalへ向かう以外の余計なもの」も明らかになる。

そして、Visionもチームとして持たなければいけない。ようは「どういうルートでGoalまでドライブする？」という点だ。
ひとつは「余計なもの」を極力・ギリギリまで削る努力をすること。
もうひとつは「有効なもの」をどんな些細なものでも貪欲に取り入れること。
これをやるためには、リーダーが頭で考えていたのでは絶対に間に合わない。自分の知識は限界があることを自覚しよう。
そのために、情報はなんでもチームで共有しよう。そして部下にはどんどん相談し、意見出し合える雰囲気をつくろう。
そう、「相談するのはOK！」なんて、まだぜんぜん生温い。mustなんだ。

Visionをしっかり見るためには、もちろん現状を全員の認識にしておく必要がある。どんな些細なことも隠し立ては無用だ。

そしてここが重要な点だけれど、これらを踏まえて「給水ポイント」を明確化しよう。
Goalまでとても長かったとしても、中継地点とそこへ到達するルートが頭にあると、人はわりと頑張れる。
そこでほっと一息つけると、次の中継地点に向かう大きなバネになる。
切羽詰ったプロジェクトほど忘れやすいことだけれど、大事だ。

時々、情報を独占することと意思決定を独占することで自己の権力増強を図る人がいる。
こういうリーダーの下では、チームは絶対に大成しない。チームメンバーにいるだけでも有害だ。

どうも、この「部下に決して弱みを見せてはならない」の章がいちばん嫌いだな。ありがちな「無理を通せば道理が引っ込む」を強調しているようで。

なんというか

この片山という人はよほど優秀な人なのだろう。
色々部分的にはいい事も言っていたりするのだけれど、全体的に他人を見下している雰囲気がある。

一方で思うのは、こういった論が気持ちにひびいてしまう背景に、日本によくある「プロフェッショナルじゃなくても仕事になってしまう」傾向があるように思う。
たとえば、この記事がおそらく対象としているだろう係長・課長クラスには、たいていの会社ではそれほどたいした人事権がない。
開発プロジェクトのリーダーともなれば尚更で、ほとんどの場合は寄せ集め部隊で出発する。（それが社外/社内関係なく）
そのために、「この人は完全にプロジェクトにミスマッチなのでは」と思っても、使わなければいけないという傾向がある。
一方で、「この人がプロジェクト的に欲しい」と思っても、なかなか融通が利かない傾向もある。
これって、本来は誰にとってもとても不幸なことだと思うんだけどね。

色々読んでいると、この人も各論・実践論ではちょこちょこといい事を言っているので、そこは学んでいいだろう。
でも、この精神論まで模倣するのは、とても危ない気がした。

ここで書いてることは理想論？
うん、そう、自分の中にある理想論さ。
でも、誰かが理想論をきちんと言わなければ、誰がそれを理想論だとわかるんだい？

前のアーティクルで自分で言及してなんだけど、ものすごーく気になったので、思考実験。
規模は数人3ヶ月を想定してみた。

従来の障害収束曲線

障害収束曲線は色々呼び方があって、最も短い呼び方ではバグ曲線とか呼んだり、Wikipediaでは信頼度成長曲線という名前で出ていたりする。
基本は「テストを重ねていけば、自然と障害検出数が低くなっていくよね。」という「現象」を取り扱ったもの。
図としてはこんな感じかな。



図は、製造フェーズ後にテストフェーズが「単体テスト」・「結合テスト」・「受入テスト」と分かれている事を想定している。
(テストフェーズも、現場や企業の慣習によって大きく扱いが違うので、この程度にした)

「恣意的だ」とツッコミが入るだろう部分を先に解説。

• 件数多くね？ … 過去3ヶ月もテストフェーズがある場合、これぐらいじゃなかったかな？という経験則。(件数に厳密な意味などない)
  
• ブレがないね … わかりやすくするため。
  
• 各テストフェーズを分けるべきだ … 自分が経験した殆どの現場では、テストフェーズ全体で障害収束曲線を測るのが一般的だったので、それに習った。
  
• なんで横軸が日付なの？ … 自分が経験した（以下略）。
  

この図で「わかる」のは、単体テストから受入テストまでしだいに曲線がなだらかになっていき、受入テストが完了するころにはほぼフラットになっている(障害検出がされなくなっている)という事だ。

CI結果を障害収束曲線に！

同じようにして、次の条件でグラフを描いてみた。

• チーム全体がTDDを前提に開発を進めている。
  
• 指標に使用したのは、CIでビルド&テストが失敗した場合に、その失敗件数を障害件数と同等として使用した。
  
• CIでの自動ビルドは、簡略化のために日に1回とした。
  

描いてみてわかったこと

この縦軸に出る「件数」って、「障害」の数じゃなくて「メンバの作業ミス」の数だよね

TDDを前提とすると、少なくともCIで実行するテストは常に「すべて通るハズのもの」であり、基本的にはデグレードしないことをチェックしている側面が強くなる。
そのため、ここでなんらかのエラーが起きるのは、たいていは単純な作業ミスに帰結することが多い。だから件数も少ないし、当然、日数とともに作業に慣れてくるので、ミスも少なくなる。
作業ミスとして現れるのは、だいたいこんなところかな。

• ビルドエラー … マージのさいのコンフリクト解消を失敗する等で、コードが一時的にコンパイル不能な状態に陥る。
  
• テストエラー … 原因はいくつかからなる。
  
  
  
  1. テストを実行せずにコミットした。(TDDに慣れない、切羽詰っててそれどころじゃなかった等)
     
  2. マージのさいのコンフリクト解消を失敗した。
     
  3. ローカルでのテスト環境とサーバでのテスト環境とに差異があった。
     
  
  

また、テストエラーも、Mockをあまり使わずにテストコードを書いていた場合、共有されやすいクラスを修正するとエラー範囲が爆発的に増える傾向があり、Mockを適度に使用するとそれが収束する傾向がある。

うん、まあ、なんていうか。
障害収束曲線という代物は、TDDを前提とした開発の場合、あまりにも合わない、というところが明らかになった感じかな。

※ もちろん、元請企業が「単体テストによる障害数」を求めているときに、これらの数字を使う/使わないは政治判断だと思う。その場合でも、「この件数とは何なのか」を自分できちんと把握しておくことは大事だ。

ただし

この障害収束曲線も、「カスタマテスト」および「QAテスト」で"(有効な)チケットを切られた数"に対して行う分には、十分計測する意義はある。
その場合、よりウォーターフォールに近いか、Agile/インクリメンタル開発に近いかが、件数の大小に現れてくるだろう。

おまけ：従来型ウォーターフォール開発で本当に障害収束曲線を描くと

最後のヘビの足。

障害収束曲線って、ホントに全テストフェーズを通してこんなキレイな曲線になるの？という点。
結論を言ってしまうと、障害収束曲線があのようにキレイな線になるのは、1つのテストフェーズに閉じた場合だけで、何段階もあるテストフェーズを通してあんなキレイな線になるはずがない。



こんな感じに。

• テストを律儀に実施した/適当に省いた に関係なく、各テストフェーズ内でテストを繰り返す間は、曲線は次第になだらかになる。
  
• だが、次のテストフェーズに以降した段階で、今までのフェーズになかったファクターが"当然"加わるため、また曲線は急勾配を描く。
  
• とくにウォーターフォールでは、顧客受入れ時の要件変更のかなりの部分が「障害」として計上されるため、その傾向に拍車がかかる。
  

この特徴をしっかり理解しておこう。
現場ではよく「前のフェーズでテストしたのに、なぜ今フェーズでまた障害が発生しているのか」が技術者の問題として槍玉に挙げられる。(そして障害票でしっかり「反省」させられる)
だがそれは、テストのスコープも違うし、ファクターも違うのだから、発生するべくして発生した障害でしかないのだ。

開発現場で出会う人をパターン化してみた。
もちろん、自分の経験の範囲なので、足りない部分も多いかと思う。
たしか、こんなのをまとめた文献があったような…？

人は時として複雑で、複数のパターン兼ね備えている人もいる。良いパターンを複数持っている場合、その人を逃さないようにしよう。
良いパターンとアンチ・パターンを兼ね備えている人は、その人の重要度から判断するしかないだろう。

パターン

ここに上げる人は、ぜひチームに一人は欲しいタイプ(ライト・スタッフ)の人だ。
正直、このような人が集まると、けっこう無茶なプロジェクトでも、なんとか乗りこなしてしまう。(日本の大規模な(WF型の)開発現場は、じつは*恥ずかしがりながら**暗黙的に*この効果に頼り切っている)

■リーダ

別名

指導者、支配者、声の大きな人(※物理的意味ではなく)

特徴

役職としてのリーダと一致するかは、現場による。
ある程度技術に通じており、プロジェクトのゴールを示せる人。
また、チーム・メンバーをうまく誘導できる人。
ある程度はスキルでカバーできる。
これを天性の才能でやってしまえる人を、自分は深く尊敬する。

■サービス・エンジニア

別名

業者、業務スペシャリスト

特徴

技術には少々疎いが、かわりに開発対象とする業務に詳しい/業務をより深く理解している人。
このタイプの人は、過去何度も同種の業務の開発を経験しているか、業務プロセスの掌握が人一倍早い。
そのため、顧客(エンド・ユーザ)から要件を聞き出すさいに、業務用語で会話ができたり、業務プロセスに敏感になり、システム化の境界面を判断できる。
ほぼスキルのみと言ってもいい。

■アーキテクト

別名

グル、導師

特徴

技術に通じているだけではなく、その思想に通じている人。
このタイプの人は、技術を設計思想的側面から掴むのがひじょうに上手く、そのため他のメンバーより素早く習得できるという特技を持つ。
そのため、顧客(エンド・ユーザ)から要件を聞き出すさいに、技術的可能性や代替案をほぼ即答できる。
また、理論が補強されているため、他のメンバーを指導するさいも手際がいい。
ほぼ天性の才能と言ってもいい。

■ファシリテータ

別名

会議の主、教え上手

特徴

じつは教え上手なのではなく、他のメンバーに「気付かせる」ことがとてもうまい人。
抱えている課題、持っている資質に気付いた人は、能動的に動けるようになるもので、そういう意味で貴重な人。
このタイプの人が活躍すると、会議や学習会といったものがとてもスムーズにいく。
そのため、顧客(エンド・ユーザ)から要件を聞き出すのも上手いことが多い。
スキル的に身につけている人もいる。

■アシスタント

別名

サポータ、お母さん

特徴

チームのメンバーのことをよく見ていて、必要なサポートを的確に行える人。
また、会議などで今チームに必要なことを自然に提案したり、実際に実践できる人。
ほぼ天性の才能だと思うが、スキル的に身につけている人もいる。

■スター・プレイヤ

別名

スーパーマン、ギーク(※敬称的意味で)

特徴

技術に通じており、他のメンバーより数倍早く・上手くプログラムを設計していける人。場合によっては、特定の言語などに特化している人も多い。
技術のトレンドにも通じているが、時々通じ過ぎていてスケープ・ゴート化している人もいる。
このタイプの人が一人いるだけで、プロジェクトの進み方がかなり違うし、コードの整理のされ方もかなり違ってくる。
完全に天性の才能なため、とても貴重な人。このタイプの人は絶対にプログラムから離してはいけない。

■ムード・メーカ

別名

チア・リーダ、マスコット、ピエロ

特徴

チームの雰囲気をよい方向に変え、他のメンバーから慕われている存在の人。
このタイプの人がひと言口にするだけで、場の雰囲気がとても和らき、時に前向きに元気にさせる。
完全に天性の才能なため、とても貴重な人。多少プログラム設計能力が劣るからといって、追い出してはいけない。

■プログラマ

別名

コード・メーカ

特徴

スーパー・スター程ではないが、プロジェクトの対象とする技術に通じており、プログラム設計に長けている人。
このタイプとスター・プレイヤーとをチーム/バディにすると、時としてとてつもない相乗効果を発揮する。
反面、自分の持つ技術以外に対しては、意外に興味を持ってなかったりもする。
いわばチームの裏方と言ってもいい。

アンチ・パターン

これから上げるタイプは、はっきり言ってチームに障害をもたらす人だ。
もし人事権を持つならば、早目に解放した方がいい。
人事権がない/じつは立場上は上司といった場合は、ひたすら耐えるしかないのが辛いところ。

■コーダ

別名

人数合わせ、奴隷

特徴

言われた事をただこなすことを得意とする人。残業や徹夜を打診すると、素直に従う。
全体的に、作業時間は突出して多くなる傾向があるが、それに見合った生産性は期待できない。
プログラムを設計できないのもこのタイプで、指示通りに書くことを得意としている。
逆に言うと、指示しないとやらない。
しかたなく使う場合も多いが、進捗がシビアな場合は解放した方が良い結果になる。

■フォリナ

別名

部外者、傍観者

特徴

なぜか達観した態度をとる人。ときに強い皮肉を伴っていることもある。
自分の意見を主張するわけでもないため、位置づけ的にはコーダタイプに近いものがある。
もし他メンバに悪い影響があるときは、解放することも考えよう。

■ローン・ウルフ

別名

一匹狼、人嫌い

特徴

他人に溶け込むのをとことん苦手とする人。
ときにコミュニケーション不全で障害を出してしまうこともある。
ひじょうに疲れるが、このタイプの人と一緒に仕事をするときは、あらゆる手段で意思を伝え、汲み上げる必要が生じる。
もし他メンバに悪い影響があるときは、解放することも考えよう。

■ミスマッチャ

別名

場違い、畑違い、○○畑の人

特徴

開発対象に疎く、技術的にも疎いが、なぜかアサインされてしまった犠牲者。
プログラマタイプの人も多いが、大体において習得するよりも先に進捗の悪さが露呈してしまう。
コーダタイプの人物の場合は要注意となる。
なるべくプロジェクトから解放してあげた方が、お互い幸せになる。

■フォーチュン・テラー

別名

不安屋、諦めた人

特徴

何が原因かはともかく、プロジェクト/チームに対して強い絶望感を持った人。
無茶なチーム運営の犠牲者である場合も多いが、元々の思考的にこうなっている人もいる。
このタイプはそのネガティブな雰囲気を周囲に撒き散らし、巻き込んでしまう。
パターンに上げた人がこちらの側(ダーク・サイド)に転化してしまうと、そのインパクトは大きい。
なるべく早くプロジェクトから解放してあげよう。

■トリックスター

別名

反抗期、天邪鬼

特徴

なぜかチームの方針に事あるごとに楯突く人。
このタイプは、チームやプロジェクトが上手くいっているかよりも、自分の考えていることが反映されているかを最重要視する。
その考えもコロコロと変わる場合、他メンバーを翻弄して疲弊させる。
なるべく早くプロジェクトから解放しよう。

■スタンピード

別名

暴走、暴徒

特徴

プロジェクトやチームに関係なく、自分のやりたい事をやり出してしまう人。
これも無茶なプロジェクトチーム運営による犠牲者の場合も多いが、自分の技術力を誇示したいだけの場合もある。
ローン・ウルフタイプを伴い他メンバから倦厭されたりする。
プロジェクトと関係ない事をやっているだけなら利も害も生まないが、プロジェクトに関係するところをやり出すと被害を出しかねない。
なるべく早くプロジェクトから解放しよう。

TwitterでこんなTweetが流れた…
エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・

UnitTestのエビデンスって…なに？

一般的にテストのエビデンスというと、次の2点を指す。

1. テスト手順を明らかにするもの（ex. テスト設計書、テスト仕様書、...）
   
2. テスト結果の証拠（ex. 画面ハードコピー、DBスナップショット、...）
   

UnitTestでは、これはこのように解釈できる。

1. テスト手順を明らかにするもの ＝ テストコード
   
2. テスト結果の証拠 ＝ 今実行すればテストが全てグリーンになること
   

これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。
なぜUnitTestはいつまでも理解されないのだろう。

余談。これらのことは、Seleniumなどを使って反復可能なテスト（一応結合テストにあたると思う）を実施する場合にも当てはまるようになる。

微妙に食い違う認識

テスト実施の時期に対する認識

テストを実施する時期…古典テスト方法では、これはいつでも「テストを実施した時点」であった。これがテスト自動化の登場・一般化で覆された。
自動化され反復可能になったテストでは、テストを実施する時期は「いつでも」になった。つまり「今動くこと」が重要になったのだ。
これがパラダイム・シフトになった。

従来の手動駆動テスト手法

• テストを実施したタイミングでのエビデンスが、必ず残っていた。
  
• そのエビデンスは必ずエラーを含み、実施を重ねるごとにエラーが少なくなっていく現象が見えた。
  
• テスト・エビデンスを追うことで、時点ごとに（スナップショット）「テストがどういう結果になったか」をチェックできた。
  
• 障害収束曲線（ほらこれだ！）を「計測」でき、それによって「テストの充実度」を間接的に観測できた。
  

反復可能なテスト自動化

• テストは常に動いているため、今現在のエビデンス(オール・グリーン)以外(要するに過去の結果)は重要ではなくなった。
  
• テストは常に動かせるため、コード作成とともにテストするように手軽になった。
  
• コード作成とテスト実施を同時に行うため、コードの完成と完璧なテストが同じタイミングで揃うようになった。
  
• 障害収束曲線は決定的に意味がなくなった。
  

コードというものが何かという認識

ここには、古くはクヌース先生等の時代から続く宗教戦争の歴史がある。

従来の、とくにウォータ・フォール型開発においては、コードというものは「最終成果物」であり、それは「製造」の結果でしかないとみなされる。
製造物のクォリティは「テストを通るか（条件を満たしているか）」のみが重視され、コード内部の整合性についてはほとんど重視されないようになった。
この視点で見た場合、UnitTestのような「コードで記述されたもの」は「余計(余分)な成果物」以外の何物でもない。

しかし一方でこれを戒め、「コードは一番詳細で唯一実行可能な設計書である」とする一派が従来からいた。この従来からある主張が、UnitTestの登場で大きく花開いた。
コードの設計書的側面が、テストによって補強される現象がおこった。
TDD/BDDでは、コードはテスト可能なまでに整理されることが前提となり、実施者は誰もが整理されたコードを書くようになった。（よく逆に考える論者(きれいなコードを書ける技術者しかTDD/BDDは実践できない)がいるが、それは違う）
そして、テスト・コードがインタフェースの詳細な仕様を表明するようになった。これがどのようなコメントよりも有言なことが確認されるやいなや、いわゆる詳細設計書を駆逐するのはおろか、コメントさえも駆逐しかけている。

何にバグが潜むのかという認識

ソフトウェア開発で不文律とされているものに「コードにはバグが存在する」というものがある。これには誰も異論がないだろう。

手動駆動テスト手法においては、その反復性の低さから「すべてのコードにはバグが存在する」という認識が強い。
バグが発生した時にそれを修正するとおこる、デグレードという現象もこの認識を補強することになった。
この認識に立っている人物は、UnitTestによるテスト・コードにもバグが潜んでいるのが当然だ、という見方をしている。テスト・コードは信頼できないものにしか見えない。

テスト自動化で反復可能になると、それが肌で感じられるほどに明らかになったことに「テストしていないコード・条件にこそバグが存在する」ということだ。
デグレードはヒューマン・ミス以外にはほぼ発生しなくなった。
この認識に立てると、コードの完全性をテスト・コードに依拠するようになる。そして、ガンガンとコード改善に手を出せるようになる。

テスト・コードにはバグはあるのか

はたしてテスト・コードにバグはあるのか？
以下の視点でみた場合、テスト・コードにしても相変わらず"バグ"はある、と言わざるをえない。

• テスト内容に抜けが発生する可能性がある。
  
• テスト内容に間違いがあり、その間違いを見逃す可能性がある。（偶然に結果が一致する場合に多い）
  

だが、これらはUnitTestだから起こるという類のものではなく、手動駆動テスト手法においても、十分起こり得るものだ。
そのため、これをもってUnitTestを無効だと主張するのは無理がある。

そして重要なことだが、次の点は完成した状態のUnitTestでは起こらない。

• テストが動かない。
  
• テストが誤動作する。
  

なぜ起こらないと宣言できるのか。それは、UnitTestにおいてはテスト・コードは100%通るからだ。カバレッジ率100%というのは実コードではなかなか難しい課題だが、テスト・コードにおいては誰でも完璧にその状態にできる。
そしてもうひとつ、テスト・コードは従来にないほど繰り返し実行される。この反復実行がまた、テスト・コードを頑強にする。

開発者は都合の悪いことには目をふさぐ？

よく言われる批判のひとつに、「開発者は都合の悪い部分をテストから無意識に排除する性質がある」というものだ。
だが、これらは原因がはっきりとしている。

1. そもそも気づいていない。
   
2. インタフェースに対する認識の低さから、インタフェースを満たすようなテストを行えてない。
   
3. 反復性の低さから、一度通ったテストを省略する衝動に駆られる。
   

最初の問題はもう、どんなテスト方法をとっても検出はムリだ。
二番目の問題は技術者の一定の訓練・経験を必要とするが、UnitTestの方がダラダラ書きができなくなりインタフェースへの意識が高まるため、UnitTestを行うことでより強力に訓練できる。
三番目の問題は反復性を高め常時実効するUnitTestではおこらない。

どう立ち向かうか

味方にしてしまおう

まず、理解していない人には十分に反復テストを理解してもらう努力をする必要がある。

• UnitTestの場合は、それが「単体テスト」であり、手でやってもコードでやっても開発者が主体でテストしている事に変わりないことを理解してもらう。
  
• Seleniumなど結合テストの自動化の場合は、従来テスト設計書でシナリオを用意してやっていたことを自動化しているにすぎないことを理解してもらう。
  

そのために、次のように働きかけるのはどうだろうか。

1. まずテスト・コードを見てもらい、どの部分がどのような事をやっているか概要を説明する。
   
2. じっさいにテスト・コードを実行し、テストがすべて成功する瞬間を見てもらう。
   
3. 目の前でTDDを実践し、テストが失敗から成功に移り変わる様子を見てもらう。
   

現場に近い人間ほど、上記を目の前にし「TDDを体験」することで認識を改めてくれる傾向がある。
残念ながら、現場から遠くなるにつれてその人物のアンテナの感度がより重要になってくるようだ。

CIサーバを立てよう

Hudsonのような本格CIサーバでもいいし、スケジューラでバッチを使ってAnt(NAnt)を定期的に実行するようにするのでもいい、またAntを手動起動するのも手だろう。
とにかく、次の手順を自動化してしまう。

1. ビルドを実施する
   
2. テストを実行する
   
3. テスト結果をHTML形式で出力する(最近のUnitTestとAntの組み合わせではほとんどのもので可能なはず)
   

これだけで、テスト毎にエビデンスを残すとか障害収束曲線の判断元がほしいといった要請には対応可能だ。

また、Seleniumなどは画面ごとのスナップショットを保存するような改造もWeb上で公表されている。積極的に活用しよう。

結合テストを強くする

自動で結合テストをしようが、手動駆動テスト手法で結合テストをしようが、結合テストという視点は大事だ。
Agileではこの時に顧客サイドに使用シナリオを書いてもらう、リアルなテストを行うプラクティスがある。
個人的には、より結合テストを強固にするためには（予算との兼ね合いもあるが）、これに加え、やはり「危険な匂いを感じ取れる」職人気質なテスト技術者を招きいれ、シナリオ作成に参加してもらうのが良いと考えている。
またそのうえで、反復しないテストの実施を職人テスト技術者に行ってもらうのがより望ましい。
これをモンキー・テストと言ってバカにする傾向もあるようだが、やはり人間は、実際にアプリケーションを使ってみて初めて気づく、というものがある。
ただし、これを行う場合、テストに失敗したものは自動テストシナリオに組み込む、というタスクを忘れてはいけない。

最近の経験から

最近の経験で、技術者たちの頑迷な強い抵抗に合い、UnitTestを導入できない、という事があった。
仕方なくUnitTestを捨て、従来のようにテスト・フェーズを厚くする手法に切り替えた。(顧客の強い要望により、WF形式での開発だった)
その結果、何がおこったか。
メンテが難しいほどに長い「メソッド」の乱立。
バグを修正するたびに起こるデグレード。
いつまでも終わらないかに思えるテスト・フェーズ。

システムは苦心惨憺の末に大改造して納品した(あらためて書き上げたUnitTestと一緒に)。だが、短い開発期間だっただけに、この時の開発-テスト・フェーズは完全に失敗だった。

TDD/BDDを実践しようとしている人は、それが絶対的に正しい行為だと自信を持ってほしい。
結合テストの自動化を目論んでいる人は、それが絶対的に正しい行為だと自信を持ってほしい。
それはシステムを迅速に仕上げる助けになるだけでなく、システムの品質をより高みに置こうとすることなのだから。

この文章は、Twitterでちょっと盛り上がった朝会のアンチ・パターンについて、勝手にまとめ、補足したものです。

朝会のあり方については、M・ファウラー氏の「朝会のパターン：立ってるだけじゃないよ」や、オブジェクト倶楽部の「プロジェクトファシリテーション実践編：朝会ガイド」(PDF)を参照してください。

運営に関するアンチパターン

座ってやっている

フォース

報告が詳細になりすぎている。時間がかかりすぎている。そもそも場所がない。

対策

立って開催することを呼びかける。
ただし、諸事情でどうしても立ってできない場合は、なるべく短くなるように全員が心がける。

シーンとしている

フォース

朝会全体に威圧的な雰囲気、または陰鬱な雰囲気ができている。プロジェクト進行がうまくいっていない。

対策

朝会を行う意義をもういちど全員で確認する。

その他

朝会以前にプロジェクトの建て直しをはかる。

誰も他人の言う事を聞いてない

フォース

朝会で報告することが毎回多すぎる。他メンバーの状況を把握すると自分に仕事が降りかかる。

対策

朝会で言うべきことを整理し、意思統一する。
ファシリテータは朝会が仕事振り分けの場ではない事を徹底する。

最初か最後にリーダーのご高説が入る

フォース

朝会をトップの意思を伝達する場と勘違いしている。

対策

朝会を朝礼と勘違いしない。
ファシリテータはリーダーが演説を始めたら止める。
上記参考文献をファシリテータ・リーダー自ら読み直すこと。

責められる

フォース

朝会が進捗の責任追及の場に転化してしまっている。

対策

他者が報告中は口を挟まないように徹底する。
ファシリテータはリーダーの言動に暴走が見られた場合、注意を喚起する。

その他

リーダーは報告者が報告してくれたことにまず感謝するクセをつける。

そもそも二度手間

フォース

他に日報・時報で作業状況を提出しなければいけない。その時間が業務時間内に保障されているわけでもない。
メンバーが状態を共有するのを苦痛に感じている。

対策

週報、日報をやめる。

その他

諸事情でやめられない場合、週報、日報を全員に開示する方法を検討し、そちらを優先する。

しゃべるメンバーが偏っている

フォース

朝会を自分の意思を伝達する場と勘違いしている。自
己アピールの場と勘違いしている。

対策

ファシリテータは報告の時間を短く区切り、計測する。(30秒以内が妥当)
他者の報告への口出しは朝会の解散後とするよう、徹底する。

@holic

報告内容に関するアンチパターン

問題点のあり/なしを言わない

フォース

うまくいかないのが自分のせいか対象のせいか切り分けできていない。作業報告の中に混ぜてしまっている

対策

問題点はどんな小さなものも報告するよう徹底する。
ファシリテータが報告のなかから問題点をみつけ、指摘する。
本人が問題点に気づくよう、粘り強くファシリテートする。（「困ってることはありませんか？」と尋ねるなど）

@kkd

遅れているか、進んでいるかが重要ポイントになっている

フォース

朝会を進捗掌握の場と勘違いしている。

対策

朝会の報告内容を「やった事」「やる事」「問題点」に絞るよう徹底する。
ファシリテータは朝会で進捗の話が出たら、注意を喚起する。
その他
リーダーは普段から「進んでいるか/遅れているか」と聞くのではなく、「期日に間に合うか」と聞くクセをつける。
そもそもの進捗管理をパーセンテージ主義から成果物主義へ移行する。

メンバーに関するアンチパターン

実施に反抗的なメンバーがいる

フォース

朝会の利点が理解できていない。
朝会が朝礼化してしまっている。

対策

朝会の意義をメンバー全員で徹底的に論じ合う。
上記テキストも活用する。

恒常的に特定メンバーがいない

フォース

ムリが続いてプロジェクトが疲弊している。
朝会が形骸化してしまっている。

対策

特定メンバーに高負荷がかかりすぎてないか注意する。
特定メンバーというのが大多数ならば、朝会の意義、重要性を再確認する場を設ける。
特定メンバーの悪癖の場合は、ファシリテータがきちっと注意する。

恒常的にリーダーがいない

フォース

ムリが続いてプロジェクトが疲弊している。
朝会が形骸化してしまっている。

対策

リーダーに高負荷がかかりすぎている場合、リーダーは積極的にメンバーに仕事を任せるように対策をとる。
リーダーの悪癖の場合は、ファシリテータが注意する。もしくはリーダーに対する監督権限がある人物に相談する。

朝会はプロジェクトがうまくいくための重要なプラクティスですが、それでも「うまくやるひとつの方法」でしかありません。
もしメンバー全体が朝会そのものに疲弊してしまっているなら、いちど廃止することも検討しましょう。

なお、各内容についてはご意見上等です。

本当に久々の更新。
自分が腐りそうだから、というのは内緒。

自分のプログラムの原点。

最初は中学生のころ。ファミコンが普及し、売れまくっていた時代。古いね。
当時、友達がそのファミコンを手に入れ、一緒にソフトを一本買った。
スーパーマリオだ、なんだと周りが騒いでいた時にそいつが買ったのが、「ファミリー・ベーシック」だった。どうにも渋いね。

でも、それがコンピュータ初体験な二人には新鮮で、二人して雑誌とにらめっこしてソースを打ち込んだり、ソースの改造をしたりして明け暮れた。
上半身がマリオで下半身が戦闘機のヘンキャラを作ったりとかねｗ
当時はゲームも作ろうとしたけど、そこまでの力がお互いになくて断念したな。たしか疑似3Dシューティングができないか？とかムチャなことを考えていたようなｗ
でも、コンピュータの動作を自分の意思で変えられる、制御できる、という魅力にこの時とり付かれたのは確かだ。

高校に入って、ムリしてMSX2を買った。自分の全財産で。当時はいた彼女にモーレツに怒られ、すねられたのは余談ｗ
当時はMSXマガジン、MSXfanという2大専門誌が発行されていて、MSXはちょっとした盛り上がりを見せていた。
とくにMSXfanで流行っていたのが、1ページプログラミング。あらゆるテクニックを使って1ページに収まる量にコードを縮めるその遊びは、ときにマシン語が入り、ときにそれをVRAM展開し、といったひじょうにこった物が多かった。
当時はただただ「世の中には凄い人達がいるな、こういう人がプロになるんだろうな」と思いつつ、サルのようにソースを打ち込んでた。

その中に、「ホンモノのプロ」が作った、パズルゲームのちょっと長めのソースが公開されたことがあった。
「なんだこれ？」読んでみて落胆した。
「俺にも読めるし、この程度だったら書けるよ。プロってこの程度？」
そう、そのソースはあまりに読みやすかった。
そして、実行速度もさほど悪くはなかった。
とりあえず打ち込んだ。
遊び倒した後は改造した。なにせ自分で書ける程度のソースだ、手を出さないわけにはいかない。
キャラを変え、ルールを変え、とにかくごちゃごちゃといじった。やがてソースは汚く変形していき、改造不可能になった段階で放り出した。

このプログラムと出会えなかったら、たぶんコ業界に入ろうなんて思わなかっただろう。
そう思わせたのは、Cを学び出してからだった。
ようこそ、構造化プログラミングの世界。すべてを整理整頓できる世界へ。
ロジック本を読んだ。プログラム書法を読んだ。無我夢中で吸収した。そして気づいた。
そうか、わかりにくいテクニックを駆使するのではなく、わかりにくいロジックをなるべくわかりやすく書く、それができるのがプロなんだ！
何かが変わった。プログラムに対する姿勢だろうか。その時、あの「ホンモノのプロ」がつくったソースの偉大さを知った。
十分にわかりやすく、そして十分に実用的。単純なBasic文だけを使い、それを果たしていたのだ。
それを弄繰り回して冒涜していた自分の行動に笑った。
快くソースを公開したプロの心意気に感じ入った。おそらく、当時のやもすると裏技的テクニックだらけが推奨されるような印象のあったアマチュア・プログラマーに、何かを伝えたかったのだろう。ソースのかたちで。

これが自分のプログラムの原点。
もうプロの道に足を入れて、長い月日が経った。
自分ははたして、あの時のプロに追いついたのだろうか？

C/C++のポインタの機能--変数の場所（アドレス）(zdnet)

これはひどい。あまりにもひど過ぎる。

ライター氏は何もポインタを理解していない様子。指摘されても指摘点がわかっていない。

ググるといくつも本を出しているライター氏のようなのだが。

日本人技術者の技術力が落ちてきているとは思っていたが、ここまで来たということなのか、はてさて……