Fun Done Learn
はじめてのアドベントカレンダーの12/19のエントリです。
スクラムトゥギャザーリングのときに川口さんから教えてもらった新しいふりかえりの方法が面白かったので、やり方をまとめておきます。またKPTの違いについて少し考えてみました。(以下の写真はスクラムトゥギャザーリングのふりかえり時のもの)
やり方
- Fun Done Learnのベン図を書く
- 付箋にFun Done Learnと思うものを書いてはりつける
- チームの皆で話ながら、ベン図のどこにあたるかを確認していく(位置をずらしていく)
Fun Done Learnの特長
感情のFunが入っている
カイゼンをするときは事実に目を向け、、、と思ってきました。でもこのふりかえりには『楽しさ』を表すFunが入ってます!ゲーミフィケーションが好きな自分にはしっくりきました。何事も楽しくないと続かないですよね!
ネガティブにならない
KPTの場合はProblem→Tryに集中してしまうことが多く、一歩間違うと犯人捜しが始まります。一方、Fun Done Learnは全てのワードがポジティブなイメージを持っているため、ダークサイドに落ちにくいと感じています。 KPTのProblemはLearn=Problem+Tryの形で出てくることが多く、次にどうしたら良いかという未来へつながる思考になることが多いと感じています。
何度も話す機会がある
ベン図上で付箋を貼り替えていくため、何度も付箋に書かれていることに触れることになります。 ポジティブな言葉で書かれているため、チームの自信を深め、信頼を深める効果があると思います。 牛で言うと反芻ですね。
使いどころ
Fun Done Learnはどこでも使えると思いますが、個人的には以下の場合の効果が高そうだと思っています。
- ふりかえり自体をやったことがない場合
- かけだしのチームなどまだお互いの信頼感が薄い場合
- 初めてのことに挑戦した場合
- チームの雰囲気が落ち込んでいる場合
- Problemで犯人捜しが始まることが多い場合
川口さん、ありがとうございました!
境界の仕様
ソフトウェアテストの#2のアドベントカレンダーの12/16のエントリになります。
今回は自分がやらかしてしまった境界の仕様の話をしようと思います。
あるセンサーのデータを収集する機能があります。 そのままデータ収集を続けるとデータが多くなって、DBの容量がいっぱいになりますので、沢山たまったデータを削除するパージという機能が必要です。 それではそのパージの機能ですが、どちらの仕様(コード)が良いでしょうか? ※ここでは仕様に沿ってコードが実装されると仮定しています。
ID | 仕様 | 条件の疑似コード例 |
---|---|---|
A0 | ある日付より前のデータは消す | date < "2018/12/11" |
B0 | ある日付以前のデータは消す | date <= "2018/12/10" |
もちろんどちらでも大丈夫そうに見えますね。 dateは日付なのでどちらも期待通りに動作します。
さて、ここに時間の概念が入ってきたらどうなるでしょうか?
ID | 仕様 | 条件の疑似コード例 |
---|---|---|
A1 | ある日時より前のデータは消す | dateTime < "2018/12/11 00:00:00" |
B1 | ある日時以前のデータは消す | dateTime <= "2018/12/10 00:00:00" |
あれ?B1のパターンは2018/12/10 12:00:00のデータが消えないというバグがありそうですね。 これを期待通りに動作するように変更すると以下のようになります。
ID | 仕様 | 条件の疑似コード例 |
---|---|---|
A2 | ある日時より前のデータは消す | dateTime < "2018/12/11 00:00:00" |
B2 | ある日時以前のデータは消す | dateTime <= "2018/12/10 23:59:59" |
23:59:59なんて何か嫌な感じですね。
さて、さらにミリ秒の概念が入ってきたらどうでしょうか?
ID | 仕様 | 条件の疑似コード例 |
---|---|---|
A3 | ある日時より前のデータは消す | dateTime < "2018/12/11 00:00:00.000" |
B3 | ある日時以前のデータは消す | dateTime <= "2018/12/10 23:59:59.999" |
ここまで来るとだんだんわかってきますね。 日付というのは実は範囲を持っていて、2018/12/10 00:00:00.000 から 2018/12/10 23:59:59.999…(省略)になります。 仕様作成時、コード実装次に、以下の図の●と○の中間をちょっと考えることで変更に強い仕様やコードになると思います。
ちなみに自分が埋め込んだバグは 以前の仕様に則って、<=を使用し、
dateTime <= "2018/12/10 23:59:59.999"
と実装したのですが、小数点以下がなんと6桁のケースもありました >< すなわち、2018/12/10 23:59:59.999001 ~ 2018/12/10 23:59:59.999999が削除されないことになります。 レビュー指摘されて、事なきを得ましたが危なかったですねぇ。
新世界 読了
初めてのアドベントカレンダーの12/14のエントリです
キンコン西野さんの本を会社の先輩から借りたので読んでみました。 好き嫌いがかなり分かれる人だと思いますが、自分は西野さん好き派ですね。 東京のプペルの展覧会も行きました。
- 作者: 西野亮廣
- 出版社/メーカー: KADOKAWA
- 発売日: 2018/11/16
- メディア: 単行本
- この商品を含むブログ (2件) を見る
この本では「信用」と「お金」の話が出てきます。
- どのように信用を積み上げるのか
- どのように信用をお金に変えるのか
- これからの世界はどうなっていくのか
色々な話が西野さんの視点と具体例を交えながら書かれています。 文もサクサクと読めるし、内容も面白いです。
自分的には特に興味をひかれたのは、文字数に応じて文字をお金のように扱うレターポットというサービス。 100レターを500円で買って、特定の宛先に送れるような仕組み。 例えば、被災地へ応援メッセージを送ることで、その文字数に応じて被災地の義援金になります。 実際に2018年の西日本豪雨では、135万円が岡山へ寄付されたとのことです。 発想とか考え方が既に面白いですね。
西野さんがレターポットのサービスから気づいたことが書かれているのですが、それにハッとしたので書き留めておきます。
ボクらは、使える文字に制限があると、わざわざ誰かを傷つけるようなことに文字を割かない。 たとえばキミの手元に、あと20文字しか残されていなければ、キミはその文字を大切な人に贈るだろう。 元来、言葉は美しい。 言葉を汚している原因は、「文字」が無尽蔵に発行できてしまうことと、そこからくるボクらの甘えだと知った。
言葉、、、気を付けようっと。
量を質に変えるキーポイント
アドベントカレンダーの12/9のエントリです
量をこなすことで質に変わる、すなわち何かを沢山やることで上達するというのはほんとにそうなのでしょうか?
量を質に変えるにはキーポイントが存在すると考えています。それは何かと言うと、『意識をしながら量をこなす』ことです。
自分は幼稚園の時から大学1年の時まで毎年スキーを滑っていました。もちろん滑るだけならだいたいどこでも滑れましたが、技術的には上手くなかったです。大学2年からは流行っていたスノーボードを滑るようになりました。*1 社会人になって5年目くらいのときに、知り合いのスキー大好きオジさんに誘われて、久しぶりにスキーを滑ることになりました。そのときにカービングのポイントである「角付け」、「荷重」、「回旋」という3つの要素を教えてもらいました。 3つを一気には難しいので、まずは「角付け」を意識しながら滑る、ビデオを見る、また意識して滑る。「角付け」ができたら次に「荷重」を意識する、ということを繰り返すことで、スキーのカービングが圧倒的に上手くなりました*2。そして何かを意識するためには、余裕が必要です。自分のスピードや斜度の範囲内で練習することで余裕ができ、意識したいことに集中することができます。
いまとなってふりかえると、どんだけ量をこなしても、ただそれだけでは質には変化しないと思います。もちろん慣れることでどこでも滑れるようになりました。しかし、その滑り方を続けていても、カービングが綺麗にできるようになるとは到底思えません。
まとめると、、、
- 意識しながら量をこなすことで質に変換することが可能となる。
- 意識を集中するためには、余裕が必要である。
最後に体重はいくら頑張っても質には変わりませんのであしからず。*3
ヒエラルキー組織における情報伝達パターン
現場では「無理」だという認識なのに、TOPは「上手くいっている」と認識しているという経験はありませんか?
自分の観察によると、この現象は以下の条件が揃うと発生しやすいようです。
- 階層構造が深めのヒエラルキー組織である
- 悪い報告をよしとしない文化を持つ
どうやって現場の無理という声がTOPまで伝わっていくかのイメージ図です。
【NO:無理です】 現場(図では一番下になっています) 【NO?:難しい可能性があります。】 【Yes?:大丈夫ですが、リスクあります】 【Yes:上手くいってます。大きな問題ありません。】
一番考えないといけないことは「報告は正しくない可能性がある」ということです。 人が報告をすると必ず伝言ゲームの要素が入ります。また悪い報告をして怒られたくないという感情や昇進のために悪い報告を隠して何とかリカバーしようとして報告を作為的に変更することも考えられます。
この状態になるとTOPが間違った情報を元に経営判断をする可能性があります。不幸なことですよね。
この解決策としては、TOPが現場を直に見に行ったり、現場の声をTOPに直接届けることができるような仕組みが必要です。このような活動を通して報告書だけでは得られない正しい現場の姿を認識することができます。 現場としては、オープンなデータを用意することで、TOPを含む誰もがいつでもアクセスできる環境を提供するのが良いと思います。
また組織としては、『悪い報告を歓迎する雰囲気』を作らないといけません。 悪い報告をすると上司の機嫌が悪くなる、上司からの叱責を回避したいという状態であれば、やはり悪い報告は後回しになってしまいます。 ここは文化なので組織に所属する人みんなで作っていきたいところですね。
テスト駆動開発(社内講演)
弊社の山梨事業所に和田卓人(t_wada)さんをお呼びして、テスト駆動開発についての講演をしてもらいました。
3時間でしたがDemoの圧倒的なライブ感が凄かったです。 和田さんの深遠なる知識と実務感を感じました。
今回もたくさん気づいたところあったので、忘れないように書き留めておきます。
TDDは単なるテストファーストではない。
プログラミングテクニックではあるけど、設計テクニックでもある。
ToDoリストからの選び方
一番重要 or 一番簡単なもの 和田さんは一番簡単なものを選ぶ
リファクタリングの終了条件
- 時間
- 数(重複が解消されたら)
重複派は2out派 or 3out派がある。和田さんは3out派
リファクタリングをするためには、All Greenが必須。
All Greenではない場合は条件を満たしていないので、まずAll Greenにすること All GreenのときのみリファクタリングしてもOK。
テスティングフレームワークはランダムに実行されている。
テスト自体に依存関係が入らないようになっている。依存があるとテストの並列作業が難しくなり、時間が極端にかかるようになる。
テストの時間を減らすためにやること
- 力とお金で解決する(=サーバー増設+並列実行など)
- 全件実行しないなど件数を絞っていく
クラウドではなく、オンプレで力押ししているところもある。
テストコードの品質
テストコードの品質はプロダクトコードと一緒にする。静的解析をかけている場合はかけるし、コードレビューもしていく。 昔はテストコードはプロダクトコードほど力を入れなくてよい、と言われていた。その結果、プロダクトコードとテストコードの割合が1対10とか1対20になった。 今となるとそれは間違っていたといえる。
t_wadaさんのレビューの仕方
まずは全体の構造=構造化されたToDoリストをじっくり見る。それがOKであればプロダクトコードやテストコードを見る。
せっかく和田さんと話す機会ができたので、札幌でTDDBCを開催したい件を相談しました。札幌でもTDDBCできるといいなぁ。
KPTのK
先日のソフトウェアシンポジウムでKPTについて考えるきっかけ*1がありました。
そこでKPTについて改めて再認識したことを書いておきます。
KというとKeep=良かったこととしてフセンに書き出すのが一般的だと思います。 その際に意識することは、Keepとして挙げた項目の中には『原因となる行動』と『その行動による結果』の両方が含まれているということです。 ふりかえりに慣れていないチームでは、『結果』の方が多く出ていないでしょうか?
例えば、「顧客から感謝された」というフセンがあったときは、これは結果になります。 これだけだと良かったねーで終わってしまいます。 もちろん結果をチームで共有することも大事なのですが、自分達のどういう行動が「顧客から感謝された」ことに繋がったかを考えて、行動のフセンも出すのが良いと思います。
「リリース前に2回デモをおこなった」(いままでは全くやっていなかった)
こういう行動のフセンが出てくるかもしれません。それがKeep(する行動)になります。
これだけKPTの天野さんのSlideShare「KPTのコツを掴め!!」p11にもこの話が載っています。
「良いことは現象なので、続けられない。その現象を引き起こす行動を確認する。」
まとめ
- Keepを出すとき/見るときは行動と結果を意識する
- 良い結果の原因となる行動をKeepする
*1 興味ある人は何があったか直接聞いてください ><