update it, Inc.社長のブログ

昔、転職をした際に、転職前後で「あれ？」と思うぐらい文化的な違いを感じたことがあります。どういう言葉で表現すべきか、いまいち適当な言葉が見つからないのですが、とりあえず「説明責任と合意」というように表現しておきます。

その転職以前は、仕事はあうんの呼吸で行うものという認識がありました。できるだけ普段から密にコミュニケートすることで、極力あうんの呼吸を保つ。こうすることで非常に効率的に物事を進めることができます。でもその一方で、私の場合、きちんと説明し、合意を求めるという部分をたびたび省いてしまっていることがありました。結果としてなんとなく相手が理解しているものと期待しているのに、いざ蓋を開けてみたら非常にまずいことになっていた、なんてこともあったかもしれません。

転職先で感じたのが、この「説明責任と合意」を意識してやっているな、という点でした。特にその会社の経営陣の人はかなり意識して、自分の言葉できちんと説明し、相手に納得してもらうということをやっていたように思います。

正直なところ、私はいまだに「説明責任と合意」を、結果としてないがしろにしてしまうことが多いように思えます。意識してそうするように努めてはいるのですが、後になって反省することが多々あります。長年培った仕事のスタイルというのは一朝一夕にはなかなか変わるものではないのかもしれません。

長年連れ添った夫婦でも同じような状態になる例があると聞きますが、やはり説明すべき点はきちんと説明するという姿勢が必要なのだと思います。勝手に相手がわかっているだあろう、という推測のもとで物事を進めるのではなく、きちんと「説明責任と合意」を果せるよう、努力していきたいと思います。

最近、SIerの受注ソフトウェア開発業の会計基準が2009年4月から工事進行基準に変わる、という記事が@ITで流れていました。デスマーチがなくなる？ IT業界に義務付け「工事進行基準」ってなんだ

従来は工事完成基準といって、開発終了時に売り上げと原価を一括計上することが多かったのですが、こうするとどんぶり勘定で行われるプロジェクトが多かったということで、これからは工事進行基準にすることで会計上におけるプロジェクト開発の透明性を増そう、という話らしいです。

工事進行基準のやり方はいくつかあるようですが、一般的な原価比例法の場合、工事原価と実際にかかった原価から進捗率を求めるという方法になります。こうして求めた進捗率と、工事収益総額、および工事原価総額により、工事進行基準における損益が計算できることになります。従ってプロジェクトを開始する前に原価と収益の見積もりをある程度の精度で求めることが要求されます。また実際にかかった原価を裏付ける資料も必要になると考えられます。

この工事進行基準という考え方は、もともと工事進行基準が適用されてきた建築工事などのおいて、長期の請負工事においてあらかじめ収益の獲得が保証されているのだから、各決算期毎に適正に収益を計上しなさいよ、というところから出来上がっているようです。

でも、ということは、システム開発プロジェクトのように、長期の請負工事においても「収益の獲得が保証されている」とは言い難い状況の場合はどうなんでしょうね？　実際上記の原価比例法で損益計算するとして、赤字プロジェクトの場合には途中から人を余計に投入して回復しようとするため、その時点で見積もり修正をしなければ実際より早く進捗率が上がっていくことになります。これはこれで変ですよね。ということは都度、見積修正をするのか？　どうなんでしょうか？

私自身、このあたりはまだ疎いので、もうちょっと勉強してみようと思っています。

エクストリーム・プログラミング(XP)で有名なケント・ベックの書いた本「Extreme Programming Explained – Embrace Change」のEmbrace Changeの日本語訳として有名な「変化を抱擁せよ」ですが、現実のシステム開発の現場ではどの程度「変化を抱擁」できているのでしょうか？　現実問題として大きなプロジェクトの場合、「変化を抱擁」して失敗した、という例も多いため、できるだけ変化しないで済むようにコントロールすることが多いと思います。

変化を受け入れるためには、できるだけ小さい単位で「完結」していることが重要です。その単位で完結していれば、完結する範囲では変化を固定することができます。一旦完結した後で、次回（次のイテレーション）で次の変化を取り入れればよいのです。逆にいうと、完結していない単位でいろいろと変化を抱擁してしまうと、収束しない、デスマーチ状態になりがちです。

大きなプロジェクトの場合、それを細かい単位で完結するようにするように進めるのはなかなか難しい部分も多いと思います。だからどうしても長めの時間が固定されることになる。これはある程度仕方がないことだと思います。

それでもやはり、できるだけ細かい単位で分けられるような構造にして、それぞれがイテレーションの1単位として完結できるようにすべきでしょう。そのような形にすれば、プロジェクト管理の観点からも非常に望ましい結果を得られると思います。

細かいイテレーションの単位に分解した場合、その当初「どういう仕様にしたのか」をきっちり管理することが必要です。ベースライン管理ですね。イテレーションを基準としたベースライン管理がきちんと出来ていることが「変化を抱擁する」ための最低条件だと思います。

ということで、ベースライン管理にはcrossnoteをどうぞ。（なんだ、結局宣伝か。）  😀

金曜日にある勉強会に出ていたのですが、その会ではコーディング規約が守られないのを如何に守ってもらうか、という話をしていました。（趣旨としては「ある特定の条件において」なのですが、その話はいろいろあるので省きます）

そもそもコーディング規約は何のためにあるのでしょうか？　Sun Microsystems社のJava言語のコーディング規約の「コーディング規約の必要性」には以下のようなことが書いてあります。

— 以下、引用–
・ソフトウェアの生存期間におけるコストは、その80%が保守に費やされる。
・ソフトウェアの保守が最初から最後まで元の制作者によって行われることは、ほとんどない。
・コーディング規則は、エンジニアが新しく目にするコードをすばやく完全に理解できるようにして、ソフトウェアの可読性を向上させる。
・ソースコードをひとつの製品として出荷する場合、それがその他のすべての製品と同様にちゃんと梱包されていて、綺麗なものであることを確かめなければならない。
— ここまで —

つまり「ソースコードを誰にでも読みやすくするためのルール」がコーディング規約であるといえます。自分にとって読みやすいということではなく、誰にとっても読みやすいかどうか、です。

もし汚いコードを書いて、そのままにしてしまうと、それは当然、他の人にとって「読みにくい」コードであり、いわば負債を抱えた状態になります。後でそのコードに含まれたバグを取らなければならない人は非常に苦労することでしょう。

この考えからすると、独自のコーディングルールというのはこの精神からは外れたものだ、といえます。独自のコーディングルールは、そのルールに皆が慣れ親しんでいれば良いのですが、人材が動いたときにそのコーディングルールに慣れるまで余計な時間（＝コスト）が発生する、という問題があります。

C言語のように「何もない」場合にはいろいろと独自のルールを導入しなければならないかもしれませんが、JavaとかC#のような言語の場合、むしろできるだけ素な、元々の言語に用意されたコーディングルールをそのまま採用するというのが正しい戦略だと私は思います。

通常、プロジェクトにはいろんな会社の人が集まります。協力会社やユーザ企業、コンサルタント、いろいろなバックグラウンドを持った人達の集まりです。そういった人達が一緒になって1つの仕事をしているわけですが、なぜか昼飯時になると「同じ会社」同士で飯を食べに行く、なんて傾向が強くありませんか？

もちろんそうではない人もいます。でも経験的に、一緒に飯を食べる相手に同じ会社の人を選ぶ傾向が強いと思いませんか？

飯を食べに行くだけの話ではなく、何かある毎に会社単位でまとまってしまう、というのは実はプロジェクトに対する所属という感覚があまり無いためではないでしょうか？　つまり所属とは会社に所属するものであって、プロジェクトに所属するものではない、という意識が自然に出来上がっている場合が多いように思えます。

しかしなんでプロジェクトではなく、会社なのでしょうか？　確かに社外秘の情報があるような場合には、同じ会社の人だけで、というのはわかりますが、普通に話しているときには同じ会社かそうでないかはあまり関係ありませんね。会社に所属しているという結びつきよりも、一緒に仕事をしている、という関係のほうがよっぽど強い関係のはずです。

会社というよりはプロジェクトに所属している、という感覚が出てくることがプロジェクトを成功させる上では重要ではないかと私は考えます。

# おととい、昨日とちょっとどたばたしていてブログが書けませんでした。

昨年はKY（空気が読めない）という言葉が流行りました。確かに空気が読めるというのは重要なことで、読めないよりは読めるほうが良いに決まっています。ですが、それだけ(空気が読めるヤツのほうが偉いんだ)になってしまうと、何か違うかな？　と私は感じています。

空気を読むというのもいろいろなシチュエーションが考えられますが、人の顔色を伺う、という使い方で考えた場合、人の顔色ばかり伺っているようではだめですよね。日本は、やたらに人と同化したがる傾向が強い人が多いと思います。同化していると妙な安心感を得るのがその理由だと思うのですが、自分の主義・主張を言う、という部分を、その「空気を読め」という暗黙の了解が押し殺してしまっていたら、大きな損失なのではないでしょうか？

で、今日の本題はKYではなく、GYです。（前振りが長い）　Gとは「行間が」、Yは「読めない」。

日本のシステムの仕様書などでは行間を読む、ということが古来行われてきました。仕様書にはすべての情報が明示されているわけではなく、システムを作る側が仕様書を読み解き、行と行の間に省略されているであろうことを嗅ぎ取る能力が求められました。

で、最近のオフショア開発ではどうも２つの傾向があるようです。

１．仕様書を書く側が行間を埋める方向

２．オフショアの受託側が行間を読み取れるように教育する方向

最初の、仕様書を書く側が行間を埋める方向というのは、国際スタンダードな方法に自分達のやり方を変える、という、通常のやり方です。面白いと思うのは、結構２のやり方を推進するケースも多い、ということです。GYなヤツは相手にしない、という方法です。

確かに教育は大変ですが、長期的に見ると２のやり方のほうが理にかなっていると思われます。システム開発においては様々なフィードバックが開発現場側からもたらされます。もし行間を読める教育をしていれば、そのようなフィードバックが得られる可能性が高まるからです。

ただ問題なのは、行間を読み取れるオフショアのSEは、そう多くはなく、かつ成長すると他に移ってしまう可能性がある、ということだと思います。１．と２．の両方をうまく使っていくやり方が必要なのかもしれません。

昔、PM（プロジェクト・マネージャ）の研修を受けたときなどに、「仕切る」ことの重要性を習いました。「仕切る」という言葉を辞書を引くと

１ 境を作って他と区別する。隔てとなるものを設けて、いくつかの部分に分ける。
２ ある範囲の物事を掌握し処理する。取り仕切る。
３ 帳簿または取引の決算をする。
４ 相撲で、両力士が土俵中央仕切り線の所で、両手を土俵に下ろして立ち合いの呼吸合わせをする。仕切りをする。
（Yahooの大辞林より）

PM研修のときに習った仕切るという意味は、上記のうち２を指しているように思いますが、実際には微妙に１の意味を含んでいると思われます。つまり、能動的に自分の身に引き受けて行う、という意味だけでなく、物事を「切り分ける」というニュアンスを強調するために、この「仕切る」という言葉を使っているように感じました。

取仕切る、つまり自ら一身に引き受けて行うことも重要ですが、実はそれだけでなく、いろいろと、こんがらがったことを「切り分けてあげる」ことこそが、この仕切ることのポイントなのだと私は勝手に解釈しています。つまり、切り分ける、つまり物事を整理し、分類し、さらにはそれを皆に知らしめることまでの一連の行為を「仕切る」という一言で表現しているのだと思うのです。

物事を切り分ける、とはすなわち、物事を構造化する行為です。これって実はかなり頭を使う行為なんですね。そして同時に「取仕切る」わけですから、そうして構造化して切り分けたことを皆に伝え、それで物事が回るように仕向ける。これは結構大変な仕事だと思います。

リーダーのみなさん、「仕切って」いますか？

以前、同じタイトルでオーケストラとシステム開発の類似点というのを書きました。ドラッカー名言集の中の言葉で、「オーケストラが明日の組織のモデル」というのを紹介して、それとシステム開発プロジェクトとの類似性を書きました。「高い専門性をもった人たちが調和して進めるプロジェクトスタイル」こそが、明日の組織のモデルであり、それを具現化しているリファレンスとして、ドラッカーさんはオーケストラを紹介しているのですが、私はシステム開発も同じだ、と考えています。

さて、いきなりテレビの話で恐縮ですが、私はクラッシックファンで、「のだめ」というドラマが非常に気に入っています。先週末、その「のだめカンタービレ」のドラマスペシャルがあるということで、非常に楽しく見ていました。

このドラマの主人公は男女の二人いて、男性側の主人公は指揮者を目指しています。今回のドラマスペシャルの1回目では、その指揮者を目指す男性側の主人公が指揮者コンクールに出て、オーケストラのメンバーとの確執などを通しながら最後はうまく纏め上げてコンクールに優勝する、というストーリーだったのですが、その最後にうまく纏め上げることができた最大の秘訣は、直接この言葉をドラマで使っているわけではありませんが、Respectすること、でした。

プロフェッショナルの集団をうまくまとめるための秘訣とは、互いにRespectし合うこと、またそうできるように、切磋琢磨し、自分を磨き上げておくことなのだと、私はこのドラマを見て感じました。

振り返ってシステム開発の現場も様々な役割をもったプロフェッショナルによる集団であり、プロジェクトマネージャーというコンダクターの下、システムを作り上げる作業に一致団結して望まなければなりません。ぜひこのドラマのオーケストラのように、Respectし合えるようにしていきたい、と強く感じました。

今日のZDNet Japanの記事に、ガートナーが昨日都内で行った「Gartner Symposium/ITxpo 2007」の基調講演で、松原榮一氏が「グーグルのサーバ数は日本の年間サーバ出荷台数より多い」と語った話が載っています。

すごいですね。すごすぎです。

でも実は私がもっとも敏感に反応したのは、このグーグルのサーバ数そのものではなく、以下のくだりの話です。

この話の冒頭に、「企業は海外との競争に巻き込まれていることを認識すべきだ。新興国が成長し、パワーバランスにも変化が起こっている」と述べられています。

少し前のブログで、日本のIT産業は研究投資していない、情報化投資していない、という話を書きましたが、海外の様子をいろいろ調べてみると、少なくともITの分野では日本はかなり遅れた国になりつつあるという現状が見えてくると思います。

問題だと感じるのは、当事者の日本国内のIT産業に携わる人達の中で、どれだけの人が危機感を抱いているのか、ということです。ITの世界は大掛かりな資金などなくとも、頭脳さえあれば十分に勝負できる世界です。資金力に限りのある新興国でもITの世界では十分に戦うことができるのです。今まで人海戦術でシステムを構築してきた日本のSIerは、このままでは「ゆでがえる」になるということを自覚すべきではないでしょうか？

昔、プロジェクト・マネージャーの研修を受けたときに、顧客と「握る」ことの重要性を習ったことがあります。「握る」とは、私なりに解釈するならば、

１．システムの目的（何のためにやるものなのか）をはっきりさせ、
２．目的に沿った形で要件の大枠を固め、
３．要件の範囲内で十分であることを顧客側の実質的なヘッドに納得させる

行為です。最初に握れるかどうかがシステムの成否を決める、と教わりました。

今ASP（今流に言えばSaaSか）を扱っていますが、この「握る」という行為はASPやSaaSの場合、存在しないんですね。握る場合にはお客様の代表がいなければならないのですが、ASPやSaaSの場合、当然そのような方はいらっしゃいません。お客様は皆、お客様なわけで、ある客様との間で「握った」としても、他のお客様がそれで満足するとは限りません。

ASPやSaaSの場合、そこから収益が得られているならばどんどん改善していくことができるということ、そして対応する要件の優先順位の決定権が、最終的には提供する側にあるということが「握れない」ことへの代償といえましょう。

とはいえ、お客様からの要望は最優先ですね…