update it, Inc.社長のブログ

ある人から、自分のプロジェクトメンバの書いたドキュメントについて、お客さんからわかりづらいと言われているという話を聞きました。実は私も似たような経験があります。どうもシステム屋の書いたドキュメントというのは、ユーザからわかりづらいといわれることが多い気がします。どうしてでしょうか？

わかりづらいといわれる理由には様々あって、簡単に1つの理由ですべてを言い表すことはできないとは思いますが、１つの傾向として、システム屋というのはどうも細かいことをくどくどと書きすぎる傾向があるように思います。でも書いている側からみれば、どれもこれも大切なことであり、そう簡単に削れるようなことではなかったりします。ではユーザの側が面倒くさがって、内容をよく読もうとしないのがいけないのでしょうか？　うーん、それはそれで、一方的な思い込みかもしれませんよね。

ひとつ思うこととしては、相手が何を求めているのかを考えて書いているか、ということがあります。つまり読み手側の立場に立って書いているか、ということです。

システム屋は自分がこれからやろうとすることをできるだけ細かく、正確に書いて、それの承認を得ようとします。この場合、そこに書いているのは「自分がこれからやること」という観点で書いています。でも「自分がこれからやること」と、ユーザが「やって欲しいと思っていること」がすり合っているかどうかが簡単に判断できない場合、ユーザは「わかりにくく」感じるのではないでしょうか？

つまりユーザの視点で、何を解決しようとしているのか、何をしようとしているのかを明確にし、それに対する解決策として、前提条件や考え方を明記し、その後で具体的にやることを対応を付けて書く、というようにするだけで、ユーザ側のやって欲しいことと、システム屋がこれからやろうとしていることとの対応付けが簡単にできるようになり、ユーザの「わかりにくい感」を減少させることができるかもしれません。

昨日は「生きたプロセス、死んだプロセス」という題名で反復可能で改善可能なプロセスの話を書きましたが、今日もそれに関連した話題です。

もし、あるプロジェクト・チームが優れた、反復可能で継続的な改善可能なプロセスを長年培ってきたとします。ではそのプロセスを標準プロセス化したら良いのではないか？　そう考える人もいるでしょう。　でも、おそらく、それを標準プロセスにして他のプロジェクト・チームにそのまま適用したとしても、結局は昨日書いた「死んだプロセス」になってしまうと私は考えています。

優れたプロセスとは各プロジェクト・チームが徐々に改善を積み重ねて編み出していくものだと思うからです。せっかくの優れたプロセス定義があったとしても、なぜそれが必要なのか、それによって何を得ようとしているのか、そういった背景的なことも含めて良い点、悪い点を理解していないと、宝の持ち腐れならまだ良いほうで、場合によっては足を引っ張るだけになりかねないからです。

プロジェクトが必要とする最適なプロセスとは、そのプロジェクトによって少しずつ異なっているはずです。また手法や開発技術は日々進化しています。また優れたプロセスでは、常に継続的な改善が必要とされます。だから決して「標準プロセス」というのはテンプレートにすぎず、固定的、決定的なプロセスというのは本来存在し得ないはずなのです。

すぐれた開発プロセスというのは、その開発チームの勲章のようなものだと思います。部門毎に異なるプロセス定義を持つ状態よりも標準プロセスに準拠した状態のほうがより上のレベルであると一般にいわれていますが、各プロジェクトが改善と最適化を遂行した結果としてそうなっている場合のことを考えると、常識のウソの１つではないかと考えています。

大手のSIerの場合、その会社独自の開発方法論を持っている場合が多いですが、実際の開発の現場ではどの程度利用されているものなのでしょうか？　一応、WBS(Work Breakdown Structure)はその開発方法論に沿ったものになっているし、各種の儀式（InspectionやCutover criteriaなど）はやっているものの、何かこう、しっくりきていないというか、「やらされている」だけで積極的に推し進めていないという場合もあるかもしれません。

もし、その「しっくりきていない感」があるのだとすると、おそらくそのプロセスで定義されていることが古臭くなっているとか、あまり役に立っていないとか、何らかの理由があるのだと思います。

標準化されたプロセスというのは、ある想定をおいた、いわば仮想のプロジェクトを対象に設定されたものです。実際のプロジェクトにそのようなプロセスをそのまま適用しようとしても、その想定と異なる部分があるのは当然のことといえます。ではそのような場合でも敢えてそのまま実施することに意味があるのでしょうか？　私はそのように、標準化されたプロセスを何の疑いもなくただ実施している場合、そのプロセスは「死んだプロセス」になっていると思うのです。

あるプロジェクトマネージャの人から聞いた話なのですが、その人のプロジェクトの場合、同じような開発を繰り返したことで、独自の開発プロセスが出来上がっていて、しかも毎回、前回の反省点を踏まえてその開発プロセスを見直し、改善してきている、と言っていました。つまり、ちょっとカッコいい言葉でいうと、反復可能でかつ継続的な改善が行われるプロセスということです。

そのプロジェクトマネージャは、今はプロジェクトが非常にうまく回っているので、自分がやることがなくなるのが欠点だ、と言っていました。

これこそが「生きたプロセス」ということではないでしょうか？　標準的なプロセスがあることは悪いことではないのですが、それに縛られるのではなく、より良いものへ常に改善していき、必要な場合にはそこから離れていくぐらいのことが必要なのだと思います。

運用をしている人でないとあまり縁がないものかもしれませんが、今日は障害報告について、です。これをテーマにしたのは、私の経験上、障害報告をもっと「有効活用」すべきではないかと感じることが多かったからです。

システムが障害を起した場合、障害報告書を書いて提出しなければならないことが多いですが、みなさんは、これをどのように活用していますか？　もし障害報告書が単に懲罰的な意味合いでしか使われていないならば、非常にもったいないことです。本来は、同じ間違いを繰り返さないために書くものだと思うからです。

同じ間違いを繰り返さないためには、事後の分析が重要です。直接的な原因ももちろんのこと、その背景の問題についても深い洞察が必要だと思います。そして分析の結果を「失敗のパターン」として広く社内に公表し、改めるべきところを改め、また同じような事例がほかのシステムでも発生しないように社内にとして紹介したり教育していく仕組みがあってしかるべきだと思うのです。

失敗の経験は非常に重要なことです。それを個人の経験として閉じ込めてしまうのは、会社としては大きな機会損失をしていることになります。

こういったことが会社としてうまく機能するようにするためには、それが個人を攻撃するためのものでは決してないことをトップダウン的に伝達し、広く浸透させる必要があります。そうなっていないと、問題を深堀することは、ぎすぎすした、あまり楽しくない職場にしてしまう可能性があるからです。

重要なのは当事者を責めることではなく、次の当事者を作らないように社内が仕組みを作り、バックアップしていくことだと思います。

プロジェクトを進めるに当たって新規に人を採用しなければならないことが多いですが、皆さんは採用面接ではどんなことを聞いていますか？

私は採用面接ではできるだけ具体的で詳細なことを聞くように心がけています。例えば前にやったシステム開発プロジェクトがあれば、それはどんなシステムだったのかとか、どんな人がどのように使うものだったのかとか、どんな技術をどのように適用していたのかとか、自分の役割に応じてどんなことをやったとか、ドリルダウンするように、できるだけ詳細に質問して聞くようにしています。また技術水準を知りたい時には、かなり具体的な、特定の技術に関する質問（例えばXXXはどう使うのかとか、使ったときにどんな問題があるのかとか）をするようにしています。当然こちらの知らない技術分野の場合もありますが、それでもできるだけわかりやすく説明してもらうようにしています。

なんでここまで詳細を聞くのかといえば、一般論として、具体的な質問をすれば具体的な答えが返ってきて、抽象的な質問をすれば抽象的な答えしか返ってこないといわれています。つまり、質問は具体的であるべきだ、と。

そしてもうひとつの、とても重要な理由が、詳細面を「突っ込む」ことで、その人の対象領域に対する理解度の深さを知ることができるからです。つまり知りたいのは相手の知識ではなく、その人が対象領域に対してどのくらい深く理解しているかを知りたいんです。

単に知識のあるなしは一時の能力に過ぎませんが、深く理解するという能力はその人の基本的な、かつ継続的な能力を示していると考えているからです。自分がやっている仕事に対して浅はかな理解しかしていない人に仕事を任す気にはならないでしょう。

ちなみに最悪なのは、XX知ってる？　的な質問だと思います。XX知っている？という聞き方ではその人の対象物への理解の深さに対する判断を、その人自身に任せてしまっていることになります。その人の本来の能力の高さを知る機会をみすみす逃しているわけで、とてももったいなく感じます。

今まで、仕事で「あ、この人はスーパープログラマだな」と思った人に何人か出会いました。スーパープログラマといっても何か一般的な基準があるわけでもなく、学歴も肩書きも資格も関係ないわけですが、明らかに他の人たちよりも「理解力に優れ」、「並みのプログラマの10倍以上の生産性」を上げ、かつ「書いたコードが美しい」人達がいるんです。そういった人たちを私はスーパープログラマと呼んでいます。

こういった人たちに共通するのは、新しいことに対する飲み込みの速さです。「地頭（じあたま）」の良さというのでしょうか。まったく新しいことでも人より早く本質を理解してしまうのですね。プログラミングというのは演習問題をいっぱい解いてお勉強をすればそれなりには組めるようになると思うのですが、そういった基礎能力だけではスーパープログラマにはなれないのだと思います。

かといって、頭が良ければスーパープログラマになれるのかというと、かならずしもそうでもないと思います。誰もが頭が良いと認めるような人がプログラミングをしても、かならずしもスーパープログラマといえるレベルではない場合も多いからです。

いままでお会いした人たちに共通する、重要に思える素質としては次のようなものがあると、私は考えています。

１．集中力、というか熱中力？
２．構成力。コンテキストを読み解く能力。

特に構成力は重要だと思います。全体からコンテキストを読み解いて、自然に構成することができるかどうか。この構成力とは数学とか理数系というよりはむしろ国語力というか、文系に近い能力だと思います。構成力が優れた人ほど理解力に秀でている傾向が強いな、と個人的に持っています。

よくよく考えてみるとプログラミングもコンピュータ「言語」を操つる仕事であり、コンピュータという感情のない機械を相手にしているにせよ、豊かな構成力が求められるのは自然なことなのかもしれません。

会社とは利益を得るために存在しています。ですので通常はプロジェクトが赤字の場合、そのプロジェクトは「悪い」プロジェクトである、とされます。でもそれは常にそうなのでしょうか？

もちろん赤字というのはあまりいいことではないのですが、プロジェクトマネージャーを育てるためとか、将来のより大きな案件のための種まきのためとか、戦略的な理由があるのであれば、必ずしも赤字プロジェクト＝悪とはいえないでしょう。これは将来に向けた投資だからです。

逆も真かもしれません。黒字プロジェクトは常に正しいのでしょうか？　黒字を確保しているのだけれども、中にいる人たちが疲弊しまくっているとか、やる気が出せないでいるとか、辞める人が続出しているとか、もしそのようになっている場合、そのときだけみれば確かに黒字かもしれませんが、将来に大きな負債を抱える結果になってしまっているかもしれません。

でも会社というのは、非常に短期的に赤字・黒字だけで良し悪しを判断しがちです。スタート時点は戦略的意味を強調して赤字でもいい言っていても、いざ決算期を迎えるとやっぱり赤字はだめ、と手のひらを返すようなケースもあります。

なかなか難しい問題ですが、やはり重要なのはコンセンサスでしょう。戦略的に赤字プロジェクトを行うのであれば、その意義について関係者間で十分なコンセンサスを得ておくのが肝要だといえます。

先日、以前買ったドラッカー名言集の経営の哲学（ダイヤモンド社　P.F.ドラッカー著　上田惇生編訳）という本を読み返していたら、「オーケストラが明日の組織のモデル」ということが書いてありました。オーケストラとは団員それぞれが専門家で構成され、全員が同じ楽譜をもつことで演奏できると書いてあります。

これってシステム開発プロジェクトでも同じことが言えますね。プロフェッショナル集団で構成され、プロジェクトマネージャーというコンダクタ（指揮者）の下、同じ楽譜（仕様書や設計書）を見ながらシステムを作り上げていくわけです。

オーケストラでは指揮者とは纏め上げる作業をする人であり、もちろんとても重要なのですが、いくら指揮者が華麗にタクトを振っても各団員の能力がなければ音楽はまとまりません。システム開発でも同じ事で、各プロジェクトメンバの専門的な能力がなければシステムという楽曲を纏め上げることはできませんし、各自が調和して行動することも求められます。

ドラッカーさんはこのような、高い専門性をもった人たちが調和して進めるプロジェクトスタイルこそが「明日の組織のモデル」であるとしているわけです。ぜひそのようなスタイルを目指したいですね。

皆さんのプロジェクトではスケジュールにおいて、バッファをどのように設けていますか？　またどのようにコントロールしていますか？

だいぶ前ですが、エリヤフ・ゴールドラット博士の書いたクリティカル・チェーンという本では、TOC（Theory Of Constraints：制約条件の理論)に基づくのであれば、各タスク毎に満遍なくバッファを分散して取るのではなく、複数のタスクの合流点（それらのタスクが同時に終わらないと先に進めない=クリティカル・パス）の直前にまとめて置くべきだと説いています。こうすることで、「仕事は期限が延びれば伸びだ期限の直前までかかる＝パーキンソンの法則」を克服することができる、と説明されていました。

この本を読んだときにはなるほどな、と思ったのですが、私の場合、実際に適用してみると2つのことがわかりました。

１．（悲しい事実ですが）プロジェクトのスケジュールに明示的にバッファを書くと、それを削れという圧力がかかります。各タスクに分散してバッファを書かないでおけば、そのようなことはないでしょう。
２．クリティカル・パスが頻繁に変化するプロジェクトにおいては意味を成さないことがあります。特に目標が変化するアジャイル的なプロジェクトには向かないと思います。

TOCの理論はもともと生産工程管理の最適化のために作られたものなので、工場向けの理論です。ウォーターフォール的に工程管理している場合には有効だと思いますが、イテレーティブな開発モデルにはあまり有効ではないのかも知れません。

いずれにせよ、スケジュールに「バッファ」を明示的に書くことができなかった、というのは非常に悲しい事実でした。ぜひバッファの正当性が認められるようにしていきたいですね。

あるプロジェクトマネージャから、プロジェクトのチーム体制作りで悩んでいる、という話を聞きました。その人は今、ウォーターフォールモデルで詳細設計まできちんと設計した上で、プログラミングに大量に人を投入するスタイルにすべきか、それとも以前に紹介したセル生産方式というべき、エキスパートのエンジニアを揃えてその人たちに自主的に設計からプログラミングを任せる方式にすべきか、ということで悩んでいるという話でした。

エンジニア達に受けが良いのは後者のタイプです。そのほうが仕事が楽しいと感じられるようです。ただ、できるだけそうしたいのだけれども、なかなか人が集まらなかったり、プロジェクト管理の立場では管理しづらい部分があるという点でなかなか結論が出せないでいる、ということでした。

私が感じたのは、作るもののタイプによってどちらのほうがいいのかは変わるのではないか、ということでした。毎回同じようなものを繰り返して作っていて、システムの仕組み上特別に難しい部分がないということであれば、プログラミング工程で人海戦術が可能な前者のスタイルのほうが効率がいいと思います。プロジェクトの遅延に対しても（あまりお勧めしませんが）人を投入することで回復しやすいと思いますし、管理もしやすいでしょう。

一方、作る対象が非常に高度で難しいもので、研究・開発色の強いプロジェクトの場合には、高い専門性が必要とされることなどから後者のスタイルのほうが良いように思えます。このようなものの場合「作ってみないとわからない」ことが多いので、そもそも詳細設計まで落としてからプログラミングに入るというのが難しいことが多いと思います。

作るものの対象に応じてプロジェクトの体制を切り替えるというのが現実的なのかもしれません。