社内発表会の話

弊社で年2回行われてる改善提案発表会で、一等賞を貰ったという話です。

内容は
「TOCfEを開発改善に使いましたよ」改め
「TOCfEの勉強会をグループと新人研修で行なったら、得られた気づきがありましたよ」について。
20分の尺の中で、どうやったら「TOCfEが効果的なツールである」と伝わるか考えて、「開発改善の事例」は、ほぼカットした感じ

内容としては、

  1. TOCfEの紹介(と改善事例を少々)
  2. 勉強会の実施と気づき(公開している内容)

を話しました。
ほんのりエニアグラムの知見が見え隠れする内容になっております( ̄ー ̄)

www.slideshare.net

業務改善のためのツール作成の発表が多い中、思考プロセスとその勉強会を話すのは、弊社の発表会ではかなり特殊になります。

「もしTOCfEを社内で広めたら、業務や職場が変わるだろうか?」と思ったので、ちょっとチャレンジしてみました。まぁ、毎回同じようなネタで飽きてたというのもあるw

ちなみに、公開しているスライドにはないですが、各TOCfEのツールは次のように紹介しました(実は発表スライド作成の大半の時間を費やしていますw

  • ブランチ・・・「割り込みが多いから、作業が計画通りに進まない」の因果関係を明らかにして変える & 実際の開発での改善例
  • クラウド・・・「悪いところを直接メンバーに指摘する」vs「悪いところがあっても指摘しない」(共通目標:チームがよりよく活動する)
  • アンビシャスターゲットツリー・・・「TOCfEを社内に浸透させる」を達成する

TOCfEの紹介に時間を割いた割に、グランドルールに食いつきが良かったです。
勉強会の方針は某bootcampを参考にしていますが、社内では「全員が認識してるけど、対策しようのない課題」だったのだろうと感じました。
グランドルールは、社長から直接「これは良い、今度会議でやってみたい」というお言葉をいただきました^_^

新しい社外監査役から「コンサル経験あるの?」って聞かれました笑
うちのソフト屋は、ソフトしか作らないというイメージが強い分、インパクトは残したかと( ̄+ー ̄)

残念だったのは、質問がなかった事。
発表内容が当たり前のように感じてしまうくらい分かりやすかったのかもしれないけど、スライドにもある通り「恐れによるもの」で意見を言えない状況が見事に出た感じでした(よく分からないので、変な質問ができない
(自分が使うことを想像して、)自分が納得する質問をしてくれるだけで、十分なのになぁと思いました。

あと、色んな人から「話し方が丸くなった」と言われました。
自分の発表で「社員に、TOCfEに対して悪い印象を持たせたくない」という理由もありましたが、一番の理由は最後の受賞コメントで煽りたかったんですよね笑

なので、最後の受賞コメントで煽りました笑

  • 研修申請したら、部長2人に呼ばれて「そんなの必要か?」と言われて以来申請してないんだよねー → 部長2人、苦笑する
  • 質問がなかったのは残念。キマイラは子供以下ですか(その後、皆さんの伸び代ですね、と付け加える → 「いつも通りだ」と言われるw

そんなわけで、褒められたのに、全方位に絨毯爆撃して全て台無しにしましたとさ笑

ブランチにまつわるエトセトラ

ロジック・ブランチで気づかされたことがあったので備忘録として。

ブランチを描く際に陥るケース

ブランチを書く際に、『何をブランチの事象にすればよいか分からない』と言う状況になると思います。

「とりあえず、ゴールを設定してみて、事象を挙げていこう。」と。

そこからアイテム出しをして因果関係を作っていくと、次のケースにぶつかります。

「ゴールに繋がりそうなアイテムが出てこない・・・」

実業務でも、そんな事起こってない?

ゴールを設定して説明しようとして、うまく説明できない事は、現実社会でも起こり得るケースだと思います。

例えば、以下のようなソフトウェア開発を例に説明したいと思います。

  • ソフトウェアテストの計画がなく、テスト実施は各開発者の裁量で行なっている
  • 新機能を開発した際に、単体テスト結合テストで、正常系/異常系の確認は行った
  • システムテストでUIから可能なテストを実施して、特に異常な動作が確認されなかったのでリリースした
  • ある顧客の環境に新しいソフトをインストールし運用したところ、異常なケースが見つかり損害が発生した。
  • 実は、その顧客向けの特殊仕様があり、新機能には特殊仕様の対応が含まれていなかった。担当した開発者も特殊仕様下のテストを行なっていなかった。
  • 顧客「早急に再リリースしれ。あと、不具合が発生しないことを説明した資料よろ」

顧客にはどう説明する?

「再リリースしたソフトと今後の修正がが不具合がない事」の説明について、思考するんじゃないかと思います。

  • 今回は、抜け漏れていた事を含めて、新機能の正常系・異常系を確認する
  • 今後は、顧客と同等の環境でテストすることを徹底する
  • 合わせて、過去に実施したテスト項目を再確認することを徹底する
  • 担当者によっては何をOKとするか変わるので、今後は過去のテストの動作ログと比較する

でも、現状どれもできていないから顧客を説得することができない。。。何より、

「どうやったら不具合がないって言えるんだろう・・・?」

と考えるのではないかと思います。

『ブランチで陥りやすいケース』に置き換えると

もし『修正したソフトに不具合がないこと』をゴールに設定し、「今回自分たちが行なった作業」をブランチを描くと、こんな図になるんじゃないかと思います。

f:id:kabe-aa:20180526164623j:plain

また、ブランチを描いている最中は、こんな事に悩むと思います(実際に自分で作ってみて感じた事)

  1. 自分たちの作業とゴールに因果関係を作ることができない
    現実と違う事を説明するために、無理矢理繋ごうとしてしまい『ゴールから逆算して推測』し始めます(これ自体は悪くない)
    自分たちの行動と推測の間に因果関係が作れるなら良いですが、そうならない場合は『推測の原因となる推測』を考え始めます。
    考えた末に、『ゴールと同一の推測』や『ゴールとは矛盾してる推測』を作ってしまいます(ブランチを描いている最中は意外と気づいてない)

  2. ゴール達成のための十分な説明ができない
    ゴールを設定しまったことで、ゴール達成の十分性を考えてしまいます。
    下手すると「ゴール達成のために国際規格に準拠することが必要だ!!」と言いかねない状況になりますw*1

ブランチを描くために、ゴールを設定するのか?

実は、自分がブランチ描く際にはゴールを設定していました(笑
で、前述したみたいに、うまくいかないことの方が多かったです。

先日、他人のブランチの作成過程をみて、以下のことに気づきました。

ゴールは設定しない

ブランチを描く際は「現状把握」のために限った方が良いと思います。

そのため、ブランチの一番上にあるものはゴールではなく「最後に起こった出来事」になると思います。

ゴールではなく、あくまで観点として使う

何を事象とすればいいか分からないなら、観点の一つとして使うならありだと思います。

観点として「現状はどうだったのか?」を広げたり、掘り下げていけば、納得のいく現状をブランチで表現できるはずです。

現状とゴールとの差異を見つける

ゴールに近づいているか、作ったブランチを元に考える。

作成したブランチ(開発で実施したこと)がゴールに達成しないのは、そもそも何か問題があるんじゃないか?と気づくはずです。

こんな感じ?

  1. 「顧客環境下で不具合が発生した過程」を現状把握するためブランチを作成する。例えば、こんな感じ
    ※ 作成したブランチは何度か修正した最終版。一番初めのブランチは後述します。 f:id:kabe-aa:20180526172053p:plain

  2. 「作ったソフトに不具合がないこと」をゴールとした場合に、
    「(顧客が納得するような)十分な確認方法」として、何が足りなかったか分析する。
    一例として挙げるなら、、、

    • 顧客は特殊仕様で運用している & 新機能の追加によって特殊仕様が動作しなくなっていた
      「なぜ、特殊仕様の事を把握してなかったのか?」「どうしたら次回以降予防できるのか?」を考える 

最小手数で効果的なところを最初のターゲットにして、開発を改善したり、顧客への説明材料にした方が現実的だと思います。 *2

それでも、説明が足りない、と言われるなら・・・

次に改善可能なターゲットを説明すると良いと思う。

もしくは、アンビシャスターゲットツリーを使って、戦略的にゴールを目指す事を説明する方がいいと思うの(今回は省略

余談(ブランチの修正)

この記事をはじめに公開してから、ブランチの図を修正してみました。 どのように変更したか記載します。

修正前のブランチ

一番最初のブランチは次のように作りました。

  1. 「顧客の環境で不具合が発生する」までの出来事を挙げる
  2. 出来事を「ブランチ作成ルール(CLR)」に従って因果関係を繋いでいく
    ただし、声に出して読んでいなかったため、違和感が残ってしまいました。

f:id:kabe-aa:20180526180123p:plain

修正内容について

基本的には「ブランチ作成のルール(CLR)」に従って、声に出して修正していますが、次のように修正しています。

  • 推測の追加
    例えば、一番上の不具合発生の原因は「新しいソフトで運用する」だけでは十分ではないため、「顧客が運用している条件」「特殊仕様に対する修正」を補足情報を追加しました。

  • 因果の組み替え
    「新機能をシステムに組み込む」→「UIから考えられる入力でテストを実施する」、「UIから考えられる入力でテストを実施する」&「特に異常となるような動作が確認されない」→「新しいソフトをリリースする」までは、声に出して読んでみると、違和感がありました。
    そのため、「新機能をシステムに組み込む」&「UIから考えられる入力でテストを実施する」&「特に異常となるような動作が確認されない」→「新しいソフトをリリースする」に変えました。

  • 文章の変更(具体化)など
    特に「顧客の環境で不具合が発生する」は、起こった現象としては抽象的なので、「新しいソフトがインストールされた顧客環境では運用できない」に変更しています。
    また、因果が特に重要そうでないものは1つの事象に統合しました。ただ、パワーポイントのスペースの制約で統合したので、付箋でブランチを作る際は逆に分けたままの方が使いやすいかも。

最後に

やっぱり、声を出して読むと気付きやすいですね(^^;;

まだしっくりこないところや足りない情報があるかもしれませんが、今の自分の実力ということで、生ぬるい目で見ていただいて、アドバイスしていただければ幸いです(^^;;

*1:きっと「国際規格を使ってどうゴールを達成するの?」ってループするんだろうけど^^;;)

*2:この狙い方はSaPIDを参考にしています

相談をストロングスタイルで受けてたつ

友人の相談

あれは昨年8月、新日本プロレスの真夏の祭典・G1クライマックス、Aブロック最終戦を観戦した時に、友人から相談を受けました。

友人「転職を考えてるんだが、転職を経験した立場としてどうなのか知りたい」(超意訳)

その時の答えは、

俺「まずは自分のスキルの棚卸しからじゃね?その上で今の会社で出来ること、そうでない事を整理した方がいい」

と言って放置プレーしてました。

そして、半年後

先日、その友人から連絡をもらいました。

友人「内定をもらったけど悩んでるので話をしたい」

その直後、回答した事は、 俺「そこまで行動したのに(=結果ももらったのに)、何に悩んでるの?」

彼とのLINEのやり取りだけでは「深く悩む内容じゃないよな」と思っていましたが、会って話をする事にしました。

彼とのやり取りをクラウドにしてみる

彼が解決したいことが何か、TOCのツールの1つであるクラウドを描いてみたら分かるんじゃないかと思い、話をしながら描いてみました。

その時に描いたクラウドf:id:kabe-aa:20180210192131j:plain

それぞれの箱の説明

今回の対立している行動は「今の会社に残る」と「今の会社を辞める」(図中の右側の上下の箱2つ)。

対立しているそれぞれの行動に対して要望を入れる(図中の中央の上下の箱2つ) 。
今回は、「今の会社に残る」の要望は「スキルがあるので、今の会社でうまく仕事(を続けることが)できる」
「今の会社を辞める」の要望は「仕事の幅を広げたい」とした。

次に、これらの要望を満たす共通目標を決める(図の左側の箱)。
ここでは「自分の将来を考えたい」に落ち着いた。

納得感が得られるまで作り変える

クラウドを作成するときは、本人の話を聴きながら、要望と共通目標を何度も作り変えています。

実際は複数の要望が出ていますが、色んな要望や目標があった中から、自分も本人もしっくりきたものを選んだつもりです。

仮定を作り、矛盾を見つける

それぞれの箱を接続している矢印には、仮定(前提条件)が存在しているので埋めていきます。
その上で、論理的な矛盾を見つけます。

上側

「自分の将来を考えたい」(目標)ならば、「スキルがあるので、今の会社でうまく仕事(を続けることが)できる」(要望)、何故ならば、「スキルが特殊である」(仮定)。
「スキルがあるので、今の会社でうまく仕事(を続けることが)できる」(要望)ならば、「今の会社に残る」(行動)、何故ならば、「今の仕事に慣れているから」(仮定)。

着目するべき仮定は「今の仕事に慣れているから」で、自分の将来を考えてるなら、「今の仕事のその先を考えて実践していかないといけないんじゃない?」と考えることができる。
つまり、「会社に残ろうが辞めようが、先のことを考えてなければ意味がないんじゃないの?」と言えるようになりました。

下側

「自分の将来を考えたい」(目標)ならば、「仕事の幅を広げたい」(要望)、何故ならば、「今の仕事がなくなるかもしれないから」(仮定)。
「仕事の幅を広げたい」(要望)ならば、「今の会社を辞める」(行動)、何故ならば、「今の会社での先が見えないから」(仮定)。

着目するべき仮定は「今の会社での先が見えないから」で「本当にそうなの?」と自分は疑問に思いました。
つまり、そこに、今の会社に残るための意義があるんじゃないかと思いました。

結論

どっちでもいいんじゃね?笑

自分の言葉で誘導しないようにクラウドを作成してたので本人の純粋な考えをまとめたつもりですし、結論も彼が決めるべきだと思うので。
※本人も相談前から「最終的には自分が決める事だ」と認識済み。

自分は、クラウドを描いてみて、彼の考えてたことを理解しましたし、彼にとって必要なものが何か見えたので、勝手に満足しました笑

少し話を発展させる

クラウドを描くだけだと、無責任感は否めないので笑。

俺「もし内定先の業務内容が似てるなら、どんな職場環境か、ある程度想像できるんじゃね?目標を達成できそうな方を選ぶ方が良くね?」 とは話しました。

共通目標が見えた事で初めて、行動を選択するための判断材料になったと思います。

ストロングスタイルな問題解決とは?

ストロングスタイル - Wikipedia

ぶっちゃけ、このエントリーを読んだ後、 「お前が言ってるのは、ストロングスタイルじゃねーよ!」 と思う人もいるでしょう。
解釈は人それぞれあるので許してくださいw

自分にとっての問題解決は「風車の理論」に近いと思っています。
かつてアントニオ猪木が言った「相手の力を9引き出して10の力で勝つ」というやつです。

ただ、ちょっと違う点としては、、、

相手の力を9引き出すのではなく、10引き出す

要は、相手の抱える不安や生の感情やら、全て引き出した上で問題解決できれば良いかな、と思います。

勝ち負け関係なく、ただ前向きに白熱すれば良い

最終的に、問題解決は本人にしかできないんですよね。

そのために、ネガティブな意見が出てこないように、前向きに話し合うことができたら、あとは勝手に問題解決してくれるんじゃないかと思います。

もちろん、答えが欲しいなら、答えを言っちゃうこともできますが。。。 そりゃあ、しょっぱい試合だった時は、そういうこともしますw

最後に

自分が提唱する「ストロングスタイルな問題解決」を、今回事例も踏まえてブログに書いてみました。

それがいつでもできる訳ではないですが、そんな風に意識して今後相談を受けてたちたいと思っています。

『ゆるファシ』体験ワーク、からの今年の抱負

NaITE #26 『ゆるファシ』体験ワークショップに参加してきました。

nagasaki-it-engineers.connpass.com

  1. ワーク体験
    やった事をざっくり、、、

    • グループ内で各個人が抱える問題を1つ説明して共有する。
      その時の背景や細かい状況は付箋にメモする。 話しているうちに別の問題が明らかになったら、新しい問題にする
    • 各人の問題点について、違いを捉えてみる
      違いを見つけるのは難しいので、最初に共通点を見つけてから、違いを見つける方が良いらしい。 
    • 違いや話した内容から、自分が解決したい問題を特定して、解決するためのアクションを決める
      グループ内で解決したい問題とアクションを宣言しました。
  2. 成果物
    自分の成果物はこんな感じ。
    「自分の作業の進捗が思ったように進まない」問題だったのですが、
    グループで共有しているうちに、「自分が始めた仕様のトレーサビリティの改善が定着しない」ことに気づいて、
    最終的な問題は「改善を進めた結果、自分の負荷が高くなっている」になりました。 アクションは、「他の人に任せられるようにする」です*1 f:id:kabe-aa:20180121121541j:plain

  3. 雑感
    自分が問題解決する際、TOCfEのツールを使って自分が感じた違和感を問いかけるように、本当の問題を見つけるようにしていますので「ゆるファシ」は、自分のやり方にしっくりきました。 でも、ゆるっとファシリテーターの、あのゆるさは正直真似できないなぁ(褒め言葉w

  4. 今年の抱負

実は、今年初めにマインドマップに抱負を起こしていたので、便乗して紹介(笑 f:id:kabe-aa:20180121121531p:plain

  • 会社に対する目標
    「業務時間に余裕を作る」の一つに「他人に作業を委譲する」って書いてたw
    あと、今年は勉強会を開催して、社員を向上していきたいかなぁ。

  • 個人の目標
    今年はプロジェクト管理のために、本格的にスクラムを学んでみようかと。 そのために、色々情報を仕入れている最中です。

*1:変えるときは、まずメンバーに合意とろうよ、自分(^^;;

2017年を振り返る

今年を振り返った。けっこう駄文w

f:id:kabe-aa:20171231102424p:plain

  1. 会社への計画

    • 自分の作業に余裕を作る
      6月あたりから、ほぼ上流設計しかしなくなった。けど、システムの要求仕様まとめるだけで今年は終わった。 。。 そもそも工数の都合でやってなかったので仕方ない… 要求仕様作成の経験者がいない、ってのも… まぁ、良い経験させていただいております(^^;;

    • 社員レベルの向上
      詳細設計、実装、(今までのレベルで)のテストは別の人に任せることができた。ただし1人だけど。
      今の問題は、自分に設計が依存してしまうこと。
      「どう設計してほしいか分からない」と言われるので結局自分で設計する羽目に。むー(; ̄ェ ̄)
      設計意図を伝えるような書き方を意識してたけど、自律的に向上させるためには、別の方法でサポートした方が良さそうです…   

    • 開発プロジェクトの改善
      当初やろうとしたことは手付かず…
      というか、グループ内の仕事改革が起きて、仕事の仕方を見直す場ができた。
      前半でキレて良かったかな(よくない笑
  2. 自分の目標

    • テスト力の向上
      今年は、某塾やモデルベーステスト自動化の分科会、他にも色んな勉強会に参加したので、色々学ぶことが多かった。
      (テスト設計ではなく)機能設計にはだいぶ反映されているかなぁ。。。アウトプットできる成果は今のところないけど。。。  
    • 設計力の向上
      機能開発以外は、ほとんど他人に任せた、と思う。 その分、他人の設計を読み取る力も身についた。  
    • 問題解決手法を学ぶ
      今年初めにTOCfEに出会ったのは大きいかも。 あと、エニアグラムの講習を受けた事で、自己理解・受容できるようになった。 自分が感じた違和感を適切な方法で伝えられる、良い方法を一緒になって考えられるようになった事は、今年一番の成果だと思います。  
  3. 当面の業務
    1つは完成して、必要に応じてアドバイスする程度なので、手離れできた。
    もう一つは、システムアーキテクチャごと変更してるので継続中…という言い訳してるけど、やっぱり見積もりは甘かったなぁという感想。
    でも、今一番欲しいスキルは、見積もりというより、メンバーの力をうまく引き出す方法ですかね。

  4. 最後に
    今年は、『ながーいトンネルの中でようやく光が見えた気がする』一年だった
    多くの出会いと学びをいただいて、皆さんに感謝です。
    来年もよろしくお願いします!

9人のテストエンジニア

この記事は、「ソフトウェアテストの小ネタ Advent Calendar 2017」の20日目の記事です。

qiita.com

エニアグラムを使って、テストエンジニアの特徴を考えてみたいと思います。

エニアグラムについて

自己成長とコミュニケーションのための人間学』と呼ばれています。

f:id:kabe-aa:20171218103419p:plain
エニアグラム

詳しく知りたい方は、ググってみてください(許諾を得ていないため、リンクは載せませんw)

テストエンジニアにいそうな特徴を、エニアグラムのタイプ別に考えてみたいと思います。 私自身は認定コースを受講していますので基本的なところについては把握していますが、それでも個人的な主観が入ってしまうことをご了承ください。

業務で自分のタイプに囚われたり、同僚と対立を生まないため、特徴を理解したい想いで考えてみましたので、ご参考程度にしていただけたらと思います。 また、タイプは自分の強く出るところですので、他のタイプの良いところを自分のものにして行けば、今後の成長に役立てられると思います。

※ ステレオタイプに当てはめてしまって行動したり、相手の方を当てはめてしまうことを私は望んでいません。

タイプ1:改革する人(本能:ガッツセンター)

テストを抜け漏れなく確実に実施したり、周りがその通りに行動するような施策を作ることが得意だと思います。

ただ、不要なテストを省略せずに全数実施することで時間が足りなかったり、作った施策を周りが実施しないことにイライラすることがあるかもしれません。 タイプ7のように、自分のタスクを気楽に考えること、周りを楽しませるように施策を考えると良いかもしれません。

タイプ2:人を助ける人(感覚:ハートセンター)

自分の業務に関係なく、テストの準備を手伝ってあげたり一緒に実施するのが好きなのかもしれません。 でも、感謝されないとストレスが溜まる傾向にあると思います。

個人のタスクを達成する事。タイプ4を参考にすると良いと思います。

タイプ3:達成する人(感覚:ハートセンター)

テストアーキテクチャ設計など、先進的な考えを導入することが得意だと思います。 また、効率性が高く、少ないテストケースの実施で、欠陥の検出できるような特徴があると思います。

たとえ、設計が先進的であっても、プロジェクトに適合できるかの検証が漏れてたりします。 効率性を重視するあまり、テストケースに抜け漏れがあるかもしれません。

タイプ6のように忠実にテストを実施すること、十分な検証も必要かもしれません。

タイプ4:個性的な人(感覚:ハートセンター)

個人ワークで黙々とテスト作業することが得意だと思います。 プロジェクトに影響されずに自分で試行錯誤して解決することができますが、一方でプロジェクトの解決するべき課題にならない傾向にあると思います。

単純なテストケースの実施は苦手かもしれません。。。 感覚が優れているので、逆にテスト実施中に別のケースに気づくことがあると思います。 ただ、アドホックにならないようにしたいです(自戒の意味も込めてw

タイプ1のように、プロジェクトの課題として改善に繋げることが必要だと思います。

タイプ5:調べる人(思考:ヘッドセンター)

テスト技法や最新のアーキテクチャ設計方法などを自ら調べ知識にしたり、プロジェクトの問題点を分析することが得意です。 ただ、プロジェクト全体から一歩引いている傾向にあり、メンバーに知識を提供しますが、それが実施可能かどうかまで検討しない傾向にあるかもしれません。

タイプ8のように、プロジェクトの達成のために積極的にチームに入っていくことが成長につながると思います。

タイプ6:忠実な人(思考:ヘッドセンター)

単純なテストケースを実行すること、作業を着実に進めることが得意だと思います。 ただし、難しい課題に直面すると、全体像がつかめず一部の問題解決だけを追求することがあるかもしれません。 テストの網羅性を把握しない、組み合わせテストで全数テストすることがあるかもしれません。

不安を感じたり分からないことがあれば、全体に問題としてあげること。タイプ9のようにチーム全員で協調することが必要だと思います。

タイプ7:熱中する人(思考:ヘッドセンター)

興味を持った技法やテストアーキテクチャ設計をすぐ試したいと思い、周りを楽しく巻き込むことが得意だと思います。 ただ、自分の業務を分析せずに適用しようとしたり、反対メンバーに歩み寄ることを苦手とするため、最終的にグダグダになることがあるかもしれません。

タイプ5のように分析すること、反対メンバーがいたら意見を聞くようにすることが良いと思います。

タイプ8:挑戦する人(本能:ガッツセンター)

プロジェクトや自分のタスク達成のための目的を本能で理解し、周りを巻き込んで実行する力があると思います。 また、不具合が発生した場合にリスクや影響範囲を収集し、いち早く消化する事に優れていると思います。

ただ、実行力に優れている反面、スキルが低いエンジニアを置いてけぼりにする傾向があるかもしれません。 タイプ2のように、一人一人に歩み寄り理解してあげる事が良いかと思います。

タイプ9:平和をもたらす人(本能:ガッツセンター)

プロジェクト自体やメンバー全員がまとまっていて協調することに生きがいを感じ、ファシリテーションが優れていると思います。 比較的ゆったりとしたペースで作業しますが、自分のペースに合わない状況がプロジェクトで起こると、ストレスを感じるかもしれません。。。

タイプ3のように、成功や効率を求める考え方を取り入れると、自分と一緒にプロジェクト全体を成長させることができるかもしれません。

最後に

テストエンジニアとあまり関係ない気がしますね(笑) また、自身のタイプである4は、記述多めです(笑

自分で読み返して思いついたのですが、プロジェクトの各工程の抜け漏れを防ぐためのチェックリストとして活用できる気がしました。

よろしければ参考にしていただけたらと思います。

WACATE2017冬公開のBPP三部作、堂々完結

って、BPP賞をいただいた話から、半年間ブログ更新してなかった(汗

というわけで、WACATEの内容に関する事は他の人に任せて、前回のBPP受賞者が過ごしたWACATEについて書きたいと思います(笑

WACATE2017 冬 ~すべてがTになる~ 開催概要 - WACATE (ソフトウェアテストワークショップ)

第1部:BPPセッション

自己理解をして、自身の日常や業務に役立てましょう』というライフハック方法の紹介です。
公開しているスライドでは、以下の内容をカットしています。 

  • 具体的な業務内容
  • ライフハックの元ネタ(このネタも含めた完全版スライドは来年公開するかも。今は伏せさせてくださいw)

www.slideshare.net

発表でやったこと、工夫したこと

  • 自分の緊張をほぐすため、最初に台本にないことを適当に喋って笑いをとる。
    今回は『初回参加の人を確認して、ベテランの暴走を抑制する』ことをしてみました。
    本当は別の事を話すつもりでしたが、、、(第02回ひとりラジオ BPPセッションで確認)

  • 全体を伝えておいてからの「話しません」で、徐々に本題に絞っていく

    • 1回目
      業務紹介した際。
      一応、BPPセッションの内容として、開発・テストの話も考えていたことを伝えるため。

    • 2回目(発表テーマに対しては1回目)
      だって、セルフコントロールコーチングの方法知らないもんw
      でも、自己理解できれば、最終的には繋がると思っています。

    • 3回目(発表テーマに対しては2回目)
      今回の発表の元ネタ(スライド非公開)なのに、話さないという暴挙に出た瞬間w


      元ネタを話し始めたらキリがなくなるし、そのワークショップを開催するためのアドバイザーの資格を持っていないので。
      でも、それを使わなくても、自己理解できることを紹介したかったのです。
      ライフハック」は、「別の言葉」から置き換えてツイートしてもらっていますw

  • 小ネタの応酬
    一つ目の手がかりにて言ったセリフ

    • 「『ピンときちゃった』ってどう言うことですか?」(某T社のCMの満島ひかりを意識して、人差し指を立てる)
      → 知らない人が多数と思われる(似てないとは思っていないw)。ただ、満島ひかりが好きなだけなので、言えて満足w

    • 「『父さん、妖気です』ってことですか?」(鬼太郎の妖怪アンテナが立った時に言いそうなセリフ)
      → 何人かがクスッと笑ってくれた。

    • 「『姉さん、事件です』ってことですか?」(ホテルの高嶋政伸のセリフ)
      → 語感が似てただけで勢いで言う。もちろんダダ滑りwwww

  • 発表内でのワーク

    • 簡単なケースを試してもらった。
      分かったからって「あいつは、このタイプだから嫌い」って殴り合いの喧嘩はしないでね。

    • 2つ目の手がかりのワークはやめた。
      WACATE実行委員から「時間超えるかも」「初めての人にはワークは難しいので、具体例を出して欲しい」というアドバイスをいただきました。 実際に自分のケースが思いつくだけでも1週間以上近く考えたので、最終的にワークをやめました。この判断は賢明だったかも。

  • 本スライドに影響を受けたもの

    • なそくんの2017夏のBPPセッションのスライド
      社外でよく見るLTのスライドとして参考にしました。

      www.slideshare.net

    • 第37回テストラジオ
      プレゼン資料の作り方は参考になりました。 twitcasting.tv

    • 進入禁止のテープ
      公開されないスライドにある素材だから、検索しても見つからないw なんとかフリー素材を見つけて使用しました。

    • IBM細川さんのプレゼン方法
      「初の社外での発表でインスパイアされてますよ、全く似てないですけどねw」と余談を入れてみる。
      「結果として自分らしいプレゼンが出来上がったし、スライドを作るためのモチベーションにもなりましたよ」って言いたかったの。

  • よかったこと

    • 発表しているときは、案外落ち着いていた

    • 30分ぴったり終わった
      普段は緊張しぃなのに、本番で強いのはなんだろね、とか思いつつw

    • ゴングを鳴らすことができたw

  • 悪かったこと

    • 語尾の癖
      自分でも気になるので、直したいところです。。。

第2部:夜の分科会

WACATEの夜の分科会のオーナーになりました。 やったことは「皆さんで自己理解してみよう」でした。

10人ぐらい集まったかも。嬉しい反面、モデレータとしての責任が。。。

分かったことは、

  • 好プレーって案外出てこない
    自分じゃ当たり前の事だから、案外好プレーは本人からは出てこないですね。。。
    もうちょっと思いつきやすい行動で、引き出し方を考えた方が良いと思いました。

  • 例えは、もっと難しい
    まぁ、承知の上だったので、聞き役になって引き出そうと思ってたけど難しかったw

最終目標として「キミはこの直感を使って、こんなのするのが上手いんだね。」と認識するところまで行きたかったけど、ただの自分語りの会になってしまったような、、、
でも、一人から「自分のことが分かった気がします」という意見をいただけて嬉しかったです。
もっと改善できるよう頑張ります!

第3部:夜の一人ラジオ

テストクラスタお馴染みの「なそとオカウチワニのテストラジオ」の「第02回 ひとりラジオ BPPセッション」のゲストとして参加しました。 今回の発表の裏話が聞けます。

twitcasting.tv

自分の声ってこんなんなんだ笑、しどろもどろだし、恥ずかしいな笑

今回のWACATEの雑感

今回は、セッションあり、分科会モデレータあり、ラジオパーソナリティあり(?)と、幅広く経験させていただきました。
セッションが終わった後は、登壇者の横でずっと聞いていました。特別席かっ!
小学校の授業で騒いで先生の前で座らされた気分にもなりましたがw

WACATEの詳しい感想は内容は後日載せるかも。。。

あと「コミュ力強化」をテーマに掲げていたので、自分の班のファシリテーションや意見の抽出を積極的にやらせていただきました。
6人中3人が初回参加でしたが、それぞれのセッションの目標を達成できるように意見を引き出せたかなぁ、と思います。
次回も参加してくれるといいですね。

WACATEスタッフの皆さん、開催までの間色々とご迷惑をかけてしまいましたが、とても貴重な経験をさせていただき、ありがとうございました。 そして、参加者の皆さん、お疲れ様でした。