mokky14's IT diary

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

7つの習慣ボードゲーム公式ゲーム会に参加してきた 

2016/6/19(日)の「7つの習慣ボードゲーム 公式ゲーム会」のレポート。

7つの習慣ボードゲームとは

f:id:mokky14:20160619130520j:plain

スティーブン・R・コヴィーの名著「7つの習慣」(自分は読んだことない)で書かれている成功のエッセンスを体験できるゲーム。
クラウドファンディングで、ボードゲームのプロジェクトの中で史上初の1000万円を達成したゲームらしいです。

ゲームの概要(公式サイトより引用)

7つの習慣ボードゲームは、
「第1ステージ:私的成功」
「第2ステージ:公的成功」
「第3ステージ:成功の習慣化」
上記3つのステージが存在し、サイコロを振りながら駒を進めていきます。
 

プレイヤーは人材を雇用しながら「影響力」を高め、 プロジェクトを成功させながら「お金」と「信頼チップ」を集めます。
 

プロジェクトのキモは「交渉」!!
「交渉」では普段の決断力や判断力が実に問われてきます。
特に「7つの習慣を理解している」ことがカギとなる部分です。
 

このゲームは、決められたターン数の間に、
・第3ステージに到達する
・「肉体」「精神」「知性」「社会・情緒」4種類の刃を研ぐカードを揃える
・「ミッション・ステートメントカード」の条件を達成する
以上、3つの条件をクリアすることで、ゴールとなります。

やってみた

結果は、クリア条件のうち、「刃を研ぐカード」を揃えられなくてゴールできず。

7つの習慣ボードゲームということで,「7つの習慣」に照らしあわせた自己評価。

7つの習慣 評価
主体的である ○ 自分の頭で考えてゲーム進めてた。
終わりを思い描くことから始める × ゴールから逆算した進め方をしてなかった。目先で困っている事(資金不足、人材不足)を優先してしまった。
最優先事項を優先する △ 自分の中では優先事項を考えてプレーしてたが、そもそもの優先事項の選択が誤っていた。
Win-Winを考える ○ 交渉の時、相手の利益も考えて交渉した。
まず理解に徹し、そして理解される △ 全く気にしないでやっていた。(特に意識せずとも友好的にゲーム勧めてたと思う)
シナジーを創り出す △ 参加メンバー同士での協同効果は作れていたと思う。(自分以外のメンバーはクリア、自分もクリア条件満たしかける所まではいった)
刃を研ぐ △ ゲームの中では「刃を研ぐカード」集められなかったので×だけど,ゲームの中ではあまり意識するものでもなかった。

経営者モード

時間があったので、経営者モードでのゲームも実施。 経営者モードは以下のルールが変更になる。

  • スタート時の資金が10倍。
  • 雇用している人材の雇用費を毎ターン支払う

結果、二回連続で破産(資金がショート)。
↓全員、手元にお金が残ってない。 f:id:mokky14:20160619162627j:plain

その後,3回目の挑戦で全員クリア達成。

f:id:mokky14:20160619172245j:plain

経営者モードの感想。

  • 経営者って大変。
    • 収入の有無に関わらず固定費が毎ターン出て行くのは怖い。
    • 想定外のトラブル(イベント)が発生したら、その都度立て直しが要る。
      トラブルは発生することを前提に対応計画を考えておかないといけない。
  • 人を雇用する事は難しい。
    • ゲーム上、雇用した人材は解雇できない。
      雇用した人材に対して毎ターン支払いが発生するので、人を抱える事が負担になる。
    • 経営者目線で見ると、成長しない人材(レベル低の人材カード)はイライラする。
      うちの会社に、人材は人財にも人罪にもなるというのがあるけど、自分は人財になるようにしないといけない。
  • 一人ではどうにもならない。
    • 全員で協力するのは前提で、その上で入念に計画立てた上でやっとクリア。

改めて、7つの習慣とは?

f:id:mokky14:20160619145054j:plain

  • 私的成功
    • 第一の習慣・主体的である(Habit 1 Be Proactive)
    • 第二の習慣・終わりを思い描くことから始める(Habit 2 Begin with the End in Mind)
    • 第三の習慣・最優先事項を優先する (Habit 3 Put First Things First)
  • 公的成功
    • 第四の習慣・Win-Winを考える (Habit 4 Think Win/Win)
    • 第五の習慣・まず理解に徹し、そして理解される(Habit 5 Seek First to Understand, Then to Be Understood)
    • 第六の習慣・シナジーを創り出す(Habit 6 Synergize)
  • 第七の習慣・刃を研ぐ (Habit 7 Sharpen the Saw)

ここの内容が分かりやすかった。
前はハードカバーの分厚さで尻込みしてたけど、今はマンガも出てるし、一度読んでみるかな。

参考

7つの習慣 - Wikipedia

世界的ベストセラー『7つの習慣』ってどんな習慣なのか知ってる? | 美女読書

7つの習慣ボードゲーム 成功の鍵 公式サイト

書籍

JaSST東北2016に行ってきた

2016/5/20(金)のJaSST東北2016のレポート。

f:id:mokky14:20160521104503j:plain

今年のJaSST東北2016はVSTeP(ブイステップ)祭りだった。

基調講演 VSTePによるソフトウェアテストの開発 ー 西 康晴 ー

VSTePとは?

テスト設計の技法の一つ。
(他のテスト設計技法は、HAYST法、ゆもつよメソッドがある)

VSTePの流れ

  • テストケースをざっくり考えてから具体化する
    • いきなり細かく考えると抜け漏れが発生しやすくなる
    • まずは「負荷」とかざっくりした観点で考えて、具体化していく
  • 全体像を把握するための図を描く
    • Excelの表だと全体像の把握は難しい
    • 図の形式やツールにはこだわらない。全体像を把握するのが目的

テスト要求分析

テスト観点図を作成する。

  1. テスト観点を思い浮かべて、線でつなげる
  2. 観点を詳細化していく(親観点から子観点を引く)
  3. 関連する観点を線でつなぐ

テスト観点図の作成方法は、トップダウン型とボトムアップ型の2種類がある。

  • トップダウン型 ざっくり観点を挙げて徐々に詳細化していく
  • ボトムアップ型 試験内容を思いつくところから挙げて、挙がった試験項目から観点を導出していく

地図見るのが得意な人はトップダウン、苦手な人はボトムアップてやるのが良い(らしい)。
実際にはトップダウンボトムアップを循環させながら進める。

テスト観点を導き出した理由・意図を明確化することが大事。
意図が分かっていれば、意図が間違っていたのか、意図通りに行かなかったのかが後から分かる。

テストコンテナ設計

テスト観点をグルーピングする。
コンテナはテストのカテゴリを示す(機能テスト、負荷テスト、セキュリティテストなど)。コンテナは単数または複数のテスト観点をグルーピングしたものとなる。

  1. コンテナを設計し、テスト観点と対応させる
  2. テストコンテナ図を作成し、各コンテナの実施順序(テストの順序)を検討する

テストの順序はテストの戦略になる。

テストフレーム設計

テストケースのひな形(骨組み)を作る。

テストケースを実施するために、どの観点を組み合わせて試験を行うかを設計する。具体的な値は詳細設計で考えることとし、ここでは観点の組み合わせのみを考える。

テスト詳細設計、テスト実装

普通のやり方でよい

  • テストケースのひな形に具体的な値を入れる
  • 値を入れたひな形を手順に具体化する

導入にあたって

  • いきなり全部導入するのではなく、自分が困っているところに入れてみるのがよい。
    とりあえず導入してみて、ダメなら止めればよい。
  • 最初から完璧を目指してはいけない。
    大事なのは困ること。困ったことを自覚して、図にして、直して、納得すること。
  • 観点の抜け漏れはしょうがない。それが自分達の現在の技術レベル。 
  • 観点網羅を目的にしない。観点が「もう出ない」ことをチームで合意する事が大事。
  • 観点として必要だと思わないものも観点として明示した上で「不要」であることを合意する。
  • 「これさえあれば、何も考えなくても作業できる」とかはない。単純作業したい、自分の頭で考えない、言われたからやる、というような人や組織では導入しない方が良い。

演習

Lhaca+の解凍機能を題材にしたワークショップ。
以前のソフトウェアテスト勉強会でもやった題材。

テスト観点図

自分らのチームで作成したテスト観点。
ファイルのパターンを重点的に抽出。それ以外は、パラパラと出ていたテストケースに対して、ボトムアップで観点を付けた感じ。

f:id:mokky14:20160520145026j:plain f:id:mokky14:20160520145020j:plain

何だか網羅性がなくて気持ち悪いと思っていたら、その不安が後で的中する形に。

テストコンテナ

写真撮り忘れた。
うちのチームでまず作ったのはこんなコンテナ。

  • 解凍テスト
    • コンテナに含めた観点
      • (インプットとして)圧縮ファイルバリエーション
      • (実施手順として)人による操作
      • (アウトプットとして)出力先

実際にテストするときは、ファイルパターン×解凍機能の呼び出しパターン×出力先のバリエーションでの組み合わせテストになると考えて作ってみたけど、こんなんで良いのかとモヤモヤして、西先生に助言を頂くことに。
西先生からは「何をテストしたいのか?」「コンテナに入れる観点は、テストしたいもの。実施手順は観点ではない」というコメントを頂きました。
このコメントを受けて作りなおしたテストコンテナ。

  • 解凍テスト
    • コンテナに含めた観点
      • 圧縮ファイルバリエーション

「解凍ソフトとして、色々なバリエーションの圧縮ファイルの解凍ができる事」を確認するテストとして、コンテナ作成した。 演習はここで時間切れ。

振り返り

  •  ファイルの観点を先に深堀りしたのは失敗だった(と思う)。 ファイル観点を深堀りしただけで満足してしまい、それ以外の観点をあまり考えないままテスト観点の作成を終えてしまった。
    • テストコンテナの作成では、深堀りしたはずのファイル観点は入れる事すら出来なかった。
      • そもそも、ファイルの種類が重要な観点だとは考えてもいなかった
    • テスト観点の全体像を作成して、重要と思う観点をチーム合意して、その観点を深堀りするよう進めた方が良かったかも。
  • チームの意識が、観点の抽出よりも、細かいテストパターンを出す方に意識が行っていたと思う。
    テスト観点の抽出に意識を向けるよう、ファシリテートする技術が必要。
  • 「プロダクトとして大切なのは何か」をチーム内で合意出来てなかった。 それぞれが、考えがバラバラなまま進めてた。
  • VSTePを使うには慣れが必要。
  • 自分のチームではテスト戦略まで考えられなかったが、他のチームが言っていたテスト戦略は興味深かった。テストの順番がテストの戦略という事がよく分かった。
    • 性能テストは早い段階で実施する。理由は、性能に問題があった場合、改修が大変なので。
    • 製品の品質を上げる事が先なので、製品の魅力テストは「当たり前品質」を確認した後に実施する。

感想など

去年のソフトウェアテスト勉強会でやったゆもつよメソッドと比べると、ゆもつよメソッドは仕様書をインプットにして観点上げるのに対して、VSTePは仕様書をインプットとせずブレストで観点上げる形なので、現場導入のハードルは高いように思う。
一方、他のチームで出ていた「魅力テスト」というコンテナとかは、仕様書からは絶対に出てこないテスト。これは「仕様書を見ずに観点を上げる」事による効果だと思う。

とは言え、プロジェクトにも寄ると思うが、仕様書見ないでテスト項目上げるのは、実業務ではハードル高い。
むしろ、設計入る前とかのブレストの方が使えるかも知れない。 あと、設計が実装に寄りすぎて「そもそもこのプロダクト何したいんだっけ?」な開発では有効かも知れない。(そもそもそんなプロジェクトは炎上案件だけど)

あと、現場導入時はファシリテート出来る人がいないと崩壊するのが目に見える。
幸い、ソフトウェアテスト勉強会でまた実施するそうなので、引き続き実践してみる。

リンクなど

VSTeP

VSTeP – Qualab

当日のToggtter

JaSST'16 Tohoku ソフトウェアテストシンポジウム 2016 東北「テスト開発しちゃいなよ!~テスト設計との違い~」 #jassttohoku - Togetterまとめ

VSTePとゆもつよメソッド(とHAYST法)の違い

http://jasst.jp/symposium/jasst13tokyo/pdf/A2-1.pdf

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

2015/09のテスト勉強会レポート。
先月の勉強会 に引き続き、ゆもつよメソッドの勉強。

マトリクスのチェック

前回作成したマトリクスに対して、仕様書等を参照しながら、作成したマトリクスに、試験が必要と思う所に○を付けていく。 (今回は時間の都合で圧縮の所まで○付け)

f:id:mokky14:20150924124030j:plain

重み付け等で差を付けたい場合は適宜記号を工夫する事。

試験項目作成

作成したマトリクスを元に、試験項目を作成する。

f:id:mokky14:20150914195026j:plain

表に記述する内容は以下の通り。

項目 記載する内容
機能名 中項目-小項目(内容が分かれば小項目のみでも)
テストタイプ テストカテゴリの種類(ex.機能性、負荷テスト、パフォーマンステスト)
テストカテゴリ テストカテゴリの各項目
仕様項目 テストでの確認観点
期待結果/確認内容 期待する結果、確認する内容等
パラメータ テストで指定するパラメータ(上図では省略)

機能名~テストカテゴリはマトリクスに○を付けたものを抜き出して記載する。 この各項目に対し、確認対象、確認する内容を記載していく。
試験項目と、マトリクス、仕様書を相互確認しながら作成する。マトリクスに不足があったりしたら、そちらも適宜修正する。

マトリクスの用途

ゆもつよメソッドのマトリクスは、システムテストのチェックに使用するために考えられたもの。

以下、自分の解釈。

単純に機能のIN/OUTだけに着目した試験だと、機能的に確認しておくべき試験が漏れてしまう事が懸念される。
そのため、ユーザシナリオでユーザにとって重要な機能を確認した上で、内部構造にも着目して試験観点を抽出する。
マトリクスの内容は、結合試験の内容と多少オーバラップしたものになるが、機能や処理パターンを網羅する事が目的ではない。 「ユーザシナリオを提供する」ために必要な機能を試験観点として抽出する事が目的になる。

非機能観点の試験は、「ユーザシナリオを提供する」ために必要な機能を抽出した上で、 その機能を多方面(性能、連続運転、ユーザビリティ、セキュリティ、等)の観点から検証するために実施する。

非機能観点は対象のプロダクトが変わっても流用できるものが多くなる。 チームやプロダクトで育てていくと良い。

最後に

ねもとさん、ありがとうございました。

仙台ソフトウェアテスト勉強会のレポート(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まとめ