UXエンジニアになりたい人のブログ

エッチだってしたのにふざけんなよ!

redmine使えないヤーツ

最近、猫も杓子もredmineじゃないですか。そうでもないですか。そうですか。redmine使い始めると現れる困った人についてまとめます。*1

 

利用者編

ステータス変えない

とても多い。コメントは書くが、ずっとステータスを新規(初期状態)のままにしておくヤーツ。

なぜそんなことになるか理解できない。どれが終わってるのか自分でわからなくて困らないのか。

 

進捗率変えない

ステータスは完了にするが、進捗率は100%にしないヤーツ。

これはシンプルにredmineの設計が悪い。完了したら100%になるのは当たり前だ。プラグインで解決できる問題なので導入すべし。

 

なんでもチケットに書いちゃう

明日打ち合わせしましょう、とか、後で電話します、とかまで書いちゃうヤーツ。いやチケットの事象がどうなるかだけ書いてよ。

 

結論書かない

なんでもチケットに書いちゃうヤーツと同類であることが多い。

結局対面の打ち合わせで自分は納得して満足して、結果を書かない。外から見るとチケットの事象がどうなってるかわからない

 

話コロコロ変える

redmineは1事象1チケットが基本であるが、コメントの途中で「そういえば〇〇はどうなんです?」などと違う話を始める。

別件としてチケットを切ってください、と何度言われても繰り返すのが特徴。受け手は話変えられたとしてもチケットで返答するしかないのでタチが悪い。

この手のヤーツはツールによらずその傾向がある。メールでも話をまぜこぜにして今いくつ話が進んでるかわからんことになりがち。

 

コメントが死ぬほど長くなる

100とか超えちゃう。常識で考えて、1つの事象に対して100回もやりとりが発生する可能性は薄く、なにかをまちがえている。基本的に話コロコロ変えるヤーツが違う話を延々と続けてるパターンが多い。

 

別管理してしまう

メールにTODOフラグつけるとか、印刷した紙に付箋つけて管理するとか、自分用Excelをローカルに持ったりとかしてそっちでステータス管理してしまう。

ので、redmine側ではステータス変更しないヤーツになってしまう。

文明の利器をつかいこなして!

 

管理者編

ライフが長いチケットを作ってしまう

バグが発生してから、直して、レビューして、修正確認して、QA確認して、リリース決めて、、、、という流れを1つのチケットでやろうとしちゃうヤーツ。高機能なバグトラッカーから移行した人がやりがち。redmineはチケット設計にかなり自由度があるので、こういう設計も間違いではないが、チケットのライフが短いことを前提に終わった終わらないを管理するプラグインが多いため、プラグインエコシステムをフルに享受できない可能性が高い。

ライフが長くなると当然フェーズごとに担当者が設定されるため、〇〇担当者というカスタムフィールドが増えて一覧性検索性も悪くなりがち。

 

超複雑なステータス遷移ルールにしてしまう

ライフが長いチケット作るヤーツにありがち。newからいきなりcloseに行けないように、などのルールを厳密に作りすぎる。

大抵例外系をすべて網羅できずに死ぬ。

しかし作り手的には「ぼくがつくったさいきょうのフロー」という自負があるため面倒なことになりがち。

ちなみに、利用者にとって「問題は解決してるのにわけのわからんシステムのせいで自分の手から離せない」というは非常に大きなストレスである。

 

管理Excelを自前で作って抱え込む

redmineのデータをエクスポートして色分けしたりグラフ化したりする便利ツールを作ってしまう。

そこには情報が集まっているので書き漏れや納期遅れなどはその人にはわかる。だから毎日毎日みなの不備を指摘するredmineおじさんとなる。

本人は開発プロセスを下支えするスーパーパーソンのつもりだが、利用者側としては毎日毎日ちまちま指摘されてウザい。状況を改善したとしても、本当に改善されたかはちまちまおじさんしかわからないのでストレスが溜まる。

もちろん改善されたはずのものが実は改善されてないとちまちまおじさんは怒り出すので、さらに厄介なことになる。

ツールは共有して誰もが恩恵を享受できるようにしましょう(ただしやっつけで作ったツールで本人以外にはまともに使えないというパターンは大いにある)

 

自分が思うredmineの使われ方がされないと、文句を言い出してしまう

おっと最後に特大のブーメランが。redmineはこう使うに決まってるでしょ、とか、そんなこともわからないんですか?などと上から言ってしまう。

どんな利用者であっても、そもそもプロジェクトの関与者は敵ではなく協力者である。それぞれの関与者にはそれぞれの仕事がある。ツールを使いこなすのが仕事ではない。だれもが進捗管理ばかりしているわけではない。

くだらない上から目線のせいで心象を概して、どれがマスターなのかもわからないExcel地獄に戻りたいのか? リスペクトを忘れるな!

*1:「出、出〜redmine使いこなせな奴〜」というタイトルにしようと思ったが、このフォーマット自体がかなり死語なのでやめた。最近とんと聞かないな

みずほの障害報告書が面白い件

6/15に今年2月から3月に連続して起きたみずほのシステム障害調査報告書が発表されました。部外者からすると結構読み物として面白く、また示唆に富んでいるので感想を書きます。

自分がアプリエンジニアなのでその方面の観点が多め。

www.mizuho-fg.co.jp

あらすじ(P.36)

2/28 9:50に大量データ登録によって定期性預金システムにおける取消情報管理テーブルがDiskFull(実際はオンメモリのINDEX格納領域の不足)になって全死

→ 取消情報管理テーブルが全死なので、定期性預金トランザクションの取消そのものができなくなる(2重エラー)

→ この2重エラー状況を検知した上位システムにより防御機構が作動し、ATMやダイレクトチャネルの流量制限が行われる

→ 流量制限されたATMでカード飲込みが発生

f:id:uxlayman:20210619195222p:plain

 

おもしろポイント1:初動の暫定対応を完全にミスっている

システムには2種類の防御機構があったようである。

1つ目は、1系統で同じサービスが30回エラーになったら、そのサービスそのものが使用できなくなるようにメニューから自動で消す「取引サービス禁止機能」(P.51)。今回だと、定期性預金サービスが全死なので、ATMのメニューから定期預金関連のメニューが消えていった。なんかちゃんと動いてないサービスあるからそれ使えないようにしといたろ、的なヤツ。

2つ目は、2重エラー(≒パーコレートエラー)が5回発生したときに、そのきっかけとなった処理区画を自動で閉じる機能(P.46) 。なんかシステム全体ヤバそうだから入り口を閉めて全体に負荷かからないようにしたろ、的なヤツ。

なお、システム全体は3系統あり、1系統ごとにATM処理用に20区画が用意されているとのこと。多分1区画ごとに複数個のトランザクションを走らせることができると思われる。「系統」は全く同じシステム構成が3個ある(負荷分散と可用性確保用)と思われる。そのへん詳しく書いてなかったのでわからんが。

 

で、今回は前述のように定期性預金サービスが全死だったので、もしなにかするなら、前者の防御機構を強めてなるべく皆が定期預金系サービスを使えないようにする必要があった。

が、あろうことかこの制限を30回→999回に緩めてしまった。この結果、皆が(抑制されていた)定期預金系サービスをつかえるようになって、それが全部エラーになって、後者の防御機構発動→ATMの停止祭り、となってしまった。

障害の真っ只中で混乱はあったのだろうが、それを差し引いても無能な対応だったと言わざるを得ない。なお、作業の指示と実行は11:37-12:08の期間で行われているが、11:30の時点で(定期性預金サービス内の)DBのDiskFullという根本事象が常務に報告されているので、この時点で常務に整然と報告できるほどに根幹は見えていたと思われる(P.38)。

なのになぜw この失敗が致命的である旨が報告書で数パターンのグラフwで示されており(P.41,53)、そのあと結局定期性預金サービスは完全に切り離したので、この措置矛盾しすぎだとか、昔うまく行った記憶をもとにノリでやりました的なこともバラされていて(P.76)もはやフルボッコ状態ww この指示者の行く末が気になるところである。

f:id:uxlayman:20210619195352p:plain

おもしろポイント2:根本事象解決後、ATMが回復しなくて大混乱

本件、先に述べたとおり根本事象はDBのDisk(オンメモリ格納領域)Fullである。領域拡張が終わったのが14:54、これを利用する定期性預金性サービスを16:22に再開完了している(←起動に1時間半もかかるのな)。

どうもここで一旦障害対応が終わったと思ってたフシがある。16:37から障害の過程でロックされた顧客ファイルの解除を試みており、つまり事後処理を始めてることが見て取れる。

一方、ようやく防御機構2によってATM処理区画が閉塞がされてたことを認知したのは17:10である。この間、だいぶ混乱したんだろうなあと。「ダメです!ATM回復しません!」「そんなバカな」みたいな。エヴァかな?ぜひ再現ドラマを作って欲しい。

こういう安堵からの再混乱みたいな話好きなんですよね。完全に他人事だから言えますが。

 

思うに、対応担当者は防御機構2(パーコレートエラー検知によるATM閉塞)を知らなかったのではないかな?定期性預金でのエラー→ATMの閉塞と直接的に考えたのではないだろうか。なので、定期性預金のエラーが検知されないようにするために、おもしろポイント1の対応を行ったのではないかと。

まあ実際にはエラーが検知されないようにする対応ですらなかったわけで、やっぱり草生える対応なわけですがw

原因と"現実的な"再発防止対応を

報告書にはさまざまな側面における原因が記載されている。

原因DiskFullだったわけなので、当然「DiskFullになる可能性を予期してレビューや事前確認を行うべきだった」てのは出ると思うんです。が、これ現実的じゃないと思うんですよね。インポート対象のテーブルがDiskFullになったのならともかく、「定期性預金サービスの、共通処理を担う取消情報テーブルの、INDEX領域がオンメモリに格納されかつそれが当日の処理量に応じて増加する性質に基づき、さらにメモリ利用量の監視警告が見逃される可能性」を予期できるか?という。

ひとはいつでも間違いを犯す、という観点に立つとあらゆる内容をルール化するとか運用体制をガチガチにしばるのもあまりイケてないなあと思います。間違いを犯しても大丈夫な仕組みを構築することが大事と思うのです。

なのでその観点でこれはできたやろという"現実的"な対策を2つ上げたいと思う。

1.カード飲み込み条件の変更

ま、これよね。P.69の原因(オ)として記載がある。前述の通り防御機構は2種類あって、定期サービスやばいから定期サービス止めとこ、と、なんかわからんがやばいから全部止めとこ、の2つ。

その内訳が↓(P.47) 

f:id:uxlayman:20210619195457p:plain

要は、「なんかやばいから全部止めとこ」の方で引っかかって飲み込まれた人が4915件と大多数。

この後者のほうがカード戻す仕様であれば、障害数が5244→329件に抑えられた上に、「定期預金サービスでエラーが発生したので、定期預金サービスを使おうとしたお客様の資産保護のためにカードをお預かりしました」と一応辻褄がある説明ができたはずなのだ。

最もあかんのは、過去3回も同様のトラブルを起こしていた(P.69)のになにもしてなかったこと。この大障害の発生後に速攻直した(P.133)らしいけど、なんだ速攻直せるんだな、最初からやっとけやそういうとこやぞと思わなくもない

人間だから、悪い仕様に気づけないことは多々あるだろう。でも同じトラブル3回も起こしたら、さすがになんかおかしいと気づけよ、と思う。

2. フェイルセーフ機能のテスト不足

P.67(イ)として記載あり。

原因は定期性預金サービスの取消情報テーブルがDiskFullになったことである。明確に記載がないが、おそらくなにか処理を実行する前、最初に実行前情報をコピーしておく(そして戻せるようにする)情報テーブル/機能だと思われる。(DBのロールバックが効かなかったときの保険的機能である旨の記載がある)

それで、この最初の処理が死んでたので事実上なにもできない状態だったと。処理エラー時に整合性が失われたか否かを返す機能があり、それを元に取消を行うか否かを判断しているのだが、それがバグってて常に取消処理を要求するようになってたとのこと。そしてその取消処理もコケるので2重エラー≒パーコレートエラーとなって、ATM閉塞を招いたと。

ここも、うまく動いていれば、障害数が329件で定期預金サービスを使おうとしたお客様のみへの影響で抑えられたはずなのだ。

取消情報テーブルの名のごとく、これはシステムがなんかやらかしちゃったときの最後の防御機能なので、特に重点的にテストすべきだったし、SPOFとなりえる点も踏まえるとオンメモリINDEX保持への設計変更も慎重にすべきだったように思う。

 

ここが原因だったから云々じゃなくフェールセーフ機構だからという観点が大事。

人間はいつでも間違える、だからフェールセーフがある。そのフェールセーフがさらに間違えないように狙いを絞って慎重にレビューとテストをすべきだった、と思う。

---

人はいつでも間違える。締め付けて管理すれば何でもできるわけではない。未来をすべて予測できるわけでもない。だから、間違いに気づいたら改善しよう。間違いが起こっても大丈夫なような仕組みだけはしっかり作ってみんなで保証しよう。

この辺がうまくできてなかったんだろうなあと思うし、これがうまく回るような"現実的"でシンプルなルールができれば良いと思う。間違ってもチェックリストが何十枚にもなるとかそういう無理ゲーな対応になりませんように。

 

ネット上の指摘への対応

みずほの話になるとなぜかネット上で知ったかして適当なこという人が増えるのでそこへのコメントを。

20万人月のあのシステムがまだ未完成なんだろ/バグだらけなんだろetc

あらすじ部分にも書いたように、特定サービスのDB DiskFullが原因であり20万人月システムことMINORIのバグではない。

報告書要旨版の原因欄の一番上にも「MINORIの構造、仕組み自体に欠陥があったのではなく、これを運用する人為的側面に障害発生の要因があった」とはっきり書かれている。

2週間で4回も障害を発生させるとか無能の極みすぎる

実は最初の1回以外、残り3回のうち2回はハードウェア故障を検知して自動切り替えしたという事象で、どちらかというとうまく動いた事象である。

残り一回は初歩的なプログラムミスだが、まあ正直よくある話で、全部一緒にして4連続障害として叩かれたのはかわいそうに思う。

藤原頭取の責任問題

めちゃくちゃある。

リーダーシップのリの時もみえない。公式な緊急対応体制が構築されたのが事象発生から7時間以上経ったあとという1点のみで辞任はやむなしである。全く危機管理体制が機能していない。就任から3年以上こんな感じだったのに、再発防止策の徹底のために続投とか片腹痛い。この報告書書いた人に頭取になってもらえ

当日の対応内容(誰も個人として組織横断的アクションを取らない)がありえない

まあ、わかるよ。言いたいことは。

でも有事に断片情報を元に本当に正しい行動を取れるだろうかと。顧客に情報を伝えるにしても、それが間違っていた場合どうすれば、などまで考えるとなかなか動き出すのはつらそうなのもわかる。

個人的にはこれ系のアプローチよりも問題そのものが起こらなくできたり局所化できたりできるように仕組み作ってくべきなんだろうなと思う。

DBがバラバラで運用が大変そう

 たしかにDBがバラバラで運用が大変そうだが、今回の直接の事象とDBの多様性は関係ないように見える。

が、そもそもの根本事象である取消情報管理テーブルのINDEX FILE容量超過。報告書内に何度も書かれているように、テーブル本体ではなくてINDEXだけがメモリ上に常駐しているらしい。そして、前日分のINDEX容量は退避されて、当日の処理量に応じてINDEX容量が増えるらしい。これって普通のDBMSでできる話なんですかね?いまいち直感に反する話なのですが、前日分までが退避領域(HDD,SSDなど)にあって当日分だけがメモリにあって、それらが透過に扱えるってこと?そういうの、今は普通なの?

そもそも取消情報管理テーブルの名前からして一時テーブル(グローバルトランザクションの生存期間でのみ有用な一時データ)みたいなイメージですが、それが日をまたぐ事があるってこと?いまいちよくわからない。このへんの「わからなさ」がDBMS固有の機能だったり固有の設計制限であったりするなら、多様なDBMSを運用している副作用かもしれない、とは思いました。

f:id:uxlayman:20210621221311p:plain

その他

パーコレートエラーってなに?

どうみても専門用語(IBM用語?)なのになんの解説もない。最初は2重エラーのことかと思ったけど、2重エラーのようなシステム全体の非安定稼働を想起させるような重大なエラー/イベントのことっぽい

 

uxlayman.hatenablog.com

 

 

 

COCOAに望むたった一つの追加機能

少し前にCOCOAの報告書でてました。

一番びっくりしたのはテストを効率化するためにパラメーターを調整(Minimum Risk Score を「1」に設定)してたという記述で、それもうテストじゃないし、何を作って何をテストした認識なんだよ、と*1

そんなCOCOAに望む追加機能があります。

 

*1:個人的には、これでPM会社とか発注主が責められるのはどうなんだろうなあと思います。開発者の資質が圧倒的に足りない。よく言われるような多重下請けが云々という話とは関係なく、仕様に対してなにを確認したのか説明できないのは最低限の義務を果たしていないのではないかと思うのですよね

続きを読む

オンラインホワイトボードコーディングテストの心得

転職活動でオンラインホワイトボードコーディングテスト(zoomでつなぎながらテキストエディタ共有サイトでコードを共有するパターン)をやったので、その心得を書いていきます。

ちなみに結果は、超簡単な問題だったにもかかわらず、テンパってしまい面接官の言われるがままコードを書いてなんとか完成させるもののもちろん落選というもので。

結構行きたかった企業の1次面接だったので、だいぶ落ち込みました。ということなので、心得というか、失敗談ですね。

 

いきなりコードを書き始めない

あとになって思い返すと、これが全てだったかな。お題が与えられたときに、どういう雰囲気で解こうとしているか、どういう処理をして、結果がどう変化していくと想定しているのか、説明すべきだったと思う。

多分ホワイトボードがあれば、配列とか集合とかの絵を描いて雰囲気説明するんだろうけど。

 

これをしないと面接官となにをどうやろうとしてるかの意思共有ができなくて、(自分からすると)的外れなツッコミを受けて混乱することになります。

あと、多分「物事を論理的にとらえてるか」とか、「人にわかりやすく説明できてるか」とかの採点指標になってる気がします。知らんけど。

最悪、説明がうまくできてれば多少コードがあれでも通るのではないかとかも思ったり。ま、面接官じゃないんで知らないですけど。

 

面接官のプレッシャーに慣れておく

コーディング中は、面接官がかなりサポートしてくれます。あれ?そこ〇〇が抜けてない?とかそういうことを言ってくれる。すごく親切。

 

親切…なんですが、これはめちゃくちゃプレッシャーになります。特にどうコーディングするかをうまく共有できてない状況だと、「あれ?なんか言われてるけどなんのこと?どこのこと?よくわからない。スルーするのもおかしいし。とりあえず直すけど、あれ?ここをこうすると全体はどうなるわけ?なんだ?なんだ?」となります。

 

そもそも、相手方だけが一方的に「答え」を知っていて、即座に口出しはしてくるけれども正解を教えるわけでもない、という状況はわりと特殊です。実務上、経験したことがない人もおおいとおもいます。

ペアプロだったら「一緒に考える」が出発点だし、わかんなかったらわかる方が書いてから解説しますからね。そもそも、コーディング複数人でやったことある人自体も少ないですよね。

 

このシチュエーション、練習しようがないのが特にアレなんですが、ともかくそういうことが起こるという心構えは必要でしょう。これ、面接官本人が親切のつもりでやってるのがさらにたちが悪い。正直、だまっててほしかったです。

 

競技プログラミングサイトで練習すべきかどうかは微妙

就職転職の面接だと、AtCoderやLeetCodeみたいな競技プログラミングサイト(以下競プロ)チックな実技試験もあります。この手のサイトで練習しといた方がいいという意見もよくみますが、ちょっと微妙です。

 

理由の1つ目は、ホワイトボードテストの問題は競プロの問題と比べて多分かなり簡単であろうということ*1

その場でロジック考えて説明して、話しながら改良して、という性質から考えると、広がりはあるものの書ききること自体は簡単な問題が出ると考えるのが妥当でしょう。

なので、競プロで練習しまくっても本番が簡単すぎて練習の意味がなくなる可能性があります。

 

2つ目は、競プロとホワイトボードテストは作業手順が異なること。競プロは、コンパイルもテストも通す必要があるけども、1人で黙々進めることができます。ググることもできるし、とりあえず書いてみてからテスト通すことを目的にバグつぶししていくこともできます。

わたしも今回初めて気付いたのですがこのタイプのコーディングをしてます。ザクっと雰囲気で書いてからリファクタしていく、という。

 

対して、ホワイトボードでは、まず概要を説明してからツッコミに耐えながら描き続けなければなりません。コンパイルが通る必要は全くないですが、コードで正しく意図を表現できる必要がありますし、要点だけをコード化しなければなりません。

AtCoderで難しい問題が解けるようになっても、それより遥かに簡単な問題の、要点部分だけを書いて、それをわかりやすく説明しなければならないですし、そもそも書き始める前に概要を言わなければなりません。

その辺意識して競プロで(たとえばコード書く前に口で説明してみるとかそういう手順を入れて)練習するなら良いのですが、ただ単にドリル的にサイトの問題を解きまくると本番で思わぬ落とし穴が来るかもしれません。

 

結局どうすればよいか

あまり答えは出てないですが、面接時の状況としてはペアプロがいちばん近いのかなあと。スーパープログラマーに簡単な問題出してもらって、横でつっこまれながら書いていって慣れる、とか?

まあ、あとはホワイトボードテストを依頼された時点でその会社はご縁がなかったとして諦めるとか。自分はいまはこの気持ちですね。あまりに出来が酷かったので、面接直後に落ち着いて書き直したら5分で完成できましたし。いまだになぜできなかったのかよくわかっていない。ただただ苦手意識だけが植え付けられてトラウマです。

参考になれば。

 

 

*1:n数1であれですが

スクラム開発批評

最近スクラム開発をやってみてるのでその感想を。スクラム開発って何?って方は以下の図をごらんください。

 

f:id:uxlayman:20200916190500p:plain

via スクラムの概要を1分で理解できるイラスト【2018版】 | Ryuzee.com

 

…すこし本題とは逸れるのですが、この絵は実際に社内のスクラム推進派の人に見せられた絵です。なんですが、、、あのさ、、、これでなんなのかわかんなくね?

この絵に限らず、スクラム開発 - Google画像検索で出てくる画像はほとんど、スクラムの構成要素をただ書いていて、結局何が良くなるのか、つまり効果がわからないのです。この時点ですでに割と不信感ありますよね。良さをわかってもらおうという気があんまりみえない。わかってる人がわかってる人のために書く図。

閑話休題。

ま、単純に言ってしまうと、スクラムはバックログという要望集を、スプリントと呼ばれる固定時間(1〜4週間程度で選択)内で、リリース可能なレベルの成果物として実現することで、素早い価値提供を可能にするための方法論です。

続きを読む

AWSはOracleみたいだから嫌い

そもそもAWSがOracleみたい、って感覚伝わるのかな。

 

どんどん新しいサービスがでてきてよくわからないとか

ベストプラクティスが日進月歩で新しくなるとか

なのに古いベストプラクティスに囚われてるマンがいたりとか

古いプラクティスを経緯や根拠を取っ払って〇〇は使うなっていうルールにして形骸化させちゃったりとか

資格がパスポートのような役割を果たしてるとことか

そのくせ資格ホルダーが使えなかったりとか

使いこなすこと(手段)と目的を混同してるマンが大量発生するとか

一般概念とベンダー固有概念の区別がつかないマンが大量発生するとか

サービスについて公式文書を見るとすごくフレンドリーそうな文面なのに結局なんだかわかんないとことか

すっごい簡単です、とか今すぐ始められますとかいう話がちゃんとできた試しがないとか

なんだかんだエバンジェリストのブログとか講演とかで超重要情報が明かされたりとか

特に性能面とか肝心なとこがブラックボックスなとことか

サポートに問い合わせると、原理上は正しく動作するはずですがあなた方で十分にテストしてください、とか平気で言われることとか

おま国とか

GUIがあるのに結局最後はCUIになったり、GUIとCUIのできることの差が激しかったりとか

胡散臭いパートナーが多いとことか

 

伝わります?まあ伝わらなくてもいいですけど。

続きを読む

「みずほ銀行システム統合、苦闘の19年史」が普通に称賛案件だった件について

各所で話題になってたみずほの本の話。

 

現システムは「大成功」

この本は3部構成になっていて、1部は稼働中の新勘定系システムMINORIの説明です。

 

本件、直接は知りませんでしたがネット上では「関わったら負け」と言われるほど悪評高く、また延期も2度行っていたので、勝手に「既存システムに〇〇を追加せよ、的な"阿吽の呼吸"の要求を元に開発して、レビューの名の下にしょっちゅう要件が追加されて、テストに入っても『運用が回らないから』とか言って要件が追加されて、出来上がったものはなんとか動いてはいるものの柔軟性のないそびえたつクソ」っていうよくあるパターン、銀行っぽいパターンなんだろうなと思ってました。

この本にもきっと「動き出しはしたものの3回目の大規模障害は時間の問題」的な裏事情が書かれているのだと思っていました。

 

しかし、第1部は予想に反してMINORIは「大成功」という体で話が進みます。

ハハッわろすと読み進めていたのですが、どうやらSOAの思想で構築された疎結合のシステムで、それゆえ機能追加時のテスト工数が減少でき、従来システムに比べて(そして競合他社に比べても)圧倒的に柔軟であるとのこと。実際たしかに本の記載を見るととても"良さそうなもの"が出来上がった感じがします*1

 

そして、読むにつれてプロジェクトの様々なことが「正しく」行われてるのがひしひしと感じられてくるのです。

驚きだったのは、要件定義にあたってasis(従来どおり・従来システムを踏襲)を全面禁止して、ユーザー部門に本来あるべき本質的な業務フローを1から考えさせてツールで表現させたというところ。

SOAはサービスやコンポーネントをいかに独立性/再利用性高く切り出せるかが鍵なので、正攻法ではあるのですが、本当に驚きでした。だってそんなことできた試しがないですから。

受託システム開発は「自分の業務すら正しく把握できない要求元が、システムを通じて浮かび上がってきた業務上の不整合を誰のせいだと揉める時間が大半を占める」というお約束で進むものであって、要求元の責務を果たそうとすること自体が珍しいのです。そして、よしんば本腰をいれてやる気があったとしても、そもそも現状と切り離して本来論を検討するというのはなかなかスキルが必要で、底力がないとできないことなのです。

しかもこれ、ちゃんと粒度や記載にばらつきがないようにみずほ側がガバナンスとってやってたらしいです。マジか。

考えてもみてください。「今の業務とはべつに自業務のあるべき姿を考えて謎のツールで表現してください。監査役からもろもろコメント入るかも知れないので対応してください。現行の業務システムから処理を書き起こすのは禁止です。」などというめんどくさい依頼を飲ませるだけでも相当大変ですよ?どれほどの苦労があったことか…

そしてSOAのサービス粒度はこの「あるべき業務」によって適切に決められたはずで、その事実だけでかなり"強い"システムが構築されたことがうかがい知れます。

 

その他プロジェクト運営に際しても痒いところに手が届くような施策をことごとくやっていて、圧倒的に「正しいこと」を頑張ってやったのが伝わってきます。またもや称賛。

例をあげるなら「最初に用語を統一する」話。さらっと書いてありますが、大企業で様々な部署がひしめく中、統一した辞書を作るだけでも超大仕事です。でもそれをしないとそのあとあらゆるところで困るので「正しい」です。そういう細かいことの積み重ね、間違った方向に行かないようにする施策がすごくたくさん出てきてだいぶスタンディングオベーションしたい気持ちになってきてました。

 

2回の延期も場当たり的に延期したのではなくて適切な時期に適切に見積もりを再評価した結果の延期で、うまくガバナンスが効かせられてたことが伺えます。

 

ひとつだけ、大丈夫か?と思ったのは「コードはすべてツールから自動作成」という記述。バグ修正などで正しい挙動を実現するコードはわかってるのに、それを自動生成させる手段がわからない、なんてことにならないかなあと。でもまあきっとそれを上回るメリットがあったのでしょう*2

 

ともかく、第1部を読み終わる頃にはなんか想像と違ったけどすごく良い本だな、という気持ちでした。

 

余談ですけど、第1部には新システムの操作教官として一般職から有志を募って教育にあたらせた話が出てきます(ちなみにこの人達が困らないようにバッチリフォロー体制もあった旨も記載あり)。その人達の現在の肩書がなんかすごいんです。出世した感が肩書きからもわかって、サクセスストーリー感がわくわくします。

みずほ経営陣は「人が育った」ことを大きな成果として認識してるとの記載がありましたが、さもありなんといったところ。

 

圧倒的クソな過去事案のせいで今がより輝く

第2部と3部は2011年の東日本大震災直後に起きた2回目の大規模障害と、2002年の合併直後に発生した1回目の大規模障害に至る軌跡の解説。

これはね、まごうことなきクソです。

 

2011年は(合併後のごたごたがあったにせよ)ずっとなあなあで動かしてきて、異常発生時のリハーサルしてないどころか異常発生時の例外フローすらない、なんならデータフロー図さえないシステムで障害起きて、非常時にもかかわらず全くリーダーシップを発揮できなくて解決まで10日もかかったという、想定以上のクソ事案。

 

2002年は、IT投資増加のために合併するというふれこみだったのに、CIOも配置せず担当レベルに検討を丸投げして、ベンダーと組みながら新銀行の主導権争いに奔走し、システム統合方針さえ二転三転した挙げ句、システム開発会社のできますやれますを鵜呑みにして見切り発車で大障害を起こすという、半沢直樹みたいな話ってほんとにあるんだな、と謎の感動すら覚えるほどの救いようのないクソ事案。

 

でもこれ、最終的に成功に終わることがわかってるので、これらの事案がマイナスに働くより、こんな文化の会社でようやったよな、という気持ちが止まらなくなるんですよ。

ほんの一年前までデータフロー図すらなくて平気だったような文化背景で、ゼロベースで本質フローを書き起こさせるだなんて、ようやったよなと。

合併先の片方にシステムを寄せる「片寄せ」すらまともにできず右往左往する文化背景だったのに、SOAで疎結合なシステムをスクラッチ開発とか、ほんとにようやったよなと。

よくこんなマイナスからのスタートでやりきったなと。

 

やっぱり合併前後くらいで入社して10年間くらいずっと「みずぽ(笑)」とか言われてた人たちが心を一つにしたのだろうか。

ぐうたらな社員でも「3度目やらかしたらマジでやばい」という危機感が共有できて一体感が醸成されたのだろうか。

いろんな想像をかきたてつつ、クソな過去が今をより輝かせるという胸熱な展開です。

 

でもホントのところも知りたい

まあでもちょっと出来すぎてるとも思うわけですよ。ホントのところはどうなんだと。実はみずほ主体じゃなくて裏でコンサルが暗躍してたんじゃないかとかさ。SOAなんて掛け声だけで実は従来通りのスパゲティ・モノリシックなんだとかさ。ただSOAは話半分だとしてもレガシーシステムと比べれば雲泥の進化だからなあ。

そもそもネット上の超悪評はいったいなんだったのかと。すくなくとも2011年以降は「正しい」ことを根気よくやってるようにみえて、ではなにをもってどんな視点でそこまでdisられてたのかと。

まああと最近できてるネット専業銀行とかに比べてアドバンテージはどうなんだろうな、とかは気になる。

 

なにはともあれ、とても良い本でしたし、無事やり遂げられたこと、心の底から称賛いたします。こういう話は元気が出るし、たしかに2025年の崖を乗り越えるヒントになるね。

ブラボー!

*1:というか旧来システムレガシーすぎるだろとビビる

*2:生コードは様々なスタイルで記載できるので、データとその扱い、異常時のポリシーのようなコーディングルールで縛れないような設計上の制約を均質化できるのはメリットかなと。