前回、標準化の流れの中で会社の枠組みが整備されていくにしたがって、組織はどんどん息苦しくなっていったと書いた。

息苦しくなる理由は、業務のための業務、すなわちメタ業務に忙殺されるようになったということ。枠組みができると枠組みが守られているかというチェックが必要になってくる。そのチェック用の資料を作ったりするのがメタ業務に当たる。

会社中枠組みだらけになると、マネージャの仕事のほとんどがメタ業務になる。メタメタ業務も出てくる。本来業務を確実に効率よく回すための枠組みだったはずなのに、本末転倒が発生し、マネージャは葛藤に陥る。

その上、標準化推進部門が権力を持つようになり（審査する側が権力を持つのは当然のことだ）、官僚の論理がはびこる。息苦しくならなければおかしいぐらいだ。

だが、官僚（以下、比喩としてこの言葉を使うが、標準化推進部門の方々はあまり気を悪くしないでほしい）は権力を持つが、一方で善意の人々であることも確かだ。彼らは、このような流れを自分たちで作ったにも関わらず、社員には個性を発揮し、創意工夫して、活き活きと働いてほしいとも考えている。なのに（だから）、社員は応えてくれない。「官僚」たちも息苦しいのだ。

 

こういう状況からどうやったら抜け出せるのだろうか？

テーラリングができる側と、できない側とでは処方箋が違うと書いた（前回）。

テーラリングができる側というのは、元請企業を指す。この場合の元請というのは、実質上の元請を指す。商流上の元請はパートナー企業だが、直接顧客とやりとりして製品の仕様を決めているのであれば、実質上の元請とする。

元請企業のマネージャはもちろんテーラリングができる。メンバーはどうだろうか。テーラリングを手伝う人もいれば、そうでない人もいるだろう。また新入社員などテーラリング自体がまだできない人もいるだろう。ただ、将来も含めた可能性として、元請企業の社員はテーラリングできる側と定義する。

そうするとテーラリングができない側は、下請企業の社員ということになる。

彼らも、自分たちに発注された部分についてはテーラリングはある程度可能だ。しかしながら、元請側が要求する資料はすべて提出しなければならない。また受託契約であれば、レビューを受ける必要は法的にはない。法的にはないが、レビューを拒むことは難しいし、拒めたとしてもレビュー記録やテスト記録は提出しないといけないのでレビューを受けているのと同じである。

この二つの立場では、息苦しさから抜けようと思うとまったく違うやり方になってしまう。

 

まずは、テーラリングができる側から考えてみよう。

ちなみに前回出てきたY社はこちらの立場だ。だから、以下はY社での講演の（肝の部分の）草稿となる。なお、Y社が息苦しいかどうかは社内に常駐していていないから分からない。ただ可能性は高い。M常務の要望を伺っていると、たぶん少しずつ風通しを良くしていきたいという思いを感じるからだ。

こちらに提案したいのは、テーラリングなんてけちくさいこと（もちろんこんな言い方はしない）を言っていないで、自分で枠組みを作ってしまえばいいということである。

たとえば業務アプリケーションを作っているチームがあるとする。業務アプリケーションにおいては、今となっては何でもやりますというのは現実的ではない（少なくとも中堅以上のSIerであれば）。

プラットフォームを決めて（プリミティブなものでもいいし、パッケージソフトでもいい）、業種・業態・対象業務を明確にし、開発規模も想定する。いったん決めたら、それしか当面はやらない（市場の変化に対応するための定期的な見直しは必要だ。しかし、プラットフォームや開発規模にはこだわる。範囲外の技術や分相応でない規模には手を出さない）。

決めてしまうと、やり方もおのずから決まる。そこから枠組みも決まる。

その後、自分たちで作った枠組みに、会社の枠組みをテーラリングすればいい。テーラリングの方向を逆にするのだ（下図）。

※上図で、チームとプロジェクトと言葉が違うが、間違えたのではない。あえて変えている。プロジェクト単位でものを考えると、従来のテーラリングをせざるを得ない。チーム単位でものを考えるようになってはじめて、会社の枠組みを解釈しようという方向性になる。プロジェクト単位では面倒くさくてやってられないからだ。

 

自分たちで枠組みを作るといっても、社会や会社の枠組みから逸脱するわけにも、無視するわけにもいかない。ここにジレンマがあるのだが、この発想なら、逸脱も無視もあり得ない。それなのに、主体性を取り戻しているところがミソだ。

ただ、標準化推進部門との初期のやりとりは大変だろうと思う。それでも一度決めてしまえば、前例ができるのであとは楽だ。官僚は前例に弱いからだ。

さらにいいのは、自分たちで枠組みを作るということは、官僚たちの奨励している、個性を発揮し、創意工夫し、活き活きと働くことにもつながるということだ。それを力説すれば、彼らも協力せざるを得まい。

 

そんな簡単にいくかと尻込みする人もいるだろう。

しかし、考えてみてください。枠組みに完全準拠でもプロジェクトが成功すると思う人も中にはいるだろうが、こういう人は息苦しさはないはずだ。

まあ、できるかもしれないけれど、そのためにしては余計な仕事が多いなあ、これがなければもっと本来業務に集中できる、残業も減るのになあ、と思っている人が、今この記事を読んでいるはずだ。

実際問題として、枠組みに完全準拠して、大量のドキュメントを作っても、それってお客さんは全部目を通してくれていますか？ そんなものより動くもの、見えるものを早く作ってくれ、そしたら一緒にチェックできるって、お客さんは言ってませんか？

 

本当はあなたもそうしたいのだけど、会社が仕様変更は絶対拒否、あるいは有償で受けろと言うから、一生懸命ドキュメントを作っているのではなかったか（これはIT業界に特化する話かもしれないが、受注生産には共通する悩みかもしれない）。

でも、仕様変更を受けられないのは、本当は大量のドキュメントを作っているからじゃないですか？ 画面の項目を一個増やすだけの簡単な仕様変更でも、ドキュメントを全て修正し、修正がすべてなされているか確認し、それをまたお客さんにチェックしてもらう、これらの工数を考えるとめまいがしますよね（そして、これだけの工数をかけても必ず漏れがあり、ドキュメントの保守はどんどん不可能になっていく）。

仕様変更絶対悪という"常識"を捨てるだけでも枠組みは変わる（下図）。不要なドキュメントは減り、動くものが早く見せられるようになり、その場で修正もできる。言った言わないなんて話がなくなり、その調整に費やす工数も減り、お客さんも満足、自分も満足、その上官僚たちも創意工夫したとほめてくれる。

結果オーライなのです。

 

  

一方で、枠組みに完全準拠して、プロジェクトが失敗したとしても、官僚たちはまったく責任を取ってくれない。理不尽でもなんでもない。それが役割分担なのだ。

問題は、枠組みを自分たちで作ってプロジェクトが失敗した場合。このときは枠組みを守らないからだと官僚たちに責められるだろう。でも、完全準拠して失敗しても責められるのである。同じことではないか。

そして、完全準拠のほうが失敗の確率は高いと、あなたは分かっている。

だったら、自主性を取り戻さない手はあるまい。

 

こんな例がある。

僕の後輩のT君は、1億円規模の案件のマネージャだった。

彼は、枠組みを守るということが本当に嫌いなやつだった。不景気なので社員はフレックスを実質返上し、９時から出社しろという業務命令にも敢然と逆らった。メンバーには10時出社の指示を出した。どうせ夜遅いのだから、残業時間が増えるだけ、それならメンバーを多少でも休ませてやりたい、というのが彼の理屈だった。

顧客との打合せを密にするが、ドキュメントはほとんど作らない。文書によるやり取りよりも、顧客との信頼関係を大事にする。グローバルスタンダード的にいえばナンセンスだ。顧客との信頼関係作りよりも、契約書を充実しろということになる。向こうでは契約を守った結果が信頼なのだ。

たしかに日本でしか通用しないやり方なのかもしれない。ただ、ここは幸い日本だった。T君のやり方は大成功を収め、彼のプロジェクトはあり得ない利益率を叩きだした。

社長は絶賛。朝９時から出社しろと言っていた張本人が、T君の決断（メンバーを10時に出社させたこと）はすばらしいと言う。

 

実際、自分たちで枠組みを作ったほうがうまくいくのです。

嘘だと思ったら、以下の記事を見てほしい。

誠ブロガーの島田誠さんの会社、プラムザの事例だ。島田さん自身の記事もある。

▼SEの未来を開く、フルスクラッチ開発術
http://jibun.atmarkit.co.jp/lskill01/rensai/fullscruch/01/01.html

▼開発にドキュメントなんていらない(1/2)
http://blogs.bizmakoto.jp/noubiz/entry/4641.html

▼開発にドキュメントなんていらない(2/2)
http://blogs.bizmakoto.jp/noubiz/entry/4652.html

島田さんの記事（開発にドキュメントなんていらない）は、中堅以上のSIerの社員には少し過激に聞こえると思う。

僕自身、ドキュメントを大量に作るということにはずっと肯定的だった（仕様変更は絶対悪と思い込むトラウマがあったのだ）。SIerにいたときも、その後ユーザー企業側のITコンサルタントになったときも、そうだった。それは単に、枠組みに囚われていたからだと気づいたのは、島田さんの話を聞いたからだ。かなりのショックだった。僕は多くのプロジェクトを失敗させてきたが、そのときは必ずドキュメントを作るというほうにこだわっていた。

島田さんのやる通りには、すぐにはできないだろうけど、少なくとも枠組みに疑問を持つきっかけになればと思う。

 

次回は、テーラリングできない側、すなわち下請企業の社員への処方箋を書く。こちらは一筋縄ではいかない。