テスターのテストによる開発者のためのテスト

システム業界で思ったことをそのまま言葉にしよう

転職を振り返ってみる

こんばんは、なそです。

 

Twitterのタイムラインが転職、仕事辞めたいであふれかえっていたので、自分の時を思い出してみることにしました。

 

【転職迷い時期】

 もともと北海道でSIerでほぼベンダーとしてシステム開発をしていたので、一気通貫の仕事が多かったです。そのため、顧客とかかわることができる要件定義から保守運用まで担当できたのはとても仕事をする上での土台を作ることができていました。

 しかし、その中でどうしても開発の終盤からリリースまで荒れることが多く、いろんな人に迷惑をかけることがありました。

 このころから勉強会に参加するようになり、いろんな方から社外の状況を聞くようになっていきます。それと合わせてプロジェクトマネージャーの勉強に加えて、開発プロセスの勉強も進め始めました。

 

【転職決断】

 前職で炎上案件の渦中におり、うまいことマネジメントができない。開発も進まない。顧客との調整もしっくりこないという状況でした。(PMは別にいたんですが、ここでもうまいことコミュニケーションが取れていなかった気がします)

 PMとは別の案件でもチームを組んだことがあったのですが、顧客への価値提供の部分でぶつかることが多く、ここでも同じことを発生させてしまいました。

 そうこうしているうちに実践している開発プロセスに疑問を持つようになり、ほかの会社はどうやっているのか気になり始めました。また、品質の指針であるテスト計画書がコピペ製作だったため、品質に対しても気になり始めました。

 そんな中、ふとした気の迷いから登録した転職サイトから一通のスカウトが届きました。それが今の会社です。上記で気になっていた「品質」「検証」「いろいろな会社」というキーワードがヒットし、ダメ元で受けてみることに。

 

【転職まで】

 ダメ元で受けるといっても、いろいろとヒットする項目があったため数社から選ぶことはせずに1社受けてダメだったら、もうしばらく会社を続けることにしました。
(性格上、ふらふらと決めかねるくらいの時は実務も転職活動も何も身も入らないので)

 エントリーからすぐに1次面接のメールが届き、東京本社を希望していたためSkypeで面談となりました。(一人しかいない部屋の中でスーツを着て椅子に座っているのはシュールでした)

 その日は前歴、転職の理由、ちょっとした雑談をして終わりました。最初は緊張していましたが、話を進めていく中で緊張も程よく解けました。

 そのままあれよあれよと決まり、無事に転職することができました。意思決定の速さには本当に感謝しています。9月下旬から10月中旬くらいのスピード決定でした。

 

【転職後】

 さて、念願かなって品質を勉強できるとのことで、いろいろと飛び込ませてもらいました。そのおかげで今、悩みながらもテストを仕事にしてよかったと思えています。

 

なんだかんだでサクッと決まりましたが、いろんな人と話をしていくなかで感じたのは「転職の理由」が大きいのではないかと思いました。

私が自問自答したのは、3点だった気がします。

  • 会社の事業に共感できるか?
  • 業務の内容は理解できるか?
  • その業務を通じて何をしたいか?

 会社の事業に共感できて、業務内容が理解できて、得たいものが定義できなければ、ミスマッチが起きますので。。。相手もこの3点がミスマッチだと落としてくれるので、自分に合わなかったんだと納得もできます。

(多少の思い込みが入っても大丈夫だし、ぼんやりしててもいいと思います。そして、会社の全部を知るのは不可能です。漠然とでもよいのでここで働きたい。こういうことをしたいとイメージできるかどうかが鍵な気がします)

そして、これがしっかりしていると周りの人に止められることはないと思います。

(転職した人周りにいなかったし、誰にも相談しませんでした(笑) 社内では特に誰にも言ってません。一番仲が良かった先輩すら転職が決まった後に報告しました)

まぁ、ノリと勢いで転職しましたが、こうして言葉にしてみると何も考えずには転職はしていませんね(笑)
(スピード決定だったのですが、転職は3か月くらい待ってもらいました。わがままを聞いていただきありがとうございます)

 

自分はこうして東京で働くことになり、いろんな人出会うことができました。

転職や今の業務で悩んでいる人の少しでも助けになれば幸いです。

 

それでは、ノリと勢いを大切にする「なそ」がお送りしました♪

転職を振り返ってみる

こんばんは、なそです。

 

Twitterのタイムラインが転職、仕事辞めたいであふれかえっていたので、自分の時を思い出してみることにしました。

 

【転職迷い時期】

 もともと北海道でSIerでほぼベンダーとしてシステム開発をしていたので、一気通貫の仕事が多かったです。そのため、顧客とかかわることができる要件定義から保守運用まで担当できたのはとても仕事をする上での土台を作ることができていました。

 しかし、その中でどうしても開発の終盤からリリースまで荒れることが多く、いろんな人に迷惑をかけることがありました。

 このころから勉強会に参加するようになり、いろんな方から社外の状況を聞くようになっていきます。それと合わせてプロジェクトマネージャーの勉強に加えて、開発プロセスの勉強も進め始めました。

 

【転職決断】

 前職で炎上案件の渦中におり、うまいことマネジメントができない。開発も進まない。顧客との調整もしっくりこないという状況でした。(PMは別にいたんですが、ここでもうまいことコミュニケーションが取れていなかった気がします)

 PMとは別の案件でもチームを組んだことがあったのですが、顧客への価値提供の部分でぶつかることが多く、ここでも同じことを発生させてしまいました。

 そうこうしているうちに実践している開発プロセスに疑問を持つようになり、ほかの会社はどうやっているのか気になり始めました。また、品質の指針であるテスト計画書がコピペ製作だったため、品質に対しても気になり始めました。

 そんな中、ふとした気の迷いから登録した転職サイトから一通のスカウトが届きました。それが今の会社です。上記で気になっていた「品質」「検証」「いろいろな会社」というキーワードがヒットし、ダメ元で受けてみることに。

 

【転職まで】

 ダメ元で受けるといっても、いろいろとヒットする項目があったため数社から選ぶことはせずに1社受けてダメだったら、もうしばらく会社を続けることにしました。
(性格上、ふらふらと決めかねるくらいの時は実務も転職活動も何も身も入らないので)

 エントリーからすぐに1次面接のメールが届き、東京本社を希望していたためSkypeで面談となりました。(一人しかいない部屋の中でスーツを着て椅子に座っているのはシュールでした)

 その日は前歴、転職の理由、ちょっとした雑談をして終わりました。最初は緊張していましたが、話を進めていく中で緊張も程よく解けました。

 そのままあれよあれよと決まり、無事に転職することができました。意思決定の速さには本当に感謝しています。9月下旬から10月中旬くらいのスピード決定でした。

 

【転職後】

 さて、念願かなって品質を勉強できるとのことで、いろいろと飛び込ませてもらいました。そのおかげで今、悩みながらもテストを仕事にしてよかったと思えています。

 

なんだかんだでサクッと決まりましたが、いろんな人と話をしていくなかで感じたのは「転職の理由」が大きいのではないかと思いました。

私が自問自答したのは、3点だった気がします。

  • 会社の事業に共感できるか?
  • 業務の内容は理解できるか?
  • その業務を通じて何をしたいか?

 会社の事業に共感できて、業務内容が理解できて、得たいものが定義できなければ、ミスマッチが起きますので。。。相手もこの3点がミスマッチだと落としてくれるので、自分に合わなかったんだと納得もできます。

(多少の思い込みが入っても大丈夫だし、ぼんやりしててもいいと思います。そして、会社の全部を知るのは不可能です。漠然とでもよいのでここで働きたい。こういうことをしたいとイメージできるかどうかが鍵な気がします)

そして、これがしっかりしていると周りの人に止められることはないと思います。

(転職した人周りにいなかったし、誰にも相談しませんでした(笑) 社内では特に誰にも言ってません。一番仲が良かった先輩すら転職が決まった後に報告しました)

まぁ、ノリと勢いで転職しましたが、こうして言葉にしてみると何も考えずには転職はしていませんね(笑)
(スピード決定だったのですが、転職は3か月くらい待ってもらいました。わがままを聞いていただきありがとうございます)

 

自分はこうして東京で働くことになり、いろんな人出会うことができました。

転職や今の業務で悩んでいる人の少しでも助けになれば幸いです。

 

それでは、ノリと勢いを大切にする「なそ」がお送りしました♪

4か月ペアテストをやって思ったこと

どうも「なそ」です!
みんなアウトプットしてますか?

 

どうも最近の忙しさから勉強会になかなか参加できなくてアウトプットできていない気がする今日この頃です。

さて、今回のお題は「ペアテスト」についてです。

 

ペアテストについては何度かテストラジオでも話をしています。

ja.twitcasting.tv

ja.twitcasting.tv

twitcasting.tv

なぜペアテストの話題を取り上げるかというと、4か月にわたって実施してきてた案件が8月末で終了しました。 

www.slideshare.net

 

ついでにWACATEでチームの話をしたので、その時のスライドです。いい機会なので棚卸を含めてここで実験結果報告を行うと思います。

 

1.きっかけ

ペアテストとの出会いは、4月に開催された「Agile Japan」で、和田さんから「アジャイル魂2015」をいただいたことがきっかけです。

和田さん本当にありがとうございます!!

その中で、ペアプログラミングについて書かれている記事を読みこれはテストにも応用できるのではと現在のプロジェクトで実施してみました!

アジャイルの魂 2015より抜粋

誤解されているのは、作業内容に関することです。プログラミングとは設計・コード作成・テストを全て含む創造的な作業を示しますが、詳細設計工程とテスト工程の間にある「PG工程」を2人で作業すると誤解している人が多く、ペアプロの理解を大きく阻害していると感じています。

 

創造的な作業ということはテスト設計にも当てはまる。ただし、テストエンジニアには「ペアプログラミング」は用語的に合わないので「ペアテスト」と置き換えてプロジェクトメンバーには説明しました。

 

また、プロジェクトのアサインの状況的にも実践しやすい環境が整っていました。1チームに2名のテスターずつ、3チームありました。私が参画した時点でペアが出来上がっていた。かつ、アジャイル開発を行っていたので、スプリントの開始時にはテスト実行できるものがない!!そのため、実行者にも教育を兼ねてテスト設計をしてもらうことになっていました。

どうせやるなら効率的にやりたい!!

ということで、メンバーと一緒にいろいろやってみることにしました。しかし、業務で成果をあげないといけないため、下記の制約をつけました。

制約①:ペアにしたのは、下記のスキルを持っている人達です。

  • テスト設計をしたことがない(普段の業務はテスト実行がメイン)
  • テスト設計・テスト実行はお手の物

制約②:ペアを組み替えたいけど、変えたことによる作業効率低下が怖いため、組み替えはあまり実施していない。(あまりということなので、0ではないです。組み替えは何度か発生しています)

制約③:ドライバー、オペレーターの交代は難しいため、各々のタスクを交互にレビューすることで役割を補う。

 

2.ペアテストの狙い

私はペアテストで狙いは

  1. テスト設計者はテスト実行者に説明することで、自身の設計スキルを見直す。
  2. テスト実行者はテスト設計者が何を考えて設計をしているか勘所を感じる
  3. お互いにコミュニケーションを取ることで仕事の進め方をブラシュアップ

でした。

チームメンバーにはこの意図を伝えた上で実践し、一人のテスト設計者に全てを任せる訳ではなく、チーム全体で解決していきました。

片方のペアが忙しいときは私が変わりに対応したり、別の人にお願いしたりと臨機応変に対応していきました。

ただ、手放しに良かったといえるかというといくつかの改善点ややらなきゃいけないことなどはありました。(業務をやりながらのチャレンジだったため、問題解決のための時間はあまり多くなかったです)

簡単ですが、振り返ってみます。

 

3.良かった点

  • テスト実行者の設計力が上がった!
  • テスト分析、テスト設計のフェーズを明確にしたことで手戻りが工数が減った
  • 勉強会を企画して、違う人とペアを組んでもらってテスト設計をした

 

 実行者の設計力は目を見張るものでした。参画当初は右も左もわからない。テスト設計ってどうすればいいんですか?という質問しかできなかったが、見様見真似でもテスト分析やテスト設計を作ってくるようになった。もちろん、知見が足りないのは重々に承知していることなので、そこはレビューや声かけのタイミングで補うようにしました。簡単な機能であれば、テストケースを独力で作成できるようになりました。

 また、工夫した点としては、テスト分析とテスト設計のフェーズを分けたことです。基本的にテスト設計者は慌ただしく、声をかけづらい雰囲気だったこともあり実行者が気を使って(本来その気遣いは逆効果だけど、こちらもキャッチアップできる雰囲気を出せなかったのはあるのでお互いの反省点)テスト分析のレビュー完了前にテスト設計に入ることが何度かありました。そのせいで、テストケースに漏れや大きな手戻りがありました。

 最後の勉強会はなかなか時間を作れなかったので、数回しか実施できていなかったですが、いつもと違う人と組んでもらいテスト設計の演習問題をやってもらいました。また、プログラムの挙動について、ゆもつよメソッドの「論理的機能構造」を使って説明をしたりといろいろな情報をメンバーに共有していきました。

 

4.改善点

  • 実行者のフォローに時間がかかり、設計者の作業に遅延が発生することがあった。
  • 実行者から設計者へのアクションが見えづらくOJTに近くなっていた
  • レビューチェックリストやテスト観点を用意しておく
  • 勉強会の課題のボリュームが大きすぎた

 フォローをするための時間は確かに必要です。しかし、それが大きくなってしまうと相手の負担になってしまい、それが明らかになってくると自分が負担になっているのではないかと思い始めることになります。この辺のフォローは難しいですね。

 実行者から設計者や私への要望は少なく、話を聞いてみるとテスト設計にいっぱいいっぱいになってしまってそれ以上のことを考えられないとのことでした。この辺は改善しなくちゃいけないですね。自分がどれだけレベルアップしているのかが見えないためにどうなっているかの変化を捉えられないってことですもんね。

 あらかじめ、こういうところに気をつけてなどの観点を用意しておいてあげれば第一歩としてわかりやすかったのかな・・・

 また、勉強会の課題の規模が大き過ぎてみんなダレてしまう結果になったのは残念でした。せいぜい2時間くらいのボリュームを考えておかないといけませんね。 

 

5.次やるときに

当初の狙いである2番目は十分に達成できた。

しかし、1番目が不十分で、設計者の教育も必要なのが分かった。

例えば、現場では以下のようなことがチラホラありました。

  • 1時間近く説明をしているが、伝わっていない
  • 途中で説明をあきらめてキーボードを奪う
  • 設計者が忙しくて、レビューがリアルタイムにできない
  • レベルアップのチャンス

 要点を絞った説明ができない、相手に考えさせる、タスク整理や時間の使い方がうまくできていない等の設計スキル以外の部分がネックになることが多かったです。開発者に求められるのは幅広い知識や経験が必要ですが、土台にはこういったスキルが必要になることが改めて実感しました。

 相手のわからないことを組み取ったうえで、説明しようとするわがメンバーの理解力には尊敬します。私は全部を説明せずに、少しだけ説明して後はやってみな!ただし、わからなかったらすぐに質問すること!を徹底していたので、そんなに時間を使っていないかったです。

  なんだかんだで、どれだけ説明したとしても本人にやる気がない場合はどうしようもないのだなというのを強く感じました。自分のやったことのない範囲をやるわけなのでいろんな感情を持つと思います。飛び込んで欲しくても飛び込めない場合は残念な結果になります。もっと飛び込んでも大丈夫という空気を作ってあげれなかったのは大きな反省点でした。

 

6.次なるペアテストの現場を求めて

 現状テストエンジニアが不足してます。では、どうやって仲間を増やかのかを考えた時、一つの教育の形としてペアテストがあると思います。今後も続けて行きたいと思います!

テストエンジニアが増えてきた時にはモブテストとかもやってみたいです♪

 

それでは、今回はペアテストの結果レポートをお届けしました!

 

 

 

 

 

 

 

 

 

 

 

 

テストラジオってなんだろう?

書くときはすぐに連チャンで書いてしまう「なそ」です。

 

お久しぶりです!

さてはて、前回のブログでもちょろっと話をした「テストラジオ」について、今回は話をしようと思います。

 

テストラジオはひょんなことから始まりましたが、初放送は2017年2月5日です。

twitcasting.tv

私こと「なそ」と東海を中心に活動している「オカウチワニ」さんがソフトウェアテストの話を行うという至極単純ですが、とてもニッチなラジオをツイキャス上で放送しています。現時点でテストラジオは19回目を放送したところです。一覧はこちらです。

twitcasting.tv

 

ツイキャスのサービス自体はリアルタイムを軸にしていますが、テストラジオは収録したものを編集して、流しています。なので、リアルタイムではありません。コメントには返事できるんですが、番組内では拾うことができないです ToT

初期の段階は録音装置も機材もなく、二人で手探りをしながら放送をしています。

この記事を書くにあたって、第1回とか聞き直してますが楽しいもんですね(笑)

 

内容に関しては、お互いが興味のある分野について話をすることが多く、特に参加した勉強会の内容を振り返ることが多いです。

そんな中ゲストに来てもらったりまったりのんびりと行っています。

ゲスト出演回

twitcasting.tv

twitcasting.tv

第1回からゲストを呼んでいます。そのあとしばらく間が空いています。

 

放送は大体1週間に一回土日を中心に行っています。最近は日曜の19時付近に放送し、テスト界隈のサザエさんと化しています(笑)

 

「オカウチワニ」さんがラジオ内で深掘りや話を広げてくれるため、「なそ」はすごく助けられています。そして、ふんふんと聞いていることがたまにあります。編集中に「オカウチワニ」さんの声だけで良くない?と思った回もあります。その回がこちら!

twitcasting.tv

 

色々とやっていますが、少しずつ進化しているはずです。

これからも配信していくので、よろしくお願いします!

 

その中で、テストラジオのパーソナリティのネットワークを活かして宣伝活動を行ったりしています。ここ最近ではJaSST東北やJaSST関西の宣伝を行っています。

 

そういえば、JaSST関西は6月23日(金)ですね!

JaSSTソフトウェアテストシンポジウム-JaSST'17 Kansai 開催要項

私も行きますが、実に楽しみです。

人工知能とかワクワクします♪

 

配信方法とかも工夫しているので、その辺も話ができれば良いかなぁ?

聞きたい人いるのかな?(笑)

 

それでは(*・ω・)ノ

 

 

WACATE 参加レポート BPPセッションして来た

2017年6月17日〜18日にWACATE 2017 夏が開催されました。

 

お久しぶりです。なそです。

最近は、「テストラジオ」などの活動でめっきり文章を書いてない。

声の発信をしていると文章は書かないけど、話の進め方とかが重要になってくる。

これって、文字にするか、声にするかの違いなのでどっちにも共通する必要なスキルってことになりますね。

 

今回はWACATEの参加レポートの中でもとてもニッチです!! 

 

さて、WACATEとは、テストエンジニアが集まる年2回のワークショップです。

1泊2日で行われるので、2日間ずっとテストに浸かりながらスキルを高めて行くことができます。

WACATEには、面白い制度があって中の人がセッションをしてくれるのですが、その中の2セッションは、外部の人が行います。

1つはテストで有名な方のセッション。もう一つは前回のWACATEの中から選ばれた1名(ベストポジションペーパー賞)のセッション。

 

で、私は今回後者の方でセッションを行って来ました。

どうやって、その1名が選ばれるかというと……

ポジションペーパー」と呼ばれる1枚の紙を参加者が申込時に提出します。参加者が約60名いるので、参加者の投票でその1名を決定します。

ポジションペーパーとは、決意表明や悩み、思っていることなどのWACATEでどうしたいかを記載した紙です。参加者、実行委員の全員が書くので、それが名刺がわりでありお互いを認識するものになります。

 

そして、前回選ばれた私はBPPセッションを行うことになりました。

前回のWACATEが2016年12月。半年の間に自分が話したいことを中心としたセッションを作成せねばなりません。超悩みました。

前回のWACATEでBPPセッションをしてくれた人が凄すぎて自分に同じようなことができるかどうかが全く想像できないのです。

 

自分の武器や得意なこと、何ができるのかがわからない中で、何か吐き出せるものがあるかと悶々とする日々でした。

4月をすぎても良い内容が浮かばなかったのですが、悶々とする中自分がやりたかったことや夢、困ったこと、やってみたいことが洗い出せて行きました。

そして、4月中旬にプロジェクトが変わってチームリーダーになったことで、今回のテーマ「良いチームを作ろう!!」を思いつきした。

せっかくチームを率いるなら楽しく、成長を感じつつ仕事をしたい。してもらいたいと思ってチーム運営をしていたので、それを吐き出そうと。

悶々としていた気持ちがすっきりすると同時に次は、何をどうやって話そうというところで躓きました。

 

そういやこういう発表したことないや(笑)

あ、テスコンで発表したけど、チームの内容だったからね。

 

また悶々とする日々です。

それでも、タイトルを決めて何をしているか、何をしたいか、何を話したいかをメモし続けました。

 

そして、2週間前の土日?に勢いよくパワーポイントで書きなぐりました。

その枚数、約100枚。

前回の受賞者からのアドバイス

  • 下の方に書くと後ろの人が見えないよ
  • フォントが28くらいでも厳しいかも

と教えていただいていたので、枚数を増やして文字を大きくしました。

また、コメント的なことを右上と左下に入れて、本音っぽいことをコメントするようにしてみました。

あとはアニメーションは使いませんでした。当日にアニメーションでトラブルになっても嫌なので使用していません。

 

何人かにレビューを依頼して言われたのが

  • 言いたいことは10個あったら1個か2個の方が良い
  • トピックスが4個かあるけど、そのトピックスと内容が一致していない
  • 各トピックごとにまとめが欲しい
  • 枚数が多い
  • 笑いが必要(内容が固すぎる)

 

色々指摘受けて、言いたいことを減らすと残ったことで深掘りしてページが増えるを2,3回繰り返した結果、100ページにギリギリ届かない枚数となりました。

 

構成としては

  1. オープニング
  2. 導入
  3. タイトル
  4. 実践内容
  5. まとめ

としました。

いつものテストラジオのような構成ですね。

タイトルが3分の1くらいにならないと出てこない異色のプレゼンになりました。

 

この資料の枚数を見た実行委員の良き計らいで5分延長可能な状態になりましたが、25分で話し終わるという駆け足で進み10分くらい質疑応答に使うことができました。

本当にありがとうございましたm(_ _)m

テストラジオも25分くらいだから、その雰囲気で話しちゃったのかな?

 

緊張するタイプなので、前日は気合いを入れるために「すた丼」を食べて、当日は「テストチョットデキル」Tシャツ(miwa719 の【チョットデキル No.1】Tシャツ ∞ SUZURI(スズリ))を着て、テストラジオパーカーを羽織り本番に臨みました。

 

あくまでも、ワークの前座なので楽しんでもらえたらいいなあと思いつつ、こんなリーダーになりたい、私だったらこういうリーダーになりたいとか思っていただければ幸いです。

 

途中で、飲み忘れていたレッドブル飲んだりして、セッションとしてどうかなぁと思いつつ楽しく話をさせてもらいました。

 

つぎのベストポジションペーパー賞の発表を楽しみにしつつ、今回も終わろうと思います!

 

WACATEの内容については、別日に書きます。書く予定です(笑)

 きっと書きます!

 

それでは(*・ω・)ノ

 

勉強×教育×努力

こんにちは!なそです。

 

JSTQBからは一旦脱線します。

今回のテーマは「教育」です。 

教え育てることであり、ある人間を望ましい状態にさせるために、の両面に、意図的に働きかけることである。教育を受ける人の知識を増やしたり、技能を身につけさせたり、人間性を養ったりしつつ、その人が持つ能力を引き出そうとすることである。    

wikipedia「教育」より引用

このテーマについて徒然っと書いていきたいと思います。お付き合いいただければ嬉しい限りです。賛否両論あるので、議論してみたいですね。

 

さて、まずは私の持論としては「できない人は絶対にいない」ということを最初に伝えておきます。会社で「こいつ使えねぇなぁ」っていうのを聞くと、その組織の教育に対する姿勢を疑います。

しかし、費用対効果を考えなければ社会人ではないでしょう。諦めるという選択肢が存在することは私も認識しています。これは本当に苦渋の選択で、自分の力不足を本当に恨みます。

 

 私はできない人は絶対にいないといいますが、その人のレベルから要求するレベルに上がってもらうのは並大抵の努力ではありません。一緒に努力する必要があります。教育方針の決定は、その人の人生を左右する事になります。途中で「あ、ごめん。教育方針間違えたわ」なんて絶対に言えません。今回は教育者目線(上司から部下)で話を展開します。(いつか逆の目線で書きたい)

 

そして、教育対象の人は下記の4タイプに別れると思っています。

  1. 進みたい方向が決まっていて、会社の方向と一致している。
  2. 進みたい方向が決まっているが、会社の方向と一致していない。
  3. 進みたい方向は決まっていないが、会社の方向は許容できない。
  4. 進みたい方向が決まっていなくて、成り行きに任せている。

1.進みたい方向が決まっていて、会社の方向と一致している。

 面談時にこんな人に出会ったときに私達が考えないといけないのは、本当に認識がズレていないかと思わなければ行けません。こういう人は会社の方向を理解し、合わせてくれている可能性を十分に含みます。そして、理解が早いのでサクサクと面談が進むので楽です。しかし、本心を聞き出すことを忘れないでください。

ある日、辞表を突然出されるということが起こるかもしれません Σ(゚Д゚)

2.進みたい方向が決まっているが、会社の方向と一致していない。

 これは結構難しい問題にぶち当たったと思ってください。簡単な例では、新人がこれに当たることが多いと思います。夢を持って入社するわけですので、事前に聞いていた状況と現状のギャップに悩むことは当然といえます。こういう人は「急がば回れ」という事を理解して貰う必要があります。ホップ・ステップ・ジャンプです。基本になる知識や経験がなければ次に進むことができず、最後の大きなジャンプをすることができません。

自分の現状の場所と最終的に居たい場所を描き、どういう道で進むかを複数示してあげてください。モチベーションが高いので、進むべき道をしっかりと作ったときの成長は早いと思います。

 

3.進みたい方向は決まっていないが、会社の方向は許容できない。

 なんて、めんどくさい事になっているんだか、どうしてこんな人がいるのかあなたは自分の心に聞いてください。この状態は5年目以上の人に多く、会社の現実に夢砕かれてもういいやって投げやりになっている可能性が高いです。相手も人間なので考える事ができます。なにが不満か全力で聞き出してください。教育はその後です。枯れかかっている心に優しく水と肥料を与える気持ちで接してください。こういう言い方をすると腫れ物を扱うように接する人も居ますが、それは違います。その人の心にぶつかるので、あなたも本心でぶつかってください。少しずつ新人の頃の気持ちを思い出し進みたい方向を思い出すかもしれません。そこで会社の方向が許容できない部分も出てくるでしょう。あなたのすることはその人の間違っている所をしっかりと論理的に指摘して気がついてもらう事です。そして、会社がおかしい場合はそれを改善するアクションをとるべきです。

 これを読んでいる人はそんなことできるわけないだろうと思うかもしれませんが、この改善のアクションは誰のためでしょう?会社のため、ひいてはあなたのためです。「情けは人のためらならず」です。きちんとググって意味調べてくださいねw

 

4.進みたい方向が決まっていなくて、成り行きに任せている。

 一番の困ったさんですが、3に近い感じがします。こういう人は「自分で考えてくれないんだよな」って言う印象が着きやすいです。なぜ自分で考えないんでしょうか?本当に考えてないんでしょうか?普段の業務中にあなたが頭ごなしに否定していませんか?

 そんなことないよ。と思った人にはもう一度聞きます。「頭ごなしに否定していませんか?」無意識のうちにその人を追い込んでいませんか?一度周りの同僚にその人と自分の関係性をどう見えるか聞いて振り返ってください。たいていの場合、相手の意見を潰し、自分の意見を押し付けています。すぐに素晴らしい考え方が身につくわけじゃありません。しかし、繰り返すことで脳は確実に進化します。それを忘れないでください。あなただって生まれたときから言葉を発したわけじゃないでしょうw

 

最後に

言いたいことを言いましたが、もう一つ言いたいことがあります。

社会人なんだから仕事のプロになる努力をしようよ!!

たまになんでそんなに勉強するの?って言われますが、私は勉強会に参加するのも、社外の人と情報交換するのも、本を呼んで勉強するのも「今の仕事に自信がないから」です。他の人より持っている情報が多い部分もあるでしょうが、周りの人はもっとすごいです。毎日の業務を仕切るので必死なら、少しでも簡単になる工夫をしようよ!!

と思ってます。他の人に丸投げとか片っ端から断るのもいいですが、今のプロジェクトが終わったときにあなたは必要とされる人であり続けることが出来ますか?っていう話です。

自分に価値をつけて行く努力はするべきではないかと思います。

 

今回は「教育?」についてでした。

次回はJSTQBに戻るかな?

それとも、とある勉強会で話題に上がった話を纏めるかもしれません。

 

それでは、なそがお送りしました!!

ソフトウェアの欠陥ってなんだろう?

こんにちは!なそです。

 

1週間ぶりです。

 

12月は寒い日が続くと思ってましたが、どちらかというと11月の方が寒かった気がする今日この頃です。しかし、油断すると崩れそうなので、皆さんも体調を崩さないように気をつけてくださいね。

 

さて、前回に引き続き、JSTQBを読み進めて行きましょう。

 

ところで、「ソフトウェアの欠陥」って何を示すんでしょうか? ひとえに欠陥といっても、自分の思った通りに動かない。エラーが発生する。設計書通りに動かない……等々とあると思います。その原因をよく考えないと修正時に間違った方向に行ってしまう可能性もあります。

 

それに自分がどういう欠陥を発見したのかを説明するときにうまく説明できますか?一括りに障害やバグ(以降「障害」に統一します)という言葉で片付けてしまうこともあると思います。

しかし、その障害がどういった要因によるものかを分類することも必要です。

その「ソフトウェアの欠陥」の分類はJSTQBでは以下で定義しています。

 

  • エラー
  • フォールト 
  • 故障

 

エラーは「間違った結果を生み出す人間の行為」3×2と入力した時に5と結果が返されると、これは欠陥ですね。掛け算と足し算を間違えている可能性大です。この間違えた行為がエラーです。

フォールトは「要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシステムの中の不備」先ほどの例で言うならば、3×2と入力した時に5と結果が返されるという事象がフォールトです。

故障は「コンポーネントやシステムが、期待した機能、サービス、結果を提供できないこと」

3×2と入力した時に5と結果が返されるということはシステムとして、計算をするという機能を提供できなくなります。この事象が故障です。

これはプログラムのエラーでもそうですが、ハードウェアを含めています。カラオケに行って、マイクが全て使えない状態になっていたら、サービスが提供できません。これも故障ですよね。

 

そして、それらの管理はインシデントと言い、意味は「発生した事象の中で、調査が必要なもの」となっています。

ただし、インシデント ≠ 故障ということだけ覚えたおいてください。テスターのオペミスということもあります。実は×だと思ったんだけど+を押していた。マイクの電源を入れ忘れた。マイクの充電が切れていたとか考えつくので、発見した事象を調査してもらい、故障かどうかを確認していくためにインシデントを発行します。

 

最近だとチケットという名前で浸透していると思います。ひと昔(今もやってると思いますが)エクセルでインシデントを管理していた時の分かりにくさったらありゃしません。個票と一覧表を用意して、それぞれの同期は手動なんて時代もありましたね。そう考えるとシステム化しただけで当時からやりたいことは変わってないですね(笑)

 

さて、インシデントにどういう情報があれば良いか等JSTQBでも定義されています。今から説明し始めるとさらに長くなってしまうので、今回はここで終わろうと思います。

 

今回は「ソフトウェアの欠陥」について考えてみました!

 

次回は「インシデントってどうすれば良いの?」と考えてみましょう♪