午前中は荷物の受け取りもあるし、早めに届いたら、花粉症の薬をもらいに、耳鼻科にも行こうと思っていました。
土曜日は、週一のゴミ出しがあるので、７時におきて、二度寝することが多いのが、
いろいろあるので、今日はご飯食べて荷物がくるまでグダグダしていた。
ぽつぽつ荷物がとどいたら、
まてよ、昨日スケジュール調整のメールきてたなと気づきました。
スケジュールに反映しました。そうしたら新人教育の日程調整がきていたので全部調整しました。そうしたら新人教育の事前教育があったので思い出してみていた。
昨年も受講したので、心得は同じ内容もあったが、あらためて、新人教育の担当する上で気を引き締めないといけないと再確認しました。それ以外にも、オンラインで実施する場合の気を付ける点も紹介されていました。去年の新人教育以降に、オンラインで教育することが増えたので内容として腹落ちしました。
正直に言いますが、去年の新人さんは、今の時代に絶対必要な人材だと思います。だって、みっちり、３か月くらいオンラインで新人教育をやっています。旧人にくらべたら、ツールの使い方、リテラシーは非常に高いわけです。みなさんもそういう目でみていただくと良いかなと思いました。
オンラインで耳鼻科を予約した運よくとれたので、診察して薬をもらってきました。
その結果、参加する勉強会に少し遅れてしまった。
ひとつ聞きたい話がきけなかった。（土曜の診察は午前中が１４時くらいなので）
オンラインでスピーカーは話す内容に聴講者はチャットで反応できるようだったので、
いくつか反応してみたら、とりあげていただいてうれしかった。
見積もりの精度を上げるという話だったが、
「見積もりは正確性を追求しすぎると、過大になりやすい。」
というのをチャットになげてみた。
だが、発表している方は互いに確認しあうことで精度をあげられているという内容だった。
私が「見積もりは正確性を追求しすぎると、過大になりやすい。」を投げた意図は、
正確性を求めるお客様は、
オーバーすれば費用をみてくれないし、
多い場合はほかの作業をやれと言われる。
こうなるとリスクを積まなければいかなくなり、過大になっていく。
私は、社員時代に協力会社から発注元にいったので、
見積もりが過大になる仕掛けはわかっている。
過大な見積もりを出させないようにするために、
「見積もりはぎりぎりで出してください。」
「バッファはいれないでください。」
「こちらが依頼した作業でオーバーした場合は追加の工数は出すので」
「また、早く終わったら、その工数はどう使ってもかまいません、先にすすめても良いし
自己研鑽や自分の会社の仕事に使ってOK」
と言いました。バッファは個別でなく管理者がもつスタイル。
こうすると、見積もりはギリギリで出してくれるようになりました。
こちらも見積もりが過大なと思うものは徹底的に確認しました。
という昔の話を思い出しました。
ちなみに、スピーカーの方がなぜうまくいっていたかは、
話している内容でわかりました。
発注元が発注先に対してかなり配慮していることがうかがえました。
だから信頼関係があるんだと思いました。うそをつく必要がないのがわかりました。
「こちらが依頼した作業でオーバーした場合は追加の工数は出すので」
と同じくらいということはかなりのものだと思いました。
こういうのも良い勉強だなと思いました。
スピーカーの会話の中で、
アジャイルの品質データも定量化したいという話がありました。
ここツッコミたかったのですが、できませんでしたね。
この話をしているのも、正直日本だけじゃないかなと思っています。
短い間隔でリリースできるチームは品質が良く、経営にも効果を出している。
第三者検証はこの結果に影響しない。第三者検証しているから品質が良くなるわけではない。ということは当たり前になりつつあるのです。
興味のある方は
「LeanとDevOpsの科学」
を読んでいただければと思います。
大切なのは、技術的負債がなく、短期間にリリースできる状態が保ちつづけられていれば、これ以上の状態はないのです。これがあるべき姿なのです。
それと、自分はこうなるだろうというのは、自分が開発リーダーの時にぼんやりわかっていた。
開発規模は小さくなればなるほど、開発期間は短くなればなるほど、定量化した数字は０に近づいていくのです。
テスト駆動開発をしながら進め、結合テスト、リグレッションテスト、出荷前テストとやっていく習慣ができてしまったら、今まで測っていたバグ密度やテスト密度などの数字はまったく意味がなくなります。
それよりも、テストカバレージが維持されているか、複製したソースコードがないか、プログラムの複雑度が増していないのかをチェックすることになるはず。
ここに想像がいかないのはなぜだろう？とか
こういう話をする人がものづくりをしていないからと、
以前は思っていました。
テスト駆動開発の教育をやるようになりました。
どんな人がやっても未経験者は躓きます。
理由は、小さくつくることができないのです。
まとめて開発しようとするのです。この結果、簡単にスパゲッティを作ってしまいます。
これは、プログラミングスキルが低いからではなく、
物事を整理整頓して、小さく進めることができないとおきます。
なので、優秀なプログラマーがそういうことをしてしまいます。
テスト駆動開発で作成するソースはことのほか少量で、
数時間でできてしまう量で、それをリリースできるようにするために、
テストを直していく作業がかなりあるのです。
このあたりが想像できないから、品質データにこだわるのかなと思います。
なので、品質担当の方に言いたいのは、テスト駆動開発を概念としてこうやる仕事ねと考えるのではなく、実際にやってみて求められるプログラム作成の小ささを体験していただきたいなと思います。そうすれば行くべき道は見えると思うのです。
勉強会は１６時前に終わり、
JASPICのSlackに言いたい放題の文章（タスクボードは何のためにつかうの？）をかき、雑談に昔話（DADを読んで汎用機OS開発を思い出した話）を書いて、
美容室に行って髪をそめていて、待ちの空き時間に今日のことをブログに書きたいなと思って書きました。勉強したなぁ。新しい本が４冊とどいてしまった。