・不具合が多い開発者は 開発をさせた結果、不具合の多い開発者と不具合の少ない開発者がいたとします。これは実力の差と言えばそうなります。 実力の通りの結果になる開発なら、それは開発者が野放しだったと言えるかもしれません。 ・実力のある人だけを集…

・ソフトウェアの品質が悪いとしたら 作った人がダメだと思うのは、間違いです。その理屈が通るなら、個人に損害賠償請求ができるはずです。工業製品であるなら、ソフトウェアの品質は組織の管理下になければおかしいです。 できないのはちゃんと作っていな…

・ワークフローを決めるときに誰が何をするのかを考える バグを見つけてから直すまでのワークフローをどう思い描くかで変わります。 登場人物が多くなるとルールの徹底が必要になりますし、難しさも増えていきます。 ツールの用意する標準的なワークフローは…

・売り上げのためにという理由はわかるけど テスターの立場から言えば、納期というのは、あくまで予定であってテストを通らないものを通すものではないのは当然です。 しかし、いろいろな制限の中でそれもできないまま、やらなければならないのはやるせない…

・年始から振り返ることになろうとは なぜなぜ分析しましたよ。 うまくいかない開発を振り返るのは重要なことではあると思います。 振り返ることは必要不可欠なんですが、個人的にはこれでは足りないという思いが強いです。 ・何も改まらないなら、時間の無…

・悪いと思えるならそれは改善の余地があるということで 何かを作る上で、生産性という言葉からは逃れられません。 効率よい開発をするのがベストですが、完全な開発はできないものです。 悪いと思えることがあるのに、流されてそのままの状態を続けているこ…