けんちゃんくんさんのWeb日記
2015/10/5

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ライフを。

created_at: 2015-10-05 02:31:09 +0900
updated_at: 2015-10-13 13:53:46 +0900
2015/10/2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

はい!がんばります!

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

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

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

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

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

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

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

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

おわりに

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

created_at: 2015-10-02 05:08:57 +0900
updated_at: 2015-10-28 09:12:34 +0900
2015/9/12

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ライフを!

created_at: 2015-09-16 02:36:34 +0900
updated_at: 2015-09-16 02:37:45 +0900
2015/9/12

2015-09-12: 散髪ログ

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

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

created_at: 2015-09-16 03:00:43 +0900
updated_at: 2021-09-02 15:32:22 +0900
2015/9/1

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

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

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

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

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

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

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

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

created_at: 2015-09-01 07:54:20 +0900
updated_at: 2015-09-01 08:19:10 +0900
2015/8/29

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

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

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

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

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

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

イベント全体のこと

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

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

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

created_at: 2015-08-31 05:04:52 +0900
updated_at: 2015-08-31 05:04:52 +0900
2015/8/21

YAPC::Asia 2015 に船で行く

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

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

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

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

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

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

created_at: 2015-08-21 07:42:56 +0900
updated_at: 2015-08-23 09:47:54 +0900
2015/8/3

2015/07に読み終えた本

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

shucreamの本棚 - 2015年07月 (3作品)
多重人格探偵サイコ (22) (カドカワコミックス・エース)
田島昭宇
読了日:07月07日
評価3

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術
ジェフ・サザーランド
読了日:07月11日
評価5

鈴木さんにも分かるネットの未来 (岩波新書)
川上量生
読了日:07月31日
評価4

powered by booklog
created_at: 2015-08-06 01:43:33 +0900
updated_at: 2015-08-06 01:43:33 +0900
2015/7/30

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

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

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

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

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

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

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

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

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

created_at: 2015-08-06 01:43:33 +0900
updated_at: 2015-08-06 01:43:33 +0900
2015/7/16

渋谷で飲み会

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

キーワード

  • 外回り営業
  • ラッパーとプログラマ
  • vimrc
created_at: 2015-08-06 01:43:33 +0900
updated_at: 2015-08-06 01:43:33 +0900
新しい記事へ 古い記事へ