読者です 読者をやめる 読者になる 読者になる

2017/2/25,26, 【SaPID+bootcamp】に参加しました。

プロセス改善の手法であるSaPIDを集中して学べるSaPID+bootcampに参加してきました。

安達さんが講師のもと、自分が仕事で抱えている問題を実際にSaPIDを用いて整理して、体験するができた二日間でした。

ワーク概要

自分が業務で抱えている問題をもとに、問題構造図を作成し、改善目標を検討するところまでを行いました。特に、洗い出した問題の精査が難しく、半日以上の時間がかけられていました。問題の精査の際には二人ペアでの作業となり、一方の問題に対してもう一方が質問をすることで問題を深掘りする手法で行われました。問題構造図を作成する技術だけでなく、相手の理解を深める助けをするSaPIDファシリテータの技術を学べるという、時間をかけられる合宿形式ならではの内容になっていました。

振り返り

二日間で振り返るポイントは山のようにありますが、特に問題構造の整理とファシリテーションに着目して振り返ります。

問題構造の整理

keep
  • 一通り、合宿をやりきれた。一日目の予定分が終わったときは中途半端に終わらないか不安だったが、ペアの人の協力などもあり最終的には一通り形にすることができた。まだまだ上手く整理できたものではないかもしれないけど、中途半端で終わらない、よりは未熟でも完了するほうが次に進めるため、個人的にはこのbootcampの最低限の目的を達成できた。
  • 洗い出しの最初の際に実務で感じた「良くない感覚」を頼りに問題を出せた。SaPIDの問題としてはとても浅いものではあるが、あとで深掘りするからこそ、「良くない感覚」を自覚するつもりでだせたため、広い範囲で問題を洗い出せたと感じた。
  • 問題がロジックツリーのように整理された形にならない、ということに気付けた。問題は人それぞれなので、必ずしも整理できる形で出てくるとは限らないことを理解できた。
  • 付箋に書き出した問題をまとめることができた。洗い出した問題の数が多くすぎて、全体の俯瞰が難しくなったが、まとめることで全体像の整理に注力することができた。SaPIDとしては問題は抽象的よりも具体的であることを推奨しているが、ある抽象的な問題に着目する必要が出てきたときに、まとめていた問題を分解すれば良い、という考えでやってみた。
  • 問題のグルーピング、構造化を早期に行った。カリキュラム的に先走った感があるので、ワーク的に妥当だったかは不安が残るが、グルーピングや構造化を行うことで、全体像を把握しやすくなり、問題をまとめることなどに貢献した。
problem
  • なかなか心の奥につっかえている問題を出すのが難しかった。こればかりは自分の心の壁を取っ払うしかないので、自分の問題に直面できる強さが必要があるかと感じた。表面に出てくる問題を解決できれば、根っこの問題が見えてくるかも。
  • 問題をまとめたこともあって、最終的な問題が抽象的になった。SaPIDでは具体的な問題整理を行うため、十分に学びきれたかに不安が残る。問題のスコープが広いこともあったため、どうしても問題が発散してしまったことが原因だと思われる。もう少しスコープを限定してやってみたい。
  • 問題の分類について理解が疎かになってしまった。問題ではなく手段も多く残ってしまった。問題と思って出したものが何なのかを吟味する必要がある。
  • 口頭でたくさん説明したが、その説明を問題として場に出すことが上手く行かない場合があった。口にだしたら即書き落とすことをもっと徹底すべきだった。
try
  • 問題が抽象的になってしまったため、より小さいスコープでやってみたい。
  • 問題をより具体的にしたい。NGワード(抽象的な言葉として良く出てくるもの)をいくつか教わったので、NGワードを分解するようにしたい。
  • 問題じゃないものを多く出してしまったため、出した項目が問題か、手段かを吟味したい。

ファシリテート

keep
  • ほかの人の問題をうまく深掘りできる質問ができたと思う。特にうまく行ったと思っているものとして、「相手が出した問題があったとして上手く行くケース」を例示することが挙げられる。それを例示することで、「いや、そうじゃないよな」と考えを深めてもらうことができたと思う。
  • 相手に教わる姿勢の重要性を学んだ。「おそらく相手はこういう問題を持っている」と予想していても、相手の捉え方が異なる場合が多々あった。事前に講師の安達さんから「相手に教わる姿勢が重要」と聞いていたが、その意味を体感することができた。
  • ペアの人がいてくれることで、感性的な問題を出しても深掘りしてくれる、という安心感があった。
problem
  • 相手が深掘りで詰まっているときに、例を出してしまい誘導をしてしまったことが何度かあった。例を出す場合は少なくとも2つ以上を出して、相手の思考停止を防ぐようにする必要があった。
  • ペアをしてくれる人に問題を話し過ぎて、自分がスルーしてしまう部分に対してペアの人もスルーしてしまうことがあった。話したことは書き落とすことを徹底すべきだった。
try
  • もっと相手のことを理解したい、という気持ちでどんどん教わりにいく。

まとめ

SaPID尽くしでしたが、学ぶことが多くてとても勉強になる二日間でした。SaPIDはもっと色々試して、自分のものになるように練習したいと思います。とても楽しい時間をありがとうございました!

2017/2/24(金)、「未来予想型チーム運営ワークショップ」に参加しました。

仕事をしていると、未経験の領域の作業をしなければならないことが多々あります。不確実性が高いため、正確な見積もりなどほぼ不可能な場合がほとんどですが、そんな中でも作業を見積もって、分からないなりに仕事をこなさないといけません。

今回はそんな不確実性の高い状況でも、自分たちのどのようになりそうかを予想しながら、問題を着実に解決し、理想的な未来のために前進するためのアイディアを学べる「未来予想型チーム運営ワークショップ」に参加してきました。
www.kokuchpro.com

問題解決のための手法である「SaPID」と「TOC」の融合という、これまでにない新しいアイディアであり、とても楽しみにしていたワークショップです。とても楽しく、非常に考えさせられる密度の濃い時間を過ごすことができました。

ワーク概要

TOCのワークショップである「CCPM×折り紙ワークショップ」がベースになっており、チームになって時間内に指定された折り紙を折る、という内容でした。折り紙のお題は最初の段階では到底達成できないと思えるような厳しい条件です。それをSaPIDをベースに起こりうることを予想して、起こりうる未来にはどんな問題があって、どのような要因から引き起こされるのかを整理します。得られた要因に対する対策を検討し、実際に折り紙を折ってみて、検討した対策について振り返りを行い、徐々に改善していきました。できないと思われた問題も、改善を繰り返していくことで効率良く進めることができ、結果的に当初の作業見積もりから大幅に短い時間で折り紙を折り切ることができました。
f:id:toshimana:20170224162739j:plain

感想

語りたいことはいっぱいありますが、その中でも特に心に残ったことを書き留めておきます。

予想した通りの結果になる

課題が厳しい条件だったため、起こりうることを予想した時も、失敗する予想が多く挙がりました。講師の安達さんから、「予想した通りの結果になる」とアドバイスをいただき、現実味があるかはともかく完成するためのストーリーも予想してみました。そういった予想が糸口となって、厳しい課題を達成できる改善案が見つけることができたため、どんなに厳しい条件でも成功するストーリーを想定することが実際に成功を手繰りよせるカギとなることを学びました。

流石にお花の折り紙が多いからと、ある参加者が「お花畑ができあがる」と予想したのが叶うとは思いませんでした。別の参加者が知らずにお花畑作ってました。
f:id:toshimana:20170224164022j:plain

言葉はできる限り具体的に

起こりうることを予想するとき、抽象度の高い言葉を使ってしまうと、問題やその要因がぼやけてしまい、具体的な改善策の検討が困難になります。予想を洗い出したあと、出てきた言葉を整理する作業がありましたが、自分では意識していなくても抽象度の高い言葉を使っていることに気づかされました。自分が予想した内容の文脈を明確にすることで、自分の頭の中も整理され、本質的な問題が見えるようになるんだということが分かりました。

SaPIDもTOCもやりたいことは同じ

SaPIDとTOCの2つの手法が上手く融合されていて、SaPIDの手法/TOCの手法が使い分けられていることを全く意識することなくワークをやり遂げることができました。お互いの強みを生かした構成になっていることもさることながら、異なる2つの手法がこんなに自然に繋がることに驚きを隠せませんでした。SaPIDもTOCもやりたいことは同じだからことできることでもあり、その2つをこんなに上手く融合させた講師の安達さん、水野さんは本当に凄いと思いました。

まとめ

折り紙のワークでは高度な改善を行ったにも関わらず、チームとして収支良い雰囲気でワークに取り組めました。実際の仕事では殺伐とすることも多かれ少なかれ存在しますが、良い雰囲気でも(むしろ良い雰囲気の方が)高度な改善が可能であることが本ワークで実感できました。
このように、成果が上がって皆が楽しめる場づくりをしていきたい、と強く感じた一日でした。

2016/11/19(土)「第二回盛岡ソフトウェア勉強会」に参加しました。

2016/11/19(土)の第二回盛岡ソフトウェアテスト勉強会の参加レポートです。

kokucheese.com


岩手では勉強会活動があまり盛んではない、というところから岩手出身の藤沢さんが岩手に縁のある方々を集めて開催しています。登壇者の浦山さつきさんは同じく岩手県出身、吉田さんは滝沢市にある株式会社ヴェスに勤務されています。私は岩手と直接の縁はありませんが、岩手出身の会社の人などと一緒に参加しました。

はじめに

ソフトウェアテストの勉強会だと、テスト技法についての話が多いです。しかし、今回は「ソフトウェアテストの第一歩」というテーマで、上流よりのテストの考え方について学ぶ勉強会となっています。講演者3者がテストプロセス、テストレベル、テストタイプについてそれぞれ語る形式となっています。

ソフトウェアテストことはじめ2016年ver

藤沢さんによるテストプロセスの要素である(テスト計画、テスト分析、テスト設計、テスト実装、テスト実行、テスト報告)についての説明と、藤沢さん自身の経験から考案したソフトウェアテスト活動簡易評価チェックリスト10か条の各項目の説明、という構成でした。

10か条は時間の都合で詳細な説明がされたのは5項目でしたが、機会があれば全部聞きたかったです。藤沢さんの経験に基づいているため、私含め参加者の皆様からしたらドキリとくる内容だったかと思います。いくつかピックアップしてみます。

テストに関する成果物のレビューを計画していること。また、計画通り実施していること。

テストに関する成果物に対して、必ず関係各位にレビューをしてもらおう。セキュリティ部門の方とか、開発の方とかにレビューをしてもらうことで、自分では気付かなかった成果物の問題点に気付くことができる。レビューを計画しても関係者とのスケジュール調整が困難な場合がある。しかし、レビューを実施しないことは危険であり、重要な人をピックアップして行うなどしてレビューは必ず実施する。

テストケースは、具体的なテスト実行手順を読み手に理解できるように記述していること。

検討したテストケースがテスト実行のフェーズになって実行できない問題が起きる場合がある。そのため、手順で使うツールや環境などの不明点は明確にした上で手順を検討する。細かい環境が分かっていないとテスト実行ができずに手戻りが発生する。

手戻り撲滅!テストからできる手戻り防止策

浦山さんからは開発のコストを下げるためのテスト側からのアプローチと受け入れテストについての考え方の話をお聞きしました。ワークが多く、ほかの参加者の方々と意見交換をすることができて楽しくみることができました。

開発コストとテスト

開発のコストとして、「製造コスト、予防コスト、評価コスト、内部失敗コスト、外部失敗コスト」に分けられる。製造コストを除いたものを品質コストと呼び、予防/評価コストを管理可能な品質コスト、内部失敗/外部失敗コストを管理ミスの品質コストとする。長期的な品質戦略としては管理ミスの品質コストを減らすことで、「機会損失」を減らすことが重要。そのために、要求分析や設計の段階からレビューにより不具合を検出して、手戻りを少なくすることが有効であるとされる。今回紹介された開発コストの分類は以下の書籍が出典となる。

受け入れテストの考え方

機能という言葉の2通りの解釈ができる。FunctionとFeatureの解釈があり、Functionはソフトウェア開発で使われる製品操作を指す言葉。対して、Featureはもとはマーケティング用語でユーザに「役に立つ」ことを指す言葉となる。テストの観点を抽出する目的としては、ユーザ視点側であるFeature側の機能を出すようにすると良い。テスト項目を洗い出した後に「これはユーザにとってどんな価値を与えるのだろう」という切り口を持つことで、新しい項目が出てきたり、その機能がどうあるべきかを見つめなおす切っ掛けとなる。

ユーザビリティの重要性

吉田さんからは様々テストの中から、テストケースでは表しにくいユーザビリティテストについての話を聞きました。エラー時の言葉の使い方や画面タップ時の挙動についての事例を紹介しながら、テストケースの手順や期待値では表せない「ユーザがどのように受け取るか」を検討することの重要性について解説いただきました。

おわりに

岩手の勉強会活動が盛んではない、という話でしたが土曜日にも関わらずたくさんの方が参加されていました。仙台からだと比較的参加しやすいので、次がありましたらまた参加したいと思います。

改善のジレンマ~ゲーム理論から学ぶ改善の勘所

改善活動がうまくいかない様がゲーム理論の「囚人のジレンマ」に似ていると感じたところから考えを整理してみました。異論は認める。どんとこい。

はじめに

勉強会に参加すると「職場の環境を改善したい」という意思を持っている人は結構見かけます。しかし「自分のチームが最高になりました」という話はなかなか聞きません。理想に近づくために改善活動を頑張っているのに、状況は一向に改善しない。自分は凄く頑張っているのに自分の周りは改善されない。頑張っているのに報われない、悩みを持っている人たちを多く見かけます。

その頑張っているのに報われない様をゲーム理論における「囚人のジレンマ」になぞり、問題の整理と改善のヒントを見つけることが今回の目的になります。

囚人のジレンマ

囚人のジレンマ」とは個人が自身にとって最適な選択を取ったとして、必ずしも全体最適にならない例のことです。

  • 共犯で重い罪を犯した二人が別件で逮捕された。警官が二人を別々の場所に隔離して取り調べを行い、それぞれに「もし相手が黙秘し、お前が重罪を自白したのなら無罪にしよう。」と取引を持ち出した。一方が黙秘し、もう一方が自白した場合、黙秘したほうは懲役10年、自白したほうは無罪となる。二人とも黙秘した場合は別件逮捕の件で懲役1年、二人とも自白した場合はともに懲役5年となる。

二人の囚人をそれぞれA,Bとします。囚人A,Bの懲役期間の表は以下のようになります。

囚人A\囚人B 黙秘 自白
黙秘 (-1,-1) (-10,0)
自白 (0,-10) (-5,-5)

仮に囚人Bが黙秘した場合は自身も黙秘すれば懲役1年、自身が自白すれば無罪になり、囚人Aにとって自白したほうが有利になります。囚人Bが自白した場合は自身が黙秘すれば懲役10年、自白すれば懲役5年となり、囚人Aにとって自白したほうが有利になります。つまり囚人Bの黙秘/自白に関わらず、「自白」することが囚人Aにとって最善の結果になります。
囚人Bにとっても同様に、囚人Aの黙秘/自白に関わらず、「自白」することが囚人Bにとって最善の結果になります。
そのため、各々が自身にとって最適な結果は「両方とも自白する」ことになります。
しかし、「両方とも自白する」ことにより共に懲役5年になるのに対し、「両方とも黙秘する」ことで懲役1年になるため、協力して「両方とも黙秘する」方が囚人にとって良い結果になります。

改善のジレンマ

改善活動を囚人のジレンマになぞって、以下のように仮定します。

  • 職場の環境に不満をもった二人の社員がいます。一方が改善活動をし、もう一方が改善活動をしなかった場合、改善活動をしたほうは改善効果より労力が勝るためマイナス、改善活動をしなかったほうは労せず改善効果が得られたためプラスとなる。二人とも改善活動をした場合はともに労力以上の改善効果がえられるためプラス、二人とも改善活動をしなかった場合は変化なしとなる。

二人の社員をそれぞれA,Bとします。社員A,Bの損得の表は以下のようになります。

社員A\社員B 改善活動する 改善活動しない
改善活動する (3,3) (-2,5)
改善活動しない (5,-2) (0,0)


社員Bが改善活動をする/しないに関わらず、社員Aにとっては「改善活動をしない」が最善手になります。同様に社員Bにとっても社員Aが改善活動をする/しないに関わらず、「改善活動をしない」が最善手になります。つまり、改善活動はしない方が良い、という結論になります!

...そんな訳ないですね。
協力して改善活動をする(3,3)ほうが、二人とも改善活動をしない(0,0)ことに比べて良い結果となります。しかし、個人レベルで見た場合は「改善活動をしない」ほうが相手の選択に関わらず良い結果となります。
この考えをもとに、あなたが改善活動をしていてもあなた以外が改善活動をしてくれないことを、ここでは「改善のジレンマ*1」と呼びます。あなた以外にとっては改善活動をしないほうが最も得をする選択なので、改善活動をしないのです。あなたはあなた以外が協力して改善活動をしてくれないことに憤りを感じることがあるかもしれません。しかし、あなた以外に悪意があるかどうかは関係なく、改善活動をしないのは自然なことなのです。

繰り返しゲーム

上記の「囚人のジレンマ」は1回だけのゲームを想定していますが、現実では同様のシチュエーションは何度も何度も訪れます。ここでは、時間経過と長期的な関係を扱う「繰り返しゲーム」を元に「改善のジレンマ」の対応策を検討します。

有限回の繰り返しゲーム

ゲームの回数が決まっている、有限回の繰り返しゲームについて整理します。T回の囚人のジレンマを繰り返し行ったときに、どのように行動すればよいかを考えます。結論からいうとT回の囚人のジレンマを行った場合、各囚人にとって「全ての回で自白する」ことが最適解になります。

  • 各囚人は最後のT回目のゲームでは過去にどんな選択をしたかに限らずに最適な行動である「自白」する行動をとります。
  • (T-1)回目のゲームでは、T回目のゲームを予想した上で、過去にどんな選択をしたかに限らずに最適な行動である「自白」する行動をとります。
  • ... (以下、1回目まで続く)

このように帰納的に考えることで、各囚人は「自白」する選択を取り続けることになります。
このことから改善のジレンマにおいても「改善活動をしない」ことを続けることが最善手になります。…いいのかコレ?

無限回の繰り返しゲーム

ゲームの回数が決まっている「有限回の繰り返しゲーム」では、協力を達成できません。しかし、恒常的な作業が「T回で終わる」という感覚をもっている人はほとんどいないと思います。改善活動などは「終わりがない」と考えている人がほとんどの筈です。そのため、より現実の感覚に近いゲームである「無限回の繰り返しゲーム」を元に「改善のジレンマ」の対応策を考えていきます。

「無限回の繰り返しゲーム」では、「有限回の繰り返しゲーム」のように一番最後のゲームから考えることができません。そのため、将来どのような結果になるかを予想する必要があります。その際、「将来得られる価値をどのように考えるか」によって結果が変わります。囚人のジレンマを例にして整理します。

  • ある囚人の「将来得られる価値」が「今得られる価値」より十分に低い場合、協力して「黙認」し続けることによる価値が低いため、現在の最適回が得られる「自白」することを選択します。
  • ある囚人の「将来得られる価値」が「今得られる価値」とほとんど変わらない場合、協力して「黙認」し続けることにより将来的に大きな価値が見込めるため、(戦略によっては)「黙認」することを選択します。

このことから、「将来得られる価値を重視する長期的な視野を持つもの同士なら協力を達成できる」と言えます。

改善の勘所

「無限回の繰り返しゲーム」では、「長期的な視野を持つプレイヤー同士」なら「協力が達成できる」とあります。つまり、「あなた以外が改善活動をする」ためには、「あなたが改善活動をする」だけではなく、「あなた以外が改善活動によって得られる将来的な価値を重要視しているか」を確認する必要があります。

つまり、改善のために何より必要なことは「あなたが改善活動を続けること」ではなく、「あなた以外と改善活動の価値を共有しつづけること」になります。改善活動の価値が共有できていないのであれば、あなたが改善活動を続けたところであなた以外は改善活動をしてくれないですし、そのことに嫌気がさしてあなた自身の改善活動が止まってしまうかもしれません。

おわりに

前の記事でかいた1項目「アンチパターン?:個人の問題を技術で解決する」に対する考察になります。
同じことに価値を感じ続けられるチームが作れたらどれだけ嬉しいことだろう、と考えながら書きました。
那須のチームに対して、何が羨ましいと思うのか - toshimana's diary

今回はゲーム理論のなかでも「囚人のジレンマ」について取り上げましたが、ほかにもゲーム理論には面白い話がたくさんあるので、それと改善との対応を整理してみるのも面白いかと思います。

参考文献

以下の文献を参考にしました。「囚人のジレンマ」や「繰り返しゲーム」の話はこちらの文献を元にしています。内容を簡単にするためにゲーム理論については詳細な説明を省いているところがありますので、細かく知りたい方は勉強してみてください。

ゼミナール ゲーム理論入門

ゼミナール ゲーム理論入門

*1:この記事でのみ使っている造語です

那須のチームに対して、何が羨ましいと思うのか

2016/10/29(土)に行われた「ソフトウェアテスト勉強会~テスターと創る開発現場~」の参加レポートです。

東北デベロッパーズコミュニティ - イベント案内 | 2016-10-29 (土) ソフトウェアテスト勉強会~テスターと創る開発現場~

"テストの妖精"こと@miwa719さんと、"プロの無職"こと@m_sekiさんに彼らの開発現場について語っていただきました。

私たちの開発現場:@miwa719
speakerdeck.com

プロの前座(tohoku again):@m_seki
speakerdeck.com



JaSST東北2014で初めて彼らにお会いして以来、何度か話を伺っています。彼らの話はいつも刺激的で、彼らのような開発現場をいつも羨ましく思って聞いています。彼らのチームは、私が知る限りにおいて"最高のチーム"を実現したようなチームだと感じています。

ふと、自分は彼らのチームの何を羨ましく思っているのだろうかと考えました。そこで今回は彼らのチームの何が凄いのか、何が羨ましいのかを整理してみました。

彼らのチームの何が凄いのか

2時間という時間がアッという間に過ぎるほど、今回も素晴らしい活動をたくさん話していただきました。

開発とテストが分かれていない

ソフトウェア開発はV字モデルに従って行われることが多いです。そのため、テストは"開発物が仕様通りに動くかどうか"を確認することになりがちです。しかし、彼らのチームは開発時にテストの設計も行います。テストの観点から開発設計に対して指摘をすることもよくあるそうです。また、テスターがあらかじめどのようなことを重点的にテストしたいかを伝えておくことで、開発者がその部分を意識するためバグを減らすことができているそうです。

忍者式テスト

過去のチケットを含めて毎日少量ずつテストを実施するという@m_sekiさん考案のテスト技法。テストを実施するチケットは一定期間ですべてのチケットが回るように工夫してあるとか。忍者式テスト自体は何度かお話伺ったことがありますが、てっきり"若いシステム"に対して有効な手段だと思ってました。今回、対象のシステムが15年以上のシステムだとの話を聞いて、軽く戦慄しています。

テストケースのメンテナンス

仕様が変更になった時、対象となるテストケースは同時期に修正されるのが一般的です。しかし、彼らのチームでは、テストケースの修正は気付いた時に実施するそうです。膨大なテストケースに対して、必要な変更をすべて洗い出すことに膨大な時間がかかることを理解しているからこその対応です。また忍者式テストによって、彼らのチームはすべてのチケットが一定期間で回り続けます。そのため、チケットが仕様変更の対象かどうか気付く機会が多いため、テストケースを適宜修正しても問題が起きないのだと思います。

彼らのチームの何が羨ましいのか

彼らの話を聞くたびに、「彼らは最高のチームである」と感じますし、「彼らのようなチームで働きたい」と感じます。そんな羨望の理由を自分なりに整理してみます。

何が"最高"なのか

彼らのチームは理想的な働き方を体現しています。彼ら以上に理想的な働き方ができているチームは知らないため、"最高のチーム"だと思っていますが、その漠然とした"最高"が何なのかをもう少し明確にしてみます。

  • 技術が"最高"なのか

@m_sekiさんは一流の開発者ですし、@miwa719さんは一流のテスターであることは疑いようがありません。彼らがとても高い技術を持っていることは間違いがありませんが、彼らの技術に対して羨ましいと思っているわけではなさそうです。ことソフトウェアテストの分野で彼らに接する限り、技術を前面に押している印象はありません。もちろん彼らの活動が高い技術によって支えられている部分があるのですが、技術に関して言えばもっと技術を前面に押し出している人がいると考えています。そのため、自分が感じている"最高"は技術ではないのでしょう。

  • 品質が"最高"なのか

彼らの活動から"品質が低いものができるはずがない"と確信しています。全員が良いものを作るために同じ方向を向いている彼らのチームは"最高"の品質を作りこめるレベルだと思います。しかし、彼らの製品は一般消費者向けではないので、自分が彼らの品質を体感できる機会はほぼありません。そのため、自分が感じている"最高"は品質ではないのでしょう。

最高のチームワーク

彼らのチームは、誰かの問題を自分の問題として真剣に向き合ってくれるメンバーで構成されています。トラブルが起きた時でもを全員の問題として捉え、知恵を出し合い、そのチームの中での最善手を選び続けているのだと思います。そんなところを羨ましいと感じています。

彼らのチームは、完璧なものなどないことを理解した上で、それでも理想に向かうために改善策を出し続けています。人はミスをしますし、完璧な成果物を作成することは不可能です。そのうえで、ミスを減らすにはどうすればいいのか、ミスが起きたことにどうやって早く気付くか、に注力しているように思います。そんなところが羨ましいと感じています。

そんな彼らのチームの「誰かの問題を全員の問題として捉え、知恵を出し合える」「人はミスをするという当たり前のことを当たり前のように受け入れ、その上で理想に向かうために変化し続ける」チームが羨ましいです。彼らのチームは私にとって"最高"に理想的な、最高のチームワークを持っているのだと思います。

どうすれば彼らのチームを超えられるのか

彼らのチームのどのようなところが羨ましいかが分かれば、それに対して自分たちにどのような改善が必要かが見えてきます。千里の道も一歩から。彼らのチームと自分のチームの差が千里あるとして、その一歩先を行くために、今の一歩を踏み出さないといけません。

  • チームで問題を出し合える環境を作る

「言うは易し、行うは難し」の最たる例です。チーム内で問題を言い合おうとしても中々出てきません。出てきた問題を他人事に捉えられたり、問題を出したことで責められたり、そもそも自分の時間が惜しくて他人の話を聞くことに消極的になったり。話す側も聞く側も問題を出し合うことにメリットを感じにくいです。実際は良いものを作るうえでは必要でメリットが多いのだけど。
具体策はまだありませんが、ポイントは「心理的安全性」と「チームがどこを向いているか」あたりでしょうか。

  • 現実に対して素直になる

完璧な環境で仕事をする。理想的かもしれませんが、現実にはそんな環境はありません。問題は「自分がうまくいかないのは、理想的な環境ではないから」だと責任を転嫁してしまい動けなくなってしまうことです。自分も他人も含め誰だってミスはしますし、出てきた成果に完璧なものなんてありません。それらから目を逸らさずに、その現実を踏まえた上で改善する方法を考え続けないといけません。

今回の考えを整理していて、最高のチームを作るうえで(IT的)技術そのものが重要ではないように感じました。求めるべきはチーム全員が一つの問題に向き合える環境であって、技術の高さではないかなと思います。では、技術が不要なのかというとそうではなく、チームの問題を解決するために技術が必要になる場面は必ず出てきます。チームの問題に昇華できていない個人の問題を技術で解決しようとすると、認識違いが起きてしまい、チームに良くない影響があるかもしれません。程度によると思いますが。
解決したい問題があったら、まずチームの問題として昇華してから解決する。その方針が良さそうかな、と思います。

まとめ

@miwa719さんと@m_sekiさんの開発現場は本当に魅力的で、話を聞くたび一緒に働かせてもらいたいと思います。そんな理想的な彼らのチームが何を大事にしているのかを理解して、自分でも同じところを大事にできると彼らのような理想的な開発現場が築けるのかな、と思います。

2016/7/23(土)「VSTeP勉強会(仮)」:テストフレーム設計

JaSST東北実行委員による、VSTePの勉強会を実施しました。
VSTePをテーマとした、JaSST'16東北は2016/5/20に完了しています。しかし、「まだ俺たちはVSTePを十分に理解していない」という考えのもと、実行委員で集まって勉強会を開催しました。

今回のテーマは「テストフレーム」です。JaSST東北のワークショップでは、チーム内の考えを揃える「テスト観点図」、テストの戦略を検討する「テストコンテナ」を扱いました。しかし、具体的なテストケースを生成するための準備に相当する「テストフレーム」はワークショップでは扱いませんでした。そのため、テストフレーム設計まで実施して、テストケースまで生成できるようになることが今回の目的でした。

テストフレーム設計を実践してみて理解したことをまとめます。実行委員のみで検討した内容になりますので、実際のVSTePの意図とは異なるかもしれませんが参考まで。

  • テストフレームの構成要素により、抽象的なテストケースが生成できる
  • テストケースにおけるテスト条件、テスト対象、振る舞い
  • 同じテストフレームでも異なるテストが作成できる
  • テストフレームはテスト観点をまとめたもの

参考資料:
http://qualab.jp/materials/VSTeP.130510.color.pdf

テストフレームの構成要素により、抽象的なテストケースが生成できる

テストフレームとは「テストケースの構造(スケルトン)をテスト観点の組み合わせで示す」もの。
例えば、解凍ソフトというテーマがあったとして、以下のようなテスト観点から構築されるテストフレームがあったとする。

  • 環境(OS)
  • ファイル(ファイル名、ファイル数)
  • トリガ(ドラッグ&ドロップ、GUIからの指定)
  • 解凍(圧縮前と解凍後のファイルが一致)

このテストフレームからは「<環境>において、<ファイル>を<トリガ>によって<解凍>することを確認する」という抽象的なテストケースを作成することができる。
具体的なテストケースでは、このテスト観点に当たるところに具体的な値を入れればよい。

テストケースにおけるテスト条件、テスト対象、振る舞い

テストフレームにおけるテスト観点は大きく3つに分類される。テストフレームに現れたテスト観点は必ずしも全ての項目を組み合わせでテストしなければならないわけではない。

  • テスト条件

テストケースにおけるインプットに当たる。そのテストにおいて、網羅されるもの。あるテストフレームからテストを生成する際に、パターンを試したいものを示す。

  • テスト対象

テストケースにおけるインプットに当たる。そのテストにおいて、テストしたいもの。あるテストフレームからテストを生成する際に、変化しないものを示す。

  • 振る舞い

テストケースにおけるアウトプットに当たる。そのテストにおいて、期待される結果。あるテストフレームからテストを生成する際に、確認したいものを示す。

同じテストフレームでも異なるテストが作成できる

何をテストしたいかによって、同じテストフレームでも異なるテストケースを作ることができる。テストフレームにおいて、各テスト観点をテスト条件、テスト対象、振る舞いのいずれかに割り当てることによって、生成できるテストが異なる。

  • どんな解凍方法でも適切に解凍できることをテストしたい

テスト条件:トリガ
テスト対象:環境、ファイル
振る舞い:解凍

  • どんな環境でも適切に解凍できることをテストしたい

テスト条件:環境
テスト対象:ファイル、トリガ
振る舞い:解凍


上記は一例。「GUIの挙動はOSに依存するから、環境とトリガをテスト条件にして、組み合わせテストしたい」というものも可能です。設定の仕方はテストエンジニアのうで次第。

テストフレームはテスト観点をまとめたもの

テスト観点図からテストコンテナを生成する。テストコンテナでどんなテストを実施したいかを定めた後に、詳細なテストフレームを設計する。テストコンテナで大まかにテスト観点をまとめるが、ここで集まったテスト観点は粗い粒度でのテストフレーム構築に相当する。粗い粒度のテストフレームから、テストしたいことに合わせて詳細なテストフレームを生成する。
例えば、「環境はOSの他にCPUやメモリ搭載量などもあるが、OSに限定してテストフレームを生成する」などが挙げられる。


感想

テストフレームの考え方を理解することにより、テストコンテナの重要性を理解することができた。詳細なテストフレームの作成には、何をテストしたいを明確にする必要がある。テストしたいことが定まっていないと詳細なテストフレームを生成することができず、意味のあるテストケースが生成できない。

組み込み開発にMVCは使えるか?

WACATE名物と言っても過言ではない「夜の分科会」の二次会で、モデリングの話し合いをしてきました。その中で、「組み込み開発にMVCは使えるか」という話が出たのでまとめます。基本的に自分の主観を語っています。異論は認めます。
toshimana.hatenablog.com

はじめに

MVCについて勘違いをしていました。正しい理解は以下のリンクなどを参考にしてください。
at-grandpa.hatenablog.jp

私の理解では、MVCのMはシステムロジックという理解は正しかったのですが、View-Controllerについて勘違いしていました。Viewをシステム外部とのやり取り全般、ControllerはViewとModelの橋渡しだと勘違いしていました。正しくはViewは表示(システム外部への出力)、Controllerは(システム外部からの入力)になります。WACATEでは自分が誤った理解で話をしていたので、ここで修正しておきます。

組み込み開発にMVCは使えるか

MVCはWeb業界で広まった印象があるため、「MVCGUIがあるシステム向けのデザインパターン」というイメージがあると思っています。Viewが表示、Controllerが操作であれば、GUIがない組み込み開発であれば、使い道がない印象を受けます。
私のイメージではViewはシステム外部への出力、Controllerはシステム外部からの入力となります。そのように解釈すると組み込みデバイスへの出力はViewで、組み込みデバイスからの入力はControllerで表現できます。ViewとConntrollerは強く依存していることが多いため、分離しない方がいいことが多そうですが。
ViewやControllerという言葉のイメージだと組み込み開発には使いにくいイメージがありますが、デバイスとの入出力をViewやControllerで表現する事でMVCを組み込みに活かすことができます。

MVCは1システム1つでなくても良い。

組み込みMVCで考えた場合、各デバイスに関する操作をサブシステムとしてMVCを用意した方が分かりやすい、という話をしました。例えばエアコンシステムの場合、エアコン本体をMVCで設計し、リモコンを別のMVCとして設計します。その2つのやり取りは統合したModelとして扱うと良いのではないか、と考えました。@dproject21さんの話では、統合したModelをサービス層と表現していました。

バイス処理の抽象化

ControllerからModelに操作を渡す場合、処理の抽象度を変えた方が良いと思います。リモコンを例にすると、Controllerでは「電源ボタンを押す」操作を扱い、Modelでは「電源ON/OFF」という抽象化したイベントとして扱う方が良いと考えています。

MVCでデータベースはどれに該当するのか

Web開発では欠かせないデータベースですが、MVCではどれに該当するか、という話が出ました。
データベースはViewもしくはControllerに該当すると考えています。システムで管理できる状態はModelで、管理できない状態はViewもしくはControllerで扱うべき、と考えています。データベースはその中に格納されているデータをシステムでは保持しません。必要に応じて、システムがデータベースに問い合わせるため、その問い合わせはViewもしくはControllerで表現されるべきだと考えています。

まとめ

組み込みでMVCは使える。ETロボコンとかで証明できるといいな。
お話しの発端はWACATEだけど、こういう開発よりの話は大好物なので、楽しかったです。