Quantcast
Channel: Ryuzee.com
Viewing all 197 articles
Browse latest View live

テストエンジニアの面接の際にするとよい20の質問

$
0
0

みなさんこんにちは。@ryuzeeです。

DZoneという海外のサイトで “The 20 Best Software Tester Interview Questions” (テストエンジニアの採用面接の際にすると良い20個の質問)がまとまっていたので紹介します。

ここにあがっている質問を必ずすべきかという話ではありませんし、完全な網羅性があるわけでもありません(カバレッジの話やブラックボックス・ホワイトボックスの話のような基礎的な質問も入っていないです)。 一方で、ある程度の規模になった組織においては、採用面接の質を向上させるために自分たちの組織で共通の質問集のようなものを用意しておくのはベストプラクティスの1つと言えます。 もちろん一度作ったらそれで終わりではなく、新しい質問を追加したり、いろいろな候補者から期待と違う回答があった場合には質問自体を見直すといったことも必要になってきます。

以下参考和訳です。

1. 曖昧さをどううまく扱うか?

テストケースが常に明快なものだとは限らない。QAエンジニアが自分の判断にもとづいて行動しないといけないこともある。曖昧さがあっても平気に感じられる必要がある。

2. 現在は手作業でおこなっているテストを自動化することについてどう考えているか?

テストケースの自動化は多くの利点をもたらす。自動化によって時間を短縮できるし、人為的ミスも減らせる。QAエンジニアは自動化の価値を認識すべきだ。

3. テスト実施中に、症状と原因をどう区別しているか説明してください

QAプロセスにおいて、テストはしばしば失敗する。しかしなぜ失敗するのだろうか?それを明らかにするには手ぎわが必要だ。よいQAエンジニアは開発者に対して単にテストが失敗したと伝えるのではなく正確な理由も伝えられる。

4. あなたが出した結果に納得しない開発者に対して対抗することを厭わないか?

ときには失敗を報告することがデリケートなプロセスになる場合もある。たぶん開発者は要求に正確に合致しているわけではないコードに対してすごく時間をかけたのだろう。QAエンジニアは自分たちが正しいと知っていることについては、それを守ることができないといけない。

5. 時間を節約するために手を抜いてもよいと思うか?

正しい答えはノーだ。全部のテストを実行しないといけない。頻繁にそういう推定を繰り返していると道を転がり落ちるような問題につながる。

6. ソフトウェア開発ライフサイクルとアジャイル開発手法について説明できるか?

QAエンジニアはそれらの役割やそれがエコシステムのどこにあうのか理解していないといけない。

7. ドキュメントに関する見解を説明してください。多ければ良いと思うか。それはなぜか、もしくはそうでないとしたらなぜか?

これはちょっとトリッキーな質問だ。ドキュメントが多ければ常に良いとは限らないからだ。実際には有害になるかもしれない。ドキュメントは完全でありつつも出来るかぎり効率的でないといけない。多すぎるドキュメントは大事な詳細を漏らしてしまう可能性がある。

8. 新しい製品について学習する際にどのように進めるか?

これはもしかしたらQAエンジニアになるのに一番の難所かもしれない。QAエンジニアはテスト対象となる複雑なソフトウェアに関する学習を厭わない必要があるし、我慢強くそれをする必要がある。多くの質問ができるよう準備すべきだ。

9. 他の人とどうやってうまく働くか

多くのQAチームには、色々なところから来た多くのチームメンバーがいる。QAエンジニアはさまざまなバックグラウンドを持つ人や言語の習熟レベルが異なる人たちとコミュニケーションするのが平気でないといけない。

10. 自分のことを完璧主義者だと思うか?

よいQAエンジニアは完璧主義者だ。QAエンジニアの仕事は自分たちがテストした全てのソフトウェアが品質基準に合致するかそれを超えるようにすることであり、いいかげんな仕事はその先のトラブルにつながるのだ。

11. プレッシャーのかかる環境や締め切りがある中でどううまく働くか?

テスト工程は通常ソフトウェア開発ライフサイクルの最後にくる。テストはボトルネックと見られることもある。したがって厳しい締め切りやプレッシャーのもとでも成果を出せることが重要だ。

12. コーナーケースを作るためのどんな経験があるか?

この質問は、テスターが明瞭でないテストケースシナリオと明確なテストケースシナリオを切り分けられるかどうかを判別する手助けになる。

13. 現在の技術トレンドにどうやって追随するか?

業界のニュースやトレンドについていっていることは大事だ。それはチームが技術の進化やベストプラクティスの変化に追随するためだ。この質問はどれだけ自分たちの仕事が好きかということも示す。

14. どんなことでモチベーションがあがるか?

この質問に対しては、考えられる回答が複数ある。その回答が良い回答なのか悪い回答なのかについては、会社の文化によるところが大きい。たとえば、製品チーム内でのチームワークが重要であれば、内部での競争がモチベーションになる候補者が最善とはいえないだろう。

15. キャリアの最終的なゴールは何か?

候補者が翌年や3年後にどうなっていることを望んでいるか知ることは重要だ。もし自分が提供できないキャリアパスを候補者が望んでいる場合、思ったよりも早くまたインタビューをすることになるかもしれない。

16. 友達があなたのことを一言で表すとしたら何というか?

この質問によって、伝統的な仕事にフォーカスを置いた質問からは得られないような候補者のユニークな個性を引き出すこともある。

17. なぜテスティングを身に着けたいと思ったのか?

どうやって候補者が現在のキャリアを作ってきたかを知ることは、候補者の大志やゴールに関して多くのことを明らかにしてくれる。

18. どうやったらこの会社がもっとうまくできると思うか?

この質問によって候補者がインタビュー前にどれだけ事前に調査をしてきたかを明らかにしてくれる。そしてその場で考える能力も分かる。

19. どうして一緒に働きたいと思ったのか?

この質問は、候補者がこの機会にどれだけワクワクしていて情熱を持っているかを知る最良の方法だ。

20. どんなテスト手法に馴染みがあるか?お気に入りの手法があるか?

複数の異なる種類のテストに馴染みのある多才な人を採用したり、喜んで新しい手法を学習するような人を見つけたりすることが重要だ。


デブサミ2016夏でDevOpsお悩み相談室というセッションをやりました

$
0
0

みなさんこんにちは。@ryuzeeです。

7月29日に御茶ノ水のソラシティでおこなわれたDevelopers Summit 2016 Summer (デブサミ2016夏)で、「DevOpsお悩み相談室〜カイゼンの文化を組織に根付かせるために」というタイトルのパネルディスカッションを実施しました。当日は多くの方にお越しいただきありがとうございました。当日の資料は以下になります。


事前にアンケートに回答いただき、全部で10個のトークテーマを用意していたのですが、時間の関係で後半の3個は扱えませんでした。それをお待ち頂いていた方もいるかもしれないので、この場で私見を説明しておきたいと思います。

Q. スクラムの定着方法

開発プロセスをカイゼンするためにスクラムを導入しましたが、みんななんとなくこなすだけになっており、カンバンや朝会も形骸化しています。今のやり方はうまく回っているようにも見えますがが、みんなにもっと真剣にスクラムに取り組まないといけないと思ってもらうにはどうしたら良いですか? 現状では、スクラムマスターという役割の人がおらず、チーム内にスクラムについて深く理解している人はいません。またマネージャーはいますが、他の業務に追われてスクラムがうまく機能するような取り組みは行えていません。この状況でうまくいかせるには、一度、開発者の中から誰かをスクラムマスターにする、といった取り組みが必要でしょうか?

なかなか難しい質問です。まず最初に明らかにした方がいいのは、「スクラムを導入したのはなぜか?」という点ではないかと思います(はっきりしていなければもう一度やってみてください)。 もともと何か組織として解決すべき課題があったので、それの対応のためにスクラムを導入したはずです。 改めてそれを明文化して、解決したかったことを優先順位順に並べ、いまどこまで解決しているのかを確認してみるとよいでしょう。 そこで上位の課題が解決しているのであれば、それが「スクラムなのか?」はチームにとっては最重要ではありません。 言い換えれば、問題を解決するのと、ソリューションを導入するのを同一視しないことです。

うまくいっているように見えている状況で、さらにそれに真剣に取り組んで貰うのも大変です。 チームに対して「なぜもっと真剣に取り組まないといけないか」を説明できないと、ただの掛け声で終わったり、自律性のない押し付けになったりしてしまいます。 したがって、以下のようなことを全員で議論してみるとよいと思います。インセプションデッキのようなフレームワークを使うのもアリでしょう。

  • 自分たちはなんのためにここにいるのか
  • 自分たちはビジネス側の期待に応えられているか
  • どうなれば、もっと期待に応えられそうか

なお、スクラムマスターのいないスクラムはスクラムとは成り得ない(スクラムの要件を満たしていない)ので、「スクラムをやりたい」のであれば、まずスクラムマスターをアサインしてください。 ただしアサインしたからといって問題が解決するわけではありません。 またマネージャーが忙しすぎて協力してくれないのだとすると、マネージャーにとっての「スクラム」はその程度の優先順位でしかないという可能性もあります。 マネージャーがどんな期待値を持っているか確認するとともに、必要な権限を委譲してもらうといった対応も必要ですし、もしくは、そもそもマネージャー自体のタスクを見える化して本当に大事なところに力を貸せるように改善する必要もあるでしょう。

最後にテクニカルな話でいうと、カンバンや朝会が形骸化する理由は簡単です。以下に一例を列挙しておきましょう。

  • タスクの単位が大きすぎて昨日も今日も同じことをやっている
  • タスクの内容が自分以外よくわからない感じになっている
  • 専門性の違いによって、人がもっているタスクを取りようがなくなってしまっている
  • 計画どおりに進めないと詰められるような文化がある等の理由で、悪いニュースを伝えにくい
  • そもそも仕事がたくさんありすぎて人を助ける余裕がない
  • したがって人が話している内容に関心を持てない
  • したがってボードがメンテされていなくても気にならない


Q. カンバンを習慣化するには?

カンバンをやり始めてもなかなか習慣化できないのですが、何かよいアイデアがあれば紹介してください。いまは以下のような課題があります。

  • 付箋化しにくいタスクがある
  • 更新してくれない(レビュー後にDoneに移動してくれない)
  • リモートワークとの共存が難しい

前の質問とよく似た質問です。まずやらないといけないのは、カンバンに何を期待するのか、チームのメンバーそれぞれに何を期待するのかを明らかにすることでしょう。 個々の悩みについてみていきましょう。

まず付箋化しにくいタスクですが、実はこういうタスクは本当はあまり無いはずです。一度、自分たちのタスクにはどのような種類のものがあるのか洗い出してみるとよいでしょう。 よくあるのは、機能の追加要求・不具合の修正・技術調査・メンテナンス・障害対応・報告・レビューなどです。チームで付箋の色の使い方や書き方の凡例を共有する(ボードのそばに貼っておく)のもベストプラクティスの1つです。

また、あわせて自分たちの仕事のワークフローの認識が正しいのかどうかも確認するようにします。 質問のケースでは、レビュー後にDoneに移動されない、とあります。 レビューが必要ということはプロセスのワークフローの中にレビューというステップが存在することになるので、分かりやすくするのであれば、「レビュー待ち」「レビュー中」「レビュー完了」といったカラムをカンバンに作ります(前のステップとの繋がりなので、前者2つを使ったり、後者2つを使ったりします)。次に、それぞれのステップに同時仕掛り数(WIP)の制限をかけます。 レビューしたあとに、次のステップに付箋を移していない場合は、仕掛りに項目がたまるので、そもそもそれ以上のレビューを行うことはできません。 WIPの制限がある項目がボトルネックの場合、その直前にタスクがたまるので、カンバンが流れていないことが見えるようになります。問題が見えるようになれば手を打たざるを得なくなります。

そして随時更新してもらうためにも、デイリーミーティングとの組み合わせは有効です。毎日WIPの制限に引っかかっている箇所がないか、何日も同じステップに滞留しているタスクがないかをチェックして対応を促すとよいでしょう。僕が支援しているあるチームでは、特定ステップでの滞留があれば毎日ドットシールを1つずつ貼っていき、何日間滞留しているか確認するとともに、それはいつまでに誰がどのように解決していくのかを確認するようにしています。

最後にリモートワークについてです。 全員同席でできないことはリモートでもできないので、チームのプロセスがしっかりしないうちに毎日リモートにしてしまうと非常に大変です。 したがって初期のうちはオンサイトの回数を増やしておいた方がよいでしょう。 なお、ツールに関してはオンライン上で使えるカンバンもあります(Trelloなど)ので、そういうものを活用しつつ、上述のとおりデイリーミーティングをSkypeやハングアウト、チャットと組み合わせて実施します。

 

Q. サービスの部分障害の把握方法

サーバーの設定を変更したことで、Webシステムの一部の機能が使えなくなってしまう問題が起こったことがあります。たとえばWebページ自体は閲覧できても、フォームやアクセス解析など一部のみで問題が起こると発見が遅れてしまいます。どのようにすれば機能単位の機能停止を早く発見できるでしょうか?

最後はテクニカルな質問です。大規模なアプリケーションになってくると、リリース後に一部が動作していないといったことは発生する可能性があります。 これを防ぐためには、リリース後にスモークテストを自動で実行することです。 また重要機能であれば、常時動作の監視が必要なこともあります。その時は監視システム上に、そのような機能の動作を確認するテストを登録し、一定間隔で実行するようにします。 スモークテスト自体は、それらのテストのサブセットになることもあります。 ほかにも、アプリケーションのログなどをリアルタイムで集約し、エラーログをチャットに通知するといった対応も必要になってくるでしょう。

チームパフォーマンスモデルとは?

$
0
0

みなさんこんにちは。@ryuzeeです。

人が集まっただけでは機能するチームにならない、というのはみなさんご存知のとおりです。 そしてチームの形成過程をあわらすモデルの1つとして有名なものに「タックマンモデル」があります(こちらを参照)。

今日はもう1つ別のモデルとしてDrexlerとSibbetが提唱している「チームパフォーマンスモデル」を紹介します。

タックマンモデルでは、チームの形成過程は形成期・混乱期・統一期・機能期・解散期の5段階(初期は4段階)で構成されていましたが、このチームパフォーマンスモデルでは、以下の7段階で構成されます。

  • オリエンテーション
  • 信頼の醸成
  • ゴールの明確化
  • コミットメント
  • 実行
  • ハイパフォーマンス
  • リニューアル

これらのステージは前半上から下に向います(形成段階)が、この段階では、徐々に制約を感じるようになっていきます。一方で後半に下から上にあがっていく(持続段階)につれて自由を感じるようになります。 それぞれのステージについて見ていきましょう。

オリエンテーション

この段階では、チームがなぜそこに集められたのか、どんなことが期待されているのかを明らかにします。 なぜ集められたのかが分からなければ、チームは不安になってしまい参加意識を欠くことになります。 アジャイル開発でよく使われるインセプションデッキでも「われわれはなぜここにいるのか?」という項目を最初に明らかにしています。 この段階でメンバーが恐怖感をもっている場合は、先に進む前に十分な説明が必要になります。

信頼の醸成

メンバーはお互いの仕事に依存関係を持つことになるため、お互いの理解が必要です。 そこで「あなたは誰?」という質問にもあるように、それぞれの強み(や弱み)、それぞれの考え方、お互いに対する期待値などを明らかにします。 ここでメンバーが警戒心を持っていたり、見せかけの振る舞いをしているような場合は、改善が必要になります。

ゴールの明確化

一番最初のステージでなぜ集められたのかは分かりましたが、ここではもう一段踏み込んで、ゴールや成果物を合意するとともに、実際に自分たちが何をやるのか明確化します。 ゴールを達成するための選択肢が複数あるのであれば、それぞれについて議論を行います。 議論において人の意見に文句ばかり言う人が出る場合もありますし、そもそもゴールに関心を持たない人がいる場合もあります。 その場合は前のフェーズでの信頼の醸成が不足していることを指します。

コミットメント

次に、どうやってやるかを決定します。ここでは選択肢の決定、個人の役割や責務の決定、必要なサポートの手配やリソースの割り当てなどを行います。 ここでも個人の役割や責務を持ちたがらないような人が出てくる可能性もあります。 また意思決定の責任を取りたがらず単に人の意見に従う人がでてくることもあります。 その場合は手前のステージに戻ります。

実行

コミットメントが終われば実行フェーズに入ります。具体的に誰が何をいつどこで行うのか、スケジュールや戦略やプロセスを決定して進めていきます。 実行段階で混乱が起こったり衝突が起こる場合は、戦略やプロセスの合意が不足していることを指します。 またプロセスが不明瞭だと規律に従わない行動が増える可能性もあります。

ハイパフォーマンス

うまく機能するチームになっている段階。チームに与えられた時間の中でどれだけ多くをこのステージで過ごすかが成果の最大化への鍵になります。 信頼関係と明確なゴールやプロセスをもとにチームが自律的に物事を進められる段階になっているので、必ずしも多くの管理は必要ありません。 一方でチームがフロー状態に入るので、たくさんの成果を出したくて負荷があがることは考えられます。

リニューアル

時間がたったり状況が変化したりすることでチームが置かれた状況は変化します。 このとき、このまま続けるかどうかを判断し、状況によっては、また最初のステージに立ち戻って自分たちがなぜそこにいるのかを確認しないといけないこともあります。 もしくは、ハイパフォーマンスなチームを維持することは大事なことではあるものの、チームを解散しないといけなくなることもあります。 このタイミングで、自分たちが達成できたことや出来なかったこと、もっとうまくできそうなこと等を洗い出して次回に反映するようにします。

雑多な所感

このモデルや、以前紹介したタックマンモデルを踏まえて考えておくと良いと思う点を列挙しておきます。

  • なぜ自分がそこにいるのかを明らかにすることは極めて重要
  • いきなり集められてお互いのことを信頼しろ、とか明日から高いパフォーマンスを出せと言われても無理
  • 当たり前の話ですが、プロジェクトをどう立ち上げるのか、チームをどう立ち上げるのかという初期の活動を軽視してしまうと後工程で大きなツケを払うことになる
  • 警戒・懐疑主義・無関心・依存といったあたりは個人の資質によるところも大きい。一方で「恐怖」によってそうせざるを得なくなっている場合もあるので、チームの外からどんな力が働いているかを明らかにする必要がある
  • インセプションデッキのようなテンプレートを用意しておくと、こういうプロセスの流れに乗りやすい。自分たち用のフレームワークを作っておいてもよいかもしれない

【資料公開】カイゼンの基本

$
0
0

みなさんこんにちは。@ryuzeeです。

2016年9月16日に行われたDevelopers Summit 関西で表題のテーマで登壇してきましたので資料を公開します。


カイゼンについては1日のトレーニングコース(バリューストリームマップ作成含む)を@haradakiroと提供していますのでご興味のある方はご連絡ください。

Azureでコマンドラインから利用料金を取得する

$
0
0

みなさんこんにちは。@ryuzeeです。

クラウドを使っていると利用料金を常時監視したり通知するのは当然の行動の1つです。 そこで、Azureの利用料金をいちいちポータルにログインしなくても見られるようにスクリプト化してみたので、やり方を紹介します。 今回は、コマンドラインツール(AzureCLI)とスクリプトの開発にはRubyを使っています。

AzureCLIを用意する

AzureCLIはNode.jsを使うので、環境設定が済んでいない場合は、nvmでもなんでもいいので用意しておきます。

それが終わったらAzureCLIをグローバルにインストールします。いろいろなパッケージをインストールするので3分ぐらいかかります。

npm install -g azure-cli

インストールが完了したら設定に入ります。

Azureにはリソースマネージャー(ARM)デプロイモデルとクラシック(ASM)デプロイモデルがありますが、現在はリソースマネージャー推奨なので、そちらに切り替えます。

azure config mode arm

データを収集して送ってよいか聞かれますので、適当にyかnを選択してください。以下のように表示されれば成功です。

info:    Executing command config mode
info:    New mode is arm
info:    config mode command OK

次にAzureにログインします。

azure login

すると以下のように表示されるので、リンクをブラウザで開きます。

info:    Executing command login
/info:    To sign in, use a web browser to open the page https://aka.ms/devicelogin. Enter the code AB12CDE34 to authenticate.

以下のようにコードを入力する欄があるので、上記の出力のコードを入力して先に進みます。認証画面を経て、最後の画面で「デバイスの Microsoft Azure Cross-platform Command Line Interface アプリケーションにサインインしました。このウィンドウは閉じてかまいません。」と表示されたらブラウザを閉じて構いません。 その時点でコマンドラインでのログインが完了しています。

Azure AD アプリケーションの作成

自前のスクリプトからの認証や権限を管理するために、Azure ADアプリケーションを作成します。 ここでパスワードを設定しますが、これは後ほど自前スクリプトで使いますので控えておいてください。

azure ad app create --name "usage_collection" \
 --home-page "http://www.ryuzee.com/" \
 --identifier-uris "http://www.ryuzee.com" \
 --password sushikuitai

実行すると以下のようなログが表示されます(値はダミーになっています。念のため)。 この中で重要なのは、AppIdの項目で、このデータも後ほど使います。

info:    Executing command ad app create
+ Creating application usage_collection
data:    AppId:                   b7b17624-5536-3888-3328-1231ba716c02
data:    ObjectId:                12ba3f8a-1222-3e5d-a77e-0699b3f2d503
data:    DisplayName:             usage_collection
data:    IdentifierUris:          0=http://www.ryuzee.com
data:    ReplyUrls:
data:    AvailableToOtherTenants: False
data:    HomePage:                http://www.ryuzee.com/
info:    ad app create command OK

次にサービスプリンシパルを作成します。引数は先ほど作成したアプリケーションのAppIdを指定します。

azure ad sp create --applicationId b7b17624-5536-3888-3328-1231ba716c02

以下のように作成が完了しました。ここで表示されたObject Idはあとで使いますので控えておいてください。

info:    Executing command ad sp create
+ Creating service principal for application b6b07346-3719-4177-8618-3661ba716c02
data:    Object Id:               aa0f5bc5-e5d8-4e30-a9cb-999a49343bb1
data:    Display Name:            usage_collection
data:    Service Principal Names:
data:                             b6b07346-3719-4177-8618-3661ba716c02
data:                             http://www.ryuzee.com
info:    ad sp create command OK

ここで対象とするサブスクリプションを確認します。

azure account list

以下のように表示されます。ここで表示されるIdはサブスクリプションIDで後で使います。

data:    Name                    Id                                    Current  State  
data:    ----------------------  ------------------------------------  -------  -------
data:    従量課金                1abc8ad2-2cc5-9876-a0ee-0f76be829d3a  true    Enabled
(以下略。複数のサブスクリプションがある場合は複数表示されます)

サービスプリンシパルに権限を割り当てます。最初のobjectIdには先ほどサービスプリンシパルの作成で表示された値を指定します。 第2引数では読み取り権限を示すReaderを設定し、最後の引数に、サブスクリプションのIDを指定します。 複数のサブスクリプションから利用データを取得する場合は、以下の作業を繰り返し実施してください。

azure role assignment create \
  --objectId aa0f5bc5-e5d8-4e30-a9cb-999a49343bb1 \
  -o Reader \
 -c /subscriptions/1abc8ad2-2cc5-9876-a0ee-0f76be829d3a/

以下のように結果が表示されます。

info:    Executing command role assignment create
+ Finding role with specified name                                             
/data:    RoleAssignmentId     : /subscriptions/1abc8ad2-2cc5-9876-a0ee-0f76be829d3a/providers/Microsoft.Authorization/roleAssignments/69738901-2cb7-46a5-8179-c81431ca6046
data:    RoleDefinitionName   : Reader
data:    RoleDefinitionId     : acdd72a7-9876-55ef-bd42-f606fba81ae7
data:    Scope                : /subscriptions/1abc8ad2-2cc5-9876-a0ee-0f76be829d3a
data:    Display Name         : usage_collection
data:    SignInName           : undefined
data:    ObjectId             : aa0f5bc3-e5d8-4e30-a7cb-977a55555bb1
data:    ObjectType           : ServicePrincipal
data:    
+
info:    role assignment create command OK

次にテナント情報を取得します。以下を実行してください。

azure accout show

画面に以下が出力されます。ここで出力されるTenant IDを控えておいてください。

info:    Executing command account show
data:    Name                        : 従量課金
data:    ID                          : 7bdf8ad2-2cc5-3986-a0ee-0f76be829d3a
data:    State                       : Enabled
data:    Tenant ID                   : 80ed711a-71af-9123-82fa-57d0464c288e
data:    Is Default                  : false
data:    Environment                 : AzureCloud
data:    Has Certificate             : No
data:    Has Access Token            : Yes
data:    User name                   : hoge@example.com

コードによるデータ取得

この時点で揃っているデータは以下の通りです。

  • Application ID
  • パスワード
  • Tenant ID
  • Subscription ID

これらを使って使用量と料金表を取得します。処理の流れは次のようになります。

  1. Azureにログインして、APIのヘッダーに埋め込むTokenを取得する
  2. 使用量をAzure Resource Usage APIを使って取得する
  3. 料金表をAzure RateCard APIを使って取得する
  4. 2で取得した使用量と3で取得した料金表をマージする

1. Azureにログインして、APIのヘッダーに埋め込むTokenを取得

2や3でAPIを投げるためにはリクエストヘッダーにTokenを埋める必要があるので、まずそれを取得します。 取得のためには、https://login.microsoftonline.com/テナントID/oauth2/token?api-version=1.0に対してデータをPOSTします(POSTの内容は下記のpayloadの箇所を参照)。 ここでPOSTの値に、上記で取得したApplication IDをセットします。 正常に動作すれば、JSON形式でデータが返ってくるので、access_tokenの値を取り出します。この値を以降で使います。

def self.api_token(application_id, client_secret, tenant_id)
  url = "https://login.microsoftonline.com/#{tenant_id}/oauth2/token?api-version=1.0"
  payload = {
    'grant_type' => 'client_credentials',
    'client_id' => application_id,
    'client_secret' => client_secret,
    'resource' => "https://management.azure.com/"
  }
  headers = {
    "Content-Type" => "application/x-www-form-urlencoded"
  }
  RestClient.post(url, payload, headers){ |response, request, result, &block|
    case response.code
    when 200
      json = JSON.parse(response)
      token = json["access_token"]
      token
    else
      false
    end
  }
end

2. 使用量をAzure Resource Usage APIを使って取得

ここで使う値は、先ほど取得したTokenとSubscription IDです。下記の例では取得範囲を当月1日から前日までにしていますが適宜変更してください。 ここではヘッダーに先ほど取得したTokenを埋めつつ、https://management.azure.com/subscriptions/サブスクリプションID/providers/Microsoft.Commerce/UsageAggregates?api-version=2015-06-01-preview&reportedStartTime=取得開始日時&reportedEndTime=取得終了日時&aggreagationGranularity=データ粒度&showDetails=falseというURLにGETリクエストを投げて指定期間の指定したサブスクリプションのJSON形式の使用量データを取得します。

def self.usages(token, subscription_id)
  now = DateTime.now.new_offset(0)
  start_time =  DateTime.new(now.year, now.month, 1, 0, 0, 0)
  end_time =  DateTime.new(now.year, now.month, now.day, 0, 0, 0)

  granularity = "Monthly"

  url = "https://management.azure.com/subscriptions/#{subscription_id}/providers/Microsoft.Commerce/UsageAggregates?api-version=2015-06-01-preview&reportedStartTime=#{url_encode(start_time.to_s)}&reportedEndTime=#{url_encode(end_time.to_s)}&aggreagationGranularity=#{granularity}&showDetails=false"
  headers = {
    "Content-type" => "application/json",
    "Authorization" => "Bearer #{token}"
  }

  results = []
  RestClient.get(url, headers){ |response, request, result, &block|
    case response.code
    when 200
      json = JSON.parse(response)
      return json["value"]
    else
      false
    end
  }
end

3. 料金表をAzure RateCard APIを使って取得

そして料金表をJSON形式で取得します。ここでいままで取得したデータの他にOfferDurableIdという値が必要になります。この値は通常の従量課金形式のライセンスの場合は、MS-AZR-0003Pとなります。詳細はAzureのポータルから自分のサブスクリプションを表示して確認します。 送信先は、https://management.azure.com/subscriptions/サブスクリプションID/providers/Microsoft.Commerce/RateCard?api-version=2015-06-01-preview&$filter=OfferDurableId eq 'OfferDurableIdの値' and Currency eq 'JPY' and Locale eq 'ja-JP' and RegionInfo eq 'JP'となります。最後の方のfilterというパラメータでどんなライセンス形式の価格を、どんな通貨、どんな言語で取得するかを指定できます。ここでは通貨と言語は日本に固定しています。

def self.rate_meters(token, subscription_id, offer_durable_id)
  url = "https://management.azure.com/subscriptions/#{subscription_id}/providers/Microsoft.Commerce/RateCard?api-version=2015-06-01-preview&$filter=OfferDurableId eq '#{offer_durable_id}' and Currency eq 'JPY' and Locale eq 'ja-JP' and RegionInfo eq 'JP'"
  headers = {
    "Content-type" => "application/json",
    "Authorization" => "Bearer #{token}"
  }
  RestClient.get(url, headers){ |response, request, result, &block|
    case response.code
    when 200
      json = JSON.parse(response)
      json["Meters"]
    else
      false
    end
  }
end

4. 値をマージする

あとは2と3で取得したデータをマージすればOKです。2で取得した使用量データには、適用する価格を示すMeterIdという項目があるので、これをキーにしてRateCard APIの結果から単価を取得します。また、使用量データにはquantityという数量を示すデータが入っているので、単価と数量を掛け合わせることで金額が算出できます。

あとは適当にテーブル形式で出力したり、もっとデータをまとめたりと好きにすれば良いでしょう。

ここで解説したコードの完全版は、https://github.com/ryuzee/azure_charge_exampleにおいてありますので適宜ご覧ください。サンプルを実行すると以下のような出力を取得できます。

プロダクトバックログ項目はReadyなものだけスプリントに投入するべきという話

$
0
0

みなさんこんにちは。@ryuzeeです。

プロダクトバックログはスクラムにおける生命線の1つです。 プロダクトバックログが良くないとプロダクトの価値がでなかったり、そもそもスクラムチームとして安定したデリバリーを行えません。

プロダクトバックログでよく起こる問題

プロダクトバックログを管理する上でみなさんがよく知っているのは、並び替えをする、という点ですが、これだけではまったく不十分です。

単に並び替えだけをしたプロダクトバックログで、スプリントを始めてしまうと以下のようなことが起こります。

  • 選択したバックログ項目の中身に対してプロダクトオーナーと開発チームの理解が違ってしまう
  • そのためスプリントを開始した後に頻繁にプロダクトオーナーと会話をする必要が出てきてしまい、場合によっては本来の要求が別のものであることが判明する
  • もしくは色々会話をしていたら、当初の想定以上に規模が大きいことが分かり、スプリント中で完成しない
  • 会話や決定までの待ち時間を惜しんで複数のプロダクトバックログ項目に同時に着手してしまう
  • 結果として、複数のプロダクトバックログ項目で同じことが起こり、同時に頑張って進めたものの結果として何一つ完成しない
  • そもそもプロダクトオーナーが会話する時間を取れなかったり、開発チームが勝手に想像して実装を進めた結果、プロダクトオーナーの受け入れ確認で拒否される
  • これらの結果、各スプリントの実績(ベロシティ)のバラつきが多く、今後を予測できない

このような問題を防ぐためには、スプリントに投入するプロダクトバックログ項目はReady(準備完了)になっているものだけを投入しないといけません。

Readyとはなんだろう?

さきほど見てきた問題を流れの観点から見ると、「要求 → 開発」の流れにおいて、逆流が起こっていることを意味します。 このような逆流が起こってしまうと、完成までに余計に長い時間がかかったり、混乱したりします。これらを避ける必要があります。

プロダクトバックログの責任者はプロダクトオーナーですが、開発チームにプロダクトバックログ項目を引き渡す(開発を始める)にあたっては、

  • 開発チームとして必要な情報が揃っている
  • 開発チームとして受け入れ可能な品質

のプロダクトバックログ項目を渡さないといけないのです。 そしてプロダクトバックログ項目がそのような状態になっていることをReady(準備完了)といいます。

なお、プロダクトオーナーはプロダクトオーナーの並べ替えの責任や最終的な意思決定の責任はありますが、プロダクトバックログを全て自分で用意しないといけない責任があるわけではありません(できるのならもちろん良い)。プロダクトバックログを作ったりメンテナンスする作業は開発チームも協力して行えば良いでしょう。

Readyの具体的な状態

それでは、開発チームとして必要な情報が揃っている、受け入れ可能な品質のプロダクトバックログ項目とはどのようなものでしょうか。

まずプロダクトバックログ全体としては、以下が必要です。

  • 各項目がプロダクトオーナーによって並べ替えられている(言うまでもないですが)
  • 各項目は開発チームによって見積もられている(並びが下の方はどちらでも構いません)
  • 各項目はプロダクトに関係がある

またプロダクトバックログの項目としては、以下のような項目が挙げられます。

  • 上位の項目については、具体的である(要望ではなく要求でないといけない)
  • 上位の項目については、達成可能である(技術的に不可能なものではないことが明確)
  • 上位の項目については、何をもって完成したのかを判断する基準が明確である。すなわち受け入れ基準やデモのシナリオ、求められる結果が明らかである(これがあればスプリント冒頭で受け入れテストを自動化できる)
  • 上位の項目は開発チームが1スプリント内で完成できるサイズになっている(すなわち継続的に見積りの見直しを行って、過去のベロシティから1スプリントに入らないことが明確であれば、事前にプロダクトバックログ項目を分割しておく必要がある)

これらを満たすプロダクトバックログを維持するためには、バックロググルーミング(リファインメント)のイベントなどを使って、継続的にプロダクトバックログをメンテナンスし続けるようにしてください。

なお、これらすべてを100%完璧な状態にしようとはしないでください。 目的は開発チームとして安定的な成果を出すためであり、開発チームが十分と思える度合いになればそれで良いのです。したがってガイドラインとして扱うのが望ましいと言えます。

Readyの定義を見える化しておく

ここまでの話は、慣れているスクラムチームであればやっている話ですが、最初のうちはReadyの定義を作ってチェックするようにしておいても良いでしょう。 いくつか、ネット上で公開されているものを抜粋して紹介します。

  • プロダクトバックログ項目が必要な場所に書かれている
  • 受け入れ基準が定義されている
  • ほかのプロダクトバックログ項目との依存関係が明らかになっている
  • プロダクトバックログ項目は開発チームによって見積もられている
  • 開発するのに必要な上流や外部から提供される部品が手に入っている
  • 必要な場合は、非機能要件(性能やセキュリティ)が定義されている
  • デモの手順がわかる
  • 開発を進める上で大きな疑問は残っていない
  • なぜそのプロダクトバックログ項目が必要なのかの価値が明確化されている

これがすべてでもなく絶対というわけではないので、ふりかえりの中で出てきた知見を反映していくのがお勧めです。 もちろん言わなくても守れるような定義はリストから外していってください。

それでは。

【新刊発売のお知らせ】ジョイ・インク 役職も部署もない全員主役のマネジメント

$
0
0

みなさんこんにちは。@ryuzeeです。

このたび、2016年12月20日に、『ジョイ・インク 役職も部署もない全員主役のマネジメント』という書籍が発売になりますのでお知らせします。


  • 出版社: 翔泳社 (2016/12/20)
  • リチャード・シェリダン(著) / 原田騎郎、安井力、吉羽龍太郎、永瀬美穂、川口恭伸(翻訳)
  • 価格: 1,944円
  • 言語: 日本語
  • ISBN-10: 4798148784
  • ISBN-13: 978-4798148786
詳細を見る
本書は、アメリカのソフトウェア会社「Menlo Innovations(メンロー・イノベーションズ)」という会社の創業者リチャード・シェリダンによる書籍の翻訳となります。

メンローは経営方針として「働く喜びの追求」を掲げており、米国の中でもっとも幸せな職場の1つと言われている企業です。

本書の中では、彼がなにを考えてこのような会社をつくったのか、日々どのような手法をつかって仕事を進めているのか、どのように人を採用し評価するのか、などメンローの考え方を余すところなく伝えています。(彼らはオープンであることにもこだわりを持っていて、実際にオフィスを訪問するツアーなども用意されています)

彼自身はエクストリームプログラミング(XP)を筆頭としたアジャイル開発の考え方の影響を受けており、実際の日々のプラクティスもそこから着想を得たものが多数あります。ただそれはソフトウェアを作っている企業にとどまらず、そのほかのさまざまな企業に適用できるものです。下部の写真やYoutubeは実際のオフィスを撮影したものです。これをみているだけでも活気と喜びのあふれる職場であることが見て取れるのではないかと思います。

【目次】

  • イントロダクション
  • 1章 僕が喜び(Joy)にたどり着くまで
  • 2章 スペースとノイズ
  • 3章 自由に学ぶ
  • 4章 会話・儀式・道具
  • 5章 インタビュー・採用・立ち上げ
  • 6章 観察のもつ力
  • 7章 恐怖と戦い、変化を抱擁する
  • 8章 ボスではなくリーダーを育てる
  • 9章 カオスを終わらせ、曖昧さをなくす
  • 10章 厳密、規律、品質
  • 11章 持続可能性と柔軟性
  • 12章 スケーラビリティ
  • 13章 説明責任と結果
  • 14章 アライメントー向きを揃える
  • 15章 問題
  • 結論 喜びのなかへ
  • エピローグ ひらめき
ぜひお手にとって読んでいただければと思います。予約はこちらから!!

プロダクトバックログとスプリントバックログの見積もり

$
0
0

みなさんこんにちは。@ryuzeeです。

以前お客様先でスクラムのトレーニングを実施した際に、プロダクトバックログとスプリントバックログの見積もりについて質問をいただきました。 見積りについてはもっとも質問をいただく項目の1つでもあるので、ここでスクラムにおける見積もりについて書いておくことにします。

プロダクトバックログの見積り

まずはプロダクトバックログの見積りについて考えてみましょう。

なぜプロダクトバックログ項目を見積もるのか?

なぜプロダクトバックログを見積もるかといえば以下の理由です。

  • そのプロダクトの全体を把握する。全体のサイズが分からないと現在の進捗が把握できません。もちろん全てのプロダクトバックログ項目を絶対に作るかといえばそうではなく、途中で項目が追加されたり削除されたりしますが、それでも全体の概要を把握しようとすることには意味があります
  • 同じ理由で、スプリント単位でどれくらい完了できるかを把握するためにも見積もりが必要です
  • 全体の見積もりとスプリント単位での完了の実績がわかれば、指定した期日までにどれくらいが完了するのか、もしくは全てを完了するのにどれくらいの時間がかかるか推定できます。この推定はスプリントを繰り返せば繰り返すほど正確になっていきます
  • これらはすなわち事実に基づいて計画を更新できるようになることを意味します
  • また見積もりがあれば、ビジネス価値と比較して規模が大きすぎるものは作らない判断をする、もしくはビジネス価値と比較して規模が小さいものは優先順位を上げるといった対応も可能になります。すなわち限られたリソースや期間の中で最大限の成果を出すための計画の精度があがります
  • なお、計画はたてることに意味があって、そのとおりにすすめることに意味があるとは限りません。したがって見積もりにおいて過度な精度は不要で、おおよそのサイズがわかるだけでさまざまな判断の材料になります

プロダクトバックログ項目の見積りのタイミング

これを踏まえるとおのずと見積もるタイミングは明らかです。見積りは以下のタイミングで実施するのがおすすめです。

  • プロジェクトの初期で最初のプロダクトバックログの洗い出しがおおよそ終わったとき。ここでの見積りは全体の把握に使います
  • 最初のスプリントを始める前。最初のスプリントの開始前に少なくともそのスプリントで着手すべきプロダクトバックログの項目が準備完了になっている必要があります(でないと大きな手戻りが発生するリスクが高くなります)。準備完了になったプロダクトバックログの上位の項目は見積りをし直します。準備完了の状態であれば見積りの精度が向上するためです
  • 最初の数回のスプリントが終わった時。最初のスプリントは成果がでないことも多いので、何回かスプリントをこなしたあとで、残っているプロダクトバックログの項目を見積り直します。その時点で開発チームは実際の開発を行った経験があるため、プロジェクト初期にくらべると見積りの精度は向上します
  • その後の定期的な見直し。もちろんプロダクトバックログの項目は随時追加されるので、追加された項目の優先順位が高い場合は適宜見積りを行います。またプロダクトバックログを分割したりもするので、分割した項目の見積りや、全体の見直しを行います

言い換えるとプロジェクトの期間中、未着手のプロダクトバックログ項目については、継続的に見積り直しが必要ということになります。 プロダクトバックログが更新されるづける成果物であるということは見積りも更新され続けるということなのです。 なお、完成したプロダクトバックログ項目を見積りし直すことに意味はありません。

プロダクトバックログ項目の見積りには何を使うか

スクラム自体ではどんな方法を使って見積もるかは定義していません。すなわち見積りの方法の選択肢としては以下のいずれも考えられます。

  • 物理単位付きの絶対見積り。例えば人日や人月、万円など
  • ポイントを使った相対見積り。よく使う方法にプランニングポーカーがある。プランニングポーカーでは、1・2・3・5・8・13などのフィボナッチ数列のカードを使って見積もる
  • Tシャツサイズ。プランニングポーカーを簡易にして、S(小さい)、M(中くらい)、L(大きい)、XL(かなり大きい)などのサイズに分類する
  • 見積もらない。全てのプロダクトバックログ項目をだいたい同じ大きさに分割し、そもそもプロダクトバックログ項目の個数をさまざまな計算に使う

このうち絶対見積りについては、外したときのインパクトが大きいこと、それを理由にして見積りが紛糾しやすいこと、数字がついているとその数字が外部に約束として扱われてしまうリスクが高くなることから避けておくのが無難です。また見積もらずに全ての項目を同じサイズに分割するのも経験が要求されるので難易度は高いでしょう。 ということで、プランニングポーカーによる相対見積りかTシャツサイズ見積りが初期のチームにはおすすめです。

スプリントバックログの見積り

次にスプリントバックログの見積りについて見てみましょう。

なぜスプリントバックログ項目を見積もるのか

スプリントバックログを見積もる理由は以下の通りです。

  • スプリント計画会議ではそのスプリントで着手するプロダクトバックログ項目を選択して、それらをスプリントバックログに分割しますが、それぞれの作業項目を見積もることで、本当にそのスプリントで選択したプロダクトバックログ項目が完了しそうなのかを予測できるようになります
  • すなわち作業項目の合計時間が、開発チームがスプリントで使える時間を超過していた場合、たとえプロダクトバックログの見積りについては過去の結果から達成できそうであっても、現実的には難しい可能性があるということが分かります。このときはプロダクトオーナーと開発チームが相談して、なんらかのプロダクトバックログ項目を諦める判断をすることになります
  • 毎日残り作業に必要な時間を追跡していくことで、スプリント終了までに予定した項目が終わりそうかが分かります。すなわちバーンダウンチャートがかけるようになります
  • つまり、もしスプリントの途中でこのままいくと終わらないであろうことが判明した場合にすぐにプロダクトオーナーと調整が可能になります
  • また見積りをしておくことで、タスクに想定外の時間がかかっている場合に、開発チームとして速やかな対処(スウォーミングなど)も可能になります

スプリントバックログの見積りのタイミング

スプリントバックログは、選択したプロダクトバックログ項目を完了させるための作業のリストなので、スプリント計画会議で見積りを行います。 全てのプロダクトバックログ項目を事前に作業に分解する必要など決してありません。必要になったタイミングで必要な分の計画を行えば十分です。 なぜなら、スプリントバックログの見積りは、スプリント単体の計画と追跡のためだけに使うからです。 またスプリント中には新たにタスクに気づいたり、タスクの実施によって他のタスクの難易度が変わることもあります。従って必要に応じて日々見積りを更新します。

スプリントバックログ項目の見積りには何を使うか

スクラムガイドで定義されているのは、残作業が追跡可能であるようにすべきという点だけです。 一般的には、ここでの見積りには時間を使うことが多いでしょう。 それはスプリント計画会議でキャパシティとの比較が容易になる点や、バーンダウンチャートによる追跡が容易になる点によるものです。 時間を使う場合、1タスクあたりの最大サイズは1日くらいの規模が望ましいでしょう。 そうすれば日々のデイリースクラムにおいて、昨日も今日も同じタスクに取り組んでいる場合異常が起こっている、と容易に理解できるためです。 もちろん成熟したチームであれば、タスクをなるべく同じサイズに揃えて、個数で管理するといったことも可能です。

それでは


2016年ふりかえり

$
0
0

みなさんこんにちは。@ryuzeeです。

2016年も残すところあと僅かなのでふりかえりしておきたいと思います。 今年のトピックはいくつかあるのですが、大きいところとして、フリーランスでの活動書籍5冊、そして法人設立が挙げられます。 充実した1年だったと思うので、来年も同じように成果をあげられるように邁進していく予定です。 仕事を依頼してくださった多くのお客様、関係者の皆さまに厚く御礼申し上げます。

タイムライン

1月前半人生に悩んでフラフラしていた
1月後半フリーランスで活動していくことを決めた
2月中旬Developers Summit 2016でベストスピーカー賞第1位を取った。過去に2位と3位だったことはあるのでやっと念願が叶った
2月後半技術評論社から『サーバ/インフラエンジニア養成読本 DevOps編』が発売。1章を執筆した
2月後半クラスメソッドさんのインタビューを受けた
3月中旬人間ドックを受診したら全ての数値が劇的に改善していた。寿司パワーすごい
3月後半オライリーから『カンバン仕事術 ―チームではじめる見える化と改善』が発売
4月上旬LeanPubにて『アジャイルコーチの道具箱 – 見える化の実例集』を発売。仲間で寄ってたかって週末の数日だけで下訳を終わらせるというスピード感
5月後半Microsoft主催のde:codeでDevOps関連のパネルディスカッションに登壇。すごく人が多くてMicrosoftの変わりっぷりに皆が注目しているのを実感した
6月上旬マイナビから『Amazon Web Services企業導入ガイドブック』が発売。AWS時代に書き始めて世に出すまでに1年以上かかった
6月上旬AWS Summit Tokyo 2016でパネルディスカッションのモデレーターとして登壇。モデレーターは大変なのでできればもう避けたい
7月上旬Microsoft MVP for Azureになった
7月上旬CodeZineで『クラウドネイティブ時代のデベロッパー生存戦略』という企画を始めた。初回は元同僚の片山さん
7月上旬リクルートテクノロジーズさん主催のイベントで『Infrastructure as Codeと組織文化』というテーマで登壇した
7月後半Developers Summit 夏でパネルディスカッションのモデレーターとして登壇。モデレーターは大変(以下略
8月全般翻訳作業に明け暮れる
9月上旬仕事で生まれてはじめて新潟に行った。日本酒飲めないのが残念
9月上旬『クラウドネイティブ時代のデベロッパー生存戦略』の第2回でAzureのプロの浅見さんに話を聞いた
9月中旬Developers Summit 関西でカイゼンの話をした
9月後半平日ほとんど全部稼働が入っていたので持続性に課題を感じ始める
10月上旬『クラウドネイティブ時代のデベロッパー生存戦略』の第3回でMSを電撃退職した砂金さんに話を聞いた
10月全般足を痛めて辛い目にあった。健康重要
11月上旬札幌でDevelopers Festaに登壇。2012年に登壇したのがキッカケでAWSで仕事することになったので懐かしい
12月上旬原田さんと永瀬さんとで法人を設立しました詳しくはこちら
12月下旬翔泳社より『ジョイ・インク 役職も部署もない全員主役のマネジメント』が発売

ブログ投稿

ブログ投稿は全部で38記事。はてなブックマークの被ブックマーク数は7265でした。2015年は29記事でブックマーク数が5100なので上昇基調です。とはいえまだ少ないので来年はもう少し数を増やしたいところです。

スクラムトレーニング開催のお知らせ(2017年2月22日)

$
0
0

みなさんこんにちは。@ryuzeeです。

このたび2017年2月22日(水)に品川にてスクラムの一般向けトレーニングを開催することになりましたのでご案内です。 講師は原田騎郎・永瀬美穂・吉羽龍太郎の3名です。多くのアジャイル関連書籍の翻訳や執筆を手がけている講師陣によるワークショップやセッションで、スクラムの基本を一日で体験し学ぶことができます。

ぜひご参加ください。詳細は以下をご覧ください。

本トレーニングの概要

トレーニング名スクラムトレーニング(SCRUM BOOT CAMP)
主催株式会社アトラクタ
開催日時2017年2月22日(水) 10:00-18:00
開催場所品川シーズンテラスカンファレンス

東京港区港南1丁目2番70 品川シーズンテラス3階
JR品川駅港南口(東口)より徒歩6分
京浜急行電鉄品川駅高輪口より徒歩9分
アクセス
講師原田騎郎、永瀬美穂、吉羽龍太郎

Harada
Nagase
Yoshiba
定員40名(最小催行人数:20人)
参加費用クレジットカード払い:54,000円
請求書払い:60,000円
(消費税込み)
その他・研修資料は電子媒体にて提供いたします
・受講終了後2週間メールでの質問を受け付けます
・決済終了後の返金は受け付けておりません。ご自身が参加できない場合代理の方にご参加いただいて構いません
お申込み

 

Scrum(スクラム)は竹内弘高氏、野中郁二郎氏が1986年にハーバードビジネスレビュー誌にて発表した「New New ProductDevelopment Game」を元にしてジェフ・サザーランド氏らが考案したアジャイル開発手法の1つで、近年アジャイルな開発の手法として日本国内においても急速に採用事例が増えています。

一方でコーチや経験者の指導のないままに表面的なプラクティスを導入し、結果としてあまりうまくいかないというケースも良く聞くようになりました。 本トレーニングではこれからスクラムを導入して開発を行うことを検討されている方もしくはトレーニングを受けないままにスクラムチームに参加されている方を対象に、スクラムの基礎トレーニングを提供いたします。

アジャイル開発は本を読んだだけで理解し実践できるものではありません。 本トレーニングでは講義に加えて、実際にさまざまなワークショップに取り組んでいただきながらスクラムに必要な要素を体験し習得いただくことを目指しています。

本トレーニングのゴール

  • アジャイル開発の本質的な価値を理解する
  • アジャイル開発とウォーターフォールの違いを理解する
  • スクラムで定義されている活動や成果物を理解する
  • アジャイル開発で必要とされる自己組織化やマインドセットを理解する

対象者

  • スクラムによるアジャイルな開発に興味を持っており導入の検討をされている方もしくは既にスクラムチームに参加されている方(管理職、マネージャ、開発者、デザイナーなど)で、体系的なトレーニングの受講をされたことが無い方
  • アジャイル開発やスクラムの基本を学びたい方

タイムテーブル

  • 10:00-10:15 前説
  • 10:15-11:00 アジャイル開発の基礎
  • 11:00-12:00 ワークショップ
  • 12:00-12:30 スクラム全体の流れ
  • 12:30-13:30 昼食休憩
  • 13:30-14:30 スクラムのロールや会議体
  • 14:30-15:30 プロダクトバックログ演習
  • 15:30-16:30 スプリント計画演習
  • 16:30-17:15 スクラムその他のトピック
  • 17:15-18:00 ふりかえり、質疑応答

費用

お支払い方法金額
クレジットカード払い54,000円(消費税込み)
請求書払い60,000円(消費税込み)
お申込み

【資料公開】スクラムの落とし穴

$
0
0

みなさんこんにちは。@ryuzeeです。

2017年1月12日〜13日にかけてスクラムのイベントであるRegional Scrum Gathering Tokyo 2017が開催されました。 その中でスクラムでよく起こる問題やその原因・対策に関するセッションを行いましたので資料を公開いたします。

アジャイルなやり方でプロジェクトをやろうとしたときの「あるある」な失敗をまとめたものとなっていますので、いま何となく上手く行っていない気がする方はセルフチェックとしてもご利用いただけるのではないかと思います。内容に関するご質問やご要望がありましたら是非Twitterなどで気軽にお寄せください。

 

なお、思い当たることがたくさんある方のために、2017年2月22日に一般参加可能なスクラムトレーニングを品川で開催しますので、ご興味のある方は是非ご参加ください。

【新刊発売のお知らせ】変革の軌跡 〜世界で戦える会社に変わるアジャイル・DevOps導入の原則

$
0
0

みなさんこんにちは。@ryuzeeです。

このたび、2017年1月25日に、『変革の軌跡【世界で戦える会社に変わる”アジャイル・DevOps”導入の原則】』という書籍が発売になりましたのでお知らせします。

本書はトラディショナルが大企業がどのようにして、マーケットの変化や顧客のニーズにすばやく対応して製品をデリバリーできるように変革したか、を事例を使って説明しています。 事例は、著者2人が、米ヒューレット・パッカードに在籍していたときに、LaserJet(企業向けのプリンタや複合機)の事業におけるソフトウェアやファームウェア開発の改革を行ったときのものです。


  • 出版社: 技術評論社 (2017/1/25)
  • Gary Gruver、Tommy Mouser著 / 吉羽 龍太郎、原田騎郎(翻訳)
  • 価格: 2,138円
  • 言語: 日本語
  • ISBN-10: 4774186635
  • ISBN-13: 978-4774186634
詳細を見る
このような大企業では、単にアジャイル開発やDevOpsのツールやテクニックをそれぞれの開発チームに導入するだけではうまくいきません。 というよりも、そもそもアジャイル開発の導入でさえも多額のコストと時間がかかる上に、導入前には成果すら予測もできません。

彼らはそのようなアプローチではなく、管理職として変革の活動をリードするとともに、いかに複数のチームが協力し合えるようにするか、から始めています。 つまり個々のチームの中のプロセスを変えるのではなく、チーム同士の関わり合い方を変えて、本番に近い環境ですべての変更を統合するサイクルを作り、そのサイクルを短縮して頻度をあげる、ということに重点をおいています。

また本書では繰り返し「ビジネス目標の設定」の重要性を説いています。アジャイルやDevOpsの「導入」(という単語もどうなのかという話もありますが)自体は目的にはならず、あくまで手段です。 ビジネス目標抜きで進めてしまうと、いまやるべきこと、あとでもよいこと、やらなくてもよいことの区別がつかなくなります。そして時間をかけた割には成果がでないということにもなりがちです。

そして目標の設定以外に、企業内に「継続的改善のプロセス」を作ることの重要性を説いています。

本書は現場のエンジニアの方向けというよりは、経営者やマネージャー、リーダーの方などを対象にしています。 また自社のITのあり方を変えていきたいと考えるユーザー企業の方にもお勧めです。

なお、巻末に日本の大手企業の事例を日本語版特典として掲載しています。

【目次】

  • 第1章 変革を理解する
  • 第2章 アジャイルチームを拡大する上での課題
  • 第3章 ビジネス目標と重要な最初の一歩
  • 第4章 エンタープライズレベルの継続的改善
  • 第5章 アジャイルなエンタープライズ計画
  • 第6章 DevOps展開におけるビジネス目標
  • 第7章 メインブランチで開発を進める文化を作る
  • 第8章 組織にしっかりした土台を作る
  • 第9章 継続的デリバリー
  • 第10章 デプロイパイプラインの設計
  • 第11章 安定性の向上
  • 第12章 さぁ始めよう

ぜひお手にとって読んでいただければと思います。ご購入はこちらから!!

また、本書の発売を記念してマイクロソフトの牛尾さんに、バリューストリームマッピングの解説記事を寄稿いただきました。非常に参考になると思いますのであわせてご参照ください。


AWSとAzureのサービス名対比表

$
0
0

みなさんこんにちは。@ryuzeeです。

AWSとAzureを両方使っていると名前で混乱したり、サービス名が思い出せなかったりするのでだいたいこんな感じというレベルでリストにしてみました。 最近の傾向を見ているとAWSはエンタープライズ向けの機能(移行支援や管理系の機能)を多く出している一方でAzureはモバイル系とかCognitiveサービス系の充実が進んでいる感じだと思います。

サービスAWSAzure
仮想マシンAmazon Elastic Compute Cloud(EC2)Virtual Machines
ストレージAmazon Elastic Block Store(EBS)Disk Storage
ロードバランサーElastic LoadBalancing(ELB)Load Balancer
データベースAmazon Relational Database Service(RDS)SQL Database
NoSQLDynamoDBDocumentDB
CDNAmazon CloudFrontContent Delivery Network
オブジェクトストレージAmazon Simple Storage Service(S3)Blob Storage
キャッシュAmazon ElastiCacheAzure Redis Cache
データウェアハウスAmazon RedshiftSQL Data Warehouse
仮想ネットワークAmazon Virtual Private Cloud (VPC)Virtual Network
専用線接続AWS Direct ConnectExpressRoute
キューAmazon Simple Queue Service(SQS)Queue Storage / Service Bus Queue
権限管理AWS Identity and Access Management(IAM)Azure Active Directory
DNSAmazon Route 53Azure DNS
コンテナ管理EC2 Container ServiceAzure Container Service
VPSLightsail-----
PaaSElastic BeanstalkWeb Apps / App Service / Service Fabric
サーバレスコンピューティングLambdaAzure Functions
バッチ処理BatchBatch
バージョン管理CodeCommitVisual Studio Team Services
ビルドCodeBuildVisual Studio Team Services
デプロイ自動化CodeDeployVisual Studio Team Services
ビルドパイプラインCodePipelineVisual Studio Team Services
IoTAWS IoTAzure IoT Suite
ゲームプラットフォームGameLift-----
ネットワーク共有ディスクEFSAzure File Storage
長期バックアップGlacierAzure Backup
障害復旧 (DRaaS)------Site Recovery
ハイブリッドクラウドストレージStorage GatewayStor Simple
メトリクス取得CloudWatchApplication Insights / Operational Insights / OMS / Azure Monitor
プロビジョニングの自動化CloudFormationAzure ARM Template
API操作の監査ログCloudTrailActivity Log
リソース構成の追跡ConfigAzure Resource Managerに統合
アプリ管理の自動化OpsWorksService Fabric
リソースカタログの作成Service Catalog----- (ARM Templateで代用)
ベストプラクティス検証Trusted AdvisorApplication Insights
エンタープライズ向け統合管理Managed Services------
移行用情報の収集Application Discovery Service------
モバイルMobile HubMobile Apps
モバイルの認証CognitoMobile Apps
モバイル端末のテストDevice Farm------
アプリケーション分析Mobile AnalyticsMobile Engagement
ターゲットプッシュ通知PinpointNotification Hubs
分散アプリ用ワークフローStep Functions------
ワークフローエンジンSWF------
ワークフロー自動化------Logic Apps
APIゲートウェイと管理API GatewayAPI Management
動画変換Elastic TranscoderMedia Services
自動セキュリティ評価InspectorAzure Security Center
証明書管理Certificate Manager------
マネージドActive DirectoryDirectory ServiceAzure Active Directory
アプリケーションファイヤーウォールWAF & ShieldAzure Application Gateway / Barracuda WAF for Azure (サードパーティなど)
コンプライアンスレポートCompliance ReportsMicrosoft Trust Center
通知SNSNotification Hubs
メール送信SESSendGrid (サードパーティ)
データベース移行AWS Database Migration Service(DMS)------
既存アプリの単純移行Server Migration------
大容量データ移行SnowballAzure Import/Export
サーバレスクエリ実行AthenaData Lake Analytics / SQL DWH Polybase
HadoopEMRHDInsight
検索サービスCloudSearchAzure Search
ElasticSearchElasticsearch ServiceElastic Stack (サードパーティ)
リアルタイムデータ処理KinesisStream Analytics
データワークフローData Pipeline------
BIツールQuickSightPower BI
ドキュメント共有WorkDocsOffice 365
メールシステムWorkMailOffice 365
仮想デスクトップWorkSpacesXenApp Express (サードパーティ)
アプリケーションストリーミングAppStream 2.0------
会話型インターフェイス構築Lex------
スピーチPollyBing Speech API
深層学習による画像認識RekognitionFace API
機械学習Machine LearningMachine Learning
運用自動化------Azure Automation
データ統合------Azure Data Factory
Bot作成------Azure Bot Service
テキスト翻訳------Translator Text API
音声翻訳------Translator Speech API

【資料公開】Effective Retrospective (効果的なふりかえり)

$
0
0

みなさんこんにちは。@ryuzeeです。

2017年3月18日におこなわれたProductivity Engineering − Forkwell Meetup #4の登壇資料『Effective Retrospective』の資料を公開します。

登壇の時間が20分ですので基本的な内容になっていますが、これからふりかえりを始める方やなんとなくいまのやり方がうまくいかないと思う方には役にたつと思います。 もっと詳細が知りたい場合は、アジャイルレトロスペクティブズを一読することをお勧めします。2007年の本ですがまったく陳腐化していないので参考になると思います。


なにかご質問があればTwitterなどでお知らせください。

スクラムマスターロールプレイ

$
0
0

みなさんこんにちは。@ryuzeeです。

スクラムに関するコンサルティングやトレーニングなどで仮想のケースを用意してロールプレイをしてみると効果的です。

以下で、たまに自分が使っている資料を公開します。ロールプレイですので確実な回答があるわけではありません。また全てをやることに意味があるわけでもありません。チームで少し時間をとって議論してみると得られることがあるのではないかと思います。


なにかご質問があればTwitterなどでお知らせください。

なお、弊社では、2017年5月30日に一般向けのスクラムトレーニング(SCRUM BOOT CAMP)を開催いたします。スクラムに関する知識を体系的に学びたい方はぜひご検討ください。


スクラムで依存関係を取り扱う方法

$
0
0

みなさんこんにちは。@ryuzeeです。

コーチングをしていてよく聞かれる質問の1つに、チーム間をまたがる依存関係の管理をどうするか、というものがあります。

これの回答となる素晴らしい記事がTHE QUIET AGILISTというサイトで公開されていました。 著者のRick Cusolitoさんに記事の翻訳と公開を快諾いただきましたので、以下で紹介いたします。 元記事はこちらです。http://www.quietagilist.com/blog/2014/10/16/handling-external-dependencies-in-scrum

スクラムの依存関係を扱う3つの実績のある方法

開発チームは機能横断的(クロスファンクショナル)である。インクリメントを作成するスキルをチームとしてすべて備えている。- K. Schwaber and J. Sutherland、スクラムガイド、2013

※日本語版より抜粋し一部補完

彼らがそうでないときを除いて。

このトピックは、あなたの視点によっては皮肉かもしれませんしタイムリーかもしれません。前回の記事では、ストーリーを縦に切ることの重要性について説明しました。すべてのストーリーを動作するソフトウェアにするために持つべき最も重要な要素は、クロスファンクショナルチームです。とはいえ、そのとおりにやるのは難しいのが実情です。

スクラムのゲームのルールに従う上で、チーム間の依存関係は問題になります。

スクラムの開発チームは開発作業を担当しますが、それが大きなプロジェクトやプログラムのごく一部ということがあります。この場合、個々の開発チームは、企業にとって役立つものを作ることはできません。ビジネスに本当の価値をもたらすために、まずは他チームの作業と統合しないといけません。

スプリントごとに少なくとも1回、すべての作業を統合する必要があります。継続的統合に向かって進めていくべきですが、一方で他チームとの日常的な統合は最小限でないといけません。最初は、各チームの作業を継続的に統合することは困難だったり組織にその能力がなかったりする場合もあります。企業は、複数のチームの作業を統合するために、開発組織を変更する必要に迫られることもあります。プロダクトの開発やテストに使用する技術を変えなければならず、組織全体のエンジニアリングプラクティスを改善する必要もあります。

個々のチーム内あるいは開発者レベルで起こる変更もあります。ただ、ほとんどの企業では組織全体で多くの改善が必要です。どんなにシンプルな設計であったとしても、非常に複雑なプロダクトを作っています。最高の状況下でも毎スプリントで動作するソフトウェアを作ることは難しいですが、毎日の開発状況を知らなくては、それはもうほとんど不可能です。組織はこのような状況を見てスクラムではうまくいかないと文句を言いますが、問題に焦点を当てつつもソリューションにも焦点をあてる必要があります。今いきなりすべてのことはできませんが、適切なエンジニアリングプラクティス、いくつかの規律、そしてそこに向けてドライブをかけていくことで解決できるでしょう。

いくつかの一般的な外部依存シナリオを考えて、それらをスクラム内でどう扱うか見てみましょう。

フロントエンドの機能がインフラストラクチャの拡張機能に依存する場合

マイレポートチームは、プロダクトバックログ項目を選択して、ユーザーが指定した期間のトランザクションすべてを1画面で表示できるようにしました。現状では、複数の画面からデータをエクスポートして、Excelでデータを集計しないと見れなかったのです。プロジェクトの作業には、画面、ワークフロー、およびデータベースの変更が含まれていました。

ワークフローとデータベースは、各部門のプロダクトの多くが使っているインフラストラクチャの一部となっていました。ユーザーの要求をサポートするには、データベースから頻繁にデータを取得したり、データベースにフィールドを追加したりする必要があります。これらの拡張が完了すれば、ユーザーインターフェイスに必要なすべてのデータが一度の要求で手に入ります。残念ながら、インフラストラクチャの変更は別のチームが担当します。そのためマイレポートチームは、(a)フロントエンドの機能拡張では、デモやテストのときにインフラストラクチャの変更に依存しないように進めるか、または(b)プロダクトバックログから別の項目を選択して、インフラストラクチャーチームが一緒に作業する準備が整うまで待つか、のいずれかになります。

幸いにも、アジャイルはこのような状況のためのガイダンスを提供しています:

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 - アジャイルマニフェスト、2001

チームが答えないといけないただ1つの質問は、オプション(a)が「価値のあるソフトウェア」をもたらすかどうかということです。答えが「Yes」の場合、それは2番目の疑問につながります。それは本当に依存関係があるのか、本当にインフラストラクチャの変更が望ましいのか?という疑問です。しかし今回の例では(a)に対する答えは「No」であるため、選択肢(b)のみが実行可能な選択肢でした。

チームは、他チームがスプリントプランニングに参加していない限り、外部の依存関係を持つストーリーを開始すべきではありません。ただしインフラストラクチャチームが複数のチームのために拡張に取り組むような場合、今回の作業を優先させられるのは誰になるでしょうか?1つのソリューションは、全体的なROIを担当するエンタープライズプロダクトオーナーです。個々のプロダクトバックログを単一のエンタープライズバックログにまとめます。エンタープライズプロダクトオーナーはインフラストラクチャのプロダクトバックログに優先順位を付けて、ROIを最大化し、リスクを最小限に抑えることができます。

作業がアーキテクチャのレイヤーで分割されている場合

時には、アーキテクチャのレイヤーを越えたクロスファンクショナルチームを作れないこともあります。このような状況では、スクラムの3つの柱(透明性、検査、適応)を見失わないようにしてください。検査し、適応するために、チームは常にプロダクトバックログのどこにいるかを知る必要があります。チームはできるだけ頻繁に動作するソフトウェアをリリースする能力も必要です。

Amlarは、疑わしい銀行活動を特定するために金融取引を監視しようと考えていました。これらの機能を届けるには5つのレイヤーが必要です。第1は、銀行と他のエンティティとの間のすべての取引を収集して格納するレイヤー。第2は顧客口座情報を保持するレイヤー。第3は、金融取引の規制ガイドラインを保持するレイヤー。第4は、トランザクションと規制内容とを比較しメッセージトラフィックを作成するレイヤー。第5は、さらなる調査のためにメッセージをアラートとして表示するレイヤー。それぞれのレイヤーは、地理的に異なる場所(1つはジョージア州、1つはニューハンプシャー州、3つはマサチューセッツ州)にある別々の組織によって開発されました。それぞれのレイヤーにはそれぞれ別のプロダクトオーナーと開発チームがいました。Amlarの役員たちは進捗に満足していました。いったいどうやったのでしょうか?チームは、どのようにして、古くなった仕様で作り続けずに変化に適応しているかを確認したのでしょうか?どのようにしてインクリメントが価値あるプロダクトに統合されるか、それぞれのチームはどのように知ることがでたのでしょうか?

まず、統合レイヤーを作成します。第6のレイヤーです!統合レイヤーチームには、他の各レイヤーの代表者がいました。統合レイヤーは毎日各レイヤーからビルドを取り出し、それらを単一のビルドに統合しようとしました。次に、統合テストを開発し、最終プロダクトがリリースされたときの機能をテストしました。障害を引き起こしたレイヤーには障害を報告しました。そのチームは、それ以上の開発を進める前に、まずは問題の対応を優先しなければなりませんでした。最後に、各スプリントの終わりまでにすべてのレイヤーをインクリメントに統合しないといけないという規範が確立されました。そうでない場合は、何も完成と呼べず、何もデモできませんでした。

スクラムチームがウォーターフォールチームに依存する場合

HipaaCareは健康保険を販売しており、従来のシステムをアフォーダブルケア法やその他の規制変更に対応するために新しいシステムに置き換える必要がありました。1つのチームが、4つの顧客層のレガシーメインフレームコンポーネントを置き換えるCRMシステムの構築を担当しました。関連する申請と請求データをCRMに取り込み、顧客データを他のシステムで利用できるような共有Webサービスは別の専任チームによって開発されていました。

Webサービスチームは、SOA設計仕様からなる独自のマイルストーン駆動プロセスを使用していました。マイルストーンは、設計ドキュメント、各サービスのプロトタイプ、そして完成したプロダクトでした。このプロトタイプは、最終的なプロダクトの簡単な模造品でしたが、CRMチームのテスト環境として提供され、スプリントのあらゆる機能の検証に使用できました。しかし、サービスチームへの納入までは3ヶ月かかりました。

CRMチームはスクラムを使用し、最初の3ヶ月で3つのスプリントを完了しました。そこでは、Webサービスの仕様に基づくモックサービスを使って機能を構築しました。実際のサービスが提供された後、開発したものを実際のCRMでテストしました。

変更やコミュニケーションミスはプロダクトの複雑さと直接関係しています。スクラムがスプリントで最低一回統合を必要としているのはそのためです。そうすればスプリントレビューでデモができます。他のチームがスクラムを使用しない場合、スクラムチームは他のコンポーネントの代わりとなるものを使いながら可能な限り統合する必要があります。これらの代替品は、後での変更を最小限に抑えるために工夫して使用しないといけません。

CRMチームは、プロトタイプの準備が整うまで、新しいサービスの構造を理解して代替となるものを作っておかなければなりませんでした。彼らは、最初のスプリントでいくつかの拡張機能といくつかの新機能を選択しました。予想される変更を考慮できるように設計をリファクタリングしました。そうすることで以前に開発した機能が引き続き機能するようにしました。

このソリューションでは、完成したWebサービスを使ってCRMチームが再テストする必要がありました。設計が変更されるたびに、再テストのために代替品を変更しなければなりませんでした。しかし再作業はその機能に限定され、変更が発生した時点で設計は完了になりました。ウォーターフォールで作られた実際のサービスで、スクラムチームのシミュレーションレイヤを置き換えたということです。

結論

チームがクロスファンクショナルではなく、自己完結型ではない理由はたくさんあります。多くの大企業がスクラムを採用していますが、まだそのような構造になっていないことが多いのです。なんらかのレベルの依存関係が必要となるようなエンタープライズ全体のシステム変更もあります。しかし原因が何であれ、すべての問題を解決するようなソリューションはありません。ただ、上記の3つの例のうちの1つを使って多くの状況に対処できることは分かるでしょう。

依存関係についてどんな問題が発生しましたか?みんなが喜ぶ解決策を見つけられましたか?

【資料公開】アジャイル開発プロジェクトの始め方

$
0
0

みなさんこんにちは。@ryuzeeです。

これからアジャイル開発を始めるときには、気をつけておいた方がよいことや、実際にスクラムでスプリントを回す前にやっておいた方がよいことが色々あります。 それについて使っている資料がありますので参考までに公開しておきます。


これもやった方がいい、こういう時にはどうするの?などありましたら是非Twitterなどでお知らせいただければと思います。

スプリントでのプロダクトバックログ項目着手の方法

$
0
0

みなさんこんにちは。@ryuzeeです。

スプリント中に対象のプロダクトバックログ項目にどのように取り組んでいくか、というのは意外とよく質問を受けるので、ここで整理しておきたいと思います。 話を分かりやすくするために、スクラムボードを見ながら考えていきます。

アンチパターン1:プロダクトバックログ項目ごとに担当を決める

プロダクトバックログ単位で人をアサイン

まず最初に避けるべきなのは、プロダクトバックログの項目単位で担当を決めてしまうやり方です。スクラムでは誰かが開発チームのメンバーに対して作業を割り当てることはしませんが、割り当てているかどうかに関係なく、開発チームのメンバーが「特定のプロダクトバックログ項目にサインアップして、そこを全部担当する」というのも避けるべきです。 このやり方をした場合には、次のような問題が発生します。

  • 開発チームのメンバーは自分がサインアップしたプロダクトバックログ項目の完成ばかりを気にしてしまう
  • 難易度の高いものや未経験のものをやりたがらない、という力が働いてしまうこともある
  • すなわちチームの成果より個人の成果を重視する方向になりがち
  • 全体で見たときに、スプリント終了時点で、「すべての項目があとすこしで終わる」という状態が頻繁に発生する可能性が高い
  • スクラムでは未完成のものは、あと少しだろうがなんだろうが成果としては扱わない。すなわちその場合開発チームとしての成果が0になってしまう
  • 個人の状況に左右されやすいため、スプリント単位での成果の量(ベロシティ)が安定しなくなる
  • 従ってプロダクトオーナーからみた場合、将来の予測性が低く、計画がたてにくくなる

アンチパターン2:散発的に色々なプロダクトバックログ項目に手をつける

散発式な作業

次に避けるべきなのは、色々なプロダクトバックログ項目に散発的に取り組んでしまうやり方です。 開発チーム内にスキルセットの偏りがあって、特定の人しか特定の作業ができない、といった場合に発生しがちです。このやり方をしてしまった場合の問題点は上記のアンチパターン1と同じで、「プロダクトバックログ項目が完成しない」リスクが高いことです。

また、このようなやり方をしている場合、潜在的に以下のような問題がある可能性もあります。

  • 開発チーム内にスキルセットの偏りがあって、特定の人しか特定の作業ができない(が特定の人がいつも忙しい)
  • 似たような作業は、同じタイミングで実施した方が効率がよい、という思い込みがあって、複数のプロダクトバックログ項目の作業をまとめてやってしまっている
  • アーキテクチャ上の問題があって、複数の開発メンバーが同時に特定のコードを触りにくくなっている。コンフリクトが頻繁に発生して大変なので、それが起こりにくいところを着手してしまっている

アンチパターン3:プロダクトバックログの優先順位を無視して取り組んでしまう

優先順位を無視した取り組み

絵は少々極端ですが、選択したプロダクトバックログの先頭から順番に着手するのではなく、順番を無視して着手しているのを見かけることもあります。 しかしこれはプロダクトオーナーに対する冒涜行為です。プロダクトオーナーが順番をつけるのは、その順番につくることで成果が最大になると考えたからです。もしこのやり方をして、スプリント終了時に上位の項目が完了しなかった場合、そのスプリントで本当に手に入れたかったものが手に入らないことになってしまいます。

このようなやり方をしている場合には、以下のような問題がある可能性があります。

  • プロダクトバックログ項目間で依存関係があり、下位の項目が終わらないと上位の項目が終わらないようになっている
  • プロダクトバックログのリファインメントが機能していない。事前に開発チームがその順番では作れない(作りにくい)ことをプロダクトオーナーに伝えられておらず、適切な並び順になっていない

じゃあどうするのか?

ここまで見てきて、もうどうすれば良いのか分かっていると思いますが、プロダクトバックログ項目にどう取り組んでいくか整理しておきましょう。

  • 原則として、スプリントで着手するプロダクトバックログ項目は、上位の項目から着手する
  • 幅広くいろいろなプロダクトバックログに着手するのではなく、上位の項目から「1つづつ」「全員でよってたかって」「完成させる」
  • すなわちプロダクトバックログ項目の単位での同時仕掛りの数をなるべく少なくし、かつ完成までのリードタイムを短くする
  • 完成させるためには、プロダクトオーナーの受け入れ確認が必要なので、項目が1つでも完成したら速やかに受け入れ確認を依頼する。すなわちバッチサイズを大きくしない
  • 完成させることが何より重要なので、効率ばかりを追求しない

よい取り組みの例

最後に

うちではこうやってる!というのがあればぜひ教えてください。

スクラムの導入状況のサマリー (The State of Scrum Report 2017)

$
0
0

みなさんこんにちは。@ryuzeeです。

スクラムの導入状況

Scrum Allianceが調査を行ったThe State of Scrum Reportの2017年版が公開されていますので、サマリーを見ていきましょう。 なお、レポートはこちらから無料でダウンロードできます。

調査の概要

2016年秋に実施。回答者はScrum Allianceのメンバー2000人以上から回答。なおメンバーになれるのは、認定スクラムマスターや認定スクラムプロダクトオーナー等のコースを受講した人であるため、回答者の属性はスクラムの知識がある人に偏っていることを前提として認識しておく必要があります。 回答者は76カ国、15以上の産業にまたがっており、40%がIT関連の仕事、26%がソフトウェア開発に携わっているそうです。 質問内容は全部で44個から構成されており、アンケート回答者の属性・スクラムの導入状況・スクラムのロールとプラクティスの3つのカテゴリに分かれています。

調査結果の紹介

前述のとおり項目数が多いので、その中からいくつか特筆すべき項目について見ていくことにしましょう。 なお数字はレポートからの引用、文章はその数字に対する私のコメントです。

組織の中でのスクラムの利用状況

世間にはスクラムを利用していることで知られている会社でも、実際にはごく一部のプロダクトやプロジェクトだけで使っていて、あとは従来型の開発をしているというのは良く聞く話です。 アンケートの結果によればスクラムの組織内での利用状況は以下のとおりです。 組織全体に適用が進んでいるのは24%なので、回答母集団の偏りを踏まえると実際にはそれより少ないと思われます。

割合状況
61%スクラムは使っているプラクティスの1つ
24%スクラムは組織全体に広まっている
11%スクラムをお試し中
2%スクラムをやってみたがその後の方針は未定
2%スクラムをスケールアップしようとしたが失敗した

スクラム適用で重要と思われる点

特に大きいのがいわゆるマネジメントや経営者のスポンサーシップとサポートです。 スクラムは組織構造と密接な関係性があるので、ボトムアップ「だけ」で行うのは辛いこともあり妥当な結果だと思います。 そもそもスクラムに限らず何かを変えていく場合には、意思決定権限やヒト・モノ・カネを扱う人からのサポートは重要です。

割合内容
66%上級管理職のスポンサーシップとサポート
48%経験豊富なトレーナーやコーチの参画
48%スクラム自体が会社の全体的な戦略やゴールに合致していること
43%スクラムを使って達成したい明確なビジネスゴールがあること
37%従来のやり方からの反発の少ない移行
30%成否を測定するための明確なメトリクスの存在

スクラムを使って成果を出す上で障壁となっている点

組織構造や文化やマインドセットなどに関する項目が多いようです。

割合内容
52%組織構造や企業文化があわない
44%伝統的なウォーターフォールからの移行が難しい
42%他のプロジェクトとの兼ね合い
41%どうやって成功を具体的に測定してよいか分からない
36%信頼関係の欠如
34%予測を欲しがる
32%プロダクトオーナーや開発チームがスクラムのプラクティスに従わない
29%透明性に対する恐怖
23%顧客にスクラムが正しいアプローチだと理解してもらうのが難しい
18%上級管理職がスポンサーになってくれずサポートもしてくれない

スプリントの期間

2週間スプリントが多いのは妥当な結果ですが、1週間スプリントがわずか4%しかないことは驚きです。 一般的に言えば、スプリント期間が長くなるほど、計画作りが難しくなり、また改善のサイクルも長くなってしまうので、できれば短くした方が良いでしょう。 個人的にはなるべく1週間スプリントを推奨するようにしています。 自分の経験では、外部との依存関係が多い、プロダクトオーナーが忙しすぎる、プロジェクトの掛け持ちをしているなどの要因がある場合にスプリント期間を長くしたがる傾向にあるように思いますが、本来やるべきなのはその要因を取り除くことです。

割合期間
4%1週間
66%2週間
26%3-4週間
4%それ以上

スクラムと併せて使っている技術プラクティス

スクラムでは技術的なプラクティスについて触れていませんが、実際に毎スプリントでリリース判断可能なインクリメントを作ろうとすると、品質を確保し続ける仕組みが必要と言えます。 集計結果を見ても、それがはっきり表れています。またプロダクトバックログ項目を上から1つづつ終わらせるには開発チームのメンバーでよってたかって終わらせる方がよいのでペアプログラミングやモブプログラミングは有効です。

割合内容
74%完成の定義
58%自動化されたテスト
57%継続的インテグレーション
54%リファクタリング
49%適切なツールの活用
35%ペアプログラミング
35%テスト駆動開発
23%受け入れテスト駆動開発
16%システムデザインのシンプル化
16%技術的負債の測定
15%Specification by Example
12%BDD(ふるまい駆動開発)
4%モブプログラミング

以上、ご参考まで。

スクラムで開発チームが自由な取り組みをするには?

$
0
0

みなさんこんにちは。@ryuzeeです。

スプリントをずっと回していると、「いつもスプリントに追われている気がする」「一回立ち止まってゆっくり考えたい」「情報共有ができていない気がするので整理したい」「技術検証をもっとやりたい」「勉強時間をとりたい」といった話を聞くことがあります。 それに対して、どのように対処していくべきか考えてみましょう。 考えられる対応策はいくつもあるので、まずはそれを列挙します(ダメなものも混ざっています)

  • 複数回スプリントを実施したら、1回分のスプリントでは開発チームは好きに活動する(✕)
  • スプリントとスプリントの間に休憩を入れる(✕)
  • フィーチャー開発以外の取り組みを行うスプリントを必要に応じて用意する(△)
  • スプリントのキャパシティを見直して、開発チームが持続可能なペースで働けるようにする(◎)

それぞれを順番に見ていきましょう。

複数回スプリントを実施したら、1回分のスプリントでは開発チームは好きに活動する(✕)

まずは基本知識のおさらいをしましょう。 スクラムでは、プロダクトオーナーは限られた期間とリソースを活用してプロダクトの価値を最大化しようとします。 そのためにプロダクトバックログの並べ替えの最終決定権限を持っています。 並び順はスプリント開始前には最新になっている必要があります。 一方でプロダクトバックログ項目すべてを作成する義務があるわけではなく、開発チームが自分たちに必要な項目を作成することもあります。

例えば1週間スプリントを3回実施したら、1回は開発チームが好きなことをする、とした場合には次のようなことが問題になります。

  • この1週間の中断のときだけ、プロダクトバックログの先頭にある項目をデリバリーするリードタイムが倍になる。すなわちプロダクトオーナーはスケジュール見通しの予測が難しくなる
  • 前のスプリントの最後に行ったレトロスペクティブの結果を、すぐにプロセスに反映できなくなる
  • 上記2つはいずれもリズムの悪さと言い換えられる。リズムが悪いと改善できているかどうかの比較もしにくくなる
  • もし1週間の中断で好きなことをやるといって、そのプロダクトで後回しにしていたこと(リファクタリングやツールの導入など)をやるのであれば、プロダクトに関する変更が入ることになるが、その一方でどんな順番で何をやっているのかの透明性が低くなってしまう

ということで、このやり方は避けておくのが良いでしょう。

スプリントとスプリントの間に休憩を入れる(✕)

スクラムではスプリントレビューとレトロスペクティブが終わればスプリントが終了し、次のスプリントはスプリントプランニングから始まります。 すなわち、ここで検討するのは、スプリント終了から次のスプリント開始までにインターバルを取る、という考え方です。

結論としては、このインターバルが完全に空白の1日以上になるのは避けた方が良いでしょう。 当日スプリントが完了して、翌日スプリントを開始するまでの間が休憩になる、という程度であれば許容範囲だと思います。

この休憩でも、前述のとおり、プロダクトの変更は避けて透明性の担保が必要です。 でないと、そのうち実は分かっていたバグとか実はまずい問題のようなものをその時間を使って直すようになります。 そして実はそれはスプリントでは完了していないことを誤魔化している状態であるとも言えます。

フィーチャー開発以外の取り組みを重点的に行うスプリントを必要に応じて用意する(△)

開発チームとしてやりたいことが色々あるのであれば、プロダクトバックログ項目を作ってプロダクトオーナーに優先順位をあげてもらうように提案しましょう。 そして、プロダクトオーナーがそれらのプロダクトバックログ項目を中心に選べば、結果的にそのようなスプリントになります。

ここで気をつけるべきなのは(しつこいですが)、スプリントでどんなプロダクトバックログに取り組みたいかは、プロダクトオーナーの最終判断になるという点です。 従って開発チームが望んだとしても、ビジネス上の判断で、フィーチャーを優先するケースはあり得ます。 また、プロダクトオーナーが、フィーチャー開発以外の作業の重要性を理解しておらず、そのようなプロダクトバックログ項目をやりたがらないことも考えられます。 プロダクトオーナーがフィーチャー以外を軽視しているような場合は、開発チームはプロダクトオーナーに対して十分な説明をした上で、それでもダメならスクラムマスターが間を取り持つと良いでしょう。

スプリントのキャパシティを見直して、開発チームが持続可能なペースで働けるようにする(◎)

最後はスプリントのキャパシティの見直しです。常に開発チームが追われているように感じるのは、スプリントでやらなければいけないことがたくさんありすぎるからです。 すなわち、やることが多いので、本当は大事な活動を犠牲にしてしまっている可能性があることを意味します。 このような場合、開発チームが1スプリントで、実際に開発作業に使えるキャパシティを見直したり、それにあわせてスプリントに投入するプロダクトバックログの量をコントロールすると良いでしょう。 開発チームにプレッシャーをかけても速くなりません。 すなわちベロシティの向上を常に求めるような環境はおかしいということです。

最後に

開発チームがやりたいと思っていることがぜんぜんできていないようであれば、それは持続的なペースではない、ということです。 レトロスペクティブなどで、どのように対処するとよいかスクラムチーム全体で考えてみることをお勧めします。

それでは。

Viewing all 197 articles
Browse latest View live