思い入れのある仕事というのは自分の中でいくつかあるのですが、特に思い入れが強かった仕事があり、その前置きとして「思い入れのある仕事 序章」を書きました。今回は本編として、実際にその仕事の内容について書いていきたいと思います。ここでの仕事は、細かくいうと、プロジェクト的には2つに跨っているのですが、ここでは細かく分けずに1つのプロジェクトとして扱って書いていきます。その仕事、プロジェクトは、当社として初めてのお客様（ユーザ企業）となりました。コンペになっていたようで、その見積もりや提案などはぼくは行っていませんでした。ただ、コンペに勝った一因として、ユーザ企業のキーマンとなる人に、以前に当社の別のチームと仕事をしたことがあり、そこでの当社の働きっぷりがよく、すごく信用できたので当社に決めた、ということがあったようです。続きをみる

＃本記事では実際の思い入れのある仕事の前段となる内容となっています。実際の思い入れのある仕事について知りたい方は本記事は読み飛ばしてください思い入れのある仕事というのは自分の中でいくつかあるのですが、特に思い入れが強かった仕事があります。今回、紹介するその仕事に携わったときは自分の中の転換期でもありました。現場から少し離れ、事業部門の技術推進を一手に行っていたころです。事業部門のラインが、特にテストにおける技術的な知見がそれほど強くなかったこともあり事業部におけるテスト技術の推進を背負ってやっていました。続きをみる

今、ある業務の関係でTPI NEXTを復習しています（参考文献：『TPI NEXT ビジネス主導のテストプロセス改善』、薮田和夫・湯本剛・皆川義孝 訳）そのキーエリアの説明で「再テスト」と「回帰テスト」という用語が出てくるのですが、文脈的に再テストが回帰テストっぽく思えたりしたこともあり、少し混乱してきたので改めて用語を整理してみました。参考文献のまえがきに「Sogetiのもうひとつの世界トップレベルのテスト手法である『TMap®』とも同期が可能である。（中略）TPI NEXTはテスト作業をISTQBに完全に整合させ」とあったので、まずはTMapとISTQBの用語をそれぞれ調べ、その後、自分なりの解釈からイメージを図示してみました。尚、TMap GlossaryとISTQB Glossaryでは「再テスト」と「確認テスト」、「回帰テスト」と「リグレッションテスト」の扱いが微妙に異なっていましたが、本記事では同等として扱います。「再テスト」については、TMap Glossaryでは、「再テスト」がメインで「確認テスト」が同義語として、ISTQBでは「確認テスト」がメインで、「再テスト」が同義語とされています。「回帰テスト」については、TMap Glossaryでは「Regression test」となっており、書籍上で「回帰テスト（regression test）」と訳されており、ISTQBでは「リグレッションテスト」となっており、「回帰テスト」という表現は見当たりませんでした。続きをみる

今期、長年勤められてきた当社の社長が社長職を降り、会長職となられました。社長（普段は社長とは呼ばずに一人の人としての尊敬を込めてお名前で呼んでいます。現在は会長となりますが、当時の思い出なのでここでは社長と表記します）は、ぼくが中部に異動になったころに就任されました。当時、ぼくは7年くらい勤務していた客先で、少しメンタルを壊してしまい、中部に異動したところでした。心機一転、中部で頑張ろうとしていたころ、当時はまだ社長になりたてか、なる前ぐらいで、ぼくが新しい取り組みを中部地区の全体会議で発表したときが最初に社長をお見かけしたと記憶しています。その発表で盛大な盛り上がりを見せた後、会議が終了し、会場から退出しようとしたときに一人の男性が微笑みながらぼくの方を見ている視線を感じました。その方が社長だったようです。続きをみる

はじめにここでは不具合やら故障、障害、エラーの用語を区別せずに「欠陥」で統一します続きをみる

はじめに6/21に開催されたJaSST'24 Kansai。すでに1ヶ月近くも経とうという時にようやく書き始めるという相変わらずの遅さなのですが、思い出しながらつづっていこうと思います。ぼくは今回、スポンサー枠でもなく、業務としてでもなく、自費で休みをとって参加しました。内容的に、今の業務に直結するわけではないと思ったのと、テスト会社として持ち帰れるものがそれほどないのではないかという推測からでした。あと、なんとなく業務として参加すると何らかの有益な情報を持ち帰らないといけないな、と個人的に思ってしまうというもあって、気楽に、自分自身のために参加しました。とはいえ参加する限りには自分自身で何をテーマに参加するのかは決めていて、今回で言うと「事業会社におけるQAはどういったことを考えられているのか、それはテスト会社の思考とどんなところが違っているのか」が見えればいいなと思い参加しました。続きをみる

はじめに１今回、本当に転職するつもりで、転職活動中に、これまでの現職での思い出がよみがえってくることがあったので転職活動の合間に書き溜めていました。しかし、最終的には現職に残ることを決意しました。ただ、せっかく書き溜めたというのと、転職か現職かで揺れている人に”退職しなかった人の意見”として少しでも参考になればと思い公開するに至りました。ぼく自身、本当にゆれにゆれました。今回の決断が良いものになるかどうかはこの先にならないとわかりませんが、良いものになるかどうかは自分次第ということもあると思います。あと、近いうちに実は転職している可能性もあるかもしれません笑続きをみる

お断り今回は軽い内容になっています。いつも軽いといえば軽いのですが、、、息抜き程度に読んでもらえるとうれしいです続きをみる

どんな内容？コンサルティングやプロジェクトマネジメントを中心に活動していた方が昔から夢であったプログラミングをやりたくて外資系の企業に入って、実際に海外の人たちと接する中で得た思考の違いの気づきをまとめた本です。続きをみる

先日、にしさんがお亡くなりになられました。にしさんのお世話になったので自分自身のために思い出を書き留めておこうと思います。とはいっても、にしさんはX（旧：Twitter）でぼくのフォローはしていないし、ぼくのことを覚えているかもわからない。なんて書くとにしさんに嫌われそう。なんかそういう人を嫌いそうなので。実際はどうだかわからないけど。続きをみる

はじめに管理って何？良い管理と悪い管理の違いって何？って聞かれたときに回答したことをメモ代わりに。何か改めて文献を探りながら書いていないのでその点はご容赦ください。続きをみる

はじめにここ最近、ちょこちょこと「『品質保証』と『品質管理』の違い」について話題に上がることがあったのですが、あまり自分自身の言葉で明確に説明できないなと感じたので自分なりの定義を作ろうと思いそれを記事にしてみました。ネットで調べてみると「品質保証は買い手視点、品質管理は作り手視点」のように書かれていることもありましたが、この定義が自分の中の定義といまいち合わなかったという背景もあります。ただ、ここでの定義はあくまでぼく自身が理解しやすいように、かつ説明しやすいように定義づけしているのでその正当性は保証していませんのでご注意ください。続きをみる

2:6:2の法則とはWikipediaで調べると「働きアリの法則」として書かれています。Wikipediaによるとパレートの法則（80:20の法則）の亜種らしく、「2:6:2の法則」とも呼ばれているものらしいです。続きをみる

はじめにテストプロジェクトの運営において、プロダクトの品質状況やテストの品質状況を測りたい場合があります。むしろ常に測りたい。その場合にメトリクスを使いたいのですが、その場合に、測定した結果がプロダクトの品質やテストの品質が良いかどうかを判断するための目安となるもの（これ以降はこれを便宜上「値」という表現をします）を次のいずれで表現するのかいいかを調査したのでそのメモを記載します。多分にぼくの解釈が入っていますし、自身が一番しっくりきた形で記載しており、必ず正しいとは限らないのでその点についてはご容赦ください。続きをみる

JSTQBで定義されている「事後条件」について、私自身の解釈が違っていたのでメモを。これまでの自分自身がテストをしてきた経験で、テスト実行したときには不具合が出ていなかったのに、テスト実行したその後の状態で不具合が発生することがままありました。例えば、複合的なテストにおいて、ある機能（A）とある機能（B）をぶつけるテストをしたときに、ぶつけたときはちゃんと優先順位が考慮されていて問題なかったんだけど、その後、ぶつけられたAの機能を動作させようとするとうまく動作しなかった、ということがありました。続きをみる

因子・水準とは因子・水準という言葉がテスト設計界隈で使われ始めたのはHAYST法からだと認識しています。HAYST法では実験計画法が使われていて、つまりは直交表を使うために因子・水準が使われていると認識しています（間違っていたらごめんなさい）。この因子・水準は実験計画法における何らかの要因となり得るものが「因子」でそれを測るための基準をもつものが「水準」であるといった意味で使われています。つまりは、因子に設定するものは何らかの要因になっている必要があって、水準はその要因を測る上での基準となっていなければならない、ということになります。続きをみる

テストタイプとテスト設計技法って同じように見えてしまうことがあるのでその違いについて明確にしてみました。私が自分で理解しやすい表現をしているので必ずしも正しいとは言えないかもしれませんが、その点はご了承ください。結論続きをみる

「これって接続性テスト？それとも互換性テスト？」と聞かれてちゃんとした違いについて即答できなかったのでこの機会に調べてみました。調べていくうちに「相互運用性」という用語も出てきたので合わせて調べています。※調べたのは「ｘｘテスト」ではなく「ｘｘ性」になります結論続きをみる

私の所属している会社では方針を掲げる資料（年間計画）に先期の成果と反省を書くことが多いようです。ただ、方針を掲げる資料に成果と反省を書くことにすごく違和感を覚えます。というのも自分自身が資料を作るときには成果と反省を書かないからです。で、何で違和感を感じるのかってのを考えてみました。1.一年単位で評価をしている続きをみる

テストマトリクス（どのマトリクスでもいいのですが、ここではわかりやすいように機能xテストタイプ（テスト観点）とします）は、私は個人的に使わないんですよね。ソフトウェアテストをやり始めた頃はマトリクスで作ると変な安心感があって使っていたのですが、やればやるほど使いづらくなってきました。なのでVSTepでいうNGTなどを好んで使うようになってきました。使いづらいと思うのは以下の点です。・交差する箇所を”並列で”1つずつ考えていくことになりしんどい・あらかじめ決められたこと以外の発想が出にくい・テストタイプによっては機能を跨ぐ必要が出てきたりして、その場合にマトリクスで表現しづらい続きをみる

仕事をやっていると少なからずトラブルが発生します。そんな時、風潮として「振り返り」をやることが多いです。振り返りといいつつも実態は反省会のようなもので、一応、なぜなぜ分析のような手法を使ってやっているようですが、その中身は全然、本質に迫れていないものが多いです。そもそもこのような形で何かしらの失敗に対して原因分析して今後のアクションにつなげていくようなことは効果があるのでしょうか。効果がないとは言えませんが、成功した事例から学ぶよりも効果が薄いように感じます。続きをみる

部門の教育担当の役割も担っている私が何らかの研修を企画するたびに「研修を受けても役に立たない」という発言があります。これ、そのいいっぷりから私は「研修には意味がない」と受け取っていたのですが、この発言の意図についてよくよく話を深掘りしていくとどうも「研修だけをやっても役に立たない」という意味だということがわかってきました。もちろん研修を受けた”だけ”では何の役にも立たなくて、研修で得た知識を実際に試してみて、そこで大抵はうまくいかないのでもう一度、知識を自分なりに理解し直して、また試して、と繰り返し使っていくうちに身につけていくものです。そういった意味で発言した内容はその通りではあります。（そして、一部分の人は研修を受ければその知識を得たと思っている人がいるっぽいです。だからこその発言だったようでもあります）続きをみる

著者著者はあの「知識ゼロから学ぶソフトウェアテスト」でお馴染みの高橋寿一さんです。ソフトウェアテストに携わっているほとんどの人は知っている方なのではないかと思います。この方はMicrosoft、SAP、ソニーというそれぞれPC、エンタープライズ、組み込み製品のドメインの中の大企業に勤められていました。そういった意味でも書いてある内容に説得力があると思います。単に私が権威に弱いだけなのかもしれませんがw続きをみる

著書名「洞察力」宮本慎也著続きをみる

ソフトウェアテストを行う上で、計画段階できちんと見積もりをして予実管理していくのはとても大切です。ただ、その見積りの正確性を問われても土台無理な話で。。。見積りの話題のときにある大学の先生から言われた言葉が今でもすごく印象に残っています。曰く、「見積りってのはいつも正しいんだよ。だって見積もった内容に合わせて行動していくんでしょ、結局。だから見積もりってのは意思表示なんだよ。このプロジェクトではこのように行動していきます、っていう意思表示」続きをみる