開発の仕方が、どう考えても効率的でないのは、成功体験の実績が力技で何とかしたものだったのではないかと思います。
プロセス通りに作るのではなく、苦肉の策で何とかするのでは、いろいろなものが犠牲になってしまいます。
これがないと売れないとうことで話が府tt来ることがあります。そういう話で、要求がねじ込まれるなら、少しおかしいです。売れない企画でここまで動いていたのは由々しき事態なのに、誰かの責任問題になったりしないのは、さらにおかしいことですが、そういう話にはならないのでしょう。
参入障壁が低かったり、うまみのない市場でのやり取りのみに追われていた会社であれば、そんなやり方でも今しばらくはやっていけると思います。しかし、この情報化社会ではそんなやり方が通るのであれば、人材の確保はどんどん困難になるでしょう。その行く末を考えないのは経営者の視点ではないのでしょうね。
テストをしてリリースするとリリース後に新たな不具合が発覚することがあります。
そして再発防止が求められ、チェックリストに今回の不具合項目を追加してテストすることにします。
ここまでは問題ないように見えますが、実は問題が潜んでいると考えています。
不具合が発覚するたびに、チェックリストが増えていくそうなると、やたらと時間はかかるし、リストそのものも価値があるのかわからなくなってきます。
この問題は不具合が流出する現状を肯定して、穴埋めの作業だけを追加することにあります。
ダメな現状を肯定して、延命措置を繰り返すというやり方で凌げるのは数回が限度でしょう。
きちんと分析してテスト設計からやり直すべきでしょう。
ダメなものを延命させるような対処を繰り返すというのは、その組織のレベルの低さの表れと考えるとよいと思います。
ソフトウェア開発を育てるとして、必要なポイントが２つあると考えています。その２つのポイントは考え方と書き方だと思っています。書き方がどれだけ良くても、考え方がまずければその先にはいけません。故に先に考え方を洗練させなければなりません。
設計というのは最悪値も考えねばなりませんが、それだけに囚われると、冗長なつくりにならざるを得なくなります。この匙加減は難しいのですが、避けて通ることはできません。
書き方は割と簡単に評価できる部分がありますが、考え方は難しい面があります。
表現の仕方に幅のある世界なので、認知バイアスの影響もあって、誤解とか齟齬とかから逃れるのが困難だったりするのです。だから評価する側にも相応のスキルが必要なのです。これがまた問題を難しくしているように思えます。
自分の仕事を人にやらせるとどう考えても自分でやったほうが速いと思うことがいっぱいあります。それが思っていることを表現する難しさであり、ドキュメントの出来そのものを左右する要素になります。ここは試行錯誤することでしか身につかない部分もあるので、正解を安易に欲しがると痛い目を見るかもしれません。
地道に経験を積み上げるのが一番なのは何事も同じなのかもしれません。
ソフトウェア技術者の評価を成果物を直接見ることなく決めるのは危険です。
きれいなコードを書く人と、汚いコードしか書けない人が、同じような評価を受けるのでは、とても危険な事と言えます。
評価の仕組みがプアな会社にソフトウェア技術者は居るべきではありません。
何かが向上した際に、それを評価する人間がいなければ、その人にとっては無駄な時間を過ごしたのと同じになってしまいます。
だから、成果物も中間成果物も直接見て、評価する仕組みがなければ人を育てていくことはできません。
ソフトウェアが経費として計上される会社では、ソフトウェアの価値が金額計算されない可能性が高いです。そうなると、無駄かどうかを判断するする術が大きく減ることになります。
また、ソフトウェアの開発上で生じた問題に関して、経営層までエスカレーションされて対策が取られないのであれば、その会社ではソフトウェア技術者は孤立していると言えます。
それでも製品が売れるので大丈夫というのは、そこが他社にとって参入障壁が高いなら良いのですが、結局、そのフィールド自体、その商品にそこまでの価値が認められないので、他社にとって旨味がないような市場でしかないのかもしれませんね。だから延々と飼い殺しの状況が成立してしまうのかもしれません。
多機能でいかなる場合にも適用できる製品は非常に魅力的に映ります。しかし、結局のところ、全く使わない機能にお金を払っていることになるわけですから、それが正しいとは言い切れません。
ユーザが欲しがるからと機能をどんどんと盛り込んでいくのは、適正な企画の結果とは言えないと思います。
正論を振りかざす人は多くいます。やらないよりやったほうがいい。少ないより多いほうがいい。それはどれも正論です。その理屈の果ては「完璧以外すべてダメ」になります。機能てんこ盛りの製品はその道を走り続けているように見えます。
製品は売れるかもしれません。それを成功体験として、次々と多機能化していくのだとすれば、開発の手間も、テストの大変さも指数的に増えていきます。いつか臨界を超えるのがわかっていても、その成功体験から抜け出せないのは、悲劇といえます。
適切な度合いが何にでもあるということを踏み越えてしまうと、多くの人を不幸にしていくような気がします。
さて、何が正しいのか、結果が出るのも見届けるが恐ろしいです。
どれだけ目の前の仕事をこなそうとも、前提としている条件が変わってしまえば、勝利条件が変わってしまうのはよくある話です。
例え前向きに戦えていたとしても、起きるときは起きます。
確かにこの状況を招いたのは、自分たちではありません。被害者であると思う気持ちもわかります。ただし、救われて当然などという保証は絶対にありません。だから自分であがかないとならないのです。
視野狭窄になって、目先のできることに飛びつてしまうと、状況が更に悪化する場合があります。なので、思い切って手を止めてでも、全体を見直すことが必要です。
結局は、勝負はここからという気概だけが、自分を支えているのかもしれませんね。
発案者以外が実行するものは論理的でなければならないと考えています。
確かにすべてを理解して実行できるのであればパフォーマンスはベストが出るとは思いますが、これは人に依存する方法に他ならないと考えています。
これは、その開発やテストが、誰がやっても、何回やっても、同じレベルの結果を出すことを保証するためであり、そのレベルで物を作らないと安定した供給ができないからということだと考えています。
詳細をわかっていない人が作り、詳細をわかっていない人が検証しても一定以上の水準の品質を達成できるようにすることが本質なのだと思っています。
工業製品の品質保証というものは、人への依存もなく、再現性と妥当性のある開発をしなければならないのであり、それを達成することがどれだけ困難なのかということはありますが、こちらにシフトできない会社はいずれ時代に取り残されてしまいます。特に日本的な考え方は個人の（犠牲の）上に成り立ってしまう傾向があるので、まずいのだと思います。
わからないからできないということは体制と状況が正しくないのだと思っております。
