レビューは百害あって一利無し：雑感
タイトルは煽りです。実際は、レビュアーとレビュイーの力量次第でどっちにも振れるので、数値化して格言っぽく言ってみたところで意味が無い話です。
本題。以下を読んで、素晴らしい経験をされてるなぁと。いいこと書いてあるなぁと。
マイハートを鷲掴みにする各論ポイント、いくつかあるんですが、結論的に整理統合すれば、大きく言えば以下3つにまとまるかなと。
- レビューすれば解決するだろうと考える問題に出会った場合には、そもそもでレビューしなくても良い状態を目指して、基盤や環境、組織運営を設計したほうが実りが多い
- 組織には組織毎の成熟過程があって、それは人員数や売上の規模、各自の想いとは別に存在するもので、その成熟度と外れた挑戦は成立しない
- 単一のルールで縛った瞬間に、間違いだったと悟ったほうがいい
レビューすれば解決する？
レビューMTGほど辛いものはないです。レビュアーとレビュイーの技術的、経営（職務上のロール）的、人生的、語彙的な背景となる空間が違う上で、レビューする対象領域の定義からレビュー価値の共有、そのMTGでのゴールイメージを共有するっていう、当たり前の会議運営だけで、しこたま疲れます。
大方、比較してよりアホなほうがイラン事を言って場が壊れます。1時間分の時給x参加人数の管理会計コストをかけてまで開催して、決まったことは「再検討」だけ、っていう。
立場が違う、役職が違う人同士での所謂レビューは、私は今後不要にしていくべきだと考えてます。
レビュー（Audit）からAssuranceへ、です。
どうしてもレビューしたいなら、開発者同士での Pull Request ベースでのレビューやペアプロのように、同じロールでの熟練度の違い・観点の違いがあるメンバーで “レビュー” したほうが、実効性があり、持続可能な実践に繋がります。助け合い感が強く、実際、品質の向上が自分たちで実感出来ます。
それは、他の業務でも同じだと考えてます。営業、コールセンター、会計、人事、企画、それぞれ、同じロールでやるレビューの設計だと、妥当なインセンティブ・モチベーションの設計になります。
残念ながら、一部のコンプライアンス、監査アプローチでは、このレビューという言葉で、経営の技術への関与を促す言葉が書かれていたりするのですよ。だいたい、「レビュー」の定義（価値、目標、手段、語彙、マナー、評価基準、廃止基準）をせずに「レビュー」を始めてしまうので、ぐっちゃぐちゃです。レビュアーの腕が良いと、バランス良く着地するんですが、そんなのよほど自主的に学んでる人でかつ、人徳がないと難しいです。
レビューで解決する程度の問題なら、レビューせずに解決します。そしてそれは大概、言葉遣いの問題だったりします。
プログラムの品質の問題は、業務設計関連3割、アーキテクチャ関連3割、コード実装設計3割、予算9割（増えとるやないかっ！）って感じで、それぞれに、品質を保証する設計と随時の改修をしなきゃなりません。
なんですが、そんな専門性が高い設計を、役職・立場・都合・既知技術の空間が違う人がレビュー可能だと思います？
コードの断片に ( x => 0 <= x ) と書かれたとして、この顔みたいなコードをレビューアーが COBOL の知識しかないから業務水準でもレビューができない、レビュアーがレビューできるようにこの書き方を禁止する、っていう状況を正当化できるほど、世の中はもう余裕もなければ、楽な時代でもないです。
ここでも Audit から Assurance へ、なんですよ。
組織の成熟過程に合致しない事は続かない
書いてはみたものの、これ、成熟過程とはどういう状態であれば、どういう水準なのか、という各種の過去の定義をすべてひっくり返していく茨の道になるので、勢いでさらっと流すんですけどね。
今いるメンバーが、120％ぐらいの力量を目指して奮起する程度の挑戦でも、継続して改善の効果を発揮しつづけられるかは、半半だと思います。
IT運用でのマズローのほげ段階みたいなノリの話も多々あるので、興味ある人は調べてもらえばいいかなと思うですんが、何やってるからどのクラスで、我々は今どのフェーズにいるんだ、っていう理解を誰が始めたら、だいたい、もう、それはうまくいかないです。だって、現場が見えてないって公言してるんでっせ。
大手SIerで続いてる業務プロセスをベンチャーで正義だと導入しても、規模が違うし人も違うし、利益の出し方からしてまるで違うので、価値の評価に連続性がないわけで、続かないですし、逆もそうで、アジャイル時代だ！っていうので、古いサイクルでしか仕事してきてなくて、それに甘んじて誰かに何かを押しつけてひた人たちで、スクラム回そうとしても失敗します。
3週間単位で報告資料を作成させてMTGを開いていたら、それは月次定例報告会と変わりません。
背伸びは必要なんですが、今なら出来る事と、今は出来ない事ってのはあります。でも判断が難しいのも事実なので、そのサイクルの価値が共有出来たよな、と感じられるぐらいまで認識共有が出来た時点で、これ回るかねー、って相談するぐらいでもいいですよ。「我々には難しいかもしれないけど、これで価値を出しんだ！」って信頼される2割の人が信じられる事なら、それは回り出すはず。
単一ルールでやってみたものは価値が出ない
IT関連のニュースメディアでの成功体験の共有って、毒だよなぁ、と思います。それそのものをメディアとして伝える事にはありがたき、の言葉しかなのですが、そこで書かれている事が、必要としている人たちのそのタイミングで、実践可能な水準にある人に届くのかどうかは、まるで解らないですよね。
雑な例だと、時代はマイクロサービスだ！って言っても、対客向けシステムだとしても、せいぜい1000人が使う、ダウンタイムもある程度は許容されるシステムで、せいぜい1～2名程度でしか運用しないシステムに、マイクロサービス指向は、オーバースペックです。10万人が使う規模のシステムでも、作り方次第で似た便益を得られる設計ありますし、一方で、たった10人でも適切であると言えるシステムもあるでしょう。
なんですが、とはいえ、情報セキュリティの観点でいえば、どんな規模のシステムでも、XSRFなり、パスワード・セキュリティコード保存しない・ログにも出さない、基盤への侵入障壁を引き上げる、文字コードの問題、最大桁数の問題、入力値のバリデーション、SQLなりに投げる際にコマンドハック出来ちゃうような事にしない、ってのは考えないといけません。
PHPで1人で書いてる50万円のシステムでも、Go使って500万円なシステムでも、C#で2000万なシステムでも、Javaで2億なシステムでも、同じです。（同じですがリスク評価して適切なハンドリングする必要はあって、それがシステム・リスクのマネジメント）
これらの多種多様なバックボーンがあるなかで、標準フレームワークや基盤が提供される利点と、欠点てのは、必ず同時に存在します。
利点と欠点は、それぞれ、時間軸方向への影響も違うし、会計処理上の影響も違います。
理解してる人は、なんとなくそのメッシュ・マトリックスが頭のなかにあるんですが、それって高度な専門性でして、それに自覚的でない状態で、ルールだけを決めてしまうと、ルールの実践にのみ注力されていくので、だいたい失敗します。失敗というか、ぐだぐだになって活力を削ぎます。
これ、開発だけの話やないんですよ。いろんなところで起きるので、要注意です。
例外条項、バスケット条項で逃げられない日本語によるルールの強制は、だいたい失敗してしまうのに、例外条項がありすぎると機械での実装が大変になるというの、いつも誤解の種なので、大変ですな。
情報セキュリティ観点での動向として
モダンな情報セキュリティ（品質も情報セキュリティですよ）の流れでは、Auditでの限界を乗り越えていくための方向をプロセス運営（マネジメント・システム）として意識し踏み込んでいってます。
ルールベースで何かを定義しても、そのルールが有効となるスイートスポットが狭い領域でかつ短命な時代に突入してるので、プリンシプル主義的な方向に進んでます。という話は、また別のどれかの記事で。
その意味では、横断的な組織を作ろうとして挑戦したその行為そのものは、大変に評価されて然るべき実践で、今後の情報セキュリティのあり方論を前提にしても、大局的な方向としては確実にベターな方向だし、各論実践で厳しい/無理なところはあったとはいえ、その示唆に富む挑戦と経験は自信をもって頂ければなぁ、とえらそうに思いながら読んでました。
みんな同じ事で苦労してるんすよ。しかもだいたい、成功なんてしてなくて、誰が飲み込んで、誰が売り上げて、誰が支えてるか、って話だったりする。
一方で、そこに風穴を開けようとしてる動きってのもあって、情報セキュリティやプログラム開発という領域での設計から現場まで、高い専門性で議論してる人々は、改善するはずだと信じて、（ちゃんとした給料をもらった上で）日々努力してるのも事実。
