なぜ糞システムができあがるか
納期が、予算が、バグフィックスが、性能、デザイン、インタフェース、使い勝手、保守が、可用性が、移行にマイグレーション、稼働率が、糞だ。そもそも要求を満たしとらんまともに動かない糞システムが、なぜ莫大な銭金かけてできあがってしまうのは、なぜか? アナリスト、コンサル、PM、SE、プログラマ、テスタ、ヘルプデスク、メンテ、ユーザー、そして経営者と、それぞれの立場から言いたいことは山ほどある。それぞれの立場から「これぞ真の原因!」と叫びたいのも分かる。経営者を除き、全てのキャリアをやってきたから。だから、自信をもって断言する。糞システムができあがる、最も根っこの原因はこれだ。 一つ前の仕事をしている それぞれの立場で「やるべきこと」は分かっている。だからこそ、そのインプットが体を成していないことが明白なのだ。仕方がないので、自分で「インプット」相当を作るハメになる。 例えばプログラマ、プログラミ
3週間でやりなおす「高校数学の教科書」
習うより慣れろ、学ぶより真似ろ。 やりなおし数学シリーズ。いつもと違うアタマの部分をカッカさせながら、3週間で一気通貫したぞ。もとは小飼弾さんへの質問「数学をやりなおす最適のテキストは?」から始まる。打てば響くように、吉田武「オイラーの贈物」が返ってくる……が、これには幾度も挫折しているので、「も少し入りやすいものを」リクエストしたら、これになった。 本書の特徴は、「つながり」。アラカルト方式を改め、高校数学の体系を一本化しているという。なるほど、上巻の「数と式」の和と差の積の形に半ば強引に持ち込むテクは、下巻の積分の展開でガンガン使うし、図形と関数はベクトルと行列の基礎訓練だったことに気づかされる。ベクトルが行列に、行列が確率行列に、さらに行列がθの回転運動や相似変換に「つながっている」ことが「分かった」とき、目の前がばばばーーーっと広がり、強制覚醒させられる。 上巻 1章 数と式 2章
「論理トレーニング101題」はスゴ本
「東大教授が新入生にオススメする100冊」に、必ず登場する名著。 本書は、安直ビジネス書に群がり、カモにされているカモリーマン向けではない。週末にナナメ読んで、「なんとなく分かった気分になる」自己満足を目指していない。1問1問、エンピツとノートを準備して、101問すべてに取り組むべし。「解説書なんかいくら読んだって論理の力は鍛えられない。ただ、実技あるのみ」のとおだ。やれば、やった分だけ向上する。 大きく2部に分かれており、前半は、接続詞に注意して正確に議論を読み取り、その骨格をつかまえるトレーニング。そして後半は、演繹と推測の適切さを論証し、さらに論証を批判的にとらえる訓練をする。すべて、①練習問題→②自力で解く→③解説と答えあわせのくり返し。章末に、ちとムズめの問題が待ちかまえており、③の理解を確かめることができる。200ページたらずの薄手の本なのに、中はどろり濃厚で、「飛ばして」「ナ
プロジェクト・アンチ・パターンの集大成「アドレナリンジャンキー」
一兵卒は必携、プロジェクトの腐臭を嗅ぎとれるようになる一冊。むしろ、「アドレナリンジャンキー」だったわたしに読ませたい 「アドレナリン・ジャンキー」とは、モーレツ社員（死語）、もしくはモーレツ社員で構成された組織のこと。すべての仕事は最優先で、全ての送信メールは、【！緊急！】で始まる。作業の順番は重要性ではなく、切迫度によって決められる。したがって、長期的な見通しは存在せず、全ての仕事は、ある日突然、「緊急」になるまで放置される。 こういう人や組織があることを知っておくと、「そこに染まりやすい」危険性も予測できる。だから、回避も可能だ。そもそも知らなければ、回避する／しないの判断をすることなく、あなたもアドレナリン・ジャンキーの仲間入りとなるだろう。 あるいは、「死んだ魚プロジェクト」。人は結構いるのに、妙に静かなオフィス。入ったばかりのあなたに対し、チームメンバーは気の毒そうな顔で応ずる
わたしが知らないスゴ本は、きっとあなたが読んでいる: いきなりコンサルタントに抜擢されたSEが読むべき5冊
上長から「来週からコンサルタントとして○○社に入ってくれ」なんて言われたときに、あわてないための5冊。以下の条件全部にあてはまる人のための選書なので、関係ない方はスルーしてくだされ。シリーズ化しつつあるエントリ（ [その1]、[その2] ）だが、ここらでまとめ。 システム開発チームのメンバーまたはリーダー 顧客の御用聞きを「コンサルティング」だと思っている ←これ誤り McKinsey や accenture といった「ファーム」と一緒に、顧客の中に入って仕事しなければならなくなった これまで、即効性と実用性で4冊レビューしてきたが、このたび5冊目として扱いたいガイドを見つけた（4冊目）のでまとめてご紹介。 ■最初に結論 コンサル会社がやっている「コンサルティング」は、決まりきった手順や方法を粛々と実行しているに過ぎない。目標に対して泥臭いぐらい愚直に反応する。そうしたメソッドと沢山持って
わたしが知らないスゴ本は、きっとあなたが読んでいる: 図書館を使い倒すための3冊
ネットはスゴいが、図書館のほうがもっとスゴい。「知の現場」はインターネットではなく、図書館にこそある―― まだ、今のところ。 ディスプレイの『あちら側』を否定するつもりは毛頭ないが、もてはやし過ぎ。Evangelist ならいいよ、いくら吹いたって。だってそれがメシの種だから。ただし、賭金は横目でチェックしておかないと。 ここでは、図書館を使い倒すための有用なテクニックや知識をご紹介。以下の本を参考にした。 ・図書館に訊け！（井上真琴,筑摩書房,2004） ・図書館を使い倒す！（千野信浩,新潮社,2005） ・図書館のプロが教える「調べるコツ」（浅野高史,柏書房,2006） 「図書館に訊け！」はサービスを提供する側、すなわちサーバー側から使い倒しのテクニックが惜しげもなく開陳されている。いっぽう「図書館を使い倒す！」は、クライアント側から図書館を徹底的にしゃぶりつくすための技が紹介されてい
要求仕様戦争（その1）
■要求仕様とは 要求仕様とは、開発するシステムに対する顧客のニーズのこと。要するに「お客さんがやりたいこと」そのもの。仕様調整で紛糾したときの決め台詞「結局アナタは何がしたいの?」の【何】に相当する。仕様トラブルの100％はこのスレ違いによる。 要求仕様について考えるために、ちょっとした質問に答えてみよう。以下のa. b. のうち、「要求仕様」を表現しているのはどちらになるだろうか? a. 身長57メートル体重550トン b. 汎用人型決戦兵器 まず a. を考えてみる。これは「何」だろうか? これは「何」かのスペックだ（しかも部分的だ）。身長・体重は分かるが、横幅や厚み、姿かたち、素材 etc... は分からない。これは受注側が「○○はどうするの?」といちいち問い合わせる必要がある。当然、聞くのを忘れたスペックは製造者の「思い」で作られるリスクを負う。 次に b. はどうだろう。身長・体
わたしが知らないスゴ本は、きっとあなたが読んでいる: ブロガーが選ぶ「2005年に読んだベスト」まとめ
本屋に並んでいる「この○○がスゴい！」に天邪鬼な視線を。商業主義に毒されたとまで言わんが、いろんな力学・政治学が働いている。 なぜなら、「この○○がスゴい！」は、出版年やジャンルという縛りがあるから。あるいはライターの意地（というか見栄）が作用して「いまさらこれを採るの？」「なんでこれ入れないの？」の有言無言のツッコミにキーボードも湿りがちになるから。 むしろブロガーが強力にプッシュする「これ読めリスト」の方が面白い。合う合わないもあるけど、知らない世界の手がかりになる。あるいは、自分が目ぇ付けている本を推すブロガーに注目してみるとか、使い方はいろいろ。 作成にあたり、hmmmさんの今年の○冊（チラシのおモテ！ ）を参考にした。大感謝。このリンク先はブロガーのベスト本だけでなく、新聞各紙の2005ベストへのリンクが充実している。 （★印はわたしの読みたいリストとシンクロ） 2005年を振り
わたしが知らないスゴ本は、きっとあなたが読んでいる: ブログでプロジェクトマネジメントする10の方法
マーケティングツールとしてのブログが流行らしいが、開発現場のマネジメントとしてブログを使えないかという提案。イントラネットに閉じたローカルブログ導入のヒントとして自分メモでもある。 1.ステークホルダーのコミュニケーションツールとして 進捗報告やマイルストーン毎のレポートなど、プロジェクトでやりとりする情報はかなりのものだが、それらを全て一斉同報メールで送るのは大変かも～というのであれば、ブログが有効かと。 日報、週報、月報のような定期レポートだけでなく、随時更新されるリスクマネジメントリストや、毎時参照されるトラブルレポートも対象となる。更新するタイミングでステークホルダーにお知らせメールを送るのも簡単だし、RSSリーダで読むようにすれば、それすらも要らぬ。その際、以下のルール決めをして浸透させておく必要がある。 どのタイミングで 誰の責任において どのような情報が 公開されるのか（公開
わたしが知らないスゴ本は、きっとあなたが読んでいる: Wikiでプロジェクトマネジメントする4つの方法
「ブログでプロジェクトマネジメントする10の方法」への反応を見ていると、独り考え込むのでなくUPしてみるものだな、と思った。実務に適用している例や、Wikiでの試みがあることを知った。言及していただいた皆様、ありがとうございます。賛否ともども大変参考になり、中の人は感謝多謝することしきり。 Wikiを発展させた開発支援コラボレーションツールMrkrgnao（via:marsのメモ） Wikiを使った「Web向けLotus Notes」Jotspot（via:関心空間ラボ） 社内限定の非公開型ブログイントラブログ さらに、「Wiki との優位性が見えない」「ストレージサービスでええやん」というコメントがあったが、そのとおりだと思う。実際、前のプロジェクトでは Wiki+CVSで「設計書+コード管理」してたし。時系列に情報を積み重ねるのがブログなら、Wikiは樹構造的な展開に向いている。各人の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
