「この業務は彼・彼女しかできません」という状況は誰のメリットにならない

理想のチームは、チームの目標をメンバが率先して共有して理解して、目標を設定して目標を達成するための活動に取り組むことです。

たぶん、誰もがそうすればいいことは言われれば「当たり前だ」というけれど、自律して実践しているメンバは数える程しかいないのが現実です。であれば、どのようにしてチームの業務を目指す運営状態にすれば良いでしょうか。

業務を再定義する

チームが担う業務の範囲を再確認し、チームが責任を負う業務の定義をし直します。わかっているメンバは暗黙でわかっているかもしれませんがそれはこれまでわかっているはずの業務を担当していたからです。

チームであれば、誰がやっても同じ業務の結果を得られることが理想であり、目標になる姿なのです。

バリューストリームマッピングなどの手法を使い、業務を可視化しましょう。

業務の依存関係を知る

業務を可視化すると一つの業務には必ずインプットとアウトプットがあります。業務の活動をしているということは何かしら生産的な活動をしているからです。生産するにはリソースが必要ですし、活動には目的があるからです。

チームの業務を担当制を進めすぎてしまうとチームの一部分しか業務を担えないメンバを作ってしまいます。そのようなメンバは自分が担当する業務だけは知っていても業務の繋がりを知ろうとしたり、気にかけたりすることがなくなってしまいます。こうした間違った組織の文化はチームの誰もがチームの業務をしても同じ結果を得られるというチーム像から遠ざけてしまうのです。

自分の仕事にさせない

「この業務は自分が担当です」「この業務は彼・彼女しかできません」という状況は、業務が属人化している明確な証拠です。

誰もがチームの業務を行い、同じ結果を得られるというチーム像を目指すなら仕事に対する縄張り意識や専門家にしてはいけないのです。

そのためには業務を人的に冗長化することから始めます。冗長化するためには業務の言語化による情報化を進めなければならず、その結果、情報共有が奨励されなければなりません。

誰がやっても同じ結果を得るためには技術移転も推進される必要があります。

メリット

チームの業務を誰がやっても同じ結果を得られるということが徐々に実現されるとこれまで業務を休むことについての心配事が無くなります。

なぜなら、チームのメンバであれば誰が作業をしても同じ結果が得られるように人的な冗長性が得られる仕組みが構築されているからです。

休まなければならないときに休めるという安心感がメリットでなくてなんでしょうか。

エンジニアの採用は簡単だけど簡単じゃないよ

とある会社の開発部門の役員の方とお話をする機会があってエンジニアについて色々話していたら、採用の話に移ったことがありました。

ワタシ自身が新卒採用と中途採用の両方の経験があるのでとても興味深く話を聞きつつ、色々と感じことがあったのです。新卒採用は新卒採用で見切れない問題がついて回りますし、中途採用は中途採用で見極めることが難しい問題があるのです。まあ、新卒採用だとか中途採用だとか分け隔てしてみても、どちらも成人した大人を仲間に迎えるという意味では全く同じで、すでにある組織が持つ文化（それを家風とワタシは呼ぶことが多いですが）に馴染んでもらえるかが大きなハードルなのですけど。

共通的な問題

新卒採用でも中途採用でもどちらでも共通の問題は、自社に迎えて期待する成果を発揮してもらえるか、です。とても当たり前なのことすぎますが、当たり前なことは暗黙になることが多いので明示的に晒すこと行為はとても大切です。

リーンキャンバスやビジネスモデルキャンバスにような可視化するフレームワークはあえて内面に持っている考えを言語化するために使うのです。このとき、実はそれほど考えていなかったことに気づかされることに気づかされているエンジニアも多いでしょう。

期待する成果とは何か

新卒採用で採る新人に期待する成果とはなんでしょうか。一人前に自社に必要とする技術を身につけ、自分で情報を集め、自分で判断し、アウトプットをするエンジニアになって欲しい。そうであれば技術を身につけられるような教育を行う必要がありますし、身につけた技術を活用するアサイメントをしなければなりません。

同じように、中途採用するエンジニアに期待する成果とはなんでしょうか。当然の期待は即戦力としての活躍です。新卒採用で育成して育ててからではビジネス上の目標の実現まで時間がかかりすぎるため、そこを飛ばして教育不要な技術を持っているエンジニアを採用するのです。

掛かるコスト

新卒採用では技術はとりあえず不問とするケースが多いです。本来であればコンピュータサイエンスの課程を経た候補者から選びたいところです。これもある意味教育コストを自社で負担することを大学などに負担を押し付けているだけなのですが。

これも当たり前ですがいくらコンピュータサイエンスを納めてきたとしても自社で取り扱う技術と一致することはあまりありませんから、結局は育成という教育は必要になりますが、学習する技術は身につけている点でアドバンテージはあるのですけれど。

何れにしても新卒採用では、技術の習得の他に仕事の仕方も身につけなければなりません。ワタシ的には技術の習得より仕事の仕方、スキルで言えば基礎スキルに分類する定性的な意欲、姿勢、協調、意思伝達、意思は生まれ持った性格や採用されるまでに経験により身につける後天的な性格に依存するためいかに活かすかこれもハードルが高いです。

中途採用では、いわゆる技術の習得や仕事の仕方などの育成コストはかからない前提としていることが多いです。必要なコストは、参画する組織の家風、制度などの仕組みになれるコストだけです。

では技術に関するコストが全くかからないかと言えば、中途採用で支払うサラリーは新卒採用の数倍以上ですから、サラリーがいきなりボンっと高いところから始まります。中途採用と新卒採用のサラリーの差異のコストが本来自社で行わなければならなかった教育コストであり、それを出来上がっている状態で、つまり、車で言えば乗り出し価格で買ってくるということです。

教育コスト

新卒採用であれば程度の差はあるけれど、育成にコストを掛けなければ期待する技術の習得に到達できないことは理解されています。まあ、採用直後に現場に投げ込んでいたらその会社の教育に関するコストは掛けないということの証左ですからブラック認定してさっさと移ったほうがいいです。ここでの教育コストは組織が必要として強制的にエンジニアに習得させる範囲のみをスコープとしており、エンジニア自身が自身の市場での価値を維持、向上するための自己研鑽は別としています。

中途採用をする会社は新卒採用していなければ、その組織では育成ができない可能性が高いです。教育をしているとしてもアウトソースしている場合です。一見良さそうですが、どこの企業でも対価を支払えば得られる研修しかないため自社独自のノウハウを研修という形式知としてまとめて習得することは期待できないということです。中途採用される側の立場で言えば、自社、つまり内製化している研修がどれだけあるかで研修に対する組織の考え方が判断できるので注意する必要があるでしょう。

再び共通の問題

教育を行う期待とそれに投下するコストについて述べてきましたが、ここで再び共通する問題について取り上げます。

それは、新卒採用であっても中途採用であっても採用するという行為に対して

・期待する成果を発揮してくれるのか
・既存するメンバと意思疎通できるのか

という点です。機械の部品であればレギュレーション、部品仕様があればそれに合うものを調達すれば性能の差はあるとしても適合することには間違いありません。

機会でない人を採用して既存のメンバの中に当てはめたときに仕事の成果の他に想定外の摩擦やコンフリクトを起こすかどうかは嵌めてみないとわからないのです。

これが判別できないから結局、

「一緒に働きたいと思うか」

という定性的なものいいでしか表現できないし、一緒に働く前提を言葉で表現すること自体ができないのです。

人材の流動性が高まるなどと表現がありますが、その裏には様々な期待とコストがかかることを知っておくことは無駄にならないでしょう。

GW後半に読みたい技術書7冊

たまにはちょっと違った趣向で。今日を入れて3日間あるので１冊くらいは読めるのではないかしら、と。

1冊目：トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

プロジェクトマネジメントも自分たちのチームの標準作業プロセスを設計しなければならないのに、ろくに設計もせずに行き当たりばったりでプロジェクトを進めているチームが多いのは、リーダであるプロジェクトマネージャがプロセスを設計する力量がないから。一つの解としてこの本でプロセス設計を学ぶことは参考になります。

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

2冊目：ジョイ・インク

読みましょう。読み物としても楽しめます。あなたがプロジェクトマネージャやマネージャでチームや組織に関与できるなら学んだことの１つでも実践してみると良いです。

ジョイ・インク 役職も部署もない全員主役のマネジメント

 3冊目：Team Geek

結局、技術的な問題より人間の関係性の問題の方が様々なところで影響を及ぼす範囲が大きいのです。だから、アジャイル開発だって組織論に進むのです。それはムリ・ムダを排除するからウォーターフォール開発でぶよぶよしていた緩衝する役に立たない何者でもない何かがない分、ダイレクトで最短にたどり着いただけです。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

4冊目：あなたのチームは、機能してますか？

 あなたのチームが機能していない？なら読むと参考になるでしょう。

あなたのチームは、機能してますか？

 5冊目：失敗の本質 戦場のリーダーシップ篇

時代は違っても人は同じ質の失敗をするのです。 

失敗の本質 戦場のリーダーシップ篇

 6冊目：米海軍で屈指の潜水艦艦長による「最強組織」の作り方

自律したチーム作りのhow toは誰も教えてくれないのです。ただ、自律したチーム、自律したメンバの意識を作れというだけ。それのhow toがわかります。

米海軍で屈指の潜水艦艦長による「最強組織」の作り方

 7冊目：アプリ開発チームのためのプロジェクトマネジメント ～チーム駆動開発でいこう！

このくらい柔らかくないと読まないエンジニアが多いのは時代なのか。

アプリ開発チームのためのプロジェクトマネジメント ?チーム駆動開発でいこう！?

お買い物

 効果あるのかしら

【2個セット】HMB 500mg [海外直送品]

みずほ次期シスの今後のスケジュールを考えてみたが…

みずほの次期シス、完成するんだ…がこのニュースを見て思った正直な感想です。いい話なら、何も連休の谷間に流さなくてもいいのに、わざわざ狙ったように公表するのは何かあるのかな、と思うけれど。

で、短いニュースだけれどよく見てみると…

this.kiji.is

第一勧業、富士、日本興業の3銀行が2000年に経営統合して発足したみずほグループのシステムは、2度の大規模障害を経て、初めて統一される。運用開始は来年度以降になるとみられる。

引用　https://this.kiji.is/232156120851988483

ん？「運用開始は来年度以降になるとみられる」とアルよ。あれと思って前を見たら

みずほフィナンシャルグループ（FG）が開発中の次期システムが今夏に完成する見通しとなったことが2日、分かった。

引用　https://this.kiji.is/232156120851988483

と、まだ完成していないが見通しは立ったので公表したようです。

さて、来年度以降に開始される運用までのスケジュールはどうなっているのかなということに興味を持ったので妄想してみましょう。

ケーススタディを気軽にシミュレーションできるのでいいですね。

どうせやるなら当事者の統括プロジェクトマネージャになったつもりでやらないと意味はないですけど。

想定する今後のスケジュール

重要なキーワードをニュースから拾いましょう。とは言え、拾えるキーワードは２つしかありませんけど。

・今夏に完成する
・運用開始は来年度以降

この２つの情報のうち、時間のマジックが含まれていることに気づいたでしょうか。

それは「年度」です。運用開始を来年度以降としています。来年とは言っていません。つまり、年なら1月からですが、年度始まりは4月から開始するのでその差が3ヶ月のディレイを生むのです。

今夏に完成する見通しが立ったので今回の発表を判断したと思われますが、翌年度、つまり、2018年度以降に運用開始するまで何をしているのでしょうか。

システム開発の完了月

開発は今夏です。夏は6月から8月ですから8月中には総合試験が終わるということが想定できます。

システム移行の時期

さらに2018年度以降に運用開始をするとしています。そこで考えなければならないことは現行システムから次期システムへのシステム切り替え、システム移行のタイミングです。一般的に年末年始、大型連休（まさにこの時期ですね！）です。

2018年度以降で最短の切り替え時期は、2019年度の大型連休となります。そのあとは2019年12月から2020年1月の年末年始でしょう。

2020年のオリンピックイヤーの年初でシステム切り替えをしてロールバックするわけにもいかないので2019年春の大型連休が最有力です。ただ、移行期間の日数によっては他の連休が候補になっていると想定されます。

完了からシステム以降までに何してる？

今夏に完了する総合試験（想定）からシステム移行の間に何をしているのでしょうか。開発中の次期システムの開発の定義が不明ですが、ベンダーの開発であれば総合試験が妥当でしょう。

とすれば2018年度以降に次期システムの運用を開始するまでに間にやることはたくさんあります。最初に挙げられるのは運用テストです。その運用テストは、業務運用テストと思いたいところですが、システム運用テストも含まれているかもしれません。

その運用テストにはエンドユーザを巻き込まないと切り替えた初日から業務が混乱することは必須です。エンドユーザもメガバンクですから国内本店系とある地域の支店だけ、というわけにもいかないでしょう。さらに言えば、本来であればシステム間インタフェースのテストで対外システムを持つ先方である企業や団体をどこまで巻き込むかも判断しなければなりません。確か、銀行系は日銀と繋ぐ必要があったはずです。

運用テストの途中から移行準備に入る必要もあります。移行設計自体は設計行程中から着手していると思われますが、いよいよデータバックアップなどの具体的な作業が入ってくるでしょう。

運用テストのリスク

試験工程を進捗するに従い、人員の絞込みが始まります。業務運用試験に入ると運用試験のサポート要員だけに極端に絞られます。でも、残されるのは全体を把握しているリーダクラスやトラブル対処のスキルを持つ技術的に高いメンバだけが残されるのでSIerとしては辛いところです。

そんな人員で業務運用試験に突入するとエンドユーザから仕様変更や不具合報告が上がるようになり、残された要員では対応できないくらいにボリュームが上がることが想定されます。ソフトウェア品質がプロジェクトの品質目標をクリアしていれば残した要員で対応できるかもしれませんが採取したメトリクスが正しいかどうかはある意味ここで試されるのですよね。

システム開発で意義のあるメトリクスを計測するために

システム開発はメトリクス宝庫です。宝庫だけれど全く採取していないし、採取することでシステム開発へフィードバックできることを知らないということもあるのです。

メトリクスってなあに？

まずは辞書を引きましょう。google先生に訊ねるとソフトウエア・メトリクスとソフトウェア品質メトリクスが出てきました。それぞれの意味は次のとおりです。

ソフトウェア・メトリクス　software metrics
プログラムの複雑さを測定するための技法の一つ.

ejje.weblio.jp

ソフトウェア品質メトリクス　software quality metrics
ソフトウェアの品質に関する尺度で, 複雑さ, 理解し易さ, 試験し易さ, などを示す.

ejje.weblio.jp

うーん、結局どういう意味何だろうとメトリクスだけで引いてみます。

メトリクス　metrics
測定法や尺度といった意味だが, ソフトウェアの品質に関して使われることが多い.

ejje.weblio.jp

もう一歩下がって基本的な言葉で引いてみます。

そく てい ［0］ 【測定】
（ 名 ） スル
長さ・重さ・速さなど種々の量を器具や装置を用いてはかること。直接行う方法と，理論によって間接的に行う方法とがある。また，広く自然や社会の現象を記述するため，一定の規則にしたがいその対象の量に数値をわりあてることをいう。 「距離を－する」 「民度を－する」 「体力－」 「 －値」

www.weblio.jp

ソフトウェア・メトリクスやソフトウェア品質メトリクスがプログラムや品質を対象としているのに対し、メトリクスの測定の意味を紐解く方がすっと理解できそうです。

測定の説明の下線の箇所をさらに要約すると

「計測対象を単位を用いて測ること」

と表現することができると思うのです。さて、システム開発では何が計測できるでしょうか。

何のためにメトリクスを計測するの？

システム開発プロジェクトの目的を達成しているかどうか現実に起きている事実を計測することで客観的に評価し、プロジェクトの目的を達成するために必要な活動にフィードバックすることでプロジェクトの目的を達成するために行う活動です。

事実を計測するのは定量的に計測することで客観性を持たせます。出来ていると思う、品質は十分確保したはず、では誰も信用してくれません。

計測対象を単位を用いて測定し、基準値を持って状態を評価することが必要なのです。

何がメトリクスとして計測できるの？

システム開発プロジェクトの活動で且つ単位を持つものは何でも計測できます。計測できますが、計測する活動を行うためには人と時間と道具が必要になります。つまり、システム開発プロジェクトのリソースを消費してしまうということです。

その計測をすることで次のプロセスにフィードバックすることができるのであればメトリクスを計測することに意味があるでしょう。

ではフィードバックに何を期待しているかといえば、プロジェクトの目的と計測時点おで計測対象のズレを定量的に把握し、許容されないバンドを超えている場合は改善に繋げることです。

何が計測できるの？

一番身近なメトリクスは、WBSの作業実績の計測でしょう。これを計測することで作業時間の見積もりの正確性を評価することができます。仕様書レビューでの不良摘出件数は、対象となる文書の品質状態を計測することができます。

同じように、コードのコミットから試験環境へのリリースや自動化試験の実施時間を計測することも可能です。

先に述べたようにソフトウェア開発プロジェクトで単位を持つ活動であればメトリクスを計測することができます。

ただ何でもメトリクスとして計測すればいいってわけではありません。それではメトリクスにリソースを使い過ぎてしまいメトリクス貧乏になってしまいます。

どうしてメトリクスを計測しないの？

端的に言えば、計測してもフィードバックできないところで計測しているからメリットを享受できずにやめてしまうからです。

フィードバックできないところでの計測とは、ソフトウェア開発の局面の終了時に計測したり、はたまたプロジェクト完了時に計測しているからです。これでは計測しているには間違いはないのでしょうが単に実績値を採取しているに過ぎません。

局面内で計測し、局面の中でフィードバックするか、スプリントのような繰り返す場合に次のインプットとすることで初めてメトリクスの計測が活きるのです。

ソフトウェアメトリクス統計分析入門―現場エンジニアによる直観的解説と実践ドリル

ソフトウェア開発の失敗は上流工程のレビュー強化では対策にならない

ソフトウェア開発の失敗の原因には上流工程での品質に問題があるとよく聞くことがおいいですね。

IPAでも「設計レビュー・要件定義強化のススメ」とタイトルを付けた資料を公開しています。

ソフトウェア開発データが語るメッセージ「設計レビュー・要件定義強化のススメ」を公開 ～定量的データに基づくソフトウェア開発のプロセス改善を目指して～：IPA 独立行政法人 情報処理推進機構

 資料自体は、ダウンロード前にユーザ登録と資料の利用目的のアンケートに答えるだけで無料でダウンロードできます。

ページを捲るとP8に図2.1-1上流工程（基本設計〜製作）強化モデルが目に入ります。

引用　IPA「設計レビュー・要件定義強化のススメ」P8

上流工程はどこの局面か

まず上流工程の定義についてP1で次のように定義されているのですが、

「本書のスコープは上流工程（要件定義、基本設計、詳細設計及び製作）の品質マネジメントである。」

この定義は一般的なんですかね。個人的な見解としての上流工程は、

要件定義及び基本設計

までだと思っていましたが。詳細設計以降はそれこそ労働集約型の工程に遷移しますし、実際にエンジニアの工数の山積みは詳細設計以降から上昇し、結合試験以降に降下するので。

強化策の違和感

もう一度図を出して確認してみましょう。

下から上に登る図です。向上を目指す図だから上に向かって矢印をむけたのでしょう。

さて、本題ですが、設計文書充実化とは文字面から設計文書を増やすことで表現漏れを防止しようとしたいと読み取れます。

ひとつ上に登ると設計レビュー強化とあり、質と量の増強とあります。まあ、設計文書を充実したのであれば量的に設計レビューは増えるのは当然として、従来の文書の設計レビューのカバーを増やしなさい、と言われているわけです。

この前提には、

「今までのソフトウェア開発において設計レビューは十分でなかった」

と懺悔していると読めるのですが。

モヤっとするのは設計レビューの質の向上です。これは現場において設計レビューの観点を持っていないということの証左ではないかと疑いを持たざるを得ません。実際、それが現実なのでしょうけれど。

これらの設計レビューを質的、量的に強化という名のカバーを増やすことで上流工程の不具合を検出することで、結果的に上流工程での設計レビューを通過した後に発現する不良を減らそう、と言っている図でしかありません。

強化すること自体がおかしい

いつも書いていることですが、品質を「強化する」という表現はおかしいです。業務要件をITで実現するためのソフトウェア開発なのに、不具合が多いから強化するなんて。

本来は、業務要件をITで実現しなければならないスコープの漏れのない仕組みを作業プロセスとして設計、実行するのです。

さらに、業務要件からITで実現する機能仕様を定義し、実装した機能仕様を検証する試験を行うことで業務要件が実現されていることを担保するのです。

その観点から言えば、信頼性向上とか「何言っているんだ、お前」なのです。

必要なもの（ドキュメント）を作り、実現できていることを検証する

ソフトウェア開発で必要な作業は、作業した結果であるアウトプットを次工程のインプットとした場合に価値を産むかどうかで作業プロセスを設計しなければなりません。

これは絶対に守らないとあったらいいねとか前回のソフトウェア開発で作っていたからと云われの不明で利用価値のないドキュメントを作る時間を割いてしまうことになります。

ソフトウェア開発でアウトプットとして作ってしまうとそれが正しいかを次工程に回す前に検査が必要になり、価値がないアウトプットであってもレビューが必要になることで価値のないレビューを行い、工数を消化してしまうのです。

上流工程が起因によるソフトウェア開発での失敗の対策は、次の３点でおこなれなければなりません。

・価値ある作業プロセスだけで作業標準プロセスを構成する
・作業を行うことで価値をアウトプットする
・価値を計測することで要件が実現できているかを検証する

レビューの強化なんて対処療法です。