人気ブログランキング | 話題のタグを見る

self memo

『基礎から学ぶチーム開発の成功法則』を読んで

著者の渡辺龍司さん経由で献本してもらい、『基礎から学ぶチーム開発の成功法則』を読んでみた。
『基礎から学ぶチーム開発の成功法則』を読んで_a0039958_2226222.jpg


結論から言うと、この本は自分的に大ヒットだった。以下に当てはまる人達にもぜひ読んでほしい。
・エンジニア出身ではないプロマネやディレクター
・プロマネに話が通じなくて困ってるエンジニア
・これからチーム開発を始める新人エンジニア
・私と一緒にアジャイル開発導入を進めてみて何かしっくり来なかった人全て

"はじめに"の中で、以下のような記述がある。
本書の内容は、「スクラムを使おう!」「アジャイルは素晴らしいので即導入だ!」といった趣旨ではありません。スクラムマスターやアジャイル開発で実績を積んでいる読者が対象ではなく、スクラムを導入してみたけどうまくいかなくて、チーム開発手法にはアレルギー的な反応を示すなど、チーム開発導入の前段階で躓いているチームメンバーに対して、まずは基礎部分をしっかり固めましょう!と考えて、本書を執筆しています。
私自身、「スクラムを使おう!」「アジャイルは素晴らしいので即導入だ!」的なスタンスで何度も導入にチャレンジしてきており、その中ではうまくいったケースもあれば、うまくいかなかったケースも多々ある。
うまくいかなかった時のふりかえりでは、以下のProblemがよく上がっていた。
・アジャイル開発のマインド、スクラムの知識不足

そのProblemに対して、以下のようなTryを実施していた。
・最初にアジャイル開発の歴史やマインド、プラクティスに関する勉強会の実施
・実際にアジャイル開発を体験できるようなワークショップの開催

このようなアプローチは、チーム開発経験豊富かつアジャイル開発未経験なエンジニアには正しいアプローチだったと考えている。しかしながら、チーム開発の経験が浅いエンジニアや非エンジニアに対しては必ずしも正しいアプローチでは無かったのかもしれない。この本を読んで、その事に気づいた。

私自身、(試)守破離という考えを好んでおり、まずはスクラムのプラクティスを自分なりに試し、その後に厳密な"守"のフェーズを経れば、自ずとアジャイル開発に対する理解が深まると考えていた。私自身、そのようなステップで理解を深めてきたからだ。
けれどもそれでうまくいっていたのは、事前にうまくいかなかったチーム開発の経験があったからこそだろう。チーム開発の経験が浅いエンジニアは、そもそも今取り組もうとしているアジャイル開発手法との比較対象が無いので、何が利点なのかなどがしっくりきていなかったのではないだろうか。

チーム開発の経験が浅いエンジニアや非エンジニアにはまずこの本を読んでもらい、いきなりアジャイル開発を導入するのではなく、まずはこの本に書いてあるような基礎的なチーム開発から始め、ある程度経験を積んだ後に必要があればアジャイル開発の本格導入に進んでいくべきだった。小規模のプロジェクトであれば、この本に書いてある内容だけで十分かもしれない。

そんな事を考えながらFacebookで色々とつぶやいていたら、営業職の同僚や、昨年まで出向していたベトナム開発拠点のマネージャー等複数の人が興味持って買ってくれたようだ。まさに嬉しい限りであり、今後の社内の変化が楽しみでもある。

それらつぶやきを以下に転載してみる。
今振り返ってみても、大変学びの多い本だった。
このような機会を頂いた、著者の渡辺龍司さん、編集の丸山弘詩さんには大変感謝している。


# by aratafuji | 2017-01-10 19:27 | レポート

エンジニアを目指す学生に伝えた7つのこと

この記事はMonstar Lab, Inc. Advent Calendar 2016 の5日目の記事です。
前々日は @noboru_i さんの 地方でリモートワークするに必要なもの - Qiita
早速の二連投、ありがとうございます!


先日、島根大学 総合理工学部数理・情報システム学科の学生向けに、アジャイルソフトウェア開発の流れについて講義する機会を頂いた。
県内IT人材を育成する『システム創成プロジェクトII』11月5日開始

その講義に先立って、エンジニアを目指す学生に意識してほしい7つのことを説明したのだが、俺なかなか良い事言ったな感があったので、それについて書いてみる。
老害乙って思った人はそっ閉じしてほしい。

1.言葉に出そう

やりたい事、叶えたい事があったら、事ある毎に言葉に出そう!そうすると実現する可能性が高くなるというお話し。

唐突だが、私はパリス・ヒルトンが昔から大好きだ。あの美貌、いつまでも変わることのないスタイル、自由奔放な生き方、その上しっかりお金も稼いでる、最高だ。私は事ある毎に「パリス・ヒルトンが好き好き」と言い続けた。そしたら会えた。その時の写真がこれだ。
エンジニアを目指す学生に伝えた7つのこと_a0039958_16194029.jpg
私のおでこのテカリ具合はスルーしてほしい。

言霊とか、そういった事を言いたいわけではない。当時の私はポータルサイト運営会社に所属しており、デビューアルバムのプロモーションのために来日したパリス・ヒルトンのインタビューのお誘いが所属会社に来た。その際に、そういえばパリス・ヒルトン好き好き言ってたエンジニアがいたなってことになって、部署も職種も全く違うエンジニアの私がパリス・ヒルトンへインタビューし、インタビュー後に2ショット写真も取ることができた。私がパリス・ヒルトン好き好き言ってなかったら、会えなかっただろう。

それ以来、私は自分がやりたい事を事ある毎に、しつこく言い続けているようにしている。ここ2,3年は、アジャイル開発!オフショア開発!東南アジア!って至る所で言い続けてたら、フィリピンのスタートアップやベトナムの開発会社でアジャイル開発の導入を支援する事もできた。

やりたい事があるなら、周りがうんざりするぐらい言い続けると良い。

2.行動しよう

私の直近1年ぐらいの行動を書き出してみる。

■2015年 10月〜11月
  • フィリピン(フォートボニファシオ)のスタートアップへのアジャイル開発導入。
■2015年 11月〜12月
  • フィリピン(バギオ)での短期語学留学。
■2016年 2月〜8月
  • ベトナム(ダナン)の開発拠点へのアジャイル開発導入、技術サポート。

これらの行動によって得られた経験は以下の通り。
  • 海外に住んで働いた経験
  • 家族と離れて暮らした経験
  • 多国籍(フィリピン、インドネシア、韓国、ベトナム、日本)チームと英語でコミュニケーションを取りながら働いた経験
  • 語学留学の経験
  • 英語のワークショップに参加したり、プレゼンした経験

クネビンフレームワークという、課題や状況を分類する方法がある。

エンジニアを目指す学生に伝えた7つのこと_a0039958_174081.jpg
このフレームワークの分類の一つである"カオス"な状況は、状況を正しく理解することが難しく、明確なプロセスも無い。その状況においてはただただ行動するしかないと定義されている。まさに現在の世界はカオスだ。複雑に絡み合った状況を正しく理解し、確実性の高いプロセスに則って人生設計することは難しい。

この状況においては、ただただ行動し続けるしかないと考えている。

3.アウトプットしよう

自分の考えや経験をまとめたら、積極的にアウトプットしていくと世界が広がるよという話し。

1.前職の社内勉強会でベトナムとのオフショア開発にアジャイル開発を導入してみた成果を発表

2.せっかく作った頑張ってスライド作ったので、Slideshareにスライドをアップロード。

3.15,000View超え!スライド見てくれた方々から連絡もらって、楽天テックトークやオフショア大学のイベントで登壇

4.アジャイル×オフショアはニーズありそうだなと思ったので、アジャイル系イベントの公募に応募

5.Regional SCRUM GATHERING Tokyo 2015の公募に採択され登壇

6.Agile Japan 2015の公募に採択され登壇

7.Regional SCRUM GATHERING Tokyo 2016の公募に採択され登壇

8.Regional SCRUM GATHERING Tokyo 2017の公募で不採択…

9.そのプロポーザルを見てくれた方から声かけて頂き、POStudy スクラム冬の陣2017 登壇予定←イマココ

アウトプットする際に。何か間違ったことを言ったり書いたりして笑われるのは嫌だからちゃんと勉強する。また、アウトプットすると良くも悪くも必ずフィードバックが得られる。そのフィードバックは本当に貴重だ。ちょっとだけ勇気出してアウトプットしてみると、これらの点から必ず成長できると確信している。

4.HRT重要

ご存知の方も多いと思うが、『Team Geek』という本に書かれている、チームで働くために必要な考え方の三本柱だ。
エンジニアを目指す学生に伝えた7つのこと_a0039958_20240855.jpg
三本柱とは以下の三つの価値だ。それぞれの単語の頭文字を取ってHRT(ハート)と呼んでいる。
H:Humility(謙虚)
R:Respect(尊敬)
T:Trust(信頼)

特に私のようなおっさんが若い人と一緒にチームを組む時や、国や文化をまたいでチームを組む時に重要な価値になる。正直言うと、HRT持っていない人と一緒に働くのは苦痛でしかない。また優秀な人ほどHRTを持ち合わせている傾向にあると考えている。チームで開発する時はHRTを大切にしよう。

5.一番の下手くそでいよう

これは『情熱プログラマー』という本に出てくる、成長の仕方の心得みたいなものだ。

エンジニアを目指す学生に伝えた7つのこと_a0039958_23115427.jpg
私は今まで10回ほど転職を繰り返して今に至るが、転職の度に自分が一番下手くそになる環境を選択してきた。一番の下手くそは辛い。優秀な同僚たち以上に日々努力し、勉強し、時間を費やさないととてもじゃないけどついていけない。そんな事を数カ月から数年ぐらい続けてふと気がつくと、あれ、普通にやれてる!って思う瞬間がやってくる。思いっきり環境に依存して自分の力を引き上げてもらっているわけだ。

私も今年で41歳、いい加減人を引き上げる側に回れと思われそうだけど、やっぱり自分も成長を続けたい。今後も意識的に自分が一番ヘタクソな環境に身を置き続けたい。

6.自己組織化しよう

"自己組織化"、この言葉が一番好きかもしれない。

ビジョンやゴールが共有されているチームにおいて、誰から指示されることも無く、ゴールを達成するためには今自分が何をすべきかを自らの頭で考え、自律的に動けるような人の事を自己組織化された人だと考えている。

自己組織化された人達が集まったチームで働くことは本当に楽しい。

以前、数千個のノベルティグッズセットを作らなければいけないことがあった。20人ぐらいで部屋に集まり、特に誰が仕切るわけでもなく机を一列に並べ、各種グッズが詰まったダンボールを机の上に置き、メンバーが一列に並んでテーブルに沿って歩きながら手にかけたトートバッグに各種グッズを詰め込んでいくお買い物スタイルでセット作りが始まった。そのうちすぐに、1回で1セットは効率悪いなと考えた人が5個ぐらいトートバッグを腕にかけて歩くようになった。五本指をうまく使ってトートバッグを開いておき、スムーズにグッズをバッグ内に入れる手法が編み出されるとすぐに皆がそれを模倣した。1ラインって待ち時間が多いよねって事を誰かが言い、迅速にテーブルの反対側にもう1ラインが生成された。その後は完成したトートバッグの中身を確認して梱包する者、グッズのダンボールを補給する者、不要になったダンボールを畳んでまとめる者、まとめたダンボールをまとめて捨てに行く者、誰も指示する者などいなくても、自らが今何をすべきかを考え、行動し、あっという間に数千セットを作ることができた。

まさにチームでのソフトウェア開発を、こんな感じでやりたい。難易度が違うことはもちろんわかってるけど、あの状況の再現を常に目指している。

7.検査と適応を繰り返そう

スクラムガイドに記載されているスクラムの理論の三本柱のうちの二つがこれにあたる。
※あとの一つは透明性

ここでは特にスクラムにおける検査と適応については触れないが、常にプロセスやプロダクトの状態を検査し、必要に応じて改善策を適応していこうという事だ。思いついた時に不定期に検査するのは良くない。毎日の終りや週末、月末、四半期末、年末などタイムボックス)決め、今の状態を検査する。対象は何でも良い。定期的に検査して必要に応じて別のやり方を適応してみる。そしてまたその結果を検査する。要は思考停止しないということだ。

ちょうど年末だし、自分も今年の行動を検査し、来年の計画を立てたいと思う。

まとめ

最後に改めて7つを並べてみる。
  1. 言葉に出そう
  2. 行動しよう
  3. アウトプットしよう
  4. HRT重要
  5. 一番の下手くそでいよう
  6. 自己組織化しよう
  7. 検査と適応を繰り返そう

他人に伝えたい事というより、自分自身が忘れちゃいけない事のリストだな。定期的に見直していきたい。

次は10日目の @takachan さん!

# by aratafuji | 2016-12-05 00:00 | つぶやき

Guideline for retrospective & sprint planning @SlideShare

I've summarized in the slide of the past three times article.


# by aratafuji | 2015-11-06 14:16 | English

Definition of Done & Acceptance Criteria

I will write about the difference between Definition of Done and Acceptance Criteria.
These difference may look a bit confusing.

Definition of Done

  • "Done" means differently by person.
  • Make sure everyone is on the same page.
  • This is a definition common to a project.
  • Improve “Definition of Done” in the Retrospective.
Definition of Done & Acceptance Criteria_a0039958_10282530.png
Quotations from "Essential Scrum"

Acceptance Criteria

  • “Acceptance Criteria” is a criteria for PO to accept if PBI is "done" or not.
  • Each PBI has its own “Acceptance Criteria”.
  • Make “Acceptance Criteria” in the Sprint Planning.
  • Write “Acceptance Criteria” on PBI.(Post-it)

Example

An example of PBI
As an internet banking customer
  • I want to see a rolling balance for my everyday accounts
  • so that I know the balance of my account after each transaction is applied
  • An example of acceptance criteria
The rolling balance is displayed
  • The rolling balance is calculated for each transaction
  • The balance is displayed for every transaction for the full period of time transactions are available
  • The balance is not displayed if a filter has been applied
http://nomad8.com/acceptance_criteria/
---
Today is the last day In the Philippines.
# by aratafuji | 2015-11-06 10:42 | English

Guideline for Sprint Planning @Philippines

I wrote about retrospective in the previous entry.

I will write an article about Sprint Planning MTG this time.
Please see below for the details.
---

Sprint Planning

Overview

  • Most HARD ceremony(event).
  • Answer two topics
    • What PBIs can be done in this Sprint?
    • How will be the chosen PBIs get done?

What PBIs can be done this Sprint?

  • Pick up PBIs from PBL from the top of the list.
    • PBL should be ordered by priority, which PO decide.
    • Keep picking up PBI as long as your team can make a commitment.
  • Commitment is important.
    • If you break your promise, …

How will be the chosen PBIs get done?

  • Make a Sprint Backlog.
    • Sprint Backlog consists of chosen PBIs and Tasks.
    • Break down PBI into small tasks.
    • Task has Summary and Estimated time.
    • Estimated time for a task should be less than 6 hours

How to

  1. Determine development capacity in this sprint.
  2. Proposal of sprint goal from PO.
    • Ex.
      • Finish ten PBIs.
      • Release push notification.
  3. Pick up a PBI from PBL from the top of the list.

    • It's the highest priority of the PBL.
  4. PO explains PBI and developers ask questions to make an estimation for it.
  5. Break down PBI into small tasks.

  6. Estimate tasks using hour(s).
  7. Repeat the process of estimation until developers feel that they can't commit to finish PBIs anymore or the capacity gets full.
  8. Review sprint goal.
  9. Make a commitment.

---
Next time I plan to write about Definition of Done and Acceptance Criteria.
# by aratafuji | 2015-11-05 15:17 | English