No.246 正しいものだけが生き残っている訳ではない
・明らかに管理不足でも
ソフトウェア開発に関して、マネジメントが機能していなくても、品質と開発期間を犠牲にすれば開発はいつかは終わり、リリースすることは可能です。営業力があれば、製品は売れるし、参入障壁が高ければ、そんな開発でもシェアは取れたりするのでしょう。
・昔気質の職人なら
細かいことは言わず、任せてくれて、出来るまで待ってくれるのだから、意識の高い系のソフトウェア開発者なら、好きにやれるのでいい環境と言えなくもないかもしれません。
しかし、そういう人材を育てるというのはこれからますます困難になるし、そもそもその会社は育てている訳でもないということになります。
・どこかに限界点がありそうだけど
北朝鮮の体制が維持されるのと同様に、そういう会社でもなんとなく続いていくということはあり得ます。しかし、それによって失われたものは、主にソフトウェア開発者が払っていることになります。周りの見える人は離職することになるだろうし、性格的に動くタイプでない人とか、受け身の人は残っていくのですが、レベルは徐々に低下していくでしょう。開発期間は遅れが徐々に大きくなっていくので、競争力は落ちていきます。そういう構造で生き残れると言うのは、環境が変わるまでは維持されるのだろうなあとなんとなく思っています。
ソフトウェア開発者にとってはいい職場ではないのでしょうね。
No.245 正しいソフトウェア開発とは
・結果だけ見るなら
製品が売れて、会社の売り上げが伸びているなら経営としては正しいと言わざるを得ません。ただそれがマネジメントされたものであるなら、同じようなにやっていくことはできるでしょう。そうでないのであれば、何かが起きた時に、踏みとどまることも、立て直すこともできずに転落してしまうかもしれません。
・マネジメント
マネジメントされているのであれば、結果はコントロール下にあるということで、予定から遅れて製品が完成するのが当たり前などということはあり得ません。
そして遅れる際にも、経営的な計算によって、出すのを後にすることを選択しているのであって、それしか選択肢がないようなやり方がされているはずはありません。
・わからないものをなくさないと
マネジメントされているのであれば、ソフトウェア開発の状況も、開発チームの力量も的確に把握されている必要があり、そのためには開発に伴うデータが蓄積されているはずです。そうでなければ、やるのと先送るのがどちらが正しいか判断することができないはずなのです。
品質は経営の質が決める側面も持っているのだと考えています。
No.244 想定を超えること
・悪い方に超える
信じられないほどソフトウェア質が悪いことがあります。テストをしていると本当にネガティブな気分になります。
特に海外で作られたソフトウェアに関しては顕著です。
・なぜひどくなるのか
これは、発注側の姿勢によるものが多いと思っています。
メンタリティの違いを認識しないで、品質の悪いものを受け入れてお金を払ってしまったら最後、相手はこちらをなめてまっとうに相手をしてくれません。どんどん質は低下します。
こうなってしまうと、その先は地獄になります。
・日本的な考えは世界ではカモに過ぎない
契約社会がなぜ契約社会なのかを考えたとき、契約しないとやらないからと考えるのはまだ甘いです。契約してもやらないのから訴訟できる余地を残せるようしたのが契約社会になった所以だと筆者は考えています。ゆえに頼んだからやってくれるとか思うような考え方は相手にカモにされて行くだけです。常に厳しい態度で臨み、少しの違いも許さない姿勢を見せ続けるのが正しいやり方です。本当に厳しいことがやれないなら、外に話を出すべきではないのです。
No.243 マネジメントは要です
・ソフトがわからなくても
管理する立場にいたのなら、ソフトがわからなくてもやらなければならないことがあります。それは、状況を明らかにすること、問題があれば解決することです。その問題の解決から逃げることは許されません。
・問題が発覚したら
もし問題が発覚したら、説明を求めなければなりません。そして対策を取らねばなりません。ソフトウェアで難しいのは遅れているときに人を投入しても早くなることはありません。まあ、「人月の神話」を読めばわかることです。
・どうやって解決する
PMBOKに倣っていうのであれば、問題と正対し、解決する方法を探ります。これが工数の問題であるなら、人の投入は悪手ですので、肩代わりしてくれる先を探すか、開発の後工程の効率化などに転嫁するなどの方策を取ることも考えられますし、一部の開発案件を次バージョンに回すことも考えます。最悪は全部受容して、納期を遅らせるとなります。まあ、この辺りはソフトがわからない管理者でもできることですので、どうか逃げないで頂きたいと願うものです。
No.241 属人性を排するということ
・達人になれば品質を上げられる
ドメイン知識が豊かになれば、それだけ設計でもテスト設計でもその知識をうまく生かして、より高い品質の成果物を作り上げられるという考え方は、当たり前に思えますがその方向に進むのは危険といえます。
なぜならば、その人を失ったときに同じ品質レベルが保てないからです。これは工業製品としては許容できないことと言えます。
・プロセスを重視するとは
プロセスを重視するとは、普通の人が決められた通りの仕事をしたときに達成される品質レベルが、実施した人に関わらず同じレベルに保たれていることを目指すものです。そのためにいろいろなものが明文化される必要があります。これがプロセスにおける生命線になると思います。
・他人は自分の出来ることが出来ない
多くの場合、自分にも出来るのだから誰にでも出来るだろうと考えてしまうのではないでしょうか。条件が同じになればある程度の人はできるかもしれませんが、ちょっと頼む程度の頼み方では恐らくほとんど場合はできないでしょう。人に頼むほうが大変だからプロセスやナレッジが存在します。故に安易に人や組織をダメだと言ってはいけません。まず、他人はできないのが当たり前だと思うことから始めることが基本にして究極なのではないかと愚考している今日この頃です。
No.240 仕様書
・仕様書を書かないで作る？
ソフトウェア開発において、仕様書を作らないでいきなりコードを書いてしまうケースはあるようですが、本当にそれがベストなプロセスなのだろうかというのは考えてしまいます。
出来上がるのかどうかで考えると、ほとんどどんな要求も応えることは可能です。背反するものは無理かも知れないですが、個別に1つを見たときに不可能なケースはメモリが足りないとかの物理的な問題ぐらいですが、それ以外は結局は作れます。だから仕様書は不要なのかと言えば・・・どうでしょうか。
・書かないのが悪いのではない
書かないというのは、プロセス上、その行為が必然ではないということで、書かない人が悪いなんてことはありません。要するにチェックするということがない・・・だから書く必要がない。
結局、そういう人材育成をしていないということになります。
・ソフトウェアの開発上の問題がエスカレーションされても
さらに困ったことに、そうなると、ソフトウェア開発上の問題がエスカレーションされても、スルーしたところでいつかはできるとわかっているので、上の人間は問題点を問い詰めたりしません。みんなでスルーして「ソフト屋がまだまだだ！」とか言っていれば言い訳です。
ということで、うちのソフト屋はまだまだ・・・とか、あそこのソフト会社はいまひとつ・・・とか、言っている会社は、ソフトウェア開発者を志す人間が入るのは個人的にはお勧めできないという感じでしょうか。
No.239 テスト設計２
・まず全体の定義から
すべてを見ることも全数テストも無理なことはわかっています。そうなると、どんな考え方で、今回のテストとしての全部を決定するかでテストの量も質も変わってきます。
・どんなモデルにする
全部を定義するとしたら、事前条件、入力、処理、出力、事後条件の組み合わせをどう考えて決定するかが個人的には考えるところです。
例えば全部の入力を入れてみることを今回の全部として定義することでモデルが決まるという感じです。
・あとは網羅条件
そこから、どこまで網羅すればOKか決めます。組み合わせ網羅では、爆発的に回数が増えそうなので、２因子網羅にするなどのテクニックを駆使しながら、期間内で実現可能な網羅条件を設定することで、テストを構築していくのが基本的な流れだと思っています。でも他にいい方法がないか、日々考えたり調べたりするのは変わっていませんが、なかなかいい方法には巡り合えないものですね。
