設計できないエンジニア（２） (2001/6/4)
『ソフトウェア開発２０１の鉄則』の解説 はこちら
長く IEEE Software 誌の chief editor を勤めている Alan M. Davis 氏の本に、「201 PRINCIPLES OF SOFTWARE DEVELOPMENT」（邦訳名：「ソフトウェア開発２０１の鉄則」松原友夫訳、日経ＢＰ刊、\1,600 見当）という名著があります。いわゆる「ベスト・プラクティス」の集大成で、著者以外にも多くの人の「Principle」を集めたもので、ソフトウェア・エンジニアだけでなく、マネージャーにとっても、とても参考になる本と私は評価しています。ただ、この本は、２０１項の「Principle」を集めたもので、それぞれの原理を味わい、読者自身の仕事に活かすには、多くの知識と経験を必要とするため、おそらく、読者は「もっともなこと」という感想だけで終わってしまう可能性があります。そこで『ＳＣだより』のページで、毎月１項目づつ選んで、その意味や背景、さらには、それを実践するための手掛かりなどを解説していますので、そちらも参考にしてください。
設計できないエンジニア（２） (2001/6/4)
◎ これからのソフトウェア・エンジニア
（）
・「プロ化」の動き
(2000/1/2)
（いまアメリカでＳＥの世界に「プロ」のライセンスを導入することが議論されています）
・エンジニアって？ (98/12/20)
（エンジニアは知識労働者としてのスタイルを持っていることが前提である）
・プロであるために (97/11/2）
（プロとして認められるためにどのような判断基準があるか）
・プロフェッショナルって？(7/30/97)
（これからのエンジニアは「プロ」でなければ通用しない）
◎ 耐えず技術革新に取り組む(97/2/9)
（適切な本を読み、自分への投資を惜しまないこと）
・自分という商品 (2000/12/29)
（これからは、自分のセールスポイントをアピールできることが求められる）
・なぜ勉強しない？ (2000/8/13)
（我が国では、自主的に知識や技能の修得に取り組んでいるひとは１０％に満たないという）
・標準作業を身に付けよ (9/6/98)
（勇気をもってプロセスの改善に取り組むことが、あなたの明日を開くことになります）
・「１番」を目指すことの意義 (8/9/98)
（「No.1」を目指さなければ、有効なアイデアも工夫も“粘り”も出てこない）
・「未来への道」(3/29/98)
（日経エレクトロニクスに見る、組み込みシステムのソフト開発の未来）
・「日常業務」で埋め尽くさないこと！(8/30/97)
（忙しさを理由に先行投資を怠れば自転車操業に陥るだけです）
・自分の役割を文字にしてみよう(8/30/97)
（自分の役割を再認識すると同時に“うまく”やるという認識が欠かせません）
・仕事を家庭に持ち込まない？(6/13/97)
（それではエンジニアといえるでしょうか？）
・年間目標を立てる(3/8/97)
（１年は“アッ”という間に過ぎていきます）
・外部の世界と積極的に接触する(3/8/97)
（「井の中の蛙」は避けなければなりません）
・技術に関する本を読む
（技術の革新は早いもの）
・社会の動きの分かる良質の雑誌を読む(3/15/97)
（全ては社会・経済の枠の中にある）
・時には自分の成果を否定する(3/15/97)
（成功体験は時には命取りになる）
◎ 仕事が約束出来ること(97/2/9)
（約束できる方法を持たないでは仕事になりません）
・設計できないエンジニア（２） (2001/6/4)
（適切な設計書も書いたことが無いというのではエンジニアとは呼べません）
・「設計」できないエンジニア
(2000/5/21)
（適切な設計書も書いたことが無いというのではエンジニアとは呼べません）
・詳細スケジューリングに取り組む
（６ヶ月のプロジェクトを３％の誤差で実現できますか）
・工数を読むことの意義について(96/12/12)
（いろいろな問題が工数を読もうとしないことから起きる）
・１日５分トレーニング
（自分で自分をコントロールできる！）
・考えるタイミングを見直す (96/12/27)
（ぎりぎりになって考えるのはよしましょう）
◎ 専門性と社会性の両立(96/12/27)
（人としての３つの役割を果たしながら仕事をすること）
・時代の転換に備えよ (98/7/11)
（日本を取り巻く状況が大きく変わろうとしている状況が見えていますか？）
・市場価値(Market Value) (97/12/20)
（あなたは“市場価値”を持っていますか？）
・迫り来る市場の要請
（市場は一体何を求めているのか）
◎ 意識の変革
・「文献の読み方 ー間違っていませんか？」 (98/11/22)
（多くの人は、プロセスを変えるための読み方をしてないのではありませんか？）
・「反省」の落とし穴 (97/11/23)
（「失敗のパターン」を繰り返し習慣に焼き付けるだけでは解決しない）
・電子メールと仕事の特徴 (97/11/2)
（電子メールに接する姿勢に、その人の仕事の特徴が現れる）
・Think Think Think! 考え続けること (97/8/30)
（考えるという行為が日常の中に組み入れられるように）
・朝こそすべて！ (97/8/10)
（朝を疎かにして、集中力や思考の深さを損ねていませんか？）
・「出来るかどうか」から「どうやってやるか」へ (96/11/28)
（出来ない言い訳の出る余地をなくす）
・「考えること」について(96/11/28)
（本当に考えていますか？）
・バグとプロセスの関係について(96/12/5)
（プロセスの欠陥がバグを産み出す）
◎ ソフトウェア・エンジニアにかかる構造的問題（96/12/12)
（この国のＳＥに於ける根本的重要問題です）