はじめに
派生開発推進協議会（AFFORDD）の皆様のお力で清水吉男さんの「"硬派"のホームページ」を復活させていただけました。感謝申し上げます。
清水吉男さんの「"硬派"のホームページ」には、多くの有益な記事があります。
この中から私が個人的におすすめする記事を、12件選び、まとめておきます。
"硬派"のホームページ
おすすめ記事
「１番」を目指すことの意義
シェアでも利益でも構いません。あるいは絶対額では規模の大きな先発企業に叶わないというのなら「率」でも構いません。「顧客満足度」でも構いません。仕事の仕方でも、残業時間の少なさでも構いません。とにかく「１番になる」という目標の存在が、そこに居る人たちの脳を刺激します。道を歩いていても、何かを考えようとするはずですし、そのような“思い付き”を大事にしたいという思いから、歩きながら記録するための「道具」を使う工夫も生まれてきます。
自分を信じ、知恵を絞って、工夫を凝らして、どうしたら「１番」になれるか考えることです。「１番になろう」としない限り、その人の持っている素晴らしい能力が引き出されることはありません。
「No.1」に向かっての「挑戦」以外に、あなた達自身の未来を確保することは出来ないはずです。
技術を得るために自分に投資しよう
自分に“金を賭け”てください。まさか競馬には外れても、自分に投資して外れることはないでしょう。
１日５分間トレーニング
たったいまから３カ月間、個人的な日誌をつけるのに毎日５分間使うこと
この取り組みの目的は、「self control」であり、自己変革です。
「反省」の落とし穴
反省会の場で行なわれているのは、皮肉にも、「失敗のパターン」を何度も何度も焼き直し（レジストし）ているだけで終わっているということです。彼らは、失敗しようとして失敗したのではありません。その方法しか知らないのです。
「なぜ上手く行ったのか」「何が効果を発揮したのか」を、文字にすることで確かめるのです。そしてそれを人に話すのです。そうすることで、「成功のパターン」を焼き付けることになり、次も同じように上手く出来るのです。
「評価」についても「上手く行くパターン」を探し、繰り返すことに外ならないのです。多くの組織では、評価は「失敗のパターン」を見つけては、それを一層焼き付けることに精力を費やしているのです。エンジニアがバグを出したことで、自ら「反省」と称してその「失敗のパターン」を焼き付けているのと同じように、「評価」においても、「失敗のパターン」を焼き付けることに力を貸しているのです。こんなことを何時まで繰り返しても、何も変わらないのです。
「分かる」の問題について
「分かる」とはその人が分かったと思う範囲でのみ分かったのである
発表の場を設けることの必要性について
先ず、組織の評価基準を「加点主義」に転じる事が必要です。満足の行くような結果でなくても、少しでも前進すれば評価することです。もちろん、その際に、取り組みの過程を振り返って反省することは当然ですが、期日との開きが小さくなったり、要求の盛り込みモレが大きく改善されたり、不具合の件数が改善されるような結果の背景には、それ相当の取り組みがあったはずであり、それは間違いなく評価に値することの筈です。
そしてこのとき、チームや組織の中で、自分たちの取り組みを発表することです。最初は恥ずかしいかも知れませんが、ここを乗り越えないと、何時まで経っても個人のスキルから組織のスキルに転化できません。はっきり言って他に方法はないのです。
間違ったマネージメント
部下（２１世紀に不適切な用語かも知れない）の人生を考え、その人がいい状態で長く仕事を続けられるように、必要な技術の習得の機会を作ったり、それを妨害するような状況をブロックすることもマネージャーの仕事でしょう。その中で、「今」マネージャーに課せられた仕事（プロジェクト）をこなすために、彼らの力を借りるのです。
部下（メンバー）の将来も考えず、その時点で課せられたプロジェクトを完成することだけしか眼中にないのなら、メンバーの力を結集することは望めないでしょう。
人は、自分の人生を考えてくれる人、仕事を通じて感激を分け与えてくれる人、生きる力を与えてくれる人に自分を捧げるのであって、人生を踏みにじり、生きる力を削ぐような人に自分を捧げるような人はいません。このことは逆に言えば、マネージャーとは、人に生きる勇気を与え、感激を与える事の出来る立場でもあるのです。勿論、そのために「決める」という困難な行為を全うしなければなりません。しかしながら、その人がメンバーに生きる力を当たるような人なら、その困難を全うする力を、彼のメンバーは惜しみなく提供するでしょう。それが感激を得ることであり、生きる力を得ることに繋がることを、彼らは知っている、いや“感じて”いるのです。一人の喜びを皆の喜びに広げ、一人の悲しみを皆で薄め、“そこ”で仕事をすることに喜びを覚える。そしてそこに居る人たちが、日々向上することに愉びを感じるようでなければ、“マネージメント”とは言わない。そしてマネージャーはそれが出来る役回りなのです。何と素晴らしい役回りであることか！
「全体と部分」について
マネージャーと呼ばれる人は、一般にその「部分（部署）」の責任者です。しかしながら、責任範囲と守備範囲は同じであってはうまくいきません。自分の「責任範囲」を全うするためにも、どれだけ守備範囲を広げることが出来るかが問われます。野球でも、守備範囲は状況によって変化させなければ、いいプレーは出来ないでしょう。責任範囲を越えた守備範囲のところで、ボールをグラブに当てて落としても、“おしかったね”と許されます。もちろん、ボールを落とさなければファインプレーです。
「そこは自分の責任範囲ではないから」という論理で動こうとしない姿勢は、組織内の論理であって、そこには「顧客の論理」は見い出すことは出来ません。簡単に言えば、自分の責任範囲に接する部分は、通常は“守備範囲”でもあると考えられます。それぞれの「部分」の人達が、共通した「全体像」を求めながら、「部分の在り方」を追及することが重要なのです。
２０１の鉄則：原理６３＜設計の原理＝代替案を評価せよ＞
他の分野では，いくつかの設計案の中から，最も要求を上手く満たしている案を選択します．だが，ソフトウェアの世界では，残念ながらそうはなっていません．
２０１の鉄則：原理２０＜一般原理＝仮定を記録せよ＞
システムのあらゆるものが「仮定」なのです。いや、要件だけでなく、開発の環境や要員も「仮定」なのです。そこから出発することが、優れたソフトウェアを開発する最大の条件であることを、目を反らすことなく見つめて欲しいのです。
これまでの「標準化」の間違い
現場の人たちは、この「エンジニアリング・プロセス」の「標準」に対して、常に何らかの手を加える作業が必要です。「標準」を使うことによって、新規に開発プロセスを作る（プロセスを設計する）よりは作業は軽減されるでしょうが、必ず「標準」に対して手を加えなければならない状況に置いておくべきです。そうでないと「プロセスを設計する能力」が失われ、「標準」による弊害が出てしまいます。
大事なことは、組織の全員が「要求を実現するために最適なプロセスを設計できる」能力を持つことです。「標準」がそれを邪魔しては本末転倒になります。「標準」を持ち込むメリットを活かしながら、それでいて「標準」によって大事な能力を失わないところに「標準」を求めるべきです。
そもそも「ＣＭＭ」が目指すのは、“組織の能力”を引上げることです。そこでいう“組織の能力”とは、要求を実現するための最適のプロセスを自在に設計できる“能力”です。要求は絶えず変化し続けます。それに応じる側の体制も常に変化します。特に、ソースから距離が離れるプロセスに於いては、２度と同じプロセスは使えないと言っても良いくらいです。
ここでの「標準」は、そのままでは使えないのです。プロジェクトの要求に合わせて、具体的な成果物名を特定したり、調査のプロセスを追加したり、メンバーに合わせてプロセスを３つに割ったりしなければならないのです。「標準」は、プロセスを１から構築する時間と、その際のブレを省くのが目的であって、自分たちのプロジェクトに対する要求を実現するために、毎回、プロセスを設計する能力を失わせてはならないのです。
仕事を楽しくなるようにしよう
仕事というのは、最初から楽しい状態にあることは稀です。楽しくなるのは、その仕事を上手くこなせるだけの技術や知識が身についてからのことです。問題は、その知識や技術を、いつ身に付けるかということです。ただし、ソフトウェアの仕事の場合、技術がどんどん変化するので、知識や技術の種類によっては習得を日常の中で継続させなければなりません。そうして、仕事がうまくできるようになれば、仕事は楽しくなり、そのことがまた日常の学習行動の動機に繋がっていきます。結果によっては報酬も増えるでしょう。
早い段階でソフトウェアの開発作業が“上手く”できるようになって、自分の持ち時間を“次”のための勉強や研究に確実に投入できる体制を手に入れることです。それが、この世界で長く活躍する場を確保することにつながるし、何よりも、仕事が楽しくなるはずです。
おわりに
ソフトウェア品質管理研究会にて、厳しく・温かいご指導をいただいた清水吉男さんに感謝申し上げます。
ありがとうございました。
関連記事