なんだ。わざわざここで書かなくてもよかったじゃんw
ひがさんからも SIer と業務知識についてのエントリが出ましたね。
SIerが必要としているのは業務知識だという都市伝説
もう一つ、はてブコメから。
で、業務知識ってやつは現状とか理想形のヒアリング時に必要になるわけだ。まさにそれを幻想だと言いたかったんです。
http://b.hatena.ne.jp/entry/http://blog.hacklife.net/archives/51601693.html
そこで必要になるのは最低限なにがわからないかをわかるための業界一般の知識（ひがさんが言われるとおり、勉強できる程度の知識）とヒアリングのスキルだと思います。
しかし、ソースコードには、さらに他の利用者がいることを忘れてはいけません。2、3ヵ月後、何かの変更を加えるために誰かがコードを読もうとするかもしれません。この利用者の存在は、軽視されがちですが、実際には最も重要なのです。コンピュータがコンパイルするのに余分な CPU サイクルがちょっとかかったからといって誰が気に留めるでしょうか。これに対して、プログラマがコードを修正するのに1週間かかったとなると、これは問題となります。コードを理解できれば、わずか1時間で済んだかもしれないのです。
プログラムを動作させようということに必死で、将来の開発者のことを考えていられないというのでは問題です。
「リファクタリング - プログラミングの体質改善テクニック」（Martin Fowler著） 第2章 リファクタリングの原則(P56)より
業務システムを長期で使っていくことを考えると、開発のコストをいかに小さく抑えるかというのは非常に重要だ。特に毎日の資金繰りに困らない程度の規模の企業であれば、初期投資のコストも大事だがメンテを 10 年続けたときに全体でいくらかかるのかという視点が大事になる。（あまりまともに試算されている例を知らないが。）
業務システムを開発するのに必要な視点は複数あるが、コンピュータサイエンスの視点よりも上位の視点（コンピュータサイエンスも含んでしまうという程度の意味であり、価値が上という意味ではない）としてこのメンテナンス可能性という視点が必要だと思う。
ひがさんが「メンテナブルなコード」という表現を使って同じような主張をしているが、「システムをメンテナンス可能にし続けておくための全体の仕組み」を作ることが重要だ。（たぶん、ひがさんはそれをフレームワークで実現できると考えているから、コードという表現になるのだと思う。こちらも参照。）
「どこで何をしているか」「ある目的のことを変えたいときはどこを変えるべきか」「ある箇所を変えた場合の影響はどの範囲に出るか」といった内容が容易に把握できるような状態を維持し続ける必要がある。そのために、ソフトウェアアーキテクチャやドキュメント（無用な誤解を避けるためにあえて設計書とも仕様書とも呼ばない）、人の採用、トレーニングプログラム、開発プロセスなどの全体の仕組みを最適化し続けていかなければならない。
それを実現するためには多くのスキルが求められる。プログラマーであることを目的とするのではなくて、プロフェッショナルであることを目的とするならそのスキルを身に付けることが必要になる。（だって、自分でやらないと誰もやってくれないのがふつうだし。）
色々なツールを知ることや使えるようになることももちろん大事だけど、どんな目的に貢献させるのかを意識しながら複数のツールを組み合わせて活用していくスキルというのはこれからもっと重要になっていくと思う。
ということで、日々の非プログラミング系の仕事のプロセスをプログラミングに模して、さらにそれをリファクタリングしようという codemaniax さんのエントリを読んでいて共感したので、最近考えていたことをメモしてみた。これも衰えない技術だよな。
「あなたのためのソフトウェア。」の時代。狭く、簡単で、少ない目的に最適化したたくさんのソフトウェアを短いサイクルで作る。そのために、極少数の優秀なプログラマが企業の内部から、自分たちの企業へインパクトを与えるためのコードを書き、課題を解決する。オンサイト顧客ではなく、いつでもプラグマティックプログラマがあなたの隣にいるということが生む価値。
これまで、ITエンジニアにとっての花形の職場、就職先はITベンダーであったわけだが、ひょっとするとこれからそれがITユーザの方に移行していくのではないか。それがITエンジニアの雇用をめぐる大転換なのではないかというのが、いま僕が考え始めている仮説である。
その21世紀型ITユーザでの仕事、つまり「自社の事業にITを活用してその結果自社事業を繁栄させることに対する対価を得る」ユーザでの仕事に、「IT を道具やインフラや技術そのものとして他社に提供して対価を得る」ベンダーでの仕事よりも、少なくともシリコンバレーでは、ITエンジニアが魅せられ始めているという現実があるわけだ。
「あーでもない、こーでもないとみんなで頭をひねり、「こういう機能があったら絶対面白い！」というようなアイデアを出し合ったり、時にはトラブルの対応に夜中に叩き起こされたりしながらも、日々進化してゆくサービスを支えるのがソフトウェア・エンジニアというわけです。コンピューターを動かすプログラムを作るという作業は、エンジニアの仕事の一部ですが、他にもサービス全体がどう構成されるかの設計をしたり、様々な問題の解決策を考えたりすることができなければ、この仕事は務まりません。そんなことから、プログラマーという呼び方はあまり使われないのでしょう。インターネットビジネスのアイデアを形にするには効率よく、しかも安定して動く大規模なサービスを作らなければなりません。しかし、こういった大規模なサービス作りは、ノウハウが少ないので、エンジニアの職人的な経験と勘がものをいいます。」
「ところが、僕の仕事はそのどれにも当てはまらないというか。プログラマというほどプログラムをガリガリ書きまくるわけでもないし、SE のようにクライアント相手に分析/設計を行って仕様に落とし込むプロというわけでもなく。時としてサーバの運用なんかもやるし、アプリケーションを作ることもあり、その一方で新しいサービスのアイデアを企画したり色んなサービスのブレストに参加したりもします。良く言えばオールマイティ、悪く言えば中途半端というやつなのです。色々やれて楽しいと言えば楽しいのですが、じゃー僕の職種は一体何なんだって思ったときに、一言では言い表せないし、万が一転職なんて話になったときに、こんなキャリアで相手にしてもらえるんだろうかとか。」
「でもここでのコラムを読んだら、どうもシリコンバレーではそんな職種が花形でもあったりするようなことが書いてあって、少しだけ自信を持つことができました。「インターネット関連の企業でエンジニアやってます」と言えばいいのですね。」
NDO:: Weblog氏が言う「SI、SE やプログラマ、ITコンサルなどに対する、ある程度型にはまったイメージ」というものこそ、ITベンダーにおけるITエンジニアの職のイメージなのである。上田さんやNDO::Weblog氏の仕事のイメージこそが、生まれたばかりの、21世紀型ITユーザにおけるITエンジニアの職のイメージとは言えないであろうか。
雇用なき景気回復とITエンジニアの雇用をめぐる大転換
ただし、要件は大抵使う場所に近いところから出るのでそこは日本でやる必要がある
独り言
日本の（大手）SIerの価値の源泉は、業務分析能力と運用も含めたシステム設計能力であって、個別のコンポーネントに精通していることは競争力の源泉とはならない。
SIerはテクノロジーで食っていけるか？
ユーザの問題解決代行業がSIerの本質だといえます。
SIがOSS化するとは何か？
シリコンバレーの本当の恐ろしさは、そこそこ優秀ではあるけれど、どこにでもいるようなありふれたスキルのエンジニアを使って、あるいは場合によっては、インドのアウトソースサービスを使って、世界中どこにもないようなソフトウェアや、サービスを短期間のうちに作り上げる仕組みのほうにあるのだと思います。
100万行のソフトの作り方(1)
事業部門の運営をサポートするようなIT資源とサービスを提供するのが「供給」のマネジメントであり、その対極にある、事業部門によるITを通じたイノベーションを助けるのが「需要」のマネジメントであって、新しい世代のCIOは、「供給」サイドの仕事でなく、「需要」サイドの仕事に専念する傾向が見られる、ということである。
企業のリーダーシップを採ろうとするCIOには、複雑に絡み合うビジネス上・テクノロジー上の動きの中から、イノベーターであれば誰もがするように、パターンや意味を抽出し、どれが「本当に役立つもの」で、どれが「ただの流行りもの」かを見極めた上でビジョンを形成する能力が求められる、ということなのだが、「ITの使い方を考える」仕事で磨かれる能力がこのようなものであるとすれば、それはとてつもなく刺激的な仕事なのではないだろうか？
ベンダーサイドだけがITのキャリアではない
「とにかく、何か新しいビジネスをオンラインで立ち上げるためには、ユーザーのフィードバックを集めながら、Plan -> Do -> Check -> Actionを繰り返していけるような体制を社内に集めないとだめだろうということです。いちいち要件定義して、仕様書書いて、SIerに発注なんてしていたら、時間もお金もかかりすぎて、事業として成り立ちません。オンラインのオペレーションは変化の連続ですが、アウトソーシングしてコストメリットが出るのは枯れたオペレーションだけなので、ここを外に出すとかえってコストは上がるし、スピードは下がるし、品質は悪化するしで、良いこと無しだろうと思うんです。」
オフショア開発で明暗別れるプログラマーのキャリア
やがてくる未来ではソフトウェアの生態系がかわると私は信じている。その生態系を、ここでは 馴染系ソフトウェア (Situated Software) と呼ぶことにしよう。特定の場面や文脈のために設計されたソフトウェアのことだ。馴染系ソフトウェアを作る方法は、いわゆるウェブ学派(かつて私がプログラミングを勉強した場所)のやりかたとは対照的だ。ウェブ学派はスケーラビリティや汎用性、完全性を美徳としてきた。
私の生徒達はウェブ学派の流儀をあっけらかんと無視し、それでいて面白いものをつくっている。
全ての関心はアウトソーシングに集まっているが、多くのダウンソーシングもまた起こりつつあるのだ。プログラミングは職業上の技能から、より広く身につけられるスキルになりつつある。もしプログラマという言葉が 「コードを書いて給料を貰っている人」 ではなく 「コードを書く人」を指すなら、2015 年にむけてその数は増えつづけるだろう。
アプリケーションを長く使いたいと考えるのは、それを作るのにコストがかかるからだ。安く簡単にソフトウェアを組めるようになれば、この原則は弱まる。ビジネスでは稼ぎのいい人々に数百時間をかけて PowerPoint? のスライドひとつをつくらせることがよくある。そのスライドはミーティングで一度使うだけだ。ソフトウェアを多くのユーザに使えるようにする、あるいは多くのユーザのために残すというのは慣習にすぎず、ソフトウェアそれ自身の要件ではない。
実際問題、多くのユーザに長く使ってもらおうと作られた大抵のソフトウェアはその両方の目標を永久に達成しない。馴染系ソフトウェアはこう主張することができる: 「大抵のソフトウェアは短い期間、少しのユーザに使われるだけだ。なぜその利点を設計に生かさないのか？」
こうした事態は、奇妙なことだが、進歩といえる。馴染系ソフトウェアが他のアプリケーションを駆逐するからではない。そうはならないだろうからだ。現在のソフトウェアがつくる生態系のもつ価値はどれも、一握りのユーザが数ヶ月使うアプリケーションがもたらすものではない。私達は新しいソフトウェアのニッチをみつけたのだと思う。コミュニティは個々の特別な要求にぴったりのツールを手に入れる。そのツールはこれまでの設計品質や成功のための試験には落ちるだろうが、にもかかわらずよく機能する。そのソフトウェアは、それを使うコミュニティによく馴染んでいるから。
馴染系ソフトウェア
ソフトウェアエンジニアの価値はシステムを作れることなのか。売れるシステムにこそ価値があるのだとしたら、そこへどんな貢献ができるのか。今、成果として何を生んでいるのか。いなくなったら、本当に困る存在か。替わりのきかない役割があるとしたら、それは一体なにか。10年後にも価値を生み続けるための競争力は、今やっていることの延長線上にあるのか。
知識労働者たるものは、自らの組織よりも長く生きる。したがって、他の仕事を準備しておかなければならない。キャリアを変えられなければならない。自らをマネジメントすることができなければならない。つまるところ、これまで存在しなかった問題を考えなければならない。
キャリア・ビジョン
勉強が好きな少年も、野球好きの少年や将棋好きの少年や音楽好きの少年と同じような「人生の厳しさ」に直面するようになる。
それが「次の10年」なのではないか。
そんなことを最近よく思うのだ。
たとえば僕の場合でも、本を読んだり勉強したりモノを書いたり、そういうことは子供の頃から大好きだった。でもそれだけでは食えない。いま僕の事業を、ひいては生計を支えているのは、僕の「勉強能力」ではなく「対人能力」もっと言えば「営業能力」なのである。
「これからの10年飲み会」で話したこと、考えたこと
「手に職を付けたい」と言ったところで、文系で就職した日本の大学生が、海外の理工系大学でIT教育を受けてきた人材に技術力でかなうわけがありません。スタート地点が違うわけです。
最後に一言
アマチュアという言葉の反対語は言うまでもなくプロである。
「mass amateurisation」の大きな流れは、今現在何かの領域でプロを自認して飯を食っている人にとって、膨大な新規参入者(アマチュアと言ってもいいし、エンパワーされた人々と言ってもいい)が、ものすごく大きな脅威になる。これこそが「mass amateurisation」現象の本質であるという問題提起である。まったくその通りだと思う。
第一タイプは、既存の体制によく親和して、何かを成し遂げようとするときには「しかるべきプロセス」の中に自然に身を置いて、その中で着実に経験を積んでいくことを喜ぶ(厭わない)というタイプである。日本のエスタブリッシュメント層の大半は、こういうタイプの人たちである。
第二タイプは、何かを学ぶのも何かの経験を身につけるのも自己流。学校や大組織のような秩序立ったところにはあまり親和せず苦労するが、混沌とした社会の現実にぶつかる経験の中から、独力で頭角を現していくタイプである。
こういう第二タイプの才能がエンパワーされて世に出やすくなる現象こそが、「mass amateurisation」なのではないだろうか。
でも、ジャーナリズムやプログラムの分野に限らず、音楽の分野、映像の分野、ありとあらゆる知的作業のための環境が低コスト化、コモディティ化するにつれて、第一タイプのエスタブリッシュメントたちを、第二タイプの在野の実力者が脅かし始めるという構図がいたるところで現れてくる。それが21世紀の「仕事の現場」なのではないだろうか。
ネットがもたらすプロフェッショナルへの新しい道
「グローバルに仕事が移転する時代では、ある時首を切られて、それ以降全く仕事がなくなってしまう、ということが十分起こり得る。
なんというか、海辺の絶壁を想像してしまう。水際ぎりぎりにぽっかり横穴が開いていて、その中で安穏と暮らしていると、だんだん潮が満ちてきて、海の水がじわじわと穴の中に入ってくる。今にまた潮が引いて、元通りの安穏とした暮らしに戻れるのではないかと思って耐えているが、ついに水は腰の辺りを超え、首あたりまで来る。どこかで決意して、荒海に泳ぎ出て、さらに上のほうにある穴によじ登った人だけが生き残ることができる。」
まわりの連中よりも何百倍も何千倍も優秀なプログラマーというのは居るものだ。そういう能力を持った人は大企業にも勤めている。でも大企業だとそういう人のインパクトが薄められる。そういう才能をきちんと雇用し、大企業の中でもちゃんと活かせ、そうすれば、顧客満足もうんと上がる。同じ成果を低コストでということばかりでなく、そういうプラス効果を考えなきゃダメだ。
年収500〜1000万円の仕事がなくなっていく米国
全く別の観点から、元オラクルCOOのRay Laneのインタビューは、グローバル化がもたらすアウトソーシングではなく、IT化のゴールとしての「リアルタイム・エンタープライズ」が実現することと人員削減の関係についての未来像を提示している。
20世紀型の「人の多い」会社から、もっともっとビジネスプロセスを自動化し、無人化していくのが、21世紀型企業のイメージだと、Ray Laneは言う。
シリコンバレーという場所は、アメリカの中でも、変化が最もラディカルに表出する場所なので、ここに住んでいると、よくも悪くも、未来の仮説が増幅した形で、僕らの前に姿を現す。ここに住むほぼすべての人たちが理解しているのが、自分たちの子供の時代になったら、人をめぐる競争環境がますます激化するという事実だ。
世界規模の人材競争に日本の若者が生き残るには
米国300万プログラマーのピラミッド構造
まず、「Software programming is the iconic jobs of the Information Age, but not all programmers are created equal. Here’s the breakdown of software jobs and their prospects」と書かれているように、この図では、ソフトウェアに関する仕事のピラミッドを6階層に分類し、それぞれの階層ごとの今後について一覧したものである。ちなみに、米国全体では約300万人が、このピラミッドにどこかに位置している。
まず、頂点に位置するのが、 Architect階層(第1階層)である。「A few thousand tech visionaries sketch out entire systems to handle complex jobs.」というわけで、この階層は数千人の世界。例としては、BEA SystemsのChief ArchitectのAdam Bosworthが挙げられている。年収は15万ドルから25万ドル。アウトソーシングの影響はいっさい受けない。
さて、次が、 Researcher階層(第2階層)である。ここがイノベーションのためのカギで、米国にとっての生命線である。ここに2万5000 人くらい居るとBusiness Week誌は推定している。年収はアカデミアだと5万ドル。在野だと19万5000ドル。基本的にはこの階層の将来は明るいが、この仕事もオフショアに出て行く可能性がある。
そして、Consultant階層(第3階層)。企業のテクノロジー・ニーズについてアドバイスし、新しいソフトウェアをインストールしたり、新しいアプリケーションをスクラッチから作ったりする、ビジネスに精通したコンサルタント。年収は7万2000ドルから20 万ドル。この階層の将来は明るい。 次が、Project Manager階層(第4階層)。グローバルソフトウェア工場の重要な歯車。異なる国、異なるタイムゾーンで働くチームをコーディネートして、仕事を時間通りに完遂する仕事。これに関連しては、本連載2月12日「グローバル化が進む分散開発体制の今」も合わせてご参照。年収は9万6000ドルから13万ドル。ここでいいマネージャーになれば、仕事は安泰。
そして下から2つ目が、Business Analysts階層(第5階層)。ビジネスニーズからプログラマーのためのスペックに落とす人。年収は5万2000ドルから9万ドル。ビジネスセンスがあって、コミュニケーションスキルがあるプログラマーにとって比較的安全な場所(仕事が外に出て行かない)。
そして最後が、Basic Programmers階層(第6階層)。「The foot soldiers in the information economy」(情報経済における歩兵)で、アプリケーション用のコードを書き、アップデートして、テストする。年収は5万2000ドルから8万 1000ドル。仕事が海外に出て行ってしまうという意味では、ここが一番危ない。この階層における仕事の18%が、6年以内に、オフショアに流れていくというのがフォレスターの予想。
オフショア開発で明暗別れるプログラマーのキャリア
Gartnerによると、IT関連職は以下4つの傾向による影響を受けるという。
「技術オタクの時代」が幕を閉じる？--米調査
- 技術インフラ／サービス関連業務は、エンドユーザーの組織では減少し、逆にサービス／ハードウェア／ソフトウェアベンダーでは増加するだろう。しかし、その業務の多くが開発途上国から提供されることになる。
- ビジネスインテリジェンス、消費者向けのオンラインサービス、コラボレーション技術に従事する人の数は、ユーザー企業、システムインテグレーター、コンサルティング企業の間では増加するだろう。
- 競争力のあるビジネスプロセスやプロセスオートメーション、業務プロセスの設計ができる人が求められるようになる。プロセスの設計／管理分野は、有望な分野になるだろう。
- 「無形の財産」を管理する能力や、地理的に分散し、作業能力も文化も異なる複数の関係者を管理する能力が要求されるようになるにつれ、関係管理や外注管理に関するスキルが重視されるようになるだろう。
手作業で開発すると500人月はかかる。それとは対照的に、同じシステムの仕様を決定するだけなら 5, 6 週程度で済むだろう。そして、その仕様がそのまま動作するシステムとなるのなら、開発期間を劇的に短縮するのに成功することとなる。〜 What Not How P7.(適当訳)
とか。
追記： What Not How に関してはこの辺とか。
たいていの人は自分のやり方というのを持っている。そして、大人にもなると少なからず自分が知らないことがあるというのを認めたくない。だから、システム開発をしているとこんなことがよくある。
「これこれこういう機能のものを作ってくださいよ。」
「その機能ってどんな機能なんですか？」
「うん。それはね、こんな風に動いて、あとはあんな風に動いてくれれば大丈夫です。」
そして、もし言われるがまま作ったものを見せると、きっとこういう答えが返ってくる。
「ちょっとイメージと違うなぁ。これだと○○なとき、困るんですよぉ。」
ちょっと待て。「よぉ」なんて言われてもこっちも困る。
というわけで、要件聞きに言ったのに機能の詳細に突っ込んで話しをして下さる人へはやんわりとこの言葉を使うことにしている。
「そうですよね。今その機能がなくて困っているのはたとえばどんなことなんですか？」
「このシステムを作る目的を教えてください。」というのは教科書的には正しい質問なのだろうけど、実際それだけ言っても通じないことが多い。たぶん「目的」という言葉が指す範囲が広すぎて、意図が伝わりにくいのだと思う。
そんなときも「自分が困っている問題」については皆はっきりわかっているので、そこについて質問すると知りたい内容が明確に教えてもらえる。
同じ内容を聞くのに聞き方はいくつもあると思うけど、いろいろ試してみた結果、今のところ上の質問が一番効果的。
3/9のエントリについて、いくつか言及を頂いたので紹介。ちなみに私自身の考えはこちら。
違いは何か。実ははっきりしています。「本気度」です。いつでも変更できますよ、というステータスだと、必死で詳細まで見ないのです。ここで決めたことがリリースされるのだ、となった途端に急に詳細まで考え抜くようになります。〆切重要。
もうすぐ春だよはぶにっき [仕事]仕様の確認方法
僕はもともと、ドキュメントじゃ確認できる内容には限界あるから、使ってもらって判断してもらう、ということには同意できたんだけど、使ってもらってであっても、本気度が足りないと全然フィードバックが受けられないというのも現実で。
m_pixyの読書日記 [dev][RD]お客様の本気度
いきなり真打登場という感があるのですが、「本気度」。たしかにこれはあります。なんで本気にならないんでしょうね？やっぱり締切りなんでしょうか。
一方で「本気になって仕様を検討するときに何をどう見ればわからない」というのはある気がしています。ユーザーの人は業務のプロではあるけれどシステム仕様を書くプロではないので。じゃ、誰がプロかっていうとやっぱりシステム作る人になるんじゃないかと。
ユーザーが本気になって仕様を確認したときに、動作するプログラムと紙の仕様書（ガチガチのもアジャイルなのも含めて広い意味での仕様を記した何かしらのもの）のギャップはどこに残るのか？（残らないのか？）が新たな疑問。
スタロジ流だと限りなく「残らない」に近いスタンスですね。残るけど、それは紙では実現不可能な部分という。
そうか。たしかにここまで割り切ってしまえば残りの部分（見えてないと仮定できる部分）の見通しはかなりよくなるなぁ。少し前進した感あり。ありがとうございます。
このズレが重いな。だから、ユーザを巻き込めという話になるのか。XPやなんかでも言われてるけど、このこと自体は開発方法論には関係しないはず。ただ、方法論としてユーザを巻き込むということを明示しているからアジャイルはイイ！って話になってるのかと思ったり。
m_pixyの読書日記 [dev][job]ユーザが本気になるタイミングと、開発側が本気になるタイミング
「リーンソフトウェア開発」を読んでいて私もこれを感じました。単純に開発サイクルが短いというのは強制的に巻き込む機会が増えるな、と。（厳密には「方法論としてユーザを巻き込むということを明示」の指されている話とは少し違いますが、言いたいところは近い。はず。）
最後に頂いたトラックバックから。
ぼくは「仕様決めのときになくて、顧客テストのときにある」のは「動くアプリケーション」と「それまでのコミュニケーションで培ってきた信頼関係」だと思う。受け入れテストといえど、純粋に仕様から落とし込むというよりは、できあがってきたアプリケーションの動作を開発チームとのコミュニケーションを通じてすり合わせられている。その上で、実際に動くアプリケーションを使って検証するから、この仕様は正しいと判断できるのだと思う。
TECH-moratorium ： テクモラトリアム [SD]顧客テストにはあって、仕様決めのときにはないもの
なるほど。たしかに丸っきり初対面から始めたようなプロジェクトだと仕様決めるにしても「空気を読みつつ」みたいなところはありますね。（身に覚えあり。その態度を反省した覚えもあり。）
「受け入れテストといえど、純粋に仕様から落とし込むというよりは、できあがってきたアプリケーションの動作を開発チームとのコミュニケーションを通じてすり合わせられている。」の部分がちょっと理解しきれなかったのですが、仕様と実装アプリの動作にずれが出ているという内容かな。そして、それをコミュニケーションですり合せている。と。（違うかも）文脈的に「この仕様は正しいと判断できるのだと思う。」の部分に掛かる理由にもなっているはずですし、もうちょっと突っ込んで聞いてみたい内容です。
あと、「動くアプリケーション」というのはなんだかんだ言ってやっぱり強いですね。Ruby まつもとさんの「ソースがドキュメントだ。 バグも完全に記述されている」ではないですが、たしかに仕様の誤り・漏れも含めてすべて実装されているというのは強いです。あとはそれを作るのはタダじゃないというコストの問題ですか。
最後のオチとしては、
逆に、お付き合いが長かったり、そのシステムに専念できるお客さまだったり、既存システムのリプレース案件の場合は、仕様決めの段階できっちりと詰めるアプローチが有効だと思う。特に、仕様のほとんどが計算式な金融系のシステムなんかはそうだろう。重要な仕様は事前に十分に検証でき、結果的にリスクも下がると思う。
にど真ん中で当てはまる案件をやっているにも関わらず、こんな問題提起をしている自分が居たり。やっぱ単なる本人の力不足か！
仕事をしている中で、 Windows のネットワーク周りの知識と知恵が物理的にも論理的にも弱点になっているのに気付く。
んで、 Google に聞いてみて「 Windows2003 Server による社内ネットワークの構築」を発見。
まさにこれだよ！という気持ちと、あー、こんな基本的なこともわかっていなかったなんて・・・という気持ちとで複雑。。
あとは、基本でこの辺か。。
