コードレビューのアンチパターン(とパターン)

@nihonbuson さんから、アジャイルでのレビューについて話してほしいというご相談をいただいた。そういえばレビューについてあまり調べたことがないし、カンファレンスでもテーマとしてそれほど聞いた感じがしない。

 森崎先生が書かれた連載が本になっていて大変勉強になったのだけど、ご本人曰くこれは設計レビューであってコードレビューではないとのこと。スプリントレビューもまた違う観点もあるかなと思いつつ、指摘のダメパターンはだいたい共通している気がしている。

なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー改訂版（日経BP Next ICT選書）

Erik Dietrich さんの Manual Code Review Anti-Patterns という記事が出てきた。

blog.submain.com

• The Gauntlet - ガントレット - 審査員が撃ってくる
• The Marathon - マラソン - 長くて枝葉末節
• The Scattershot Review - 乱れ打ち - 指摘に一貫性がない
• The Exam - 試験 - 説明によって合否が決まる
• The Soliloquy - 独り言 - 本当にレビューしてる？
• The Alpha Dog - アルファドッグ - 特定の人々が牛耳って学ぶ意欲がなくなる
• The Weeds - 雑草 - 枝葉末節に時間使う

需要あるなら、ちょっと時間とって訳したい気もします。

レビューといえばパターンランゲージのコミュニティの人たちは時間をかけてレビューにレビューを重ねる文化を持っていたので、参考になる気がする。文章に対して真摯で、英語圏ってそういうものかな(とういうと日本語も真摯な人がたくさんいるのでよくないけれど)。

と思ったら、検索順位のその下に、C2Wiki に「Code Review Patterns」というのがあった

http://wiki.c2.com/?CodeReviewPatterns

• Read PeerReviewsInSoftware : 

  Peer Reviews in Software: A Practical Guide (Addison-Wesley Information Technology Series)

• DoInspections - インスペクション
• FormalStandards (are these the same as CodingConventions?) - 正式な標準
• FormalReviewProcess - 正式なレビュープロセス
• ReviewProblemAreasFirst - 問題のある領域をまずレビュー
• ArchitectReviewsEverything - アーキテクトはあらゆる点をレビューする
• AtLeastTwoReviewers - 少なくとも2人のレビュワー
• CodeReviewTeam - コードレビューチーム
• InvolveNewbies - 新人を巻き込む
• InvolveExperts -  達人を巻き込む
• DefectSeeding - 欠陥埋め込み (チェック前にいくつか欠陥を埋め込んでおく)
• PeerReview - ピアレビュー
• HighlightChanges - 変更点をハイライト
• CodeWalkthrough - コードウォークスルー
• AllowRedesign - 再設計も許可
• MakeReviewsFun - レビューを楽しく
• MakeReviewsConstructiveNotCaustic - 原因追求より建設的に
• ReviewBeforeCheckin - チェックイン前のレビュー
• ReviewsBeforeBigChanges - 大きな変更の前にレビュー
• CodeReviewDay - コードレビューデー

Regional Scrum Gathering Tokyo 2018 三日目(土曜日)のオープンスペーステクノロジー

RSGT2018まで2週間を切りました。今回は久しぶりに Open Space Technologyを行うのですが、全然説明しておらず、「３日目ってなにやるの？岩切さんのキーノートだけ？」というお問い合わせを複数頂きましたとのことで、遅ればせながらこちらに説明を用意しました。カンファレンスサイトには準備でき次第掲載いたします。
2018.scrumgatheringtokyo.org

オープンスペーステクノロジー

まだ議論し足りない？
聞きたいことが聞けてない？
誰かに聞いてほしいアイデアがある？

本年のRSGT３日目は、東京では３年ぶりのオープンスペーステクノロジー(OST)を行います。

Regional Scrum Gathering Tokyo 2018 - Program Schedule | ConfEngine - Conference Management Platform

OSTは事前にアジェンダを決めないセッションです。その場にいる人が議論したい内容を提案し、自分でセッション枠を割り当て、自己組織化でセッション表を作っていきます。OSTはスクラム "ギャザリング(集まる)" の象徴ともいえるセッションの１つで、海外で行われる Global Scrum Gathering では定番となっており、近年ではさらにCSPやCSTだけが集まる前日イベントでも同様の形式が取り入れられています。実践者自らが未来を考え、同じ課題を持つ人同士が繋がりあう、この"ギャザリング"とクロージングキーノートをもって会期を締めくくります。

セッションの流れ

OSTの流れは、オープニング、ディスカッション、クロージングのパートで構成されます。(写真は Global Scrum Gethring 2014 New Orleans での風景です。)

オープニング: 概要説明とトピック提案の時間です

ディスカッション : 各トピックのディスカッションを進める時間です。Law of two feet ( 近くに集まったら参加、離れたら離脱の自己組織化ルール ) に従って議論を進めます。

クロージング : 最後に全体で集まってトピックごとの議論について簡単に報告します。(そのままクロージングキーノートに移る予定です)

 

ディスカッションの進め方

ディスカッションのパートでは、セッション表に従ってその時間その場所に集まります。

議論の進め方の原則は以下の通りです。

Whoever comes is the right people
そこにいる人は誰でも正当な参加者です。わからないことを質問したり、知っていることをアドバイスしたり、そのトピックに集まった人たちの成果に貢献しましょう

Whenever it starts is the right time .
When it's over, it's over
スケジュール表はありますが、始める時間も終わる時間も自由です。開始時間も終了時間も自己組織化してかまいません。

Wherever it is, is the right place
場所の割り当てはスケジュール表作成時に行いますが、みなさんでよい場所を見つけたらそこが開催場所です。

Whatever happens is the only thing that could have, be prepared to be surprised!
そこで起こることが全てです。驚くようなことを知ることができるかもしれません

 

３つの役割

代表的な役割が３つあります。

Bird (さえずる鳥) : トピックを決めて議論をファシリテートする人(たち)です。もちろんその場所のは優秀なファシリテーターが他にもいるでしょうから、助けを求めてもいいでしょう。

Bee (群がる蜂) : トピックに群がる(スウォーミング)する人たちです。寄ってたかって議論を前に進めたり、建設的な提案や促しをしていきましょう

Butterfly (飛び回る蝶) : １つのトピックにずっと居たくない人も重要です。複数のトピックを回りながら、他家受粉を促しましょう。許可をとって写真を撮るのも大事な役目です。

参考: Wikipedia : Open Space Technology
https://en.wikipedia.org/wiki/Open_Space_Technology

玉川憲さんのお話 - Tech Crunch Japan 2017

Tech Crunch Japan 2017 に参加してきた。２日目の最初のセッションはソラコムの玉川憲さんのトーク(聞き手は西村賢さん)で、だいぶクラウドメモ帳(Facebook)にメモったのでここに置いておきます。素晴らしい聞き手と素晴らしい答え。ありがとうございました。メモ内容の正確性は...ごめんなさい(指摘いただければ直します)。

jp.techcrunch.com

IVSとWiLから7億調達。
起業に不安はなかった。
クラウドによって起業しやすくなった。
以前はラック立てるために一億円とか
しかし日本であまりスタートアップが出てこないという葛藤が
安川さんとシアトル出張
ビールを飲んで盛り上がる
クラウドでなんでも作れるよね。でも世間は思ってない
銀行の基幹システムとか
別れてホテルに帰ったあとねれなくて仮装のプレスリリースを書いた(アマゾンの文化
その時の名前はコネック
起きたらこれいけるんじゃないかと
朝ジャグジーで安川さんに共有
でもすぐはいけなかった
AWSでやるということもあったと思うが、AWSのユーザーとしてやった方がいいなと思った

KDDIの投資額は正確には公開してない。Amazonへの売却もありえた。キャリアかクラウドベンダーの２つの選択肢がありえた。(世界中の候補を回って) KDDIを選んだのはM&Aの後のシナジー。昨年からすでに一緒にやっていた。KDDIのIoT向けはソラコムの技術を使っていて、いち早く採用してくれた胸熱な相手。

松本さんは投資家ですが元々起業家でヤフーに事業を売却して、起業家と投資家の両方の視点でわれわれに寄り添ってくれた

5Gとかになると帯域は大きくなるが、IoT向けではそれほどいらなくてモジュールが小さくてどこにでも入るというのが重要。

多くのスタートアップで使ってもらっている。例えばファームノート。牛の胎内の体温を測る。まごチャンネルのチカクさん。おじいちゃんおばあちゃんが孫の写真を簡単に観れる。

ソースネクストの通訳端末のデモ。29800円でSIM込み。音声データをそのままクラウドに送っていて言語によって違う翻訳エンジンを使う

IoTは無限の可能性があって、産業ごとにIoTがある。メイカーズムーブメントによって色々なデバイスがでてきて。Twitterが出てきて、みんな悔しがるみたいなことが起こるんじゃないかと。

 

 ソラコムの平均年齢は36-7。玉川さんが39の時に起業。おっさんスタートアップって言ってたら広報に言うなと言われてる。嫁ブロックはなかった。初期メンバーはほとんどが即決できなかったので、場合によっては自分も直接会って。ビジョンと、ブラックじゃないというところを説明。ソラコムは子だくさん。関東IT保険は子供の数が多くて断られたくらい。でもメンバーは未来があるから子供を産むわけだからこれを誇ろうと。ソフトウェアテクノロジーで価値を作っている会社なので。優秀なソフトウェアエンジニアかどうかはゼロイチができるかどうか。完全にフルフレックスで満員電車に乗るなと。私も乗ってない

 

テクノロジープラットフォームを作る会社でグローバルにやりたい。着実な売り上げ成長より一気に成長するスタートアップにしたかった。少人数で価値の高いプラットフォームを作ろうと。15年以上の経験があるいわゆるフルスタックエンジニアにストックオプションしっかり払って。基本的な給料はそのまま以上で入ってもらって、ボーナスはストックオプション。日本だとストックオプションの額がよくわからないけど、アメリカだとシリーズと役職で業界標準のストックオプションの数が決まっている。アメリカから入ってくる人はそれを期待してくるのでそれに合わせようと思ってやってる。額は公開していない。プライベートなことなので。

 

投資家から見るとあまりたくさん出すのは価値の希薄化になるので嫌がる。だが会社が成長するために必要なこと、といえばオプションプールは作れる。ストックオプションがないと特に海外は優秀な人材が採用できなかったと思う。日本だと理解してない人が多いかもしれない。我々は説明しようとしている。ある意味どうなるかわからないものなので細かい値はどうでもよいところがあって、それよりどれだけのスピードで成長できるかが大事。0.1ポイント増やすとかで交渉しなくてよくなった。ソラコムは2年で売却なので時間がかからなかったが長くなると疲弊してくるが、ストックオプションならそこは明らかなのでいい仕組みだと思う

 

スタートアップの技術的負債について。ソラコムはすでに10個のサービスを持っているのでそのメンテナンスが重荷になる。ソラコムでは開発と運用を分けてないので元々汚いコードは自分を苦しめるので書かない。技術的負債のお掃除の期間をとったりしている

 

アメリカヨーロッパ、シンガポールにオフィス。アメリカはオープンドアが顧客についたので立ち上がってきた。内見用の鍵のIoT。う埋め込みのチップ型SIMも。IHIはプラントに。旭硝子は労働者の移動の最適化のためのデバイスをやっている。

 

スタートアップの苦労。苦労話はずっとあるけど、自分でやってるので...。きつかった時期は何度かある。シリーズAを受けるまでは心臓が痛かった。手持ちの金でやっていたけど、資金調達できなかったらどうしようというのはあった。なので資金調達のニュースがあったらおめでとうと言ってあげたい。資金調達は何かのマイルストーン、KPIを超えてるから受けられるもの

 

私自身ここに偉そうに座らせていただいているけど、最初に西村さんに声かけた時は全く思ってなかった。昨年のTechCrunchの時はM&Aを考えてなかった。それがスタートアップのダイナミクス。AWS時代に既にVCなどの人に沢山あっていたので、投資を受ける時にも初対面じゃなかった。そこは結構ポイントなのでTechCrunchなどで是非知り合ってほしい

Zero Bug tolerance (既知のバグをゼロにしてデリバリーする)

いつだったか、たぶん今年だけど、Zero Bug tolerance (既知のバグをゼロにしてデリバリーする) の話によしおかさんから「それは現実的じゃない。」という指摘を頂いた。確かに昔はやってなくて アジャイルとか CI/CD とかで変わってきたところだと思う。

むかし、半年以上のスパンで出すときは、リリース時にQAで見つかったものに重要度/緊急度の分析をして対応決める(トリアージ)が普通だった。深刻じゃないバグは注意書きしたりした。一定以上、深刻なのは小さく再リリース(HotFix)したり。なのでリリース後は結構忙しかったり。

あ、HotFixっていうのもマイクロソフトが自動アップデートするようになったWindowsの方のXPあたりから聞くようになった単語ですね(個人的にはそうだけどもっと前からあったのかもしれない)。

継続的デリバリーの世界では毎日潰してく。品質が上がったというよりマインドの問題っぽい気がする。扱うシステムの粒度が違ったり、リリースの頻度も違うんだろうけど、基本的なパスのエンドツーエンドテストを毎日やるようにしたりとかかなぁ。 

で、同じようにQAしたらそれなりに発見されるんだろうけど、問題はクラウドというオープン系では2週間も状況を固定してテストしたりできないってことかな。(だから、品質の"判定"を会議でやるのはもう無理だと思う。)

あ、昔は完全な動作確認環境も作れなかったりした。 ハードウェアがあってドライバ違いで出るやつとか。プリンタ機種依存問題とか辛かったな。仮想化とクラウドでずいぶんやりやすくなった、というのはある。

なんでこんな話を再考してるのかっていうと、Hunter の Chris Lucian が モブ始めて一年半バグが出なかったので、信頼を得て次のステップに進めた話をしてて、そうそううまくいかないプロダクトはバグ対応に自分たちが潰されちゃうんだよね、って思い出したことによる。

アンクルボブのClean Code の世界。これもアジャイルやってる人はみんな知ってると思うけど、意外と知られてなかったりするのかもしれない。きれい(Clean)といっても美意識の問題じゃないのです。ビジネス直結の話。

いまどき、リリース前のQAでボコボコ基本的な指摘が見つかるようなブロダクトに近づきたくないですよね。

Clean Code アジャイルソフトウェア達人の技

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

ロッシェル・カップさんのトーク : シリコンバレーのスピードを身につける方法

ロッシェルさんのトークに行ってきた。ビデオはこちら(Facebook https://www.facebook.com/codechrysalis/videos/1566566250046015/?fref=mentions&pnref=story)

codechrysalis.connpass.com

よくまとまっていてさすがロッシェルさんだなぁ、と思った。聴衆はあんましソフトウェアとかシリコンバレーに詳しくなさそうな人が多くて、どの質問も新鮮だった。

特に最後の質問がすごく興味深くて、「シリコンバレーの企業は性善説の前提に立ってコントロールよりエンカレッジだというのはわかる。日本ではできないのでは？」というもの。

これはまさにNUNMIで元GMの従業員に対してトヨタが自律的な改善を教えたのと逆のことになっていると感じた。これは地域性でも民族性でもなくて。信頼の問題だったのだと気づく。トヨタと同じ国に生まれただけにすぎないな、日本人、って思った。

SQL Database の入り口

Azure の マネージドサービスで久しぶりにSQL Server のセットアップをしたら世界が変わっていたのでメモ。畠山大有さん、ご説明ありがとうございます！自力で調べると時間がかかるので先に調べてる人から聞くのは楽でいいです。

Azure Portal で SQL Databases を選択して作る。データベース名は適当。

Pricing Tier は料金プラン。プランは４段階。さらに性能としてDTU(アクセス数)とストレージ容量が調整できる。現時点ではストレージ容量は値段に影響しない。

本番はStandardくらいからがオススメとのこと。月2000円しないのに、クラスタリングされてるとか素敵。

一番高いプランでも10万円だった。一番安いリアルDBサーバより安そう。

Collationは言語設定のデフォルト。日本語を扱う場合は、Japanese_CI_AS にしとくのがオススメとのこと。列ごとに設定もできるけど、ここで設定しておくとテンポラリのテーブルにも適用される。

インスタンスができたところ。データ暗号化、自動チューニング、監査、脅威検知、地域分散、動的データマスクのオプションがある。有料だけど、なんか自分で設計しなくていいのやばいな。

自動チューニングは、毎日問い合わせのデータをとっていて、インデックスの生成/削除をおすすめしてくれる。機械学習が使われている。

脅威検知( Threat Detection )はサーバへのログインで地域が変なところから来たら検知するやつ。これが用意されているのはクラウドならではですね。

基本的なメトリクスはデフォルトで取れてるので、自分で設定してた10年前くらいを思い起こすと、便利になったなぁ、クラウドすげぇなぁ、と思いました。

追記: アクセス元IPの許可

ソフトウェア職人マニフェスト

Ron Jeffries たちが、2009年くらいから、Scrumとかチームのプラクティス中心になってしまったアジャイル業界を嘆いて、技術プラクティスの復権のためのミーティングを行っていて、そこで生まれたのがソフトウェア職人マニフェスト ( Manifest of Software Craftsmanship : ソフトウェア・クラフツマンシップ・マニフェスト) だ。

平鍋さんが当時行った翻訳はこれ。

動くソフトウェアだけでなく、しっかり作られたソフトウェアを。
変化に対応するだけでなく、着実に価値を付加していくことを。
個人と相互作用だけでなく、プロフェッショナルたちのコミュニティを。
顧客との協調だけでなく、生産的なパタートナーシップを。

なぜか本編サイトにマージされていない。

Well-Crafted は「しっかり作る」よりもっと技術職人っぽく、「精巧に作る」、「巧みに作る」というニュアンスがあったらいい気がした。

Steadily Adding Value は「着実に価値を付加していく」で異論なしだけど、その技術的背景が大事な気がする。「安定的に価値を付加する」とか。Steadilyを調べたら「絶え間なく」なんてのが出てきたので、Continuous Delivery的にはこっちのほうがそれっぽい。

Community of Professionals は「プロフェッショナルたちのコミュニティ」は、たぶんコミュニティオブプラクティスからもじってるんだと思うけど、そのまま訳すと意味不明なのが難しいところ。個人と対話より、という文脈なのでただ複数形というより、主体と主体が積極的にコミュニティを作るというニュアンスで「プロフェッショナル同士のコミュニティ」とかどうかなぁ。

Productive Partnership は「生産的なパタートナーシップ」でこれは単に誤字修正で「生産的なパートナーシップ」としたところで、よくわかんない気もした。日本だとパートナーシップがちょっと活動というより関係に過ぎないっぽい匂い。形だけの関係でもパートナーって言っちゃうので感じ悪い言葉になってしまっている。「生産的な協業関係を」協調だけでなく何かを一緒に作るという意味で、協"業"するなんて言葉の遊びも入れてみた。

動くソフトウェアだけでなく、巧みに作られたソフトウェアを。
変化に対応するだけでなく、絶え間なく価値を付加していくことを。
個人と相互作用だけでなく、プロフェッショナル同士のコミュニティを。
顧客との協調だけでなく、生産的な協業関係を。

ちょっと平鍋さんに見てもらって、まだメンテされてるようなら、本家に送ってみようかな。

Manifesto for Software Craftsmanship