クソレビューアだらけのレビュー会をもう少し考える
クソレビューアだらけのレビュー会 という、はてな匿名ダイアリーのエントリがホットのようです。共感する方が多いのか、1日でブックマーク数が700を超え、結構な勢いでコメントがついています。
何を対象にしたどのような条件下でのレビューなのかを示す文脈は直接書いていませんが、
- ソフトウェア開発、システム開発における
- 欠陥の摘出を目的としたレビューであり
- レビュー対象はWord等のページ番号のある文書(仕様書や設計書)であり
- 少なくとも5名以上の同僚が集まる
- 対面の会議であり
- 文書の作成者が進行をリードするウォークスルースタイルで
- レビュアーはこの会議で初めて文書を読んでいる
ということが推測できます。
レビューのスタイル
であれば、もううまくいかないことは目に見えています。会議の場で初めて見る文書をウォークスルースタイルで作成者が頭から説明してゆくやり方は、設計の欠陥や仕様同士の矛盾などを見つけるのには向いていないでしょう。欠陥を見つけるには、レビュアーは自分のペースでページを行き来したり、ほかの文書と見比べたり、場合によっては紙に図を描いたりコードを書いたりした方が効果的でしょう。ウォークスルースタイルで事前に文書を配布していないと、そのような読み方ができず、欠陥が見つかりにくくなることが考えられます。
仕様書や設計書の欠陥摘出であれば必ずしも対面で会議する必要は無く、むしろ各レビュアーが自分のペースで集中してレビュー対象に向き合う時間をとり、その後で各レビュアーの指摘をまとめ、議論が必要となりそうな指摘内容があれば会議を開く方が効率的でしょう。また、誤字やフォントなどの体裁については、欠陥とは分けて記録しておいた方が欠陥の摘出に集中できるでしょう。体裁は簡単に指摘できますから、レビューした気になってしまいますので。
レビューには複数のスタイルがあり、ウォークスルーが悪なのではなく、目的よって向き不向きがあるので目的に合わせてスタイルを選びたいところです。
- カジュアルな欠陥摘出ならチームレビュー
- 厳格な欠陥摘出ならフェイガンインスペクション
- 教育や引き継ぎならウォークスルー
- コーディングならペアプログラミングかピアデスクチェック
といったところでしょうか。集まって読み進めるやり方しか知らないのであれば、ピアレビューでググるといいと思います。
各"クソレビュアー"の主観的ランク
これをわざわざ書くかどうか迷ったのですが、当の匿名エントリを読んだ感想の整理のために書いてみることにします。
○寒がり
クソどころか超重要。寒暖を我慢したまま会議をするなんてバカげてます。
○レアケース厨
悪魔の証明に類することを指摘しても意味はありませんが、レアケースであっても信頼性の向上に繋がりそうな指摘をして議論することは、そのレアケースを考慮する必要が無かったとしても有意義であると思います。
△ついていってない
これはおそらく、スタイルがウォークスルーにも関わらずレビュアーが自分のペースで集中して読み進めているために起こるので、チームレビューであれば良いレビュアーになるかもしれません。
△体裁厨、用語統一厨、箇条書き過剰、寂しがり、目悪い、指摘曖昧系
文体をわかりやすくしたり、見栄えを良くすることも必要かと思います。こればっかりでは困りますが、別に良いのではないでしょうか。9ptだと辛いから11ptにしてくれとか。
△遅れてくる系
これもウォークスルーをやめれば活躍する人かもしれません。
△寝てる
連日の疲れがたまっているのかもしれません。必須のレビュアーでなければそっとしておきましょう。
×成果物興味なし系
役立たずその1。居る意味が無い。ただし、レビュアーとしてマッチしていないだけで、この人がクソとは限らないことに注意。
×物忘れ激しい系
役立たずその2。居る意味が無いどころではなく害悪。レビュー以外でも迷惑をかけていそうです。
×PMO 「指摘密度が基準値に満たないので…
役立たずその3。非生産的な仕事をさせようとするクソパーソン。レビュー以外でも似たようなこと言いそうですね。
WACATE2014夏
日高屋でラーメン食ってるときに参加を決めた
3月、テストの人達の人物像を確かめるためにJaSST'14Tokyoへ行きました。収穫は多くありましたが一日見物したくらいでテストの人達とは何だかわかるわけもなく、消化不良感もありました。
JaSST '14 Tokyo 感想 - テスコンとテストの人達とは。必要なのはロマンスとエンジニアリングだ。 - MassKaneko.Out
そしてある日の夜22時、くたびれた体で汁なしラーメンを食べながらTwitterを見ていると「WACATE2014夏申し込み今日まで」との情報があり、迷いました。
WACATE受付締切あと2時間じゃん。冬だけだと思ってたけど、どうしよう。
— Mass Kaneko (@masskaneko) 2014, 6月 1とりあえずTwitterでそれっぽい人達を探してみるとなんかマニアックでやる気あるっぽい方々が多くいそうだし面白いんじゃないかと。あと、私はテスト専門ではないのですが今のポジション的にはもうちょっとわかってないといかんという事情もあって参加することにしました。
といったところで汁なしラーメンを食べ終わりました。
改めて、ソフトウェアテストと自分
WACATEでは参加者がポジションペーパーをあらかじめ書くのが恒例のようです。40人以上が参加して1泊2日を過ごすワークショップですから、参加者同士のコミュニケーションが生まれやすいように配慮しているのでしょうね。
人によってはずいぶん気合の入ったポジションペーパーもありましたが私はいかんせん締切2時間前にラーメン屋で気付いた経緯もあり、そこまで凝ったものは作れませんでした。というか変に短時間で気の利いたことを書こうとしてちゃんと自己紹介を書けていませんでした。そこで改めてソフトウェアテストと職務上の自分との関係を簡潔に示してみることにします。
- 元々は開発者。テストでバグを出される側。出されるとげんなりする。
- システムテストを手伝ったこともあったけど自分はほとんどバグを見つけられなかったので、向いてないんだろうなと思った。逆にレビューではズバッと欠陥を見抜いたり、静的コード解析には強い興味があったりした。なので、Static Testingだけ尖ってる感じがある。
- なんやかんやで開発からコンサルティングをする立場になった。ソフトウェア工学のことなら何でも一通り押さえておかないといけなくなったけど、テスト…特にブラックボックス視点でのシステムテストはぽっかり穴が開いていた。
※他にも穴はあるけど特に苦手意識があった - ふとした縁で何人かの識者と会ったことをきっかけに基礎を固めることにした。テストエンジニアと技術的な会話をできるようになっておこうと思ったからだ。とりあえずJSTQB FLのシラバスくらいは読んだ。他、色々調べたり手を動かした結果、テスティングはクリエイティブで発展している技術分野っぽいことがわかった。
- 生粋のSoftware Testerみたいな人を見ておこうと思ってJaSSTへ行き、WACATEにも参加することにした。
WACATEのワーク
Workshopなのでワークがあります。あるお題のアプリケーションのツッコミどころ満載な不完全な仕様書とテストケースからテストの意図をリバースするというのが今回のテーマでした。これを数名のグループで一泊二日どっぷり取り掛かるわけです。リバースの手法としては「ゆもつよメソッド」(の一部)を使って機能：テストカテゴリの表を作り、意図が書いていない既存のテストケースをはめこんでいくというものでした。
私としてはトップダウンでテスト分析するより、具体的なテストケースから抽象的なテスト条件に汎化させて更にそれらをカテゴライズしてテストカテゴリを導き出す方がやりやすいかなと思いました。テストカテゴリは全然思いつきませんが「確認しておいたほうがよいこと」「懸念・心配すること」の方が先にどんどん思いつきますから。テスト対象のプロダクトに馴染みがあり、論理的機能構造(入出力・変換・貯蔵…)や品質モデルを理解していたとしても、テストカテゴリっていきなりは出てこないと思います。リバースの方がしっくりきました。
グループワークとしては機能の抽出ですらなかなかモメたりして「うまくいかんもんだなー」と思ったりしましたが、お題のドメインに親しみがあったのがグループで私しかいなかったようなので致し方なしかな。でも凄く良いワークだと思いました。
※参加者向け：惜しむらくはリバースではなくトップダウンで仕様から入ろうと思えば入れたところでしょうか。あのお題の仕様書がもっと欠落していれば、よりリバースっぽい作業ができたのでは。お題を作る側としては相当バランスに悩んだと思いますが。どうでしょうか。
WACATEの人達と雰囲気
参加者は実行委員を除いて50名近く。初参加は約半数。でしたっけ。とにかく皆さん自発的に来ているだけあってかとても熱い感じです。かなり遠くから前泊して参加した方も結構いらっしゃったようです。あと、フレンドリーな方ばかりでしたから初参加でも全然問題ないと思いました。
ポジションペーパーを見る限りでは、職種の分布は「テストエンジニア・QA(9)」「開発(3)」「コンサル・研究(1)」ってところでしょうか。業界はバラバラのようです。とりあえずワークのグループメンバーはステートマシン図にはあまり馴染みがないようでした。
ワークのテーマが派生開発を背景にしているからでしょうか、XDDPの生みの親である清水吉男さんがいらっしゃいまして、参加者の多くが知っていそうな感じなのが結構意外でした。組込み分野以外ではあまり認知されていないと思っていたのですがそうでもないようです。そういえばこの間のAFFORDDに行けなかったんですよね。あいにく旅行がかぶってしまいまして。おっとこれは関係ない。
1日目のワークが終わり、夕食からは酒が入って皆さん饒舌になっていきます。ワークが終わっても「夜の分科会」なるものがあり、個々人の嗜好別に何かしらのテーマについて議論します。探索的テスト好き集まれーみたいな感じ。更に夜が更けると寝る人と寝ない悪い人に分かれます。私は分科会が終わって目がさえてしまったので寝ない悪い人を選びました。ここから先はもうただの酔っ払い同士なのですが、それでもまだ技術の話が続くわけですね。「テスターはコードの品質には興味ないんですよ」なんて話も聞いて、それはもう大ショックを受けてMPが0になりましたが私は元気です。
そうそう、あとJaSST'14Tokyoで見た参加者の声を自由に書けるようなボードに「バグ出しは楽しい！」って書いてあるのを見て「正気か？」って思っちゃったんですよ。だってバグなんですよ？ダメなことがわかるんですよ？仕事増えるんですよ？凹むじゃないですか。で、WACATEにはバグ出しが楽しい人が沢山いると思って何人か…7人くらいかな…に聞いてみましたところ、目を輝かせて「楽しいよ！」と語る方と「うーん？」という方に分かれました。ちなみに自分がもしテストエンジニアだったら、エンドユーザーの利便性に大きく関わるバグを技術を使って見つけて、更に直ったところまで見届けて、できれば自分で直せれば楽しいですね。見つけること・出すこと自体は特に惹かれません。ここは分かれると思います。人それぞれの嗜好の背景を聞くのは好きなのでまたWACATEみたいな層と会うことがあったら聞いてみたいと思います。
行ってよかったですか？2014冬は参加しますか？
参加費22000円はものすごく割安だと思います。迷ってたら行くべし！ 参加者の方々、実行委員の方々、講師・ゲストの方々、貴重な機会を頂きありがとうございました。
といいつつ何回も参加するのが吉なのかは測りかねているところもあるのですが、冬のWACATEは夏とはプログラムの組み方が違うらしいので今のところは参加しようと思っています。
願わくばこのエントリが未来のテストエンジニアの背中を押せるかどうかはわからんけど何かの役には立ちますように。
個人的ソフトウェア世界マップ
※無知な人が勝手にソフトウェア開発の世界を1枚に描いてみたってだけのエントリです。
「多様さをスパッと描きたい」などと供述しており
ソフトウェア開発業界って言っても色々あると聞きますし実際そう思います。遠い世界の人と話すときに文脈や単語が通じてているのか怪しい場面を経験したことはないでしょうか。それは、エンドユーザー・開発環境・アーキテクチャ・ありがちなバグ・チーム内のロール・文化的習慣…などがきっと様々だからなのでしょう。
ゲーム業界の方はプロマネではなくディレクターと言うでしょう。ウェブシステムに馴染みの無い方にはデプロイという単語は通じにくいでしょう。「毎回DBを読みにいくウンコードが…」という愚痴に耳を傾ける組込マーは頭の中でフラッシュメモリへの無駄なアクセスに置き換えているかもしれません。
オープンな勉強会やカンファレンスに参加したりするとその多様さが良い刺激になります。時々その多様さを一枚に表せないか？と思うことがあるんですね。世の中には一体どんなソフトウェア開発の世界があるのかという分類は時々目にしますが、絵に描かれたものが無かったので試しに自分で描いてみることにしました。
描いちゃった
はい、いきなりですがドーン。
え、ほんとにこうか…？これでいいのか…？「私からはこう見えてる」ってことを図示できればそれで良いという勝手な趣旨だからいいんですけど、一応パブリックな場に出すとなると躊躇しなくもない。ま、恥はかきすて。ブログも書き捨て。あまり気にしないことにします。
comsumer, enterprise は一般人向けか法人向けかという軸です。鉄板な軸の一つだと思います。そしてちょっと説明が必要そうなのは縦軸です。この縦軸は計算機の抽象度・汎用/特定用途・マシンパワーを表しています。上がクラウド・スパコン、真ん中がPC、下が組込みというイメージです。
ウェブ系とかエンプラ系っていう言い方はこの図だと…
で、一般的にはもっとざっくりした分け方されてますけど、私的にはこんな図を思い浮かべてます。エンタープライズ向けのウェブシステムが両者の重なる部分になります。クラウドの登場でSIerがヤバいなんて話もこの重なる領域かと思います。ゲームはコンソール・アーケード・PC・ウェブといった幅広いスペックの計算機で動くものがリリースされていますので、ウェブと組込みに重なる部分を設けています。組込みはコンシューマー・エンタープライズの両方をカバーしています。
オチはあるの？
今日のところはこれで勘弁してください
*1:エンタープライズ系とウェブ系 (2014)もうちょっとなんとかなるのでは？と思ったのも図示することの動機です
*2:クラウドがもたらす破壊と創造 = Developer Summit 2014 = (2014)スライド22枚目。クラウドの利用領域の話なのでこの分け方なのかもしれない。
*3:組み込みソフトウェア業界というナゾの裏世界の話 - きしだのはてな (2014)裏世界じゃないよ
*4:「IT業界」なんて、ないんだよ。 - 思っているよりもずっとずっと人生は短い。)(2011)記憶に残るエントリの1つです
*5:組込み、エンプラ/IT系という分類で大丈夫？：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ (2008)組込みだけ分類するなら良い軸だと思う
*6:5つの世界 - The Joel on Software Translation Project (2002)今読むと時代が変わったなと思う箇所がところどころ。
JaSST '14 Tokyo 感想 - テスコンとテストの人達とは。必要なのはロマンスとエンジニアリングだ。
テストのイベントに参加するのは初めて。行ったのは2日目だけ。参加した理由はJSTQB東京の試験が大雪で中止になってムシャクシャしてたから！…という感情的な動機がありつつも目的は2つ。
- テスト設計コンテストを見て、レベルの高いテスト設計およびそれらの優劣とは何なのかを確かめること。
- テストのイベントに来る人たちの層・人物像を確かめること。
主な感想。
俺の #jasst まとめ。八谷さん「ロマンスとエンジニアリングだ！(*´-`)」西さん「ロマンスとエンジニアリングだ ！L( ＾ω＾ )┘」TFC KA・RI・YA「ジスイズアワテストアァキテクチャア！！＼(^o^)／」
— ( ´∫`)( ´ε`)( ´x`) (@masskaneko) 2014, 3月 8…。記憶が新しいうちにブログ書いておきます。
テスト設計コンテスト決勝
ソフトウェアに関するコンテストというと、プログラミングコンテストのようにその場で問題を出されていかに早く解くかを競う形式が思い浮かびます。が、テストのコンテストはそうではなく、あらかじめ提示されたテストベース(※今回の場合は自動販売機の仕様書)に対してどのようなコンセプトで分析・設計を行うのか(※観点の抽出や技法の選択など)が勝負どころのようです(前回(2013)の審査基準)。
今回は日本全国での予選を勝ち抜いてきたチーム同士の決勝戦で、各チームのプレゼンを聞くことができました。どのチームもテスト要求分析とテストアーキテクチャの説明が7割くらいな印象でした。私はテスト要求分析もテストアーキテクチャも理解がさっぱりなのですが、それらの存在意義・あると何が嬉しいのかを理解できたチームは「MKE98」と「TFC KA・RI・YA」の2チームでした。で、これらのチームが優勝と準優勝。おお、私の目に狂いは無かった！(偶然だろ？)
多くのチームがPFD・DFD・UML・マインドマップ・マトリクスを使って図示していたのも印象的でした。テストベースに加えて「ステークホルダー」「対象システムの特性」「過去のバグ事例」「品質特性」を踏まえてマインドマップでテスト観点を発想し、各テスト観点のテストベースに対する網羅性をマトリクスで確認するというのが一つの定石なのかなと思いました。
結局当初の目的である「レベルの高いテスト設計およびそれらの優劣を確かめること」についてはプレゼンだけでは理解できなかったので、後日ASTERのウェブサイトで公開されるであろう具体的なドキュメントを見るしかないですね。とりあえずは過去の発表資料でも見ることにします。
テスコンの物足りなさ
テスコンで求められるのはクリエイティブで工夫のし甲斐のある知的な活動であり、それにのめり込む層が存在することは理解しつつも、何か消化不良感・肩すかし感があります。
それは、動くソフトウェアを見ていないから。私が最初に「テスト設計コンテスト」という言葉を聞いたときに真っ先にイメージしたのは、実際に目の前でバグが検出されてゆく様を見ることができるライブ感のあるコンテストでした。例えば仕様などのテストベースを事前に渡しておき、本番では各チームが一斉にテスト実行、バグレポート提出、制限時間内に見つけたバグがテスト対象の価値向上にどのくらい寄与するかで競う形式です。実況「Bチーム3つ目のクリティカルバグ発見ぇん！！」聴衆「おおおおお
！」だとか。
そもそも名前がテスト「設計」コンテストですからテスコンの主旨はそこには無いとは思いますし、上記のようなコンテストを実現するのは準備がとても大変でしょうけれども、エンジニアとしてはやっぱり動くものを見たかったというのが私の一番の本音です。
思ったよりカジュアルな雰囲気
テスコンが終わって次の講演が始まるまではポスターセッションと企業ブースをうろうろ。仕事でお会いした方もちらほら。東海メトリクス勉強会の同人誌を見たり、バグレポートのパターンを調査する話を聞いたり、CodeIQの問題に答えてどらやきもらったり、ソフトウェア病理学の読書会の方とお話したり、テストエンジニアの声がポストイットで沢山貼られているボードを見たり、テスコンの詳細なドキュメントを見たり…さすがソフトウェアテスト専門のイベントだけあって濃かったですね。
あと、思ったよりカジュアルな雰囲気でした。「どーせISO29119なんて堅いこと言い出す人達の集まりはスーツのおじさんばっかりだろ？」とか偏見持ってて本当にすいませんでした。皆さん、技術が好きなエンジニアばかりです。
八谷さん講演
まずは八谷さんの講演。懐かしのメーラーPostPetの作者であり、ナウシカに登場する飛行機メーヴェを実現させちゃった人。なんでJaSSTにいるのかわからないけど、とても元気の出るお話でした。実況ツイートから1つ引用します。
メーヴェを作った八谷さんの講演 "ロマンスとエンジニアリングがあれば人は空を飛べる" "あと意地と諦めの悪さ" "宮崎駿から「死なないでください」とメッセージをもらった" ヤバイくらい面白い #jasst
— Takuto Wada (@t_wada) 2014, 3月 8講演の終わりに質疑応答タイムがありました。面白いのが、あらかじめ座席の肘掛に貼られたポストイットに質問を書いてスタッフが回収し、まとめてサクサク答えてゆくというスタイル。1000人は入るであろう場所での講演で、こんなに沢山の質問に答える光景は初めて見ました。
パネルディスカッション
続いて大御所同士のパネルディスカッション。お題はテストエンジニアの育成。前置きと自己紹介で多くの時間を費やして結局まとまりませんでしたが、私は「ワクワク・ロマンス・エンジニアリング」というシンプルな西さんの意見に最も同意しました。「パクんなｗｗｗ」って思ったけど。
「技術だよ！エンジニアとしてワクワクする技術を学びなさい。」
パネルディスカッションで、西さんがいいこと言いすぎて、他の人がポンコツにみえた。
#jasst
#fb
— 板垣真太郎 (@ItagakiShintaro) 2014, 3月 8元々は「ワクワク感」って言おうと思ってたんだけど、メーヴェをパクりました。 orz. RT @NoriyukiMizuno: 高い技術への憧れ…必要なものですね。
たしかに表現としては”ロマンス”に近い感じかも。
— YasuharuNishi (@YasuharuNishi) 2014, 3月 8結局目的は果たせたのか。行ってよかったのか。
- テスト設計コンテストを見て、レベルの高いテスト設計およびそれらの優劣とは何なのかを確かめること。
知識が足りなくて理解し切れませんでした。主にテスト要求分析とテストアーキテクチャ設計に関する知識が必要と思われる。本を読むだけではなく、手を動かさないと理解できなさそう。
- テストのイベントに来る人たちの層・人物像を確かめること。
テストが好きなエンジニア。気質は開発エンジニアに通じるが、興味の対象は異なると思われる(普通の開発者はバグ出しが楽しいなんて多分言わない)。
最初は参加費5000円に躊躇しましたし、ソフトウェア開発についてテストは第一の興味ではないのですが、ちょっとでもテストに興味があれば行くと得するイベントだと思いました。
例え話だけで解決に向かうのか? - 技術的負債論
はじめに
以下のエントリがHOTになっています。公開4日後の現在で949はてブです。
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
私は企業で Software Engineer in Test としてソフトウェアの保守性に責任を持つポジションに就いている身ですのでこのテーマに関心があるのはよいことだとは思います。技術的負債そのものについてのエントリは過去にも沢山あるようですが、mizchi さんのエントリは誤解を恐れないシンプルで断定的な書き方ですので多くの人に刺さったのでしょう。
ただ、技術的負債(technical debt)というメタファーが万人に誤解無く伝わるのかは疑問です。時間を借りているのかはピンと来ませんし、財務的負債と異なり返済の義務はありません。また、エンドユーザーに提供する価値よりも負債にフォーカスしてしまうのではないかという懸念があり、以下のツイートと同様の感想を覚えています。
特にソフトウェアを使ってサービスを展開してらっしゃる業界で働く方々におかれましては、メンテナンスコストの多寡がどうあれソフトウェアは資産であるという認識をもつべき。その理解なしに「技術的負債」とか言っちゃうとプログラマ以外にいらぬ誤解を与えかない、と思ってる
— Kazuho Oku (@kazuho) 2014, 2月 21このエントリでは技術的負債のより良い例えを再考し、問題視されていることを解決する指針を示したいと思います。本来1エントリに収まるテーマではなさそうですが、書いてみることにします。
なぜ例えが必要なのか？
例えが必要なのは「誰か」に理解して欲しいから。順を追って考えてみます。
まず技術的負債とは端的な説明をすると、ISO/ICE25000シリーズで言う内部品質における保守性が低いソースコードのことです。読むのに時間がかかる・勘違いしやすい・意図しない影響を生みやすい・テストしにくいという特徴を持ち、バグが生まれやすくなると考えられます。*1
そして、この問題に気づくためには、ソースコードから保守性を感じるスキル(できれば測定するスキル)と、保守性が開発効率と利用時品質に影響することの理解が必要です。
問題に気づいて保守性を向上させようとすると、すなわちリファクタリングが必要になります。当然ながら悪いものほど良くするのが難しく、リバースモデリングスキルとリソースの確保が重要となります。そもそも保守性の低いコードを生まないためのスキル・プロセス、およびそれらを育てるためのリソースも必要になります。
つまり、低保守性の問題に気づいたエンジニアは
- エンジニアに対して「スキルを覚えてください」
-
プロジェクトマネージャーあるいは経営層に対して「リソースをください」
と要求したくなるでしょう。
しかし、低保守性に気付いて問題視するには前述したスキルと理解が必要で、要求が受け入れられるとは限りません。特に後者に何とかして伝えるためにはエンジニア以外にも伝わる言葉を使った方が有効でしょう。そこで「技術的負債」という言葉が生まれたと考えられます。*2
「健康リスク」というもう一つの例え
技術的負債の生みの親であるウォード・カニンガム氏は、保守性を高める設計を考える時間を省くことを「時間を借りる」、低保守性のコードと付き合うことを「利息を払う」、リファクタリングすることを「返済する」と例えています。
良い気もしますが、保守性が一定以上のコードを生むのに必ずしも時間がかかるわけではないと思いますし、負債というと「返さなければならないもの」と誤解される恐れも懸念されます。技術的負債という言葉は WyCash というポートフォリオ管理システムの開発にて生まれたので、周囲の理解が得られたのではないでしょうか？もっと万人向けの例えは無いのでしょうか？
といったところで「健康リスク」です。通じるかどうかは相手次第ですが、私的には「健康リスク」の方がより多くの方に誤解無く伝えられると思います。いかがでしょうか。*3*4
| 健康リスクがある → 病気になりやすい | 保守性が低い → バグが起こりやすい |
| 健康リスクを避ける習慣：タバコとお酒はほどほどに・よく寝る・手を洗う・歯を磨く・栄養バランスの良い食事をとる・運動する | 保守性を高める習慣：OOなどの設計手法・TDD・リファクタリング・レビュー・フォローアップ・lint・バージョン管理・インシデント管理・ドキュメンテーション |
| 健康リスクを高める習慣があっても、病気になるとは限らない。 | 保守性が低かったとしても、バグが起こるとは限らない。 |
| わかっちゃいるけどやめられない | わかっちゃいるけどやめられない |
| ハードボイルドに生きる | ハードコーディングする |
ソフトウェアメトリクスを用いた正攻法
例え話を持ち出したのは
- エンジニアに対して「スキルを覚えてください」
-
プロジェクトマネージャーあるいは経営層に対して「リソースをください」
という要求を満たすためでした。エンジニア個人レベルの問題なら理解だけで解決に向かうかもしれませんが、集団に理解を求めてアクションを期待する場合はプラス何かしらのプッシュが必要になることでしょう。また、リソースを求める場合は理解の有無によらず「どれくらい必要？」と返ってくることでしょう。ROIも求めないといけないかもしれません。
これに答えるためには、
- 保守性の定量化
- 開発対象における保守性とバグの相関算出
- 保守性向上を行った場合に回避できるであろうバグの修正コスト算出
- 保守性向上を行った場合に発生するであろうバグの修正コスト算出
- 保守性向上のための設計・コーディングコスト算出
をやるのが正攻法と考えられますが、なかなか真正面から取り組むのは難しいでしょう。そこで頼りになるのが先人の研究成果です。残念ながら私は沢山の研究事例を知っているわけではないのですが、知る限りで一番近いのが昨年に公開されたMITのD論でIron Bridge Software社の事例を研究したものです。*5
- 手続き・構造共に複雑な箇所を変更すると、0.414件のバグが発生することが予測される。
- 手続き・構造共に単純な箇所を変更すると、0.059件のバグが発生することが予測される。
- 最も構造の複雑なソースファイルのバグ密度は、最も単純なそれの3倍。
- 複雑な箇所の担当に回されると生産性は半分になり、離職率は10倍になる。
という興味深い数字が出ています。保守性の重要性を説くだけならこれだけで十分なのではないかと思います。
「よその事例だけじゃなくて、うちではどうなのよ？」と聞かれるかもしれませんが、ツールで測れる保守性に関するソースコードメトリクスを適当に選んでバグ数との関係を散布図にプロットして相関係数を算出するだけならハードルはそんなに高くありません*6。コストの算出まで踏み込む場合はやったことがないのですが、経験的なバグあたりの修正時間・関わる人々・人件費を用いればなんとか求められるのではないかと考えています。
保守性に悩む現場では上記のような定量化を試みて発表してくれたらなと願います。*7
まとめ
- ソフトウェア開発における技術的負債とは保守性の低下したソースコード
- 低保守性はエンジニア以外には伝えにくいので「技術的負債」「健康リスク」という比喩を使う
- 例えだけでは不十分な場合は定量化をやっていこう
*1:9126 ではプロセス品質→内部品質→外部品質→利用時品質 の影響を説明するわかりやすい図があったが25000では無くなってしまった。実はある？私が知らないだけだったりして。
*2:"technical debt" の生みの親の文章からもそう読み取れる http://c2.com/cgi/wiki?WardExplainsDebtMetaphor
*3:健康や病気に例えている例は早稲田大学の岸知二教授からJEITAのワークショップで聞いたことがある http://home.jeita.or.jp/cgi-bin/page/detail.cgi?n=646&ca=1
*4:ソフトウェア病理学という昔の本が参考になりそう http://www.slideshare.net/mori_ryuji/sig-26157700
*5:http://dspace.mit.edu/handle/1721.1/79551
*6:どんなメトリクスを選ぶのか、相関があるように見えるだけじゃないのか、など考えると難しい
「知識ゼロから学ぶソフトウェアテスト」 を読んで
読むきっかけ
1年ちょいくらい前からでしょうか。ソフトウェアテストの世界で活躍する方々(JaSST とか WACATE とか) に出会う機会がありました。で、現在縁あってその人達と仕事をする機会が生まれたのですが、テストってちゃんと学んだことなかったんですね。そこで試しに JSTQB-FL の問題に100問くらい臨んでみて4割くらいは怪しい結果(合ってても自信が無いやつが多い) だったので「知識足りないなぁ」と。じゃあJSTQB-FLでも勉強するか？といったところ、人気のある入門書が改訂されたとの情報を得て読んでみました。こっちの方が読みやすそうだし。
感想
すごくおすすめ。テストエンジニアはもちろん、開発エンジニアも1冊通してコモンセンスとした方が良い内容ではないかと思いました。
開発エンジニアにとって身近なテストはユニットテストとレビューだと思います。ユニットテストでどのようなテストケースを作れば良いかは「2章 ホワイトボックステスト」「3章 ブラックボックステスト」の知識が必須になります。レビューでも有効です。「4章 探索的テスト」「6章 テストプラン」は開発エンジニアにとって直接必要となる場面は少ないと思いますが、テストエンジニアがどのような仕事をしているのか知っておくとコミュニケーションがしやすくなると思います。
テストエンジニアの中にはシステムテストが中心でコードはほとんど見ない(読めない)という方もいるかもしれませんが、制御フローテストのカバレッジやソースコードのメトリクスの知識があれば狙いを定めたシステムテストができるのではないかと思います。
とにかく読みやすいので、なじみの無い内容でも全部読めます。にもかかわらず、あんまり省いている感じがしません。注釈や参考文献がしっかりしてるのもとてもいいです。ただ、"知識ゼロからの" と銘打っていますが、未経験者では恐らく身にならないのではないでしょうか。入門書ではありますが、何らかの開発プロジェクトをキックオフからリリースまで通して経験してからの方が得られる知見が圧倒的に大きいでしょう。
私的に得られた知見・再認識した知見をまとめると以下のようになります。
- 同値分割・境界値分析・デシジョンテーブル・状態遷移・制御フロー、基本に沿って全部やれ。悩むのはそれからだ。
- パフォーマンスのバグはできるだけ早く見つけろ。パフォーマンスのテストが実行可能になったらすぐテストを始めて定期的に行え。
- 開発エンジニアもテストのこと覚えろ。テストエンジニアもコード読めるようになれ。(※本には直接書いてない)
開発とテストの境目
P206 には開発エンジニアとテストエンジニアの区別がつきにくくなってゆく時代の流れが書いてあります。テスト自動化が現在進行形で進化・浸透していること、Software Engineer in Test というポジションが登場していることからも、私もその流れを感じています。互いの専門性は存在しつつも、開発エンジニアはテストを覚える必要が、テストエンジニアは開発を覚える必要が出てきているのではないかと思います。
ただ、私の視点・感覚では両者は混ざり合っていません。この間のデブサミ2014のスピーカーも似たようなことを言っていました。開発エンジニアからの歩み寄りとしては、本書のようなテスト技術書を読んだり、JaSST や TEF なんかに参加するのが良いのではないかと思います。丁度 JaSST'14 は3/7(金) 3/8(土) に開催されます。私は行ってみる予定です。
カナダのバンフへスキーに行ってきた
どっか海外旅行行こうかと思っていたところに「カナダでスキーすっぞ」と友人達からお声がかかったので行ってきた。滅多に行かないだろうからブログに残しておく。そもそも海外へ行くのは15年ぶりくらいだったし。
今回行ったのはバンフ。成田空港からカルガリー空港まで10時間弱。そこから西へハイウェイで1時間ちょいで着く。
行ったスキー場は以下2か所。日本だと宿からスキー場まで歩いて行くことが多いけど、バンフでは宿からバスに40分くらい乗っていく。バス代はリフト券とセットだった。
装備はこんな感じ。顔をすっぽり隠すのがよい。でないとしぬ。何しろマイナス20度だとかが普通の世界なので、耳が出ていたりすると危険。今回は Amazon で "ロシア 帽子" で検索して出てきた帽子を買っていったが、これが大正解。町を散策するときもずっとこれをかぶっていた。
これが真冬のカナディアンロッキーだ。 スキー場へ向かうバスからの景色は大体こんなん。ひたすら雪と針葉樹と岩。土は全くと言っていいほど見えない。ある程度の高度になると木が無くなる傾向にある。たまに川や湖が見えるが、凍っていて湯気が出ている。こわい。
いよいよスキー場。カナダのスキーというと…「ヘリで頂上まで連れていかれて雪崩に追われながら木々の間を滑り抜けてゆく」 というイメージを勝手に抱いていたのだが、ちゃんとリフトがあったしコース標識もあった。そりゃそうか。この写真の太陽の真下にチリみたいなものが映っているのがわかるだろうか。これはチリではなくダイヤモンドダストだ。最初は目の前にキラキラした粒が見えて「飛蚊症か？」と思ったけど、5秒くらいで気づいた。マイナス10度以下でないとみられないらしい のだけど、このときはもっと寒かった。寒かった…。
日本と圧倒的に違うのは広さ。山1つ全部スキー場かよってくらいの広さ。伝えられるいい写真が無いが、ぽかーんとしてしまうくらい広い。さすが人口密度が日本の 1/100 なだけはある。コースも当然たくさんある。上級コースの名前の中には "Think Again" だとか "Hell's Kietchen" など、ユーモアの効いたものがあって面白い。
疲れたらロッジなどの建物で休む。治安はそこそこいいらしく、板にはほとんど鍵がかけられていない。"Lock it or Lose it !!!" なんて警告は書いてあるけど。
ごはんはスキー場でも町でも肉とポテトが中心。サーモンも名産らしい。バッファローの肉なんてのも食べた。うまい。でもポテトはきつい。ポテトは意識しないと避けられない。飽きたり苦手だったりしたら "Veggie" って表記されたメニューを食べるのがいい。
北海道のスキーも何か所か行ったけど、バンフのスケールは段違いだった。国内のスキーに飽きたら特攻してみるのがいいのではないだろか。お金はかかるけど、きっと満足できると思う。
