mokky14's IT diary

IT関係の仕事メモ、勉強会の感想など書いてます。

仙台ソフトウェアテスト勉強会のレポート(2015/08)

2015/8/20のソフトウェアテスト勉強会のレポート。

今回はゆもつよメソッドのテスト分析マトリクスを使ったテスト分析のワークショップ。

なお、今回の内容は、勉強会主催者の理解に基いたコンテンツを、更に自分の理解した内容で書いているため、オリジナルのゆもつよメソッドと違う事を書いてたりする可能性があります。しかも自分が内容を理解し切れていません。 予めご了承下さい。

テスト設計三大巨頭

  • 西先生 VSTeP/NGT ツリー型の分析
  • 湯本先生 ゆもつよメソッド マトリクス型の分析
  • 秋山先生 HAYST法 リスト型の分析

テスト分析マトリクスとは?

こんなやつ。

f:id:mokky14:20150821125856j:plain

このマトリクスに対して、テストが必要なところに○を付けていく。

このマトリクスで、テスト全体を俯瞰して漏れがないようにする。
また、関係者でテスト観点についての合意を取るためのネタにする。

なお、このマトリクスは、 +Lhaca に対して作ったもの。

マトリクス要素の抽出

f:id:mokky14:20150820204241j:plain

分割した3つの要素をそれぞれ作成していく。

機能一覧の作成

中項目の導出

f:id:mokky14:20150820194758j:plain

  1. ユーザストーリーを考える
    ストーリーはメイン(ユーザの主利用方法)のシナリオ、サブシナリオを考える。
  2. 作成したストーリーからキーワードを導出する。
  3. システム管理、設定の項目を追加する。
    これらの項目はどのシステムでも汎用的に使える。
    なお、設定は中項目に入れるパターンと小項目に入れるパターンある。
小項目の導出

f:id:mokky14:20150820194950j:plain

抽出した各中項目に対して、小項目を抽出する。

機能テストの導出

f:id:mokky14:20150820201941j:plain

完全なブラックボックスではなく、少し構造に踏み込んで検討する。

  1. 「論理的内部構造」のモデル(上図)に対して、対象機能が扱うデータや操作をマッピング
  2. マッピングしたデータを抽象化してキーワードとする。
  3. 「状態遷移」「異常処理」を追加する。

f:id:mokky14:20150820204129j:plain

非機能テストの導出

f:id:mokky14:20150826123602j:plain

非機能の観点は世の中に出回ってるのでこれをベースに考える。
中項目、小項目で上げた機能に対して、機能を揺さぶる観点から、必要な非機能観点を抜き出す。

マトリクス化

中項目、小項目と、機能性項目、非機能カテゴリを掛け合わせたマトリクスを作成する。

感想、疑問など

  • 何で大項目がないんだろう?
  • 非機能カテゴリ、「機能を揺さぶる観点から」考えると、頭の中で中小項目と非機能のカテゴリを掛け合わせて、必要なものを考える事になるように思う。 突き合わせ結果はエビデンスとして明に残しておいた方が良さそう。
  • 中項目、小項目と機能性項目の掛け合わせ、フルのマトリクスでやる必要ある? 中項目/小項目単位で機能性項目考えてもよいのでは? 無駄に対象を大きくしてるようにも見える。
  • ユーザシナリオをベースに項目を考えること、ユーザのメインシナリオ中心で項目抽出するのは、大事な所からテストするという点で有用そう。

今回は消化不良気味。
次回続きを行うそうなので、その時にはもう少し理解出来るかな。

JaSST'15 東北 に行ってきました

今更公開するのも何だけど2015/5/29のJaSST東北のレポート。 今年のテーマは「レビュー」。

togetter: JaSST'15東北まとめ - Togetterまとめ

現在のレビューに必要な次の一手を把握するレビュー実践ウォークスルー

www.slideshare.net

ドキュメントレビューについて

100の問題があるプロダクトを与えたときの問題検出率は、

  • レビュー:80%
  • テスト:50%

レビューの方が問題が見つかりやすい。 バグは混入してから直すまでの時間が短いほど効率的に修正出来る。

レビューによるコミュニケーション効果

  • レビュー後に、チーム内の認識を一致させることができる
  • チーム作りができる
  • レビューを通して、プロダクトへの理解を深められる

レビューの開始基準

もし、突然レビューを頼まれたら?

  • まともな欠陥は見つからない
  • 何となくレビューすると、書いてあることだけのレビューになる
  • 思いつきでレビューが出来るほどのスキルを持っている人はほとんどいない

構造化されたドキュメントは、短い時間で多くの指摘が出来る。

人にレビューお願いする前にセルフチェックは実施しておいてもらう。
そのスキルもない人だった場合は事前方針を決めてからレビュー。

レビュー対象だけではなく、その対象物のInput情報も一緒に見る。

安達さんがレビュイに求めるレビュー条件

  1. レビュー観点が言えるか
  2. どう作ったかを言えるか
  3. 単純な指摘(誤字、脱字等)ばかりが出てこないか(レビューに耐えうるものか)
  4. 設計相談にならないか

レビュー観点

立ち位置(役割)によって観点は変わる。

  • 開発者:「作れるか?」
  • テスター:「テストしやすいか?」
  • 企画者:「使いやすいか?」
  • マネージャ:「売れるか?」

レビュー観点にも粒度がある。
レビュー観点の粒度の例:

  • 使いやすいものになってるか?
  • 文字は見やすいか?
    • フォントサイズが適切か?
    • フォントカラーは適切か?
  • ボタンは適切なものになっているか?
    • 押しやすいサイズになっているか?
    • 誤解を招く名前になっていないか?

レビュアのスキルによって、観点の粒度(どこまで具体化するか)も調整がいる。

何をどこまで書くか? IEEE830 1998 に情報がある

よくある欠陥

  • 開始・終了条件のアンマッチ
  • 非機能用件の抜け

観点の体系化は目的の整理になる

レビュー実施方法

ラウンドロビン:章毎に別担当にレビューを割り当てる インスペクション:効果は最大だがコストも最大

状況によりレビュー方法も使い分ける必要がある

この本がお勧め。

なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー

なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー

確認方法のシナリオ化

表現形式

図・表を自分の解釈で書き直してみる

テスト因子の洗い出し ラルフチャートを使うとよい

意地悪漢字
裏のワードも書かれているか?

全てやっていると時間が足りなくなるので、どこまでやるかはPJ毎に考える必要あり。

メトリクス

何に使うか?

ソースレビューは、150~200行/時間 くらいが効率が良い。

レビューは個別->全体 の順に。いきなり全体レビューは効率が悪い。

レビューコメントの書き方

レビュー指摘の仕方は一歩間違うと雰囲気が悪くなる。 主語を「あなた」ではなく「私」でコメントする。
× 「あなた」のこの書き方はおかしい
○ 「私」はこの書き方は修正した方がよいと思う

レビューの振り返りはレビューの後すぐやる。短い時間でやる。

改善をより効果的に回すためのレビューへの取り組み (CookPad 松尾さん)

www.slideshare.net

見るものをGitHubに集約

振り返りで人的な負荷が毎回課題に上っていた。
個人の意識だけでは継続が出来ない。
見るものを分散すると、人の負荷になる。
一カ所に集約することで、忘れることもなくなる。

レビュー観点

  • ソフト全体 価値あるソフトになっているか?
  • 計画、ドメイン、設計
  • コード誤り
  • 成果物
  • ドキュメント

チェックリスト

PullReqを出す前にセルフチェックする

静的解析(Dokumi)

変更差分に対してのみ静的解析を行い、コメントする仕組みを用意。 自動的に行う。

まとめ

  • 計算機が出来ることは計算機にやらせる
  • 分散させない

効率的なレビューの運用について (村上さん)

PMPは書類が多い
打ち合わせが多い
実作業<管理作業になる

バグトラッキングシステムで指摘を管理するように

  • 指摘と修正もチケットで管理
  • コミットログで修正履歴を管理

議事録も全てチケットで管理。 全文検索が出来るので便利。

達人の指摘から学ぶレビューのポイント (根本さん)

不具合の印象は強く残っているが、レビュー指摘の印象はあまり残っていない。 喉元すぎると忘れてしまう。

知識がないのにレビューをしなければいけない立場になった。
→達人のレビュー指摘から学ぶことにした

達人のレビュー指摘から観点とキーワードを導出。 自分が同じ指摘出来るようなレビュー観点を作成する 注意するキーワードを見つける

分からない事はすぐに確認。後に回さない。

業務改善コンサルからソフトウェアテスト効率化へ ~ 株式会社SHIFTサービス紹介 ~

テスト支援ツール chibinekoの紹介 https://chibineko.jp/

ライブコードレビューで学ぶ!「納品のない受託開発」を支えるコードレビューの取り組み

倉貫さんパート

レビュー=成果物に対する指摘
マニュアル通りに書けるプログラムはない

人を育てるには、作らせて、指摘するしかない。 教育効果も狙える

相手の事を考えられる人を増やすには?
全てを担当する。 毎週、「成果」を提供する。「時間」を提供するのではない。

仕様変更はビジネス価値最大化のための選択。

ビジネスモデルとビジョンを共有する。
作る物をミーティングで合意して、翌週届ける。
動くソフトウェアが設計書。
設計内容はボード等で説明。後に残す必要はない。

ソフトウェアに求められる特性

  • 常に仕様を追加・変更できること
  • 常にリリース可能であること
  • スピード感を持ち開発できること
  • 不具合はすぐ修正可能であること
    完全にはなくせないが、検知できること。放置しないこと
  • 上記の特性により、持続して変化できること

ソフトウェアは塩漬けにはできない。 外的環境が許さない。何もしなくてもOSやミドルウェアのバージョンアップが発生し、追随しなければならない。

西見さんパート

www.slideshare.net

ソースコードで全てを回す

以前はペアプロでコードを共有していた。効果はあるが時間がかかる。 レベルの高い人同士であれば、コードレビューで理解し合えると気づいた。

出来ない人がコードレビューするのは時間の無駄。
一人前の人は「良いコードは何か?」の共通認識を持っている。

ランチタイムのディスカッションで共通認識の醸成をやっている。

レビュータイミング

  • ローンチ前の全体レビュー
  • 本番リリース前レビュー
  • リリース前レビューは毎回実施

レビュー観点

  • 意図を読み取れるソースコード
  • テストコードは書かれているか
  • リリース時に問題が起こらないか
  • 障害時のリカバリは考えているか、問題時にすぐ対処できるか
  • 環境周りの変更はないか

読みにくいソースコードは「読みにくい」と素直に言う。

価値観

コードレビュー 7つの秘訣

  • レビューの観点を明確にすること
  • 我が身に返る事を恐れずに指摘すること
  • 何故悪いコードなのかを論理的に説明すること
  • 良いコードについての共通認識を持つこと
  • 小さい単位でレビューを繰り返すこと
  • 指摘は素直な気持ちで受け入れること
  • 指摘は人格否定でないことを理解すること

ディスカッション みんなにとって分かりやすいものにする

個人の趣味で指摘をしないこと

まとめ

  • 自分たちの開発プロセスに適したレビュー観点を設定する
  • レビュー観点に基づく、良いコードの共通認識をチームで持つ
  • レビューは小口化して継続的に実施する

人の目を入れてコードを腐らせない

レビューに関するQA

自分の質問と、パネラーから頂いた回答。

質問) 効率的にレビューを実施するにはどうすればよいか?
十分な時間がない中でレビューを実施する事があり、短い時間の中でもレビューを有益なものにするにはどうすればよいか?

  • 小さく作ってレビューする。
    いきなり全部作ってではなく、5~10%くらい作った時点でレビュー。
    大きい固まりが一度に「ドン!」と来たら既に負け戦。
  • 「気になるところ」をチームでレビューする。
  • どういうところが大事かを事前に決め、そこを見る。

  • 時間割を決めてやる

  • 大事な所からやる
    リスク部分、難しい所、重要な所など
  • ゴールを決める 何が出来るようになればOKか?
  • 人間特性、手薄い所、異常系の記述量が薄い所を見る。

他のQAでなるほど、と思ったコメントなど。

  • 「レビューをやって良かった!」と思わないと継続できない。 レビューの効果を測定し、見える化する。

  • レビューの時間は予め予定に組み込んでおく。

  • 大きいプロダクトのレビュー終了条件は「時間」。 レビューが遅れたら後行程の作業はその分遅れる。
    期間を予め決めて、その期間の中でプロダクト品質を高めるにはどうすればよいかを考えた方がよい。

改めて思った事など

ドキュメントは読み手のレベルに合わせる必要がある。 万人に対して大丈夫なドキュメントなど存在しない。

ソースがドキュメントになるには、プログラマのスキルは必須だが、言語も選ぶと思う。
Rubyはともかく、手続きのコードが多くなりがちなC言語のソースを「ドキュメント」というのは辛いように思う。 ソニックガーデンさんがRubyを選択してるのはRuby on Rails使える以外に、ソースがドキュメントになり得るという所もあるのかな、と思ったりした。

前のプロジェクトで、こっちが作った設計書に「あれ書いてない」「これ書いてない」「フレームワークが分からない」と散々ダメ出しされた事があって、チームの雰囲気が最悪になった事を思いだした。
気にするポイントはその設計書を見る人の数だけあるので、事前にサンプル出して相手と意識合わせする事が重要。

レッツゴーデベロッパー555に行ってきました

2015/7/25のレッツゴーデベロッパー555のレポート。

ソフトウェアエンジニアとして心がけてきたこと 柴田芳樹氏

当日のスライド

www.slideshare.net

ソフトウェアは「人」が作る

ソフトウェアを書くことは芸術。うまくなるには10年を要する。

優秀なプログラマであれば、低レベルの言語、扱いにくいシステムであっても克服するが、 優れたプログラム環境は出来の悪いプログラマを救済してはくれない

優れたソフトウェアは人が作る。ツール技法が作ってくれるわけではない。

プログラマー現役続行するために

読みやすいコードを書く

ソフトウェアエンジニアの責任は、何年も使われ続けるビジネス資産を作り出すこと。
保守できないコードは、負債となる。初心者だからといって、汚いコードを書くことが許されるわけではない。

コンピュータが理解できるコードは誰でも書ける。優れたプログラマは、人が理解できるコードを書く。

ネーミングは設計の中心。良い名前を付けることは訓練を必要とする。熟練したプログラマとなるためにはこのスキルを伸ばすことが重要。

  • 優れたネーミングはシステムの理解を助け、作業を容易にする
  • 貧弱なネーミングはシステムの理解を妨げ、後でシステムを扱うプログラマに辛い日々を送らせる。
論理的思考
  1. プログラムの失敗を観察する
  2. 観察と矛盾しない失敗の原因についての過説を立てる
  3. 仮設を使って予想する
  4. 予想を実験でテストして、更に観察する
    1. 実験と観察が予想を満たすなら、仮説をさらに精緻なものにする
    2. 満たされないなら、別の仮設を立てる
  5. 仮説がこれ以上精緻にできなくなるまで、手順3と4を繰り返す

キーボードを早く触りたい気持ちを抑えること。思考はそれに勝るとも劣らない行為。 まず深呼吸をしてから、バグを引き起こした原因について考える。

継続した学習

ソフトウェア業界で取り残されないようにするには

  1. 重要な本、出版物を読み、主なカンファレンスに参加すること。
  2. 今日読んだ情報は3年から5年で古くなるため、常に終わることのないプロセスであると言うこと。
  3. あなたの会社は、良くても限られたサポートしか提供しない。最悪何もサポートしてくれない。

ソフトウェア業界で取り残されないためには、自分から進んで自分の時間や自分のお金を投資しなければならない。

一冊の良い本を選べば、他の人が何十年もかかって習得してきた見識を、数日で得ることができる。
技術を創りだした人が執筆した書籍を読むとよい。
アメリカでは、プログラム言語を作った人が本を書くことが多い。

技術書には誤りがあると思って読む。 誤りがあると思ったら、間違いだと思って流さずに問い合わせたりすると新たな知見が得られたりする。

柴田さんは、Effective Java(英語版)を読んで衝撃を受けたそう。 (その後、この本を翻訳してしまう行動力がすごい)

EFFECTIVE JAVA 第2版 (The Java Series)

EFFECTIVE JAVA 第2版 (The Java Series)

コンピュータの基礎知識

何年立っても陳腐化しない。

コミュニケーション力
  • 相手が理解していないと感じた場合には、相手が理解できる内容・用語・比喩に切り替えて説明する。
  • 相手の説明をきちんと理解できない場合に、相手が何を言いたいのかを逆に質問して、正しくコミュニケーションを取るように務める。
英語力
  • 専門的な技術の継続した学習と同様かそれ以上に、英語力を身に付けるための継続した学習が必要
  • 内容を理解し、技術書をある程度のスピードで読むには、TOEIC900点以上が必要

追い越される人、追いぬく人

新卒と一人前のエンジニアの差は縮まることはない。
一方、何の努力もしていない人を追い抜くことは、立ち止まってる人を追い抜くような簡単なもの。

立ち止まることなく、ソフトウェア開発を楽しみましょう。

セッション1 多階層組織の中でのエンジニアのありかた 村上正則氏

多階層組織とは

  • 社長を頂点とした階層組織
  • プロパが上がれる階層は決まっている
  • 組織図からは読み取れない、人のつながりがある
  • 業務で縦割りが基本
  • プロジェクトの構成も業務で縦割り
  • 1次受け 2次受け 3次受け...

プロジェクトの中で、プロジェクトを進める人の割合は1%!この人たちだけが本当のエンジニア。
この人たちだけが「プロジェクトを進めるために何をするか」考えている。この人が抜けたらPJ炎上はする。
でもこの人たちは上には行かない(出世コースに乗れない)

エンジニアの取れる選択肢
  • スキルチェンジして、管理をやる
    コード書くのは辞める
  • 組織外のコミュニティに参画する
    会社での出世は諦める
  • 内部改善をする

モチベーションの話

優れたエンジニアは、給与とかポジションとか気にしてない

技術は面白い
  • 勉強会はいたずらして遊ぶ時間
  • 動いたら楽しい
  • うまくいったら楽しい
楽しむためにやっていること
  • 無知を装う
    • 作業を丸投げされるのを防ぐ
    • 作業のゴールを曖昧にさせない
    • 作業のやり方、ゴールを言わせる
      「お前がやると言った」と言われないように
  • 管理しない
  • でも、コミュ力はそこそこ必要
    • 露骨な否定はしない
    • 話は聞くだけにする
    • 同意はしない
コミュニティに参加する
  • 自分の興味のある部分だけ
  • 無理しない。背負わない
  • できたら貢献する

エンジニアに朗報!

管理のピラミッドの他に、技術のピラミッドが作れる環境がもうすぐ出来てくるはず。

外圧と新陳代謝

  • 組織内の人も5年もすれば変わります
  • 人が変われば、仕事も変わる
  • 組織外の圧力には、そうそう逆らえない

組織の良い部分を使う

  • 数がある
  • 組織同士のコネクションがある
  • 組織は時間があれば変えられる

最後に

  • 作れる人が一番偉い
  • 技術の価値は必ず現れる
  • 組織は時間があれば変えられる

セッション2 ザ・ジェネラリスト ソフトウェア開発を勉強し始めて6年でトップレベルになるためにやったこと kyon_mm

当日のスライド

www.slideshare.net

エンジニアとは

ソフトウェア工学を知見を活かして仕事する人

トップレベルとは?
  • 既存の技術を作り直せる人
  • 次のステップを作れる人

always cool engineer

最高のエンジニアに対して最高の評価をする人が現れたらどうする? その時になってから勉強しても間に合わない

No Time Release

リリースまでの時間を0にしよう。 実際に0にすることは出来ないが、これをどこまで努力するかがエンジニア。

Cyber Punk

この仕事のモチベーションは攻殻機動隊
攻殻機動隊の世界を作るために必要なスキルは何でも欲しい 。

Generalist or Specialist

ジェネラリスト:何でも出来る人 ドラクエで言うところの勇者 スペシャリスト:特化型

8:2の法則を使うと、スキルレベル全体の8割を満たすまで達成するのは2割の時間で出来る。 残り2割を勉強するのは時間がかかるので諦める。 これらを全ての分野で行うことが大切。 たいていの人は多くの分野を知ろうとしないし、つなげることもしない。

言語学を勉強したことが、オブジェクト指向言語の理解につながったりする。(オブジェクト指向は海外で生まれた考え方なので、その国の言語学で勉強したことがオブジェクト指向の理解につながったりする)

8割を目指すのであれば形式知(本)でいける。

ある程度の技術書1冊はあるコミュニティの3年間の歴史が入っている。 技術書を年間に3冊読む人は1年で9年分の歴史を手にしている。 kyon_mmさんは技術書を年間40冊以上読むことにしている。 計算すると1年で120年分の歴史を手にしている。

愚者は経験に学び、賢者は歴史に学ぶ 。

Reading

技術書は2周以上読む。1周目は必ず3日以内に読む事。分からなくても問題ない。
どこかに詰まって読めないと、いつまで経っても読めない。

  • 短期記憶とうまく付き合う
    時間を空けると前の方に書いてあったことを忘れる。書いてあった事を忘れないうちに一通り読んでしまう
    読んで詰まった事が後に詳しく書いてあったりする
  • 本の中の言葉の使い方に慣れる。繰り返し出てくる言葉には気をつける
  • 書籍のクセ(構成、濃淡)を知る

本の読み方についてのkyonさんのスライド。

www.slideshare.net

Speaker, Blog, Article, Book

セルフブランディングについて考える機会。 組織やプロダクトをより良くするためにとても重要な考え方。

  • 自分では気づかないことを知っている人と出会える
  • 世界の広さを知ることができる。(良い面、悪い面とも)
Speaker

自分の考えを整理するスキルを身につける時間を作れる。

わかりやすく表現することに積極的に取り組んで、多少の失敗が許される。 マサカリを受けても、基本は受けた側が痛いかどうかだけ。投げている側はマサカリだと思ってない。

Concern

Scrum

権限が十分にあるプロフェッショナルな小さなチームがリズムを保って動くことで、生産性がとても高くなることをうまくルールにしている。
Scrumがうまくいってない人は、スクラムガイドに書いてある必要な事を全部やってないだけ。

BDD

フォーマルメソッドでは上手く行かない分野でうまく開発するための新しいプロセス。

kyonさんが書いたTDD/BDDの記事。

「いまさら聞けないTDD/BDD超入門」最新記事一覧 - ITmedia Keywords

MicroService with OO

PaaSとオブジェクト指向の出会い。これからどんどん世の中はSmalltalkのようになっている。 テスト不可能よりも、エンドユーザがサービスを作る時代。 (例. IFTTT、Wikipedia)

Conclusion

  • ジェネラリストになるということは、ある意味でソフトウェア開発におけるマニアというか研究者である
  • なんでもできるやつが絶対強い。

Extreme Fishbowl 川口恭伸氏、井上岳大氏

Pair Programming

経験が隣で見ている人に伝播させることが出来るやり方。 暗黙知は実際にやらないと伝わらない。

mob programmingという、ディスプレイにコードを映しながらみんなで議論してコーディングしていくやり方もある。

その後、ポーカーの役を判定するお題でmob programmingを実践。 迷ったけど、前に出てプログラムやってみた。 以下、やってみた感想。

  • お題の内容を少しずつ実装していくとして、最初にどこまで作るか悩んだ。
    Cardクラス実装しようか、判定する役が増えた場合に向けた処理構造どうしようか、等。
  • 少しAPI調べれば書けるコードだと思ったけど、何も見ずに書く事が出来なかった。
    ワンペア、ツーペア判定のコードはJava8のstreamAPI使えば簡単に書けるだろうなとは思ったけど、どう書けばよいのか出てこなかった。 普段から刀研いでおくの大事。
  • ルール、やる事を明確化して進めれば良かった。 自分はポーカーのルール知ってるけど、ルール知らない人もいたので、最初に明確化した方が良かったかも。
  • 人のマシン使うのは難しい。

この後、本もらいました。ありがとうございます。

Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築

明日から何やる?

参加者各自で、明日から何をするかを検討した。 自分が取り組む事にしたのは以下。

  1. 溜めてる本を全部読む。
    途中で詰まったりして読むのを中断してた本が結構あるので、それを読みなおす。
  2. プログラムを書く。 少しでもいいので、プログラムに触る機会を作る。
    書いたプログラムはGitHubに上げたりQiitaに投稿したりする。

感想とか

今回のレッツゴーデベロッパーのテーマは「エンジニア」。 自分は、エンジニアとして生きていくなら、ずっと勉強をし続ける必要があると思っている。 凄い人達は、自分より勉強してて、今も勉強し続けてるんだと分かった。

一方、コードを書く技術も磨き続ける必要がある事を改めて実感した。 昔は書けてたコードも、しばらく書かないでいると、かなり錆びついてたりする。 たとえ仕事でコードを書く機会がなくても、個人でコード書く事はやっておかないとダメ。 あと、後日のTDD勉強会でfishbowlの続きをやった時、柴田さんが言っていたネーミング技術の大事さを実感した。 読みやすいコード書くには、名前付けの技術は必須。

英語力の向上は継続課題。(-"-

「見立て」でコミュニケーション問題解決を図るワークショップ に行ってきました。

2015/06/13 のワークショップのレポート。

f:id:mokky14:20150613124903j:plain

妖怪とは?

コミュニケーションの問題

多くのプロジェクトではコミュニケーションの問題が内在している。 このとき、コミュニケーションの問題を理解し、問題を解決する糸口が分からない。時には精神論になり、具体的なアプローチが困難になったりする。 その結果、プロジェクトや現場のQCDが悪化し、大きな問題になることがある。 この身近にあるコミュニケーションの問題を「妖怪」として見つける。

妖怪のしくみがもたらすこと

  • 問題を妖怪のせいにして主体性を確保する
  • 不明な事象を妖怪にして安心と勇気を得る
  • 妖怪は、乗り移り、場を作り出す
  • 問題(妖怪)は善意によって発生する。妖怪を友達にしてバランスを修正する。
  • 妖怪による健全なコミュニケーション

ただし、距離感を忘れると、妖怪に乗っ取られる。

妖怪の見つけ方

  1. 発生している具体的な事象や出来事を見つける。
  2. なぜ、その事象は発生するのか? 問題解決を困難にする理由を見つけて名前を付ける。
    事実と感情は分けて考えること。
現場によくいる妖怪の一部
  • ナワバリン 「僕の仕事じゃありません」
  • タライマワシ 「これよろしく~」
  • クチダケ 「これはね~」
  • シッタカブリ 「それ知ってる」
  • シジマチ 「どうやってやればいいんですか」
  • ダマリン 会議中は黙っていて、後で話しだす

ゾンビ

ゾンビとは「健全なコミュニケーションが取れず学習が停止した状態」

  • 自由で活発に意見が言えない
  • 萎縮してしまう
  • 大したことがないと思ってしまう

その結果、 - 創造性や自主性の芽が摘まれる/損なわれる - 自己組織化が困難になる

ゾンビの種類
  • 否定されたと感じる
  • 途中で投げだし
  • イエスマン、意見が言えない
  • 覇気がない
  • ため息
人をゾンビにさせるアクション
  • 「知らなくていいんだよ」
  • 話を聞かない
  • (不適切な)マサカリ
  • 見下した態度
  • 攻撃的な態度
  • 信じる(意味の支配)
  • 参加意識の欠如
  • 矛盾したメッセージ(その時々で言うことが変わる。ダブルバインド)
  • 価値観の強制、相手の束縛が根底にある

ゾンビに魂を入れるためには

  • 自我状態を分析し、適切な反応を返す
  • 相手の状態により、情報を与える/得る
  • 問題解決せず、その状況を味わう
  • 矛盾しないメッセージを投げる(ダブルバインドの解消)
  • 自信や自尊心などを貯金する良い反応やフィードバックを与える(ストローク)

ストローク

ストロークの語原は「なでる」こと。

ある行動に対してストロークを与える(注目する)と、その行動の継続が促される。
ある行動を無視すると、その行動の消失が促される。

行動に対する肯定的なストローク(条件付)

もらうためには「何かをする」必要があるので、「条件付ストローク」と言われる

  • 具体的なほうがよい
  • 本当の事を言う(お世辞や適当にほめるのは×)
  • ストロークを与えるタイミングは、
    • 気づいたらすぐやる
    • 相手がよい方向に向かっているときにやる(完璧にできるまで待たない)
行動に対する建設的な否定的ストローク

普段からの信頼関係が大事。信頼関係のない人に言われても反感買うだけ。 伝えるときは肯定的なストロークでサンドイッチにして伝えるとよい。

ゾンビは、ポジティブな言葉掛けをしても吸い取ってしまう。
でも、あきらめずに続けることが大切。

自分で「ゾンビ状態」であることを選択することもある。 (ex.よく分からないけどとりあえず従っておこう、とか) このとき、ゾンビ状態であることを、自分で「選択した」と思っていることが重要。
でないと本当にゾンビになる。

妖怪への対応

相手(妖怪)の望みは何か?

  • 相手の立場について想像してみる
  • 妥当なこと(基本的に良いこと)は何だろう?
  • 発生した問題や迷惑ではなく、相手の迷惑に着目する

なぜ問題(妖怪)は起こるのか?
問題には理由がある。問題を起こす人は悪いことをしたいと思っているわけではない。
妖怪は善意によって発生する。

妖怪とうまくつきあう。

「自分が悪い」「誰々が悪い」ではなく、妖怪のせいにして、解決策を考える。
自己悪化(自分が悪い)では解決しない。
自分で妖怪を見つける事が重要。

ワークショップでやったこと

  1. 相手(妖怪)に向かって不満を言う
  2. 第三者的に、自分が妖怪に対する不満を言っている姿を観察する
  3. 妖怪の立場になって、不満を言っている自分を眺める

ワークショップでやったこと2

妖怪に対して、どんな妖怪をぶつければ仲間にできるか考える。 (「退治する」のではなく「仲間にする」がポイント)

感想

後から思い返しても、色々と考えさせられることが多い勉強会だった。 箇条書きで感想。

  • 難しい問題に当たるとどうすればよいか分からなくなることがよくあるが、「自分」で妖怪(対処するべき問題の原因)を見つけて対処するためのフレームワークとしてよく出来てると思う。
  • 問題を「妖怪」とすることで、相手の人格攻撃にならずに済む。 対処するべき相手を人ではなく妖怪とすることで、「なんでこの人は自分の思い通りに動いてくれないのか」という気持ちを抑止することができる。
  • 「事実と感情は分けて考える」は大事。 妖怪の大半は問題そのものではなく、ある事象に対する自分の感情が発生させてると思う。
  • 妖怪を「仲間にする」という考えも面白い。 人は皆何かしらの妖怪(個性)を持ってるので、別の妖怪(人)をぶつけて、その妖怪を友達にする(自分の力にする)ことができる。
  • 映画のキャラクターを何かのメタファーとして見るというのは面白かった。
    キョンシー(ゾンビ)と導師(人をゾンビ化させて自分の思いのままに操る人)という話は納得した。相手の意見をことごとく否定して自分の思い通りに相手を動かす人とか見たことある。 (今の若い人はキョンシー知らないだろうな。。)

当日のTogetter

#DevSen 「見立て」でコミュニケーション問題解決を探るワークショップ 2015年6月13日 - Togetterまとめ

WIndows PowerShellで日本語フォントを使う

Windows PowerShellで日本語を使えるようにしたときのメモ。

参考:コマンドプロンプトの設定

環境:Windows7 Professional(x64)

対応前

dirコマンドでファイル一覧を表示すると日本語のファイル名が化ける。

f:id:mokky14:20150427180029p:plain

プロパティ→フォントを指定しても、日本語のフォントがメニューに出てこない。

f:id:mokky14:20150427180152p:plain

プロパティから「現在のコード ページ」を見ると、「437 (OEM - 米国)」となってる。 このため、日本語のフォントが選択出来ないらしい。

f:id:mokky14:20150427180527p:plain

対処方法

コードページを日本語のものに変更する。
PowerShellのウィンドウから以下コマンドを実行。

> chcp 932

プロパティから、コードページが932(Shift-JIS)になった事を確認。

f:id:mokky14:20150427180844p:plain

フォントタブを指定すると、日本語フォントが指定出来るようになってる。

f:id:mokky14:20150427180726p:plain

フォントを指定すると、日本語のファイル名も正しく表示されるようになった。 日本語ファイルのtab補完も出来た。

フォントのカスタマイズ

MSゴシックとラスターフォント以外のフォントを使う方法。
参考サイトに以下の情報があったのでこれに倣う。

既定のフォント以外に変更するには、選択可能なフォントのリストに新しいフォントを追加し、それを選択します。そのためにはレジストリを書き換える必要があります。

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont]に、現在設定されているフォントのリストがあります。ここに種類を「文字列値」、キー名を現在のコードページ番号である[932.]として、値にフォント名を設定した項目を追加します。

レジストリエディタを起動。
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont] を開く。

f:id:mokky14:20150427181053p:plain

右クリック→新規→文字列値を選択。
名前に「932.」を指定し、「値のデータ」に追加するフォント名を指定。

f:id:mokky14:20150427184312p:plain

PowerShellを起動し直して、プロパティ→フォントを開くと、追加したフォントが選択可能になってる。

f:id:mokky14:20150427184347p:plain

選択したフォントで日本語も問題なく使えるようになった。

f:id:mokky14:20150427184356p:plain

Agile Japan 2015 仙台サテライト「YOU CAN REDO」 に行ってきました

2015/4/16のAgile Japan 2015 仙台サテライトのレポート。

f:id:mokky14:20150417065232p:plain

基調講演1:アジャイル・テスティング ~ チーム全体のためにテストとテスターができることを学ぶ旅

Janet Gregoryさんによる講演。Janetさんは『実践アジャイルテスト』の共著者。

t.co

分散したチームでのテスティングの話。 開発は一拠点に集まって開発を行うのがBestだが、色々な事情により、分散して開発せざるを得ない場合がある。

分散開発の問題

  • フィードバックが遅くなる(質問に対する回答が24H後になる等)
  • コミュニケーションのコストがかかる
  • ダイバーシティ
    • 歴史の違い
    • 習慣の違い
    • 言語が違う
    • 挨拶のやり方が違う(握手、ハグ等)

スティングに特定した課題

f:id:mokky14:20150416102019j:plain

対策

コミュニケーション
  • 情報(意思決定、計画作り会議、議事録等)を全員にオープンにする。
  • 均等に機会を与える。全員が会議に参加出来るようにする等。
  • コミュニケーションツール(メール、電話、SNS等)を必要に応じて使い分ける。
コラボレーションツールを使用

f:id:mokky14:20150418081507p:plain

メンバー間での会話がある事が大事。 Janetさんが本を書いた時は、パートナーとお互い何を考えているかをMindMapで共有して書いた。

テストを通して共通理解を作る

f:id:mokky14:20150418081830p:plain

人によって、作業の「完了」のレベルは異なる。 作業をテストの形で書いて、その内容について確認(会話)することで共通理解を作る。

「早いフィードバック」が大事。

学ぶことが出来る環境

失敗から学ぶことが出来るようにする。

f:id:mokky14:20150418081354p:plain

異なるチームに対して、文化は簡単にコピーできない。 振り返りが大事。

信頼関係を作る

互いの状況を理解することで、相手を気遣うようになる。
全員に見えるようにすることが大事。

f:id:mokky14:20150418081327p:plain

適応する

f:id:mokky14:20150418081250p:plain

自分のSafe Zoneから出て、周りと話をしましょう。

基調講演2:デジタル革命には アジャイルがよく似合う

横塚 裕志さん(東京海上日動システムズ株式会社顧問)による講演。

デジタル革命

f:id:mokky14:20150423112617p:plain

  • 富士フィルムの本業はもうフィルムではない。
  • 3Dプリンタで車や家の部品が作れる。
  • リアルタイム翻訳システムが今年中にできる。
  • 2014年ワールドカップで優勝したドイツは、選手の靴にセンサー付けてデータを取った。
  • 某便器メーカは、毎朝の尿からその人の健康状態を判定するセンサーを開発してる。 → 医者が不要になる。
  • 自動車の運転が自動化されると、交通事故が起きなくなる → 自動車保険が不要になる。
  • 防犯カメラの精度や監視機能が向上する。 → 警察が不要になる。

今後、少し頭を使うような作業(銀行の融資担当、保険の査定など)はコンピュータに取って替えられると言われている。

この世界で生き残っていくには?

デジタルビジネスの特徴

f:id:mokky14:20150424113232p:plain

競争の軸が変化する。 新聞を例に取ると、紙の時は正確さが大事にされたが、デジタルではスピードが大事になる。

競争優位は続かない。
企業に常にイノベーションを続ける体力が求められる。

勝ち残るためには、「テクノロジーが実現する新しい価値作り」が必要。
企業が「売れる」と思うかは関係なく、お客様が価値を感じるものでないと売れない。

価値作りのための4つの視点

Customer Centric

自動車を作ってる人は、自動車の運転を自動化しようとは考えない。 「運転するの面倒くさい」と考えるお客様目線で考えないとダメ。

考えるためのメソッドとして、デザインシンキングがある。

デザインシンキングでは、プロトタイプを作ったり、実際に体験したりする。 座学だけでは意味がない 。

Collaboration

対話することで気付きが得られる。

  • ビジネスとエンジニア
  • チームとお客様

一緒にどういうものを作るか考える。 考える人と作る人を分離しない。

Visible

見えるようにする。見えるようになれば工夫できる。言葉だけでは分からない。

プロトタイプを作るなどして見える化する。

Iterative

f:id:mokky14:20150423113801p:plain

お客様に見てもらって改善していく。改善、改善、改善。
これから新しいサービスを作ろうとして、最初から良い物を作れるわけがない。 お客様の反応を見ながらフィードバックを受けて改善していく。

常にお客様のフィードバックを得ながら改善していかないとビジネスで勝ち残っていけない。

ウォーターフォールアジャイルか」なんて議論やってる場合じゃない。もうアジャイルに決まっている

Agile is Mind-Set

昔ながらのマインドセットではダメ。 フランクにお互いの言うことをよく聞いて戦略を立てる。

f:id:mokky14:20150423113837p:plain

3年先を考えるなんて無理。4半期くらいで見直さないとダメ。 敵は自分の業界の外から来ることもある。

今変わらないと、10年後、日本はタダの部品メーカに成り下がる。

アジャイルするためにはBA(Business Analysis)スキルが必要。

ビジネスイノベーションアジャイル、ビジネスアナリシスは1セット。 個別で考えるものではない。

ビジネス側に提案できるようになることは技術者の責務。

f:id:mokky14:20150416114905j:plain

午後の仙台セッションに続く。

リンク

Janetさんの著書。

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

まとめ:
2015/04/16(木) Agile Japan 2015 ~午前~ #agilejapan - Togetterまとめ

公認レポート:
Agile Japan 2015 レポートコーナー

RedmineにAgileプラグインをインストール

Redmine使ってみて、チケットをかんばんの形で表示するプラグイン探してみたところ、Agileプラグインでいけそうだったのでインストールしてみた。

環境

  • OS : CentOS6.5
  • Redmine : 2.6.0-1
  • ruby : 2.2.2p95
  • gem : 2.4.5
  • bundler : 1.9.4

ダウンロード

プラグインRedmine pluginsからダウンロードする。 ダウンロードにはユーザ登録が必要。
多機能な有償版もあるようだが、今回はフリー版の redmine_agile-1_3_8-light.zip をダウンロード。

インストール

Redmine Agile plugin installation - Agile plugin - Redmine pluginsの手順に従いインストールを実施。
Redmine2.6.0の場合、pluginsディレクトリは、Redmineインストールディレクトリのapps/redmine/htdocs/plugins/ になる。

[root@centos6 htdocs]# pwd
/opt/redmine-2.6.0-1/apps/redmine/htdocs/plugins/
[root@centos6 plugins]# unzip /tmp/redmine_agile-1_3_8-light.zip
[root@centos6 redmine_agile]# bundle install --without development test
Fetching source index from https://rubygems.org/
Could not fetch specs from https://rubygems.org/

Proxy未設定によるエラーと思われるため、Proxyを設定。

[root@centos6 redmine_agile]# vi ~/.gemrc
http_proxy: http://proxyuser:proxypass@proxyhost:proxyport

再度実行。

[root@centos6 redmine_agile]# bundle install --without development test
Fetching gem metadata from https://rubygems.org/.........
Using rake (10.3.2)
Using i18n (0.6.11)
Using multi_json (1.10.1)
Using activesupport (3.2.19)
(途中略)
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.

    /usr/bin/ruby extconf.rb
checking for ruby/thread.h... no
checking for rb_thread_blocking_region()... yes
checking for rb_wait_for_single_fd()... yes
checking for rb_hash_dup()... yes
checking for rb_intern3()... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lm... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lz... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lsocket... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lnsl... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lmygcc... no
checking for mysql_query() in -lmysqlclient... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.
(途中略)

An error occurred while installing mysql2 (0.3.14), and Bundler cannot continue.
Make sure that `gem install mysql2 -v '0.3.14'` succeeds before bundling.

mysql2のインストールでエラー。
エラーメッセージにしたがってgem installしてみる。

[root@centos6 redmine_agile]# gem install mysql2 -v 0.3.14 -r -p http://proxyuser:proxypass@proxyhost:proxyport
Building native extensions.  This could take a while...
ERROR:  Error installing mysql2:
        ERROR: Failed to build gem native extension.

    /usr/local/bin/ruby extconf.rb
checking for ruby/thread.h... yes
(途中略)
checking for mysql_query() in -lmysqlclient... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
        --with-opt-dir
(途中略)
        --without-mysqlclientlib


Gem files will remain installed in /usr/local/lib/ruby/gems/2.0.0/gems/mysql2-0.3.14 for inspection.
Results logged to /usr/local/lib/ruby/gems/2.0.0/gems/mysql2-0.3.14/ext/mysql2/gem_make.out

mysql-develがインストールされてないとダメらしい。mysql-develインストールしてからmysql2インストールする。

[root@centos6 redmine_agile]# yum -y install mysql-devel
[root@centos6 redmine_agile]# gem install mysql2 -v 0.3.14 -r -p http://proxyuser:proxypass@proxyhost:proxyport
Building native extensions.  This could take a while...
Successfully installed mysql2-0.3.14
Parsing documentation for mysql2-0.3.14
unable to convert "\xE0" from ASCII-8BIT to UTF-8 for lib/mysql2/mysql2.so, skipping
Installing ri documentation for mysql2-0.3.14
1 gem installed

mysql2のインストールに成功。Agileプラグインのインストールに戻る。

[root@centos6 redmine_agile]# bundle install --without development test
(途中略)
Net::HTTPServerException: 407 "Proxy Authentication Required"
An error occurred while installing ruby-openid (2.3.0), and Bundler cannot continue.
Make sure that `gem install ruby-openid -v '2.3.0'` succeeds before bundling.

なぜかProxyの認証エラー。
色々試したが、最終的には一旦ログアウトして、再度ログインして実行したら動いた。

[root@centos6 htdocs]# bundle install --without development test
(途中略)
<= 1.8.6 : unsupported
 = 1.8.7 : gem install rdoc-data; rdoc-data --install
 = 1.9.1 : gem install rdoc-data; rdoc-data --install
>= 1.9.2 : nothing to do! Yay!

インストール手順に従い、次のコマンド実行。

[root@centos6 htdocs]# bundle exec rake redmine:plugins NAME=redmine_agile RAILS_ENV=production
/usr/local/lib/ruby/gems/2.2.0/gems/bundler-1.9.4/lib/bundler/shared_helpers.rb:78: warning: Insecure world writable dir /opt/redmine-2.6.0-1/apps/redmine/htdocs in PATH, mode 040777
/opt/redmine-2.6.0-1/apps/redmine/htdocs/vendor/bundle/ruby/2.2.0/gems/activesupport-3.2.19/lib/active_support/values/time_zone.rb:270: warning: circular argument reference - now
Migrating redmine_agile (Redmine Agile plugin (Light version))...
==  CreateIssueStatusOrders: migrating ========================================
-- create_table(:issue_status_orders)
   -> 0.3914s
-- add_index(:issue_status_orders, :issue_id)
   -> 0.0539s
-- add_index(:issue_status_orders, :position)
   -> 0.0218s
==  CreateIssueStatusOrders: migrated (0.4674s) ===============================

==  CreateAgileColors: migrating ==============================================
-- create_table(:agile_colors)
   -> 0.0135s
-- add_index(:agile_colors, :container_id)
   -> 0.0240s
-- add_index(:agile_colors, :container_type)
   -> 0.0230s
==  CreateAgileColors: migrated (0.0607s) =====================================

==  RenameIssueStatusOrders: migrating ========================================
-- rename_table(:issue_status_orders, :agile_ranks)
   -> 0.0049s
==  RenameIssueStatusOrders: migrated (0.0050s) ===============================

手順に従い、Redmine再起動。 再起動後、ブラウザからRedmineのページを開き、管理→プラグインを確認。 無事インストール出来たっぽい。

f:id:mokky14:20150417154537p:plain

使う

プロジェクトの設定→モジュールから、Agileにチェックを入れることで、該当プロジェクトでプラグインが有効になる。

f:id:mokky14:20150417155445p:plain

プラグインを有効にした後、「Agile」タブをクリックすると、かんばんが表示される。

f:id:mokky14:20150417160750p:plain

チケットのステータスは設定したワークフローに従って表示される。 個々のチケットはドラッグ&ドロップで移動可能。
同じステータスのチケットの表示順も変えられるので、優先順の並べ替えが可能。

チケットに表示する情報はAgile pluginの設定画面から設定可能。

f:id:mokky14:20150417163340p:plain

やりたい事は出来るようなのでこれで運用してみる。

参考:
Redmineのアジャイル開発向けプラグイン - torutkの日記
https://groups.google.com/forum/#!topic/redmine-users-ja/r836-uwS2gM
gem install実行時、Proxyサーバ認証ユーザに @ を含む場合のTips - 会長@腹部日記(2013-05-08) Proxy環境でgem install - Qiita
gem インストール時に発生したエラーとその解決方法まとめ - kzy52's blog