作成者別アーカイブ: toshiotm

toshiotm について

京都アジャイル勉強会を共同主催。 CSM CSPO CSP @toshiotm

社外スクラムマスターとしてRSGTについての思いを書きたい(かも)

おはようございます。これは、Regional Scrum Gathering Tokyo Advent Calendar 2018 の5日目の記事です。

昨日は、Ken Takayanagiさんの「RSGT2019にチームでの対話についての場が見えてきた話」でした。
チーム内で上手に衝突するって難しいですよね。高柳さんはファシリテーションのプロなのでチームの衝突に困っている方は是非RSGTでワークショップに参加してみる、もしくは、他のイベントで高柳さんを捕まえてみてください。

それでは、「社外スクラムマスターとしてRSGTについての思い」をつらつらと書きたいと思います。

どうして最初RSGTに参加しようと考えたか

実は、初参加は2017年でした(めっちゃ最近やん)。
スクラムは、2009年にCSMを取得してから、試行錯誤の末、どうにか実践できるようになっていました。

スクラム開発当初の試行錯誤はこちらで発表させていただきました。(あっ会社変わってるw)

それまでは自分のやっていることは、スクラムをそのまま実践しているだけなので、スクラム系のイベントで発表できることなんて何もないなぁと感じていました。
それに、関西からまる3日間(当時は2日間)も仕事も家族も完全フリーにして参加するのは結構自分にはハードルが高く正直考えていなかったです。
(ちょうど2人の子供もかわいい&手がかかる時期だったりもして)

それがたまたま非ソフトウェア会社でスクラムを実践したので、お店の宣伝がてら発表して何か提供できるかもと思い初参加&初登壇しました。

自分の発表がどうだったかは自分ではよくわからないですが、発表後に何人かの方に自分も非ソフトウェア業界にいるのでやってみたいとフィードバックをいただけたのは嬉しかったです。

社外スクラムマスターとしてRSGTをどう捉えているのか

参加前まで、海外のアジャイル系のイベントだとアジャイルコーチの集客的な要素が強くなっていると聞いていたためてっきりRSGTもそうなのだと勝手思っていました(食わず嫌いすぎた)。

でも、実際に参加してみて感じたことは

  • 日本のスクラムの浸透具合がある程度わかる
     事例セッションを聞いているとスケーリングの話が出てきている一方、非ソフトウェアやハードウェア系でのスクラム実践事例が少ないように感じているので実際に業界によってまだまだ偏りがありそう。

  • 年初にRSGTが開催されることもあって、日本でその年のトレンドになる考え方やプラクティスが発表されることもあります
     社外のスクラムマスターは、同時並行して複数チームを持っているため、短期間で複数チームの知見が貯まりやすいです。
    (契約の範囲内で)複数チームでの複数の経験(それもその年に発表されたような新鮮なやつ)を一気に日本のスクラム現場に広める事ができる

  • 通訳があるとはいえ、英語セッションに参加する経験が得られるので、海外イベント参加への敷居を下げてくれる
     今年はAgile Vietnam Conference 2018に参加したのですが、RSGTで全て英語セッションに参加しているのとあまり違和感ありませんでした。
     Kiroさんの英語セッションも日本での英語セッションと変わりなくて、一瞬日本にいるのかと錯覚したくらい。あっでも笑いはあっちのほうが断然多くおこっていた!

  • 1年を通じて心地よいプレッシャーを感じ続けられる
     RSGTでしか会えない人たちもかなり多いため、1年間何してたの?とならないためにも、プロポーザルを出せるように(採択されるかどうかは問題じゃない!)、1年間心のどこかにRSGTの心地よいプレッシャーを感じつつ複数の現場に立つことができる。

社外スクラムマスターとしてとか書いていますが、完全に個人の主観です(でした)。
ただ、スクラム研修以外で、3日間完全に社会から隔離され、スクラムのことしか耳に入らない、話さない、考えないができるイベントもなかなかないので、どっぷり浸かってみたい方は是非参加してみてください。

おわりに

明日は、yasudatadahiroさんの「スポンサー視点からRSGTの素晴らしさを伝えてみます」です!
コミュニティの主催はしているのですが、スポンサー様に協賛していただけるほどのイベントを企画したことはないので、今後のためにも是非知りたいです!

おわりのおわりに

番宣です。
社外スクラムマスターから社内スクラムマスターになってでも、長く関わっていきたいと感じた組織のプロダクトの過去・現在・未来を発表させていただきます。
ご興味ある方は是非ご参加下さい。
チームワークの会社で最高のプロダクトを目指すチームができるまで -強くてスケールするチームの作り方-

改善出来ないチームで継続的に改善に取り組むには

Startup Stock Photos

緊急度高なタスクばかりをやっているチーム。
日々の残業やときには休日出勤も行われている。
トップダウンで改善策をするように指示され続けているが、どれもできていない。

仕事が終わらなくて残業しているのに、トップダウンで支持された改善策をする時間なんて無い。
というのが、チームの本音じゃないだろうか。

こういった状況でどうやったら改善できるかという話になったとき、チームの人たちに「改善に取り組んだら少しでも良くなるんだという」小さな成功体験とまではいかなくても感覚を持ってもらえるようにしたいなぁと。

時間がない人たちだからこそ、本気で改善したい問題・課題を自分たちで選んで、実現できそうな改善策を自分たちで実行することがとても大事なのではないか。ということで、

  • チーム全員で、発生している問題や課題だと考えていることを5分程度で付箋に書き出す。
  • それぞれ書き出したものを説明する。その際、先の発表した人と同じ問題だと思ったら自分で近くに集める
  • 付箋には問題の本質ではなく感情や状態が記載されていることが多いので、問題の本質に行き当たるまで、「なぜそれが問題か?」をチームで深掘りする。
  • 各人2票ずつで改善したいと考えていることに投票する。
  • 投票数の多いものに対して、1週間以内に自分たちで実行できそうな改善策を考える。
  • 改善策は、全てタスクになっていて、改善策が実施されたかどうかが、どうやったらわかるかも一緒に合意しておく
  • 次週、前回の改善策で改善したかの確認を行う。
  • 引き続き同じサイクルで改善活動を実施し続ける

せっかく自分たちで出した改善案に、リーダーやマネージャーが異論を唱えてしまうと、改善しようという空気になっていても、いっきに場の空気が元に戻ってしまう。
取り組む問題や課題よりも、改善活動で実際に改善されたというチームの実感が湧くことがまずは、とても重要なんじゃないかな。

どうせ残業するなら改善活動をするためにしたい。

受託開発という名前の弊害

受託開発という分野を作っているのは、実は開発を行っている側が自分たちは受託開発だと思い込んでいるだけで、世の中に受託開発っていうのは、本当はなくって、お客さんは、自分のビジネスをいい方向に一緒に考えてくれる人に発注した(orしたい)と思っている。
それは、お客さんの会社の大きさ(大きな企業とか小さな会社や個人事業主)には関係ない。

作る側のビジネス・モデルの都合で、「考える事」と「つくること」を分けて作業し始めたから、お客さんも手を動かしている開発者も不幸な結果になってしまうことが起こっているんだなと自分の足で立って、営業から開発までやってみて今更ながら実感。

大企業のお客さんと仕事をしていた時に、大企業の中でも情報システム部門(or100%小会社)に属していない、本当の発注者の顔や声に直接触れられた時に会社なんてどうでもいいから、この人が喜ぶために、全力で考えて、社内だろうが社外だろうが全力で泥臭い調整業務を行って、開発チームに対しても自分に対しても「それは、お客さんが喜ぶかな?」と言うことを常に問い続けた。

結果、終わった時にお客さんに笑顔で言われた「お願いして良かったです」という言葉がすごく嬉しかった。

という2年前のポエムを忘れないようにメモっておく。

UbuntuにインストールしたjenkinsでR言語のRUnitを動かす

UbuntuにインストールしたjenkinsでR言語のRUnitを動かす際に、ハマったポイント。

jenkinsのjobの下にRUnitをダウンロードしたかったので、

options(repos="http://cran.ism.ac.jp/")
install.packages("RUnit", lib=Sys.getenv('WORKSPACE'))

library(RUnit)

runTestFile("test.sample1.r")

と記載したところ、

`RUnit’という名前のパッケージはありません

と言われてしまった。。。。

installされたパッケージをlibraryに教えてあげないとわからないようなので、

library(RUnit)

と記述していたところを

library(RUnit, lib=Sys.getenv('WORKSPACE'))

に変更したら無事読み込んでくれました。

これで、テストが動かせる。

UbuntuにインストールしたR言語でpackageのインストールがうまくいかない場合

もうタイトルそのままで、ただ自分がハマっただけだというTips。

Ubuntuのr-base(R言語)のバージョンが最新でない可能性があるので、r-baseを最新にしてから再度試してみたら、うまくいった。

ちなみに、Ubuntuのバージョンは、 Ubuntu 14.04 LTS(Trusty Tahr)

r-baseのアップデートは下記を参考。
UbuntuにRをインストールするための手順

今回は、RUnitを利用したかったのでパッケージにRUnitを指定。

install.packages(“RUnit”)
library(RUnit)

これで、RUnitが使えました。

INVESTだけでいんですと?

@posauneさんのINVとESとTのポストを読んで、京アジャのレフトウイング(どっちがどっち担当だったっけ?)として勝手思ったことを書いてみる。

実際のプロダクトオーナー(PO)にINVESTとはですねーといっても必ずしも技術畑でもなければ、暇でもない(POが暇だって?!)POになかなか意識して書くことを要求するのは酷だったりする。
(書き方を気にするあまり、追加するのをためらわれたら本末転倒)

けれど、POはプロダクトへのアイデアはあふれんばかりに持っている(はずだ!)から、アイデアを思いついた時にプロダクトバックログですぐにでも関係者に共有したい。

こんなときどうすんの?

プロダクトバックログにはゾーン(Zone)という考え方がある。

気にしないゾーン

プロダクトオーナーは、アイデアレベルのプロダクトバックログアイテムを、まずは気にしないゾーンに入れておく(INVESTですらないかも)。

気にしないゾーン

気にしないゾーン

荒目ゾーン

次のスプリントではないけど、近々行いたいプロダクトバックログアイテムを荒目ゾーンに移動する。
この荒目ゾーンで、INVが満たされているものがきていれば、POとTeamや関係者とのコミュニケーションが進んで、中期的にどんなことをやろうとしているのかが共有出来て、コミュニケーションがはかどる。

荒目ゾーン

荒目ゾーン

詳細ゾーン

詳細ゾーンは、市場の状況が変わらなければ次のスプリントで着手するプロダクトバックログアイテムが入っているはずなので、可能ならINVESTであることが望ましい。なぜかというと、スプリントプランニングにコストをかけ過ぎたくないので。
当然、アクセプタンス・クライテリアを詳細に書かないとTestableにはならないし、スプリントプランニングでコミュニケーションコストをかけ過ぎてしまう。

詳細ゾーン

詳細ゾーン

とうことで、POに優しいプロダクトバックログを作るためにはINVESTに合わせてZoneも意識してみてはいかがでしょうか?

「京都アジャイル勉強会 アジャイル1日体験ワークショップ vol.2」を開催しました

京アジャ アジャイル一日体験カバー

当日は、台風接近中という状況にもかかわらず、ほぼキャンセルなく参加して頂きました。
ご参加頂いた皆様有難うございました!

イベントページ

http://connpass.com/event/7562/

開催理由

京都アジャイル勉強会Lightで行っていた「アジャイルサムライ」読書会(第2回目)の卒業イベントを兼ねて、一日アジャイル体験イベントを行いました。

また、アジャイルもかなり経験者が増えてきているかと思うのですが、京アジャの周りではまだまだ座学やプラクティスだけという方もいるため、少しでもアジャイルの素振り経験を増やすお手伝いができればという思いもありました。

概要

makedoという子供向けなんだけど大人も本気になってしまう工作キットを使用して、「宇宙基地開発」をプロダクトにして行いました。

詳細は、またやるかと思うのでここでは省くとしてw
1年前に行った同イベントから主催者が得たフィードバックを受けて、今回工夫した点を記載します。

前回からの変更点

ユーザーストーリーの作成

経緯

前回のイベントではユーザーストーリーの作成を各チームで行いませんでした。
理由は、ユーザーストーリーをINVESTな状態に持っていくのは、非常に時間がかかるため、アジャイル初心者で、しかも限られた時間内に当日初めて聞いた宇宙基地開発のユーザーストーリーをPOの意思をくみつつ作成するのは難易度高すぎると考えて、宇宙基地開発に必要なタスクを出して下さいということにしていました。
そのため、単なる作業リストが出来てしまいPOの価値に直接紐付かなかったため、別途時間を取ってやり直すチームが出てしまいました。

Try

今回は、ユーザーストーリーは事前に主催者が作成しました。
でも、一度は経験してほしいということで、各チーム一つだけユーザーストーリーを作成してもらうことで、少しだけれどもユーザーストーリー作成の素振りをしてもらうことにしました。

気付き

各チーム同じユーザーストーリーでプロダクトを作成してもらったので、出来上がったプロダクトに各チームごとの特色が出ていた。通常のプロジェクトだと、同じユーザーストーリーで複数チームがプロダクトを作るとか贅沢すぎて出来ないと思うので、プロダクトの比較をするという良い経験ができた。

事前に、各チームごとにPOとユーザーストーリーの中身や優先順位について話し合っていたため、第一スプリントから出荷可能なプロダクトが出来ていた。

ただ自分たちで作成したユーザーストーリーから着手したチームは、プロダクトについての理解が浅い状態で作成したユーザーストーリーだったため、そこにPOの意思が見えずに苦労していた。

ユーザーストーリーの内容に、チームとして理解できるているか(なぜ必要なのかを含めて)がスプリント中に混乱が起こるか起こらないかに、かなり影響するということを経験出来たのではないかと感じました。

完了の定義(Difinition of Done)の導入

経緯

前回のイベントでは、完了の定義を設けなかったため、スプリントレビューの際にチームがプロダクトオーナー(PO)からの質問にそれなりに答えられていれば、レビューOKという流れが何となく出来てしまいました。
そのため、終了時間が差し迫った後半のスプリントに作成したプロダクトの出来がちょっと雑になってしまう傾向がありました。

Try

その反省を踏まえて、予め用意したユーザーストーリー全てに完了の定義を設定しました。
POは、スプリントレビューの際に、この完了の定義を確認することで明確に完了と判断することが出来ました。

気付き

予め完了の定義を与えられているとチームはスプリント内に検証環境(デモ用に用意されたテーブル)に作成途中のプロダクトを持って行き、完了の定義を満たしているか自分たちでチェックを始めました。

これは、前回のイベントでは無かった行動でした。
完了の定義を設定し事前にチームに共有しておくことで、チームは作成途中のプロダクトを使って常に完了の定義をクリアしているかをチェックしながらプロダクトの作成を行っていました。

実際のプロジェクト開発でも、チームの成熟度に応じた完了の定義をチームで作成&共有することで、コミットされたソースコードの品質を一定に保つことが出来るということの擬似体験が出来たのではないかと感じました。

最後に

参加者の方に、振り返りを兼ねてコメントを頂いたのですが、その中でも
* プロダクトの内容が面白かった(社内でパクらせて下さいw)
* ユーザーストーリーのボリューム感がちょうどよかった
* 時間の関係なんだけど、前半のユーザーストーリーの作成までをもう少しじっくりやりたかった
などの意見を頂きました。
2回目ということで主催者側としては、1回目の反省点をフィードバックした内容に出来たかなと。
3回目を行うなら、ユーザーストーリーのところをもう少し厚めにできる工夫を凝らしたい。

当日の風景

写真 2014-08-09 15 52 30

写真 2014-08-09 15 53 01

「DevLOVE関西×泥臭い受託開発を語り合う」で発表してきました

今回発表させていただいたのには理由がありました。

訳あって7年勤めた会社を退職しました。
その際一緒に仕事をしていた人への引き継ぎを行っていたのですが、丁度DevLOVE関西で「泥臭い受託開発を語り合う」勉強会が開催されるということで、ここに引き継ぐ人に参加してもらって、ここで引き継ぎを完了させようと勝手にたくらんでいました。

ところが主催者側の都合で開催時期が2ヶ月伸びてしまったのと、引き継ぐ予定の人に開催日を伝えるのを忘れたため、結局ただの発表となってしまったという経緯がありました。無念。

すごくコンテキストを絞った発表だったため、お役に立てるかかなり心配だったのですが終わった後素敵なフィードバックを複数頂きました。
参加された皆様、資料をご覧になってフィードバックをくれた皆様有難うございます。

7年間勤めた会社で得た自分なりの経験を引き継ぐ人に少しでも伝わればという思いで作成した資料だったのですが、同じ境遇の方に何かを感じ取って頂けたため無駄にはならなかったというだけでもすごく嬉しい日となりました。
また、退職した実感が湧いていなかったため自分にとっても卒業式的なイベントとなり、お陰様で無事卒業出来ました。

普段は京都アジャイル勉強会で素振りを行っています。発表資料の内容やアジャイルに興味をお持ちの方は是非お立ち寄り下さい。

スクラムによる受託開発#2

〜スクラムを学び始めた自分へ、今伝えられるなら何を伝えたいか〜

7年前にスクラムを学び始めた自分に、今の自分がスクラムを伝えるなら何を伝えているだろうか。

契約について

スクラムで受託開発をする場合の契約は、どうすれば良いのだろうか?

NobMouse via flickr

Contracts

最近では、IPAが非ウォーターフォール型開発時の契約書を公開している
http://www.ipa.go.jp/sec/softwareengineering/reports/20120326.html

他にも、@kdmsnrさんが翻訳してくださっている「次のアジャイルソフトウェアプロジェクトに使える10の契約」もすごく参考になる。
http://capsctrl.que.jp/kdmsnr/wiki/transl/?10-agile-contracts

ただ、実際のところ受託開発で下請け側の意向で契約形態の変更は、かなりハードルが高い。
大抵は、会社全体で同じ契約書を使用しており、それをプロジェクトに依存する箇所(※1)のみ変更して契約している場合が多いと思う。

では、契約方法が変更できないからスクラムでの開発は出来ないのかというと、案外そうでもない。プロジェクトのコンテキスト(※2)に依存するところは多分にあると思うけれど、
「契約が変えられない=スクラムを導入できない」
では、思考停止してしまう(実際そう思っていた時もあって、プラクティスに走ったりもしたけれど。。。)
では、どうすれば良いのだろうか?

何も変えないという方法

実際のプロジェクトで契約しているのは、納品日と金額と納品する成果物だけであって、どのストーリーを実現するかを契約書に記載しているわけではない(あくまで自分の場合はだけれど)。

ということは、決められた金額、納期、成果物を満たしつつ、よりユーザーにとって価値のあるストーリーからプロダクトを作り、その都度フィードバックをもらい、大きな変更については他のストーリーとの優先順位をつけてもらい、今回の開発から外して、次回の改定に回してもらうなどの交渉を行いながらやっていく。

実際ユーザーもプロジェクトのかなり早い段階で、プロダクトに触れる事ができるため、真剣にプロダクトを触りながら、優先順位やフィードバックを出してくれる。
(見慣れないExcelファイルに書かれた図と小さい文字をみて内容に承認を求められ、その結果、数カ月後に作りましたと初めて見せられた時には既に修正するには手遅れなどという状況にはなりにくい)

実行するにはいくつか注意点も

Warning breakdancers!

受託開発をスクラムで行うには、READYになっておく必要があり、これらもそのための準備だと言える。

  • ”要件定義”から参加するプロジェクトであること

要件定義の段階から、ユーザー、発注側とスクラム開発に向けた準備を進める必要がある(あくまで、スクラムの準備だと考えているのは開発チームだけ)。
主に、インセプションデッキ(※3)を使用してその準備を行っている。
ただし、インセプションデッキは、要件定義〜基本設計の間に作成してこそ本来のパワーを発揮するツールだと思う。
詳細設計からスクラム開発を行うと、かなりの部分で交渉の余地がなくなっているため、その段階でインセプションデッキを作成しても、現状の把握には利用できるが、交渉の余地があまり残っていない分、その効果も低い。

  • 発注側に、開発途中のプロダクトをユーザーに見せて確認する旨を伝え、了承を得ていること

事前に発注側に
「今回のプロジェクトは不確定要素が多いため、リスクヘッジを兼ねてプロジェクトの早い段階からユーザーに単体テストが完了しているプロダクトをお見せしてフィードバックをもらいたい」(※4)
と正直にお伝えすること。
決して、スクラムを使用して開発しますなんていう必要はない(言うことで、逆に抵抗にあうことだってありうる)。
リスクヘッジについて考えてくれているということで、好意的に取られる可能性もある。

契約も標準もリスクを管理(or回避)するための手段だと思う。
それを考えた人たちには、すごく意味のあるものだけれど、その恩恵を受けるところからしか関わったことのない人たち(自分も含め)には、なぜ契約と標準があるのかもセットで伝承しないと、その有り難みも弊害も理解できない。

スクラムを使った開発を行うということがきっかけで、この辺りに疑問が持てるようになったことも、すごく学びにつながった。

次は、インセプションデッキかな。

※1契約名、金額、納期、納品物など
※2業務系のWebシステム開発で要件定義〜基本設計;準委任契約、詳細設計〜システムテスト:請負契約となることが多い
※3インセプションデッキ自体は、スクラムのツールではないけれど、全てではないにしろ必要な物は、必ず作成したほうが良いと思う。
※4全く不確定要素のないプロジェクトなんてないとも思うけれど

スクラムによる受託開発#1

〜スクラムを学び始めた自分へ、今伝えらるなら何を伝えたいか〜

7年前にスクラムを学び始めた自分に、今の自分が伝えるなら何を伝えているだろうか。

どこから手を付けたらいいのか?

7年前の自分は、スクラムを自分が参画するプロジェクトに適用しようと考えた時に、どうやって、どこから適用しようか色々と試行錯誤した結果、失敗に終わった(※1)。

今、あの時の自分に教えるなら、まず何から始めることを教えるかな。

スクラムは開発ツールの一つ

ツールとして使用できるようになるまでには、それなりの準備が必要。

いきなり使って、すぐに上手には使えなくて当然で、まずは、次のステップをふんでチーム作りから進めたい。

 

Step1.

組織内で1人は、サラリーのためだけに仕事をしているのではなく、より良い物をユーザーに届けたいという思いがあるメンバーを見つけ、チームに入れること

最初のフォロワーは、自分で見つけるということ。
(有名なこの動画の様に最初のフォロワーが見つかればよいが、見つからなかったら見つけるしかない)

何がユーザーにとって本当に必要な価値であるかを話し合えるメンバーがいて、開発中に2人でそのことについて話していると、次第に他のメンバーも巻き込まれていく。
つまり、2人でどれだけちっぽけでも良いので、まずは同じ目的地に向かうバス(※2)を作ることが、重要だと思う。何も、いきなり全員バスに載せる必要はない(そういえば、いきなり全員バスに乗せようとして失敗したことも。。。)

他のメンバーが仕様書を実装するあまり、ユーザーの価値を考えて開発できなくなっているメンバーだった場合(悪い人では決してないのだけれど)、1人でどれだけ熱く語ったところで改宗してもらうための努力は、徒労に終わることが多い(手を動かすオペレーターという役割が長すぎて、そもそも価値って何?となっている人も少なくない)。
相手にとって興味が無い事へ興味を向けさせることほど、大変なことはないと思う。すくなくとも自分の場合そうだった

まさに北風と太陽で、バスに乗ってほしいのであれば、矯正するのではなくて、バスに乗って楽しそうにしているところを見せれば良い。

 

Step2.

1人見つけたら、一緒に社外のスクラムイベントに参加して、スクラムを最初から最後まで通して学べるワークショップに参加すること

image via “Scrum Simulation with LEGO”

スクラムの開発プロセスは、1枚の図でよく表されていることが多い。
それだけ、プロセスについての表面的な理解はそんなに難しいことではない。
でも実際にやると、

  • プロセスをなぞってはいるものの、チームのやる気が今までと何も変わらない(やらされている感)
  • 本当にユーザーに価値を提供できているのか(ただのスクラムごっこ(※3)の成果物となってはいないか)?
  • チームは、リズムにのって開発を行っているか?
  • 日々改善する努力を行えているか(ふりかえりで出た、改善策は出しただけになっていないか)?
  • など、ただ、スクラムのプロセスにそっているといったことにはなっていないだろうか。

    スクラムを実践する前によく考えていたのは、「1度でいいからスクラムで開発しているチームに参加することができれば、自分でも出来る気がする。」という思い。

    そんな時は、社外のスクラム勉強会にぜひ同じチームのメンバーと参加してほしい。
    そして、できれば1日でスクラム体験が出来るワークショップが良い。

  • 実際に、スプリントを回していくとはどういうことなのか?
  • プロダクトオーナーにデモするプロダクトがないときのバツの悪さ
  • 荒ぶるプロダクトオーナーにどう対処するのか?
  • スプリントを重ねるごとに、その日即席で出来たチームがすすんでお互いを助け合いタスクをこなしていく感覚
  • ベロシティを上げたいと思う気持ち
  • など、たった1日だけのワークショップだけど学びは1プロジェクトを終えたぐらいの学びがある。
    素振りと呼ぶには、十分な体験が得られる。

     

    Step3.

    そのワークショップで、スクラム開発での経験を持っている人たちと知り合い、悩みがあればいつでも相談出来る場を見つけること

    jonevans94 via flickr

    Thinking

    スクラムはスポーツと同じで熟練度によって楽しみも辛さも学びも異なると思う。

    だから、スクラムは学び続ける必要があるし、仮に1つのプロジェクトで上手く行ったからといって、次のプロジェクトでも上手くいくという保証はない(上手くいかなかったのならなおさら)。
    要は、いかにしてチームで早く基礎になる部分を体得して、そこからさらに楽しめるようになるか。
    一度楽しめるようになったらどんどん価値を生み出すことが出来て、どんどん楽しくなっていくと思う。

     

     躓いてしまった自分へ

    この先長く続くプロジェクトを一人で生き残るのは結構きついと思う(納品後のプレッシャーとかは、実際きつかった)。

    でも、

  • 同じチーム(もしくは組織)の人がより良い物をユーザーに届けたいという思いが感じられない
  • イベントに誘ってみても、いまいち興味を抱いてもらえなかった
  • などということももちろん、あると思う。

    そんな時は、思い切って社外の勉強会に参加している人を、自分のチームに参加してもらうことも考えてみてはどうだろうか。
    権限がないかもしれないけれど、上司だって優秀な人材を探しているし、SIerの場合、大抵職務経歴書をみただけで、雇うかどうか決めなければいけないわけだから、自分の部下が積極的に優秀な人を連れてきてくれることは、上司にとっても嬉しいことではないだろうか。

    また、上司に頼んで派遣の方の面接に一緒に参加させてもらい、自分で直接チームに加わる派遣の方を採用するという方法はどうだろう。
    スクラムはチームの文化をすごく重要視していると思う。
    技術は教えられたとしても、考え方や感じ方が異なる人とチームを組むことはすごく難しい。

    であれば、面接に一緒に参加させてもらい、自らチームのメンバーとなる同じ文化の人を採用してみるのも手段の一つだと思う。

    これで、7年前の自分が一歩踏み出せるかは、甚だ疑問だけれど。

    ※1 ここでの失敗は、スクラムのプロセスにのっとった開発すらできなかった
    ※2 アジャイルサムライの第3章「みんなをバスに乗せる」に因んで
    ※3 チームが自発的に改善に取り組んでおらず、”時間が来たから”、”支持されたから”スクラムを行っている状態をスクラムごっこと言ってみました。