けんちゃんくんさんの Web日記

あけおめ

あけましておめでとうございます!今年もよろしくおねがいします!

そういえば大学から院のころは、高校の同級生何人かとスキーに行っていたんだけど、社会人になって自然消滅してしまった。みんな元気かなぁ。

今年は手帳を使おうと買ってみたので、目標や計画はそっちへ書いてみた。会社では熊谷代表の使っている(作った?) リフィルが配られるんだけど、今年これをちゃんと使ってみようと、年末年始を使っていろいろ書いてみた。こういうのって、どういう方法でもいろいろ試してみると、新しい発見があるのでたくさん試してみるのがいい思う。一般販売は クマガイ☆スタイルSHOP 【夢手帳】手帳・システム手帳の公式販売サイト からどうぞ。

ソシャゲガチャはまずまずといったところだったけど、家であけたフォーチュンクッキーからはなかなか考えさせられる言葉がでてきた。

今年は慎重かつ大胆にやっていこう!

2015ふりかえり

仕事について

今年はペパボに丸1年いたということになるんだけど、ようやくペパボらしい仕事ができるようになったのではないかと思う。

一つの理由は、今年の重点施策の一つであるプライベートクラウド基盤に関われたこと、もう一つはペパボの歴史あるサービスのミドルウェアバージョンアップを、予定通りとは言えないレベルであったけど、ある面ではやりとげられたということだろうか。(バージョンアップの話は、2016年にテックブログで公開予定である)

また、 ペパボ プロダクトオーナーシップ 勉強会 のような活動をはじめることができたのも、自分の活動を見る人が見てくれているということなので、話が来たときは素直に嬉しかった。

コードを書くということ

散々なかんじなのでなんとかしましょう。

発表とか

社外のみで8本、社内を入れると10本ちょっとくらい。予想外に注目された資料もあったりしておもしろかった。ただ、隙間産業的に社内の人がいかないところが多かったり、CFPがあるようなところでは普通に落ちてるので、来年は正攻法ででかいところで発表したい。そのためにも(ry

家庭のこと

今年は特に大きな変化はなかったと思う。一方、来年は息子が小学校…学区ロックイン問題やいろいろなしがらみが見えてきたので悩ましい限りである。住宅ローンカジュアルトークスの開催を待つ。

まとめ

来年はちょっと大きな変化がある予定(辞めません!)なので、今後ともみなさんよろしくお願いします!

歯医者納め

今年の夏くらいから、そろそろ親不知をどうにかせんといかん(完全に虫歯だし…)と思って一念発起して行きはじめた歯医者。

途中2ヶ月くらい行けなかったんだけど、歯石のクリーニングと虫歯治療からということで、結局今年は銀歯4本くらいでフィニッシュ。来年は抜いてもらうぞ!

#kanemochi 的にはセラミックらしいけど、清貧の心を忘れずに銀歯にしています。

というのはまぁ半分冗談だけど、セラミックでも銀歯でも、結局はメンテナンスが必要だし、医療も日々進歩しているので、取り返しのつく範囲で保険適用されてるやつでまわしていくのがいいと思っているのでありました。

猫の予防接種2days

毎年恒例猫の予防接種2days。

動物病院までは徒歩で片道15分くらいなんだけど、5キロくらいの荷物を持って、息子の相手をしながら2往復するのはなかなかよい運動になる…

今年は空いてたのでよかったけど、運が悪いとそこから1時間待ちになるのでほんとうにつらい。

そういえば、もう上の子は7歳で、そろそろ健康の事を考えてあげないといけないお年頃なのだなーと。

そんな心配をしていたら、なんと下の子が前年比1kg増でびっくり。たしかに動かないからもうちょっと遊んでやらないとだめだ…

2匹とも今年は健康に過ごしてくれたので、来年もそんなかんじでよろしくおねがします。

忘年会week

今年はこの木金の2回でフィニッシュの予定。

木曜は社外の人と新宿、金曜は技術部のみんなと渋谷。

まだ今年中にやらないといけないことがけっこうあるんだけどがんばっていこう!

2015年12月3日 のくんさん

午後は外でミーティングだったので、その近くお昼が食べられる場所を探していたところ 札幌スープカリー 東京ドミニカ新宿店(新宿三丁目/スープカレー) - Retty があったので行こうという話をしてた。

実際は、行ってみたら満席で泣く泣く別の店でイエローカレーを食べた。それそれで美味しかったのだが、「熱いので気を付けてください」という忠告を軽く考えていたため、口内を火傷することになった。つらい。

2015年12月2日 のくんさん

今日はPHPとTreasureDataいじり。

TDでどばっと出力した25万行のCSV、インターネットの情報によるとExcelならそれくらい開けるそうなのだけど

  • Google Driveのスプレッドシートはフリーズ
  • Numbersは65535行目以降を勝手に捨てる

という状況なので、vimで編集したり、sortコマンドでソートしたりした。便利。

TDにデータがたまってくるといろいろ弄りたくなってしまって気付くと時間がたってるので、毎日タイムボックスでちょっとずつ触るほうがいい気がしてる。

帰ってきてから 【Rubyist応援企画】リファクタリングのBefore→Afterを投稿して、回らない寿司を当てよう! - Forkwell Jobs のお題に投稿したり。テスト無しでリファクタリングってどういうことなのか意味がわからないので、一応テストも置いときました。

平鍋さんを囲む会

永和システムマネジメントの社長に就任した平鍋さん を囲む会に行ってきました。

昔のオブラブ懇親会かなと思うようなメンバーで、昔話や今の話をいろいろできて楽しかったです。

平鍋さんからは、自分のプログラマ人生に計り知れない影響を受けているので、こういう会に呼んでいただけてとても嬉しかったです。幹事の木下さんありがとうございました!

散髪ログ

思いだしたのように。前回9/12で丁度2ヶ月。

Hello Nexus 5X

ついに待ちにまったNexus 5Xです!家族体調が不良だったのでお休みを家でやれることやってたところ、着弾しました!

とりあえず開封して、Galaxy Nexus、Nexus 5、Nexus 5Xと並べて写真をとって、各種アプリへのログインマラソンをして今にいたる感じです。

真ん中のNexus 5が重症を負ってからは、Galaxy Nexusでしばらく凌いでいたのですが、ひさびさの快適なAndroid生活で満足です。アプリが落ちない!起動が速い!Galaxy Nexusを使っててわかったのは、ホームアプリが重いってことですね。

ざっと感想を箇条書きで。

  • 箱は正方形に見えて実は長方形
  • 付属の充電ケーブルがUSB TypeC-TypeC
  • 指紋センサーのつもりでカメラに指を押しつける儀式
  • 指紋でのロック解除はディスプレイ消えててもできて便利
  • 指紋センターの位置に合わないとスパイダーの原因になりそう…
  • ホームが5x5になったおかげでだいたい2枚でことたりる
  • ゲームの類はだいたい快適に動く
  • フレームはNexus5よりしっかりしていような手ざわり

ケース付けたくないけど、Nexus 5のような思いをしたくないからつけようかなぁという気分…とりあえず周りの人の報告待ちです。

Stack Overflow DevDaysに参加しました

好きなJoel on Softwareのエッセイは「ジョエルテスト」と「射撃しつつ前進」です。こんばんは。

このイベントのことを知ったのはたしかJoelさんの以下のツイートだったと思います。

これを見て、もう行くしかないでしょということで気付いたときにはアンケートに「発表もしたい!」と書いていました。

前夜祭の話

登壇者の人は、なんと前日にJoelさんとご飯を食べるというイベントがありました。

Joel on Softwareのサイン会がはじまったり、今日のトークやQAコーナーにも繋がるようなお話がいろいろ聞けてとても楽しかったです。

実は、登壇者もかなりの人同士も初めてお会いする人が多くて、かなり独特な雰囲気のディナーでしたw

前夜祭から続くJoelさんの話

前夜祭、当日のトーク、そして急遽行なわれたQAコーナーでは様々なお話がありましたが、自分が感じたメッセージは

  • プロダクトとその周辺のコミュニティをマネジメントすること
  • コニュミティとプロダクトのデザインは密接な関係がある

という2点でした。

対象がエンジニア向けのサービスなので、より身近に感じられるというのもあるかもしれませんが、どんなプロダクトでも共通する話なのかな、と。

また、同じ場にQiitaのyaottiさんがいて、2つの似てるようで違うプロダクトのデザインと、そのコミュニティについての対比があったからこそ、強く感じたように思います。

私の話

今回は、資料がほぼ背景文言集(画像集ですらない…)になってしまったのですが、終わってから声をかけていただけたりしたのでよかったです。

口頭では言いましたが、たぶん社内で一番評判がよいのが「狩野モデル」の話で、今回のイベントでの反応も同じような感じでした。

このあたりの分野って、要求工学になるんですかね。英語版のWikipediaでは狩野モデルから派生した分析のモデルがいくつか紹介されているので、ここが響いた方はぜひ類似の技法や研究も調べてみるとよいのではないでしょうか。(そして今度は教えてください!)

おわりに

今回、Stack Overflow の日本での初めてのイベントということで、日本担当のメシエルさんやスタッフの方は大変だったと思いますが、私個人としてはとても充実したイベントでした。ありがとうございました。

もし、第2回があるようでしたら、また何らかの形でお手伝いしたいので今後ともよろしくおねがいします!

息子が風邪をひいた模様

昨夜からあまり食欲がないなぁとは思っていたけど、今朝も朝ご飯をちょっと残して登園したんですが、すぐ幼稚園から電話がきて奥さんが迎えにいったらしい。

ウィルス性の胃腸炎らしいんですが、土曜日には運動会をひかえていて、子供ってそういうときに風邪ひくよなーと思ったりした。(自分も結構そうだった)

結構練習もしてたっぽいから土曜までに元気になるといいなぁ。

GMOグループ全体ミーティング

GMOグループでは、四半期毎にグループ全体のミーティングがあるんですが、その中で熊谷代表の話が毎回とてもおもしろいんです。

今回は孫子の一節である「拙速は巧遅に勝る」というのが自分含めて沢山の人に響いたように思いますが、エンジニアとして「拙」「速」それぞれのレベルを上げていかないとな、という思いを強く感じました。

完璧でなくても速いほうがよい、でも同じ速さならレベルが高い当然よいわけです。

自分が速くできることのレベル自体を上げていきながら、全体レベルを上げていくための仕組み作りにも積極的に取り組んでいけるというのが、技術基盤チームに所属しているメリットでもあると思うので、もっともっとがんばるぞ!という気持ちになったのでした。

MNPに3日もかけて得た知見を共有します

いろいろな事情があってdocomoからみおふぉんにMNPするのに3日かかりました。そこで得られた知見を共有しますので、3キャリアの2年契約切れのタイミングを狙っている人の参考になれば幸いです。

前提

今回MNPしようとしたのは奥さんの使う、本人名義の回線でした。 これのせいでここまで面倒になるとは、当時はまったく想像していなかったのですが…

みおふぉんファミリーシェアプランへの2枚目MNPは事前にプラン変更が必要

当初の予定では、私の契約しているみおふぉんのファミリーシェアプランへの2枚目MNPでした。しかし、これは早々に諦めることとなりました。

みおふぉんのサイトには当然書いてあるのですが、 まず問題になったのは MNPの受け入れと同時に契約プランの変更はできない という点です。

みおふぉんの場合は契約プラン変更は 申し込みの翌月1日から反映 という仕組みになっています。 このため、現在の契約がファミリーシェアプラン以外の場合は、MNPをする予定の前月 までにプラン変更を申し込んでプランを予め変更しておく必要があります。

このことを完全に失念していたため、私の回線は当然ミニマムスタートプランのままだったのでした。

ただ、いろいろ調べてみたところ、我が家の場合はおそらくミニマムスタートプラン * 2のほうがちょっとだけお得だろうということがわかりました。

ミニマムスタートプラン * 2 回線とファミリーシェアプラン SIM 2枚の比較は以下の通りです。

ミニマムスタートプラン * 2 ファミリーシェアプラン
料金 3200(1600 * 2) 3960(3260 + 700)
データ量 3G * 2 合計10G
同一プラン内通話割引 なし あり(10%)

いかかでしょうか。ファミリーシェアプランの回線間の通話が少なく、かつ1回線あたりのデータ量が3Gで間に合っている場合、ファミリーシェアプランではないほうがちょっとだけお得です。

というのを調べて自己正当化できたところで、次の問題を見つけてしまったのでした。

みおふぉんのビックカメラ店頭での契約には写真付き身分証明書が必要

ファミリーシェアプランへのMNPはもうあきらめていましたが、その過程で新たな問題を発見しました。

それは、ファミリーシェアプランへの2枚目MNPには、 MNPする回線の名義がみおふぉんを契約している人の名義と同一 でなければならないという点です。

これを知ったところでもう諦めているので関係はないのですが、回線の名義 という点に不安を覚えました。

みおふぉんへのMNPは、奥さんの回線ということもあり、ダウンタイムを極力短くしようとビックカメラの店頭での手続を予定していました。その手続を調べているときに大変な記述をみつけてしまうのです。

それは、本人確認書類の条件です。 みおふぉんのビッグカメラ店頭での契約の場合、本人確認書類は 写真入りの身分証明書 が求められています。

そして、なんと奥さんは免許証などを持っていないため、このままでは本人確認ができずに契約ができません。

そこで、まずは今のdocomo回線を私の名義に変更することを決めました。

docomoの名義変更はほぼ新規契約でドコモクラウドのデータが消える

docomoはもう出ていく身分なので、あまり時間をかけずにさくっとやりたかったのですが、ここで問題になったのは名義変更の際に発生する手続とシステム上の仕組みです。

前述の問題がわかったあたりで、いくつかのアクシデントが発生していました。

  • 奥さんが体調不良で外に出れそうにない
  • 問題がわかったのが日付がかわってからだったので、docomoの来店予約ができなかった

後者は時間の問題だけだったのですが、前者は致命的な問題になってしまいました。

ちなみに、docomoの契約者の名義変更は以下の書類があれば現在の所有者と後の所有者が別になっていても手続自体は可能です。

  • 委任状
  • 現在の所有者の身分証明書
  • 変更後の人の身分証明書
  • 変更後の人名義のクレジットカード

問題になったのは、名義変更によって発生するdocomo IDの変更でした。

docomo IDが変更になると、まず今使っているメールアドレスが新規に発行、つまり変更になります。そして *ドコモクラウドに保存されているデータ全て消えてしまいます。 *

これがどれくらい影響があるかというのが、本人のいないところでは判断できずに一旦退散することになったのですが、実際に問題になりそうだったのは過去のメールデータでした。

ドコモの標準メーラーだと、全てのメールをローカルには保存せずに古いものはドコモクラウドからとってくるような動きをするので、これをまず全部ローカルにもってきてバックアップをとりました。

名義変更の当日はMNPの予約番号の発番に制限がある

店頭で聞いた話では、名義変更当日のMNP予約番号の発番は、変更前後の人に両方確認がとれないとできないということでした。

実際にドコモのサイトからするしようとするとエラーが発生して、翌日にもう一度やったらうまくいきました。

実際の条件がどうなっているのか、151に電話すれば発番できるのか、など詳細な検証結果が待たれます。

まとめ

だいたい見出しを読んでいただければわかる通りですが、

  • MVNOの価格の安さには当然理由があるのでちゃんと手続を調べる
  • 自分名義ではない回線を扱うときはちゃんと調べる
  • docomoの名義変更はほぼ新規契約である
  • docomoの来店予約は神機能なので絶対使うこと

というあたりの知見がたまったので、よかった(?)ように思います。

みなさんも充実したMNPライフを。

ドキュメント トヨタの製品開発を読みました。

夏休み(もう2ヶ月近くたっている…)の課題図書であった ドキュメント トヨタの製品開発: トヨタ主査制度の戦略,開発,制覇の記録 の読書感想文です。

あとがきにある通り、自動車開発の課程と、その中における主査という役割について驚くほど詳細に書かれており、プロダクトマネジメント、プロダクトマネージャについて考える上でとても参考になりました。

本書は、製品開発の実像を正しく理解してもらうために、また研究・教育の参考資料とするために、自動車の製品開発を全体像から活動細部に至るまで詳述したものである。

一方で、詳細に踏み込んでいるが故に、自動車の仕組みや業界を知らないと置いていかれてしまう部分もそれなりにあるので、そういった部分を流しながらトヨタの主査の仕事に着目して読むとよいのではないかと思いました。

主査の責任と守備範囲の広さ

序章に「担当車種に関しては、主査が社長であり、社長は主査の助っ人である」という一文があるように、主査の守備範囲はあまりにも広い。

私がエンジニアであるために、エピソードの中での主査の技術的な知識や能力の高さに驚くばかりでしたが、おそらくマーケティングや企画の人が読むと、そういった面での主査の能力の高さというものに気付くのではないかと思います。

当然それだけ広い範囲をただ一人ではカバーできないので、「主査付き」と呼ばれる「主査と同一人格」と見なされるメンバーとチームを組むという話で、この「同一人格」というのがとても力強く感じました。

また、主査付き以外の人には一切の人事権を持たず、説得でのみ人を動かさなければならないという点においても、技術やマーケティング、企画の能力だけではなく、思考力やヒューマンスキルなど、本当に幅広い能力を高いレベルで求められています。

エンジニア目線で熱いと感じたポイント

実際の設計問題は、力学系、環境条件、深が複雑すぎて、簡単な仮定のもとに成り立つ工学理論では解決できないが、工学理論の根底にある論理に頼れば、勘に頼るより、トラブルの少ない解決策を得やすい

現実社会は厳しいんですが、でもそのよりどころは根底にある理論なことが多いですよね。

設計者はまず性能・品質目標を、その後に原価目標と重量目標の達成を目指す習性があるが、それでは背反する三つの目標の同時達成はますます難しくなる。初めから三つの目標達成を同時進行させる以外方法はない。

これは本当に難しいですよね。複数の相反する(と感じる)目標があるときに、どれか一つを達成させるところから初めてしまうと、その時点で視野を狭めてしまうが可能性があると感じているのですが、似たような話なのかなと思います。

発売直後の品質問題は早期発見し早期対策しないと、新商品に回復不可能な致命傷を与えかねない。

Inspiredでも言われていたことなので心に刻みます。

新商品がヒットしなければ製品開発は成功とは言えない。

はい!がんばります!

勝ち続ける製品開発グループは多くの協力者を得てますます勝ちやすくなり、負けた製品開発グループは多くの協力者を失い再び勝つことが難しくなる。

ここまでストイックな場合は少ないとは思いますが、一度勝つと次も勝てる可能性が高いというのは、資金面も、メンバーの自信という面でもそういう側面があるだろうなとは感じますよね。

顧客は、造ることにかけては素人でも、買うことにかけてはプロなのだ。

この本のなかで一番ささった一文な気がします。顧客もプロなのです。

商品が顧客ニーズに合っている、合っていることを顧客が理解している、お買い得感がある、ことも必要不可欠である。

「ニーズに合っていることを顧客が理解している」というのはハッとさせられました。顧客が「理解」できるような仕組み作りが必要なんですね。

セールスが気づく前に発見し、顧客が気づく前に対策を終えたい。

こういうペースで問題を解決していきたい!

おわりに

近年のIT業界におけるプロダクトマネジメント機運の高まりの根底には、トヨタ生産方式とその主査制度があるのは間違いないでしょう。その中でも主査という役割の具体的な実例が書かれている数少ない書籍ですので、そういった分野に興味がある人は自分の立場や役割と比較しながら読むと沢山の学びがあるのではないでしょうか。

XP祭2015でLTをしてきました

タイトルは「俺達もプロダクトオーナーシップを磨きたい!」ということで、最近各所で話題になっているプロダクトマネジメントやプロダクトオーナーシップについて、社内でやっている勉強会の活動報告をさせてもらいました。

今回のLTは古きよきLT、ちょっと懐しい王道のLTを目指してスライドや流れを作りました。

ちなみに、たぶん界隈の人とはよくお話させてもらっているとは思うのですが、XP祭への参加は初めてだったので結構緊張していました。 しかし、LTで狙い通りに拍手や笑いがでたときには、嬉しいような安心したような気持ちになりました。聞いてくださった参加者の皆さんありがとうございました。

ただ、写真を見てもわかるように、ほとんど下を向いてしまっていて、余裕のなさと練習不足は隠せなかったようですw

ペパボプロダクトオーナーシップ勉強会について

さて、この勉強会についてですが、「プロダクトオーナーシップ勉強会」という名前は想像の通りPOStudyから(勝手に)いただいたものですが、自分含めて参加者の人からはとても親しみのある、大事な名前になっているように感じています。

プロダクトマネジメントやプロダクトマネージャというと、一見するとかなり敷居が高く、かつそういう役職の人向けの勉強会に見えてしまいます。しかし、「プロダクトオーナーシップ」という言い方には、職種を限定しない、プロダクトに関わる人全員が身に付けておくべき考え方やスキルというような印象を受けます。 (スライドにあるようにそれでも敷居の高さを感じてしまうというのはあると思いますが…)

その意図通り、プロダクトオーナーシップ勉強会には様々な職種の人が参加してくれており、それ故に書籍に書いてあることを自分事として捉えることができ、様々な立場から見た意見や考え方を知ることができているのではないかと思います。

一方で、この活動を通してサービスや組織の改善、さらには売上利益をバーンとするところまではかなり距離があるので、今後はそこを少しずつ詰めていく活動もやっていきたいなと思っているところです。こちらの活動はあまり外にはだせない可能性もありますが、可能な限りオープンにしていきたいと考えていますので、ペパボ プロダクトオーナーシップ 勉強会 をたまに見ていただけると嬉しいです。

LTについて

ちょっとだけ今回のLTをする上で考えていたことを書いておきたいと思います。

勢い重要

Lightning Talksってやっぱり勢いが重要だと思うんですよ。一般人でも勢いを簡単にだせる方法としては、とにかくスライドを早くめくるということです。

そのためにはとにかく枚数を稼ぐ必要があるので 高橋メソッド をベースとすると、文字も大きさも相俟って勢いを感じさせることができると思います。

今回は約80枚のスライドだったので、平均すると3-4秒で1枚をめくらないといけない計算になるので、これくらいあるとまぁまぁ勢いをもって進めることができると思います。

ただ、実は最後のアンケートの紹介にはいるときに時計をみたところ、まだあと1分以上あってけっこう焦っていましたwあとは流してゴールだという想定だったので。

笑い重要

真面目なので 笑いをとるのが苦手なのと、hitodeくんさんの

おもしろい話というのは受けを狙って変な話をするということではなくて、興味深い話をするということで、アニメの絵とか貼ればよいというものではない。 プレゼンテーション - hitode909の日記

これがまさに本当にそうだと思っているので、普段はネタのようなものは避けています。

ただ、XP祭のLTという場を考えると、そこで求められている物の一つには「笑い」も含まれているだろうなと勝手に想像して、今回は多少ネタを入れてみました。 当然ですが、過度にコンテキストに依存したり特定の誰かを不快にしてしまったら、多数が笑っていてもそれは失敗でしかないので、それだけは気をつけたつもりです。もしこれでも不快に思った方がいましたら、本当にごめんさい。

ちょっとは役にたつ

私の人生初のLTはノルディックスキーに関するLTでした。

これくらい意味がないやつだとそれはそれでいいかもしれませんが、さすがにもう3X歳の人間がなんの役にもたたないただ笑えるだけのLTをしてもしょうがないので、多少は誰かの役に立つ話がしたいですよね。

今回のLTでは、勉強会のやりかたとその資料を公開している点、こういう活動を通して参加者がどう感じているかを持って帰ってもらって、もし同じような課題感を持っている人の役に立てばと思っております。

時間内に終わらない

これが本当に大事です。銅鑼を叩かせてあげましょう。

しかしここには一つ落とし穴があって、結論を最後にもっていくと結論が言えなくなってしまいます。先人達はここでも解決方法を編み出していて「大事なことは最初に」というメソッドです。

今回の私もそれにならって、一番伝えたい https://bit.ly/join-pmjp の紹介とPOStudyへの謝辞を最初にもってきています。

もう一つ確実に時間内に 終わらせない ために、後半に情報量の多いスライドをもってくるということをやっています。

まさにアンケートの回答の部分ですね。もし時間があまったらここを深掘りして話す、時間がなかったら「資料は公開するのであとで見てください」と流す、こうすることで最後の時間を調整できるように組んであります。

ただ、実は最後のアンケートの紹介にはいるときに時計をみたところ、まだあと1分以上あってけっこう焦っていましたwあとは流してゴールだという想定だったので。

上でこのように書いたのは、ある意味想定内だったのですが、想定内とはいえ多少は焦りますw

おわりに

というわけで、今回のLTの内容に関する補足と、ネタバラしでした。みなさんも楽しいLTライフを!

散髪ログ

一回分記録が漏れてる気がする。

XP祭なので散髪。たしか2ヶ月ぶり。

論理削除 Casual Talks #1という夢を見たんだ

それは前職のころ、今回の登壇者でもある @moro の発表にもあるような「要件としての論理削除はない」ということに熱く語りあったりしていたとかいなかったとか。

そして、ある日私が論理削除つらいということをつぶやいたところからこの企画は動きだしました。

このときは半分冗談で、いつか内輪で集まってやれたらいいかなというくらいだったのですが、今年の春にJxckさんの RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita をきっかけとしてインターネットで論理削除が盛り上がったこと、所属する組織から技術イベントをやっていこうという機運が高まっていたこと、この2つがちょうどいいタイミングで重なって、これはやるしかないなと思ったのでした。(とはいえ、Jxckさんのエントリからは半年も経ってしまっていますが…)

@t_wadaさんの全体像と総論(と思ったら予想以上に踏み込んだ内容でおもしろかった!)から、yoku0825さんのDBAからみると「毒を食わらば皿まで」という話。@misoobuさんからは論理削除をいくつかの方法で実装してきた歴史と、それを踏まえて削除ログという形に落ち着いているという生の声を、moroさんからはアプリケーションの要件定義や設計フェーズでの考え方を示していただき、gyugyuさんからはDBMSの外にある論理削除という感じで、登壇者の方々は発表内容のユニーク制約に苦労したようですが、それぞれが伝えたい重要なメッセージには特徴があったように思います。こんなテーマのトークを引き受けていただいてとても感謝しています。

懇親会では、Oracleと札束では我々が相手にしているような論理削除は問題じゃないのではないかという話や、実はあの発表の裏にはアレな事情があってとか、発表内容にちなんだより深い話ができてとても楽しかったです。

今回こんな冗談みたいなイベントができたのは、本当に登壇者の方と参加者の方(とスタッフとして手伝ってくれた同僚と、懇親会費用をサポートしてくれた所属企業)のおかげですので、本当にみなさんありがとうございました。

もし第2回(?)があればまたお会いしましょう!

第3回ペパボテックカンファレンスでE2Eテストについて発表しました

今回は、今携わっているブログサービスのサーバ移設について、いろいろやっている取り組みの一つを紹介させてもらいました。

自然言語でテストコードを書くというの、一時期のブームは過ぎ去って若干のオワコン感がありますが、メリットも十分あると思うのでこれを機に見直してくれる人が増えるといいなと思っています。

これって本当はDDDのユビキタス言語とも結び付けて議論したいところなのですが、そっち方面の学が足りないのであえて入れずに発表しました。また同じテーマで発表するときまでに勉強しておきます…

質疑や懇親会でいろいろお話させてもらったので、そのあたりをせっかくなので文書化しておきます。

  • Q. 自然言語のテストコードを複数人メンテナンスしていくのは敷居が高いように感じるがどうか
    • A. まずは自然言語としての外見を揃える。自然言語で不自然な言い回しがないようにstepを作って、内部はプログラマががんばる。
  • Q. 350項目もあると資産価値の高いものから低いものまでありそうだが、どうやって選定したか
    • A. 元々のサービスに詳しかったわけではないので、わかりやすくてそのサービスの肝になる部分を最初にやった。その後、技術的に難易度が高そうなところをバランスよく入れていった。
  • CucumberとTurnipを比較すると、やっぱり正規表現でマッチさせたいことがあるし、stepが充実しているので最初はCucumberのほうが使いやすいかもしれない。ちゃんとメンテされてるんで。

イベント全体のこと

あれ?これuzullaさんのイベントだったっけ?というくらいuzullaさんのイベントだった…(自分含めて)固くなりがちなところで、休憩の前に入るLT(と30分トークw)はとてもいいスパイスになっていて、殆どの人はuzullaテックカンファレンスだと勘違いしてしまったのではないだろうか。

これは完全に我々の力不足としか言いようがないので、どんどん場数を踏んでがんばっていくしかないですね。ネタに走るのではなく、興味深い発表しながら聴衆に自分を印象付けていくというのは本当に難しいので、精進してまいります。

雨の中来てくださったみなさんありがとうございました!

YAPC::Asia 2015 に船で行く

大切なこと : 8/22(土)は水上バスが運休です!もうYAPCには水上バスでは行けません!

今朝、YAPCどうやって行こうか考えてたときに、「浜松町から船でいけるよ」というタレコミがあったのでこれは最後のYAPCに相応しいと思い、水上バスで優雅に会場入りしました。

だれか一緒に行かないかなーと思ったけど、社内の人だれものってきてくれなかったのでボッチで行きました。1人でも最高のユーザ体験でした。

水上バス乗り場までは浜松町から徒歩10分弱、水上バスはお台場を経由するので30分くらいでした。他にはほとんどだれも乗ってなくて410円でプチセレブ感をあじわえるし、これ平日にお台場いくときはみんな使うといいのではないでしょうか。

これからは水上バスの時代!!!

大切なことなのでもう一回書いておきますが、8/22(土)は水上バスが運休です!もうYAPCには水上バスでは行けません!

2015/07に読み終えた本

今月は3冊、スクラムゆっくり読み過ぎた感。鈴木さんも面白くてかなり考えながら読んだということはあるけど、ほんとに本読むペースが遅すぎる…

shucreamの本棚 - 2015年07月 (3作品)



powered by booklog

「エンジニア実績システム」が導入された

「エンジニア実績システム」を導入した - delirious thoughts にあるように、ペパボにも「エンジニア実績システム」が導入されました。

一通りの情報を入力し、自分のアウトプットのポートフォリオして見てみると

  • 総数や順位的なものは職位としてはギリギリ合格点かな…
  • それなりにレアな実績を持っていた
  • 発表やブログなどの実績はそれなりにあるが、プロダクトの開発やサービスの運営といったところがまるでだめ

ということがわかり、売れないIT芸人であることが可視化されてつらい気持ちになりました…がんばろ。

また、他の人の実績や全体を見ると

  • 意外な人がもってたレアな実績が可視化された
  • 組織的な隙間が明確になったので差別化のヒントになる

という点がよかったですね。

よくない点は…なんですかね。いろいろな可能性を考えればよくない結果を生むこともあると思いますが、今のところそういう未来は考えられないので、全体的に見てもよかったんじゃないかな、と思っています。

渋谷で飲み会

いい話がいっぱいできた。もっと目線をアゲアゲでいかないと!

キーワード

  • 外回り営業
  • ラッパーとプログラマ
  • vimrc

POとPOじゃない人の勉強会 第10回

POとPOじゃない人の勉強会、ついに記念すべき第10回!発表者の一巡したので私から。

範囲は24章から26章で、資料は社内の事情を盛り込まなかったので一般公開。(盛り込む時間がなかったとも言う)

緩やか変更や迅速な対応という部分では、自社サービスを沢山抱えている企業としてはあるある過ぎて「そうだよね」と同意するばかりでした。

ただ、迅速な対応の部分では「リリース後すぐにチームを解散させないメリットを上司や経営層に説明するのは数字からも簡単だ」というような一文があるんですが、本書の中ではそれ以上具体的な数字や材料がなくて、どういう風に計測したり、持っていけばいいのかな、というのが疑問に残りました。特に、リリース直後はみんなばたばたして重要な数字を記録していなかったりするので、プロダクトマネージャはそういうことをちゃんとやれよ、ということなのかな、とも思ったのでした。

アジャイル開発手法の話は、著者が過去に嫌なことがあったんだろうな、と思わせるような本書の中でもかなり長い章ですね。

言わんとしていることはまったくもってよくわかるので、あまり深入りせずに今のアジャイル開発の話をして、そのあとは社内でのスクラムの取り組みについてディスカッションしておしまいでした。来週も楽しみだー。

AEP読書会 19章

AEP読書会、私の中ではビルの外のあるセブンイレブンから大量の発泡酒(だいたい2,3人で500mlを40本と軽食)を輸送するイベントとなっています。ちなみに、前回からは「すぐに返しにくるから」とカゴのまま持っていくという技を編み出したことにより、指にかかる負担がかなり軽減されました。

  • 完成と完了って使いわけてる? > スクラムガイドで訳語が「完成の定義」になったので、そっちを使ってる。プロダクトり完成と、作業の完了という意味合いで、前者を強調したかったのでは?
  • 「ほぼほぼ発覚」 > わかってるけど認めたくない。盲牌の状態。
  • 進捗率80%コレクターがいる。進んでいるとは言いたいけど、終わったことにしたくないのでは。
  • エピックとストーリーは粒度が違うだけ?エピックを砕くと情報が欠落するかもしれない。それを補完するのがテーマでは?
  • パーキングロットとパーキングロットチャートは違うよ
  • 「見える」と「見えてる」の差について。行動を誘発できるかどうかが違うような。

今回も盛り上っていい会でした。