モブプロ始めました

引っ越しやらで更新できていませんでした（言い訳）

今回は、最近チームでモブワークを始めたのでそのきっかけと内容について書きます。

きっかけ

ただ集まっているだけのチーム

今までうちのチームはプロダクトの担当を個人ごとに行っていました。そのため、同じチームですが、お互いのやっていることにはあまり関心や理解が乏しく、チームで仕事をしている感じではなかったです。そのため、何か問題が発生したとき、自分の担当範囲ではない内容だとスルーな傾向が強かったです。ここに強く責任が分散している状態でした。

個人のスキルの差が大きい

個人でプロダクトを担当するので、人のやっている内容の知識・スキルはほとんど共有されていません。以前チームメンバーでスキルマップを作ってみたら、見事にそれぞれのスキルが個人ごとにしか蓄積されていませんでした。悪くはないのかもしれませんが、やはり問題があったときに対応できる人が１人しかいないのは精神的にもしんどいですね。

モブワークとの出会い

実際はこれが一番大きかったかもしれません。上記のような問題は抱えていましたが、案がありませんでした。そんな中、TAKAKING22さんのスライドを見つけました。最初の感想は「楽しそう！」でした。また、私が抱えている問題を解決できるのもまさにモブだ！と思いました。

導入まで

導入しようと思ってから導入までは実はそんなに障壁はありませんでした。さすがに最初に紹介したときは、働き方が大きく変わるので「良いのはわかるけど・・・できないよね」といった感じでした。それから数週間たったある日、ミーティングか何かの時に、ちょうど「うちらって個人に責任が偏ってるよね」という話になり、すかさず「モブなら～～」という話をすると「あーたしかに。いいね！」という流れで、次週からモブを始めることになりました。

導入に当たっては、とりあえずやってみようということだったので、時間や進め方などを概ね決めるだけで始められました。うちのチームなかなか良い感じ。

導入してから

やはりいざ始めると、環境の問題（PCや社内環境）や業務の進め方（個人の業務はいつやるのか）などありました。ただ、そこらへんを差し置いて、「スキルの共有」「責任の分散」「楽しい！」という効果が目に見えて発揮できており、私は相当満足しています。メンバーもいいですねとは言ってくれているので、このまま進められそうです。

特に「責任の分散」のところが、まさに「問題ｖｓチーム」の構図になることが効果を発揮しています。今までは個人で抱えてたので、やはりプレッシャーもあるし、自分一人で担当していると「自分ｖｓ他のメンバー」の意識になりやすかったです。それが「問題ｖｓチーム」になることで、精神的にかなり楽に立ち向かえます。（既にそう実感できてます！）

不安な課題

個人の時間

やはりどうしても個人の仕事は発生するので、その時間はいつするのかという課題はあります。一日のスケジュールは午前中は個人時間、午後からモブとし、モブへの出入りは自由にしています。それによりだいぶ問題は緩和されていますが、今までと仕事の進め方が異なるので、チームとしてはそういった不安があります。まだ問題にはなっていませんが。

みんなで一つの仕事に取り組む体制への不安

チームとして並行して業務を進められないので、やはりそこの不安はあります。チームで問題を片づけるので、出力の早さは実感していますが、全く手がついていない業務があるのも事実です。これはどちらかといえばスケジューリングとか業務の優先順位の決め方の問題かとも思っています。いままでのスケジュールは週単位でざっくり決めていたので、かなりラフなスケジュールでした。しかしモブでやっている以上、「今日何をするのか」をきちんと決めていないと、リカバリーや手戻りの影響は大きいと思っています。（そういうときは分担してもいいのかもしれませんね）

以上が導入してみた感想です。

とにかく楽しく仕事ができて、効果を実感できるのでかなり良いです。働き方が大きく変わるので、それを許容できるチームな必要はあるかもしれません。今のメンバーには感謝ですね。引き続きモブワークをしていきます。

テスコンU-30チュートリアルに参加しました。

テスコンには参加しませんが、テストに関するスキルアップのため参加しました。もともとは資料を眺めているだけでしたが、同僚とテストの話をするときに資料を参考に説明をしていると、ふと「この説明であっているのだろうか」と不安になったため、この資料でどんな話をしているのか気になったので参加することにしました。

当日のチュートリアルに参加して

以下、口頭で説明されていた部分で、私がポイントだと思った点や気づいた点です。

（※理解がずれている内容もあるかもしれません）

本チュートリアルは、いかにいいテストをするためにどうするかを考えるもの

テスト技法が出てくるのは、具体的にテストケースを作るとき（工程としては最後のほう）

私にとっては新しい知見でした。今まではテスト＝同値分割！ブラックボックス！みたいな感じでした。「テスト設計」を考えると、技法についての検討はもう少し先なのは納得しました。

ワークショップにて

ワークショップで、結果を共有したときにマインドマップで検討している方がおられて、そういうツールがすんなり出てくるあたりすごいなぁと思いました。

バグが出ることがテストの価値ではない。テストしたからバグが出ないことがわかる。そのためにどんなテストをしたか説明できないといけない。

これまでの取り組みでは「テストでバグを見つける」ことを意識しすぎていたかもしれません。「バグがない」ことを知るためにもテストが必要ですもんね。

膨大なテストケースはレビューできない。テスト観点で構造化すればレビューしやすくなる。

これはチームでも何となく問題に思ってた点です。今のテスト仕様書はただの羅列でただただ数が多い。今のテスト仕様書を構造化する取り組みから始めてもいいかも。

制御パス・手順もテスト値に含まれる

今まで操作手順によるテストってアドホック的にしか考えてなく、それが「テスト値」という考えすらなかったです。テスト値と考えると、いろいろなテスト技法も活用できそうですし、ちょっと考え方が広がりそうな感触がありました。

感想

チュートリアルで具体的なイメージが付きやすい話が聞けたので、聞いておいてよ良かったです。また、スライドも十分わかりやすくまとめてあるので、理解に大きなずれはなかったかなと思います。

後日談

このチュートリアルに参加したあと、社内のメンバーにも共有を行いました。

共有するにあたり、以下の点に重点を置いて共有しました。

• まずは「テスト観点」という考え方を理解してもらうこと

• ”チームで考える”ことに意味があること

• テストにも開発と同様にプロセスがあること

主な反応としては、以下のような感じでした。

• テストを構造化すればいいことはわかった

• なんとなく雰囲気はわかるが、実際にどうすればいいのかもやもやする

• とりあえず何かで試してみたい

私が理解した程度で話をしたので、十分に伝えられたかはわかりませんが、雰囲気は掴んでもらえたようです。特にチーム内で、今までの羅列していたテストよりもこっちのほうが良くなりそう、という感触を得られたのでよかったかなと思います。

 これから実際に手を動かしてみるフェーズに入ります。テストについてはノウハウがほとんどないので、手探りの状態であり不安はありますが、テスト開発のサイクルを回してみてどうなるのかを試してみたいと思います。

カイゼンジャーニーを読んで

以前からTwitterのTLで流れていたので、気にはなっていました。

たまたま本屋に寄った時に見つけたので、少し立ち読みしたところ、まさかのストーリ仕立ての本で驚きました。しかも、最初は一人で改善に立ち上がるところから始まり、様々なマネジメント手法を用いながら、”越境”に取り組む姿が描かれています。

数ページで見ただけで購入を決意するほど、一気に引き込まれました。ちょうどその時、私も現在の仕事の進め方・チームの取り組み方には課題を感じていたので、勉強になる部分が多かったです。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

どんな本か？

会社を変える決意をした主人公が、たまたま参加したカンファレンスの登壇者から突き付けられた「あなたは何をしている人ですか」という言葉。主人公は会社の問題点を愚痴っていただけで、実際には何もしていないことに気づく。そこから主人公は、一人で改善に取り組みはじめ、その取り組みが徐々にチームに波及していく物語。

”カンバン”　”スクラム”　”インセプションデッキ”　”KPT”などなど、様々なプラクティスが紹介されています。ストーリーに応じて、その場で適切な手法が説明されるので、適用するタイミングのイメージが湧きやすいです。

印象に残った点

他の人に気づかせてもらう

”一人で”仕事の振り返りをしていた主人公ですが、振り返りの内容が芳しくありません。自分の経験や思考だけの振り返りでは、自分自身が限界になることに気づきます。「他の人に気づかせてもらうんだ。自分で気づけないのはどうしようもない。」ということに気づき、”チームで”の振り返りの必要性に気づいた瞬間です。

スクラム

スクラムについては、聞いたことがある程度でどんな内容かを全く知りませんでした。本書ではストーリーに沿ってスクラムのフェーズが進むため、スクラムのイメージが湧きやすかったです。

プラクティスの多さ

とにかく紹介されているプラクティスが多いので、改善手法、マネジメント手法についてあまり知識が無いにはとても良いと思います。（私がそうだった）

やってみたいことがたくさんあって、新しい手法が出るたびにわくわくして読むことができました。

実際に取り組みたい・取り組み始めた事柄

タスクマネジメントや振り返りなどの手法にはめちゃめちゃ疎かったんで、本書で紹介されている内容は参考になりました。

私が始めてみた手法、およびこれからやっていきたい手法を紹介します。

一人朝会・タスクボード

一人で朝会をはじめ、Trelloでタスクボードによるタスクマネジメントを行うようにしました。早速効果があり、本書で紹介されているように「今日のタスクマネジメントは、明日のタスクマネジメントでもあります」。どの作業を後に回せるか、どれだけバックログがあるかが見えるだけで、作業に計画性が出てきたように思います。これは今後も続けていきたいと思ってます。

KPTによる振り返り

これも今はTrelloでボードを作成してます。きちんとした振り返りはできていません。しかし、KPTをすることを意識しているので、日ごろの作業に対する進め方の問題点を意識するようになりました。もう少し継続して、振り返りのリズムが作れるように進めていきたいです。

ドラッカー風エクササイズ

これはやりたいことです。今のチームは、お互いのことをきちんと話したこともないので、腹の探り合いをしているところもある状況です。（仲が悪いわけではない）

お互いがお互いを理解して、スムーズなコミュニケーションをとれるチームを目指してみたいです。

ファイブフィンガー

これもやりたいことです。私のチームでは個人の感じている問題点が共有できていません。進捗、スケジュール感に関しても、実際のメンバーはどう思っているかを話せる場もあまりありません。ファイブフィンガーで気軽に共有できる場づくりをしていきたいです。

まとめ

これから改善に取り組みたい人や、何か課題は感じているけど、取り組み方が分からない人は、一度この書籍を読んでみてはいかがでしょうか。必ず何かヒントは得られると思います。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

「時間がなくてできません」

仕事でよく聞く言葉です。特に私の周りでは、品質とのトレードオフのように使われます。（テストする時間がありません。確認する時間がなかったです。など）
この言葉について思うことを記事にします。

時間があればできるのか

少し前にTwitterか何かで、「時間が無いことを言い訳にする人は、時間があってもできない」のような趣旨のツイートを見ました。（引用出来なくて申し訳無いです）
私もそう思います。「時間がないからできない」というよりは「品質の確認をする時間を取ろうとしてない」のではと思います。どれだけ切羽詰まろうとも、致命的になる部分の確認は怠るのは良くないと思います。というか、そこは品質というより設計の範疇です。

時間があっても不具合はなくならない

どれだけ時間があっても、不具合はゼロにはできません。むしろ、有限な時間でどれだけ致命的な不具合を検出しておけるかが焦点になります。（特に時間が限られているときは尚更）
発生した不具合はどれだけ致命的だったのか。その確認もなく、頭ごなしに「不具合はダメ！」と言われてもどうしようもないっすね…。

時間を浪費しないように

そもそも、品質を確保するための手段が確立されていますか。手当たり次第にやっても時間を浪費するだけです。「どういうところが致命的なのか」「複雑な仕様はとこか」など、プロダクトに対して理解を深めておくことが重要です。

「時間がなくてできません」

むしろ時間があるときのほうが珍しいはずです。時間がない中で、どこまで確認できてどこはできないのか、その目安をつけておくことが重要です。

おわりに

時間がないときにいろいろ言われると腹立ちますよね。なるべく日頃からこの辺りの意識はチームで揃えたほうが良いと思います。みんな余裕無くなってくるとこういうところで衝突が起こるので。
（特に何かあったわけではありません！念の為。）

追記(2018/11/18)

改めて自分で読むと、なんとなく「時間がないことを言い訳にするな」みたいに見えてきた。
マネージャー含め全体で意識を合わせないと、不具合出てから本人責めてもどうしようもないし、逆にチームとしてその不具合でそうなやばさを検出できないとだめですよね。
何をどうしたいのか、具体的な考えはまだありませんが・・・。

GoogleTestのパラメータテストについて

業務でGoogleTestを使ってテストを書いています。導入したはいいものの、レガシーコードに対してテストを書いているということもあり、進捗がいまいちです。また、不慣れな点も多く手探りな状態で使っています。

今回は、パラメータテストをしていた時に「このパターンどうやって書くんだろ」と思ったので、その内容を記事にします。

パラメータテストの書き方

本題の前にパラメータテストの書き方です。

公式ドキュメントなど以下の記事を参考に書いたので、目新しいことはしていませんので、記事の紹介のみで割愛します。

• 上級ガイド — Google Test ドキュメント日本語訳
• Google Testで「値をパラメータ化したテスト」を試してみる：とりあえずやってみる：So-netブログ

• google-gtest: value parameterized testのCombineを使う - nobu-qの日記

複数のパラメータを設定するときにtupleを使うっていうのはめちゃめちゃ参考になりました。

書きたかったパターン

本題です。まず、私がやりたかったテストのパラメータは以下の通りです。（因子などは例です。）

テストパラメータ

モータ	スイッチ	設定
モータA	スイッチA	オフ
モータB	スイッチB	オン

上記のパラメータから以下の組み合わせのテストを行いたかったのです。combineを使用すれば普通にできるのですが、今回は、モータとスイッチの組み合わせは固定しておきたかったのです。（モータAのときはスイッチAだけをテストする。）

実行したい組み合わせ

モータ	スイッチ	設定
モータA	スイッチA	オフ
モータB	スイッチB	オフ
モータA	スイッチA	オン
モータB	スイッチB	オン

combineだとすべての組み合わせをテストしてしまうので、思ったパターンをテストできませんでした。

以下GoogleTestの一例。これだと、すべての組み合わせがテストされてしまう。

INSTANTIATE_TEST_CASE_P(
        TestData, 
        ParamTest,
        ::testing::Combine(::testing::ValueIn(motor),
                           ::testing::VaueIn(switch),
                           ::testing::Bool())
);

 対処した方法

 モータとスイッチの組み合わせを別の因子に置き換え、テストコード内でモータとスイッチを取得するようにしました。

テストパラメータ

ハード構成	設定
ハード構成A	オフ
ハード構成B	オン

ハード構成

ハード構成	モータ	スイッチ
ハード構成A	モータA	スイッチA
ハード構成B	モータB	スイッチB

テストの組み合わせは、ハード構成の番号と設定の組み合わせにする。

INSTANTIATE_TEST_CASE_P(
        TestData, 
        ParamTest,
        ::testing::Combine(::testing::ValueIn(hardware_no),
                           ::testing::Bool())
);

例えば、ハードの構成を配列などで事前にテストフィクスチャに定義しておけば、以下のような記述で、モータやスイッチを取得することができます。

TEST_P(ParamTest, test) {
    int hardware_no = std::tr1::get<0>(GetParam());
    bool setting = std::tr1::get<1>(GetParam());
    
    int motor_no = hardware[hardware_no].motor_no; 
    int switch_no = hardware[hardware_no].swtch_no; 
    
    ASSERT_EQ(...); 
}

おわりに

以上のやり方で、目的のパターンでテストすることができました。

「設定」の部分が２値なら、こんなことしなくてもテストケース羅列してもよかったのですが、結構組み合わせが多かったのでいろいろ模索しました。

（そもそもテストに対する知識不足は否めない。。。）

アウトプット大全を読んで

前回に引き続き、「学びを結果に変えるアウトプット大全 (Sanctuary books)」の感想です。読み終わったので、各チャプターの参考になった内容を紹介します。

チャプター２：話すこと

チャプター２ではアウトプットの１つである「話し方」についての内容です。私は発表や説明など、話すことが苦手なので、いろいろと参考になりました。

見た目や態度は、口ほどにものをいう

コミュニケーションには「言語的コミュニケーション」と「非言語的コミュニケーション」の２つにわけることができます。言語的コミュニケーションは、言葉の意味などそのままの意味です。非言語的コミュニケーションは、外見・表情・しぐさなど視覚的情報、声の調子・強弱などの聴覚情報を指します。

人は話を聞くときは、この非言語的コミュニケーションを重視しているそうです。そのため、「何を話すか」（言語的）と「どう話すか」（非言語的）を意識するとよいそうです。

私はよく緊張するので、発表や数人の前で説明するときは、おそらくこの非言語的コミュニケーションがうまくなく、説明が伝わりにくくなっているのだと痛感しました。（説明も下手なのは当然あると思いますが・・・）

「どう話すか」というポイントについては、実は考えたこともなかったので、今後は話し方を意識してみようと思います。

 チャプター３：書くこと

チャプター３は「書くこと」についてです。「書くことで記憶に残りやすくなる」という内容から、メモ・TODOリストの書き方など幅広く紹介されています。

要点をまとめて相手に伝える「要約力」

要約力が高い人は、相手の考えていることや伝えたいことをくみ取り、まとめ、言い換える能力が高いと言えます。この要約力を鍛えるためには、Twitterがおすすめされていました。１４０文字という制限がある中で、本の感想などを要約して投稿することを繰り返すことで、要約力がつくとの内容でした。

また、要約力が鍛えられることで「読解力」が鍛えられ、「読解力」が高いと「思考力」も高くなるそうです。

私は要約するのが苦手です。というよりは「相手にきちんと伝わるように」と思い長々と話す傾向にあります。今回の「書く」ということについても同じですね。ついつい長いメールなどを書いてしまいがちです。

今まであまり意識できていなかった「要約」を行ってみようと思います。Twitterもあまり投稿できていないので、もう少しアウトプットに活用していきたい・・・。

チャプター４：行動する

チャプター４は行動する、です。話す、書く以外のアウトプットはすべてこの行動するに当てはまります。続ける・教えるなどから笑う・泣くなど、インプットに対する「行動」はたくさんあるなあと気づかされました。

最強のアウトプット「教える」

本誌に乗っているすべての項目の中で、自己成長につながる最強のアウトプットを上げるとすると、この「教える」だそうです。人に教える前提で勉強をするだけで、記憶力がアップします。また、しっかりと理解していないと、教えることができません。そのため、自分の理解度が不十分な点が明確に見えてきます。

インプットしたことをアウトプット（教える）して、不明点などをフィードバックしてまたインプットする。これらが自己成長術、とのことでした。

 「教える」が最強のアウトプットというのは、言わずもがなですね。前回の感想でも触れましたが、教える前提でセミナーを受講すると、記憶力だけではなくて「理解しよう！」とするので、集中力も上がる気がします。

ただ、実際には教える機会って少ないんですよね。本書には自らそういう場を作ろう！という内容も紹介されています。輪読会などを開催したりしているので、その流れで勉強会的なことを開催してみようかなぁ。

まとめ

アウトプットを始めたばかりなので、参考になる部分はかなり多かったです。アウトプットってたいそうなことだと思ってましたが、むしろ小さなアウトプットを繰り返すことで鍛えていくべきなんだ、ということがわかりました。

小さなアウトプットのやり方の紹介もしてあるので、「アウトプットって何？」って人から「アウトプットをしているけど続けられない」と思っている人まで、幅広く読める本だと思います。

この本を読んで、読んだだけでアウトプットしてない本は記憶に残らないとあり、去年読んだ本を見返してみると、驚くほど覚えてませんでしたｗｗ

その辺の本も再度読み返して、簡単にTwitterで感想をあげたりしていきたいですね。

アウトプット大全を読んで（チャプター１）

最近、自己学習のためにアウトプットすることを意識しています。

今回紹介する「学びを結果に変えるアウトプット大全 (Sanctuary books)」をたまたまAmazonで見つけ、ちょうどタイミングもよかったので購入しました。

まだすべてを読んでいませんが、チャプター１について紹介したいと思います。

アウトプットの基本法則

チャプター１には、

• アウトプットの定義
• アウトプットの基本法則
• アウトプットのメリット

が主に記されております。

その中から特に共感したポイントを２つ紹介します。

インプットは脳内世界が変わる。アウトプットでは現実世界が変わる。

セミナーや読書によるインプットを行えば、知識が増え脳内世界が変わる。しかし、その知識を活用して何かを実行（アウトプット）しなければ現実世界を変えることはできない。という内容です。

少し内容は異なりますが「わかってても、やってみたらできない」みたいなこと、平気でよくありますよね。脳内に知識をためておくだけではなくて、実際に活用してスキルにしていかないと、本当に必要な時に力を発揮できずに意味ないよなあ、と思いました。

成長曲線はアウトプットの量で決まる

１０冊本を読んで１冊もアウトプットをしない人より、３冊読んで３冊アウトプットする人のほうが成長する。自己成長の量はアウトプットに比例する。という内容です。

私も今まで受講したセミナーなどで、周りに内容を紹介したほうがよく覚えてます。というか、周りに紹介しよう！と思って受けたセミナーのほうが理解しようという気持ちが強かったかもしれません。当然、アウトプットことでよい効果がありますが、その前の段階（受講するときの意識）から変わることができそうだな、と思いました。

今までは漠然と「アウトプットしたほうがいいんだろうなー」と思ってました。本書を読むことで、アウトプットの重要性を明確に確認することができそうです。残りの部分も読み進めて、アウトプットしていきたいと思います！

学びを結果に変えるアウトプット大全 (Sanctuary books)