タグ

ブックマーク / dain.cocolog-nifty.com (30)

  • わたしが知らないスゴ本は、きっとあなたが読んでいる: いきなりコンサルタントに抜擢されたSEが読むべき4冊目

    このエントリは、「いきなりコンサルタントに抜擢されたSEが読むべき3冊」[参照]の続きになる。 「コンサルタント」と一緒に仕事をしたことがあるだろうか? 肩書だけのなんちゃって自称コンサルではなく、McKinsey & Company や accenture といった、それでメシ喰っている連中のことだ。 彼らの阿呆ほどの猛仕事ぶりは、「マッキンゼーIT質」[参照] に書いたが、仕事の順序というか、ダンドリの要領よさについては常々不思議に思っていた。「俺たちに明日はない」という言葉がピッタリの猪突猛進なのだが、仕事のやり方は整然粛々としている。見た目のロジカルさだけでなく、コンサルティングの仕事そのものが、あたかも何かのマニュアルに従っているかのような感じがしてならなかった。 その予感はあたってた。マニュアルを見つけたんだ。それは、「情報システム計画の立て方・活かし方」。いや、その辺に転

    わたしが知らないスゴ本は、きっとあなたが読んでいる: いきなりコンサルタントに抜擢されたSEが読むべき4冊目
    clavier
    clavier 2006/06/05
    コンサルティングファームの種本。
  • 悪のプログラマ―――もっと冴えたやりかた

    「悪のプログラマ」[参照]で、優れたプログラマが気で犯罪に手を染めるなら、痕すら残さないゾと書いた。さらに、デバッグとしてのソースレビューだけでなく、犯罪防止のためにコード検閲が必要だとも言った。 ところが、この容疑者はそれほど優れたプログラマではなかったようだ。以下、「NTTデータ元社員が取引記録を不正利用しカード偽造の疑い」[参照]より引用。 NTTデータは、2005年10月と2006年2月に発生した偽造ローンカードによる不正キャッシング被害に関連して、同社から仙台銀行のATMでカードを利用した際の取引記録の一部が不正に持ち出されていた可能性があることを発表した。 容疑者の元社員は、システムの運用にあたっていた人物。彼のやりかたのどこがマズかったかを指摘し、「もっと」冴えたやりかたを提案してみる…が、それだけだと教唆になっちゃうので、防止策も。 媒体(ここでは紙)が噛んでいる 誘拐で

    悪のプログラマ―――もっと冴えたやりかた
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: プログラマになれなかったわたし

    今は昔、ひとりの駆け出しプログラマがいた。 その頃はCOBOLばかりで、しかも保守ばかりだった。そこで、独学で身に付けたCをやらせてもらえる仕事を奪ってきては書いた。スクラッチプロジェクトを見つける嗅覚だけは抜群だった。たいていは人手が足りず、新人でも歓迎されたからだ。 そこには優れた先達がいた。「スーパープログラマ」と呼ばれていた。 なぜ「スーパー」なんて修飾子がついたかというと、速いプログラムを早く書いたから。もちろん、「速い」とは少ないメモリ・小さいプログラムのことを指し、「早く」とは実装が早いこと。実際、彼らが書いたプログラムはサクサク動き、バグは簡単に見つけられた。 教えを請うと、先達たちは、おしなべてこういった。 最初に学ぶべきは、コンピュータサイエンス。特にアルゴリズムとデータ構造だ。実践的なコーディングテクニックよりも、まず基礎だ。これはコードを書きながらではなく、文献から

    わたしが知らないスゴ本は、きっとあなたが読んでいる: プログラマになれなかったわたし
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(まとめ)

    この連載を始めたのは、Waterfall 2006を見たから。ついカッとなって書いてしまった。今は反省している。この連載は体系的じゃないし、blog よりむしろ出版物の形で問うべき。何よりも、今週の睡眠時間を大幅に犠牲にしてきたので、眠くてたまらん。 …というわけで、ここでは総括+補足して締める。 ウォーターフォール・モデルとは、プロジェクト構造化モデルと言い換えられる。その特徴として、以下のことが挙げられる。(その1) プロジェクトを構造化し、段階を踏んで要素成果物を構築する 次に、必要な要素成果物を適切なタイミングで持ち寄り、組み上げる 要素成果物を構築する工程はスパイラル・モデルを適用できる。しかし、組み上げる工程は逐次的であることが求められる プロジェクトを構造化することにより、プロジェクトを「見える化」できる。全体と部分、出来てるところと空白のところが分かる。未確定事項がオープン

    わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(まとめ)
    clavier
    clavier 2006/02/20
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(その5)

    ウォーターフォールの怨嗟の的になっているのは「ドキュメント」だろう。使うかどうかも分からぬような大量のドキュメントを書かされる。しかも顧客の一言で大幅に書き直しを命ぜられる。さもありなん。だが、ここでは、ウォーターフォール・モデルにおけるドキュメントの必要性を強調する。 ドキュメント=契約書 なぜドキュメント化が嫌われるのか? SEの立場から言うと、ちゃんと検討していないまま、「とりあえず」ドキュメント化をさせられるから(結果、後から手直しが多発する)だろう。PGの立場からすると、理解してコードに落とすだけの内容を、なぜ語弊の出る日語に書き直さなければならないか、疑問に思うだろう。 当の問題はSE/PGがドキュメントを書いていること。あるいは、片手間にドキュメントを書いていることをなんとかすべき。来なら専門部隊を準備するか、リソースを明示的に割り当て、執筆期間を設ける必要がある。 こ

    わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(その5)
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(その4)

    決めるべき2つの日どり 二つ目の戦略。それは「日どり」だ。「あいまいな仕様」が"今は"決まってないことを顧客自身の口から言ってもらった後は、何月何日までに仕様凍結するかプロジェクト全体のスケジュールの中で顧客と決める。「仕様の再確認」ができていない以上、そいつができる日はいつなのかを決める。 こいつを最初に決める。ここを過ぎると挽回が不可能とうい点「ポイント・オブ・ノーリターン」を"今"決める。ここまでギッチリ動機づけしておけば、仕様凍結の最大の脅威「先送り」を回避できる。 あるいは、こっちの方がもっと重要なのだが、「仕様凍結を先送りしている事実」を共有できる。極端な話、仕様が凍結されていないのが問題なのではない。仕様が凍結されていないことが公になっていないまま、先へ進んでいるほうが深刻なり。 表向きは仕様は固まっているはずなので、顧客からは口頭や電話だけで「指示」がくる。当然、仕様書は書

    わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(その4)
    clavier
    clavier 2006/02/16
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(その3)

    ちょっと思い出して欲しい。次の弾丸が飛んでくるのはいつだろうか? 「すでに決まったはずではないか」 「そう読み取れるではないか」 「いまさら言われても困る」 よい子のみんなはもちろん分かってる。納品が間近に迫ってきたときだね。品質がアレなのか、そもそもマトモにできていないことが明らかになったか、トリガーは様々だけど、たいていはプロジェクトも終盤になってそんな弾丸が飛んでくる。 これは「仕様のあいまい性」を先送りしてきたツケだ。実はこの弾丸、プロジェクトを通じて3度発射する機会があるという。 1回目:顧客との契約時、仕様の確認をするとき 2回目:ベンダーと請負会社の契約直前に、請負会社から仕様の確認を求められ、顧客に問い合わせるとき 3回目:火ダルマになっていることが知れ渡り、顧客が乗り込んできて「こんなのを作れなんて言ってない」と言い放つとき .…にもかかわらず、3回目がほとんどだろ。この

    わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(その3)
    clavier
    clavier 2006/02/15
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(その2)

    ウォーターフォール・モデルとは一言で説明するなら、「プロジェクトの構造化」だ。逐次実行や先手管理、進捗の予実管理なんざ、特徴的だが質ではない。それらはキチンと構造化された後に実現できる。プロジェクトの構造化をしないまま先手管理しようとするからおかしくなる。 プロジェクトの構造化はこうやる ウォーターフォールは逐次的な開発技法であり、ウォーターフォール全体として「分析>設計>製造>試験」とはならない。顧客受けしやすいようそんな絵を書くこともあるが、実質は異なる。 「すべきこと」単位に分解して、「すべきこと」同士の順序性を決めた後、「すべきこと」同士では逐次的な関係を守らせるようにすることが当。 「すべきこと」の分け方は「分析」「設計」「製造」「試験」ではない。これらは分断するものではない。「なんちゃってウォーターフォール」をダメにしているのは、工程(=フェーズ)ごとにチームを割り、それぞ

    わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(その2)
    clavier
    clavier 2006/02/14
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: ブロガーが選ぶ「2005年に読んだベスト」まとめ

    屋に並んでいる「この○○がスゴい!」に天邪鬼な視線を。商業主義に毒されたとまで言わんが、いろんな力学・政治学が働いている。 なぜなら、「この○○がスゴい!」は、出版年やジャンルという縛りがあるから。あるいはライターの意地(というか見栄)が作用して「いまさらこれを採るの?」「なんでこれ入れないの?」の有言無言のツッコミにキーボードも湿りがちになるから。 むしろブロガーが強力にプッシュする「これ読めリスト」の方が面白い。合う合わないもあるけど、知らない世界の手がかりになる。あるいは、自分が目ぇ付けているを推すブロガーに注目してみるとか、使い方はいろいろ。 作成にあたり、hmmmさんの今年の○冊(チラシのおモテ! )を参考にした。大感謝。このリンク先はブロガーのベストだけでなく、新聞各紙の2005ベストへのリンクが充実している。 (★印はわたしの読みたいリストとシンクロ) 2005年を振り

    わたしが知らないスゴ本は、きっとあなたが読んでいる: ブロガーが選ぶ「2005年に読んだベスト」まとめ
    clavier
    clavier 2006/01/04
  • わたしが知らないスゴ本は、きっとあなたが読んでいる

    なぜ自分が自分の形を留めていられるかというと、自分を知る誰かがいるから。 誰も自分を知らない場所へ旅するのもいい。そもそも誰一人いない場所を旅するのもいい。だが、いつかは放浪をやめてこの世界のどこかに落ち着かなければならない。さもないと人という存在と疎遠になり最後には自分自身にとってさえ他人になってしまう。 誰かを撮った写真は、近しい人間の心のなかでしか価値を持たないのと同じように、人の心も別の人間の心の中でしか価値を持たず、その人の思い出は、思い出したときにのみ存在するだけであって、思い出す人がいなくなれば、消え去るほかない。 人生は思い出だ、そして思い出が消えれば無になる。だから人は思い出を物語ろうとする―――コーマック・マッカーシーの『越境』を読んでいる間、そんな声が通底音のようにずっと響いていた。 マッカーシーの代表作ともいえる国境三部作(ボーダー・トリロジー)の第二作がこれだ。第

    わたしが知らないスゴ本は、きっとあなたが読んでいる
    clavier
    clavier 2005/12/12