SQuBOKによる無知の知の体験

SQuBOKv2読破会アドベントカレンダー4日目のブログエントリーです。

www.adventar.org

SQuBOKの入手動機と読破会への参加動機

SQuBOKというのはこれです。ソフトウェア品質体系ガイド。

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)

いかにも堅そうな名前の本を手にした理由は 「一応専門家のはしくれだし*1持っておくか」くらいのもので、読もうとは思っていませんでした。 ぱらぱらとめくってみると、文体は淡々としており、図はあまり無く、かみ砕いた説明も無く、 色気の無い本だなという印象でした。読破会*2の主催者は「宝箱のような本」と言っていますが、 一体こんな色気の無い本のどこが宝箱なのかと思っていました。 読んだ今では、BOKにごてごてとした読者への配慮を求めるものではないということがわかったのですが、 読む前はBOKと名のつく書籍を手にするのは初めてだったこともあり、そのような印象を持っていました。

また、ソフトウェア開発に関するBOKとしてはIEEE発のSWEBOKが筆頭に挙がると思います。 SWEBOKがあるのにSQuBOKが作られたことは疑問でした。そして、SQuBOKは日本発のBOKというのも疑問でした。 SQuBOK V2の"はじめに"には次のことが書かれています。

日本のソフトウェア品質への取り組みは、製造業を中心として発展した品質のマネジメントに学ぶところから始まった。 それは一定の成果を得たものの、その技術や知識は各企業の現場それぞれで暗黙知の状態だった。 SQuBOKガイド第1版の策定動機の一つは, 日本で培われたソフトウェア品質に関する暗黙知形式知化することにより…

こんなことを書くと何人に石を投げられるかわかりませんが… 日本で培われたソフトウェア品質に関する暗黙知に参考になるものがあるのかと。 製造業を中心として発展した品質のマネジメントが一定の成果を出したのかと。 NTT, NEC, 富士通, 日立, 東芝, 松下などの日本企業よりも、 Microsoft, Apple, Google, Amazon, Facebook などの米企業の方がソフトウェア工学において先を行っているのではないかと。

そう、思っていました。 だから、日本からSQuBOKが生まれたのは不思議でした。 いや、読んだ今でもその疑問は解けていないところもあるのですが、読む前は実に不思議でした。

そこで読破会の誘いを受けて、参加することにしました。 私に知識があるのか無いのかを確かめるために、 本当に宝箱のような本なのかを確かめるために、 日本発のソフトウェア品質の知見が参考になるのかを確かめるために。

あと、読破会の主催者がV1の策定メンバーであったことや、 8人という少人数であることも参加を後押しする理由でした。

無知の知テーブル

読破会の進め方は毎月集まって30ページずつ程度を読み進めながら議論をするというものです。 2015年の1月から始めて今月で終わる予定なので全部読んだわけではありませんが、 大体読んだとみなして、ここでSQuBOK全体の中で私が知っていたことと知らなかったことをまとめてみました。 結果、知らないことが多かったことを認識できました。なので、これを無知の知テーブルと呼ぶことにします。

  • ● : 半分以上知っていた
  • △ : 一部は知っていた
  • × : 全くと言って良いほど知らなかった
項目 ●△× コメント
1.1 品質の概念 × なじみがあったのはISO25010と狩野モデルくらい。デミング賞のデミングってここで出てくるのかー
1.2 品質マネジメントの概念 × 日本における品質マネジメントの歴史があるんだなーと
1.3 ソフトウェア品質マネジメントの特徴 × 理解はともかく冒頭の文が熱い!
2.1 ソフトウェア品質マネジメントシステムの構築と運用 × 日本企業、昔から努力してたんですね。QCサークル,品質会計,Qfinityとか色々初見。
2.2 ライフサイクルプロセスのマネジメント × プロセスモデルだけならまだしもライフサイクルと言われると難しい
2.3 ソフトウェアプロセス改善のマネジメント × 名前しか知らないものがほとんど。三階層SEPGやばい
2.4 検査のマネジメント 1ページだけで、まぁそうだよねという内容。
2.5 監査のマネジメント × 経験がないので全く知りませんでした。
2.6 教育・育成のマネジメント × 知っていたのはETSSだけ
2.7 法的権利・法的責任のマネジメント × PL法なんてあったなーとか
2.8 意思決定のマネジメント × IPD, 今でもやってるんでしょうか
2.9 調達のマネジメント 外注するなという話が欲しいところだけどBOKには書かれないかなぁ
2.10 リスクマネジメント × ISO/IECの規格があるんですね
2.11 構成管理 仕事でやってるのでここはまぁまぁ
2.12 プロジェクトマネジメント × PMBOKの名前くらいしか
2.13 品質計画のマネジメント トピックがベンチマーキングだけなのはいいんでしょうか?
2.14 要求分析のマネジメント 深そうな項目名だけど難しいことは書いていない
2.15 設計のマネジメント まぁやりますよねという内容
2.16 実装のマネジメント まぁやりますよねという内容
2.17 レビューのマネジメント 大事
2.18 テストのマネジメント やけに手厚い
2.19 品質分析・評価のマネジメント どうマネージするのかは理解が浅い
2.20 リリース可否判定 合格基準って意外とわからない
2.21 運用のマネジメント × 経験がないのでさっぱり。理解できないところも多い。
2.22 保守のマネジメント × 経験がないのでさっぱり。理解できないところも多い。
3.1 メトリクス だいたいは
3.2 モデル化の技法 PAD, DSLは初見。
3.3 形式手法 経験はありませんが、ツール名・効果・労力に関して話に聞くことがあります。
3.4 品質計画の技法 × そういうのもあるのか
3.5 要求分析の技法 清水吉男さんの本を読んだくらい
3.6 設計の技法 デザインパターンやTDDなど馴染みのものもありますが、ほかにもあるんですね。
3.7 実装の技法 契約による設計が初見
3.8 レビューの技法 3.8.1については名前は知らないけど実はやってるというケースが多いのではないかと
3.9 テストの技法 SQuBOKの中で一番ボリュームがあるのではないか。"3.9.9テスト技法の選択と組み合わせ"は熱い!
3.10 品質分析・評価の技法 知っているのは2割くらい
3.11 運用の技法 × 仮想化よくわかりません
3.12 保守の技法 コードクローン分析は保守の技法なのか?
3.13 使用性の技法 黒須先生の本を読もうかなと
3.14 セーフティの技法 × 安全とは一体うごごご
3.15 セキュリティの技法 テスト, これ以外に無いのかなと

SQuBOKを読んで良かったこと

どの知識領域をどれだけ知っているかを認識でき、どこを伸ばしてゆくかを考える機会ができました。 BOKでありポインタ集なので知識そのものが増えるわけではないのですが、知識を増やすためのキーをたくさん得ることができました。 キーというのは、用語・人名・書籍名・規格名のことで、SQuBOKを読む前はこれらのキーを全く知らなかったことを考えると、それだけでも収穫だと思います。

ソフトウェア品質マネジメントの歴史の中に日本の大企業や日本人が多く登場することも初めて知りました。 実は20年前の方がプロセス改善やマネジメントの面では力を入れていたのではないかとも考えさせられました。

また、少人数で集まって読むというスタイルは、SQuBOKを全て読むために欠かせないことでした。 一人では最初から最後まで考えながら読むということは、BOKに対してはできなかったと思います。 今でもSQuBOKを開くと読破会の情景や議論したことを思い出します。 この知識領域は誰が詳しかったなとか、あのトピックは意見が分かれたなとか。

主催者の言うように宝箱のような本なのかは読んだ今でもわからないのですが、 私の職務に関わる広大な知識領域において、有志の協力を得て無知の知を体験できたことは、とても貴重であることは間違いありません。

おわりに

あっさりとしたエントリにしようと思っていたのに結構書いてしまった! SQuBOKV2読破会アドベントカレンダーはまだまだ続きます。 次は @Kazu_cocoa さんです。よろしくー

*1:私はQAではなくSEPGやSoftware Engineering Consultantの立ち位置です

*2:詳細は1日目のエントリーを参照

情報会議#3に参加してみて

情報会議

johokaigi.org

ソフトウェア開発チームの情報共有を扱う会に参加しました。 ちょうど最近チーム開発ツールに関する仕事をしていたところ、たまたまTwitterでPeatixの申し込みを見つけたのがきっかけです。 ただ、その時は既に満員で「満員かー」とツイートしたところ、主催者の@so1_さんから「キャンセル出たので参加しますか?」とリプライが来て参加することに。 そんなこともあるんですね。

グループワークでは幾つかの少人数グループに分かれて各々のお題について議論しました。 私がいたグループでは「情報共有ツールを導入する効果の定量化を求められてしまった」という悩ましいお題について考えました。 思い付きをポストイットに書いて貼っていくスタイルで考えたのですが、数名で前向きに考えると短時間でも結構アイデアが出てくるものですね。 アイデアは以下の5種類でした。単なる効率化では済ませないところが重要かなと思います。

  • 指標を考える前にまず導入目的や期待するを明確にする
  • どの程度利用されているかという指標
  • 現在の仕事の効率化に関する指標
  • 新しい価値に関する指標
  • 定量化せずに済ませる荒業

主催者の一人がIncrements社員(Qiitaの会社)ということもあってか、参加者は事前にQiita:Teamでお互いを知ったり情報共有に関する議論を重ねていました。 Qiita:Teamに触ることができたのも良い収穫でした。

あと、@so1_さんから誘われてLTしました。5分なのでLightningな感じで喋りました。人前で話す機会は仕事含めてここ2年でぼちぼち増えてきたのですが、実はLTと名がつくものはやったことが無かったり。最短記録更新。(最長は3時間)

情報共有のスコープ

単にソフトウェア開発のための情報共有といっても、人によって思いつくものは違うと思うのです。 VCS,BTS,CIといったチームのためのエンジニアリングツールで行われる情報共有なのか、 プロジェクトマネジメントツールなのか、チャットなのか、メーリングリストなのか、wikiなのか、身内(社内)SNSなのか、対面の対話なのか。

情報会議がどこに主眼を置いているのか今でもよくわからないのですが、今のところは 純粋なエンジニアリングツールやプロジェクトマネジメントツールがカバーする情報というよりは、 ナレッジシェア、メンバーが欠けてもタスクが継続できるようにする、モチベーション向上…といったことをするための情報に 重きが置かれているのではないかという所感です。

この先、議論を進めるには共有したい情報とは何なのか、共有したいシチュエーションとは何なのかを具体的にし、 幾つかの典型例をもとに掘り下げてゆく必要があるのではないかと考えています。

情報共有ツールの利用に必要なメディアリテラシー

Webベースの情報共有ツールを利用するにはいくらかのメディアリテラシーが必要だと思います。

  • フリーワード検索, 検索式
  • カテゴリ, タグ
  • @アカウント名 で通知
  • いいね, thanks
  • 個々人のアカウントごとにアイコンがある
  • 全員でばりばり書く
  • 共同編集する
  • コメントをつける
  • 編集履歴をつける
  • 編集リクエストを送る
  • Markdown などのテキスト記法
  • リアルタイム性によるツールの使い分け
  • チームメイトが喜ぶように/傷つかないように

これらはブログ・SNSVCSを使用している人にとっては自然と身についていることだと思います。 しかしそういう人ばかりではないのではないでしょうか? 日本でSNSmixiFacebookによって広まりましたが、そのうち構造のある文章をブラウザから書いた経験のある割合はどの程度なのか。 @masskanekoがアカウント名だとわかる人がどの程度いるのか。 書いが方が良いことと書いてはいけないことの区別をつけつつアクティブに使える人がどの程度いるのか。 そういったメディアリテラシーを学ぶ機会が必要だと思うのです。

大学や高専ではコンピューターリテラシーと呼ばれる授業があり、ファイルやフォルダの概念、文書作成、メール、インターネット検索エンジンについて学ぶ機会があります。 現在ではもしかすると情報共有ツールを円滑に利用できるだけのリテラシーを教えているのかもしれませんが、今の働き盛りの年代の方々を主な利用者とするのであれば 組織内での教育努力が必須なのではないかと思います。もちろん、そういった努力があまり必要でない組織もあるかと思いますが、それはかなりラッキーなのではないでしょうか。

次回参加するかどうか

情報共有そのものについて考えたのは初めてですが、浅くないなと思いました。 道具はもうあるんです。でもうまく使うにはかなり人間にフォーカスした努力を行う必要があるのだと思います。

当たり前ですが、情報共有ってツールが登場する前からも行われていたはずです。人間にフォーカスするのであれば歴史に学ぶのが良いのかなと。 Wikiが登場する前はどうしていたのか。 Web技術が無かった頃はどうしていたのか。 掲示板か。回覧板か。 実はタバコミュニケーションや飲みニュケーションのような昭和のアナログな手法でまかなっていた情報共有が現在の情報共有ツールの役目に相当するのではないか。 100年前はどうだったのか。

もちろん、テクノロジー面からのアプローチもまだまだこれから発展すると思います。 botが一週間のまとめ記事を作ったり、個々人の端末の画面やキー操作から困っているかどうかを判別したり、手首につけた社員証デバイスが今日の気分を読み取ってグループウェアに送ったり…。

そういう世界もあるなぁと思いつつ専門家になる気は全くありませんが、少なくとも身の回りのチームが円滑に仕事できるにはどうすれば良いかを考える機会として、次があれば参加したいと思いました。

長崎旅行記

なんでまた長崎に

8月12日 長崎SWQuality&DevelopmentGathering2015(長崎県) というイベントに参加することをきっかけに長崎に行きました。主催の池田暁さんと最近付き合いがあるのですが、池田さんが急に故郷への貢献に目覚めたらしく、誘われることとなりました。

今思い出しても、よく関東から長崎くんだりまで足を運んだものだと思いますが、「九州って行ったことないし、カステラでも食って返ってくるか。」くらいの軽い気持ちで行くことにしました。どうせ遠くへ行くなら何日か観光をしようと思い、5泊6日滞在することにしました。

とりあえず江山楼のちゃんぽんは美味しかったです。ちゃんぽんって、私の生活圏に出す店が無く、全く食べる習慣が無いのですが、これは時々食べたくなると感じました。

イベント本編と清水吉男さん

イベントのテーマが派生開発でしたので、XDDPやUSDMの生みの親である清水吉男さんの講演がメインコンテンツでした。無料のイベントなのに、よく来てくださったなぁと思います。

清水さんの講演は、基本的には著書の内容に沿ったものであり、そこに自身の開発経験・コンサルティング経験を交えながら要点を説明したものでした。USDM形式のように要求仕様を書くというのは、「計画重視のプロセスはソフトウェア開発に向いていない」という先入観があった私からするとあまり現代的な印象が無かったのですが、氏の主張である「大半は仕様の問題」「要求の裏にある理由は安定している」「良い要求仕様は良いソースコードを導く」を考えると、20年経っても通用するのではないかと思わされました。

ただ、その理解はまだ感覚的なものなので、USDMとユーザーストーリー、XDDPとXP、変更設計書とDesignDocについては、共通点と違いを理解しておきたいと思いました。

他のセッションでも興味深い話があったのですが、質疑の時間が十分でなかったのが心残りでした。

イベント後は長崎らしい料理を前に懇親会が行われました。魚だ。この街は魚がうまいんだ。

清水さんは非常にきさくな方で、氏の手法の話はもちろん、昔の開発経験、コンサルティング経験、一度は挫折した話、技術がいかに生産性を高めるかという話、大学教育の話、私のちょっとしたキャリアの相談など、色々なお話をすることができました。

市内めぐり

イベントの翌日は主催の池田さんが市内をめぐるツアーを組んでくださいました。

グラバー邸を軍服を着て歩いたり、孔子廟で華麗なやかんさばきを見たり、中華街で角煮まんやハトシを食べたり、出島で昔のビリヤードをしてみたり…など、記憶に残る観光をすることができました。観光できる場所が多い街というのは良いものですね。昔から海外との交流があった街というだけあって、文化的資料はもちろん、現在の建物や街並みにも特徴がありました。勿論、Ingress のポータルの数も多くありました。

長崎市街は路面電車が多く走っているのも特徴でした。私は路面電車には全く馴染みが無いので非常に新鮮でした。路面電車は昭和の産物なのかなと思っていましたが、この街では現役であり、市民の重要な交通網として動いていました。この旅行でも何回も利用した、ありがたい存在です。

(孔子廟で撮影した写真をうっかりデコってしまったもの)

(出島の施設にあった昔のビリヤード台。大きな耳かきのようなキューで玉を突き、立っている棒を倒すとか倒さないだとかのルールで競う。)

離島で釣り

あとの日は完全な自由行動です。釣り道具を持ってきていたので釣りをすることは決めていたのですが、どこで釣るのかを決めていなかったので、ホテルで調べることにしました。「どうせなら島に行きたい」と思って調べてみると "飛島磯釣り公園" という場所が、設備の整った磯釣り公園の割にはそこそこいい代物が釣れるという情報を得て、船に乗って行くことにしました。長崎港では高島との往復料金と釣り施設の入場料がセットになったチケットが売られており、2040円と思ったより安い値段でした。

飛島磯釣り公園のある高島までは、長崎港から伊王島経由で30-40分くらいだったでしょうか。甲板でビールを飲んで風景を見て眺めていたせいか、あまり長いとは感じませんでした。港から釣り施設へ向かうバスがあったのですが、道中を歩いて楽しむことにしました。

釣り施設への途中には海水浴場がありました。海はとてもきれいな色をしており、珊瑚の中を色鮮やかな小魚が泳いでいるのが遠目からでもはっきり見え、南伊豆や沖縄を思い出させるものでした。しかも、人はまばらで、思う存分泳いだり、砂浜で転がることができます。いいですね。海水浴場はこうでなくては。しかし、BGMとして「粉雪」がかかっていたのはしばらく忘れることができそうにありません。

いよいよ釣り場へ。磯釣り公園という名前がついているだけあって、足場がしっかりしており、竿を出せる場所も広いです。入口近くに小さな釣り具屋さんがあり、船のチケットを見せると入ることができます。ついでに餌のオキアミとアミエビも買いました。

オチから言うと、まぁまぁ釣れるのですごく楽しいです。施設の奥には、沖へ向かってのびる足場(写真)があるのですが、そこは水深が結構あります。人はあまりおらず、魚もスレていないようで、色々な場所に落とし込むだけでもアタリがあって楽しいです。

主な釣果は、カサゴメジナ、アイゴ、ハタの仲間と思われる何か、ノコギリダイ、ハコフグでした。他、名前のわからないものも釣れましたがわからずじまい。ホテルの冷蔵庫を生臭くすることは気が引けたので基本的にはリリースし、その日に食べる分だけその場で柵取りしました。釣り場の近くには水道があるので、そこでさばくことができます。

精霊流し

8月15日、高島から長崎市街に戻ると精霊流しが行われていました。そこら中で爆竹が鳴り響き、山車のような精霊船が引かれていく様を見ると、祭りにしか見えません。しかし、精霊船に取り付けられた遺影を見ると、爆竹の音もどこか物悲しく聞こえてきます。チリンチリンアイスを食べながら1時間ほど見ていました。

あくまで弔いであって見世物ではないのですが、その物珍しさからして観光的には見物する価値のあるものでした。爆竹の赤い箱ごと火をつける場合が通常で、中には問屋から卸したような爆竹詰め合わせのダンボールに火をつける場合もあり、音も煙もすごいことになります。YouTube でその様子を見ることができます。

平和公園

終戦記念日である8月15日に訪れようかとも思っていたのですが、ぼんやりと釣りができるくらい平和になったことを実感した方が終戦記念日らしいと思い、翌日16日に訪れることにしました。公園内はとても広く、多くの慰霊碑があり、それらを見るだけでも平和ボケした私の頭にも刺さるものがありました。

そんな場所でXMPバースターを撃つのは趣がありました。

いいところだった

ここ何年か、国内旅行というとスキーばかりでしたし、九州自体初めてだったということもあり、大いに楽しむことができました。街並み、歴史、海、魚介が好きなら楽しむことができると思います。

また、今回の行程は半分くらいは一人だったのですが、今まで一人旅はしたことがありませんでした。日本の中でも訪れたところが無い地方がまだまだ多いので、もっと気軽に旅行をしてみたいですね。

やり残したこと

カステラ食ってねぇ!

5か月の糖質制限実験

背景

小太りを通り越してデブになりそうな勢いがあったのでなんとかしようと思ったのですが、

という強い意志がありました。あと、結果にコミットしたくなかったし…(どうでもいい)

といったところで

1日6,000キロカロリーを食べて太らなかった男の人体実験が凄すぎる | パレオな男

という情報を得たことをきっかけに、流行しているらしい糖質制限食を知って、試してみることにしました。ダイエットというよりも「本当にカロリーって関係無いの?どうなの?」ってのを自分の体を使って実験したい!と思ったんですよ。さすがに1日6000キロカロリーは摂取しようと思いませんでしたが。

実施期間は1月中旬から6月中旬の5か月間です。7月になった現在でもズルズルと続けています。

結果

ゆっくりだけど体重が減りました!

あと、健康診断の数値も尿酸値が少し基準値からオーバーした以外は特に異常はありませんでした。自覚症状も特にありませんでした。

項目今年去年
血圧 118/74 118/76
総蛋白 7.7 7.2
γ-GTP 39 52
中性脂肪 114 142
HDL-C 54 48
LDL-C 132 110
尿酸 7.1 6.6
HbA1c 5.0 5.1

 めでたしめでたし!

計画

…ということを実行する前に考えたことがあります。少しググるとわかりますが、糖質制限食は、推奨する意見と警告する意見の両方があります。はっきり言って素人にはどちらが正しいのかわかりません。そこで、以下の中止条件を設けました。

  • 糖質制限を始めるとき(2015年1月中旬)から職場の健康診断がある時期(2015年6月中旬)までを実施期間とし、診断結果に異常が見られれば中止すること。※5か月の誤りなら後から挽回可能という考え
  • その他、体調不良の自覚症状があり次第中止すること。

また、これまで当たり前のように米や麺を食べていたところに急な制限をかけても続かないと予想されることと、なけなしの健康に関する知識を考慮して、食事の制限事項を以下のように定めました。

  • 糖質とは米、麺、パン、粉もの、芋、菓子、糖類を多く含んだ飲料、のことであり、これらが制限の対象である。果物、調味料、揚げ物の衣は制限しない。
  • 朝食には制限を設けない。
  • 昼食と夕食は糖質を摂取しない。
  • カロリーの制限は一切行わない。
  • 空腹を我慢せず、満足するまで食べる。
  • 外食時、メニューの構成上、糖質を制限できないときは摂取しても良い。
  • 旅行では糖質制限をしない。
  • お酒は制限しない。
  • 風邪など病気の際は一時中断して治癒を優先すること

食事の例

さて、これらの条件においてどのような食事を摂っていたかというと、一言でいえば「主食が減った分、その他が増えた」というだけです。自宅での夕食例を幾つか示します。

チキンステーキ, オムレツ, 焼きトマト

アジのなめろう, 野菜の煮物

いなだの刺身 (他、野菜を食べたと思うけど撮ってない)

なんだかお酒が目立ちますが、自宅では飲まない日の方が多いのであしからず。撮るときにお酒があることが多いだけです。ちなみに私はお酒の中でも糖質が多いと言われているビールと日本酒が特に好きです。なんという悪条件。それでも制限しませんでした。

あと、平日は会社で働いているのですが、朝食はカロリーメイト(100円で2本のやつ)とオレンジジュース500ml、昼食は社員食堂で主食を抜くというパターンがほとんどです。昼食で一番多い組み合わせは、{納豆、味玉、菜物か海草の小鉢、魚、味噌汁} です。

主食以外で特に変わったなと感じているのは、卵と豆腐と鶏肉の摂取量が増えたことです。卵は平均2.5個/日ほど食べていると思います。豆腐も週に3パックほどコンスタントに消費しています。オリジン弁当のから揚げや、ローソンのLチキを買うことが増えました。数えてはいませんが、いずれも以前より明らかに増えていることは間違いありません。

実感

数字としての結果は先述の通りで、さしたる異常はありませんでしたが、実感としてどうだったかというと特に精神的にキツイことも無く、身体的な異常の自覚もありませんでした。頭がボーっとすることも無ければ、便秘や下痢になることもありませんでした。

始めた初期こそ食事の見た目に違和感があったものの、2週間ほど過ぎてからは米を食べないことが普通だと思うようになりました。

今では「銀シャリが恋しい…!」「中本の北極が食べたい…!」と思うようなことはすっかり無くなってしまいました。目の前に出されれば食べるとは思いますが、自分から食べたいとは思わなくなりました。

もっとも、飲み会の後にラーメンが食べたくなることはあって、実際4回ほど食べてしまいましたが、基本的には主食を食べないのが普通で、主食とはうっかり食べてしまうとき以外は食べないものという認識です

個人的な継続のコツは、

  • ダイエットではなく実験と捉えること

です。ダイエットと思うと身構えてしまって続きませんが、実験であれば途中でインチキをするわけにはいかない!というバイアスが働くので続けやすくなります。時には途中でラーメンを食べたくなることがあるかもしれませんが、それは外乱による結果と捉えれば良いのです。

これから

実験期間は終了しましたが続けようと思います。運動をせずに糖質の制限だけでどこまで体重を落とせるものか試してみます。健康診断の結果だけで健康面の懸念が無いとは言い切れないのですが、実験以前よりは健康でしょうと思うことにして続けます。

あと、尿酸値が基準値をオーバーしたのはビールしか思いあたるところが無いので、ちょっとだけ控えるつもりです。

さいごに

  • 「運動なんてぜってーやんねー!」
  • 「運動なんてダッセーよな!」

最後のWACATE

あらすじ

WACATEという一泊二日で行うソフトウェアテストの勉強会があります。夏と冬の年2回行われており、もう何年も続いています。「1回くらい行ってみるか」という気持ちで参加したのが2014夏、「冬は夏と違う」という情報を聞いて参加したのが2014冬、そしてそこで賞を頂いて講演を条件に無料で参加したのが今回2015夏です。

WACATE2015 夏 ~ワタシハソフトウェアテストチョットデキル~ 開催概要 - WACATE (ソフトウェアテストワークショップ)

ソフトウェアテストに関わる人のための Biased Position Talk - BPPセッション

www.slideshare.net

その賞というのはBest Position Paper 賞というもので、参加申し込み時に提出したポジションペーパーの中から参加者投票によって選ばれた一位に贈られる賞です。

というわけでお話をする機会を得られました。最初は何か単発の技術セッションを開こうかと思ったのですが、2015夏のメインコンテンツが上位テストレベルの機能テストを主に対象にしたテスト開発方法論である "ゆもつよメソッド" に決まったので、「自分のセッションだけ浮いたことをやってもなぁ」と思い直し、最終的に「ポジションペーパーで選ばれた人のセッションなんだからポジションのお話をしよう」というシンプルな?考えに至り、上記スライドのような内容にしました。BPT(Biased Position Talk)がBPPにかけてあることや、「そもそもポジショントークなのにBiasedって何だよ」というツッコミを待っていたのですが全くなく、無力感でいっぱいです。

業種や職種などのポジションと聞いて語りやすいところから始め、テストに関して意見がこう分かれるだろうなぁと私が想定している点を、聴講者にほぼ二択で突いてゆくというスタイルでお話しました。予想通りなことも、そうでないこともあって面白かったですね。例えば "網羅したい vs 賢くサボりたい"では、「半々くらいかなぁ」と予想していましたが、賢くサボりたい派の方が優勢でした。

そんなこんなで気分良く話していたら時間が足りず、スライド2枚分をカットすることに(テクノロジー/メソドロジーの話と、名君/名人/名作の話)。といっても試しにシャドーで練習したときからそれはわかっていて、何しろ30分の枠なのに練習では60分以上も喋っていて、こりゃダメだわと。なのでこの場でちょっと補足します。

ソフトウェアエンジニアリングにおいて、テクノロジーとメソドロジーはどちらも日本語では「技術」と言われます。区別して訳すならテクノロジーは科学技術、メソドロジーは方法論です。例えば静的コード解析ツールやテスト実装・実行ツールはテクノロジー、ゆもつよメソッドアジャイル開発はメソドロジーです。ソフトウェアエンジニアリングは両方によって成り立っています。そして更に、ソフトウェアエンジニアはどちらを好むかという嗜好があると考えています。コンピューターに計算させたりハックしたりすることに興味を持つのか、概念のモデリングや人々が織りなす社会活動・プロセスとしてのソフトウェア開発に興味を持つのかという嗜好の違いがあると予想しています。WACATE等で出会ったテスター達は、どちらかと言えばメソドロジー寄りなのかな?という感触です。どうでしょうか?以前の私はメソドロジーにはあまり興味はありませんでしたが、今ではあまり偏りが無いかな…というのが自分の感覚です。

話し逃したことをもう一つ。名君/名人/名作の話。これはShu Uesugiさんオリジナルの文章*1を是非読んで頂きたいのですが、これも違いがあるということです。WACATE等で出会ったテスター達は、かなり名人志向だと感じています。私はこの中で選ぶなら名作志向で、あまり「この分野で一番になりたい」とか「負けたくない」とは思うことはそんなにありません。まぁそもそも意識高くないから3つのどれでもない説もありますけどね。

スライドにある項目それぞれについて私のポジションを以下に示します。

  • 業種:情報家電, 自動車, OA機器あたりのエリア
  • 職種:品質を作る立場、品質を明らかにする立場の両方
  • テストレベル:上下両方
  • テスト・品質系:おかしいと思う
  • テストの楽しさ・達成感:品質が向上されたとき
  • きっちり網羅 vs サボりたい:サボりたい
  • 無則とか探索とか:必要だとは思うけど好きではない
  • テクノロジー/メソドロジー:あまり偏りは無い (以前はテクノロジー寄り)
  • 名君/名人/名作:名作

…と述べたように、ソフトウェアエンジニアが置かれている状況から考えられる有効なエンジニアリングと、その人が行いたいエンジニアリングは同じとは限らないと思うんですよね。そして、そのポジションを表明しておくことはWACATEのように色々な背景を持った人々が集まる場では交流のために有効に働くと思うのですよ。あ、勿論「プロならやるべきエンジニアリングをやるべきだろう」という意見はあると思いますが、それはそれで別の議論です。

セッション終了後、「考えさせられました」「あれは同意です」などのポジティブな反応を頂き、何かしら価値を提供できたことに安堵しています。

BPPの選定条件とは

いやーそれにしてもポジションペーパー…立場表明書が選ばれるというのは他に経験が無いので面白いですね。一体皆さんどうやって選んでいるんでしょう?私は3回参加(3回投票)していますが、振り返ると、

  • できるだけ初参加に近い人
  • 背景・動機・これまでの活動・これからの活動に一貫性のある記載をしている人

という条件で選んでいました。背景と動機だけで活動を書いていない人、手書きなどでインパクトがあるだけの人は選んでいません。…という選び方をしていましたが、私の選んだ方は3回とも一位にはなりませんでした。まぁそんなもんでしょう。私もなぜ前回選ばれたのかはわかりません。特に狙って書いたわけでもないんですけどね。機会があれば教えてほしいものです。

夜の分科会:コードの美的感覚を語る会

WACATE本編では結構みっちりとしたグループワークと講義があるのですが、その後、お酒が入った宴会の更に後にも一部の参加者が打ち立てたテーマについて議論する"夜の分科会"と呼ばれる場があります。私も「最後だし何かやっておくか」という動機で "コードの美的感覚を語る会" を開きました。 このような分科会は幾つか開かれて、分科会オーナーでない人達は各自興味のある分科会へ参加します。が、コードの美的感覚を語る会にはあまり人が来ない!アピールの仕方が悪かったのか、コードと聞いて身構えてしまったのか。

ともかく少人数で議論したところ、その分非常に濃い話ができました。ここも詳細に書きたいところですが、さすがに1エントリに書くには長くなりすぎますので今回はやめておきます。一つだけ興味深い意見を出しておくと、「実務において美しいという言葉を使うのは説明すべきことから逃げている」があります。実務に関係の無い感覚的なゆるい話をしようというつもりだったのですが、がっつり実務に関係する議論になりました。疲れた…。

ゆもつよメソッド

さて、自分が出番の話はこれくらいにしてメインコンテンツについて書きます。ゆもつよメソッドはテスト開発方法論であり、漫然と手をつけると漏れや重複を起こしてしまいがちなテストすべきことを他人に説明できるように整理することを目的としており、ISTQBで言うところのシステムテストレベルにおけるテスト分析/設計・機能テストを主な対象としています。

2日間に渡る演習により、既存の資料 *2 *3 *4 だけではわからなかったことが色々とスッキリしました。ただ、テストカテゴリの必要性は実感としての理解には至りませんでしたが、これは場数を踏まないと理解できないことなのだと思います。あと、講義よりも演習の回答を見た瞬間が一番勉強になりました。「あぁ~こういうことを書くのね」と。*5

それにしても疑問に思うのは、ISTQBで言うテスト分析の必要性を肌感覚として理解している人ってどれだけいるのでしょうか。私は経験不足なので実感までは至っていません。恐らくその理解に至るためには

  • 機能テスト向けのクラシックなテスト設計技法を常用し、それだけではダメだという痛い思いをしている。
  • 色々なタイプの非機能テスト
  • システム統合テスト以上のテスト計画

という経験が必要なのだと思います。それともそこまでの経験は必要無くて、普通のテスターなら皆わかっていることなのでしょうか?今度テスターに会うことがあれば聞いてみたいですね。

ありがとうWACATE

WACATEに参加するのはこれで最後にします。

  • WACATEに頼らなくてもテストのことを学んだり、詳しい人にコンタクトできるようになった。
  • 自分で企画したプロダクトを自分で開発することを目指しており、テスターを目指しているわけではない。

というのが理由です。現在は職務上ソフトウェアエンジニアリング方面に舵をきっており、半年程度はそれを続ける予定ですが、その後はBPPセッションのスライドで少しだけ登場した工作の方面にシフトしていこうと考えています。

以前はソフトウェアテストという技術分野があることを知らず、テスターが集まるコミュニティがあることも知りませんでした。デブサミは知っていてもJaSSTは知りませんでしたし、情報処理技術者試験は知っていてもISTQBは知りませんでした。テスターに対する誤解も大分ありましたが、スキルや志の高い方々との出会いにより、それも無くなりました。テストを学んだのは職務上必要になったからという理由がきっかけとして第一にあるのですが、それ以上にWACATEで出会った方々からの影響を受けたことが実に大きいと感じています。

私はこれで最後にしますが、周りにテストに興味がある人・開発経験はあるがテストの経験が無く悩んでいる人・技術者コミュニティにデビューしたい人がいればWACATEを薦めようと思います。

ありがとう!さようならWACATE!

JaSST'15 Tokyo 感想 - 昨年よりは理解が進んだと思いたい

JaSSTソフトウェアテストシンポジウム-JaSST'15 Tokyo

へ行ってきました。2日目だけです。開催されてから幾分日があいてしまいましたが、得たことや思考のために残しておきます。

昨年も2日目だけ行きました。テスト設計コンテスト(テスコン)について肩すかしを受けたという旨の文章を書いたところ、関係者と思われる数名からTwitterでリプライを頂きまして、テスト実施とバグ検出に重きを置くテスティングライブからテスト設計に重きを置くコンテストに移ったという歴史がわかりました。

JaSST '14 Tokyo 感想 - テスコンとテストの人達とは。必要なのはロマンスとエンジニアリングだ。 - MassKaneko.Out

前回から1年経ったわけですが、その間に私はJSTQB FLの勉強をしてみたり*1、SQiPやJaSSTの論文を読んでみたり、昔の雑誌 を読んだりなどしてみたので、今回はもうちょっと理解が進むだろうと踏んだわけです。理解が進むだろうというのは、テスコンもそうですが、もっと言うと「テストをテーマにして大きなシンポジウムを開催できるほど人が集まるものなのか?」について理解が進むだろうということです。

タイムテーブルを見るとわかりますが、今回はセッションのサブタイトルがずいぶんくだけた感じになっていましたね。同じ時期に開催されるデブサミはちょっとずつ固くなっていると感じるのに対してJaSSTはやわらかくしていく方針なのでしょうか。1日目の基調講演、「ウェブよウェブウェブ」、「今夜ビジネスで比べてみました」の3つは聞きたかったのですが、普通に仕事してました。無念。

テスト設計コンテスト(テスコン)

2日目お目当てのテスコンです。テストベースは今回も自動販売機のようです。テスコンのセッションは9:00から始まるのですが寝坊してしまったので9:30ごろに到着。見ることができたのはT研, しなてす, TEVASAKIplus, 1年4組の4チームでした。

一応真剣に聞いてメモをとったつもりですが、時間の割にスライドの内容が濃くて理解し切れませんでした。プレゼンの後に展示されている成果物も読みましたが、どのように工夫したり苦労したりしたのかが読み取れないところもありました。

つたない理解の中での印象ですと、しなてすが手堅く、TEVASAKIplusがオリジナリティと説得力を兼ね備えていると思いました。テスコン参加の説明会ではTest.SSFのプロセスが紹介されるそうですが、TEVASAKIplusの説明にはそれらしい言葉が無く、テスト対象の設計・構造の理解を重視し、機能タイプの分類・脆弱性の発見・悪条件の導出をするという方法は理解しやすく、効果もありそうだと感じました。ただ、全ての思考の起点が機能なのは問題があるのではないかとも思いました。テストタイプによって思考の起点が機能かどうかって異なりません?まぁ、自動販売機の場合はそれで良いのかもしれませんが。

あと、しなてすのプレゼンに対して「テストアーキテクチャが低凝集・高結合になっているのではないか?」という質問があったのが印象的でした。仮にテスト設計にアーキテクチャがあってクラス図のような箱と線で表せたとして、ソフトウェアの設計のように高凝集・低結合が良いのだろうか?と考えさせられました。もしそのような原則があるのであれば、テスト設計についても七つの設計原理(富士通)みたいなものがあるのかもしれませんね。*2

テストに何が求められるのかをテストベースを分析して求めるプロセスと、テスト設計技法を使ってテストケースを求めるプロセスの間に、何か工夫をするプロセスがあった方が良く、それはテスターにとってのmaintainabilityとも言うべきテストの品質を確保するために行うプロセスだというのは直観的にはわかるのですが、それをテストアーキテクチャ設計と呼ぶのが良いのかはよくわからないんですよね。テスコンに出場してる方々は理解しているのでしょうか。*3

おっと、話がそれてしまいました。結果、優勝はしなてす、次点はTEVASAKIplusでした。おお、私の目に狂いは無かった!*4

 テクノロジーセッション:ソフトウェアテストの新潮流

自然言語解析・人工知能機械学習といった技術を用いたシステムの補助により、従来はベテランの経験が無いと勘付けなかったようなテストを、初級・中級者でも行えるようになる*5」とか、「昨今の計算機性能の発達により、"全数テストは不可能" の原則を覆えすことに挑む*6」とか、「レガシーコードを解析して期待値を自動的に生成する*7」といった一歩先を行っていると感じる内容でした。計算機にできることを増やして、人間しかできないことにフォーカスしようという思想が見えるようで好感度大です。

プレゼンの中で「テストにおいて人間にしかできないことが減っていくと、テスト技法よりもテスト対象や欠陥の知識が要求されるようになる。」と言われていましたが、先進的な技術をさんざん述べた後でなぜわざわざ当たり前のことを言うのだろう?と疑問に思いました。もしかして世のテスターの多くはテスト対象の理解や欠陥の知識が不十分でありながらテスト技法の知識だけはあってテスト活動を行っているのでしょうか。そうだとしたら憂慮すべきことかと思います。

クロージングパネル:Michael Bolton の言葉は非常にしっくりくる

f:id:masskaneko:20150304221131p:plain

クロージングパネルではデベロッパーとテスターの関係についてパネルディスカッションが行われました。エモい話とか組織論とかテスターを持ち上げる話なのかとボーっと聞いていましたが、Michael Bolton が出した図を見て目が覚めました。直観的にしっくりくるものだったからです。開発をするときのマインドセットとテストをするときのマインドセットの変化らしく、Critical Distance と題されていました。上の図は私のメモから起こした図なので間違っている可能性があるのですが、こんなような図でした。上下左右4つの文は、何かしら開発やテストをしたことがある人であれば、右の build some of it から時計回りに読めばわかるでしょう。そして、弧を描く複数の矢印の半径の違いは、恐らくテストレベルが高いほどマインドセットを切り替えたりテストで得られたことを開発に活かすのが難しいことを表しているのでしょう。例えば、自分が書いたコードの間違いにユニットテストで気づいて直すことよりも、受け入れテストレベルにおけるユーザビリティテストで「これはイケてないな」ということがわかって、それを開発にどう活かすのかを見出すことの方が難しい、ということを表しているのだと思います。

テスターとは何をする役目なのか、という話もありました。Michael Bolton 曰く、「テスターにはコードを書く権限も、予算を決める権限も、採用や解雇をする権限も、リリースの判断をする権限もない。ではテスターは何ができるのか。プロダクトのクオリティを明らかにすること、認識できるようにすることだ。」とのことです*8。これも納得です。うなずきながら聞いていました。決して期待値と出力を人力でベリファイするロールではないんですね。また、クオリティはどのロールが責任を持つのかという話もあり、デベロッパーだけでもテスターだけでもないという意見がありました。これも同意です。日本では「テスト・品質系」というくくりで職種や技術が語られることがありますが、あれには非常に違和感があります。だからSQiP2014のデベロッパー参加比率が低いのではないかと考えてしまいます。*9

あと、ささいなことかもしれませんが、ゲーム業界のパネリストの方がテストのことを「デバッグ」と呼んでいたのは非常に気になりました。JaSSTとは全く別の機会で他のゲーム業界の方も同じように「デバッグ」「デバッガー」という言葉を使っているのを聞いたことがあるので、ゲーム業界の習慣なのかもしれませんね。

Tester と テスター

先の話でテスターという言葉を使いました。もちろん Michael Bolton はカタカナではなく Tester という言葉を使っています。両方同じ意味と捉える方もいれば、違うでしょ?と思う方もいると思います。私は、日本と海外(どこの国々なのかはわからないが)の違いとして

  • Tester:プロフェッショナル、エキスパートのニュアンス。
  • テスター:システムテスト実行の人海戦術要員のニュアンス。

というニュアンスの違いを感じています。昨年のデブサミDeNAの方が「テスターじゃない、テストエンジニアだ。」と語っていましたのを思い出します。*10

日本のソフトウェア開発現場で全体的にこのような認識がなされているのかはわかりませんが、もしそうだとすればテスト技術やテスターは(Tester であったとしても!)軽視されてしまうでしょう。

テストをテーマにして大きなシンポジウムを開催できるほど人が集まるものなのか?

実際に東洋大学の講堂を埋め尽くす人が集まっているのに何を言っているのかと思われるかもしれませんが、1年前の自分はそう思っていました。また、テスト専門の会社があることを初めて知ったときは非常に驚いた覚えがあります。テスト技術を多少勉強したり、WACATEに2回参加した後の今でも「なんだか不思議だなぁ」と思うところがあります。これについて少し考えてみます。考えるというか、深層心理を吐き出しているだけで整理ができておらず、専門家やテストが好きな方から見ると気分を害すかもしれません。

  1. QAとかテスターとかその辺の人々による内輪感がある。品質を確認する側、管理する側の立場の人、SEPG、コンサルタント、研究者に偏っている気がする。
  2. QAとかテスターとかその辺の人々が単にテストと言うとき、暗黙的にシステムテスト以上のテストレベルを指していると感じる。
  3. 「どのようなプロダクトを作りたいのか?」という前提を全く共有しないままテストの話で盛り上がっているのを見ると空論に聞こえることがある。モデリングが好きなだけで何を作るかあんま興味無いんじゃないか、だとか。
  4. バグを見つけるのが楽しいという感覚が全く理解できない。
  5. 社会科学や心理学的な側面の話が多く、計算機やプログラミングっぽい匂いがしないと感じることがある。

これらは私の勉強不足による誤解かもしれませんし、単に趣向の違いかもしれませんし、もしかするとJaSSTなどの世界にとってまずいことかもしれません。1番目は結構まずいんじゃないかなと勝手に思っています。

とりあえず最近の自分にできそうなこととしては、次回のWACATEにデベロッパーを呼ぶことや、「テスターは刺身タンポポ業じゃないんだよプロなんだよ」と説くことですかね。

以上、JaSST'15 Tokyo の感想でした。昨年よりは理解が進んだと思いたいものです。

*1:合格しました

*2:しなてすには「テスト設計に凝集度や結合度なんてありませんよ」と真正面から跳ね返すロックな返答をして欲しかったのだが、そうはならなかった。

*3:もちろん決勝出場メンバーは理解して論を打ち立てているのだと思いますが、各チームがそれぞれテストアーキテクチャとは何なのか、どう表現できるのかを説明したときに、果たしてそれは同じ概念を指しているのだろうかと疑問に思ったりするわけです。

*4:前回もこんなことを書いたような…

*5:単に仕様書を食わせてあいまいな箇所を見つけるだけのツールなら以前からあった気がするので、これはもっと進んだことをやっているのだと思う。

*6:英語で Exaustive Testing と言うらしい

*7:本来ブラックボックステストで扱われるような期待値の推定のように聞こえたが自信なし

*8:通訳された発言を解釈して書いているので正確ではないかもしれません。

*9:ソフトウェア品質シンポジウム2014(SQiP2014)オープニング:SQiPの紹介

*10:Software Engineer in Test at DeNA

ソフトウェア開発などの技術書の整理

知り合いのソフトウェア開発の技術書を沢山持っている方がブクログを使ってそれらの技術書を整理していました。その方は私と同じ職種なのですが、所持している技術書の傾向が随分異なり面白いと思いましたので、私もブクログを使ってリストアップしてみました。といっても私の所持している冊数はその方の1/10程度ですが。結果は次の通り。


masskanekoの本棚 (masskaneko) - ブクログ

 

どのようなカテゴリを作るかというのは悩むところがあります。そして、どのようなカテゴリを作るかでその方の趣向もわかるのかなと思います。例えば私は「モデリング」「テスト」「品質」「プロセス」といった分け方をしていますが、これは「ソフトウェア工学」というだけでは分類が大ざっぱ過ぎると思うからです。人によってはこれは些細な問題であり、むしろ私が「プログラミング」に分類している書籍をプログラミング言語や実行環境別に分類したいという方もいると思います。

 

あと、せっかくなので簡単でもよいので振り返りのためにレビューを書いてみようと思うのですが、読み返さずにレビューを書けるほど覚えているものってそこまで多くないことに気付きました。あまり血肉になっていない証拠でしょうか…。まぁもう一度読みなさいということですね。