プロジェクトマネジメントのもう一つの世界観 に思ったこと
弊部部長のブログが素晴らしいとネット上で話題に!
↓
これを読んだ感想を書いてみました。(ですので先に上記の記事を読んで欲しいです)
私は前職で「クリティカルチェーン」とか「学生症候群」の話を知った時に、あぁ、自分もそうだよなーと思いました。その時は業界的に「予測型」があたり前の世界だったので、いかに未来を予測するか(そして記述にあるようにバッファを盛り込むか)みたいなことをやってたなーと。
見積もりを依頼されてまず思うのは「これくらいでできそうです」と言ったらその中で終わらせないと約束破ったな的な非難をされるんじゃないかという恐れ。それでも当時は「見積もってその通りに終わらせるのが仕事。それが無かったら仕事できないじゃん」が常識でした。
私はアジャイルとかスクラムをここ2年くらいで知りました。弊部には2人「認定スクラムマスター」がいますが、その人がスクラムマスターを務めたプロジェクトを見てて感じたことがあります。(残念ながらプロジェクトメンバーとして参画したことがまだ無い)
メリット
- 目の前の、作業完了が予測できる範囲を見てるので安心できる(このスプリントとその次くらいにが終わった時に何ができるのかわかる)
- バックログにやるべきことが優先度の高い順に並べて上から順にやっていく(非常にシンプル。割り込みがあってもそれがバックログに追加される)
- 予定も仕様も変更されるものである、が前提なので、変化を許容できる(プロセス的にもそうですが、特に精神的にも変わってあたり前が受け入れられる)
- 変更(特に追加)がある場合、それに応じてスケジュールかスコープが変わるので、「今のスケジュールのままだし、スコープも同じだけど、コレを加えてね、よろしく」ってことにはならない
- これらから、関わるメンバーの気持ち的なゆとりが生まれる
デメリット
- 自分たちが1スプリントで実行可能な作業量をウォッチしていくので、過度な残業や休日出勤がされないかわりに、プロジェクト終盤の「追い込み感」が無い (コレに関しては私自身がメンバーになって体験していないので、外からはそう見えた、ってことで)
- 例えば来週火曜にリリースだからこの土日出勤してでもブラッシュアップしていきたい!という気持ちに歯止めがかかってしまう(←ココらへんは臨機応変にやればいいとは思いますが)
- 従来の(納期とスコープが動かせないタイプの)開発の仕方のほうが、短期間プロジェクトであればいいモノができるのではないか(ここは比較してはいないので完全に私の主観なのと、いいモノの定義もいろいろ)
また、スクラム自体に勘違いされそうだなと思う点として
- 発注する側からみると、何でもかんでも好きなときに、お気軽に変えていいんだな、って思われちゃうのは違う
- 開発チーム側からみると、「できるところまでしかやらない」が「ラクしていい」に受け取られるのは違う
特に後者で、日々ものすごい業務量をこなしている開発者にとって「できるところまでしかやらなくていい」という言葉を聞くと、なんかすげー助けられた感があるじゃないですか。ホっとするというか、肩の荷が下りるというか。一方で、「じゃあえて低く設定しとけばラクし放題じゃね」みたく受け取られちゃうんじゃないかというのが心配なところ。そうじゃないですよねw
スクラムが上手くいく条件として私が思うのは「発注する人も作る人も、本気でそのプロジェクトの成功を願ってるし、そこに向けて惜しみなく自分のできることを出していけるし、メンバー間の信頼度も高い状態。結局のところ人が成功のカギ」
「労働者は可能な限り少ない労力で可能な限り高い賃金を得たいし、使用者はその逆」という世界には絶対に合わない仕組み。
(私自身はスクラム開発について本読んだくらいしか知識がないので、この記事の中で勘違いや知識不足などあったら申し訳ありません、、、)
新人研修用にQAレクチャーした話
表題の件はコチラのブログに載ってますw
このブログに書かれていない話を。
このレクチャー、実は3回目なんですよね。
1回目は2013年に「ジョブウェブコラボレーションプロジェクト」として、エンジニアになりたい学生に向けたセミナーでした。
なにこれ、面白そうだよね!
そもそもエンジニアになりたい学生が品質とかテストに興味を持っていること自体が激レアなわけです。この会でもどこまで学生に刺さったのかなぁ。。。初めてだったし、不安だったなー。そういえば形から入ろうとしてスーツ着てで講義してたのを思い出しました。
2回目は2014年新卒研修。その会はエンジニア5人に向けて行いました。
そして今年の3回目。自信を持って言えるのは、今回が一番盛り上がったということ!今年の3人はいいやつだw
その都度少しずつ資料を更新しているのですが、自分でも改めて読みなおしてみると、 もっとちゃんと理解しなきゃなー、とか、もっと別なことも大事なんじゃないかなー、 とか思ってしまい、どんどんボリュームが増えるっていうね。(削除もしてます)
自分の勉強にもなってとてもいい機会でした。いやほんと。人に教えるっていう経験は大事ね。
テスト関連イベントの雰囲気と、TestingCasualTalks#2の感想
5/14に第6回Ques、5/25にTestingCasualTalks#2 と、近い日程でテストイベントがありました。
Quesでは一般参加者として、TestingCasualTalksではスピーカーとして参加したのですが、これらのテスト関連イベントについて思ったこと、感じたことを書いてみます。
前提として、私自身がソフトウェアのQAなのですが、今のところ非開発者なのでお仕事ではコードは書かないです。(書けないんじゃないよ!ちょっとだけ書けるよ!) そんな私が参加するイベントはJaSSTとかWACATEとかです。過去に自分で「Webなテストの勉強会」(タイトルはうろ覚えw)と題して20~30人くらいの勉強会+懇親会を企画したことがあります。第5回Quesではスピーカーとして参加させてもらいました。(その時の資料はこちら) これらの会の空気感はとてもよく似ていて、テストの勉強会ってこんな感じなのねー、って思ってました。(よく考えたら関わってる人たちに共通の知人が多いのであたり前か)
で、今回のTestingCasualTalks#2ですが。 120人(?)くらいの参加者の100人くらいが開発者というね。私の気持ちとしては完全なアウェー感でしたねw 第5回Quesの時はQA、開発者、その他、が1/3でして、そんな体で資料とかトーク内容考えてたので「あれ、これわ...」って思いました。 話をしている最中の会場の暖かい笑い(?)はとてもありがたく、懇親会の雰囲気とかでうまいこと馴染めたかな?って思いました。
今回は3人のスピーカーが登壇したのですが、私以外の人の話は「コードでのテスト」の話がメインで、会場の食いつきもそちらのほうが強かったような気がしました。さすが開発の皆さん、自然言語よりも形式言語で語ってくれってことですよね!<違うと思う
@hsbtさんのmrubyの話は、次が私の発表だったのでドキドキしててちゃんと聞けませんでしたごめんなさいw
www.slideshare.net
2番手として私の発表。ポイントは手書きプレゼンに挑戦 <そこ?
www.slideshare.net
@deme0607さんのブラウザテスト自動化・並列化の話
これは自分の発表が終わって気持ちが解放されていたのと、ちょうどSeleniumWebDriverでのブラウザテストはやったことがある(これからまたやる)のでとても興味深く聞けました。とはいえ、私の場合はまだ「大規模化」とまではいけてないので、技術的な解決方法よりも「ブラウザテスト自動化のメリット(の説明の仕方)」とか参考になりました。
その後のLTではWebサービスに使えそうなテストツールを教えてもらいました。
ちょっと調べてみよう。
発表スライドにも書いたのですが、ガイアックスでは「技術を使ったQA」というテーマで新たな活動を開始しようとしています。そもそも私が技術わかってんの?て感じなので頑張ります。そして一緒にやってくれる人募集してます。いやほんとに。
最後に、QuesとTestingCasualTalksの大きな違いを書いておこうと思います。これはとても大事なことです。
Quesの方がTestingCasualTalksに比べて女性参加者が多い
@ikasam_aさん!TestingCasualTalksも盛り上げていきましょう!私にできることがあれば是非お手伝いさせてください!(女性集客のどこに貢献できるかわかりませんがw)
Ques#6 感想とメモ
2015/5/14 に行われたQues#6のメモ。
永田さんの話に勇気づけられた会でした。
あと、懇親会で知ってる人がだんだん増えてきてそこで近況報告とかするのが楽しくなってきたのでこの輪を大事にしたい。だけど懇親会の時間だけじゃ話足りないのよね。懇親会だけを目的としたイベントとかあればいいのに。(やればいいのか。ただの飲み会だけど)
感想、思ったことを先に
スクラム開発について
スプリント内に終わらない話
- スプリント内にテストが終わらない、あるいはテストは終わってもそこで見つかったバグ修正が終わらない、とか。
- 本来は「○○のバグを修正する」という作業もストーリーとしてチケット化され、ストーリーポイント(作業にかかる工数というか相対的な値)を割り振るのがセオリー。
- だけどスプリントでのベロシティは変わらないはずなので、ここでもスコープ(か納期)の調整が発生する。
- これを吸収するには「バグ修正」のタスクを予め想定しておくこと、かな。
そもそもスクラムのチームって一つのチームなのでは?
- 役割が違うだけで、チームとしてやるべき作業は洗い出されているはず。
- 企画・設計・開発が作ったものをQAがテストする、という仕組みじゃない。
- 企画・設計・開発・QA(必要ならその他の役割も)で一つのチーム、という思想。
- だけどこれまでの経緯から「作ったものをテストする」タイプの関わり方をしていた組織にとって、開発チームの中に入っていって何ができるのか、は課題。うちの会社でも課題。
- でもそこで確立できたら楽しそう。
スクラムに必要なドキュメント
- 何でもドキュメント化するんじゃなくて、チームの暗黙知が高まると、そのチーム内のコミュニケーションは高速になるよ、というのはわかる。
- そうしそうしたいけど、そこに後から入ってくる人とか、引き継ぐ人がいる。
- あるいは将来の自分が見た時に「これなんだっけ?」になりそうなジレンマはある。
- 「必要最低限のドキュメント」として何がアレばいいのか、はその時々だけど、その時々で定義できるのかな自分は。
セッションのメモ
ソニーの永田さんの話を聞いたメモ。(最初のKDDI鈴木さんのセッションには到着が間に合いませんでした)
品質をよくできなければアジャイル開発は成功しない
テストベースどうするのか?
- ドキュメントが書かれない。
- それがないとテスト出来ない・・・うまく関係が持てない
- まずここが障壁になりそう
- なぜドキュメント化しないか?(QAから見て欲しい情報)
- 企画、開発は暗黙知を持っていて、それで意思疎通している。
- 設計をするためにアーキテクチャやプロトコルはドキュメント化している
- そのドキュメントと暗黙知をミックスして開発している。
- その中にQAが入って欲しい情報をとってくる。
設計開発へのフィードバック
- (テストをして)何をフィードバックするのか、を説明する
- そのためにどんな情報、成果物が必要か
- その中で信頼関係が生まれる
- 設計者にテストケースをレビューしてもらう
- 設計にテストを組み込んじゃう
- 設計しているときにシステムテストをやるイメージ
- ツールから取れる情報を見える化する
- メトリクスとかKPIに対する現状とか
- バーンダウンじゃなくてバーンアップチャート
- ストーリーポイントが増えていることがわかる
- ベロシティは経験値。改善していくことで上がっていく。
- 劇的には変わらない
- 手戻り(バグ)を減らす
- コミュニケーションロスを減らす
- 待ち時間を減らす
- 現状の把握(メトリクスとか、事実を見て)
- それに対してどうするかを計画する、何をするのかを都度決める
- (今起こってる、すぐ改善すべきところはどこなのか)
3分悩んだら聞け
- 困ったら聞けばいい→ドキュメント減らせる→暗黙知高まる
QAが(開発プロセスも含めて)改善する
- おしまいのフェーズに入ってくるのではなく
- 朝会も振りかえりもQAが入っていて改善していく
- 施策の効果がメトリクスに現れる
- 例えばバグ傾向のフィードバックとか
ウォーターフローでは情報を待ってた
- アジャイルはイテレーションごとにメトリクスがわかる
- それを改善するところに入っていく、むしろ仕切る
- アジャイル開発を正しく理解することが必要だけど。
- やってることはシステムテストレベル。マニュアルテスト。
- それをやるためのテストベースを「取りに行く」
トークライブ
鈴木さんと永田さんのトークライブ。MCは@snskさんでした。
アジャイルチームに歓迎されるテスターのスキル・人物像
- 鈴木さん
- コミュニケーションに苦痛を感じないこと
- 暗黙知やフィジカルなコミュニケーションがMUST
永田さん
- 年齢とか関係ない。
- 得意なところ、何を提供できるかを「表現できる」と信頼される
永田さん
- 鈴木
- スーパーヒーローはいらない
- どこにでもいる人でやっていける
- マインドセットが大事。
最低限必要なアジャイルチームのドキュメンテーションは
ユーザーストーリーのテンプレはある。ただHOWが書かれていないのでテスト設計ができない。どんなドキュメントが必要になるのか。
- 永田さん
- エラー処理を全ては(ドキュメントに)書くわけじゃない
- が、だいたいパターンが決まってる。(ウィンドウのどこにエラーがでる、的な)
- そこは書こうよ、という決めにした。
- 鈴木さん
- 製品によって違うけど、うちの場合は画面設計書は必須。
- ユースケースマップを作っている
- 誰が目的で使うか、かな。
- (そのドキュメントは)主に設計開発の人がつかう。QAの人もみる。
- 永田さん
- 結局はチームで決めること。
- 今までQAが入っていないなら、これから入っていって「何がアレば自分たちは何ができるのか」を言っていく(成果を出す)ことでチームに信頼してもらう
...以上です。 今回も楽しい会でした。 運営の方、ありがとうございました。
ansibleやってるよ、ほんとに。
ansibleでサーバ環境の構築を自動化しているのですが、なんというか、今さらですが人がやることを自動化していくっていかにも技術ー!って感じでステキ。
ただ、いかんせん私の理解が遅いのと、技術情報の調べ方に慣れていないのでなかなか進まないこと。(でも楽しい)
調べたことがあったのでQiitaに書いてみました。
ansibleやってみてる
久々の更新。そして久々の技術の話。(他の人には役に立たないただの日記)
新人研修として、実際にテストを体験してもらうというアクティビティをやる予定です。 テスト対象は私が作った全然いけていないイベント掲示板アプリ。 自分の勉強も兼ねてRailsで書いてみました。
じつは去年も同じことをやったので、その時のソースコード持ってきて環境だけ作る、みたいなことなのですが、去年は環境構築の部分をまるっと他の人にお願いしちゃいました。
今年はせっかく(?)なので自分でやってみようと。
新人3人分の環境を、Dockerのコンテナ(これは自動で作ってくれる社内サービスを利用)にansibleで構築し、ServerSpecで確認する、みたいなの。
今はansibleで格闘しているのですが、ansibleの書き方以前にわかってないことが多すぎ。 Linuxのこととか、ssh接続とか鍵認証とか、bitbucketからcloneするとか、、、
もちょっと理解のスピードを上げていかないとならない、と焦るものの、焦ってもすぐに理解できる頭ではないので、まぁ少しずつでも前に進もうと思いましたとさ。