ikeike443のブログ

Playコミッターが書くソフトウェアビジネスに関心がある系のブログ

#DevLOVE 関西でお話させていただきました

進め、現場のチーム開発 〜チーム開発実践入門〜 (DevLOVE関西Ver) - DevLOVE関西 | Doorkeeper におよびいただき、チーム開発についてお話させていただきました。恐縮です。ちなみに場所ははてなさんにご提供いただきました。ありがとうございます!

以前東京で行った 池田尚史氏に聞くチーム開発の極意 ~「進め,現場のチーム開発 ~チーム開発実践入門」レポート:レポート|gihyo.jp … 技術評論社 の時の講演内容に事例を加えて少しラップアップを足したものです。


僕の発表の後、みんなでディスカッションを行いました。いろんな開発現場の方のいろんなケースを伺えて面白かったです。

台風が来ていたので勉強会は早めに切り上げ、近くの居酒屋で16時から飲んでおりました。。(恒例)

はてな新社長(!)の栗栖さんともご挨拶させていただき、一緒に串かつを頬張りました。

ステッカー欲しいな、って言ったらくれました! 言ってみるもんだ!


mackerel(https://mackerel.io/)、チョー気になる。使ってみたい。

プロダクトマネジメントとプロジェクトマネジメントまたはプロダクトマーケティング

Inspiredという本があって、数年前からWeb上で翻訳が進んでいたのは知っていた。

しばらく忘れていて、先ほどたまたま確認したら既に2年前に翻訳が終わっていた。
http://inspiredjp.com/toc/

この本にはソフトウェア企業に務めている人であれば誰でも悩むようなことが書かれている。

プロダクトマネジメントとプロジェクトマネジメントの違い、プロダクトマネージャーの重要性と不在、特にプロダクトマーケティングの不在。アジャイル開発との関係。カスタム開発*1とパッケージソフトあるいはインターネットサービス開発の違い。アジャイル開発はもともとカスタム開発の問題解決のために考案されているためか、プロダクトマネジメントについての考慮が抜け落ちている件、などだ。

僕もまだ読んでいる最中なんだけど、この話題はとても興味があり、悩みも多い。
プロダクトマネジメントとプロジェクトマネジメントの違いについては、8年前にSI企業からパッケージソフト企業に移ってきた時に一番考え方を変える必要があった分野だし、今でも自分で上手く扱えていない問題だと思っている。

日本に限らないと思うけど、ソフトウェアエンジニアの大半はSI企業で受託開発をしている人が多い。僕もそうだったし。なので、パッケージソフト開発の企業も、Webサービス開発の企業も、元々はSIで働いていました、という人がほとんどだ。SIからパッケージやWebサービスの企業に移ってきた人は僕も含めてみな最初はこの違い*2を理解できずに苦しむ人が多いように思う。

とりあえず、自分の頭を整理するためにプロダクトマネジメントとプロジェクトマネジメントについて表に書きあらわしてみた。*3
f:id:ikeike443:20140713000828p:plain

プロダクトマネジメントとしては、プロダクトマーケティングとプロダクトデベロップメントの両方のマネジメントが必要だろう。

プロダクトマーケティングは、市場創出を含めたマーケティングプランの作成実行と、ブランディングあたりをレスポンシビリティとするのかなと思う。

プロダクトデベロップメントはいわゆる製品開発の領域で、製品企画を考えたり、機能一覧を作ったりユーザーシナリオを整理したりという、要件定義っぽい分野を想定している。

どちらの職務も製品開発には必要なのだが、はっきり違う領域を扱わないといけないことがわかる。

プロジェクトマネジメントの方は、ビジネスリクワイアメントとデリバリーというふうに分けてみた。簡単に言うと、要件定義と進捗管理だ。WhatとHowって言ったほうがわかりやすいかな。

責任を負う期間も違っていて、プロダクトマネジメントはプロダクトのライフサイクルの終了までずっと面倒を見るイメージ。プロジェクトマネジメントはあくまでプロジェクトの終了までであって、プロダクトのライフサイクルにおける一部を担うのみ。


パッケージ・Webサービスの企業とSI企業をあえてマッピングしてみるとこんな感じだろうか。
f:id:ikeike443:20140713000850p:plain

SIの場合はプロダクトマネジメントという観点はあまりまたはほとんどないというのは納得していただけると思う。
パッケージ・Webサービス企業においてはアジャイル開発、特にスクラム(またはスクラムっぽい何か)を採用している企業が多いと思うので、プロダクトオーナー、スクラムマスターという用語を当てた。ここはウォーターフォールの場合はプロジェクトマネージャーが一人で兼ねるところだと思う。
表では、SI企業=旧来型のPMみたいに書いてしまったがこれは便宜上で、実際にはアジャイル開発をしているSI企業もいれば、ウォーターフォールで製品開発をしているパッケージソフトやWebサービスの企業も存在する。わかりやすく書いているだけなので、自分のところは違う、みたいに怒らないで欲しい。

ただ、おそらくなんだけど、パッケージ・Webサービスの企業においても、プロダクトマーケティングにレスポンシビリティを持って働いている人はほとんどいないのではないだろうか。
ほとんどの場合この領域はマーケティング部門が担当していることが多い。マーケティング部門はそのプロダクト専任のマーケティング担当では無いので、どうしてもマーケティングプランは通り一辺になってしまう可能性がある。(もちろん優秀なマーケの人が多い会社であればそれでも事足りることはあると思う)

このへん、みんなどういうふうにしているんだろう、ってのがすごく気になる。こんな話ができる勉強会とかあったら出てみたいなあと思った。

プロダクトマネジャーの教科書

プロダクトマネジャーの教科書

Inspired: How To Create Products Customers Love

Inspired: How To Create Products Customers Love

https://itunes.apple.com/jp/app/inspired-j/id532852475?mt=8
inspired-j

inspired-j

  • Mare Azzurro, Inc.
  • ビジネス
  • ¥1,400

*1:いわゆる受託開発や企業内システム開発のことを指している模様

*2:プロダクトマネジメントとプロジェクトマネジメントの違い

*3:表が画像になってるのは特に意味はない。。なんとなくCacooでかいてpngに書きだしたからこうなっただけ

#DevLOVE でお話させて頂きました

さる6月19日(木)、DevLOVEさんのイベントにお呼ばれして少しおはなしをしてきました。
進め、現場のチーム開発 〜チーム開発実践入門〜


資料は下記になります。


かんたんに本の紹介と、チーム開発にまつわるあれこれをお話させていただいたあと、会場の皆さんとディスカッションをしました。

来場された皆さんに聞いてみた印象としては、バージョン管理、チケット管理は行なっている現場が多いようでしたが、CIについてはほとんどやっていない、ユーザー受け入れテストの自動化についてはほとんど誰もやっていない、という傾向のようでした。

発表でも話しましたが、開発ツールをどう使うか、というのはプロジェクトを改善するための数ある手段のうちのごくごく一部ですし、必須のものでもありません。ツールを使うことが目的化してしまうことは避けないといけません。

とはいえ、最低限のレベルというのはあると思っていて、バージョン管理をする、チケット管理をする、CIをする、というところについては、ほぼ全ての現場において必須のプラクティスだと思いますし、拙著を参考にしていただけるといいなあと思いました。

なかには一切のソフトウェアダウンロードを禁じられているとか、15分毎に強制的にネットワークが遮断される環境にいるとか、チーム開発の改善どころの話ではない現場の方もいたようでした。

ここまでひどい閉鎖空間になってしまうと、どう言ったらいいか正直私にもわかりません。。それでその会社の業務が本当に成り立っているのならいいのかもしれませんが。。

そういう現場において、いかに改善のための予算取りをするか、稟議を通すか、あるいはダマでこっそりツール導入や改善を進めて既成事実を作りに行くか、みたいなところは本書には入れられてないのですが、いずれ別の機会にでも、語る場を持てればなあと思っています。

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

増刷しました 『チーム開発実践入門』

ありがとうございます。みなさんのおかげで早くも増刷となりました。ビリオネアになれそうです! 住宅ローンの返済に充てたいと思います!!!!

いろんなかたにブログで取り上げて頂きました。みなさん楽しんで読んでいただけたようで、なによりです。ありがとうございます。
http://www.slideshare.net/yuishikawa/2014-0428-teamdevelopment
http://garbagetown.hatenablog.com/entry/2014/04/16/145448
http://shibayu36.hatenablog.com/entry/2014/05/01/100003
http://qiita.com/takachan/items/8cd832bba9779390c6d8
http://blog.niwaringo.com/entry/2014/05/21/234328
https://nulab-inc.com/ja/blog/backlog/team-development-book/
http://webcreator.weva.jp/book/1039
https://medium.com/@urasoko/24ed1e16682a
http://kt-kiyoshi.com/wp/2014/05/18/team_development/
http://masutaka.net/chalow/2014-04-26-1.html
http://memo.sanographix.net/post/84010382417
http://daipresents.com/2014/team-dev/
http://blogs.yahoo.co.jp/tnakita/15441587.html
http://netmark.jp/2014/05/teamdev60.html

上記ブログの中にも書いてくれている方がいらっしゃいますし、私の知り合いにも言ってくれた方がいたのですが、この本は非エンジニア(デザイナーさんだったり、企画担当だったり、発注者だったり)にとっても、チームでなにかモノを作る際のヒントを感じていただけているようです。

この本はチーム開発に関する先端的なことが書いてあると言うよりは、2014年現在におけるある種スタンダードなんだけど、どこにも体系だててまとめられていないものを一つにまとめた的な本です。

チーム開発の今を知るにもいいですし、また若手エンジニアの教育用にも適しているかなと思っています。

御社の新人研修用資料として大量購入なんていかがですかね!?(ゲス顔

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

ともあれ、ご購入いただいた方、ありがとうございます!

興味があるんだけどまだ買おうかどうしようか迷っているという方、ぜひ本屋などで立ち読みしてみてください!



なお、この本がらみで面白いお話をいくつか頂いています。またこのブログで色々ご報告できるといいなと思っています。

『チーム開発実践入門』という本を書きました

2年くらい前に技術評論社さんから「チーム開発に役立つツールや方法論をまとめた本を書かないか」とお声がけいただきました。

それから構想1年(ぼんやりしてた)、執筆に1年かけて(週末がなくなった)、ようやく4月16日に発売できそうなところまで来ました。

今印刷所でゴインゴイン刷っていると思います。


技術評論社さんのページを見てもらうと、表紙画像もアップされてますね。
http://gihyo.jp/book/2014/978-4-7741-6428-1

Amazonさんにもページができていますが、まだ表画像はアップされてません。

チーム開発実践入門 ~コラボレートを円滑に行うツール・方法論 (WEB+DB PRESS plus)

チーム開発実践入門 ~コラボレートを円滑に行うツール・方法論 (WEB+DB PRESS plus)

目次もまだ公開されていませんが、数日中に公開されると思います。また注意深い人は気づいたと思いますが、技術評論社さんのページとAmazonさんセブンネットさんのページとでサブタイトルが違っています。技術評論社さんのページに書いてあるサブタイトルのほうが正しいです。これも数日中に改まると思います。

執筆にあたって意識していたこと

チーム開発に役立つツールと方法論を一冊にまとめるのってかなり辛くて、詳細に書くと全12巻組みくらいの大長編になっちゃいます。

そこをグググッと凝縮して、300ページちょっとに収めました。なのでツールの使い方にフォーカスを当てて解説しています。ホントはチーム開発を上手く行かせるのに必要なのってツールの使い方だけじゃなくて、チームビルディングの方法だったり、タフネゴシエーションの技術だったり、いろいろあるのですが、そこをあえてツールに絞って書いています。大長編になっちゃうからね。。

ツールに絞ったとしても全6巻くらいにはなるはずのところを1冊にしているので、ツールのインストールの方法や細かな設定方法についてはそれなりに端折って書いています。チーム開発の現在形をざっと概観するための本だと捉えてくれれば幸いです。

総じていうとアジャイル開発の本なのですが、書籍中ではアジャイル開発という言葉はほとんど使っていません。最近、アジャイル開発という言葉にはなんだかスピリチュアルなニュアンスがついちゃったような印象が個人的にあり、出来るだけ避けたかったというのがあります。現実の問題に対処するためにツールを使ってどう問題解決を実践するのか、という話にフォーカスを当てたつもりです。

目次

詳細な目次は公開されるのを待っていただくとして、ここでは大項目レベルでお知らせします。

第1章 チーム開発とは

導入ですね。チーム開発ってどういうもので、どんな問題が起きるのか、どう立ち向かえばいいのか、について触れています。

第2章 チーム開発で起きる問題

チーム開発の現場で実際に起きがちな問題をケーススタディとして見せている章です。
起きる問題の例としては、例えば下記のようなものです。

  • 重要メールが多すぎて優先順位が決められない
  • テスト環境で動かしてみるまで、アプリが壊れていることに気づかない
  • 自信を持ってリファクタリングできない
  • バグの発生時期、修正時期がわからない、追跡できない
  • 開発環境で動くものが本番環境では動かない
  • リリースが複雑で属人的、時間がかかる、よく失敗する

本文ではこの他にも色々、ありがちな問題をあげ、起きていることの解説をしています。そしてこれら問題の解決策となるのが次に続く3章から始まる各章、というかたちです。

ちなみに3章以降は、チーム開発改善の際に手をつけるべき順番に並んでいます。

第3章 バージョン管理

バージョン管理の章です。基本的にGitの話を書いているのですが、バージョン管理システムの歴史についても触れています。ほんの20年ほどで劇的に変わっているのがバージョン管理です。チーム開発の基本となるこのバージョン管理が、いかに変化の激しい分野なのかを知ると色々はかどります。

また、データベーススキーマのバージョン管理(データベースマイグレーションですね)についても触れています。

第4章 チケット管理

チケット管理システムはOSSのものも商用のものもたくさんありますので色々紹介しています。バージョン管理システムとの連携方法も説明しています。チケット駆動開発についても簡単に解説しています。

第5章 CI(継続的インテグレーション

CIについて、主にJenkinsをベースに解説しています。ビルド、テストの自動化の方法、Jenkinsの使い方、Pull RequestをCIする方法(GitHub Pull Request Builder Plugin)も解説しています。もちろんTravisCIにも触れています。
ここまでがチーム開発の基礎となる部分の解説です。ちなみにここまでは私が書いています。

第6章 デプロイの自動化(継続的デリバリー)

デプロイの自動化について、必要性と方法を解説しています。
Bootstrapping, Configuration, Orchestrationの3フェーズに分けて解説しています。
Kickstart, Vagrant, Chef, Capistrano, Fabric, Serverspecといったツールについて解説しています。

クラウド時代のブルーグリーンデプロイメントについても解説しています。また、PaaSを使ったデプロイについても触れています。

この章はシャノンの藤倉さんが書いているのですが、この章が一番大変でした。執筆していた2013年という年はこの分野に劇的な進歩が見られた年で、どんどん変わっていく技術を追いかけながら実践して書籍に落としこんでいくのはかなりの苦労だったと言えます。

残念ながら時期が上手く合わず、Dockerを始めとするImmutable Infrastructureについては、ほんの少し言及するにとどまりましたが、総じてエキサイティングな章になっていると思います。

第7章 リグレッションテスト

最後の章はSelenium1をつかったリグレッションテストの自動化についての章です。時間のかかるSeleniumテストをいかに高速化すればいいのかについて、シャノンの井上さんが書いています。内容としては2年ほど前にJenkinsユーザーカンファレンスにて井上さんが発表した内容がベースになっています。

類似書籍との違い

同じ技術評論社さんから先ごろ出版された『GitHub実践入門』と似ているんじゃないかと思う方もいらっしゃるかもしれません。
確かに一部かぶっているところもあるのですが、こちらの書籍のほうがより広い範囲を扱っている本になります。逆に言うとGitHubについては、『GitHub実践入門』のほうが詳しくわかりやすいと思います。
同じ事は『Jenkins実践入門』や『JUnit実践入門』などについても言えます。

むしろのこの『チーム開発実践入門』という本は、『GitHub実践入門』、『Jenkins実践入門』、『JUnit実践入門』といった書籍の間をつなぐミッシングリンクのような本です。

この本で概要をつかみ、さらに個別の書籍を買って理解を深めることで、バラバラの知識が一つにつながることと思います。

興味の湧いた方はぜひお買い求めを!

発売日は4月16日予定です。

デベロッパーサミット2014 OSSコミッタ大集合に登壇してきました

遅くなったけど簡単に。


先週の13日、Developers Summit 2014:【13-E-1】OSSコミッタ大集合に登壇してきました。

資料は下記です。いろんなOSSのコミッタさんがいらっしゃいます。
https://docs.google.com/presentation/d/1eh7fMYMEUA1CriyUxay4wkYaWtnxLkg0l4jtd9CXLv4/htmlpresent

当日の様子はこちらから:
2014/02/13 デブサミ2014【13-E-1】OSSコミッタ大集合 #devsumiE - Togetterまとめ


元々のこの企画の趣旨はHerokuの相澤さんが下記のように定義してました。

ソーシャルコーディングの台頭によって、オープンソース・ソフトウェアへの貢献は「ふつうの」エンジニアにも解放されました。新機能の開発やバグの修正だけでなく、不具合の報告やドキュメントの修正も、オープンソース・ソフトウェアに対する素晴らしい貢献活動です。誰もが知っている有名なプログラマーだけでなく、デブサミに集まるエンジニアの中にも数多くのオープンソース・ソフトウェアのコミッター/コントリビューターがいます。オープンソース・ソフトウェアへの貢献はわたしたちソフトウェア開発者にとって、もはや特別な活動ではありません。わたしたちがオープンソース・ソフトウェアに対して何か貢献をしたいとおもったとき、今できることがあります。
この企画では、なるべく多くの『人』を紹介することで、もしかしたら「敷居が高い」と感じていたかもしれないオープンソース・ソフトウェアへの貢献を、より身近に感じてもらえたらと思っています。


僕もそのとおりだと思っていて、僕みたいなヘボいプログラマーでもOSSに貢献できる余地はあるんだよということが伝わればいいと思い登壇いたしました。結果、聴衆の方にどう伝わったかはちょっとわかりませんが。。

当日は思ったことをうまくしゃべることができなかったですが、言いたいことは簡単で、

  • OSSにバグを見つけたら報告しよう
  • そのバグを直せるならその場で直してパッチを送ってあげよう
  • ドキュメントに不備があれば直したり整理したりしてあげよう
  • その他なんでも気づいたら手を貸してあげよう

くらいしかないです。

OSSは基本ボランティアベースで(企業が担いでいるものももちろんたくさんありますが)、みんなリソース的にもカツカツの中やっていることがほとんどです。

普段OSSのお世話になっていないソフトウェアエンジニアはいないと思います。普段OSSから受けている恩恵を、なんらかのかたちで少しでも還元していただければ、世界中のみんなが少しずつハッピーになります。

というわけで、OSSに貢献しよ−!

明日のデブサミ2014「OSSコミッタ大集合」に出ます

これです。
http://event.shoeisha.jp/devsumi/20140213/session/394/

よろしく鬼ヶ島っす!(茶魔語