・ソフトウェアだから ソフトウェアだから、後から変更しても大丈夫と言われていた時代があったように思えます。 変更を許容するのかアジャイルの精神ではありますが、いい加減なものをつくるということではありません。 でも、変更を許容しつつ高い品質を維…

・仕様書が正しく書けているか わからないから、書けないわけですが、単純な話です。テスト仕様書以外なら、正確にテストで検証できる内容になっていれば構成要素としては正しいということになります。 ・構成要素って 何を書くかといえばその構成要素ですが…

・全部テストしたのか こういう言葉を掛けられることがあります。本当に全部テストしたら、ライフワークにしてやっても時間が足りませんという話になるかもしれません。 テストをすることは手段であって目的ではありません。ソフトウェアが品質目標を達成で…

・なぜ要求は難しいのか 一言でいえば、入力に関しての統制が一番効かないものだからです。 様々なステークホルダーが、それぞれの立場から、それぞれの考えで、要求してくる訳ですから、難しくない訳がありません。 ・善意のなせる業 要求というのは明示的…

・いいものができたとしても 品質のよいソフトウェアが出来たとしても、何のプロセスも守られておらず、ろくなエビデンスもなく偶然出来上がったのだとしたら、それどれだけの価値があるのでしょうか。 もう二度と、そのような品質で作ることは出来ないかも…

・入力は統制されてさえいないのに 要求のステークホルダーは多く、それぞれが完全な要求を提供してくれるわけではないので、それに完璧に応えるというのは厳しいと思えるのは筆者だけでしょうか。 不完全な入力にに対して完全な出力が求められるのはある意…

・ちゃんと失敗しよう 失敗を恐れ、途中でああでもない、こうでもないとやることを中途半端に変えてしまうのは前向きに見えて実際には、危ないやりとりになっていることが多いです。 やり切って失敗したほうが、その後のためにいいと思えることが多いような…

・統制された美 ここ最近、桜の木を見ると、その葉は紅く色づいて、紅葉の季節を感じさせてくれます。 春の桜（ここではソメイヨシノ）は、一斉に咲き誇ることで、統制の美学を思わせる美しさを見せてくれます。本当に鮮烈な記憶を残すいい仕事だと思います…

・正しい作り方 QMSは正しい作り方で物を作ることを求めています。ソフトウェアについても同じことが求められます。ゆえに、作る過程であってもきちんとした管理を求めています。 ・ソフトウェアは１回しか作らないけど 製造業でいう部品とか製品とか繰り返…

・品質の悪さを人に押し付けてはいけない 作り手の能力が低いから品質が悪いと結論付けるのは、ソフトウェアの中身を誰もチェックしないからと考えざるを得ないと、最近は考えています。 結局、ちゃんとできているか外からチェックする方法が、動作させての…

・講師をすると Teamsなどで講師をすると、ワンウェイの形になりがちで、何かを感じ取りながら進めるのは難しいと思います。実際に対面とは異なり、手ごたえも感じられず、ただしゃべっているだけのような感じで、どうなるのかなという感じで最後までやって…

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

・考えて作って確かめる 何を作っても、この３ステップは必ずあります。品質の良いソフトウェアは本当に緻密な積み上げの上にしか組みあがることはありません。 考えなければならないこと、気を付けなければならないことが、半端じゃないくらい多いのです。…

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

・教育でできること 欲しいのは「出来る人」や「教えられるレベルに達している人」だとします。 教育というのは、知識として与える工程であり、その結果は「聞いたことがある状況に達した人」か、うまくいけば「知っている人」でしょうか。 ・スキルはどうし…

・知っていないと とは思う SQubokを読むと、この技術は次から次へと書かれています。成果物は品質がマネジメントされた結果の成果物でなくては品質が保証されていないのと同じですから、マネジメントするためには種々の品質技術が必要となります。 読んでい…

・モノを作る（創造） 開発とはモノ作りに他なりません。そして工業製品として作られたモノは誰かを幸せにするのです。つまり、開発者である以上、その使う人の人生に影響を与えるのですから、いい加減なもの作って済ませるわけには行きません。しかし、本当…

・楽しくなければ どれほどのものが作れたとしても、そこに楽しみが存在しなければ、人の心は疲弊してそれを続けることが困難になります。 人は機械になることができないのだと思っています。 ・自分の楽しさは他人の楽しさとは違うかもしれない 自分の楽し…

・できたものを左右するのは 評価してみることで、出来上がったものがどの程度か把握することができます。検証とか検査とかいわれる工程が存在ることで、それを測ることができるわけです。 形のないソフトウェアを測るということは、とても難しいのですが、…

・「出来る人」になった人は、自分でなっている ソフトウェア開発における開発者自身の力量は、品質や納期を左右します。 中には「達人」と呼ばれる人がいて、納期も品質も見事にカバーしてしまったりします。 そして、間に合わなかったり、品質問題を出して…

・バグ曲線は好きみたいですが よく、バグ曲線を見せろというオーダーが来るのですが、一通りしかやっていないテストのバグ曲線を見て、枯れているかどうかわかることはありません。 残っている不具合の分布が全体に対して一様になる点は一巡だけでは始点と…

・洗練されたプロセスで開発をしてきた人は 非の打ちどころのない洗練された開発プロセスでソフトウェア開発を行ってきた人が、手弁当で何とか日々の仕事をこなしているような現場を見ると、プロセスが悪いと口にします。 間違いない指摘で正解であることは…

・変わりたくない いつもと同じように遅れる仕事とか、前と一緒といわれても、実は細部が異なったり、この範囲を指定しない「同じ」というのは、変わりたくないとか、変わっていることを認めたくないとか、同じでいることに安心している部分があるように思え…

・立場の違いから 開発部門と品証部門など、立ち位置の違いから、正義が食い違うことはよくあります。 立場が違うので、正しいを積み上げた結果、間違っていると指摘されていると思ってしまうと、味方という印象は薄くなりますよね、心情的に。 ・目指すもの…

・悪かった原因の羅列は大事 とにかく、何が悪くてこうなったのか並べてみるといろいろなことが挙がると思いますが、概ね自分たち以外の原因の物が多く上がるのではないかと思います。 自分たちに解決できないことを挙げて終わるのでは、言っても何も変わら…

・できるようになる人 できない言い訳を、自分以外に求めない人は伸びます。なぜなら、そういう人は反省して、改善を行うからです。 改善して実践して、また反省して改善策を出していく。そうして実力を伸ばしていくのです。 ・できない人は できない理由を…

・ソフトウェア開発をどう考えるか 出来上がればそれでいいなら、難しいことは必要ありません。できるまでやり続けるだけです。評価基準ができたかどうかだけなら、それでいいのです。 そういう価値基準しか与えず、出来上がったものに不具合があれば非難す…

・完璧に作れるならテストはいらない そもそも完璧に作ることはできません。なのでテストが必要です。それは当たり前な話です。 でも、だからと言って作り手がやってみないとわからないことを放り込んでいいことにはなりません。それをしたなら、きちんと確…

・不具合が少ないなら まあ、不具合が少ないから品質がいいと考えがちですが、たった一つでも致命的な不具合が引き起こす損失は計り知れないものがあります。 少ないほうが確率的には及ぼす損失も小さくなる計算にはなりますが、たった一発での逆転が起こり…

・コードを直すからコーディングミスって訳じゃない 確かに不具合が出れば概ねコードを直します。しかしその原因はコーディングミスとは限りません。もっと状況は複雑で混沌としているものです。 まず、要求から要件が定義され、設計が行われ、最終的にコー…