nDiki : 開発

2017年1月17日 (火)

第11回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会11回目。今日は第11章 開発チーム。

ここまでの章で様々な視点でスクラムの説明がされてきたので、開発チームの章は比較的おさらないな感じで読めました。

開発チームのスキル

開発チームは設計・開発・統合・テストなど必要な作業を全て行うので、必要なスキルをチームは全て備えている必要があります。

このために

マネージャーは、今いる人たちでT型スキルのチームを作るべきである。

マネージャーは、学習や実験の時間がうまく作れるように、チームメンバーを支援する必要がある。

と書かれています。他のメンバと互いに専門分野を教え合いながらできる仕事を増やしていくのがまずは近道でしょうか。ただこの方法だと浅く広く学習は進むと思うのですが、 T 型の縦の部分、専門分野の部分を深めていくのは(機能別のチームで学び合うのに比べて)難しくなるのではと感じました。

「専門分野については個人で学ぶ方法を獲得していて自力で学べるのでは」という意見が勉強会では出ました。

開発チームの構成

チーム構成の話では小さいチームの方が

としています。一方

  • チームのもつスキル
  • 議論の多様性
  • 学習

などを考えるとある程度の人数も必要でこのあたりのバランスが重要そうです。本章では

一般的には5〜9人のチームが最適とされている。

ビジネス価値を迅速に届けるスイートスポットは5〜7人のチームである。

と述べられていました。そういう意味では今の私のいるところのスクラムチームは人数がちょっと少なすぎるかなと感じました。

掛け持ち

掛け持ちに対する問題は承知しているものの、現実的にせざるを得ない場合が発生します。

複数のプロダクト(またはプロジェクト)や複数のチームに関わると生産性が低下する

3つ以上のプロジェクトの仕事を同時に行うのは経済的ではない

とありこれに従うとすると仕方なく兼務にするにしても2つまでにすべきということですね。そういった状況が発生するのは

多くの組織では、同時に開始するプロジェクトが多すぎる

ということで組織体制の工夫以前にプロジェクトの見直しをすべきなのでしょう。

チームの寿命

長寿のチームはできたてのグループよりも生産性が高い

については完全同意。今までもチーム殺しをしないように意識はしてきました。特にスクラムではチームとして見積もりやベロシティの履歴が蓄積されることで正確性が向上していくところがあるので、チームを維持していくことがより大切に感じられます。

スポンサード リンク
[ 1月17日全て ]

2017年1月24日 (火)

第12回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会12回目。今日は第12章 スクラムチームの構成。

今回の内容は主にスクラムチームメンバより上のレイヤーの人たち向けの内容です。

複数のスクラムチームによる共同作業が必要だと、いつかは思い知ることになるのだ。

ということで複数のスクラムチームの話。前半はフィーチャーチームとコンポーネントチームについて。本書ではフィーチャーチーム推しで、コンポーネントチーム構成からフィーチャーチーム構成へ徐々に移行する場合の体制の案を示しています。

フィーチャーチームかコンポーネントチームかという問題を解決する万能のソリューションはない。

ということで、ここはプロダクトと組織にいるメンバの状況に合わせて考えていくしかない感じです。

本章でも「同時に開発を進めるプロダクトの数を減らす」という話が出てきていろいろ考えさせられます。

スクラムオブスクラムについては、定期開催で開かれるのは良いとして現実的にはアドホックにどんどん相談していっちゃう方が早いんじゃないかなと感じました。

リリーストレインについてはかなり大規模なプロダクトが想定でしょうか。「スクラムのためのアクティビティで時間が奪われすぎないか」「末端のスクラムチームでは適応できる余地が少なくなってしまうのでは」などという疑問が湧きました。

[ 1月24日全て ]

2017年1月30日 (月)

これからしばらくは「プロセスではなくプロダクト」

去年の秋から何チームとかスクラムチームとして開発をするようになったこともあって「プロセス」に意識を割く割合が多い日がここしばらく続いていました。

ちょっと形になってきてプロセスの方の検査と適応はまわるようになってきたので、2月から、といわずこれからしばらくはよりプロダクトの方に意識を向けていくことにします。

[ 1月30日全て ]

2017年2月7日 (火)

第14回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の14回目。今日は第14章 スクラムのプランニングの原則。

原則とは?

今回は「原則」の章ということで、今日の発表当番だった CSM の人があらためて「原則とは?」という点について掘り下げてくれました。「価値とプラクティスを結ぶ」原則について

「原則なしに上辺だけプラクティスを実行してても意味ないよ」

と CSM の人が語ってくれました。「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」についてその場でみんなで見返しました。

事業体としての価値観と原則、個人としての価値観と原則、そして開発プロセスフレームワークとしての価値観と原則と、この辺り自身でも整理しないとなと最近考えているところです。

プランニング

プランニングについては出来上がった計画よりも計画のための対話などのプロセスが重要なのだなと最近感じるようになりました。

  • 事前にきちんと計画を作れると思うな
  • 計画を守ることよりも、計画の調整や再計画を重視する

ということで継続的にプランニングし直していくことが大切なのだなと。

14.4 プランニングの選択肢は、最終責任時点まで変更可能にする

についてはここではかなりあっさりとかかれています。物事を進めるには常に大小様々な意思決定をしていく必要があるので、さらっと読むと気持ちわるい感じがします。ここは 3.3 節にも

重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。

とあるので、方向転換できない状態に早い段階でならないようにするといったところなのだと理解しました。

14.7 早めにリリース、頻繁にリリース

については原則として頭にいれつつ、実際には適切なフィーチャーが揃っているかをきちんと考える必要がありますね。あまりに小さなリリースすぎて早い段階でユーザーに見限られてしまう危険性や、頻繁な変更によってユーザーが負担を感じて満足度が低下してしまう可能性も常に意識すべきかと。

この章でも

この手法には限界もある。まずどんなプロダクトであっても、最低限これだけは揃えないとリリースできないし市場で勝負できないというフィーチャー群がある。

と言った上で

もし部分的にでもよいから少しでも早めに受け取りたいという業界を相手にしているのなら、小さい単位で頻繁にリリースするという原則はとても重要になる。

としていました。

[ 2月7日全て ]

2017年2月8日 (水)

3チームのプロダクトバックログを1つにまとめる

昨年秋から開発グループを3チームに分け、それぞれのプロダクトバックログを用意してスクラム開発をしていました。数カ月経ちだんだんとスクラムチームとしての形ができ、また課題も見えてきたこのタイミングで3つのプロダクトバックログを1つにまとめてみることにしました。

月曜日に CSM からプロダクトバックログを1つにまとめるとう提案を受けたので、勢いでその日に1つにマージしちゃいました。3つのチームで取り組んでいることについて優先順位をつけるのはガッツが必要ですね。それぞれのチームとしては最優先のものを取り組んでいるものに対して優先順位をつけるのですから。

ツールとしては Google スプレッドシートでプロダクトバックログを作っていたので、そのまま Google スプレッド上で1つにまとめ、そのかわりにフィルタを使ってチーム別のビューも用意しました。

一昨日に1つにまとめたあと、昨日と今日と各チームのプロダクトバックログリファインメントを実施。他のチームのにあったプロダクトバックログアイテムについての興味の持ち方はチームそれぞれ。じっと概要をまず聞くチームだったり、積極的に内容を聞いてくるチームなど個性がありました。

3本のプロダクトバックログを1本にまとめることで、同時に進める開発の数を減らすべきだなということがおのずと見えてきました。今後は全チームを通してみんなで優先順位の高いものからやっていけるようにしていきたいなと思っています。

[ 2月8日全て ]

2017年2月14日 (火)

第15回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の15回目。今日は第15章 さまざまなプランニング。昨年12月のプロダクトオーナーの章ぶりの発表当番です。

この章ではスクラムを使ったプロダクト開発に関係する以下のプランニングを紹介しています。

  • ストラテジープランニング
  • ポートフォリオプランニング
  • プロダクトプランニング(エンビジョニング)
  • リリースプランニング
  • スプリントプランニング
  • デイリープランニング

勉強会では自分たちの事業でのプロダクトは何か(例えば mixi は1つのプロダクト)を確認し、実際やっていることのどれが各プランニングにあたるのかを確認。スクラムチームメンバから直接体感できるのはプロダクトプランニングまでで、ポートフォリオプランニングはうかがい知れないことが多そうという話になりました。

それから(旧来からの)受託開発の場合は、リリースが固定スコープ・固定日だよねなんて話も。

スクラム開発チームメンバからは「トップダウン型のプランニングの流れの印象だが、スクラムチームの見積もりでわかった計画との差異はどのように上位の計画に反映していくのか?」という疑問もあがりました。

このあたりは続く章で説明があるのかもしれません。

[ 2月14日全て ]

2017年2月15日 (水)

進捗に合わせてスプリントゴールを変更するということ

もうすぐスプリント終了という時期に開発チームから

残りのタスクは開発チーム外の人がやることになりました。もうこれ以上開発チームではこのスプリントではやることがないので、進捗したところまでにスプリントゴールを変えたいです。

という相談が入りました。

開発チームとしてもいろいろ検討した結果なので開発チーム外の人待ちになること自体は受け入れるのですが、スプリントゴールを変更して「これでバーンダウンチャート上 0 になります」というのは違うんじゃないかなと強く感じました。

スプリントゴールは基本変えるべきではありませんが「状況が変わったからゴールを変える」や「予想より難しいのでスコープを調整する」こと自体は問題ないですが「進捗したところまでにゴールを変える」というのは完全に異質だと思うのです。

スプリントゴールは変えずにスプリント終了時に未完成とし、きちんとふりかえるのが良いのではないでしょうか。

[ 2月15日全て ]

2017年2月16日 (木)

Developers Summit 2017 1日目 #devsumi

rimage:/nDiki/2017/02/16/2017-02-16-093430-nDiki-1200x900.jpg

今日から2日間目黒雅叙園でデブサミです。今年で来るのも3回目。例年通り一般参加者はテーブル無しのぎゅうぎゅう席なので1日いるとちょっと大変です。今年はノート PC を持っていきました。開けたのは半分ぐらい。

10:00~10:45 【16-E-1】 Web フロントエンドの変遷とこれから

株式会社サイバーエージェント 佐藤歩(@ahomu)氏 泉水翔吾(@1000ch)氏

@1000ch 氏

200x 前期からのタイムラインを浅く解説。

  • Progressive Web App (プログレッシブ ウェブアプリ)・Service Worker を使ってオフライン環境での動作。
  • Extensible Web
@ahomu 氏

Web フロントエンドに期待される変化と適応。一般論的な展開でした。

11:05~11:50 【16-A-2】 Yahoo!ブラウザーアプリのプロダクトマネージャーが考えていること

ヤフー株式会社 里山南人氏

プロダクトマネジメントについて3点。最初の2点は自身も見直したいなと思いながら聞いてました。

市場環境の分析と戦略化
  • 競合を明確にした上で差別化
    • 4C 分析 機能・流通チャネル
根拠に基づくアプリの成長手法
  • 健康状態のチェック(KGIKPI)
    • KPI ツリーと対応する施策
    • 継続利用: 定着しそうな機能を重視
  • 定期的な観察と分析
組織連携・組織貢献
  • 安定市場でのリソース(エンジニア)確保は難しい。
    • エンジニアが取られていく。
    • グロース施策 (東京)
    • 基本的品質改善(ベトナム)
  • All Yahoo! JAPAN フラグシップ戦略

13:05~13:50 【16-B-3】 パネルディスカッション「エンジニアが創るプロダクトの未来 ~エンジニアからプロダクトマネージャーへ~」

ソニーモバイルコミュニケーションズ株式会社 高橋りさ(@hatarakuboysmom)氏 株式会社ビズリーチ 鈴木康弘(@yappy727)氏 株式会社サイバーエージェント 横道稔(@ykmc09_dev)氏 グロースエクスパートナーズ株式会社 関満徳(@fullvirtue)氏

エンジニアからプロダクトマネージャーになった人によるパネルディスカッション。きちんと事前に準備がされて、パネラー同士のからみもある良いパネルディスカッションでした。

プロダクトマネージャーになることでコードを書く時間は無くなったけれど、自分で SQL クエリを発行してデータを取ったりできるのはやはりエンジニアリング経験の強みとのことでした。「プロダクト」マネージャーですが、どなたも強いチームを作るために費やしている時間の割合が多いということがうかがえました。

今週読み始めInspired: 顧客の心を捉える製品の創り方」が何度か引き合いに出されていました。やはり必読書のようですね。

14:10~14:55 【16-B-4】 MicrosoftのAI開発機能/サービス

日本マイクロソフト株式会社 佐藤直生(@satonaoki)氏

AI 界隈のおさらいをしたあと、Microsoft の取り組みなどを紹介。エバンジェリストらしいちょっとセールスぽいセッションでした。

解約・離反対策として、解約・離反しそうな人を予測発見するというさらっと出た事例が面白そうでした。ぜひそういうのをもっと聞きたかったです。

15:15~16:00 【16-B-5】 AI礼賛時代にエンジニアはいかにしてサバイブすべきか

株式会社ブレインパッド 下田倫大(@rindai87)氏

下田氏のセッションということでチョイス。そういえばふわっとしたタイトルだったので最初は何を話すのかなぁと思って聞いてました。公募セッションだったのでキャッチーなタイトルにしたとのことです。

内容としては昨今の「人工知能やりたまえプレッシャー」のなか機械学習にどう取り組んでいくかという話と、機械学習に携わっていくエンジニアのスキル・キャリアパスにはどのようなものがあるのかでした。

実務に裏打ちされた惹きつけられるセッションでした。機械学習(や人工知能)がらみの新事業に入るエンジニアも聞いておくと良かったんじゃないかなと感じました。

16:20~17:05 【16-C-6】 事業成長にコミットするエンジニア組織への道のり

株式会社リクルートライフスタイル 小川健太郎氏

「社員エンジニア」急増に合わせた組織と文化を作ってきましたという話。抽象化された説明の部分が多くてそこは「まあそうですよねー」なので、時々でてくる具体的な点を注意して聞いてました。かなりぼやかされた発表でしたが、いろいろ試行錯誤されたんだろうというのは伝わってきました。変えてこれているのは実際すごいなと。

17:25~18:10 【16-A-7】 ザ・黒帯 ~ Yahoo! JAPANのエンジニアの働き方とキャリアを語る

ヤフー株式会社 楠正憲(@masanork)氏 伊藤宏幸(@hageyahhoo)氏 倉林雅(@kura_lab)氏 里山南人氏 CodeZine編集部 斉木氏

パネラー同士のからみはあまりない進行スタイル。

黒帯制度がらみ中心とした Yahoo! JAPAN の中の話。Yahoo! JAPAN 独自の話の中、パネラーの方がそれぞれどのような立場・思いで仕事をされているのかというのが少しですが伝わってきました。

それとは別に始めの方で @masanork 氏が PDCA を回す内製プロダクトと受託開発プロダクトとの差が大きくなってきた時代という話をされていたのが印象的でした。

[ 2月16日全て ]

2017年2月17日 (金)

Developers Summit 2017 2日目 #devsumi

今年は「人工知能とは」「機械学習とは」を繰り返し聞きました。

10:00~10:45 【17-B-1】 きゅうり農家から保険会社まで、機械学習を「民主化」するTensorFlow

グーグル株式会社 佐藤一憲(@kazunori_279)氏

  • 「テンサーフロー(発音)」
  • ニューラルネットワークでチーターを見つけられるかも?
  • Google 検索: RankBrain

わかりやすくわくわくする発表でした。簡単に出来ちゃうと感じさせるトークでしたが、製品に適用していくには泥臭いトライアンドエラーとリリース後の保守が待っているのだなあというのも想像しながら聞いてました。

ハードウェアの話を聞いていると、もはや超大手の手のひらの上で学習させていくしかないのかなーと感じさせられちゃいます。

11:05~11:50 【17-C-2】 教育、医療、もの書き市場で戦うプロダクトマネージャーの考え方 ~訴求ファーストとこだわり駆動開発とは?~

株式会社ジャストシステム 宮崎哲哉(@miya2tetsu)氏 大島教雄氏 岡美香氏

  • プロジェクトは「訴求ファースト」
  • スマイルゼミ。企画の話。訴求シート。あまり驚きのない内容。
  • JUST DWH。訴求シート。
  • 一太郎。ユーザー調査をしっかりやったという話。

自社製品の訴求セッション。デブサミじゃなくてもという感じではありました。

12:10~12:40 【17-A-L】 ママセキュリティエンジニア奮闘記 ~ 子供と一緒にラズパイで遊んでみた♪ ~

ソニーデジタルネットワークアプリケーションズ株式会社 吉田万里子氏

エンジニアとしての思いと親としての思いを叶えるためにラズパイで遊んでみるという話。子供の成長についていろいろ考えていらっしゃって素敵だなと感じました。

後半にだんだん技術的に具体的な話にきちんともっていく構成も上手いなと。

13:05~13:50 【17-D-3】 リーンスタートアップとスマートなエンジニアリングの葛藤

グロースエクスパートナーズ株式会社 関満徳(@fullvirtue)氏

  • プロダクトマネージャーとプロジェクトマネージャーの分業化。
  • 日本的プロダクトオーナー(幅広い業務範囲)
  • リーンから見た葛藤。リーンのサイクルとスクラムのサイクル。
  • オポチュニティバックログ。
  • Done の定義は最近は「ストーリーテスト」。
  • スプリントに入れないようなタスクのためのかんばんを作る。ToDo/Ready/In Progress/Done/Feedback
  • そのかんばんをどれくらい捌いていくか(FAQ)。→ 経験則で。アジャイルだから学習していく。リリース日を含むスプリントはかんばんの方多め、そうでなければプロダクトバックログの方多めがやりやすい。

準備完了なプロダクトバックログアイテムを準備完了にしていくためのサイクルやタスクをどうするかなと思っていたので参考になるかもしれないなと思いました。複雑になるので今のチームの状態でやるべきかは見極める必要がありそうですけれど。

14:10~14:55 【17-A-4】 C#で簡単にモバイルアプリを作ろう!

日本マイクロソフト株式会社 千代田まどか(@chomado)氏

一つ前のセッションを見終えてからいったらもう満席でした。

15:15~16:00 【17-C-5】 コミュニティとエンジニアの生き方

TickleCode 代表 小林由憲(@yoshiii514)氏 関西Javaエンジニアの会 阪田浩一(@jyukutyo)氏

勉強会コミュニティの始まりと成長。」

勉強会の話。

「Javaコミュニティを作ったら人生変わった」

「運営に関わろう、なければ作ろう」

なりたい人に近づくといいよという話と、貢献しなよという話。

16:20~17:05 【17-B-6】 インテリジェンスで挑むサイバー攻撃の最前線

株式会社インターネットイニシアティブ 穴吹健一氏

  • 今後はリアルタイムモニタリングとインシデント発生時の迅速な対応、リスク管理、ユーザの教育。
  • カラオケでのレコメンド(セキュリティ?)。
  • IIJ の情報分析基盤。Hadoop とか Zeppelin とか。
  • IP(アドレス)のレピュテーション情報の生成。

最後は IIJ のセキュリティビジネスの話に落ち着いて終了。さすが IIJ 的な内容のトークはあまり無かったです。

17:25~18:25 【17-E-7】 すべてのIT屋は全力で反省しろ!『ITは本当に世界をより良くするのか?』発刊記念トーク

株式会社ワークスアプリケーションズ 井上誠一郎氏 株式会社ノーチラス・テクノロジーズ 神林飛志 株式会社セゾン情報システムズ 小野和俊氏

お互いにレスペクト感があるなかでの軽快な対談を楽しみました。

[ 2月17日全て ]

2017年2月21日 (火)

第16回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の16回目。今日は第16章 ポートフォリオプランニング。

これまで読んだ章の中で一番頭にすっと入ってこない章だったのは、あまりかかわってこなかった領域だからでしょうか。

ポートフォリオプランニングはプロダクト(あるいはその1リリース、プロジェクトなど)をどれぐらいの期間でどの順番でやるかを計画する作業です。

本書ではプロダクトのライフサイクル収益(プロダクトの生存期間中に見込める利益の総合計)が最大になるように優先順位を決めましょうと言っています。ライフサイクル収益は遅延コストと存続期間の影響を受けるのでこれをきちんと考えましょうとのことでした。

今日の発表者によると「ライフサイクル収益を使うのは社内政治の排除のため。ライフサイクル収益には利益以外にも社員満足度・顧客満足度・従業員満足度(離職率と採用コスト・回復コスト)なども考えれれる」といったことを CSPO 研修で聞いたとのことでした。社内政治排除のためというところが重要どころだそうです。

本書によるとポートフォリオバックログに入れる際は

コストや価値に関するちょっとした見解の相違で言い争いになって決断ができないのだとしたら、そのプロダクトの開発は却下すべきだ。

とのこと。

ほとんどの組織では、価値の高いプロダクトを開発する機会が有り余っている。価値を生み出すか疑わしいプロダクトについて、いつまでも議論をしている余裕はないはずだ。

と言い切ってます。迷ったら不採用という考えについて Joel on Software の採用面接ゲリラガイドを思い出しました。

[ 2月21日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィの SNS の企画開発を行うグループでマネージャー・プロダクトオーナーをしています。CS 向上・ユーザーサポート・健全化などにも取り組んでいます。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.098705s / load averages: 0.58, 0.44, 0.42
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker