@kyanny's blog

My thoughts, my life. Views/opinions are my own.

2016年を振り返る

毎年恒例の。

仕事

2016年は仕事に追われた一年だった。受験サプリを Quipper プラットフォームへ移管するのが一番大きな仕事だったが、移行当日に体調不良でぶっ倒れてしまい、肝心の移行作業中は自宅で床に臥せっていた。情けない。吐くほど具合が悪くなることは年に一度あるかないかで、なぜあのタイミングだったのか未だに不思議だ。

その後も雑多な仕事に終われる日々が続いたが、夏ごろにようやく落ち着いてきたので、負担が目に見えて増していたリリーステストのテコ入れをしようと QA プロジェクトを立ち上げた。しかし、他のプロジェクトの仕事もしながら片手間でやれるほど簡単ではなく、過去のトライと同じく道半ばに終わってしまった。残念。

そして、この冬からなんと「マネージャー」と名のつく立場になってしまった。いろいろ理由があってのことで、どれも妥当な理由だと思うし、自分でもいろいろ考えた末に納得して受け入れているのだけど、それでも「よりによってこの俺が」という気持ちは拭えない。とはいえ、「マネージャー」の名のもとにする仕事の半分以上はこれまでも勝手にやってきたことだし、単なるロール(役割)と思って粛々とやっていきたい。「マネージャー」の仕事の片手間に QA プロジェクトはできそうもないので、どうしたものか、というのが唯一の心残り。

生活

体調面は良くなかった。数年前から CRP 1 オーバーが続いていてレミケードの増量をほのめかされつつも騙し騙しやってきたが、春先のレミケード前の採血で CRP が 4 を超えてしまい、主治医の「次回まではもたない」という判断により、緊急でその回から倍量になった。倍量になってからは落ち着いてきたものの、やはり CRP 1 くらいで推移しており、良くない。切り札を一枚減らしてしまったし、有効な次の一手も無い状態なので、来年は薬をさらにちゃんと飲みたい。

家庭は円満だけど、妻の仕事がとても忙しそうで、無理をしすぎているので妻の健康がとても心配。常々、「ストレスと過労で身体を壊すくらいなら、仕事なんて辞めてしまって、猫と楽しく暮らしたら」と言っているのだけど。

その猫は今年もダイエットには失敗したが、夏には金沢へ帰省して、今回は妻の実家にもだいぶ慣れた様子だった。さらに、秋には歯石取りの治療をした。以前から獣医師に「いつかやりましょう」と言われていたもので、施術の前日は普段より早めに晩御飯を済ませて当日の朝ごはんは抜き、全身麻酔をしたのだけど、麻酔から醒めてご対面したときは気が狂ったのかと思うくらい落ち着きがなくて、家に帰ってからは気が狂ったのかと思うくらいご飯を高速で食べまくっていた。あと、昨年にも増して、甘えたになった。

勉強

ろくに勉強できなかったし、成果もかんばしくなかった。語学は、英語と、たまにスペイン語、気まぐれ にロシア語なども冷やかしたけど、日々の忙しさに流されて継続できていない。 TOEIC も受験しなかった。たぶんスコアはあがっていないと思う。ただ、英会話の度胸はそれなりについた。リスニングも少しはマシになってきている手応えがある。一方プログラミングはさらにひどくて、 Go とか Rust とか Vue.js とかをほんのちょっと触ったくらい。

これではいかんと思い、未来の自分への投資という意味も込めて、一月ほど前から Udacity で機械学習のオンラインコースを受講しはじめた。週末に少し進める、というペースだけど、これは今のところ続いているので、継続したい。ちなみになぜ機械学習かというと、 Facebook で江渡浩一郎さんが清水亮さんと中島聡さんの議論にコメントしているのを読んで、「機械学習をやっている人たちにとってはこれが常識」といっていたものが全くわからず、せめて教養程度には知見を深めたいと思ったから。

本はそこそこ読めた。なんといっても Code Complete 下巻を読めたのが良かった。そして、紙ではもうどれほど暇であっても分厚い技術書など読み終えられないと悟った。こまめに読み続けられないと、読んでいた内容を忘れてしまう。これまで紙で買って積ん読になっている名著と呼ばれる本が何冊も本棚の肥やしになっているが、潔く電子書籍で書い直して、一冊でも二冊でもいいから着実に読んでいきたい。

イベント

何の成果も挙げられなかった。カンファレンスに CFP を提出することすらなかった。それに値する活動を何もできていないことが、とても良くない。来年改善できる見通しも立っていない。どうしたもんかな。

総括・来年

仕事と家のことと猫の世話をしてたらあっという間に一年過ぎてしまった感じ。来年は...与えられた仕事をきっちりやるのみ、かな。あとは、この一年のまとめブログを、年越しぎりぎりにようやく書き上げるのはやめにしたい。

Nagoya.Testing in Tokyo -テストを強いられている人達の話- に参加した

ソフトウェアのテストに関心があるので、Nagoya.Testing in Tokyo -テストを強いられている人達の話- - connpassという勉強会に参加した。

テストというよりもアジャイル開発、とくにスクラムと、チームのマネジメント・コーチングの話で、とても参考になる内容だったものの、自分が求めていたものとは少し違っていた。求めているもののほうが間違っているのかもしれない、という気づきがあった。

特に印象に残った部分

  • バグの根源には何かしら「無理」がある。無理からくるバグをテストで取り除こう、という考え方が間違い。無理をやめよう。
  • いかに普段からテストして、テストを減らすかを常に考える。
  • 残業をしない。
  • ソフトウェア工学の知見を活かす。先人に学ぶ。
  • チームメンバーに、わかるまで800回くらい、同じことを表現を変えて言い続ける。伝え続ける(人間とはそういうもの)
  • いかにして、アイデアを「自分が考えだした!」と思わせるか。インセプション。
  • 基本を大事に。基本ができてないのにいきなり我流スクラムとか、うまくいくわけない。うまくいかない理由が、基本を外してるせいなのか、他に解決すべき真の問題があるのか、切り分けるためにも、まず基本に忠実にやる。失敗しているなら、まず基本と違うところを基本に戻す。
  • できるようになるまで、被害が少ない範囲内で、7回くらい失敗させる。失敗とは、物事が計画通りにできなかったこと(ミスに限らない)。イテレーションの間隔を短くして、何度もPDCAサイクルを回せるようにすれば、より多く、小さな失敗から学べる。
  • 計画と予測が粗いと、そもそも本人が何に失敗しているのか気づけない。何かがうまくいかないから計画からズレるわけで、まず計画からズレているということを認識させる。ズレる原因が何か、を考えるのはそれから。
  • 形式知にすることにこだわらない。積極的に暗黙知にする。形式知にしたところで、活かすための訓練の方法論がない。チーム開発の体験を通じて、暗黙知を共有する。
  • 開発と別に独立したQAのチームを作るのは絶対にナシ。お互いの「結果」が相反するので、結果を出すためにお互いが敵視し合う関係になってしまうから。QAのコーチを雇って、テストはあくまで開発者自身がやるが、どのようにテストすればよいかのコンサルティングを受けられるようにするのはアリ。
  • ユーザーが強いられてる体験があるなら、自分たちも同じことを手でやって体験して、「プロダクトデザイン変えたほうがよくね?」とユーザーのつらみを感じがほうがよい。 GUI とか自動化しづらい部分は無理せず手で触ってテストすべき。

バグ年間一件 kyon_mm

名古屋 株式会社オンザロード テスト無くしたいエンジニア スクラム、SCMハンズオンセミナー

一番多かったのは、二ヶ月に一回もリリースしてない

基盤チーム 4人 フレームワークとライブラリの受託開発、毎月リリース

二年間で2件 メンバーは一年くらいでローテーション

Scrum Test Metris / Regional Scrum Gathering Tokyo 2016 Agile Japan 2016 テスト期間 PDF

バグの根源は無理からきている(何かに無理がある) 無理からくるバグをテストで取り除くという行為が無駄 無理するのをやめよう いかに普段からテストして、テストを減らすか。が重要コンセプト

2014年まで 年間バグ10~20くらい リリース年3,4回、バグったら直してリリース 残業も多かった

品質が10倍あがった => バグが1/10に減った

バグを分析 リリースが難しい要件をチームが作る、という要因 残業を乗り越えられる体力とパワーがあったがゆえに。

チームの分析 解散して情報がたまらない(ローテーションの悪の面 開発とテストがチーム内で微妙に分かれている 責任範囲を狭くしたがる

理想像を描く 残業しない ソフトウェア工学の知見を活かす

チームを変える情熱、理論を構築 みんなで変えていく、という気持ちをあげていく メンバーと何度も話す。伝える。聞く。違う表現で。

どう進めるのか、戦略

Product Owner がビジョンをはっきり持つ 世界最高になるために 必要なコストは際限なく払う(赤字でも 大量の失敗を許容する チームに自由と規律を与えて制限を外す

人は自由を与えても思ったほど好きにやれない 本人にオーナーシップを与えて責任に気づかせる

細かいことを入れると一人に年間400-800回くらい言ってる 子供が何か覚えるまでに言う必要回数が800回くらい、チームも子供も同じ(人間はそういうもの、言わなきゃ変わらない

いかに相手に「自分が考えだした!」と思わせるか(インセプション!

オーナーシップ、デリバリーの最後まで責任と自覚を持つ

それやらせてバグ出してリリースできなかったらどうするの? => 実際にリリースするのと社内でやるのと別にすればいい。スクラムのスプリントミーティングのデモとか。

基盤チーム、1週間スプリントから今は1日スプリント、20スプリントくらいやってリリース

基本をちゃんとやる、スクラムちゃんとやったことないのにスクラムっぽいことやってうまくいくわけない 失敗しているなら、まず基本と違うところを基本に戻す。それから改めてどこが悪いか考える。

学習効果を最大化する いろんなやり方で失敗、挑戦、体験する 一つの失敗体験で同じように人が学べるわけではない(体験から学習するやり方は人によって違う) 一つのバグについて7回くらい失敗すると、もう失敗しなくなる。お客さんに影響ないやつは何度でも失敗させる。 チームで失敗も褒めるも尊敬も自由に話せる雰囲気を作るのが大事 KPT で個人的な問題をずらずら書く。個人をけなす意味ではなく、事実を、それがフツー 毎日できるだけ、サンクスカードと懺悔カードを付箋に書いて、次の日に会ったとき渡す

わかめ@TypeScript味 ‏@vvakame 2m2 minutes agoView translation 避けたいバグがあるなら半年とか前からそのバグを踏むようにユーザーストーリーを組んで気づきを得させてやったりするらしい。先見性の塊かよ…。だいたい7回踏ませると綺麗になる。 #NagoyaTesting

積極的に暗黙知にする(SECIモデル) 形式知にする必要あるか?形式知化することは難しい 形式知にしたところで、活かすための訓練の方法論がない

優先順位、設計・テスト判断基準、レビュー方針、これらを形式知化して活用し続けるのは難しい => 暗黙知を体験通じて共有できるようにするほうがよい

スプリント毎にロールをくじ引きで決める(今日のプロダクトオーナー、が新人、で仕様聞かれる、みたいなレベル) スプリント期間が短ければ失敗の影響が小さくて済むし、全くできなければチームがヘルプするので、まわる

やればわかる部分はやればいい、それでもわからなければ形式知にすることを初めて考える

効果 Scrum を完全にマスター バグ減った チームの関係がよくなった 定時で帰るのが普通になった

そもそもバグを作らないプロジェクト、プロダクトにする。その覚悟を全員に持ってもらうようにするのがマネジメントの本領発揮


質問への回答: 実績ベースだと、独立したQAチームを作るのは無し。結果を出すためにクソな感じになるので、開発者がちゃんとテストするようにしたほうがよい。けどQAのコーチングは必要かもしれないので、外部のエキスパートを呼ぶのもアリと思う。QAという肩書の人が、テストについてなんでも聞いて教えてくれる人(ただしテストそのものは聞いた開発者自身がやる)、という社内のQAコーチという位置づけなら、ありかもね。

「スクラム現場ガイド」という本を読め。

敵対的な態度の開発者がいた場合は? => 大失敗してもらうのがいい。明らかなテストだけやる。「この人がテストすると便利」としておき、他はテストせず、相手に気づかせる。

開発とQAの関係 => 分かれてないので、開発者がユニットテストもシステムテストも全部書くし全部やるスタイルにした

ユーザーのことを考えない人にとっては、形式知化したテスト手順書をやるくらいしかできない。手順書を書いた時点でもうテストが終わっている(?書かれたことしかテストしないので、テストの価値が低いし、発見的じゃないからバグも見つからない、的なことか?)

難しいテストはどうする?UI,非同期、多システム連携 etc. もみあげの人 => UI は諦めた。システムテストは、ステージングとかで定期リリースして触ってもらう?フィードバックを短期でもらう 眼鏡の人 => 多システム連携は、SIerだとフットワーク軽くないので、インタフェース境界をバチッと決めて、政治力駆使してこっちはそれ通りに作る、自衛する方向。 グラサンの人 => ユーザーが強いられてる体験があるなら、自分たちも同じことを手でやって体験して、「プロダクトデザイン変えたほうがよくね?」とユーザーのつらみを感じがほうがよい。 GUI とか自動化しづらい部分は無理せず手で触ってテストすべき。

個人プロジェクト「コンパイル時にユニットテスト終わってないとか時代遅れ」というライブラリ作ってて論文書いてる

基盤チームとプロダクトチームがあって、品質をどっちが担保すべきか。プロダクト側でやってほしいが出来る人がいない。基盤のほうが能力は高いが二人しかいない。 眼鏡の人 => 両方やってる身として、基本、基盤側に寄せたほうがよい。プロダクト・プロジェクト側は玉石混交なので、質が一定で担保できない。そもそも線引せず、プロダクト・プロジェクト側で出来る人が直接基盤側にコミットできるようにするのがよい。品質保証は完全に基盤側に寄せないとダメ。(さっきの開発者がテストすべき、という話とちょっと矛盾しないか? => 品質って、テスト済んでる前提で、パフォーマンスとか、一歩先の話なのかも) アーキテクトというロールがある。社内どのプロジェクトにも好きに口出して良い。

大量の失敗を許容するためのマネジメントは、何をすればいいのか? 短いスプリントとかわかるけど、具体的にどう失敗させればいいんだっけ? => 見積もりを明らかにするためにチームで細かく見積もりを何度もする。どうせ失敗するのでリスクバッファを積みたいが、どれくらいバッファ積めばいいかわからない。どうすればいいか。全員のタスクを、最小30分の単位まで細分化する。 人によって所要時間のブレ幅がめっちゃ大きくて20倍とか生産性に差がある。それを認識できてないので見積もりが甘くなる。それを認識させるためのプロジェクトを組んで、成長させる。実験する。経過を細かく見る。いつ 1.02 倍から 1.5 倍とかになるのか。プランニングしてるから事前にだいたいわかるけど、二週間とかのスパンで定点観測していく。それができるような予算組みでやる。

そもそも失敗って何のこと? => 計画したことがうまくいかないこと(ミスとかだけを指すわけではない) 失敗学。差分を知る。課題に対する期待と現実の間に差があるのが失敗。でも失敗はネガティブではない。計画通りいかなかった、という学習機会。当てずっぽうの計画では意味がない(学習にならない) 計画と予測が粗いと、そもそも本人が何に失敗しているのか気づけない。何かがうまくいかないから計画からズレるわけで、まず計画からズレているということを認識させる。ズレる原因が何か、を考えるのはそれから。そのために計画 => ズレ => 修正、のサイクルを短期間で多く回させる。学習機会を大量に消化させる。

失敗した後のやること、お決まりの定番はあるか?

表面的ではなく、なぜバグったか?で分類している。「いまバグってもいいだろ」と思っているフシがあった、とかだと、昔見過ごしてたけど今検知できてるバグがある、君は昔と同じことをしている、という話をまずして、お金の話をする。基盤が作ってるライブラリとかはユーザーがたくさんいる。OSSではなく、お金払って、仕事で仕方なく使っている人たち。バグがあると、ユーザーの仕事が遅れて、どんどん膨らんで、全体でどのくらい損失が出るか(三次受けのプログラマがバグ踏んで、とか)君が手抜きした30分のテストでバグが出たせいで、2200万円分の時間が無駄になる。その30分の手抜きで君はそれを奪った。という一例。

「人と組織はなぜ変われないのか」免疫マップ、を書け。

QCストーリー 「トヨタの型」 マイク・ローザーのウェブサイトで PDF のテンプレがある メンターと一緒に課題に対してメトリクスをつける習慣をつける。小さいことでいい。毎日やる。

iPhone 6 で PDF を(それなりに)快適に読む

Foxit MobilePDF for iOS で Landscape (横向き)にすると、 PDF 書類の左右の余白?を程よい感じに切り詰めて両端を揃えてぴったり画面幅に収まるサイズで表示してくれるので、縦スクロールで読み終わったら横にスワイプでページ送り、という感じで、それなりに快適に読める。もちろん、縦スクロールは面倒くさいし、通勤電車で吊革を持った状態で片手で Landscape (横向き)の iPhone 6 を操作するのは難しいので、どうしても、という場合。

以下、白背景に白余白(?)の画像だと境界がわかりづらいので、画像の周りの box に背景色をつけている。

Portrait (縦向き)
f:id:a666666:20161228030459j:plain
Landscape (横向き)
f:id:a666666:20161228030512j:plain

iBooks だと両端の処理がイマイチで、拡大すれば読めるは読めるけど、左右にもスクロールできてしまい、文字が見切れたりして使い勝手が悪い。

Portrait (縦向き)
f:id:a666666:20161228030356j:plain
Landscape (横向き)
f:id:a666666:20161228030403j:plain
f:id:a666666:20161228030424j:plain

ちなみに Dropbox 連携のアドオンを追加購入する必要は無く、 Dropbox アプリ内で PDF を開いた状態で、エクスポート > 別のアプリで開く... > Foxit PDF にコピー で ok。

エンジニア立ち居振る舞い: オフラインでも即レスする

お題「エンジニア立ち居振舞い」

オンラインのコミュニケーションで即レスを心がけている、という話を何度か書いたが、オフラインでもそうしているよ、という話。

blog.kyanny.me

blog.kyanny.me

やってることはオンラインより単純で、

  • 話しかけられたら即座に応対する。そして、その場の会話で、できるだけ多くの疑問に答え、できるだけ多くの課題を解決する。自分一人では解決しきれなかったら、より適切な人に繋ぐ。
  • 手が放せないときは「今は手が離せないから、○分待ってくれ」と言う。短時間なら待ってもらうし、長くなりそうなら手が空き次第こちらから連絡すると告げて、後回しにさせてもらう。

これだけ。当たり前のことだけど、疎かにしがちなので、たまに意識するようにしている。

短期的にみれば自分の時間をより多く費やすことになるが、チーム全体でみると、こういう風に都度発生する非公式な「打ち合わせ」を丁寧に各個撃破していくほうが無駄なコミュニケーションを省くことができて、時間の節約になる。そして、結局は自分の時間を節約することに繋がる。

GitHub Issues や Slack など、テキストベースのオンラインコミュニケーションが中心の仕事環境で、それでもなお口頭で話す必要があるということは、それだけ急を要する用事だといえる。であれば、話しかけられる側も相応の応対をして、さっさと用事を片付けてしまうのが、お互いにとって(そして他の同僚にとって)ハッピーである。