http://proger.blog10.fc2.com/blog-entry-69.html 現場の人間が「プロセス改善は工数の無駄だ」といった時に、つい「長期的な視野に立ってないからだ」ということがよく言われます。大抵の場合、それも一理あるとは思いますが、決してそれだけではありませ…

http://app.blog.livedoor.jp/hiroaki_sengoku/tb.cgi/50603640 つまり、ソフトウェア開発を自動車の製造と比較しているのである。自動車は、「わずか」数百万円なのに「使える」製品が買える。自動車と同程度に複雑なソフトウェアを開発しようと思ったら、…

「現在のソフトウェアは規模が増大しています。建築で言えば、今までは一軒家の建築だったから腕の良い大工さんの能力でやっていけたけど、高層ビルは腕の良い大工さんが居るだけでは建てられませんよね。だから工学的な手法が必要なのです。」えっと、理系…

http://www.hyuki.com/d/200606.html#i20060616 思うに、ソフトウェアも、本も、想像以上に複雑で大きなものであり、人間が誤りなく全体の設計を前もって行うというのは不可能なのではないか。設計が不要だとか、コードがすべてだという気持ちはさらさらない…

上のエントリは、id:JavaBlackさんのエントリに触発されて書いたもの。 http://d.hatena.ne.jp/JavaBlack/20060504#p2id:JavaBlackさんも憂鬱本否定派なんだけど、id:naoyaさんが「オブジェクト指向が判ってない」と判断されてるのはどうかと思う。id:naoya…

趣味プログラマが職業プログラマになろうとするとき、ソフトウェア工学を学ぼうとして時間を無駄にしたり、自分が間違った方法で開発しているように思わされて引け目を感じたりする事がある。はてなのid:naoyaさんもその中の一人らしい。http://d.hatena.ne.…

http://d.hatena.ne.jp/methane/20060410/1144683796 の続き結局、上司が何を知りたいのかのポイントをまとめてみて、運用してみたらそれなりに良い感じになった。管理にかかるオーバーヘッドも、フォーマットが固定してからは週１時間以内になって、バラン…

ハネムーンナンバーという単語をご存じだろうか？以前までトラックナンバーと言われていたものである。 ただし、トラックナンバーから少し定義が変わり、「最低」何人が居なくなったらではなく、「平均」何人が居なくなったらとされている。（参考）で、今、…

ある作業がある。その作業を行うのに、２つの方法があり、その片方は経験済みだとする。 さて、２つの方法で予測コストに大きな差がないとき、どちらの方法を選ぶだろうか？官僚的なマネージャーなら、経験済みの方法を選ぶだろう。そっちの方が高い精度で予…

アジャイルプロジェクトマネジメント 最高のチームづくりと革新的な製品の法則 のレビュー 「最高のプレイヤーがいるチームが最高のチームだ」 「スキル不足をプロセスで穴埋めする事はできない」 「バスに乗っている一部の不適格者のために官僚的なプロセス…

http://d.hatena.ne.jp/sakuneko/20060417#p2 私自身が実行ファイルではなくソースコードを最終的な成果物として納めている立場ですので、最終的な設計作業はあくまでも関数仕様書に基づく関数設計であって、ソースコードは製造するものなのですよね。 多分…

http://www.alpha-net.ne.jp/users2/gzmgzm/article/09/19.html ソフトウェアが小説に似ているって書いてあるページ。まぁ、内容に全く同意なのは当たり前として、ちょっと面白かったのがこの文 人間が作るものの中でソフトウェアというのは、かなり複雑な部…

昨日、チーム連絡会で、チームのメンバーがたくさん居る前でリーダーに質問した。「この面倒な進捗管理＋見える化をやれば、本当に上から無茶な日程の指示から守ってくれるんですね？」って。 リーダーの回答は、「やる。それでも上が聴かないようならどうし…

家の建築のように、手順がしっかり決っていて、前のことをやらないと次のことが出来ないという状況ならマネージメントにも意味がある。 でも、今のチームの状況は、余りにも仕事が多すぎて、何かの仕事が止まってたら別の仕事をするだけ。無駄な時間なんてほ…

今、上司が、部下の仕事の内容や優先順位や時間の割り振りやらを把握しようとして、それを週ごとに詳しく報告する事を求めている。コレ、何かのアンチパターンでありそうだよなぁ・・・と思ったら、マイクロマネージメントと言うらしい。マイクロマネージメ…

http://satoshi.blogs.com/life/2006/03/post_8.html http://d.hatena.ne.jp/JavaBlack/20060320#p1料理の品質は、客が簡単に評価できる。毎日メシを食ってれば、初めて入った店で出された料理を食べて「この店はダメだ」とか「この店は値段の割りにマトモな…

評価制度を作るのは良いけど、それで評価した後に社員に評価制度や評価結果に対して不備・不満が無いかアンケート取ってくれ。今の評価制度は使い物にならない。僕はこの半年、予定と全然違う事をした。目標の達成度という視点で見たら、とてもじゃないけど…

昨日の続き設計には、「仕様設計」と「詳細設計」がある。「詳細設計」の設計書はソースコード＋α程度で良いが、「仕様設計」の設計書＝仕様書は、先にかなりの完成度で作っておかなければならない。さて、ウォーターフォールの工程は、大きく「設計」「製造…

まず、建築における設計図に当たるものは、ソフトウェアにおいてはソースコードに他ならない。日本語で詳細な設計を書くなんて論外。電気屋さんが回路設計の設計書を日本語じゃなくて回路図で書くように、設計には設計対象を詳細に表せるための表記法があっ…

http://d.hatena.ne.jp/JavaBlack/20060206#p1 を読んでいて、過去に考えていた優秀なプログラマを集める方法を考えていたので、ちょっと公開してみる。 まず、頑張って数人の優秀プログラマを集める。 プログラミングコンテスト（高校・高専・ACM・etc...）…

部下に「失敗する権利」を与えるのが良いらしい。 「責任は俺が取るから、お前たちが考えたとおりにやれ」って言ってくれる、ソフトウェア開発管理者は希だよね。

暗黙知が人に属する以上、その人が居なくなると暗黙知は無くなってしまう。必要な暗黙知にはバックアップが必要だ。 バカな管理者は、形式知に変換する事しか暗黙知のバックアップ方法を知らない。しかし、このバックアップ方法は非常にコストがかかる。形式…

管理者は、人間を交換可能なものとして扱いたがる。たとえば、頑張ってプログラマ能力を標準化しても、個人が持っているノウハウ（＝暗黙知）を計測するのは現実的ではない。こういった数字にならない事は無能な管理者には管理できず、自分が管理できないも…

人間の入れ替えがあると、経営者が想像できないほど大きなロスが生じる。Ｍさんは長い間この職場におられて、大量のノウハウを保有している。たとえＭさんと同じ能力を持ったプログラマ（Ｍさんレベルのプログラマは、適当に雇って適当に配置しているだけだ…

前、「管理者は全員デマルコ本を読む事」って言った手前、自分で読んで無いのは許せないので、Amazonのマーケットプレイスで買った。ただし、 デッドライン―ソフト開発を成功に導く101の法則 は既に直属の上司であるSさんに借りて読んだ。で、今回買ったのは…

「ソフトウェアは見えないから見える化が必要」って、矛盾してるよね。見える化・定量化は、見える部分・定量的に表せる部分に注意を向ける。ソフトウェアの大事な部分は見えない部分なのにね。 「ソフトウェアは見えないから難しい」のだから、管理者が開発…