品質管理の知識を持たないエンジニアはモグラ叩きのループから抜け出せない

ソフトウェアの品質管理というとエンジニアは何を頭に思い浮かべるのでしょうねぇ。設計書やコードのレビューかな。それともバグのチケットの書き方が面倒だなーということかな。

どれを取り上げても品質管理はエンジニアから見ればやらされている感が満載ですよねぇ。

プロジェクトマネージャはその品質管理をやりたくてやっているかと言えば、これまた組織の品質管理部門とか品質保証部門とかPMOとかうるさ方の部署からアレ出せ、コレ出せと言われるので、お作法として、プロジェクトに余計な鑑賞をされないために義務的にやっているといっても語弊はないかもしれません。

どうして品質管理が必要なの

端的に言えば、要件、そう、顧客が実現したい事業上の課題をITで解決するために、プロジェクト化してソフトウェア開発したコードに要件が備わっているかを検証・評価するためです。

とだけではわかりにくいですね。言っていることはわかるけど、みたいな。

ソフトウェアは形状がない、物理的な要素がないので外形的な特徴から計測することでそのソフトェアが持っている能力を測ることができません。とは言え、そのままでいいのかと言えば、それではやりたいことができるかどうかが判別しないのでちゃんとできますよ、としたいわけです。お金かけていますからね。

何を検証・評価するの

例えば、スマートフォンは形があり、外形から物理的な特徴があるので工場で生産した出荷前のスマホを設計データの許容範囲の誤差内に収まっているかを測定することで出荷して良いかどうかを評価できます。

一方、スマホの中に入っているOSは、物理的な形状がありません。ですから、仕様どおりの要件がソフトウェアに備わっているかを検証し、評価することが必要です。

どのタイミングで検証・評価するの

全部ができあがってから検証・評価しようとすると、まず組み立てが必要でそこで部品どうしの寸法が違えば組み立てができないです。

ですから、部品の状態の遷移するタイミングの前にその工程で加工した要素が備わっているかを検証・評価した方が良いです。これは物理的に計測可能な対象でも無形上のソフトウェアでも同じです。

どうやって検証・評価するの

ドキュメントならレビューが多いですね。コードならテストですね。ただ、レビューもテストも検証を実施するアクティビティの一つでしかありません。

検証・評価は何をすればいいの

ざっくりとアクティビティを並べればこんな感じでしょうか。何を検証するのか、何を評価するのかをはっきりしてないということは品質管理の目的が曖昧でやらされているということと同じですね。

• 評価要素の選択
• 評価方法の策定
• 検証方法の決定
• 検証の実施
• 検証結果の評価
• 改善

主体性を持ってやらないと品質不良が出易いし、事後対応ばかりになってモグラ叩きの呪いから逃れられませんよ。

どうしたら品質管理でバグが減るの

これは設計書なりコードを作成するときの作業プロセスに踏み込んで、品質を作り込むプロセス設計をしないといくら品質管理を一生懸命頑張ってもバグは減りません。

だって、対処療法ですから。

身体を鍛え、病気になりにくい体質に変えなければどうしようもないです。身体を鍛えても病気になると思うかもしれませんが程度がかなり違います。些細なことで済むことが多くなるし、それこそ大規模なインパクトがあるケースは想定外になるので。

なので、アウトプットを作るときから要求される品質特性を折り込みしておきたいので作るときから品質を備えた作業プロセスを実行しておきましょう、ということの他はないのです。

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)

エンジニアは本を買わない

「お疲れでーす。何か最近面白かった本とかありませんか」
「私の専門を知っているんだからキミにフィットしないとわかるだろう」
「いやいや、アジャイルの本とかは割と早く読んでいるじゃないですか」
「ああ、そうかも。積読が多いけどね。Kindle版を買うと可視化されない積読なのでよりひっそり感がある積読になっているんだけどね」
「同じようなものですよ」
「そう言えば相変わらず技術書は机に積んでいるの」
「フリーアドレスになってから固定席ではないので困りますね。ロッカーも小さいし。2−3冊くらいしか。プロジェクトルームがある時はそこに積んでおきますけど」
「フリーアドレスになって、ますますエンジニアは技術書を読まなくなるのかねぇ」
「そうかもしれません」
「出版不況だというのにエンジニアが書籍を読まなくなると負のスパイラルが加速するしね」
「ジワリと値段も高くなっていますよ。欲しい技術書は躊躇いませんけど。でも、周りを見ていると本を席に積んでいるエンジニアは少なくなったような気がします。アプリ開発にいれられるじゃないですか。ほんと、アプリ開発のエンジニアが本を読んでいることは見かけないですね。10人いて1人いればいい方ですから」
「なんでいくらでも買うぜ、なんだっけ」
「昔のマネージャが給与の10％は本を買って読まないとエンジニアとしての価値があっという間にゼロになるぞ、って刷り込まれたからかなー」
「定率か定額かは置いといて、技術知識を更新したり拡張しておかないと確かに価値はあっという間に減ってしまうな。特に、技術の適用するスキルはその傾向が高いな」
「言語とかフレームワークとか製品とかですね」
「そうそう。バージョンアップしたらそれまでの技術が終わっているときがある」
「それはツライですね。技術の更新を追いかけるのもツライし、EOLになったらなったでツライですし」
「でさあ、結局、何某かの技術書を買うのは避けられないのだと思うんだ。エンジニアとしての価値を最低限維持しようと思ったら。でも技術書が売れていなくて不況らしい。エンジニアは技術書を買うものだと思ってたんだけれど、それは技術習得をエンジニア自身が価値の向上、いや維持でもいいけれど投資として書籍に給与の一部を再投入しているという仮説は間違っていたということになるんだけどさ」
「売れていないなら何かが間違っているのでしょうね」
「そこでだ、エンジニアは技術の向上や維持のために書籍に投資をするという前提が間違っているとしたら」
「あー、そういうことですか。技術力向上も維持もしないエンジニアが増えたということですか」
「かもしれない。でも、別の見方があるかもしれない」
「具体的には」
「書籍を買うのはエンジニアの中でもプロフェッショナルだけ、かもしれない」
「プロフェッショナルだけに限定したら売れないでしょうね。ITSSレベル6くらいですか。それは人数少ないでしょう」
「さらにだ、昔、20年くらい前に比べて技術の細分化が進んでいるとしたらどうなると思う」
「エンジニアの母数が、その細分化された末端の、ですが、エンジニア数が少ないですよね」
「そうだよ。そこに本を買おうと思うのはエンジニアの中でもプロフェッショナルだけだとしたら」
「売れる気がしないですね。売れないですよ、それじゃあ」
「だろう。まだ別の考え方の軸があるんだよ」
「なんですか、それ」
「どのジャンルでもマニアという層がある」
「ありますね。カメラとか鉄道とか天文とか無線とかアニメとか」
「詳しいね。それはそれとして、みんな趣味の欄に読書と書くけれど、常に新しい本を買うとは限らない。芥川賞でも図書館に行って借りる人は多い。そういう人だって趣味は読書だ。いいよね」
「まあ、いいんじゃないでしょうか」
「新書で買うのはマニアだけだ」
「あ、そういうことですか」
「つまり、プロフェッショナルかそれに準じる層と書籍のマニアが交差するポイントの面積だけでしか本が売れない」
「でも、ゼロから作るDeep Learningの本とかリーダブルコードの本とか売れているらしいじゃないですか。ポップに貼ってありましたよ」
それはキャッチーな技術だったり、新人教育で全員に配布したりしたから結果的に母数が広くなったからだとしたらそういった現象が起きていても不思議ではない」
「なるほど、習得科目の教授の本を買わせるようなものですね」
「新人教育に使われる本が売れる理由の方は微妙な発言なきがするが…まあそいうことだよ」
「どのくらいしか売れないんですかね」
「仮に60万人いて、1％が技術エリアの母数なら6000人になる。そのうち、プロフェッショナルで且つマニアな交わりの面積は10％あったとしても600冊。まあ、素人の仮説だけどね」
「600冊なら大手サークルの方が売れていますね」
「壁サーと同列にしては不憫だよ」
「どうなっちゃいますかね、技術書は」
「多分、電書化が進む。紙は減るし、値段が上がる」
「じゃあ、持っている本にプレミアつくかな」
「電書があるからね」
「じゃあ、サインしてもらおう」
「それこそマニア向けになっちゃうよ」

Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来

類語辞典

講談社のがよかったのになぁ。大辞林を持っているから角川一択か。

角川類語新辞典

• 物書堂
• 辞書／辞典／その他
• ¥1,600
• 

チームの自己組織化の道を今選ぶべきか

自己組織化。そうした話題がTLで出てくるのだから、流行りのキーワードと言えばそうなのかもしれない。

実はここのところ、メンバに対してある実験をしているのです。明示的にどんな実験かをメンバには伝えていません。あくまでも業務の一環として。まあ、その業務自体が意味あることなのでそれが直接的な目的に当たるのですが、マネージャとしては間接的な目的の方が重みがあるのです。

マネージャがいつも考えておくこと

マネージャがいつも考えておくことにはどんなことがあるでしょうか。小難しことではなく、実務としてわかるよと思ったら、先を読まずに付箋紙にでも書き出してから読み進めるとマネージャがいつも考えておくことの違いを知れて良いかも知れません。

関連本

のん、呉へ。 2泊3日の旅

TESCOM 毛玉クリーナー テスコム 毛玉とり KD556-A ブルー

CEOの思いが思いどおりに現場に届いているかを可視化する方法

イノベーションへの解に組織が取っているイノベーションの施策が、継続的イノベーションと創発的イノベーションかに振り分けるチャートがあります。

このチャートを使って、組織の理念、wayなどの行動規範で表される組織の価値感である価値基準から現場に降りてくるタスクまでをプロットすることで、トップの思いがどこまで意図したまま届いているかを可視化することができるのです。

どういうことかというと、チャートの本来の使い方をするだけで迷いなくプロットできればトップの思いが現場まで届いていると判断して良いですし、様々な施策をプロットする際にどこに配置すれば良いかを迷うなら、その施策はトップと現場の間のどこかの中間管理職のレイヤーでトップの思いが減衰し、捻じ曲げられているという判断ができるからです。

施策をプロットする際に、施策を上下で分けて配置してください。チャート自体がもともと継続的なイノベーションと創発的イノベーションに分けるようにデザインされているので。 

上の水色には継続的イノベーションの施策を配置します。下のピンク色には創発的なイノベーションの施策を配置します。

施策がイノベーションかどうかはきにすることなく、組織の中期、年次の事業計画、全社共通の施策、部門の施策、部署の施策が現状のビジネスの延長線上だと思ったら、上のどこかの箱に配置します。

組織が意図的に、明示的に創発的イノベーションと言っていなければほとんどは継続的なイノベーションになるので。

検証したいことは、トップの思いがどこかの中間管理職のレイヤーで手段が目的化として変質してしまっていることを明らかにすることです。

なぜ、中間管理職のレイヤーで手段が目的化してしまうのか。それは、中間管理職が無能…いや、マネージャを担っているはずなのにオペレータに劣化しているからです。当の中間管理職としては楽ですからね。オペレータを演じるのは。そしてそうなってしまうのは、その組織の意思決定の判断基準が組織の文化として深く浸透していることに起因するのです。

だから、トップがいくら組織を変えたいと思いを込めてメッセージしても過去から積み上げ、組織のワークフローに染み付いてしまった価値観を変えることはトップ自身ができないというトラップに嵌ってしまっているのです。

もし変えるとするならば、変えたい、メッセージとして伝えたことを中核となる事業部門のミドルを総入れ替えするか、全く別の組織を別立てとしてそこにメッセージを推進する少数精鋭のリソースを投下し、トップの直下に置くことが必要です。

イノベーションへの解 利益ある成長に向けて (Harvard business school press)

ウォーターフォールも出来ないエンジニアがアジャイル開発をできるわけがない

「もう、聞いてください。アジャイルで開発しているのに、みんな受け身なんですよ」
「顔見た途端に愚痴なんだ」
「もう不憫な状況なんですから。このくらい聞いてください」
「いいけれどさぁ。それで」
「みんな受け身で、コードが書けるドキュメントがないと何も出来ないとかいうんですよ」
「切れば、そいつら」
「できるならそうしたいですよ。でも権限ないですから」
「じゃあどうしているの」
「しょうがないから指示しているんですよ。ドキュメント書いたり」
「それ、本来の仕事なの。違うでしょ。ツッ返せばいいじゃん」
「できるならやってますって」
「上に言ったの」
「上同士もなあなあなんですよ」
「じゃあ、だめだ。早く逃げておいで」
「今は無理です」
「でもさ、アジャイル云々の前の話だよね」
「ほんとそうですよ」
「そう言えばさ、リーダSEはいるんだっけ」
「いますよ、あーだこーだ言い訳して必要もないドキュメントを作っているんですよ。ほんと無駄」
「そいつらも切れば」
「切れるなら切ってますって」
「そんなに使えないエンジニアって呼んでいいのかわからない奴をご退場願ったらコスト半分で済むんでは」
「なります、なります。ほんそれですよ」
「ほんそれ、なんて使うやついるんだ、リアルで」
「言いたくなるくらいですよ。なんかバカみたいですよ」
「受け身だったり、意味のないドキュメント作ったりしているなんて、どんだけ価値のないエンジニアなのか。そいつらを切ってその分のコストをキミにあげたいものだ」
「いいです。いなくなるだけで」
「その方が辛辣だけどな」
「だって」
「悪いわるい。だけどなー、どーするのかな、そのエンジニア様たちは。社員もいるんだろう」
「悪いお知らせと悪いお知らせのどちらから聞きたいですか」
「同じじゃん」
「肝心なところにいるのは社員です。ええ、外注さんがかわいそうです」
「ノーコメント」
「そんな」
「しかしなぁ、そいつらはこれから何で食べていくんだ」
「ほんとです。アジャイル開発できないとこれから大変でしょう」
「いや、本質はそこじゃないな。そのエンジニア様たちはウォーターフォールでさえきちんとできないんだな。極めて個人的な見解としては、どっちでもいいけど、どっちとは、ウォーターフォールとアジャイル開発だけどさ、どっちでもいいから片方をちゃんとできないエンジニアには使い物にならん」
「それはそうだと思います」
「更に言えば、ウォーターフォールがちゃんとできれば、基礎があるのでアジャイル開発もできる…技術的素養はあるハズ。マニュフェストのあれ左側より右側の話のところが忠実にできるかどうかは別だけど。まあ、ちゃんとできるなら学習の仕方は知っているだろうからそこで担保するとしてもさ、期待はしてもいいと思うんだ」
「なんとなくわかります。そうかもしれません」
「別に同意しなくても理解できなくてもいいよ。そう思っているだけだから」
「いや、そんなことはなくて…どもどうするんでしょうね、そのエンジニア様たち」
「まー、エンジニア様たちのビジネスだからねぇ、口は出せないね。マネージャでもないし」
「ひどいですね」
「頼まれもしないことはしないよ。エンジニア自身が助かりたいと思っているなら何かできるかもしれない。でも、そのエンジニア様たちはそうでもないみたいだ」
「どうするのがいいのでしょうね」
「キミはさっさとキリよく抜けることだね。聞いたところは難しそうだけど。誰か後継を作るもの仕事だからさ」
「そうなりますか。そうですね…」
「まあ、肉でも食べに行こう」
「あ、はい、行きます」

アジャイルサムライ−達人開発者への道−

SCRUM BOOT CAMP THE BOOK

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

ユーザーストーリーマッピング

カンバン仕事術

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-