Suicaのシステムがいかにすごいか仕組みを徹底解説
- Suicaの凄さ
- サービスを落とさないための「自立分散高速処理技術！」
- ものすごい処理量をこなす緻密な速度改善
- お金を扱うからこそ間違わない仕組み
- 当時は最先端の非接触ICカードを採用
- 年寄りも当たり前に使えるサービス
- だからSuicaは６０００万枚も普及した
- まとめ
Suicaの凄さ
- ものすごい処理量（1日4000万件）
- 全然サービスが落ちない
- 年寄りも使っている
Suicaがない社会なんて今や想像できないですよね？東京でSuica持ってない人はいないくらい普及していますし、レストランやコンビニでSuicaを使って買える場所も普通になってきました。普通に考えて、1日4000万件も処理して0.1秒以内に処理を完了させないといけないシステムなんて無茶苦茶難しくないですか？しかも、Suicaがリリースされたのは2001年です！ちょこっと調べてみたすごいブレークスルーの数々を紹介してみようと思います。
IT・Suica事業
https://www.jreast.co.jp/youran/pdf/2013-2014/jre_youran_group_p63_67.pdf
交通系電子マネーのご利用件数が最高記録を更新！
https://www.jreast.co.jp/press/2015/20150602.pdf
ＩＣカード乗車券システムにおける自律分散高速処理技術と そのアプリケーション
http://www.sice.jp/ia-j/papers/jitk6-20050722-1305.pdf
サービスを落とさないための「自立分散高速処理技術！」
改札が止まれば日本の通勤ラッシュをさばくことができない！すべてはこれを解決するために安定して高速にサービスを動かし続けるアーキテクチャになっています。かんたんに言うと、「ピッ」する改札は独立させて、「ピッ」したデータが改札→駅→中央サーバに送信できたら送信するという仕組みになっていて、中央が死んでも駅サーバで処理できちゃう！キューのような仕組みになっていて、データをある程度蓄積し、通信が確立されれば、より上位のサーバ（改札＜駅＜中央）にデータを複製することで間違いが起きずに中央集権的に顧客管理ができます。
そもそも、改札＜駅＜中央が独立できるのは、改札を通って駅構内に入ってから人間が行きたい駅まで移動するのにタイムラグが発生する電車の特性によるからなんです。つまり、「ピッ」した情報は次の駅の改札を通るまでに到着駅サーバに到達すれば良いのでこんなアーキテクチャができるわけです。逆に、改札入ってすぐ出る場合は駅サーバまで複製できていれば処理できるので信頼性の高い処理が行える・・・キレイな設計ですね。
ＩＣカード乗車券システムにおける自律分散高速処理技術とそのアプリケーション
http://www.sice.jp/ia-j/papers/jitk6-20050722-1305.pdf
ものすごい処理量をこなす緻密な速度改善
「ピッ」した時にやってることは「運賃計算」が主な処理とのこと。これを100msec（0.1秒）以内に計算して、改札に返さないといけないのです！どれくらい難しいかというと、普通のWebサービスのレスポンス速度は1秒以内でも結構早い方で、処理速度的には0.2秒とか意外にかってたりします。糞なアプリだともっと遅いです。Suicaが凄いのは問題解決にピンを置いて、普通降りる時に運賃計算するのを乗った時に処理の一部をカードに保存してしまうという逆転の発想があった。こういう逆転の発想はエンジニアは必要な思考法で、その時にしなくても良いものを先にやっておくという考え方は色んな所で使われている。アイテムベースの協調フィルタリングで「この商品を買った人はこんな商品も買っています」というレコメンドでも利用されている。前例に囚われることなくあらゆる可能性を考えてみるというのは忘れないで置こうと思ったのでした。
したがって，処理時間を短縮 するために，乗車時に予め定期区間内の乗継駅 （仮精算駅）および乗車駅-乗継駅間の運賃を IC カード内に記録する技術を考案した．これは， 個々の改札機に自駅から各駅への運賃データを記憶させることで可能となった技術である。
お金を扱うからこそ間違わない仕組み
間違わない仕組みというより、間違うからこそ間違っても何とかなる仕組みが大事だと思います。完璧なシステムよりも完璧じゃないことを前提にそれでも正しく動く仕組みって大事ですよね。つまり、実際に起ったことを確実に記録して、それがエラーだったらもう１回やればいいよっていう冪等性（べきとうせい）のある仕組みを考えておくべき。Suicaだと『だれがいつどこで「ピッ」したか』と『だれがいくらチャージ』したかが分かれば、必ず正しい状態にすることができます。このデータをネットワーク上のサーバに複製しておくことで中央が死んだり、改札が死んだりしても最終的には数字を合わせることが出来る仕組みになっています。僕が主にやってきたECでも障害はよくあることなので、障害がおきても復旧できるようにユーザの生データは確実に保存できるような仕組みになっていました。
当時は最先端の非接触ICカードを採用
「ピッ」の技術は非接触ICカードといいます。この技術は大きく２つに分かれて、NFCとFelicaがあります。どちらもソニーの技術ですが、NFCはオランダ：フィリップスと共同開発になっています。NFCはかざすだけで通信する技術で、Felicaはデータ管理とセキュリティの技術になっており、この２つが合わさってSuicaや他の電子マネーが動きます。世界的に見ても当時は日本が最先端を走っており、Suicaの登場で東京の通勤ラッシュも大きく緩和されることになったと思います。
非接触ICカードの歴史
1988年 ソニーでFelicaの基礎技術研究が始まる
1997年 香港「オクトパスカード」でFelicaがはじめて実用化
2001年 Edy、Suicaサービス開始
2004年 おサイフケータイ（Felica)がドコモから発売
2011年 Felica対応スマホが発売
2016年 ApplePayでiPhone7にFelicaが搭載
年寄りも当たり前に使えるサービス
当たり前に使えるというのがシステムでは相当難しい話になります。しかし、１００％確実に動くシステムなんて存在しません。物理的なモノがある以上災害があれば止まりますし、９９％の稼働率でも年間87時間停止していることになります。これではまるで使えません。そんな中でも障害が起きた話は直近でたった1時間のみです。先ほど説明した「自立分散高速処理技術」と呼ばれている自立分散の部分で、一部が死んでも動き続ける仕組みが実装されていることによる影響が大きいです。サーバースペックに依存することなく、アーキテクチャとして一部が死んでも動き続けるヒトの血管の弁のような仕組みを盛り込む必要があるということです。
だからSuicaは６０００万枚も普及した
通勤ラッシュのとんでもなく高い要求仕様をエンジニアが解決したことで、とんでもなく使いやすい電子マネーのSuicaが誕生し、現在では約６０００万枚発行されているみたい。使えるお店も３２万店舗！端末は６３万と、コンビニでは当たり前に使えるし、自動販売機でも使えてどんどん便利になっていってますよね。
クレジットカードの発行枚数は約２億５０００万枚
Tポイントカード発行枚数約１億３０００万枚（内アクティブ６０５０万人）
楽天Edy発行枚数約７８００万枚
nanaco発行枚数約４０００万枚
他の電子マネーと比較すると、枚数差はそんなにありません。ただ、交通系カードなのでアクティブ率が他と段違いで高いため、電子マネーといえば圧倒的No1でSuicaなのです。
クレジットカード発行枚数調査結果の公表について
http://www.j-credit.or.jp/information/statistics/download/toukei_03_a.pdf
電子マネー「楽天Edy（エディ）」 | 加盟店募集｜楽天Edyの特徴
電子マネー nanaco 【公式サイト】 ： 法人のお客様 | 電子マネーnanacoとは
T-POINT 10周年 | TポイントとTカードの総合サイト[T-SITE]
まとめ
だれでもかんたんに使えて、速さを意識しないくらい自然に支えるシステムの裏には地道な速度改善のための問題解決と、アプリレベルではないアーキテクチャとして仕組みによる問題解決が重要な要素になっているということ。難易度が違っていても、課題をドリルダウンして解決できるレベルの課題を本質的に解決していくことが大事なんだなということを感じた。
みんな辞めたいけどもう止まれない！基幹刷新プロジェクトの裏側[2]
はじまる怒涛のプロトタイプ開発
与えられた工数は２周間
通販の受注を受けるプロトタイプをスクラッチすることになった。
お客様はパフォーマンスを気にしているとのことで、顧客・受注・商品のテストデータ１０００万件で高速に動くことがデモできるようにとのオーダー。
システム構成は速攻で作れるようにフロントはAngularJSを使い、バックエンドはPHPだったけどLAMP開発素人だったので２～３日はなれるまで苦労した。
新人エンジニアに教えながら、アジャイルで作っていく。
朝６時に起きる
８時にはコーディングを始める
ランチして
２３時には終電だから帰る
土日もはたらく
そんな怒涛の２週間はすぐに過ぎた。
これが評価されてどでかい基幹刷新プロジェクトが始まった。
業務を変えずにシステムだけ刷新する本末転倒
プロジェクトは始まったものの、弱体化した情シス（一回基幹刷新失敗している過去）なので業務を変えずに既存のシステムだけを刷新するという方向性になっちゃった。
こんなプロジェクト
- 現行踏襲
- 業務は変えない
- 仕様バグも影響わかんないから踏襲
そもそも今回のプロジェクトのゴールはメインフレームからオープン系に切り替えることで、高額な保守コストをカットして機能追加にコストがかけられるようにするということだった。
ぼくの頭のなかでの理解
ニーズが変わる→業務が変わる→保守コストがかかる
リプレースする際に全部書き直すとかアホみたいにコストがかかるので、本当に必要な機能や仕様だけにそぎ落として新システムに移行すべきなのはだれでもわかることと思う。
必要な機能や仕様とは、ニーズがあること、つまりその業務がなくなるとものすごい困るもの。言いたいことは機能そのものが大事なのではなく、結局お客様のニーズ次第なので業務はそれに合わせて変わるし、踏襲するのは「ニーズに対しての問題解決」だけだ。
はじめからボタンを掛け違って大変でした。
逃げ出す協力会社たち
既存プログラムを設計書とソースコードから解読し、PHPで書き直しテストするという面倒くさすぎてクソおもしろくないルーチンワークが500人月くらい積み上がりました。カットオーバーまで残り１年！
1ヶ月、2ヶ月、3ヶ月と日が経つにつれてエンジニアの目が死んでいきます。
おもしろいくらいに目が死に、勤怠が悪くなり、モチベーションが落ちる所まで落ちている気がします。なにせ大して頭使わないし、間違ったら怒られる！
それだけでなく、メインフレームのILE RPGという言語仕様はすべてイテレータパターンで実装されていて処理の全体像が見えづらい！
解読が難解→実装が遅れる→デスマ
平均の稼働時間が２８０時間くらいだったんじゃないでしょうか。
続々と協力会社は白旗をあげだす始末
全然使えないという理由で切り捨てた協力会社もありましたが、だいたい仕事がキツすぎて逃げ出しました。
だれも業務しらないというトラップ発動
究極だったのは、現行踏襲でコードもわけわかんなくてどういう風に業務やってんですか？って聞くとだれも知らないという事実だけが分かるトラップ。
業務が分断化・定型化されすぎてだれも全体像を知らなかったり、何千人かいる社員の中の１人だけがやってました的なトラップには何度もハマった。もうそれいらんやろ！
覚えるかドキュメント書いておけよ！
学んだこと
限界を超えて働かせることはできない。
おもしろい仕事か承認欲求を満たすモチベーションを報酬にしないと体を壊す。
はじめ方とおわり方が大切
あと残り９ヶ月でカットオーバーって時でこの状態です。
＞＞つづく（荒ぶるWBSと伝家の宝刀GWで打鍵祭り）
＜＜もどる
みんな辞めたいけどもう止まれない！基幹刷新プロジェクトの裏側[1]
- トップダウンで始まった基幹刷新プロジェクト
- 他ベンダーの３分の１の金額で受注
- 激甘な見積もりと序盤の進捗管理
- やったことがないから肌感覚がない刷新メンバー
- そんなこんなで基幹刷新プロジェクトがキックオフ
- 学んだこと
トップダウンで始まった基幹刷新プロジェクト
東証1部上場の大手で始まった基幹刷新プロジェクトに僕はアサインされた。鶴の一声で始まった案件だったため、現場からの反発がものすごく、「仲良くするには」的な議題が上がることもあったくらい現場はギスギスしていた。
20年近くメインフレームのシステムを利用し、情報システム部は脆弱でITゼネコンがあまい汁を吸うという典型的な日本のITの構造になっていた。さらに、数年前そんな状況から脱出しようと一度基幹刷新を試みるも失敗してきたという経緯があった。その古傷をえぐり全否定するのだから反発は当然といえば当然なのだが・・・。
他ベンダーの３分の１の金額で受注
実績が欲しかったのと、カットオーバー後は継続開発もありドル箱案件になるため、他者の３分の１程度の金額で受注した。これが後々大きなしこりになった。今だから思うが決して赤字でプロジェクトを受けてはいけないし、そもそも値引は良くない。適正な価格で提供しなければ発注サイドも疑心暗鬼になってしまうと思う。
激甘な見積もりと序盤の進捗管理
そもそも緻密に見積もれないくらいに誰も知らない業務とか埋まっていたりする。プログラムの仕様が間違ってたり、想像だにしない問題が大量に発生するのが基幹刷新なので、工数管理はかなり難しい。
とはいえ、序盤から進捗が悪化した時のリカバリー方針がリスケリスケで問題先送りスタンスだったため、週次MTGの度に負債が積み上がっていくプロジェクトだった。そもそも積み上げられる問題は放置できることが多いのでわざと放置してカットオーバー判定対象から除くことを最初から決めていたのかもしれない。
やったことがないから肌感覚がない刷新メンバー
テスト工数が圧倒的に短すぎるスケジュールになっていて、エンジニアだったら肌感覚でわかることがPMとかコンサルあがりにはまるでわからないことが多々ありました。開発にかかる時間軸でのコストは開発１：テスト２くらいが妥当なところで、開発の中もざっくり動くレベルが０．２で細かい仕様を実装するのが０．８でパレートの法則に近い。（個人的な見解です）
とにかく「テストには開発の倍くらいコストがかかる」というのを覚えておいてもらいたい。バグが発生すれば調査して単体テスト書いて修正してコミットとか作業が多い。テストが楽なコードでなければ調査も大変だし、修正によるデグレが発生するリスクもある。
だから開発５００人月のプロジェクトで５０人月くらいの内部結合テストは明らかにスケジュールがおかしい！
そんなこんなで基幹刷新プロジェクトがキックオフ
ギッスギスしたまま始まったプロジェクト、PM以下はだれも喜んで進めたくないような雰囲気を漂わせながら。
学んだこと
ビジョンの共有と目標設定、それをベースにした意思決定の基準について初めに握るか共通の認識を持ち、それを常に意識することが大事だと実感した。いつ終わるか分からないマラソンにはだれも参加しない。
＞＞つづき（怒涛のプロトタイプ開発とスタート失敗）
PMが知っておくべき稼働を上げて対応は麻薬と同じだという事実
稼働を上げて対応は麻薬
下の図はシンプルに稼働人日と欠勤をチャート化したものです。（実測値）
平穏だと欠勤は２％～３％くらいで月に1回休むかどうか程度で、概ねスケジュールに問題が発生しない状態になります。
4月と9月には大量アサインがありましたが、6月は追加要員がありませんでした。
稼働量推移
※9月途中なので9月1週目終了時点での欠勤率です
欠勤率推移
欠勤率のチャートを見れば麻薬の効果は明らかで、4月増員したことで生産力が向上したため負荷が分散されて体調不良は目に見えて低下、しかしその後順調に仕事量は増えてゆき（シナリオテストの戻り修正等で）5月GWがあったのに欠勤率が高止まりしてます。
なぜならGWももちろん働いているからだし、土日の工数がこのグラフに出てきてないですが、土日どっちかは自宅で作業している感じになっています。稼働が限界に近づくと欠勤率が直接上がって結局トータルの生産性が上がっていないことが言えます。
麻薬ゼッタイダメ
稼働を上げずにトータルの生産量を増やすには？
「集中」とか言いません。別に集中力が悪いから生産性が悪いことなんて滅多にないからです。そもそもPMが個々人の生産性に依存した時点である意味終わっているし、組織とかチームとしても終わっていると思います。
最も早くて確実に作れるのは知っている仕事です。
逆に、最もスケジュールがあやふやで遅くなるのはだれもやったことがない仕事です。
1人で完結しない仕事で一番やっかいなのが、お客様がよくわかっていないし、自分もやったことがない仕事とかです。調べて、分かりやすい資料に落とし込んで説明して、お客様と握って、実装して、テストして、全然1周間なんかで終わるイメージが湧きません。こんなのがガシガシ差し込まれて崩壊が始まっていないでしょうか。
知っている仕事をとにかく増やす。
個人とチームの両方に、SlackやChatworkやWikiのような仕組みを使って形式知を拡散すること。だれかに負荷が集中することを避け、本当にその人だけが出来る仕事に集中させる体制を取ることで総生産量を高めます。
難問を小分けにして解決する
問題解決の方法論として解決できる小さい単位の問題に切り分けて優先順位で対応するものすごい基本的なことです。頭を抱える前に書きだして小分けにして分からないことを整理するという本当に基本的なこと。ただ、こういう問題解決の方法論をSIerの新卒エンジニアが勉強するには自分で本を買ったりしないと知らないわけで、そういう人のメンターを買って出るのも一つの手であります。
ゴール感を明確にしてから調べる
お客様分かってない系の調査は事前にニーズ、守るべき価値観の目線を合わせてからゴール感というか着地をイメージして調査しないとふわふわして仕事量が増えがちです。MECEにやり過ぎてもただ無駄工数を積み上げてしまうだけというのはよくある話です。時にはAとBとそれ以外ぐらいざっくりなMECEで判断出来る時もあります。
つまり、リーダー陣はゴール感の認識を常に共有しておく必要があります。どうでも良い進捗とかTODOの共有なんかより、ゴール感や意思決定の判断基準を常に共有し続けることのほうが優先度高です。
逆に稼働を上げたいワーカホリックもいる
別に土日やることがない独身男性で、仕事が好きなやつとかは稼働をあげたいと思っていたりします。仕事にものすごいやりがいを持ち、ビジョンとマッチ度が高い若手を見つけてほど良い高稼働にするのは歓迎。ある意味麻薬なので好んで仕事中毒になってしまうかも。一方で、子供と会えないくらい終電まで働かせて、土日も働いてというのは人間の所業ではない！！
かんたんに出来る稼働をすぐに上げてしまうのは崩壊のはじまり
自分への戒め
プロジェクトに悪い印象を与える心理バイアス付き勤怠メールの送り方
なんかあいつ勤怠悪いな、クソが！
どこのプロジェクトでもそんな声があるのではないでしょうか。締め切りが近くなって勤怠が悪くなったり、高稼働が続いて遅刻が増えたり、でも実は定量的に分析してみると意外とそんなに勤怠が悪くなかったりします。
相手を不快にするような心理バイアス付き勤怠メールの事例から学ぶことで、よりよいデスマーチライフが送れることをゴールとしてお話します。
「様子を見てから出社します」
様子見てから出社メールはそのものに対するツッコミだけでなくもう１つのバイアス（錯覚）を受け手に植え付けます。
「様子見」→「全休」コンボによる繰り返し勤怠メールが心理的な強化を促します。
「こいついつも勤怠メール送ってんなコラ！」がどんどん潜在意識に刷り込まれてしまいます。勤怠メールを投げる＝受け手に繰り返しの効果を与えることを意識して一撃必中ですごく申し訳なさそうな文面を送りましょう。たとえ理不尽な理由で遅刻してしまったとしても、自己管理できなかった私はクズですぐらいの低姿勢で行きましょう。
なぜか本人じゃない所から勤怠メール
IT系あるあるだと思いますが、協力会社で何人かプロジェクトにアサインしていると、これまで直接勤怠メールを送っていたのに、いきなり同じ会社の人に勤怠メールを投げさせる事変が発生します。
「休むお前が連絡しろ！」
だいたい年長者が休みまくっていたり、進捗遅れているのに休むと、なぜか別の人からそいつの勤怠メールが飛んできます。なんかもう受け取るこっちが恥ずかしい。休む時は堂々と休みましょう。
悪い勤怠メール例文集
例：本日体調が不安定なため～
答：不安定ってなんだよ！
例：体調不良が改善しないため本日は欠勤とさせていただきます。 at 11:30
答：お忙しいところ大変申し訳ありませんが！だろっ
例：体調不良のため午前休とさせていただきます。
答：寝坊しただけだろ！
例：私用が長引いており本日は欠勤とさせていただきます。
答：前もって休むって言えよ！
例：腹痛のため30分ほど遅れます。
答：だからっ申し訳なさを出せよ！
例：体調不良のため、午後から出勤とさせていただきます。
答：午後じゃなくて何時にくるかいえよ！
こんなツッコミどころ満載なのが多いITの戦場からお届けしました。
あなたも年収1000万かも！？ITエンジニアの給与事情を激白
ITエンジニアの人手不足というのは結構騒がれているが、「上流と新人」が余っているだけだと思う。実際人はなんだか多いし、新人とかすぐ入ってくる。
構造的な問題としてはITエンジニアとして成長するには相当量の独学が必要だということ。1年で即戦力になるレベルで成長しようとすると本代も馬鹿にならないし、土日なんてまずないと思った方がいい。平日も当然16時間くらい働くんだけど。
これを5年間かけてゆっくり成長しようと思っても、デスマーチに巻き込まれたら業務で１２０％時間が使われて、業務特化型に成長してしまい潰しが効かなくなる。
逆に上流の人余りは、昔Cobolとかメインフレームやってた人が上流のコンサルとかやってて、テクノロジーに追いつけなくなった系はなんとなく余っている気がする。
というわけで、どこも熟練のタフなITエンジニアが足りてない現状が起こると見ている。需給の関係で相対的に給与もあがっていくのは自然な流れ。
ITエンジニアの単価
新兵（1年目～ 3年目） 単価0円～40万（ベテランと抱き合わせ商法などがある）
戦士・分隊長（～10年目） 単価70万～150万（この辺が一番生産性高い）
軍曹・将軍（10年目～） 単価150万～300万（マネジメント/PM）
だいたい戦士クラスのフリーエンジニアだと単価100万くらいになります。よりハイスキルな人だと150万とか、結構青天井な領域
になります。軍師クラスだと最大単価300万とかありましたが、結果数億の効果があれば価値あるよね的な価格設定です。
ソフトウェア系も結構食い込んでます。
僕も新卒３年目で年俸７００万くらいでした。
なので、クラブでナンパしたり金遣いの荒いイケイケの人も多いです。
システム化の需要って当分なくならないよね？
まだまだ世の中情報処理を手作業でやっているのでシステム化の需要は当分なくなりません。マイナンバー特需も今年ありましたし、なんだかんだみんなシステムが大好きです。
供給サイドは人工知能がコーディングしない限り、爆発的にITエンジニアは増えないので給与は高止まりしたまま数年は行くだろうと思います。
金もらっててもITエンジニアとは結婚はしないほうがいい
- 家に帰ってこない（帰れない）
- 休日は仕事しているか勉強している
- 動かないのでだいたいお腹だけ出てる
結婚には向いてないと思う。
実体験として笑
