・品質問題をテストだけに押し付けてはいけないが 品質が悪いという話になるとテストを強化しなければという話になることが多いと個人的には感じています。 間違いではないが、不具合が多いのであれば、原因分析をしないとその対策は効率の良いものにはなら…

・変えようとする側の理屈 傍から見て、間違っていたり、非効率だったりすることを改めるように指示したり、提案したりすることはよくあると思います。どう考えても自分は正しいと感じているので、どうしても駄目なことを許容できなくなってしまったりします…

・人に依存するのではなく まず、属人性の高い組織は、その人を失うと品質が保てなくなります。 見えないから誰がやってもやっても同じに見えるようなスポンサーから有能な人材が逃げるのは当然です。 人がダメだと言いながら有効な手が打てず、同じ状況を繰…

・うまくいかないから #問題解決 をしたいなら、測ることが最初に必要だと考えています。１手目で成功してしまうより、改善を積み上げた末の成功のほうが人が得た経験値が多くなるからです。しかし、それだと初回は失敗を前提としているように思われてしまい…

・問題は認識したら即解決が吉 開発途中で問題に遭遇したら、即解決が断然効果的です。 いつもそんなにうまくいかないとか、自分では解決できないとか考えずに、「悪、即、斬」が理想的だと、個人的には思っています。 ・ふりかえりの問題は熱量差 ふりかえ…

・実力を定量評価しづらい ソフトウェアエンジニアの実力は、見ていればできる/できないについては感じられるものです。しかし、それを定量評価するのは難しいかもしれません。 ある一定以上のラインはわかると思うのですが、それ以上は難しいかもしれません…

・手離れの良さ 速く終わっても、手離れが悪ければ、トータルでの時間としては掛かってしまうことになります。 しかし、仕事が速い人の仕事は手離れも良いようで、速さと品質の双方を満たしているように見えます。 ・合理的に時間をかける 結局、手戻りして…

・教育が目的？ まず、教育はするためにするものではないと考えています。 特にソフトウェアの教育の成果は量ることが難しく、単に受けた数とか、受講後の感想などが評価になってしまうようなことがあったりするのではないかと思います。 教育をすることが目…

・いつも通りの罠 停滞が後退であるなら、いつも通りというのは危険です。 疑うことはみっともないかもしれませんが、定期的に実施しておかないと手遅れになってしまうかもしれません。 ・プロセスを通しで考えたときに いつものようにやっていても、部分最…

・開発者の役割 できないことを出来るに変える。技術者として挑みたいものではありますが、量産の開発でこれをしてはいけないことになっています。宇宙に飛ばすロケットが、できるかどうかわからないものを本番には使わないように、量産の開発は確立された技…

・不十分さは確認できない 何が怖いか、自分の分かったと思う範囲が、完全に対象を網羅できているかは確認ができないからです。知らないことを知らなければ、自分だけでそれを解決することは不可能です。 わかるの問題とおなじことで、分かったのはあくまで…

・都合のいい部分だけを切り出していないか ドキュメントを書けてないから、アジャイルが向いている。こんな短絡的な思想は危険でしかないと思っています。 仕様が決まらないから、アジャイルがいい。こんな思想も危険だと思っています。 都合のいい部分しか…

・改善を行う際に 必ずいるのは反対派で、いて当たり前です。全員が同じ方を一斉に向くようなら、その方が組織として健全ではないと思わざるを得ません。 で、よく言い訳に使われるのは「忙しい」です。 忙しいのは特別なのかと言えば、常態化しているなら、…

あけましておめでとうございます。 ・ダメなことの指摘は簡単 まあ、本当に指摘するだけなら簡単ではありますが、解決までがセットでなければ、指摘した時間が無駄になるわけですので、直すべきなら直ることまで面倒を見ないと、指摘するべきではないと考え…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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