nDiki : 開発

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日全て ]

2017年2月23日 (木)

「Inspired 入門」 (第1回)

Inspired: 顧客の心を捉える製品の創り方

プロダクトオーナーやプロダクトマネージャー(PdM)の必読書と言われているらしい「Inspired: 顧客の心を捉える製品の創り方」の内容を理解し、実践・共有することで力をつけていきましょうという「Inspired 入門」勉強会に参加してきました。今日が第1回。渋谷界隈でネットサービスを行っている4社から参加者が集まりました。

各社ネットサービスを展開していますが、お互いにビジネス領域が被らないためざっくばらんに話ができそうです。企業毎に組織体制や文化が異なり、プロダクトマネージャーの仕事・役割もそれぞれ違うよねということをあらためて感じました。取り組みや課題などをお互いに情報交換することで、いろいろ学びがありそうです。CS 部門経験者の方も何名かいて、ぐっと親近感がわきました。

今回は幹事役をしてくれた方が資料を用意してくださっていてそれを使いながらファシリテーションしてくれました。感謝。

話題から

ある方のところでは、ユーザーに影響のある施策についてはコンセプトシートを書くとおっしゃっていました。他の方はリーンキャンバスを作るようにしているとのこと。自分のチームではプロダクトバックログ上にストーリーを書いて済ませることも多いのですが、少し大きいサイズのものはこういったものを書いた方が良いなと今回感じました。

PdM という役職・肩書のある会社はというお題については、ほとんどの方がないということでした。

それからユーザーストーリーマッピングを1日かけたという話をしてくれた方は「エンジニアも一緒に参加することで、作る側の納得感が出て良かった」とおっしゃってました。なるほどです。

Inspired より

今回は1章から3章がトピックだったので以下個人的なメモ

第1部は「ソフトウェア製品の開発に関わる人たち」。人・プロセス・製品という3領域の中の「人」。その役割と責任について。

第1章: 製品開発の鍵を握る担当者とその役割

まずは役割の説明。プロダクトマネージャーのやることとして以下を挙げています。

プロダクトマネージャーの主な任務としては2つある。製品の市場性を評価することと、開発すべき製品を定義することである。

プロダクトマーケティングも兼務になっていることが多々あるがまったく別の技能が必要なので、兼務は非常に難しいとしています。この点は第2章で詳しく取り上げられています。プロダクトマーケティングが分離されていると助かります。

プロダクトマネージャーは5〜10人のエンジニアに対して1人必要とのこと。スクラムチームの人数ともだいたい同じ規模感。

第2章: プロダクトマネジメントとプロダクトマーケティング

「プロダクトマネジメントとプロダクトマーケティングをそれぞれしっかり」「製品の最終責任者を明確に」「プロダクトマネジメントは専任で」

プロダクトマネージャーの役割とプロダクトマーケティングの役割をきちんと区別するのが大切。

第3章: プロダクトマネジメントとプロジェクトマネジメント

ここではさらにプロダクトマネジメントとプロジェクトマネジメントを区別しましょうという話。

[ 2月23日全て ]

2017年2月28日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の17回目。今日は第17章 エンビジョニング (プロダクトプランニング)。

「エンビジョニング」という言葉に馴染みがなかったので「プロダクトプランニング」の方がわかりやすいよなーと最初は思ったのですが、慣れてくればエンビジョニングでも「ビジョン」に意識が向いていい気がしました。

エンビジョニングのタイミング

何度も繰り返すアクティビティであり、一度やってそれで終わりではない。

これ系のアクティビティはどうしても半期毎のサイクルになってしまいがちなのですが、アジャイル的にはもっと早いサイクルにやった方が良いということですね。

エンビジョニングをやりすぎないようにエンビジョニングの完了予定日を設定しておくのは確かに必要だなと感じました。やろうと思えばいくらでもやれてしまうものなので期日を明確にした方が経済的でしょう。

エンビジョニングの参加者

最初のエンビジョニングで必須なのはプロダクトオーナー。いったんプロダクトの開発が動き出して以降のエンビジョニングにはスクラムチーム全体が参加すべき。概要レベルのプロダクトバックログの作成でストーリー記述する際もスクラムチームメンバ全員が関わった方が良いと言っています。

このあたり結構孤独にやっちゃうことも多いんじゃないかと思うですが、やはりチームでやった方が良いようです。

価値のカテゴリ

図17.3 で「ステークホルダーが得る価値の分野」としてカテゴリ分けされているのは地味に便利ですね。

  • 参入条件
    • ハードルをクリアする
    • リリース可能な最小限のフィーチャーをデリバリーする
    • SOX、FDA、HIPAAなどに準拠する
  • 使用可能性
    • 新たなマーケットを対象とする
    • 他のプロダクトやサービスを販売できるようにする
  • 差別化要因
    • 競合他社と差別化する
    • 顧客を喜ばせる
  • 妨害
    • 競合他社の差別化要因を無力化する
    • ハードルを上げる
    • 市場での注目先を変えることで、ゲームのルールを変える
  • コスト削減
    • 市場に投入する時期を早める
    • 開発工数や投入する要員を減らす
    • 利益を増やす
    • プログラミングの技術を高める

自分が取り組んできたものだと「顧客を喜ばせる」「要員を減らす」とかが多かったですが、製品・市場によっては確かに妨害とかもあるのでしょうね。

今日は参加者少なめで5人。23章までいれるとあと6回のところまできました。

[ 2月28日全て ]

2017年3月2日 (木)

渋谷 PdM ランチ会 Vol.1

先週参加した Inspired 入門勉強会グループメンバで都合のつく人で交流ランチ。第1回の勉強会ふりかえりや次回の進め方などの話をしつつ、カジュアルにプロダクトマネージャー業の情報交換となりました。

私のグループのチームは今はスクラム開発していますという話をしたところ、他の3名のところではスクラムを導入していない/できていないとのことでした。

私もスクラムは学びながらやっていて「エッセンシャル スクラムを読む会」という社内勉強会に参加している最中です。

1週1章1時間、(参加者がその回の章を読んできている前提として)その日の当番の人がサマリを発表、流れで随時「ここ良くわからなかったのですけれどどう思います?」とか「私たちの組織・やり方だとここが当てはまっている・違っている」とかそういう会話をする流れでやってます。

といった感じで進めていますと紹介しました。

さっそく戻って読み合わせやろうという話になっているというコメントをもらって、皆さんスピード感があってさすがだなぁと。

[ 3月2日全て ]

2017年3月13日 (月)

今年度最後の有給休暇 【日記】

まだまだ有給休暇が残っているので今日は休みにしました。多分今年度は今日が最後。今の地に引っ越してから気にはなっていたものの一度も入ったことのなかったハンバーグ屋に行ってみたりしました。

Google Play をみてみたら iA Writer for Androidアップデートが出ていたので更新。気に入っているライティングアプリなので開発が止まっていなくて嬉しいです。

[ 3月13日全て ]

2017年3月21日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の20回目。今日は第20章 スプリントの実施。すでに前の章で説明されていることもまた出てきて、そのあたりはおさらいとしてさらりと読むことができました。

誰がどの作業から始めてどの作業から完成させていくか

誰がどのタスクの作業をするのかはチームメンバの共同責任。どの作業から始めるか開発チームに選択する能力が必要。どの作業から完成させていくかはチームが決めること。開発チーム自身が考えてねという感じです。がんばれ開発チーム。

実際に作業を完成させていくにあたっては「スウォーミング」という聞きなれない言葉が出てきました。

新しいアイテムに着手する前にキャパシティのあるチームメンバが集まって、すでに誰かが着手したアイテムを完成させること。

ということで、動けるメンバで順にアイテムを完成させていきましょうと書かれています。ただ完全にシングルタスクで進めていけばいいかというとそうでもなく「すべてのチームメンバーが同時にひとつのアイテムに取り掛かるのは危険だ。」と書かれており、いい感じに絞ってやりましょうということでした。

ちなみに巻末でのスウォーミングの説明には

ある程度のゆとりと適切なスキルを持ったチームメンバーが集まって、ある項目に対して共同作業(スウォーミング)を行い、新しい項目に着手する前に、すでに進行中の作業を完了させること。

と一見 GNU 的な説明になってました。

デイリースクラム

デイリースクラムのところには

チームメンバーの最適な作業配分についてみんなで理解する

とありました。「昨日やったこと・今日やること・困っていること」という型ついなぞるだけになりがちですが、きちんとチームとして誰が何をどうやっていくかを共通のものにすることを意識していくことが大切ですね。

[ 3月21日全て ]

About Me

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

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

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

月別インデックス
Process Time: 0.104995s / load averages: 0.46, 0.49, 0.59
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker