読者です 読者をやめる 読者になる 読者になる

Hacker Tackleでアジャイルテストにおけるアンチパターンについて講演しました。 #hackt

3行まとめ

  • Hacker Tackleっていう激熱なITデベロッパー向けのイベントで「アジャイルテスト」について講演しました。
  • みなさんがつらいのはわかるけど、解決したいなら本気で取り組む必要があるので、参考になれば幸いです。
  • あと、アジャイルにテストしている人達といろいろ議論したいです。

Hacker Tackleとはなにか

hackertackle.github.io

HackerTackleは、プログラマのための総合技術イベントです。 「ハッカー・タックル/博多・来る」の意味を持つイベント名には、多くのハッカーが博多に来て、さまざまな議論をぶつけあう場になればという思いがこめられています。 イマのプログラマにとって必要な知識を切り取った、さまざまな技術に関するセッションを用意しています。 ぜひ博多に来て、新しい技術を吸収し、議論をぶつけあってみませんか?

なんかMMA感がありますが、まさしく登壇者の多様性と豪華さはすごかったです。 主催者と登壇者のみなさまほんとうにありがとうございました。 僕はホクホクして帰りました。

名前の由来はハッカータックル、ハカタクル、博多来る というかんじです。 今年で2回目ということでして、昨年に引き続き参加させてもらいました。

どんな講演をしたのか

speakerdeck.com

50分間の講演だったので、30分はスライドの内容をかいつまんではなし、20分は会場と意見交換をしました。

スライドでは次の3つのアンチパターンを紹介しました。

  1. 過剰自動化
  2. モック酔い
  3. TDD不要論

で、時間の都合上2番目のモック酔いは軽くだけふれて、1と3を中心的に話しました。 これら3つはまぁ私のまわりではよくあったので、その状況における原因とか自分なりの対策をまとめました。

ちなみに1の話ではかの「自動化ハイ」についても口頭で言及しました。 @関西のテスト自動化コミュニティ

また、アンチパターンだけはなしても「こいつうさんくさい」とおもわれるかなぁとおもったので、 一部ではありますが、自分達のチームがどのようにテストにとりくんでいるかも紹介しました。

いまは少しずつですが、手動テストもテスティングフレームワークで書くような下地をつくりはじめているところ。ってかんじですかね。

会場との意見交換では、いろんな質問がでておもしろかったです。 きょんくんの現場ではこういったことは困っていないのか?といったものから、参加者さまの現場で困っていることについての方針相談などなど。

まとめ

アジャイルって「素早く順応する」ってことが大切だとおもうので、みなさんも自身含めてどんどん変化していくとよいのでは!!!とおもっています。

改めてになりますが、Hacker Tackleの運営のみなさまによって素晴しい会になったとおもいます。本当にありがとうございました。 また、来年も参加させてもらえると非常にうれしいです。

Specification by Example: How Successful Teams Deliver the Right Software

Specification by Example: How Successful Teams Deliver the Right Software

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

「アジャイルコーチの道具箱 - #見える化実例集 -」を読みました。 by mari

kyon_mmさんの友人のmariです。今回はkyon_mmさんのブログを借りて、「アジャイルコーチの道具箱 -見える化実例集-」の書評を書かせていただきました。

本書はすごく楽しんで読めた一冊でした。著者、翻訳者のみなさまありがとうございます!

leanpub.com

付箋愛

まず感じたのは、「溢れんばかりの付箋愛!」です。 私も会社でガンガン使っています。 すぐかけて、貼りたいところに貼れて、 誰かに渡すことも簡単で、すぐ共有できる!

付箋がもたらす情報共有力、見える化力ってすごいですよね。 私も好きです、付箋。

肝心の本書の内容について。

基本的に説明が書いていないので、好き嫌いは分かれる本なのかもしれないなぁと思います。 どういう理由でそれをやるのか、を誰かに教えてほしい人には読みづらく感じそうです。 説明がないと物足りない!って人は、別の本を読んだ方がいいと思います。 私はどちらかというと感覚でものをとらえるタイプなので、 非常に好きなタイプの本でした。

Exampleが基本1頁に1つの構成になっていて非常に読みやすいです。 読むというより、観るって感じが近いかもしれません。 長い文章が一切なく、半分以上が図となっており、感覚的に脳に入ってきます。 本書で取り扱うExampleの中にも、図や表を利用するExampleが多く出てきますが、 それらの効果を本書をもって証明しているように思います。 すぐにできそうなシンプルなExampleばかりで、すぐにでもTryできそうです。

見えるようになるとそもそも何が嬉しいのか。

  1. 気づかなかったことに気づくようになり、今まで考えなかったことを考えるようになる。
  2. コミュニケーションが増える。
  3. 知らなかったことを知ることができる。
  4. 成長できる。
  5. 楽しいと思える機会が増える(ここは人によりそうですね。)

楽しんでチームと仕事をする、という部分に特化しすぎているように思える部分もありますが、 「楽しむ→やる気がでる→効率よく仕事ができる」 とつながっていくので、仕事をするうえで楽しむって必要なことなんじゃないかな、と自分は思います。 「仕事に楽しさは求めていない」という人もいますが、 私は楽しむことで、自分の人生が金銭的にもメンタル的にも豊かになると信じています。 本書には、楽しんで仕事をする、チームうまくやる、ための工夫がたくさん詰まっています。

下記に、特に自分の心に響いた部分をいくつか引用し、レビューの締めとします。

シンプルに。

更新されなくなると信用されなくなり、どんどん使われなくなっていく。

どんな情報もツールも同じだし、よくあることだと思います。 メンテナンスされない膨大な利用ガイドや、設計書を含め、 身に覚えがある人も多いのではないでしょうか。 始めは凝ったつくりにするものの、結果として自己満足になっていて、 他の人からすると、情報や装飾が多すぎて使いつらいとか、読みづらいとか、 そういう使えないものになり、更新されなくなっていく。 作った人は、せっかく作ったのに、とイライラし、結果としてチームの雰囲気が悪くなる。

私は身に覚えがありすぎて、「本当それ!」と叫びそうになりました。 言うのは簡単ですが、実行するのは難しい。 「シンプルに」考える、「シンプルな」ものをつくる、 このあたりの考え方は、人生をより楽しく生きるためにも必要な要素だと思います。

自信のニコニコマーク!

これならひとりひとりの感覚が可視化できるし、 毎日、進捗や達成可能か?と考えることができます。 そして達成できるためにできることはないだろうか、と考えるきっかけとなると思います。 なんとなくバーンダウンを見て、「はい、見た!終わり。」ってなっているチームや、 そもそもバーンダウンなんて見てません!ってチームに取り入れると意識が変わりそうですね。

情けない話、自分のチームではそういうことがありました。 こういう工夫をしていたら、もっとよいチームになれたような気がします。

評価しよう。改善、調整をしよう。必要ないなら、使うのをやめよう。

やめ際がわからなくて、ずるずると必要のないことをやってしまったり、 引き際がわからなくて、余計なことを言ってしまったり… たくさん思い当たるふしがあります。 ずっとやってるからといって、必要かどうかを考えずにやり続けている レガシー的な何かとか。 常に物事は変わっていくのだから、常に評価して 必要がないのであればやめるというのはよく考えたら当然のことですね。 全然できていないけど、それは頭を使っていないってことなんだなぁと思いました。

テスト(コード)レビューの方針 書きなぐり版

牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。

元記事 「自動化対象のユニットテスト単体テスト)の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs

僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな?」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日

牛尾さんのコメント「どっかに書いてありますか?もしあったら記事にはります。」

僕のコメント「書いていません!」

僕のコメント「書きました!」

続きを読む

パターンに関する質問と、パターンとはアートなのかデザインなのか考えてみた

最近、 TwitterとかFacebook で @ryuzee さんとか @katzchang さんが「スクラムにおけるImpediments Listはどう扱うのか」みたいなやりとりがありました。 そのやりとりの途中で @jcoplien さんが日本で開催した組織パターンに関する講演の話がでてきました。それは @m_seki さんのブログにレポートがあって先ほど読みました。http://d.hatena.ne.jp/m_seki/20131110#1384094601

で、これらを読んで思ったことを書きながら、TODOってなっていることを @ryuzee さん、 @katzchang さん、 @m_seki さん、 @kawaguti さん、 @jcoplien さん、 @haradakiro さん @digitalsoul0124 さんあたりに質問してみたいなぁと思っています。

ちなみに話題にあがっていた Impediments Listは僕は扱いやすいように管理しておけばListでもバックログでもKPTでもなんでもOKで、いつ解決しないとやばい問題であるかが最初に考えることですかね。出てきた問題によって置き場が変わります。

パターン

パターンが何であるかのより具体的な説明として @jcoplien さんが説明した様子を @m_seki さんは次のように書いてくれていて、「パターンは複数の問題に対して使える」という理解は僕もなんとなくしています。

研修のテキストに「1つのパターンが、いちどに解決する問題は一つだけ」という誤訳があり「一度に一つずつ適用する」が正しかったのですが、これを起点に「一つのパターンが複数の問題を解決するよ、それは...」といった具合にコプリエンが暴走してくれました。

彼の話を全部受け止められた自信はないのですが、がんばって説明します。

まずたくさんのいろいろな向きのフォースが存在する空間があるモデルを考えます。

# ホワイトボード全体にいろんな向きの矢印(フォース)を描いてくれました。だれかホワイトボードの写真残ってない?

つぎにいくつかの矢印を「対象の問題」として選び囲み「それらを解決する、調和させるのがパターンだ!一度に複数の問題が解決されるんだよ!」っぽいことを話してました。

うぉー。なにを問題と思うかも自分たちに任されてる!パターンはきれいに並んでるわけじゃなく重なり合ってる!この説明はいいなあ . . . あ、あれ?

今思うと変だな。あのときは腑に落ちたんだけど...。これってパターンじゃなくてコンテキストとフォース、解決策ですよね。それのカタログがパターンなんだろうか...。

問題すら自分たちで選べるっていうのは自分たちのチームの雰囲気と合ってていいなあと思いました。でもカタログの方はあんまりぐっとこないんですよね...

@m_seki さんの気持ちと一緒かどうかはわからないけれど、パターンのカタログがわくわくしないみたいなのは僕も組織パターンというか、PLoPのなにかを読んでいても同じ気持ちになります。(ちなみに僕はパターン言語好きです) 僕がよく説明するのは「パターンとパターン言語の関係は、業界用語と業界の会話のような関係で、業界用語リストを見てもわくわくしないけど、どの用語を組み合わせるのか、新しい用語を発見するときはちょっと楽しい」みたいな感じです。パターンとイディオムは区別すべきなのですけど、ここでは関係を表現する比喩として使いました。 TODO この認識であっているか聞いてみる

文中にある1度に1つのパターンを適用しなさいは組織パターンというパターン言語(6.2 漸進的成長を主眼にして話した内容)だったからだと思う。どっちにしても1つのパターンが複数の問題の解決に役立つというか、どの問題に使うかは自由で、それは自分がどんな文章組み立てるかは自由なのと似ていると思う。 カタログとしてのパターンやパターン言語は僕の中では、辞書とか文例集とかが近いです。でも、組織パターンやいくつかのパターンに関する名著からも伺えるようにそれはなんらかのストーリーであるべきだし、うまく書かれているものは読んでいて感情移入できるくらいに読めるものもありました。例えば、僕は Fearless Change というパターンの書籍ではいくつかのパターンは読んでいて興奮しました。

でも、どんなに瑞々しい文章でも、自分たちが体験してことばにならないものを触り続けている瞬間の感覚とはかけ離れてしまうなぁと思います。恋愛小説を読んでいる時と自分の恋愛の違いみたいに感じます。恋愛しなくなったり、まともな恋愛をできていないと、恋愛小説を読んで羨ましくなることはあると思います。パターンと毎日楽しく触れ合っている人には、カタログになったパターンはきっとつまらなくうつってしまうときがあるし、そうではないときもある。くらいの印象です。

日本語でも「つまらない」と表現することはいろんな事象に当てはめられるし、「旅行で休む」という行為においてもいろんな問題(仕事で忙しい、家事が大変、日本のキッチリさが鬱陶しい)を解決することもできます。 でも、その1フレーズだけでその人の状況が表現できないので、パターンというのは言語の1部であり、全体性が重要であり、パターンを見出すというのはある種の言い回しと状況を具体的にするという行為なのかなぁと思いました。 TODO もう少し具体的にしたいけどよくわからないので、聞いてみる

パターンはデザインかアートか

最近「芸術とは何か」みたいなのを勉強しているので、パターンはデザインなのかアートなのか考えてみました。(芸術という言葉が面倒(歴史的経緯が面倒)なので、とりあえずアートという言葉で言います。

パターンをみつけたり組み合わせたり、明確にしていくという過程は「デザイン」なのか「アート」なのか。 現代的?に捉えると、アートであるならば問い、未来、可能性の性質が強くなりますし、デザインならば答え、過去の性質が強くなると思います。(僕はデザインとアートの違いをそう捉えている) そうではなく、本来的な意味を考えると、アートは問いと答えを連続させていく行為であり、その蓄積物のスナップショットが文化であるがゆえに、文化とは迷いの象徴であるというようにも捉えることができます。

パターン、パターン言語に触れているその瞬間は「問いと答えを連続させていく行為」としてのアートに近い存在、もしくは「アートとデザインの両方を持っている」と思います。 また、先にあげた業界用語のように比喩に上げたものでさえも同じように言えると思います。日本人が時折バラエティなどで「あぁ、この漢字、熟語の成り立ちはこうだったのか」と感心するのはまさにそういった例なのではないかと思うのです。

デザインの性質が近いパターンとはおそらく本来的な意味のパターンを表現していないのだと僕は思います。 問いや意思や可能性を広く深くしようとするという思いが感じられるから、複数の問題を解決するために使えるパターンになるのではないでしょうか。 TODO 全体的におかしいところがないか聞いてみる

次回

「UXを重視したいという風潮が、建築、都市計画、ITの業界で起きているのは、アートとデザインが再び統合されようとしているのではないか。もしくは似非アーティスト、似非デザイナーをあぶりだす時代の到来か」みたいな話を書きたいと思っています。(予定は未定

組織パターン

組織パターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系

ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系

2015年に読んだうさみみエンジニアがよかったと思う書籍

2015年は会社の業務外でまるでアウトプットができませんでした。特に下半期はやばかったです。 自分なりにいろいろ大変な時期だったので、学んだことはたくさんありました。学んだことの量で言えば多分仕事し始めてから一番学んだ1年だった気がします。

で、振り返りを書くのは大変だし、むしろそういうのは、 Scrum Gathering Tokyo 2016 で話すので、自分の記録として恒例の「2015年に読んだうさみみエンジニアがよかったと思う書籍」をまとめておきます。

組織

HARD THINGS

HARD THINGS

ワーク・ルールズ!―君の生き方とリーダーシップを変える

ワーク・ルールズ!―君の生き方とリーダーシップを変える

How Google Works (ハウ・グーグル・ワークス)  ―私たちの働き方とマネジメント

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

エクストリームプログラミング

エクストリームプログラミング

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

組織パターン (Object Oriented SELECTION)

組織パターン (Object Oriented SELECTION)

エッセンシャル スクラム

エッセンシャル スクラム

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

リーン開発の本質

リーン開発の本質

テスト

絵で見てわかるシステムパフォーマンスの仕組み

絵で見てわかるシステムパフォーマンスの仕組み

Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design

Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design

プログラミング

Groovy in Action

Groovy in Action

  • 作者: Dierk Konig,Paul King,Guillaume Laforge,Hamlet D'arcy,Cedric Champeau
  • 出版社/メーカー: Manning Pubns Co
  • 発売日: 2015/06/27
  • メディア: ペーパーバック
  • この商品を含むブログを見る

コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方

コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方

C#実践開発手法 (マイクロソフト公式解説書)

C#実践開発手法 (マイクロソフト公式解説書)

.NETのエンタープライズアプリケーションアーキテクチャ 第2版 (マイクロソフト公式解説書)

.NETのエンタープライズアプリケーションアーキテクチャ 第2版 (マイクロソフト公式解説書)

Lean Architecture: for Agile Software Development

Lean Architecture: for Agile Software Development

C#プログラマのための.NETアプリケーション最適化技法 (Programmer's SELECTION)

C#プログラマのための.NETアプリケーション最適化技法 (Programmer's SELECTION)

  • 作者: Sasha Goldshtein,Dima Zurbalev,Ido Flatow,サシャ・ゴルドシュタイン,ディマ・ズルバレフ,イド・フラトー,株式会社プロシステムエルオーシー
  • 出版社/メーカー: 翔泳社
  • 発売日: 2013/07/23
  • メディア: 大型本
  • この商品を含むブログ (4件) を見る

要求

ソフトウェア要求 第3版

ソフトウェア要求 第3版

バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る

バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る

誰のためのデザイン? 増補・改訂版 ―認知科学者のデザイン原論

誰のためのデザイン? 増補・改訂版 ―認知科学者のデザイン原論

ユーザーストーリーマッピング

ユーザーストーリーマッピング

ゴール&ストラテジ入門: 残念なシステムの無くし方

ゴール&ストラテジ入門: 残念なシステムの無くし方

  • 作者: Victor Basili,Adam Trendowicz,Martin Kowalczyk,Jens Heidrich,Carolyn Seaman,Jurgen Munch,Dieter Rombach,鷲崎弘宜,小堀貴信,新谷勝利,松岡秀樹,早稲田大学グローバルソフトウェアエンジニアリング研究所ゴール指向経営研究会
  • 出版社/メーカー: オーム社
  • 発売日: 2015/09/26
  • メディア: 単行本
  • この商品を含むブログを見る

IMPACT MAPPING インパクトのあるソフトウェアを作る

IMPACT MAPPING インパクトのあるソフトウェアを作る

価値論

哲学概論 第1部 (岩波文庫 青 654-2)

哲学概論 第1部 (岩波文庫 青 654-2)

哲学概論 第2部 (岩波文庫 青 654-3)

哲学概論 第2部 (岩波文庫 青 654-3)

新カント学派の価値哲学―体系と生のはざま

新カント学派の価値哲学―体系と生のはざま

行動経済学

お金と感情と意思決定の白熱教室: 楽しい行動経済学

お金と感情と意思決定の白熱教室: 楽しい行動経済学

文章

数学文章作法 基礎編 (ちくま学芸文庫)

数学文章作法 基礎編 (ちくま学芸文庫)

数学文章作法 推敲編 (ちくま学芸文庫)

数学文章作法 推敲編 (ちくま学芸文庫)

数学

初等整数論 ―数論幾何への誘い― (共立講座 数学探検 6)

初等整数論 ―数論幾何への誘い― (共立講座 数学探検 6)

超高速グラフ列挙アルゴリズム?〈フカシギの数え方〉が拓く,組合せ問題への新アプローチ?

超高速グラフ列挙アルゴリズム?〈フカシギの数え方〉が拓く,組合せ問題への新アプローチ?

経済学

コーポレート・ファイナンス 第10版 上

コーポレート・ファイナンス 第10版 上

コーポレート・ファイナンス 第10版 下

コーポレート・ファイナンス 第10版 下

看護学

看護覚え書―看護であること看護でないこと

看護覚え書―看護であること看護でないこと

看護の基本となるもの

看護の基本となるもの

今年はあんまりテストの書籍を読んでいないなーと思ったのですが、テストはもっぱら論文ばっかりだったのと、チェッキングよりもテスティングに力をいれていたという事情があってあんまり書籍には結びつかなかった感じですかね。。。

いつもよりはいろんな分野の書籍を読むことになったので、来年もこの調子でもっといろんな分野の知識を統合できるといいなぁと思っています。

来年の個人的な目標は「価値基礎勉強会」をやることですね。

要求を明確にしたり、整理したり、共有するときに参考にしている書籍リスト

背景

次のようなリプライが飛んできたので、後輩も絡んでいることだし kyon_mmが普段仕事で要求を明確にしたり、整理したり、共有するときに参考にしている書籍リスト を公開してみる。

これらの書籍の情報から得られるPOとしての振る舞いを僕は常日頃、自他共に求めている。読んだことがなくても体験で得られるものもあるとは思っている。僕はその体験を待つだけの忍耐がないのと、自分に恥を感じるのと、知的好奇心からこれらを読んだ。ちなみに全部合わせて2年くらいで読んだと思う。

ビジネスモデル系

ビジネスモデル・ジェネレーション ビジネスモデル設計書

ビジネスモデル・ジェネレーション ビジネスモデル設計書

バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る

バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る

ビジネスモデルYOU

ビジネスモデルYOU

キャズム

キャズム

HARD THINGS

HARD THINGS

ゴール指向

IMPACT MAPPING インパクトのあるソフトウェアを作る

IMPACT MAPPING インパクトのあるソフトウェアを作る

ゴール&ストラテジ入門: 残念なシステムの無くし方

ゴール&ストラテジ入門: 残念なシステムの無くし方

  • 作者: Victor Basili,Adam Trendowicz,Martin Kowalczyk,Jens Heidrich,Carolyn Seaman,Jurgen Munch,Dieter Rombach,鷲崎弘宜,小堀貴信,新谷勝利,松岡秀樹,早稲田大学グローバルソフトウェアエンジニアリング研究所ゴール指向経営研究会
  • 出版社/メーカー: オーム社
  • 発売日: 2015/09/26
  • メディア: 単行本
  • この商品を含むブログを見る

ソフトウェア開発全体系

実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識-

実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識-

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

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

アジャイルソフトウェア要求 (Object Oriented SELECTION)

アジャイルソフトウェア要求 (Object Oriented SELECTION)

ソフトウェアシステムアーキテクチャ構築の原理 第2版 ITアーキテクトの決断を支えるアーキテクチャ思考法

ソフトウェアシステムアーキテクチャ構築の原理 第2版 ITアーキテクトの決断を支えるアーキテクチャ思考法

  • 作者: ニック・ロザンスキ,オウェン・ウッズ,榊原彰,牧野祐子
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2014/09/26
  • メディア: 大型本
  • この商品を含むブログを見る
システムアーキテクチャ構築の実践手法 (IT Architects’ Archive)

システムアーキテクチャ構築の実践手法 (IT Architects’ Archive)

Lean系

リーン開発の本質

リーン開発の本質

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

リーン・スタートアップ

リーン・スタートアップ

Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)

Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)

リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)

リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)

Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES)

Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES)

ユーザーストーリーマッピング

ユーザーストーリーマッピング

アントレプレナーの教科書

アントレプレナーの教科書

要求仕様系

ソフトウェア要求 第3版

ソフトウェア要求 第3版

要求工学知識体系 第1版

要求工学知識体系 第1版

ユースケース駆動開発実践ガイド (OOP Foundations)

ユースケース駆動開発実践ガイド (OOP Foundations)

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?

ユーザエクスペリエンスのためのストーリーテリング -よりよいデザインを生み出すストーリーの作り方と伝え方 -

ユーザエクスペリエンスのためのストーリーテリング -よりよいデザインを生み出すストーリーの作り方と伝え方 -

モデル系

UMLモデリングの本質 第2版

UMLモデリングの本質 第2版

形式手法入門―ロジックによるソフトウェア設計―

形式手法入門―ロジックによるソフトウェア設計―

抽象によるソフトウェア設計−Alloyではじめる形式手法−

抽象によるソフトウェア設計−Alloyではじめる形式手法−

VDM++によるオブジェクト指向システムの高品質設計と検証 (IT architects’ archive)

VDM++によるオブジェクト指向システムの高品質設計と検証 (IT architects’ archive)

見積もり系

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

ソフトウェア見積り

ソフトウェア見積り

ソフトウェア見積りのすべて 第2版 ―現実に即した規模・品質・工数・工期の予測―

ソフトウェア見積りのすべて 第2版 ―現実に即した規模・品質・工数・工期の予測―

IA/UX系

誰のためのデザイン? 増補・改訂版 ―認知科学者のデザイン原論

誰のためのデザイン? 増補・改訂版 ―認知科学者のデザイン原論

IAシンキング Web制作者・担当者のためのIA思考術

IAシンキング Web制作者・担当者のためのIA思考術

インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針

インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針

IA100 ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計

IA100 ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計

  • 作者: 長谷川敦士
  • 出版社/メーカー: 株式会社ビー・エヌ・エヌ新社
  • 発売日: 2009/10/28
  • メディア: オンデマンド (ペーパーバック)
  • この商品を含むブログを見る
一人から始めるユーザーエクスペリエンス

一人から始めるユーザーエクスペリエンス

ユーザビリティエンジニアリング原論―ユーザーのためのインタフェースデザイン (情報デザインシリーズ)

ユーザビリティエンジニアリング原論―ユーザーのためのインタフェースデザイン (情報デザインシリーズ)

リスク系

熊とワルツを - リスクを愉しむプロジェクト管理

熊とワルツを - リスクを愉しむプロジェクト管理

ピープルウエア 第3版

ピープルウエア 第3版

ソフトウェアテスト293の鉄則

ソフトウェアテスト293の鉄則

人月の神話【新装版】

人月の神話【新装版】

チームの文化系

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道

Software in 30 Days スクラムによるアジャイルな組織変革

Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

  • 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,黒沢 健二,松永 肇一,美谷 広海,祐佳 ヤング
  • 出版社/メーカー: 早川書房
  • 発売日: 2012/01/11
  • メディア: 単行本
  • 購入: 21人 クリック: 325回
  • この商品を含むブログ (36件) を見る
組織パターン (Object Oriented SELECTION)

組織パターン (Object Oriented SELECTION)

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

RE:統計的品質管理の功罪

概要

SNSで『統計的品質管理の功罪』というスライドについての意見を多数みかけたので、僕も読んでみたので感想を書きます。 ゆえに発表場所では多くのコンテキストが語られているかもしれませんが、スライドからはこう読めるよっていう感じです。 僕の感想は一言でいえば「タイトルは違うほうがいいし、SQCの勉強してないですよね?よく言えますね。」って感じです。 お酒飲みながらのLTだったらありかもーくらい。

もしSQCに村を焼き払われたという事情があるのであれば、SQCを徹底的につぶすくらいの非難なり、手法なりもってくるほうがよいのではないでしょうか。 つまり、マサカリ投げるなら徹底的に投げろ。

発端や背景

SNSで下記のスライドに対する言及が多数ありました。

"辛いよねー"と共感するか、"コンテキスト広く言いすぎじゃないか?"と批判するかの2つが多かったように見えます。

私もこのような行数あたりのバグ数に関してつらい思いをしたことはありますが、やはりこれはあまりにコンテキストが広すぎるという感じです。

kyon_mmの所感

「ソフトウェアの品質を評価するのにコードを一切見ていない」というのは、たしかによくないかもしれないですが、 では、この現場では例えば「こういった意味で品質の良いコードです」ということは伝える努力はしたのでしょうか? それがコードを見なくてもわかるようにです。

僕は、プログラマーじゃない人にでも品質を評価してもらうというのは重要だと考えています。 最終的にはスポンサーがコードの品質にもお金を払っているわけで、 スポンサーにも同じように説得する場面が存在するであろうからです。

説得しなくても十分な場合もあるでしょう。 そのときには、この品質管理担当さんがいなくてもいいか、 もしくはもっと違う方法を取ってもらうことでサポートしてもらう必要がありそうです。

仮に「コードは、実物を見ないと評価できない」とあきらめるのであれば、 僕はそういった態度についてエンジニアとしてある種の諦めを感じますし、 あまりソフトウェア開発の未来に前向きではないなという印象を持ちました。

GitHubのIssueやコメントを求めているってどんだけ狭い話なの?

35ページに「僕たちが望んでいるもの」として、おそらくGitHubのIssueやコメントのような画面表示がありました。 そして次のページには「現実」として行数とエラーの原因や発生フェーズが書かれていました。

どちらも必要な情報だと僕は思っています。また、どちらかだけをほしいってどんだけ狭い領域で仕事しているんだよって感じです。 むしろ、この2つで足りるとでも思っているの?大丈夫?って感じが。

例えば後者の情報が長年蓄積され、共有されたことで「何をつくるかをハッキリさせることが重要だ」(要件定義のミスはやばい) という共通認識を多くの人が持っています。それらにどう対応するかはプロセス次第です。 まぁ、この情報の取り方が正しいかを考えていない人もいるでしょうが。(個々のプロジェクトでほしい情報は異なるよねー。的な)

Web上で気軽にコードのちょっとした設計について議論できるのもとても大切です。 ただ、IssueというかコメントもWeb画面上でひたすらやりとりされて、必要な情報が一切ないというのはいろんな場面で遭遇します。 あとは、楽しいと思っているだけで実際の効率について考えたことがどれくらいあるのかというのも気になります。 個人的にはチャットツールにも同じことを感じています。 (自分はSlackを使っていますが、チームメンバーで使い方ルールをつくりました。)

アジャイルの人はこれだからとか言っている人達もおかしいよね

このスライドに対してSNSの反応でアジャイルの人だからーというのが見受けられましたが、 どこにアジャイル要素があったのかわかりませんでした。

永和だから?Rubyって書いてあったから?GitHubっぽいページがあったから?コードの話をしたから? これらであれば、アジャイルかどうかなんて全く関係ないです。

仮にこの発表のコンテキストがアジャイルだったとして、 少なくとも資料上からはアジャイルに顧客への価値提供、チームビルディング、改善を考えているようには見えませんでした。 つまり、アジャイルな発表ではカケラもない。

なにがしかのイメージでアジャイルだからーとか言うのはよくないかと思います。

SQCの例としてはあまりに貧弱ではないだろうか

イベントの都合かもしれないのでなんとも言えないのですが、 この内容でSQCというのはあまりにも貧弱な内容で、お前が言いたいのはなんなんだって感じです。

SQCについてなにか思うところがあるなら、本来のSQCの使い方とどうずれてしまっているのかなど言うべきだし、 SQCがクソだと思うなら、こんな指標値よりもっと使えるものあるんだけど!とか言えばいいだけです。 とりあえずエンピリカルなソフトウェア工学の書籍や論文を片っ端から読んだらどうなんですかね。ええ。

こんな貧弱な批判でやつらを倒せるとでも思ってんのか!てきな。

コードを書籍で例えて考えてみる

最後になりますが、僕の考え方としてコードを書籍でたとえます。 初めてのアウトプットになるのでほころびがあるかもしれませんが、僕はよく頭の中でこう考えているという具合に思ってください。

まず、コード行数というのは、書籍でも行数にあたります。 それで、行数あたりの間違いが少ない方がいいっていうのは、例えばですが、書籍でも行数あたりの誤字脱字がどれくらい少ないかという話にも通じます。 書いてあることに整合性がないとか、間違った情報が書かれているとかも、行数ごとに見ることもできます。

例えば、素晴らしい発見を伝える書籍でも誤字脱字があまりにも多かったり、表現が統一されていなさすぎると読みにくいですよね。 なので、その書籍に「ユニークですごい」「文章力が低い」みたいな評判がたつかもしれません。

では、書籍同士の比較をするときに、文章力の低い人と、文章力の高い人で同じテーマの書籍について同様に「行数あたりの間違い」で見れるでしょうか? 例えば、文章をうまく書ける人であればそもそもだらだらと書く必要がありません。 そう、ここがソフトウェアのコード行数と同じようになるのです。シンプルに伝えることが1つの美徳とされます。 (もちろんそうではない分野もあるでしょうが、1例としてです)

ですが、行数あたりの誤字脱字やどれくらい整合性のとれない主張を書いてしまうかを数値で見えるようにすること自体はとても意味があります。 例えば、その著者のなかでは成長のメトリクスに使えるかもしれません。 実際には編集さんがものすごい頑張っていてそのようなメトリクスは世の中にないかもしれませんが、 編集さんがどのように思っているかを話すと、ある程度いえる数値があったり、どうやってレベルなどを感覚的に分類しているかはありそうですよね。

このように「じっくりと読んでわかる品質」もあれば「伝聞ベースの統計的に見てもわかる品質」などもあります。 なので、個人的には行数で計測すること自体にはあまり問題ないと思っています。 当たり前ですが、どうやってその行数を使うかが重要であり、くだらない方法をかざす人を見ただけで方法論を非難するのはちょっと芸がないです。