ikeike443のブログ

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

auの誰でも割自動更新には気をつけよう

黙って更新されて、解除料を1万円以上取られます。
2年縛りが解けたあと、ぼやぼやしてるとまた2年縛りになるのでご注意を。
カスタマーセンターに電話して自動更新を解除することはできるっぽいので、早めに確認しておいたほうがいいでしょう。

合法のようですが、黙って更新するのは心象としてはとても悪いですね。

KDDIが逆転勝訴=解約金条項は適法、携帯割引 2年縛り  : キジトラ速報

Jenkins + Maven3.2.1 で IllegalAccessError on AbstractMapBasedMultimap

メモ。時間があるときに調べる。
Maven3.2.1とJenkins1.581のCoreとで依存しているGuavaのバージョンが違っていることが遠因になっていくつかのプラグインが動かなくなっている。(下記参照)
[#JENKINS-22252] Maven 3.2.1: IllegalAccessError on AbstractMapBasedMultimap - Jenkins JIRA

JenkinsでMavenプロジェクトを作って静的解析をしていて下記のようなエラーが出ていたらこの問題に該当すると思って良さそう。PMD, CheckStyle, FindBugs全て同じ。静的解析以外でも問題が起きそうだけど、今のところ聞いてない。

java.io.IOException: Remote call on channel failed
	at hudson.remoting.Channel.call(Channel.java:748)
	at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:168)
	at com.sun.proxy.$Proxy7.execute(Unknown Source)
	at hudson.maven.MavenBuildProxy$Filter.execute(MavenBuildProxy.java:206)
	at hudson.plugins.analysis.core.HealthAwareReporter.registerResultsOnMaster(HealthAwareReporter.java:325)
	at hudson.plugins.analysis.core.HealthAwareReporter.postExecute(HealthAwareReporter.java:316)
	at hudson.maven.Maven3Builder$MavenExecutionListener.recordMojoEnded(Maven3Builder.java:628)
	at hudson.maven.Maven3Builder$MavenExecutionListener.mojoSucceeded(Maven3Builder.java:610)
	at hudson.maven.Maven3Builder$JenkinsEventSpy.onEvent(Maven3Builder.java:306)
	...
Caused by: java.lang.LinkageError: Failed to load com.google.common.collect.AbstractMapBasedMultimap
	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:326)
	at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:236)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:270)
	at hudson.remoting.MultiClassLoaderSerializer$Input.resolveClass(MultiClassLoaderSerializer.java:113)
	... 
Caused by: java.lang.IllegalAccessError: class com.google.common.collect.AbstractMapBasedMultimap cannot access its superclass com.google.common.collect.AbstractMultimap
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:643)
	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:322)
	... 39 more

Workaroundとしては、Mavenプロジェクトをやめてフリースタイルプロジェクトで作るか、Mavenのバージョンを3.0.5くらいまで落とせば一応動く。細かいバージョンの組み合わせは試してないが、まあ3.0.5まで落とせば大丈夫っぽい、という程度の理解をしている。

これ結構直すのは面倒そうだなあ。JenkinsのGuavaバージョンをあげるのか、各プラグイン側でWorkaroundな修正を入れるのか。。

『プロフェッショナルのための 実践Heroku入門』を読んだ

もう2週間も経ってしまったが、RubyKaigi2014に参加してきました。Rubyは全然書いたことないのですが、最近Ruby絡みの仕事をすることになったので行ってみた感じです。

そこでHerokuの相澤さんに買わされたおすすめされた本がこちらです。


これがその時(買った時)のTweet。おっさん二人でむさいですな。。


相澤さんは律儀に僕の本の宣伝もしてくれました! ありがとうございます!!


さてこの『プロフェッショナルのための 実践Heroku入門』ですが、クラウドの利用はすでにしていて、なんだったら他のPaaSも使ったことあるけど、Herokuはちょっとチュートリアルを触ったくらいで細かいことはわかりません、みたいな人にオススメです。Herokuの採用を検討している人も読むといいでしょう。

Herokuをつかって実際にサービスを立ち上げる際に気をつけるべき点や、よく詰まる点などが解説されています。

例えばPaaSならではのタイムアウト制限についても、単純なレスポンスのタイムアウト制限の話から、Herokuの仕組みを知っていないと理解しがたいSlugコンパイル時間の制限、Slugの容量制限の話まで、Herokuの仕組みについて触れながらわかりやすく説明してくれます。

実運用に入れば必ず気になる、カスタムドメインの設定の仕方やSSL導入の際の注意点、Heroku Postgresを使う際のポイントも解説されています。

また7章では実際にHerokuのテクニカルサポートをされている織田さんが、ありがちなトラブルについて具体例を上げながら解説してくれていて役に立ちます。

最後の9章はHeroku創業者の言葉であるThe Twelve-Factor Appの全訳です。全訳はWebでも読めますが、改めてこの本につけていることに大きなメッセージを感じます。
これはHerokuを使う使わないに限らず、モダンなソフトウェアが持っているべきものだと思います。熟読しましょう。

僕自身は前職ではHerokuもよく使っていましたし、Herokuを使って立ち上げたサービスとしては日本では結構早い時期に属するものに関わってたなあと今思い出しました。(更にいうとPlay2+Scalaだったしね)

転職してからはHerokuはじめいわゆるXaaSなものとは全く疎遠になりましたが、また触れる機会を持ちたいものです。。


最後に僕の本のアフィも貼っておきます。一緒に読むと効果的ですよ!

#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)