日本ヒューレット・パッカード(株)様、社内プロジェクトマネジャー向けセミナーで講演してきました
日本ヒューレット・パッカード(株)様、社内プロジェクトマネジャー向けセミナーであるPM Proffession セミナーに、PMI日本支部*1としてアジャイルについてお話してきました。
講演内容は、
全体で1時間半のセミナーとなりました。
当日は、約100人(リモートでの参加者も含む)の方に参加していただき、社内の関心が高いことがうかがえました。
事情があり資料は公開出来ないのですが、自分がお話した内容をまとめると
- なぜアジャイル開発プロセスが求められているのか?
- アジャイルについて
- 従来型とアジャイル
- 予測型 / 適応型
- それぞれ向き・不向きがある
- 本質的には変わらない
- Don`t do Agile, Be Agile.
想定参加者は、アジャイル初心者を対象としていました。
そのため、アジャイルマニフェストについて理解することが大事であること、そもそもアジャイルのプラクティスだけやってもアジャイルになれないと言う話を強調してお話させていただきました。
講演後、アジャイルにとても興味を持ちましたって方が、お話をしに来てくれて、自分としては、講演した甲斐がありました。
このような場でお話する機会をいただいた 日本ヒューレット・パッカード(株) 一ノ関様、石井様、PMI日本支部 三島さん
一緒にお話した (株)アドヴァンスト・ソフト・エンジニアリング 渡会さん
本当にありがとうございました。
TOCfE認定ファシリテータートレーニング Day2+4Days
TOCfE認定ファシリテータートレーニング Day2
Day1は以下を参照takubon.hatenablog.com
Day2は、TOCfEの3つのツールの復習およびTrT(Transition Tree)を学びました。
TOCfEのファシリテーターは、TOCfEについて詳しく、参加者の学びを最大化する目的があるため、TOCfEの3つのツールについて復習しました。
TOCfEの3つのツール
- ブランチ
ものごとを因果関係で結び、シンプルでわかりやすく、ロジカルにものごとを考えられるようになるツールです。
私は、開発プロセスの改善や現場での課題などの根本的な原因を見つけるために、このツールをよく使っています。
対立解消図ともよばれ、対立を起こしている行動には、その目的(要望)があり、その両者の要望が満たすことが出来る解決策を導き出すツールです。
私は、ブランチで見つけた根本的な課題に対して、クラウドを用いて解決策を考えます。
- アンビシャスターゲットツリー
目標を阻害する課題を洗い出し、その課題が解消した状態(中間目標)を導き出し、中間目標に到達するための、行動を考えます。
目標に着実に進んでいくためのツールです。
私は、開発プロセス改善やアジャイル導入支援などで、行動計画を立てる際に利用することもあります。
研修では、それぞれ、「TOCfEのファシリテーターとしての課題」をテーマに、個人でブランチ、クラウドを作成しました。
その後、参加者1名のブランチ、クラウドを題材に、参加者全員で、ブランチ、クラウドの精度をあげていきました。
TrT(Transition Tree)
ブランチの派生で、ゴール達成に向けての、一連のアクションを相手の立場をふまえて、論理的に設計していくためのツールです。
TOCfEのトレーナーは、このツールを使って、トレーニングコースを作るそうです。
研修では、実際に、アンビシャスターゲットツリーの代わりに、TrTで、「TOCfEのファシリテーターとしての課題」から中間目標を出し、それをテーマにTrTを作成しました。
「目標:ファシリテーターが自分の一つのサービスメニューとなる」で作成してみました。(作成途中ですが...)
※ 付箋が重なって見えづらくてすみません。
実際にTrTを作成した感想は、ツールとしての完成度は高いとは思うが、変更するのが大変だと言うのが第一印象です。
実際にTrTで作成した計画に沿って進めていった際に、計画と現実は異なる事が多いことが予想され、計画を作り直す際に、このツールでは変更コストが高そうです。
(研修で実施した程度なので、実際に使ってみたら違う印象になるかもしれません)
TOCfE認定プログラム
ファシリテータートレーニングの後、8/13から8/16の4日間、TOCfE認定プログラムにファシリテーターとして参加しました。
ファシリテーターの主な役割は、認定プログラムで実施されるグループワークでのサポートです。
詳細は、参加者の方がきっとブログなどに書いているでしょうから、ここでは割愛します。
今回の参加者の方たちは、意識が高く、ファシリテーターとして困る場面はほとんどありませんでした。
ファシリテーター同士も信頼し合える仲間として、とても有意義な時間を過ごすことが出来ました。
参加者のみなさん、講師のみなさん、スタッフのみなさん。ありがとうございました。
さいごにTOCfE横浜塾のご紹介
現在、TOCfE横浜塾を主催しています。
参加者の方が作成してきた、ブランチやクラウドを全員でレビューしディスカッションしていきます。
初心者の方には、スタッフがTOCfEについてサポートいたします。
みなさまのご参加をお待ちしております。tocfe-yokohama.doorkeeper.jp
ディスカッション用のFacebookグループもあります。
https://www.facebook.com/groups/yokohama.juku/
TOCfE認定ファシリテータートレーニング Day1
TOCfE認定ファシリテータートレーニング
毎年夏に、京都、東京で交互に行われている
TOCfE認定プログラムに、ファシリテーターとして参加してきました。
今年は、ファシリテーターは、認定ファシリテータートレーニングがあり、認定ファシリテーターになるために、参加しました。
ファシリテータートレーニングは、認定プログラムの前に2日間行われ、認定プログラムでのファシリテーターと合わせると計6日間の怒涛スケジュールになりました。
ファシリテータートレーニング Day1
Day1は、TOCfEのファシリテーターについて学びました。
TOCfEのファシリテーターは、通常のファシリテーターとは異なり、TOCfEについて詳しく、参加者の学びを最大化するために存在します。
そもそも、TOCfEでのファシリテーターって何って言うのを、Day1では学びました。
そもそも、ファシリテーターってなんでしょう?
私のファシリテーターの定義は、その場を構築し、参加者がその場のゴールに到達するためにサポートする人(答えは参加者が持っている)と定義しています。
TOCfEのファシリテーターと、通常のファシリテーターの定義で異なるところは、TOCfEのファシリテーターは、TOCfEに精通していることが条件になります。
参加者がワークで躓いているのであれば、適切な質問(TOCfEとしての)をする必要があります。
ファシリテーターは、参加者が目的を達成できる。答えを出せると信じる。
主役は参加者であることを常に最優先に考える。
事が求められます。この辺りは通常のファシリテーターと同じですね。
研修の途中で、今回のファシリテーターとしてのODSC(
プロジェクトの計画と実行 – ODSC とは? | 生き抜く力。
)
を各チーム毎に定義しました。
私のチームのODSCは以下のとおりです。
- O(目的):4日間の後も学び続けたい気持ちを持ってもらう
- D(成果物):みんなで考える楽しさに目覚めた参加者
- SC(成功基準):自ら勉強会を開催する意思表明する受講者がいる
成功基準である自ら勉強会を開催する意思表明をする受講者がいるとかなり高めの成功基準を設けましたが、北九州で勉強会を発足すると言う方がいらっしゃったので、私達のODSCは満たされました^^
ファシリテーターとしての基本的行動順序
こちらは、ファシリテーター協会の吉池さんが講師となり、進められました。
重要な要素は以下の3つ
- 観る
- 聴く
- 話す
この講義で感じたのは、傾聴(
傾聴(けいちょう)とは - コトバンク
)が重要だと
私もアジャイルコーチを行っており、傾聴を意識して行っていることもありますが、ファシリテーターとしても傾聴はとても重要なのだと感じました。
ここでやったワークもとても面白く、傾聴スキル云々としてもそうですが、アイスブレイクでも使えると感じました。
最後に認定プログラムを想定したロールプレイングで、実地研修を行いました。
個々のファシリテーターとしての問題が浮き彫りになり、とても面白いロールプレイングでした。
ロールプレイングの題材は、実際にTOCfEの認定プログラムでの実体験を元にしていると聞いて、参加者としても面白い人達がいるなぁと思った反面、そんな人ばかりだったらどうしようと不安にも思いました。
(実際の認定プログラムでは、そんな不安が的中することはありませんでした^^)
ファシリテータートレーニング 1日目は以上です。
その後、ファシリテータートレーニングとマスタートレーニングを受講した方々で懇親会があり、NPO 教育のためのTOCについて、マスタートレーナーの松山さん、理事の吉田さん、大東さんとディスカッション出来たのがとても良かったです。
つづきは、また ファシリテータートレーニング Day2に書きます。
PMPを取得しました
6月のネタですが、また資格取得ネタでもう一つ
PMIが認定しているProject Management Professional:PMPを取得しました。
PMPとは
PMP - Wikipedia
受験資格
PMP®試験の受験資格|PMI® 試験・資格について|一般社団法人 PMI日本支部
試験について
PMP/ PgMP | プロメトリック
なぜPMPを取得しようと思ったのか?
なぜ、アジャイルを推奨する立場で、今更PMPを取得しようと思ったのかと言うと、理由は2つあって
PMI日本支部のアジャイルプロジェクトマネジメント研究会に所属し、アジャイルの研修を実施しており、
PMIに関する人との関わりが多くなり、良い機会だと考えたこと。
アジャイルの基礎的な研修を行う際に、従来型のプロジェクトマネジメントと比較をしてお話する機会が多く、過去の体験や知識(私の知識はPMBOK第3版ベースでした)だけでは無く、PMBOKに則った形でお話をしようと考えたのが理由です。
PMBOKとアジャイル
まず学習し始めて思ったのは、アジャイルと基本的な考え方は同じであると言うことで、比較的学習は容易でした。
例えば、プロジェクト憲章は、アジャイルで言うビジョニングに当たりますし、スコープマネジメント計画での要求事項収集、スコープ定義は、ストーリー収集に当たります。
コミュニケーションマネジメント計画では、ワーキングアグリーメントの設定や、スクラムイベントの設定などです。
この辺りの話も今後、ブログに書ければと思っています。
今回は、実際の試験についてお話します。
会場入り
試験会場は、プロメトリックの東京(御茶ノ水ソラシティ)でした。
試験会場のご案内:御茶ノ水ソラシティテストセンター | プロメトリック
横浜会場は無くなってしまったようです。
試験開始時間は、AM9:00開始か、PM1:00開始かを選べるのですが、自分はAM9:00を選択しました。試験時間は4時間です。
4時間タバコを吸えないので、自分は8:30には現地に到着し、レッドブルを飲みながらタバコを吸って、余裕を持って会場入りしました。
受付
会場に入り、受付をします。必要なのは事前にメールで送られてきた試験の情報と身分証明書です。
有効な身分証明書にはいくつかあるのですが、免許証だとクレジットカードなどが必要になるため、1つで済むパスポートを持って行きました。
受付を済ませると、試験の注意書きとロッカーの鍵が渡されます。
ロッカーに荷物(飲み物を事前に買っておくことをオススメします。休憩時にロッカーに入れた飲み物は飲むことが可能です)を入れて、呼ばれるまで待ちます。
その間、勉強していることも可能ですが、自分は腹をくくって試験の注意書きを読んでました。
試験会場入り
試験会場に入るために、また受付があります。呼ばれたら、その受付で、金属探知機での持ち物チェックや試験の注意を聞き、入場時間等を記入して、試験会場に入ります。
持ち込めるものは、身分証明書と受付でもらう鉛筆2本と計算用紙4枚だけです。それ以外は基本無しです。(ティッシュは何枚かは持ち込めるみたい)
試験会場は、さながら静かなプロジェクトルームのようで、既に試験を受けている方も何人かいます。
いざ試験
席には、PCとマウスと耳栓代わりのヘッドホンがあります。
最初に試験の説明とデモ画面が表示されますが、英語なのでさっとやめて、すぐに試験にとりかかりました。
問題は200問で、英語と日本語(試験申込時に日本語を選択する)の2画面表示になっており、チェックボックスは、英語の画面にのみあります。
日本語で問題を読んで、英語の画面にチェックを入れるのは中々違和感があります。
私が受けた試験問題は、長文が多く、問題文を全て読んで回答するケースが多く、全ての問題に回答するのに3時間半以上かかり、見直す時間は少ししかありませんでした。(模擬試験などでは、2時間で全ての問題を回答出来ていたので見直す余裕があるつもりでした)
途中退出可能
途中退出する際は、試験会場の受付に行き、退出時間と名前を記入して退出します。自分は、100問終わった時点で、気分転換のためにトイレに行き、ロッカーに入れてあった水を飲んでリフレッシュしました。
タイムアップ!
4時間が経過した時、ダイアログが表示され強制終了
アンケート画面が表示されるも、英語なので即終了
すると画面上に、採点結果が表示される「Pass」と表示され合格したことを知る
試験会場を出て、名前、退出時間を記入して、試験結果を印刷したものを受け取ります。
アジャイルサムライ横浜道場「リファクタリング:技術的負債の返済」を開催しました。
アジャイルサムライ横浜道場は、アジャイルの代表的な書籍である
アジャイルサムライをベースに担当者が章ごとにネタを準備し、それをベースにディスカッションする形式の通常会と、ワークショップや講演を実施する特別会を 2012年から実施している読書会(勉強会)になります。
今回(8/4)のアジャイルサムライ横浜道場のテーマは、「リファクタリング:技術的負債の返済」でした。
ディスカッションのお題ネタは、大中さんにお願いしました。
大中さんが遅れていたので、先にディスカッションしたいネタを募集(投票してもらい優先順位を決定)
- リファクタリングをどこまでするの?
- レガシーコードのリファクタリングの仕方
- 教育どうしてますか?
- テストでカバー出来ないデグレをどこまで許容していますか?
- リファクタリングのガイドラインはありますか?
- リファクタリングしたコードをレビューしていますか?
- リファクタリングがふるまいを変えていない事をテスト以外で確認している方はいますか?
大中さんのスライドはこちら
www.slideshare.net出てきた話で面白かったをいくつかピックアップ
- 大掛かりなリファクタリングを実施した後にバグが発生すると一気に信頼貯金が無くなる
— テストで担保していたので、リファクタリングが原因でも無いのでは
- あまりにも大掛かりなリファクタリングを実施してしまい、大丈夫か自信が無くなって消してしまうことがある
- レガシーコードで変更がある部分だけテストを追加してリファクタリングを行うが、変更の無い部分はレガシーのままのものがある
- 教育のためのコードレビューでは、自分たちのコードでは無く他のチームのコードレビューを行ったりする
— 自分たちのコードで指摘されると、落ち込む人がいる(自分が書いたコード=自分自身)
大中さん、ありがとうございます。
次回は、9/9(水) 会場の関係で次回は水曜日になります。
テーマは「テスト駆動開発」になります。
https://yokohama-dojo.doorkeeper.jp/events/29615
参考
githubページ : http://bit.ly/yokohama_dojo
ディスカッション用FBページ : https://www.facebook.com/groups/yokohamadojo/
twitter : https://twitter.com/yokohama_dojo
日本で16番目のCertified Scrum Professional(CSP) 取得しました
CSPとは、スクラムでのより深い知識と経験を実証したことを認定する資格で、認定スクラムマスター(Certified ScrumMaster:CSM)、認定スクラムプロダクトオーナー(Certified Scrum Product Owner:CSPO)、認定スクラムデベロッパー(Certified Scrum Developer:CSD)の上位の資格になります。
Scrumの世界的な団体であるScrum Aliance が発行している認定資格で、認定スクラムマスターは有名なのでご存知の方も多いのでは無いでしょうか。
CSPの資格を取るためには、Certified ScrumMaster (CSM)・Certified Scrum Product Owner (CSPO)・Certified Scrum Developer (CSD)の、いずれかの現役有資格者であること。
過去5年で、合計36ヶ月分のスクラム・アジャイルに関する(成功)経験を積んでいて、説明できる状態にあること。
過去3年で、SEU(Scrum Education Units、後述)を70ポイント以上取得していること。が取得条件になります。
上記が揃ったら、Scrum Aliance にレビューを申請します。レビュー申請には100ドル掛かります。
レビュー通過して、150ドル支払いすると、晴れてCSPとなります。
申請は全て英語で書かなくてはなりませんので、英語力の無い自分は、なるべく短文にして、Google翻訳で翻訳をしたものを、辞書で確認しながら記述したので、かなり時間が掛かりました^^;
資格取得方法をブログに挙げていただいた伊藤さんに感謝です。d.hatena.ne.jp
大量のissueを一括登録する方法
GitHubを拡張してかんばんっぽく利用できるZenHub.io - Agile Project Management inside GitHubいいですね。
イニシャルバックログの登録を一括する方法として、hubをインストールしてコマンドラインから登録しました。
参照:GitHub | Command Line で GitHub を操作する hub の基礎 - Qiita
まずは、hub をインストール
brew install hub
そして、エイリアスを登録して、gitコマンドとして扱えるようにします。
eval "$(hub alias -s)"
これで、コマンドラインからissueを登録できるようになります。
あとは簡単
ちなみに issueコマンドの使い方はこんな感じ
usage: git issue or: git issue create [-m <MESSAGE>|-f <FILE>] [-l <LABEL-1>,<LABEL-2>...,<LABEL-N>] git issue create -m "issue title"