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年目ビジネスマナーの教科書