記事要約
- プロセスを改善するためには、プロセス構想とプロセスモデル、ひいては組織の文化をすべて見直す必要がある。
- 改善のためには問題を可視化する必要があり、そのために監視と面談がとくに重要である。もっとも困難な問題は、しばしば「個人的問題」であり、面談によってあぶり出すことができる。
- プロセス改善が効果をもたらしたかを判断するために、つねに監視しておく必要がある。なぜなら、実際のプロセスはつねにプロセスモデルから予期せぬしかたで乖離するからである。
書籍情報
Amazonリンクで出典と代えさせていただきます。
注意
この記事は自らの読書体験を可視化するためのものです。
記事タイトル内にある本の内容を正確に描写することは保証しません。
練習問題の本文は、改行を変更した箇所もありますが、文章は完全に引用しております。
※ 問題解説は筆者の解釈です。本の中には書かれていません。
構成
タイトルの本全体および、章について自分なりのまとめを書く。
その後、章末の「練習問題」を解くようにした。
本の概要
ソフトウェア開発における品質と生産性向上のための環境をどう作るかについて書かれたもの。
全４巻のシリーズ構成となっており、この本は４巻目。
前３巻までで解説した管理ツールとしての考え方を用いて、
組織に健全なエンジニアリングマネジメント（本では工学管理と称していた）を将来にわたり継続できるようにするための方法を述べている。
１４章の概要
この章では、プロセスを実際に改善するための取り組みについて説明されている。
ここに至るまでに、良いプロセスとは何か、また、プロセスは何に影響されるのか、が説明された。
この本は、「組織に良い変革をもたらすには実際にどう行動するか」について書かれたもので、この章では実際にプロセスを改善する行動について書かれている。
１３章で、プロセスは「プロセスモデル」と、「プロセス構想」に強い影響を受けるものだと説明されていた。
その対応関係は以下の通りであると認識している。
| 名前 | 役割 | 別の表現 | 依存するもの |
|---|---|---|---|
| プロセス構想 | どうなりたいか | ビジョン、理想像、将来像 | 経営層の欲望 |
| プロセスモデル | どうあるべきか | ミッション、使命 | プロセス構想 |
| 実態プロセス | 実際の行動 | 設計、開発、調整 | プロセスモデル |
実態プロセスは、プロセス構造に依存はするが、しかしプロセスモデルを正確に反映しないものでもあったりする。
それとは反対に、実態プロセスを改善するためには、プロセス構想とプロセスモデル、ひいては組織の文化をすべて見直す必要があると書かれている。
上記３つのプロセスの意味に対して、以下の４つの改善ステップを適用することが古典的なプロセス改善戦略である。
- 実態プロセスを文書化する
- 問題の根本原因を発見する
- プロセスを修正して変動を縮小する
- プロセス改善をテストする
改善チームはしばしば、その背後における根本原因を究明せずに症状だけに対処しようとする。根本原因を理解して初めて、チームは解決案を選択し、以前は暗黙の存在だったステップを加えてプロセスモデルを修正できる。
(p.286)
これは組織の文化に対しても同じである。上級管理層の行動を明確にモデル化しなければ、文化の変革は不可能である。
実態プロセスが改善されたら、本当に改善されたか監視することがつねに必要である。なぜなら、実態プロセスはつねにプロセスモデルから予期せぬしかたで乖離するからである。
監視が大事なのは、現実がつねに理想と離れるから。
言い換えると、「予想がないと監視する意味がない」ということ。
監視と面談は、乖離の背後にある目に視えない要因を明るみに出すために不可欠であるといってよい。これらの要因はしばしば、その文化の下ではふつうには議論できない人的要因である。ひとたびこれらの要因が明らかになり処理されると、将来同じパターンの再発を予防する文化変革の制度化がしばしば必要となる。
(p.287)
エンジニアにとって監視は重要だとよく言われるが、面談も同じように重要なものだとは思わなかった。
人的要因に対する可視化には、面談も大事なのだ。
多くのプロセス改善環境を研究すると、原則のあるパターンが視え始める：
- 個人的問題がしばしばもっとも困難な改善環境の背後にある。
- 短期的解決への取り組み方が文化的前例を設定する。
- 文化が変革されないかぎり、同種の個人的問題が再発しつづける。
- 文化変革は上級管理層を巻き込むことになる；さもなければ、最初にプロセス問題を生んだまさに同じ文化がその改善を元に戻しつづける。
- まず論理的なプロセスを変革できるが、これを問題全体が論理的なものかどうかを見るテストとみなせ。
- 感情的問題に対処するには、何を口にしてはいけないかを支配する文化的慣行に保護されている表層よりもっと深い情報に届く必要がある。
- 非難がましいやり方では変革はできないことに留意せよ。
- 非難を控える政策は追従政策を意味しない。
(p.287)
プロセス改善をいくらやっても、組織の文化が変わらなければ同じことだ。いまの現場ではプロセスモデルを改善しようと外部のPMOを入れていたが、上位層の意向でそのPMOがいなくなると、改善されたはずのプロセスは見事に元に戻ってしまった。
また、非難がましいやり方では、人は非難されないように情報を隠すようになる。自分も、怒られるのが大の苦手で、「なんで遅れたんだ！」と怒鳴られると、次からは遅れを「うまく」隠すようになる。つねに北風にさらされているような気分になりたくないのだ。
プロセス原則の学習を回避するありふれた方法は、「そう、とても結構。でもわが社は別だ」ということである。なるほど細部はつねに異なるが、原則は同じだし、結果も似たり寄ったりなのだ。
(p.287)
これはソフトウェア開発にも同じことが言えるように思う。特異なシステムだとしても、原理原則が同じものであることは非常に多いと感じる。
練習問題
問題１
読者自身の組織の金網事例を3件挙げることができるか？
管理層はそれらについて知っているか？
彼らの反応はどうか？
彼らの反応は作業者にどのように影響するか？
問題解説
金網事例というのは、本章の冒頭で紹介されていた事例で、プロセスモデルのみに注力して現場の実態を見ないことを現した言葉。
著者の友人である組織開発コンサルタントが有名なチェーンソー製造企業の工場を視察したさい、マネージャが工場の製造プロセスがいかにハイテクかを紹介している横で、工員が作業場の一画に置かれている大きな金網のロールを１フィート四方に切り取っていた。
マネージャはその作業について知らないと言ったので工員に尋ねると、チェーンソーの外カバーを塗装したあとで乾燥させておく標準の乾燥台がチェーンソーを支えきれずに床に落ちるので、切り取った金網を使って乾燥台をいちいち作成しているのだ、ということだった。
工員は毎月何回か、金網の大ロールを自腹で購入している。
自分の回答
以下の３件を挙げたい。
- パソコンのメモリ足りない事件
- 開発アカウントの過剰セキュリティ事件
- テスト自動化あんま意味なかった事件
パソコンのメモリ足りない事件
自宅から１時間くらいの勤務先で作業をしていたとき、急きょ通勤に２時間かかる顧客先へ移動させられることになった。
以前の作業場でのパソコンはメモリ8GB。移動先では4GB。移動前に使っていたIDEでは起動が遅すぎるため、メモリ増設してと訴えた。
だが、「ほんの２，３か月だから」だとか言われて受け入れられなかった。
結局、1年半その作業場にいた。
あとあと考えてみると、なぜ自分がそこにいなければならなかったのか全く不明である。
そこにいたほうが作業効率が良いからなんだろうか？
しかし、メモリ不足でブラウザを立ち上げるとカクカクしてしまうPCを使わせておいて、作業効率もなにもあったもんじゃない。
自分はしばらくは頑張ったが、１年後に管理者へのヘイトが爆発し、移動を願い出た。
開発アカウントの過剰セキュリティ事件
Linuxのアプリケーション実行ユーザのパスワードが開発者に伝えられていなかった。
Tera Termで操作する場合は、開発者の個人ユーザを作成するときに顧客がアプリ実行ユーザへのsudo設定を付与してくれるので問題はなかった。しかしソースをアップするときはアプリユーザで接続できない。まず個人ユーザで接続して個人用のアカウントにアップロードし、アプリユーザにsudoしてターミナル上から操作する必要があった。
管理者はこのことを知っていた。しかし改善されることはなかった。改善しようとも思わなかったのかもしれない。
開発者は結局、自作ツールを使ってアップロードを効率化しようと頑張った。
それで効率化は確かにされた。しかし自作ツールなのでドキュメントも無い。新規メンバが加わるたびにいちいち説明をするのがとても苦痛だった。
ステージングサーバならともかく、開発サーバの開発ユーザのパスワードを知らされないというのは、作業効率を著しく下げるばかりでセキュリティの恩恵も何もなかった。
管理者はたしかにソフトウェアアーキテクチャを考える頭はあった。しかし効率的な開発はアーキテクチャを考えるだけで成立するわけではない。メンバーは、非効率なチーム運営にそのうち疲弊し、言葉を上げることに無力感を感じはじめてしまった。
テスト自動化あんま意味なかった事件
Test::Moreなどのモジュールを使って自動テストを作った。
Seleniumも使ってGUIテストも自動化した。
そんなテストコードが管理者に理解されなかったのだろうか、こちらでリポジトリに登録したものがごっそり無くなっていた。
なぜ？と思い「登録されていたテストコードを登録していいですか？」と聞いたら「はい」と返ってきた。
管理者は本当に開発者なのだろうか？？
というか、これはテストコードの効率性について開発者が説明不足だっただけかもしれない。
しかし、この管理者はいったい何を管理しているのか分からなくなった。
管理者に不信感が募った。
問題２
読者の組織で試みたプロセス変革を一事例選択せよ。
どのプロセス原則を適用し、どれを無視し、そしてどれに違反したか？結果はどうだったか？
問題解説
こうしたくてこうしました、的なことを書く。
自分の回答
いまの現場で過去に実施されていた横断的プロセス変革のことを書こう。
これは何かというと、顧客の組織が弱点としているプロジェクトマネージメントの手法について、外部のPMOにいくつかのプロジェクトを横断的に見てもらうというものだ。
プロジェクトの計画フェーズ（要件定義、WBS作成）からテスト推進に至るまで、プロジェクトを効果的に進めるための組織推進をお願いしていた。
自分はそのPMOが担当するプロジェクトのひとつでサーバサイドエンジニアをしていたので、WBS策定などの上位工程には関わらなかった。
しかしテスト推進や、朝会など、全員が参加する場所では関わりがあったのでその視点から分析してみる。
まずPMOの人は結構当たりが強く、グイグイと物事を進めるタイプだった。いわゆる「ボス」タイプだ。
一方で、現場の作業員に対する作業環境面でのケアも出来る人だったし、組織の管理層に対しても説得力のある説明ができる人だった。
組織の文化を変革していこうという意図が、顧客の経営層かもしくは中間管理層にあったのだと思う。その意味で、変革のために組織の全階層を巻き込んだといえる。
しかし結果としては、あまりうまく行かなかった。PMOが離任してから、マネージメントの質が明らかに落ち出した。
全階層を巻き込まず、クローズドな領域に逃げ込んで部分最適化をひたすら行う組織に戻った。もともと、やりたいことを自由にやる気質の人たちが揃っていたことが大きな原因だったと思う。他人のことなんて二の次。外部の人間はコスト。エンジニアリングマネージメントのエの字もない単なる慣習型組織になってしまった。
PMOが当たりの強い人だったため、怒られるのを嫌って重要な情報をオープンにしなくなった。
PMOはあくまで外部の人間であったため、組織を推進できても組織開発まで出来なかったということも後でわかった。
上位層を巻き込むことも、結局は出来ていなかったのだ。
個人的な問題に踏み込むことも出来なかった。外部の人間だからという理由で。
そして推進をしている間も、自チームの管理者からは「こいつうるせぇな」程度の認識しかされていなかった。
こうして、組織は死んで行ってしまうんだなと思った。
問題３
自分の組織で改善したい事柄に対して、読者ならプロセス改善の原則をどのように適用するか？
問題解説
問題２をふまえて、自分ならどうするか？
自分の回答
これは正直キツイ。何がきついって、今まで不満ばかり言ってきた自分と正面から向き合うことになるからだ。
いろいろ見えても、見えてるからって対応できるとは限らない。
ただ、個人面談のしくみというか、個人がどんな感情や課題、望みを持っているかについて可視化できるようなことはやって損はないと思っている。
結局、いまの組織はやりたいことを自由にやることを奨励している風潮だし、そういう人が集まってもいる。プチアメリカみたいな感じだ。
だからこそ、チームワークが弱い。他人との折り合いが付けられていない感じがする（これはそのまま自分への課題だ。）
そして、見えたからといって対応するかどうかはまた別の話だ。
『コンサルタントの秘密―技術アドバイスの人間学』にも確かそんなことが書いてあった。「頼まれてないかぎり、依頼主の問題でも解いてやるな」と。正確には本章との文脈は異なるが、言ってることは同じであって、問題解決を直接することが本人のためになる場合もあればそうでない場合もある。解決しないと組織に悪影響が及ぼされる事態にならない限り、そこまで直接的に関わってしまうことが却って事態を悪くすることもありうる。
ただし、仕事が出来るエンジニアを、その人と折り合いが悪いからといって簡単に潰してしまうことは非常に勿体ないことだとは思う。
自分はずっとエンジニアとして生きていきたいし、現場のエンジニアが一番偉いと思っている。そんなわけで、人をモノみたいに雑に扱い、尊重をしないような感じにはなりたくない。