満足せる豚。眠たげなポチ。

で、肝心のBDDですが、これは確かに実績を上げてました。RSpecとSeleniumを使うようになって格段にバグも減ったし、「何をやってるか知りたければまずSpecを見ろ」っていう習慣も自然に浸透したし、LLに不慣れなベテランプログラマや新人プログラマを含む混成部隊でもペアプロのお陰で開発速度を維持できたし全体の技術水準も上がりました。

あと余談だけど、「Specのないコードを書くときは上長に申請書を提出させる」とか「ペアプロ時にはナビゲータはピコピコハンマー装備」とか、今回の名言「わかんないやつは黙ってろ」とか、本当にやっちゃう人ですからねyuguiさんは。実際に。そこに痺れる憧れる。

via RubyKaigi 2008に行ってきた

以上、個人的なメモ。

最近、自分でコードを書くときはよほど小さなツールでないかぎり、ほとんど BDD で開発している。BDD の体感的の感覚としては、森博嗣氏のこの話が近いと思う。

「どうしても、思いどおりに小説が書けません。どうしたら、良いでしょうか？」と尋ねられることも少なくないのだが、そういうときは、「思いどおりに書けなかった小説を見せて下さい。何作くらいあるんですか？」ときき返す。１作も書けていない人が多い。１作も書いてないのに、どうして思いどおり書けないなんて言うのだろうか？　書いてから悩めば良いではないか。書けない書けないと悩む人がいるけれど、書けないなんてことはない、なにかは必ず書ける。幼稚園児だって書ける。100時間も1000時間も悩めば、必ず書けるだろう。５作くらい書けば、自分の才能が小説に向いているか向いていないか、多少はわかるのではないか。

(略)

沢山の具体案を考えることは、無駄なようでけっして無駄ではない。採用されなかった案が、その人の将来の持ち駒になるからだ。

via MORI LOG ACADEMY

つくづく、よくできたやり方だと思う。

  

諸々あって、今年は参加できなかった RubyKaigi2008 だったのだけど、続々とアップされている動画＆レポのおかげで、いくつかの興味のあったセッションについて内容を把握できた。（あ、あと yugui さんのを見ないと。）

KaigiFreaks の方々とレポをしてくださった皆様、そして実行委員の皆様に感謝。特に KaigiFreaks は LT 見て、あらためて感謝です。札幌から自費で参加って！おかげさまで、自宅からも楽しめました。どうもありがとうございました。

そして、共通タグらしいので rubykaigi2008 タグ付けてみた。livedoor blog のタグ機能なんて初めて使ったよw

  

なんだ。わざわざここで書かなくてもよかったじゃんw

ひがさんからも SIer と業務知識についてのエントリが出ましたね。
SIerが必要としているのは業務知識だという都市伝説

もう一つ、はてブコメから。

で、業務知識ってやつは現状とか理想形のヒアリング時に必要になるわけだ。
http://b.hatena.ne.jp/entry/http://blog.hacklife.net/archives/51601693.html

まさにそれを幻想だと言いたかったんです。

そこで必要になるのは最低限なにがわからないかをわかるための業界一般の知識（ひがさんが言われるとおり、勉強できる程度の知識）とヒアリングのスキルだと思います。

  

前エントリの続きで、「業務システム開発学科」の単元を挙げてみる。

これがないと作れないという要素をボトムアップ（上流・下流からいくとボトムではないけど）で挙げていったつもり。（「エンタープライズ・コンピューティング学科」は要らぬ誤解を招きそうなので、止めておく。）

やりたいこと・やるべきことを決める (Why/Whom/What)

• 現状のヒアリング
• 理想形のヒアリング
• 目的の確認
• 誰が使うのか
• どのようなものを作るのか

計画を立てる (When/Where/Who/How much/How)

• スコープを決める
• 実現方法の検討
• 見積り
• スケジュールを決める
• 担当を決める

道具を知る (How)

• コンピュータサイエンスの基礎 (設計しテストするのもプログラミングの一部としてここに入る)
• ネットワークの基礎
• コンピュータアーキテクチャの基礎
• OS の基礎
• RDB の基礎
• アプリケーションのための製品知識・技術 (programming languages, VMWare, HULFT, JP1, JCL, ABAP, ApacheHTTPD, WAS, BIG-IP, Tomcat, OracleDBMS, Sybase, DB2, SQL Server, ActiveDirectory, Visual Studio, Eclipse, etc...)

ということで、ぼくが書くと業務知識は入らない。異論反論多そな内容だなぁ。

あ、金融系などで計算系のシステムをやるなら数式の意味を理解できる程度の数学の知識っていうのはあるかもしれない。対数？微分？わかりません（＞＜）とかだと困るだろうから。（数式読めるってこと。数式発明する必要はない。）

あとは日々のチーム運営だとか、これだけだと契約を取ってこれないから営業面を強化すべきとか思想信条によってご意見があることでしょうが、「業務システム開発学科」だとやはりこれかなぁと思う。

迷いがあったのはユーザビリティとセキュリティ。ただ、これも上記を目的を見失わずに学べば十分にカバーされると思い、個別には挙げなかった。

それから、これは非常に重要なのだけど結果としてはコンピュータサイエンスに集約されると思うので挙げなかったのが「ドメインに見られる変化のボトルネックを抽象化するスキル」。これは・・・面倒だから説明は端折る。

最後に、主張したいのは「業務知識要らない！」ってことではなくて、「業務知識偏重 or 製品知識偏重はかえって危険ですよ」ってこと。そりゃ、無いよりはあったほうがいいですよ。念のため。

  

SI業界が開発するシステムの目的は何か？　それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。
スーパークリエイターがSI業界で即戦力になれない理由

もう業務知識幻想は止めようよ。必要なのは課題を適切に設定する能力とその解決に向けてプロジェクトを円滑に進めるプロジェクト遂行能力。その最低限の基盤になるのがコンピュータサイエンスなり、プラットフォームの知識と経験でしょう。（自分も弱いのを棚に上げて言うけどさ。）

一番性質が悪いのが「業務知識」だと思うよ。この言葉も意外に確かなものを伝えていて、所詮知識なんだよね。別にそれを使って仕事をしたわけではないから、業務スキルではなく業務知識。

「業務知識」の意味するところっていうのは、『開発チームの一員としてドメインに精通している（少なくとも文化としての用語がわかり、それがなぜそうなっているかの背景を知っている）人が最低一人は必要』っていうだけのことだ。それは別に SIer として必要というわけではなくて、開発プロジェクトのチームの中に一人は必要というだけのこと。もちろん、お客さんでもいいし、客先の社内 SE でもいい。

はてブのコメントとか見ていると、本当にこれに納得している人が多いようで、参ってしまう。いっそ「業務システム開発学科」の基礎になるような単元考えてみようか。「業務知識」や「HULFT (やら諸々)」の比重がいかに軽いかわかるから。

あ、ただし、

即戦力とは「金融工学と財務会計に詳しくてCOBOLとABAPが読めてWebSphere上のJavaが書けます」

な人が、SIer の営業的に売りやすくて「即、金になる」人なことはまったく否定しない。「人月単価方式では、遊びの時期を最小化するのが在庫削減なんです」みたいなことを考えている企業には最高に都合のいい人材なことは間違いない。

追記：ということで、書いた。「業務システム開発学科」開講。

あ、なんか読み返してみると元記事への dis っぽくなってしまってる。。どちらかというとはてブを読んで誤解のまま広まると参るなぁと思っただけです。

元記事の言われていること（ちゃんとコンピューターサイエンス学んだような人が SIer に来るとスキル（とたぶん嗜好）のアンマッチが〜という話）は、「得意な分野にターゲットを絞って勝負をして、その後に自分の担当範囲を広げていけば、地力が生きてくるだろうなぁ。楽しいだろうなぁ。うらやましいなぁ。」と今も勉強を欠かせないぼくのようなやつは思います。実現したいけれど、手に余って実現できていないことがたくさんあるので。

まとまらなくなったので、リンクして逃げることにしよう。
あわせて読みたい >「システムに入れ」