Murga

個人的に言いたいコト・主張・気持ち。

契約による設計・契約プログラミングが少しワカッタ

「契約による設計 Design By Contract」とか「契約プログラミング Programming By Contract」とか、単語は聞いたことあったけど何するもんなのかよく分かんねーなーと思ってた。

Wikipedia の記事を抜粋するとこんな感じ。

プログラムコードの中にプログラムが満たすべき仕様についての記述を盛り込む事で設計の安全性を高める技法。

契約は、コードの利用条件が満たされることによって成立する。 それら条件は、満たすべきタイミングと主体によって、以下の3種類に分けられる。

  • 事前条件 (precondition)
    • サブルーチンの開始時に、これを呼ぶ側で保証すべき性質。
  • 事後条件 (postcondition)
    • サブルーチンが、終了時に保証すべき性質。
  • 不変条件 (invariant)
    • クラスなどのオブジェクトがその外部に公開しているすべての操作の開始時と終了時に保証されるべき、オブジェクト毎に共通した性質。

何かをコードに入れることでどうにかすんだろーなー、とは分かるが、何を書くことを指しているのかがよく分かっていなかった。

そしたらコチラの記事を見つけた。

とても分かりやすい。

つまりこういうことだ。

  • 事前条件 (Precondition) : 引数チェックしろってこと。
    • IllegalArgumentException を投げる実装でも良いが、ひととおり実装が終わった後に「想定外の値」が飛んでこない確証があるのであれば、アサーション (assert()) で書いおいても良いと思った。
    • アサーションの良いところは、開発中のビルドではコードが残るのでチェックできるが、プロダクション・ビルドの時はアサーションのコードが除去されるので、実行速度が落ちないという点。ただし、もしもその上で例外が発生した時は、スタックトレースが追いづらくなる恐れはある。
    • 関数を呼ばれた側が、関数のド頭で引数チェックをする実装が基本。事後条件と並べて「入力」と「出力」を保証できる。入力仕様はその関数の作りによって決まるだろうから、呼ばれる側に実装しておけば間違いない。
    • 関数を呼ぶ側が、呼ぶ直前に設定する引数をチェックするような実装もアリみたい。このやり方の注意点は、呼び出す関数の仕様が変わった時に、許容しているはずの引数のパターンをアサーションエラーにしてしまうような「修正漏れ」が起きそうなところ。
  • 事後条件 (Postcondition) : return する値の仕様チェック。
    • 「この関数では計算結果が負数になることはない」とか「データがない場合は空の配列を返す、null は返さない」みたいなことが決まっていれば、それを return の直前assert() しておく。
    • アサーションで実装し、単体テストと結合テストが済んでいれば十分だとは思うが、別に例外をスローするような実装にしても問題はなさそう。
    • 関数を呼んだ側が、受け取った戻り値を検証するような実装は見かけなかった。
  • 不変条件 (Invariant) : クラスのプロパティの値を変更する時にチェックする。
    • クラスの関数を呼ぶ前、呼んだ後で変わらない条件のこと。なので、全ての関数の最初と最後で、同じ条件をチェックする、というのが最も律儀なやり方。
    • そのような不変な条件って、クラスのプロパティの仕様ぐらいなので、プロパティに値を代入する直前にチェックすれば良い、と考えられる。
    • this.num = num; の直前に assert(num > 0) とチェックしたり
    • this.itemArray.push(newItem); の直前に assert(newItem != null) とチェックしたり
    • setText(text) のような Setter 関数のド頭でチェックしたり
    • という登場位置が妥当。

なーんだ、コレってほとんど普段から俺がやってることじゃん。と思った。アサーションは言語によっては使わないけど、関数の頭で引数チェックしてるし、関数の最後で戻り値のチェックしてるし、Setter 系の処理の所では引数チェックと同じノリでチェックしてるし。コレが契約プログラミングだったのか。

防衛的プログラミングとの違い

似たような言葉で、防衛的プログラミングという考え方もある。コチラは以下の記事で要領を掴めた。

起こりそうな例外を予めチェックしておき、例外を発生させないというプログラミング手法だ。

関数の引数チェックでは、null などの異常値を空文字に変換して処理を続行させたり。処理中の例外は catch して、何らかの初期値に差し替えて処理を終了させたり。

このようなコーディングもよくやってる。JavaScript の場合は nullundefined のような Falsy な値のチェックと変換が必要になることが多いので、そういう癖がついたと思う。

言われなくてもやってたわ

こんなの「契約プログラミング」だの「防衛プログラミング」だの、大層な名前を付けずとも当たり前にやってることだろ、と思ったんだけど、違うのかしら。「概念を知らないと意識できない」とは思うが、僕はこれらの手法の概念を理解していなかったのに、「こうやれば色々防げるでしょ」って思い付いていた。ということは誰でも思い付く程度のことだろう、と思うんだけど、違うのかしらねぇ。

俺が弊社に指摘していた「認識の甘さ」が大事件になってたご報告

(※ 多分にフェイクあり)

弊社は技術力の高い人間はまぁまぁいるが、ビジネスコミュニケーションスキルが皆無だったり、契約や書類仕事が低品質で雑だったりする。「俺達は技術力で戦うぜヒャッハー!」的な学生っぽいノリだけでやってきた小さい会社なので、

  • 見積書の計算ミス・ゼロの数の間違いは当たり前
  • 他社の製品紹介資料を丸パクリしただけの提案資料を平気で作る
  • 「押印必須!」と言われている経費精算申請書を電子提出しても何も言われない
  • 社内ネットワークに縛られた客先に、個人の PC と Wi-Fi 端末を持ち込んで自由に作業

…など、社員のレベルの低さ、質の悪さの事例を挙げたらキリがない。

そして最近、最後に挙げた事例をやらかしていた数名が客先にバレて、こってり絞られたらしい。その中には自分の組織上の上司もいた。チームとしては自分と上司は別れていて、その上司のいる現場には自分も時々訪れるくらいの関係だったが、そのチームを見ていると色々と野放し状態だった。だからその上司には前々から

  • 「誤字脱字とかいうレベルじゃなくて、提案書でこんなひどい間違いしてたらダメですよ」
  • 「社内ネットワークの外に出られるプロキシサーバ、って…これ、セキュリティ的にまずいっすよね?」

などなど指摘していたのだが、その人は

  • 「まぁウチの会社って技術で売ってるじゃん?こういうドキュメントの品質とかは二の次でいいじゃん」
  • 「セキュリティにはアレかもしんないけど、この方が早いじゃん?」

と調子の良いことを言うばかりで、全然改善されなかった。


それが先日、お客様のお偉いさんがフラッとその人の現場に立ち寄った時に見つけたらしく、

  • 「あれコレ、ポケット Wi-Fi じゃーん、会社貸与の端末に繋いだらダメやで!」
  • 「え、つか、コレ会社貸与の PC じゃないじゃーん、個人のなんか勝手に持ってきたらダメやで!」
  • 「うわしかも社内ネットワークに勝手に穴開けてんじゃーん、禁止事項やで!」
  • 「おたくのセキュリティに対する認識マジ疑うわー」

と怒られたようだ。そりゃそうだ。


自分の前職は金融系だったので、セキュリティルールはバカみたいに多かった。それらのルールと、システムポリシーによる技術的な縛りによって、悪さはできなかったし、やらかした悪さは必ずバレる仕組みになっていた。

技術屋としては、非効率なばかりでマジでくだらないなと思うようなルールも多かったが、客が自分の身を守るために考えたルールとしては、納得できる一面もあった。

そんな現場に新人で入って、面倒だけどそれが当たり前、この面倒臭さには意味がある、という水準で育ってきたから、現職の緩さは「作業効率のため」とかいうレベルの話ではなくて、ただ単にセキュリティリスクを甘く見てサボってるだけなのは明らかだった。


で、「我が社の社員たちはセキュリティの認識甘い!教育しちゃる!」と意気込んだ弊社上層部がセキュリティ研修を始めたんだけど、その人が作った「力作」の教育資料もひどい有様。誤字脱字は当たり前、説明も下手クソだし、「本来取るべき対策」として書かれている内容がことごとく「全然足りないだろそんな対応じゃ…」ってモノばかり。

おまけに研修に参加させられた弊社社員たちの意見や質問がことごとくバカ。

  1. 「客先に持ち込んでいる、弊社貸与の PC で、ウイルスバスターによる週次チェックを行っていると思うが、それがウイルスを検知したら、ネットワークを遮断して上長に報告するんだぞー」という話に対して :
    1. 「会社貸与の PC にウイルスバスター入ってるんですか?」
    2. 「週次チェックって勝手に終わるけど、ウイルス検知した時は何かメッセージ出るんですか?」
  2. 「基本原則は、『業務に関係のない作業を客先でしないこと』だからな!今お客様に怒られている以上、この基本原則に立ち返って、自分の日頃の作業を厳しく見直すんだ!」という話に対して :
    1. 「え、じゃあ、業後の飲み会のために食べログ見るのはダメですか?」
    2. 「どこからが良くてどこからがダメなんですか!」(なぜか逆ギレ)
    3. 「それがセキュリティ的に大丈夫なのかよく分かんないときって、どうしたらいいんですか?」
  3. 「この初回のセキュリティ研修に招集した連中は、やらかしたメンバーと同じ客先にいる連中だ。セキュリティに対する十分な認識を持って業務に取り組んで欲しい」という締めの話に対して :
    1. 「このセキュリティ教育、他の社員にはやらないんですか?」

一つずつツッコんでいくぞ。

  1. 会社貸与 PC のウイルスチェックと発見時の初動 ← 当然やるモンだよなぁ。分かる。
    1. 「ウイルスバスター入ってるんですか?」 ← 「入ってるのか知りませんでした」って平然と言えちゃうの、クッソ恥ずかしいな?w
    2. 「検知したらどうなるんですか?」 ← 同上。つか正常終了してるかどうか分からないってことは、何が動いてるのか気にしてないんだろ。定時チェックが正常終了しているかどうか、レポートを毎回見ろよ。
  2. 基本原則 ← 意識的な話だけじゃ何も理解できそうなバカどもばっかりだけど、言ってることはそりゃそうだよね。当然そうあるべき。
    1. 「食べログダメですか?」 ← このレベルのことを聞かないと分かんないヤツ、ヤバくない?業務と私用の境界線に関して論じる時間じゃねえんだぞ?グレーなことをやろうとすんなって。
    2. 「どこからがダメなんですか!」 ← 具体例を山ほど列挙したら理解できるようになるとも思えないし、ただのクソバカ。そのくらいの判断能力は持った状態で入社しろや
    3. 「分かんない時はどうしたら?」 ← 上司と客先に質問して許可をもらうんだよ当たり前だろ。その後も「どうやって許可を求めるメールを出したらいいんですか?」とかほざいててアァーマニュアル人間。テメェに関数定義してやる時間は取れねえよ親じゃねえんだから。
  3. 締めの言葉 ← そうやって「意識」とか根性論みたいな言葉で逃げてきて社員教育をまともにしなかったツケがこのザマだろ、とも思うけど。
    1. 「他の社員には研修やらないんですか?」 ← それ今聞いてどうすんの?つかお前やらかした本人だよね?なに会社全体のこと案じ始めてんの?お前の身を案じろよ懲戒処分級なんだぞ。

他にも腐るほど頭の悪い質問が飛び交っていて死にたくなった。

総合的に見ると、こういうところがバカ。

  • この研修がなぜ開催されたか、自分たちに求められるアクションは何かを理解していない。
    • 事の経緯は1時間かけて説明されたし、情報不足ってことはないはずなんだけど。
    • この研修を受けた社員には、こういう行動を取って欲しい、こういう行動は取って欲しくない、という狙いがあって、研修が開催されていることは明らか。そこを全く読み取れていない。
  • その質問に答えてもらうことで、何を得ようとしているのかが曖昧なまま質問している。
    • 「この研修を全社的にやりますか?」とか、お前が聞いてどうすんだって。やらかした犯人なのに。
  • 「こんなことも知らない・判断できないと思われたら恥ずかしいなー」という判断すらつかないまま発言している。
    • 「ウイルスチェックされてるんですか?」「この具体例はダメですか?」「どうしたらいいですか?」
    • その質問されて、上司がソイツをどう評価するか。つまり自分がどう評価されるか、ちっとも考えてない。
    • 「分からないことを分からないままにしない姿勢」は良いことだが、質問のレベルが低すぎるからアウト。
    • マジでセキュリティリスクに対する認識がクソ甘いんだなコイツら。

色々とクソバカで、上層部含めてビジネススキルがまともにあるヤツ一人もいなかった。俺が当たり前だと思うレベルって、そんなに高い水準の話だったのかな。それともこの会社の水準が極めて低いのかな。個人的には後者だと思うけど。

コレでも色々フェイク入れてて、実際はもう少しで新聞沙汰なところだったから、弊社の人間どもマジで気をつけろ。

これだけは知っておきたい!大人の常識力大全 (できる大人の大全シリーズ)

これだけは知っておきたい!大人の常識力大全 (できる大人の大全シリーズ)

入社1年目ビジネスマナーの教科書

入社1年目ビジネスマナーの教科書

クラウドやるならアプリやインフラの垣根はなくさないと

フェイクあり。

オンプレからクラウドへのシステムリプレイス案件に携わった。PM はイベントに登壇して「エンタープライズにおけるクラウド移行の勘所」みたいなのを語ってるような人だったので、さぞ見識が深いのだろうと思っていたけど、いざ蓋を開けてみたら何にも分かってないことが判明した。

インフラの構築コストと設計コスト

確かに、クラウド化によって、サーバ構築の手間は物凄く減った。マシンスペックを選択してボタンポチーして鼻ホジーして待ってたらサーバが出来上がる。ミドルウェアや監視ツールをプリインストールしてくれるような機能もあったりするし、スケールイン・スケールアウトも容易だ。

ただ、当然ながら、インフラ構築はコレで終わりではない。

サーバインスタンスに直接 Public IP を振ると冗長化しづらいし、侵入の危険性もある。そこで、仮想ネットワークに閉じてインスタンスを配置し、インターネットからの流入口はロードバランサに集約する。その上で特定のポートだけ開放して LB とインスタンス間の通信を許容するよう、ファイアウォールを設定する。DB が絡んだり、クラウド外のシステムとの連携があるとさらにネットワーク構成が複雑になる。

ココまでは、クラウドに限らずオンプレでも同様に考慮すべき、インフラ設計の一般論。

クラウドサービスを利用する場合は、どうしてもそのクラウドベンダごとの仕様や特徴に合わせた考慮が必要になる。サービスの仕様上、この外部サービスとの連携は出来ないだとか、PaaS の場合は IaaS ほどチューニングの自由度がないだとか。

先述の PM は、この「クラウドベンダごとの特色に合わせた思考」が全く出来ない人で、旧態依然なオンプレ思考が色濃く残る一般論でしか喋れず、「何で自分が思っているように簡単に行かないんだ!」とお怒り。ウーン、でもこのクラウドベンダに決めたのアンタだから、少しは勉強してくれ。

インフラ設計はアプリに依存する

さて、システムを構築するにあたり、サーバのスペックや冗長構成はどのように決まるだろうか。

それらの要件を決めるための視点は、一般的には以下のようなモノが考えられる。

  • システムの利用者数 → システムが捌きたいリクエスト量
  • システムが扱うデータのサイズ
  • スループット (処理時間。ある処理をどれだけの時間内に終わらせたいか)

システムの利用者数は、そのシステムがどんなシステムかによって決まる。社内向けなら人数はそこまで多くないだろうし、B to C な Web システムなら百万人規模のアクセスを見越すことも当然ある。

システムが処理するデータ量や、期待する処理時間を決めるにあたっては、そのシステムの実装が大きく影響してくる。ミドルウェアより上の、ソフトウェア = アプリケーションの領域で、どのようにシステムを実装するつもりかによって決まってくる話なワケだ。特に、スクラッチではなくパッケージを利用している場合は、予め最低スペック要件が提示されているはずだ。

要するに、サーバのスペックや台数を考える時は、そのサーバに載せるアプリのことをよくよく把握しておかないと決められないというワケだ。当たり前のことだが。

「インフラチーム」と「アプリチーム」という垣根

それなのに、PM の思考はオンプレ寄りなので、「キミたちはインフラ担当」「キミたちはアプリ担当」とチームを別けてしまった。

コレだと、アプリ担当の人間は自分達が使用するパッケージと、それを活用した実装部分にしか目が行かなくなり、ハード (= インフラ) 的な視点が欠落してしまう。逆に、インフラ担当の人間も、アプリ担当が何を使い、どう実装しているのか分からない (分かりにくくなる) ので、どんなウワモノが乗るかが分からず、完全に推測でハード的なスペックを決めたりしないといけなくなる。

インフラとアプリがチームとして分断されると、ミドルウェア領域の話が宙に浮いてしまう。DB と接続するデータソースの定義だとか、JVM のヒープ設定だとか、そういうミドルウェア領域の設計・実装は、アプリ担当とインフラ担当のどちらがやるの?というところがうやむやになり、お互いに押し付けあってしまう。

アプリ担当的には「マシンスペックとか決めたのはインフラ担当なんだから、その情報をベースにミドル設定もしてよ」と思いたくなるし、インフラ担当としては「そのアプリが必要な設定はインフラ側では分かんねえよ、お前らアプリ担当の連中が握ってるんだろうからお前らがミドル設定しろ」と言いたくなるワケだ。

インフラチームが別部隊に別れる組織構造は、オンプレ時代はよくあった話だ。物理的にサーバを調達し、会社のサーバルームで物理的に構築していくワケだから、アプリ開発する人間とは地理的にも離れるし、専任性が高まるのは自然な話だ。

この場合、システムを載せるとなると、「アプリ担当チーム」にあたる人間たちが、自分たちのシステムに必要なマシンスペックを計算し、「インフラ担当」に連絡してサーバを調達してもらっていたはずだ。インフラチームも自分たちの専門知識の範囲でハード寄りのアドバイスなどはするが、主導するのは「アプリ担当」側、といってよかったはずだ。そして、インフラ構築が終わると、LB やサーバの IP アドレスがインフラ担当からアプリ担当に連絡されるので、あとはアプリ担当がミドル含め設定していく流れだ。

物理的にも距離が離れているからこそ、このようなコミュニケーションルートが自然になっていたと思う。しかしそれはオンプレ時代の物理的な制約による組織構造であり、クラウドを活用するにあたっては邪魔でしかない考え方だ。

仮想化技術により色々なリソースが抽象化されているので、オンプレの感覚だけではなくクラウドに知見を持った人間がいないと、上手く話が出来なかったりすることはある。それでも、ハードウェア選定はウワモノありきでしか決められない、もしもそうでないなら、先に決めたハードのスペック内で出来ることがアプリの要件になる、という2択には変わりないはずだ。

だったら、アプリチームとかインフラチームとかいう別け方は止めて、まずは全員でアプリ寄りな視点でのシステム要件を洗い出し、それからその要件に見合うハード面のスペックを選定すべきだと思う。

インフラに知見のないプログラマばかりが集められた

コレは先述の PM が自分のコネだけで要員を調達してるからという弊害なのだが、チームの SE やプログラマは、いずれもアプリケーションの開発工程くらいしかまともにやったことのない人達が集められていた。年齢だけは重ねてるんだけど、要件定義や概要設計を経験した人間がほぼいなかったのだ。

だから、そもそもシステムの要件ってどんな要素があるのかとか、ハードウェアの性能をどうやって決めたらいいのかとか、「そういうことを考慮する必要がある」ってことすら認識していないレベルだった。

そしてクラウドの活用経験もないのに、なぜかクラウドに関しては「簡単に構築できるもんなんだろう」「とにかくお手軽で楽なんだろう」と思い込んでいて、「オンプレからただクラウドに引越しするだけっしょー?」と軽々しくのたまっていた。

先程「アプリチームとインフラチームで組織的に別けられた」と言ったが、インフラチームに割り当てられた人間たちも、こういう連中の中から適当に決められただけだった。「クラウドって GitHub ですか?」「Terraform…?TeraTerm ではなくて…?」みたいなレベルの人間たちだったのに、いきなりインフラ設計を任されてしまったのだ。

こんな感じだったから、「サブネット」の概念も分からず、ファイアウォール設定もされてない、マシンスペックの選定もパッケージの仕様を考慮してないからほとんどデタラメという有様だった。さすがに有識者からツッコミがあってだいぶ是正されてきたものの、これら諸問題の原因は明らかだった。

つまり、クラウドを使うということは、これまでサーバルームにこもって作業していた「インフラ担当」の仕事を、全てアプリ開発者が巻き取ることに他ならないのだ。オンプレ時代なら「インフラ担当」に任せっきりで知りもしなかった分野も、彼らに頼らずクラウド化するとなると、アプリ屋がハードやネットワークの設計が出来ないといけないワケだ。

勿論、個人の趣味レベルの話ではなく、エンタープライズレベルの堅牢さ・安全性が求められるワケだから、クラウド未経験とかインフラ知らないとか、そんなメンバの都合は関係なしに、「この水準以上のセキュリティは担保してもらわないと…」と社内稟議で突っ込まれるのは当然のことだ。

リリース後のことも考えて

アプリを開発するだけのプログラマは、リリース後の運用保守作業を知らない。運用保守とは何をするのか、何に手間がかかるのか、そういった知見がない。

それはその人が書くコードを読んでいても分かる。保守改修を経験してきた人のコードはリーダブルだが、開発しては転属を繰り返していた、「作り逃げ・作り捨て」が板に付いている人のコードは、読めたもんじゃない。

そういう開発屋さんの感覚では、「リリースを迎えたら仕事は終わり」なのだが、今回の案件は、クラウドリプレイス後の運用保守も、そのチームで引き受けることになっていた。

ということは、サーバの高負荷やヘルス監視、そして検知したら迅速に復旧対応、といったタスクが増える。じゃあ監視はどうするの?というと、コレもオンプレ時代は「インフラ担当」に任せっきりで、どう監視したらいいのか、何を監視したらいいのか、といった知見がなかった。

一応、24時間・365日の運用監視が必要になるという名目のシステムなので、夜間監視は別会社に委託するワケだが、委託しようにも説明資料が何もない。素人たちが混乱を極めるプロジェクトで、仕様書や手順書なんてモノは一切作られていなかった。

高負荷対応やシステム復旧に関しては、どうやらクラウド関連のバズワードを仕入れた人間がいるみたいで、「Jenkins サーバを立てといて、オートスケールしたり、インスタンス生成やアプリのデプロイを自動化したりしましょう!DevOps ってヤツです!」って意気込んでた。運用コストも下がるだろうってことでやることになっていたのだが、「Jenkins サーバ」とか言ってる時点でお察し。巷の CI・CD ツールには目もくれず、考慮不足の自前スクリプトを時間かけて実装して、後で全然実用に足りないことがバレて大問題になった。

一連の問題に気が付かない PM

ココまでの話から容易に察してもらえるだろうが、このプロジェクトの PM は、自分の考えに固執するタイプだ。自分の考え (一般論) が正しいし、それで上手くいくと本気で思っているのだ。ハードやインフラの知識がない人ではないのだが、オンプレ時代の「インフラ担当」に任せてきた仕事をまるっと巻き取ることの難しさには全く気付いていないようだった。

「インフラ担当を任命したし、あとは上手くやっといてもらえるもんだろう」と思ったのか、PM は要件定義段階から雑にフェードアウト。渡された見積書にもロクに目も通さず OK を出し、なんとなく開発がスタートしていた。

オンプレからのリプレイス案件だと言いつつ、アプリ改修も同時に大量に行っちゃう、よくあるバカな案件だったので、アプリ担当は改修作業で手一杯だった。インフラ担当も、慣れないクラウドの壁にぶつかり、数々のトラブルが多発していた。

PM が異変に気付いたのは、結合テストが完了予定日を2ヶ月過ぎても完了していなかった時だった。アプリ担当とインフラ担当の間で情報共有、知識ベースのすりあわせがされないまま、中途半端にお互い隠蔽体質なまま進んできたので、アプリをクラウドサーバに載せた後でトラブルが多発していた。ミドルウェアの設定もそうだし、アプリの都合によって「ロードバランサでこういう制御が必要だ」みたいな話が出始めたりしていた。

さすがに PM もヤバいと思ったようで、クラウドの有識者を雇ったのだが、そもそも根本的にインフラ設計に欠陥があることが判明。しかしその時点で構築されていた構成は、PM が雑に承認した見積に沿っているモノで、欠陥を改善するためにはその見積よりも大きな金額がかかることが明白だった。

開発工程も半ばを過ぎたところで、いまさら見積の不備を指摘される PM。明らかに予算が足りず、リリースにこぎつけられるか、リリース後の運用体制が整うかも分からなくなった。

読んでいなかった (もしくはクラウドの知識がなくて読解できなかった?) 見積書とはいえ、責任は PM にある。本人もパニックみたいで、「何でこんなことになるまで誰も言ってくれなかったんだ!」などとのたまっていたが、いやもういい歳した大人が「誰かに注意してもらわないと私は見積書を見過ごしちゃいます」と告白してるのに等しい発言はさすがに吹き出しそうになった。有識者からは「でもあなたがこのおかしな構成で承認しちゃってますから、認識してるはずだと思ってましたが…」と正論を言われ、苦し紛れに「この見積作った奴連れてこいや!」と怒鳴り散らしたりしてた。片腹痛い。

実は自分はこの頃にテコ入れとして雑に投入されたメンツの一人なのだが、既に1年近く開発してるはずなのに全然成果物がなく、最初は全然状況が掴めなかった。あちこちにヒアリングして回った感じだと、みんな自身がこの案件の内容に対して実力不足なのは薄々自覚してて、恥ずかしかったり、言いにくかったりして、内々で問題を抱え込もうとする傾向にあるのが分かった。だからアプリチームの都合はインフラチームに聞こえてこないし、インフラチームもアプリチームに何か言われるまで黙ってたりしたみたい。

組織構造どおりのシステムが出来上がる、「コンウェイの法則」という言葉があるが、このシステムはまさにこの法則を体現している。いや、構築が出来ていればまだいいんだけど、今のところまともに動かないからね。下手したら UAT (ユーザ受け入れ・ユーザ承認テスト) で却下されてリリースできないかもしれない。

個人的には、そもそもこのプロジェクトに絡まされた意味 (経緯) が分かんないので、どうにでもなったらいいのに、と思っている。一般論しか知らず「クラウドは楽だ」と思い込んでた連中が、いざやってみて「全然上手く使えなかった」と挫折してゴメンナサイする姿が見てみたい。そのくらいのお灸をすえてやった方がいいと思う。

クラウドは全領域に深い知識が要る・全員が高いスキルを有していないとダメ

ココからは、このチームがこうだったら成功していただろうな、という感想。

何度か述べたとおり、クラウドというモノは、アプリケーションそのもの以外に、ハードやネットワーク、運用に至るまで、システムを構成する全ての領域に対する設計が要る。設計をするには知識が要る。すなわちフルスタックでないとならないのだ。コレは IaaS だろうと PaaS だろうと FaaS だろうと関係ない。コンテナ化しようがしまいが、システムをクラウド上で動かすためには、アプリ領域だけではダメで、インフラ領域も知らないといけないのだ。

そして、チーム内で役割分担がある程度できるのはいいのだが、「アプリ領域を知らない人」「インフラ領域を知らない人」がチーム内に1人でもいると、恐らくクラウド活用は失敗する。全員がフルスタックでいるべきだ。

リーダや PM 層になると、日本では実際に開発したり手を動かさない場合が多いが、個人的には、クラウドを活用するなら上の層の人ほどコードを読み書きして、何についても一番詳しい人間でいないといけないと思う。メンバに丸投げしていい分量ではないし、全領域を俯瞰しながらのハンドリングが重要になるので、上に立つ人間は誰よりも賢く、実態を正確に知っていないといけないのだ。細部を省略していたり、一般論で語っていてはダメだし、Terraform や CLI ツールは当たり前に使っていないといけない。

「そんなの無理ゲーじゃね?」「そんな優秀な人いないって」

うん、そうだと思う。だからそういう素人しかいない古臭い日本の企業は、オンプレからクラウドへの移行なんて難しいこと止めた方がいい。彼らにはコレをやる能力がない。

クラウド化する世界~ビジネスモデル構築の大転換

クラウド化する世界~ビジネスモデル構築の大転換