nDiki : 開発

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

2017年3月26日 (日)

カンバン? かんばん?

Kanban って「カンバン」なのか「かんばん」なのかどっちかなぁと思っていたのですが、ソフトウェア開発で出てくるのは「カンバン」みたいですね。

「かんばん」プル型システム、見える化、その他リーンのアイデアを、技術開発やITオペレーションに導入するためのツールを駆使した進化的な変手法を示す用語として、(カタカナの) 「カンバン」を使用する。 -- カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business

アジャイルサムライもカンバンでした。

[ 3月26日全て ]

2017年3月28日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の21回目。第21章 スプリントレビュー。スプリントの中でいちばんうまく出来ていないスプリントレビューの話です。

スプリントレビュー

スプリントレビューは作業結果(出荷判断可能なプロダクトインクリメント)の検査と適応をするアクティビティです。

不都合な真実も含めて、現在のプロダクトの状況を透明に見せてくれる。

という、ちょっと最初は勇気が必要なアクティビティです。

この章によるとスプリントレビューはスクラムチームがスクラムチーム外の人に説明しフィードバックを得るための機会なのです。しかしながらついチーム内の確認の場になりがちで、チーム外の人からきちんとフィードバックを得られていないと反省しています。

スケジュールの調整

スクラムチーム外の参加者が最も多く、スクラムのアクティビティの中では最もスケジュールの調整が難しいと述べられています。たしかに。ステークホルダーのスケジュールに合わせてスプリントレビューのスケジュールを決め、それに合わせて他のアクティビティを合わせるのが現実的とのことでした。

スプリントレビューに参加してくれないようなら、それは開発する価値のないプロダクトということである。したがって、プロダクト開発を注視すべきだろう。

きちんと参加者が集まらない場合は同時並行の作業が多すぎないかも見直すべきなのかもしれません。

スプリントレビューのアウトプット

リファインメント(グルーミング)したプロダクトバックログと更新したリリースプランがスプリントレビューのアウトプットだと書かれています。

ほとんどのチームはスプリントレビューでグルーミングをしている。関係者全員が開発の現状と今後を理解して、新しいPBIを作成したり、既存のPBIの優先順位を変えたり、不要なものを削除したりする。

これも全然意識できていないところ。今はコメントをもらって終わりになっています。きちんと対話をしプロダクトの適応をするところまで実現できていないなと。

デモ

デモが難しいからといって、それはデモをしない理由にはならない。

プロダクトオーナー側でも「まぁいいか」と思ってしまうの良くないですね。反省。

スプリントレビューはスクラムマスターと協力してきちんと設営していく必要があるなと感じました。

[ 3月28日全て ]

2017年4月14日 (金)

第23回 エッセンシャル スクラムを読む会 (最終回)

rimage:/nDiki/2017/04/14/2017-04-14-092915-nDiki-800x1200.jpg

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の23回目。第23章 未来へ。ついに最後の章です。

スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変するために協力しあいながら確固たる信念をもって立ち向かおう。

そんなメッセージを本章から受け取りました。

第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。

「エッセンシャル スクラム」と「エッセンシャル スクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャル スクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。

エッセンシャル スクラムを読む会ふりかえり

エッセンシャル スクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。

ふりかえって出てきた話題としては

  • 取り組む領域がクネビンフレームワーク(第1章)のどの領域なのかを見てスクラムを採用するかどうか考えたい。
  • チームメンバでエッセンシャル スクラムを読むことで「PBI」などの同じ理解で使える言葉が増えた。チームの共通言語作りに貢献できた。
  • 原則大事(第3章・第14章など)。
  • WIP を下げる重要性をあらためて学んだ。
  • 準備完了の定義・受け入れ条件が重要。

などが上がりました。

また実際に読む会と並行してスクラムを行ってきた中で

  • プロダクトバックログリファインメントで1スプリントにおさまるように適切にプロダクトバックログアイテムを分割するの大変だよね。
  • スクラムマスターと開発チームメンバ(エンジニア)との兼任が難しかった。
  • スクラムマスターであると同時に組織図上のリーダーという立場でいると、自発的行動を促すのとある程度指示的に動かすのとの兼ね合いが悩ましかった。
  • 困った状態であることにメンバが気がつくのを3カ月待った上で物理カンバンを導入してみた(すごい)。

などの話が出ました。

スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。

全23回

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

[ 4月14日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・PO をしています。

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

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

月別インデックス
Process Time: 0.111483s / load averages: 0.31, 0.23, 0.26
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker