・講演をしてくれと言われて 還暦を過ぎて再雇用で働く身の上の自分に、こんな依頼があるとは思ってもいなかったのだが、社会貢献できる機会を頂けたのだからと、ボランティアとして受けることにしました。 なぜ要求でくろうするのかを語ってほしいというの…

・外国人との差異 知識としてメンタリティが違うということが分かっていても、実体験としてそれを学ぶケースは多くはないでしょう。 外国人の開発者にこちらがテスターとして不具合を指摘して直してもらうのは、そのメンタリティの違いを乗り越える必要があ…

・常識とは刷り込みのようなもの その環境における普通が、一般的なものと違っても、その世界しか知らないものにはそれ以上のことはできないものです。 北朝鮮の体制が維持されるのも、そういう側面があるのだと思います。 だから、まともとは言えないプロセ…

・組織のために 組織は組織のために、人を使います。しかし、人にとってのベストな環境といえるかどうかは別物です。 仕様変更、プロセスを無視する例外の強要、それらはすべて組織のためにの一言で成立する世界といえます。 ・自分のために 組織を優先する…

・仕様書は後回しで これを認めた結果、仕様書をチェックする人間は不要になります。そして書く人間もチェックされなくなるので、そのスキルは育ちません。 例外を認めるということはその組織の価値を貶めています。 ・リリースは早くなるのか 例外を認めて…

・成功体験は必ずしも正しくはない 開発の仕方が、どう考えても効率的でないのは、成功体験の実績が力技で何とかしたものだったのではないかと思います。 プロセス通りに作るのではなく、苦肉の策で何とかするのでは、いろいろなものが犠牲になってしまいま…

・よくある話ですが テストをしてリリースするとリリース後に新たな不具合が発覚することがあります。 そして再発防止が求められ、チェックリストに今回の不具合項目を追加してテストすることにします。 ここまでは問題ないように見えますが、実は問題が潜ん…

・ソフトウェア開発者として ソフトウェア開発を育てるとして、必要なポイントが２つあると考えています。その２つのポイントは考え方と書き方だと思っています。書き方がどれだけ良くても、考え方がまずければその先にはいけません。故に先に考え方を洗練さ…

・何を以て評価するか ソフトウェア技術者の評価を成果物を直接見ることなく決めるのは危険です。 きれいなコードを書く人と、汚いコードしか書けない人が、同じような評価を受けるのでは、とても危険な事と言えます。 評価の仕組みがプアな会社にソフトウェ…

・製品の機能がてんこ盛り 多機能でいかなる場合にも適用できる製品は非常に魅力的に映ります。しかし、結局のところ、全く使わない機能にお金を払っていることになるわけですから、それが正しいとは言い切れません。 ユーザが欲しがるからと機能をどんどん…

・事態は常に変化している どれだけ目の前の仕事をこなそうとも、前提としている条件が変わってしまえば、勝利条件が変わってしまうのはよくある話です。 例え前向きに戦えていたとしても、起きるときは起きます。 ・被害者意識でいても救われない 確かにこ…

・開発の外部委託も第三者検証も 発案者以外が実行するものは論理的でなければならないと考えています。 確かにすべてを理解して実行できるのであればパフォーマンスはベストが出るとは思いますが、これは人に依存する方法に他ならないと考えています。 ・わ…

・明らかに管理不足でも ソフトウェア開発に関して、マネジメントが機能していなくても、品質と開発期間を犠牲にすれば開発はいつかは終わり、リリースすることは可能です。営業力があれば、製品は売れるし、参入障壁が高ければ、そんな開発でもシェアは取れ…

・結果だけ見るなら 製品が売れて、会社の売り上げが伸びているなら経営としては正しいと言わざるを得ません。ただそれがマネジメントされたものであるなら、同じようなにやっていくことはできるでしょう。そうでないのであれば、何かが起きた時に、踏みとど…

・悪い方に超える 信じられないほどソフトウェア質が悪いことがあります。テストをしていると本当にネガティブな気分になります。 特に海外で作られたソフトウェアに関しては顕著です。 ・なぜひどくなるのか これは、発注側の姿勢によるものが多いと思って…

・ソフトがわからなくても 管理する立場にいたのなら、ソフトがわからなくてもやらなければならないことがあります。それは、状況を明らかにすること、問題があれば解決することです。その問題の解決から逃げることは許されません。 ・問題が発覚したら もし…

・達人になれば品質を上げられる ドメイン知識が豊かになれば、それだけ設計でもテスト設計でもその知識をうまく生かして、より高い品質の成果物を作り上げられるという考え方は、当たり前に思えますがその方向に進むのは危険といえます。 なぜならば、その…

・仕様書を書かないで作る？ ソフトウェア開発において、仕様書を作らないでいきなりコードを書いてしまうケースはあるようですが、本当にそれがベストなプロセスなのだろうかというのは考えてしまいます。 出来上がるのかどうかで考えると、ほとんどどんな…

・まず全体の定義から すべてを見ることも全数テストも無理なことはわかっています。そうなると、どんな考え方で、今回のテストとしての全部を決定するかでテストの量も質も変わってきます。 ・どんなモデルにする 全部を定義するとしたら、事前条件、入力、…

・決めるべきこと どんなものにもゴールは必要で、テストが終わったときにどうなっていなければならないかを決めておかねば、テスト設計はできません。 対象の範囲、そして密度、そして実践する方法などが必要です。 どこからどこまで見るのかは、特に派生開…

・不具合を見つけないテスト かつてよく聞いた言葉に「何個不具合を見つけたのか？」というものがあります。これを言われると自動テストより手動のテストのほうが不具合を見つける可能性が高くなり肩身が狭いなんて話を聞いたこともありました。まあ、単体テ…

・明らかに モノづくりとしてはわきが甘いソフトウェア開発で、品質に関しても十分な評価ができているように感じられなくても売上の数字はよく、儲けている組織はあるように思えます。 とすると、多分、相応の品質目標があるのでしょうが、なんとなく届いて…

・ソフトウェアを作る過程で ソフトウェアが工業製品として作られる以上、その品質は保証されねばなりません。よって、テストをするのは当たり前のことになります。 このとき、何となくいつものように実行して、いつものようなことが繰り返されて、なんとな…

・ゴールを定義する まず、＃ソフトウェアテスト であるなら、テスト完了時点の品質をどうやって担保するか考えねばなりません。そこから、どれだけのことをすればそれが達成できるのかを導き出します。多少強引でも決めてしまう必要があります。 そうしなけ…