遙かなるマチョジニア

マッチョXエンジニアを目指すブログ

【書評】みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト 

これはやばそうな本が出たぞ。というワクワク感で買ったものの、 amazonの評価を見るとそうでもない感じだった。

www.amazon.co.jp

同じようなレビューが複数存在していて、なんか著者はみずほ銀行に忖度しているのかと思ってしまったが、 とりあえず読んでみることにした。

結果的にはレビューの通り、罵詈雑言が飛び交うものでもなく、現場の荒れ果てた状況が語られるわけでもなく、どちらかというと、すごいシステムを作り上げたという評価に近いものであった。

本は3部構成になっており、 1部が最近完成したMINORIというシステムについて、2部は東日本大震災直後のシステム障害について、3部は統合後の最初のシステム障害についてである。

2部、3部についてはいろいろ問題があって起こるべくして起きたと語っているものの、1部のMINORIについては、35万人月、4000億以上のコストをかけたすごいプロジェクトを成し遂げたんだ。という内容になっており、拍子抜けだった。

技術者であれば、人が増えることで一人あたりのパフォーマンスは下がることは経験的にわかるはずで、これだけの人数が携わっているならそれはもう想像しただけで恐ろしいと思うのだが、なぜかその苦難というのがあまり語られていない。過去の失敗から学び、大きな問題なく完成させたぞ、みうほは銀行の中でもリードしているのだ。みたいな。

まあ実態は違うんだろうけど、それでもまあここに語られていることが全てならば、予想していたよりもよいものができているんじゃない?と思ってしまう。

  • ブラックボックスの排除
  • 経営陣のIT軽視、IT理解不足の解消
    • IT理解不足の場合は、ソフトウェアが障害の原因なのにハードウェアベンダーの責任を問うなど見当違いが発生する。
  • SOAを採用
  • APIゲートウェイの採用
  • AS IS(現状のまま)の要件定義を完全排除
  • Xuppterを使って、「あるべき業務フロー」をゼロベースで検討
  • 超高速開発ツールを採用し、属人化を排除
  • Fintechとの連携を想定し、コア部分は自前、それ以外はオープンAPIを利用

まあ、言うは易く行うは難しだと思うので、MINORIが完成したことはすごいとは思うし、障害が発生しないで星いと思うばかりである。

【書評】「新しいLinuxの教科書」大まかな風呂敷の大きさがわかるつもりになれた。

GW中にざっと読んだ本。

新しいLinuxの教科書

新しいLinuxの教科書

仕事でubuntuはよく触るけど、あくまで実践的に触る程度で、 躓いたらその都度ネットで調べるというスタイルだった。

なのである特定のコマンドはしってるけど、/varがなんだとか/etcがなんだとかは知らないし気にしていなかった。 ネットで「そこにシンボリックリンク」とあればそうするだけだ!みたいな。

まあそれだと寂しいので、ちょっと前に、独習Linuxを読んだ。

独習Linux 第2版

独習Linux 第2版

  • 作者:小林 準
  • 発売日: 2011/12/17
  • メディア: 大型本

これはこれで良い本だった。中古で200円くらいで買った気がする。 ただ、まあ最近は「教科書」とかいうのが出てそれの評価が高いので、じゃあっと思って読んでみたけど、 まあ、わかりやすかった。

20のチャプターから構成されている。 最初にLinuxとは、から始まって、あとは具体的なコマンドの羅列、後ろの方にシェルスクリプトの実践やgitについての説明など。 程よく浅く網羅されているんだな、と感じた。とはいえ、Linuxの全体像を知らないから、これで全部かはわからないが。 これを教科書とするなら、風呂敷の大きさは大体わかった気分になれる。 実際はもっと奥深いんだろうが。

LPICなどの資格を受ける場合はこの範囲をさらに深堀りする必要があるだろうなと思うが、 とりあえずwindowsユーザーがLinuxを触るさいには、一読しておいて損はないと思った。

ただ、「教科書」というのは、実はただで入手できる。

Linux標準教科書

まあ、2700円払うのがもったいないなら、こちらですませてもいいと思う。

個人的な付箋

sshを使って、リモートホスト上のファイルを直接手元にコピーする方法。

ssh osumi@serverB 'tar czf - dir1' | tar xzf -

czf -と指定することで、リモートホスト上でディレクトリdir1をtar+gzファイルとしてアーカイブし、その出力をこちらのシェル標準入力へと渡している。 手元のシェルでは、受け取ったtar+gzのデータストリームをxzf -として展開することで、リモートホスト上のdir1ディレクトリを直接手元にコピーすることができる。

GW中の勉強内容

以下の通り。

  • udemy これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座(SAA-C02試験対応版)
    • セクション15/16完了
  • AtCoder
    • 165
    • 166
  • 読書
    • さあ、才能(じぶん)に目覚めよう
    • OpenSSH[実践]入門
    • 新しいLinuxの教科書
  • 勉強会
    • CDLE勉強会 #1

家族がいるのでフルタイムで勉強はできなかったが、 朝5時に起床して3、4時間勉強に当てた。 あとは寝る前に、読書。 ドラマと映画はまあまあ見たが、udemyの講座が終わらなそうなだったので途中から我慢。

udemyの講座はすごく有益だった。これがセールで1400円弱だと言うのは本当にすごい。

www.udemy.com

今はクラウド前提だし、クラウド前提の場合awsファーストで考えないといけないし、 という講師の見解があったが、勤めている会社はそんなのまったく触れ的てないどころか、 インターネットは敵であるみたいな考えだからまあ、未来は明るくないだろう。 会社をあてにせず精進したいが、やはりawsはお金がかかる。 この講座を受けるにあたってawsに課金した金額は約1000円くらい。 実サービスとして利用したらやはりかなりお金がかかるんだろうなと考えると、 個人での利用は厳しい。

とにかく、まだ理解できない点は多々あるので、これはblackbeltや書籍を買って補う。

できなかったこと

【書評】「さあ、才能に目覚めよう」は全く色あせていない

この本は、2011年に購入した。今は2.0というのがあるが、購入したのは1.0(2.0とついてないもの)。 勝間和代の帯が若干恥ずかしいんだけど、それは置いとく。

社会人も11年目になる、この本は入社して2年目くらいに買った本で、 何かのサイトでお勧めされていたと思われるが、そのまま積読してしまった。

そして今、自分は色々社会人として悩んでいる。 このままだらだらと仕事をこなすのか、思い切って環境を変えるのか。 そもそも自分は何がしたいのだろう?microsoftの澤さんがいうように、beingを考えたとき 自分はどうしたいんだ?と答えが出せなかった。

そんな時にふとこの本を思い出した。 自分の才能ってなんだろう。と。 そしてこの本にあるストレングスファインダーをしてみたという流れである。

この本は、7章まであるが、大まかに3部構成になっている。

  • 才能についての説明
  • 自分の才能の活かし方
  • 他人の才能の活かし方

前半中盤と、自分と向きあう内容になっており、これはこれですごく役に立つ。 まず自分の才能がなんなのか。 40分くらいのテストに回答すると、34種類の才能の中から特に特徴的な5つを発見してくれる。

自分の場合は、過去に述べた通りである。

shuheilocale.hatenablog.com

その才能をとりあえず受け止めることにした。 直感と外れていないし、自分にとってこうありたいという内容と近いからだ。

しかし、この書籍で(期待していなかったが)嬉しかった内容は終盤の 「他人の才能の活かし方」である。 昨今withコロナで働いき方が否応なしに改革されている中で、 この本に書かれている内容は非常に重要だと思う。全く色あせていないどころか、今読むべき本なのかもしれない。

さて、他人の才能の活かし方、と書いたが、 他人というよりも部下にあたるかもしれない。 これはマネジメントに近い話である。 部下に何を期待するのか、どう接するのか、どう評価するのかなど。

自分の場合は部下というよりチームメンバーにあたるが、 年齢的に一番上というのもあって若干マネジメントのようなこともしている。

その際に漠然と思っていたことがこの本に書かれていた。 自分の中では、こういうチームができたらもっといいのになと思っていたことが、 この本でその通りのことが書かれていて、すごく嬉しかったのだ。間違ってなかったと。

例えば下記。

ここの従業員を型にはめ込むのではなく、あくまで最終的な結果に重きをおくべきだ

日本の多くの企業がそうかもしれないが、多様性は基本的に認められない。 評価の多くは減点法であり、平均的にミスしない人間が評価される。 特別目立ったスキルを持っている人間を特別なタスクの担当にさせるようなことも滅多に起こらないし、 そもそもそのようなスキル発掘の場を設けていない。本当はあの人はすごいのに・・・もったいない。という人材がたくさんいるのだ。 彼らが評価されないのは、1種類の陳腐な物差しですべての社員を評価しているからだ。 さらにそれが過程の比重が大きいからたちが悪い。例えば残業して頑張っているかどうか、上司に好かれているかどうか。等。

研修にかける時間と資金は、従業員の弱点を矯正してスキル・ギャップを埋めるだけではなく、一人ひとりの強みを発掘し、それを伸ばすために費やすべきだ

社内研修や社外研修はあるが、本当に心の底からクソだと思ってしまう。この時間を返してくれと切に願う。 そもそも何のための研修なんだろうと考えると、管理部の自己満なんだろうなとしか思えない内容だ。 これで何をしたいんだろう、ビジネスマナーや論理的思考など、すっごい薄っぺらい内容だ。 なぜエンジニアが受けるのか。この疑問に対する答えは「社会人としての常識」などであろう。 でもそんな常識を立派に持っている人間よりも、バリバリ設計やコーディングができる人間の方がプロジェクトはうまくいく。

専門知識のある従業員とここの顧客との関係が尊重される知識経済の世界では、特定の分野にしろ、顧客情報にしろ、従業員の方がマネージャーよりもくわしいなどということがいくらでも起こりうる。そういう状況でマネジャーが従業員の決定や判断を覆すおそれががあるようなら、そんな企業はすぐに力をなくすだろう。

上司は、なぜか自分を偉いと思う。部下を教育するとか、部下をしかるとか、訳のわからないことを抜かす。 そのくせ仕事は承認印を押す、定例会議に参加するがメインである。 忙しいというのは、シャローワークだろう。誰にでもできる仕事で忙殺されている人間のどこが偉いのだろう。

自分は役職はついていない。そして役職をもらうための社内政治もするつもりはない。 今の会社では役職はいらないと思っている。この会社での陳腐なものさしで自分を計測されるのが嫌で仕方がない。 ただしチームメンバーやその他従業員に対して、一緒に何かを作り上げたいという気持ちはあるし、 彼らの人生を棒に振るうような飼殺し的なキャリアパスは避けさせたい。 そのための努力はしたいと思っている。

まずは自腹でチームメンバーにこの書籍を買おうと思う。 そしてお互いの才能を確かめ合い認め合うことから始めようと思う。

【AtCoder反省】AtCoder Beginner Contest 166

atcoder.jp

Dの問題が意外とあっけなくとけた。

解説より f:id:shuheilocale:20200504103321p:plain

範囲については真面目に考えなかった。とりあえずえいやでいいや。みたいな。 あとは、大体考え方は同じ。

X = int(input())

a = [int( i/2)*((-1)**i) for i in range(1, 1000)]
b = [int( i/2)*((-1)**i) for i in range(1, 1000)]

"""
1 Aが正ならBは負または、Aより小さい正
2 Aが負ならBは負
3 X/(a+b)は、1以上の整数
"""

find = False
if X == 0:
  print(0)
else:  
  for a_ in a:
    for b_ in b:

      if a_ + b_ == 0:
        continue
      if a_ >= 0:
        if b_ >= 0 and b_ > a_:
          continue
      if a_ < 0:
        if b_ >= 0:
          continue
      """
      if X%(a_+b_) != 0:
        print("hoge")
        continue
      """
      if (a_**5) - (b_**5) == X:
        print(f"{a_} {b_}")
        find = True
        break
    if find:
      break

3 X/(a+b)は、1以上の整数

については、n乗同士の差の展開式で (a+b)(a4−a3b+a2b2−ab3+b4) = X となって、 (a4−a3b+a2b2−ab3+b4) = X/(a+b)

となるから左辺が整数だから右辺も整数になると思って制限設けたけどうまくいかなかったので外した。

自分はinputが何行にもわたるものが嫌いだ。だって面倒だから。 今回はBもCもそんな感じだった。けどそれで食わず嫌いしてると点数が稼げないんだろうから そこをちゃんとテンプレート化して楽になるようにしないといけないなと思いました。 環境も今はgoogle colabでやってるが、 ちゃんとした物を作りたい。けどめんどうなのでとりあえずほったらかし。

【AWSソリューションアーキテクト】Route53、データベース

Route53を利用したフェールオーバーな構成を実習した。

構成は↓ (udemy講義から引用

f:id:shuheilocale:20200504101414p:plain

この場合の構成を別リージョンに構築するときは、 構成をそのままコピーするよなコマンドはなくて全部手作業で作る。 超面倒な作業だしミスも発生しそう。

ついでにデータベースについても座学だけ。 実習は一旦飛ばした。お金がかかりそうだから一気にやれる時間を確実に確保しなければいけないから。

以下メモ書き


  • データウェアハウス
    • Redshift
  • 分散型DB/データレイク
    • S3
  • KVS
    • ElastiCache
    • DynamoDB
  • ワイドカラム
    • DynamoDB
  • ドキュメントDB
    • mongoDB
  • インメモリデータグリッド
  • 全検索型エンジンx分散DB
    • Elasticsearch Service
  • グラフDB
  • 分散OLTP

Aurora、Dynamo、EFS、kinesisについてはハンズオンをする。

【AWSソリューションアーキテクト】信頼性の設計

ELBとRDSを使った。

ELBは、最初設定ミスって違うAZを指定してしまっていたので、 これを変更するのに手間取って結局VPC削除して作り直した。 もっと簡単に変更できるんだろうけどこういう入れギューラなパターンに対して対応できないのは素人の証拠。

RDSは作成と削除がとにかく遅い。 作成で数十分待ってても「作成中」のバナーが消えないと思ったら、既に作成されていた。 削除についてはレプリカの削除の時点でおっそい。

作った構成は下記(udemy講義 から引用) f:id:shuheilocale:20200503102855p:plain