|
- 2008/08/27 20:42豊富すぎるリソースは、生産性と創造性を損なう
- 10人で、10ヶ月かかる仕事があったとします。100人月です。では、20人いれば、5ヶ月で終わるかというと、そうはいきません。単純計算ではいかないのが、プロジェクトです。なぜか。それは、人数が増えることによる、コミュニケーションロスもあり... [続きを読む]
|
- 2008/08/24 01:54自己のROEを高める
- エンジニアは知識労働者です。知識労働者は、つねにその知識を更新しなければなりません。それには自己投資が必要です。しかし、投資であるからには、そのリターンを考えなくてはなりません。元をとらないといけないのです。ただ漫然と、本を読ん... [続きを読む]
|
- 2008/08/17 23:33問題はなくならない
- 改善を進めようとする人が、疲れてしまうことがあります。いつまでもなくならない問題に、疲れてしまうのです。これはあるひとつの思い込みが原因です。すなわち、 いつか問題のない、理想的な仕事ができるという思い込みです。しかし、理想... [続きを読む]
|
- 2008/08/04 21:03言い訳をしない
- 何か問題が起きたとき、失敗したとき、言い訳したくなるのが人情です。言い訳はいくらでもできます。できなかった理由は、いくらでもあるからです。しかし、言い訳をしてしまうと、そこからは、何一つ学ぶことができません。脳が、 仕方なか... [続きを読む]
|
- 2008/08/04 00:16善なる待機
- いま、日本全体で、景気が落ち込んでいます。原油高、原価高によって、企業の業績が下方修正されています。ソフトウェア業界も例外ではなく、プロジェクトの途中打ち切り、予算の圧縮、削減など、わたしたちソフトウェアエンジニアの仕事を直撃しています。... [続きを読む]
|
|
|
- 2008/07/28 00:00アマゾン第２四半期ランキング
- もう前四半期を過ぎて、かなり時間が経ってしまいましたが、ランキングにまとめておきます。第１位勝間和代のビジネス頭を創る7つのフレームワーク力 ビジネス思考法の基本と実践記事リンク：「ビジネス版「クスリの辞典」」勝間和代は強し。やはり、罪深... [続きを読む]
|
- 2008/07/27 12:41結果に対応するのではなく、原因をつくる
- 世の中のすべての物事には、原因と結果が存在します。原因がなければ結果はなく、どんなささいなことでも、かならず結果を生み出します。それが因果律です。ソフトウェアプロジェクトも、例外ではありません。できるマネージャと、そうでないマネ... [続きを読む]
|
- 2008/07/22 06:36モチベーションのせいにしない
- よく、「きょうはモチベーションが上がらない」とか、「あの上司の下では、モチベーションが下がる」などといいます。たしかに、モチベーションの波は、誰しもあるし、環境によって左右されます。しかし、仕事は仕事であって、モチベーションが高... [続きを読む]
|
- 2008/07/13 22:15人には受け入れてくれる人が必要
- 人はそれぞれ、必死で生きています。うまくいかないことも、たくさんあります。だからといって、ダメなわけではありません。間違っているわけではありません。ただ、未熟なだけです。だとすれば、成長すればいい。うまくいっても、うまく... [続きを読む]
|
- 2008/07/13 18:08折衝は、終わったあとの「状況」をイメージして臨む
- 納期交渉、単価交渉、見積もり交渉、ソフトウェア開発では、日々、さまざまな交渉がなされています。ソフトウェアプロジェクトは、さまざまな利害関係を持った人たちで成り立っています。そして、利害の異なる人たち同士が、それぞれの利害を守るた... [続きを読む]
|
- 2008/07/06 14:15人はニセモノがだいすき
- 人はほんとうに役に立つもの、自分のためになるもの、必要なものよりも、一見、きれいなもの、きらびやかなもの、わかりやすいやさしさに、寄っていってしまいます。しかし、派手なもの、パフォーマンスが過ぎるもの、ほんとうのやさしさではないも... [続きを読む]
|
- 2008/06/30 00:05デキル奴と、結果がダセル奴は違う
- ソフトウェアエンジニアが、よく理解しておかなくてはならないのは、結果を出すためには、ほとんどの場合、技術は二義的なものなのだということです。もちろん、プロとして満たさなければならない、技術的水準は、厳然として存在します。しかし、そ... [続きを読む]
|
- 2008/06/29 22:28過去のメールをすべて読んでみる
- プロジェクトで起こる問題は、一つひとつ異なりますが、パターンは似通っています。そのパターンを知ることが、プロジェクト成功への、一つの手立てです。ほとんどのプロジェクトでは、あらゆるやりとりが、メールで行なわれます。ということは、... [続きを読む]
|
- 2008/06/29 22:15形式知は展開できるが、暗黙知は展開できない
- 一芸は万芸に通ず、といいます。一つの道を究めた者は、ほかの道に進んでも、かならず大成する、ということです。つまり、あるものに上達することによって、普遍的な上達のコツを習得できるのです。しかし、現実にはそうとは限りません。確か... [続きを読む]
|
- 2008/06/29 21:02学びもシナリオ思考で
- 仕事は常に、ゴールから逆算しなければなりません。これが、シナリオ思考です。まずゴールをイメージし、その１ステップ前には、どんな状態になっていなければならないか。そのプロセスには、どんなインプットが必要か、どんどんさかのぼって、... [続きを読む]
|
- 2008/06/29 18:34プロのエンジニアリングとは―『ソフトウエア開発プロフェッショナル』
- ソフトウエア開発プロフェッショナル『Code Complete』の著者、スティーブ・マコネルが書いた、ソフトウェア・エンジニアリングに関する本。目次：日経ＢＰ社より序論最良のときと最悪のとき／本書の目的／本書の構成／1999年以降、学んだこと／本書の対象読者... [続きを読む]
|
- 2008/06/29 13:12本ほど安いものはない
- ディスカヴァー干場社長が、本というメディアの優秀性について、書かれています。ディスカヴァー社長室ブログ：私達は、用紙代にお金を払うわけではなくて、その中身、書いてあることの中身にお金を払っているはずなので（このことについても、以前こちらで、問題... [続きを読む]
|
- 2008/06/29 12:48刻んでやる
- 何度か書いているように、ソフトウェアエンジニアには、３つの知識が必要です。 ・ドメインの知識 ・コンピュータサイエンスの知識 ・ソフトウェアエンジニアリングの知識ドメインの知識とは、組み込み業界であれば、携帯電話や、カーナビといった、... [続きを読む]
|
- 2008/06/27 00:34ストリートスマートな数的感覚―『数に強くなる』
- 数に強くなる (岩波新書 新赤版 1063)※『ＳＥの本棚』統合にあたり再掲エンジニアは必読。この本に書いてあることを実践し、数に対する感覚を身につければ、進捗管理や、見積もりなんかは、オチャノコサイサイでしょう。この本を読んで、私はいままで疑... [続きを読む]
|
- 2008/06/26 23:33評価、イコール価値ではない
- 人は人に評価されます。入学試験では、学校が受験生を評価します。会社に入ってからは、上司が部下を評価します。そして、市場が企業を、商品を評価します。人が人に評価されることを、避けることはできません。しかし、ここで覚えておかなく... [続きを読む]
|
- 2008/06/25 06:06理解を深めて、人と向き合う―『もし部下がうつになったら』
- もし部下がうつになったら 「携書」このブログでも、何度かふれていますが、ＩＴ業界における、うつの発生率はかなりのものです。いつ自分がそうなっても、おかしくありません。とくに、上司がうつになってしまった、というケースは、少なくないでし... [続きを読む]
|
- 2008/06/25 00:57改善は、改善したあとのひずみをとってやっと改善
- フォーマットや、プロセスの改善を行なう際、改善案を出してさえしまえば、もしくは、改善を実行さえすれば、やった気になってしまいます。しかし、それではまだ足りません。改善では、かならずどこかに、ひずみがでます。改善したことによって... [続きを読む]
|
- 2008/06/22 20:49日本人が忘れてしまったもの―映画『西の魔女が死んだ』
- 観終わったあと、誰も立ち上がらず、誰もひと言も発しませんでした。ただ静かに、余韻に浸っていました。そんな映画は初めてです。小説を読んで感動して、その静かな、愛に溢れた空気を、映像でも感じてみたい。そう思って、映画を観にいきま... [続きを読む]
|
- 2008/06/22 13:24プチうつのとき、聞いてほしい２枚
- サーフィシングクリムゾン・コレクション1&2守護ＩＴ業界は、構造的にうつになりやすい、そう言われています。慢性的な長時間労働、納期のプレッシャー、スキルの陳腐化、先行きの不透明さ、たしかに、他の業界よりも、うつになりやすい... [続きを読む]
|
|
|
