作成者:yasunaka昔、転職をした際に、転職前後で「あれ?」と思うぐらい文化的な違いを感じたことがあります。いう言葉で表現すべきか、いまいち適当な言葉が見つからないのですが、とりあえず「説明責任と合意」というように表現しておきます。その転職以前は、仕事はあうんの呼吸で行うものという認識がありました。できるだけ普段から密にコミュニケートすることで、極力あうんの呼吸を保つ。することで非常に効率的に物事を進めることができます。その一方で、私の場合、きちんと説明し、合意を求めるという部分をたびたび省いてしまっていることがありました。結果としてなんとなく相手が理解しているものと期待しているのに、いざ蓋を開けてみたら非常にまずいことになっていた、なんてこともあったかもしれません。転職先で感じたのが、この「説明責任と合意」を意識してやっているな、という点でした。その会社の経営陣の人はかなり意識して、自分の言葉できちんと説明し、相手に納得してもらうということをやっていたように思います。正直なところ、私はいまだに「説明責任と合意」を、結果としてないがしろにしてしまうことが多いように思えます。意識してそうするように努めてはいるのですが、後になって反省することが多々あります。長年培った仕事のスタイルというのは一朝一夕にはなかなか変わるものではないのかもしれません。長年連れ添った夫婦でも同じような状態になる例があると聞きますが、やはり説明すべき点はきちんと説明するという姿勢が必要なのだと思います。勝手に相手がわかっているだあろう、という推測のもとで物事を進めるのではなく、きちんと「説明責任と合意」を果せるよう、努力していきたいと思います。作成者:yasunaka最近、SIerの受注ソフトウェア開発業の会計基準が2009年4月から工事進行基準に変わる、という記事が@ITで流れていました。IT業界に義務付け「工事進行基準」ってなんだ従来は工事完成基準といって、開発終了時に売り上げと原価を一括計上することが多かったのですが、こうするとどんぶり勘定で行われるプロジェクトが多かったということで、これからは工事進行基準にすることで会計上におけるプロジェクト開発の透明性を増そう、という話らしいです。工事進行基準のやり方はいくつかあるようですが、一般的な原価比例法の場合、工事原価と実際にかかった原価から進捗率を求めるという方法になります。して求めた進捗率と、工事収益総額、および工事原価総額により、工事進行基準における損益が計算できることになります。従ってプロジェクトを開始する前に原価と収益の見積もりをある程度の精度で求めることが要求されます。実際にかかった原価を裏付ける資料も必要になると考えられます。この工事進行基準という考え方は、もともと工事進行基準が適用されてきた建築工事などのおいて、長期の請負工事においてあらかじめ収益の獲得が保証されているのだから、各決算期毎に適正に収益を計上しなさいよ、というところから出来上がっているようです。実際上記の原価比例法で損益計算するとして、赤字プロジェクトの場合には途中から人を余計に投入して回復しようとするため、その時点で見積もり修正をしなければ実際より早く進捗率が上がっていくことになります。これはこれで変ですよね。?私自身、このあたりはまだ疎いので、もうちょっと勉強してみようと思っています。現実問題として大きなプロジェクトの場合、「変化を抱擁」して失敗した、という例も多いため、できるだけ変化しないで済むようにコントロールすることが多いと思います。変化を受け入れるためには、できるだけ小さい単位で「完結」していることが重要です。その単位で完結していれば、完結する範囲では変化を固定することができます。完結した後で、次回(次のイテレーション)で次の変化を取り入れればよいのです。逆にいうと、完結していない単位でいろいろと変化を抱擁してしまうと、収束しない、デスマーチ状態になりがちです。大きなプロジェクトの場合、それを細かい単位で完結するようにするように進めるのはなかなか難しい部分も多いと思います。しても長めの時間が固定されることになる。これはある程度仕方がないことだと思います。それでもやはり、できるだけ細かい単位で分けられるような構造にして、それぞれがイテレーションの1単位として完結できるようにすべきでしょう。そのような形にすれば、プロジェクト管理の観点からも非常に望ましい結果を得られると思います。細かいイテレーションの単位に分解した場合、その当初「どういう仕様にしたのか」をきっちり管理することが必要です。ベースライン管理ですね。イテレーションを基準としたベースライン管理がきちんと出来ていることが「変化を抱擁する」ための最低条件だと思います。いうことで、ベースライン管理にはcrossnoteをどうぞ。(なんだ、結局宣伝か。作成者:yasunaka金曜日にある勉強会に出ていたのですが、その会ではコーディング規約が守られないのを如何に守ってもらうか、という話をしていました。Microsystems社のJava言語のコーディング規約の「コーディング規約の必要性」には以下のようなことが書いてあります。・ソフトウェアの生存期間におけるコストは、その80%が保守に費やされる。・ソフトウェアの保守が最初から最後まで元の制作者によって行われることは、ほとんどない。・コーディング規則は、エンジニアが新しく目にするコードをすばやく完全に理解できるようにして、ソフトウェアの可読性を向上させる。・ソースコードをひとつの製品として出荷する場合、それがその他のすべての製品と同様にちゃんと梱包されていて、綺麗なものであることを確かめなければならない。—つまり「ソースコードを誰にでも読みやすくするためのルール」がコーディング規約であるといえます。自分にとって読みやすいということではなく、誰にとっても読みやすいかどうか、です。汚いコードを書いて、そのままにしてしまうと、それは当然、他の人にとって「読みにくい」コードであり、いわば負債を抱えた状態になります。後でそのコードに含まれたバグを取らなければならない人は非常に苦労することでしょう。この考えからすると、独自のコーディングルールというのはこの精神からは外れたものだ、といえます。独自のコーディングルールは、そのルールに皆が慣れ親しんでいれば良いのですが、人材が動いたときにそのコーディングルールに慣れるまで余計な時間(=コスト)が発生する、という問題があります。C言語のように「何もない」場合にはいろいろと独自のルールを導入しなければならないかもしれませんが、JavaとかC#のような言語の場合、むしろできるだけ素な、元々の言語に用意されたコーディングルールをそのまま採用するというのが正しい戦略だと私は思います。作成者:yasunaka通常、プロジェクトにはいろんな会社の人が集まります。協力会社やユーザ企業、コンサルタント、いろいろなバックグラウンドを持った人達の集まりです。いった人達が一緒になって1つの仕事をしているわけですが、なぜか昼飯時になると「同じ会社」同士で飯を食べに行く、なんて傾向が強くありませんか?もちろんそうではない人もいます。所属とは会社に所属するものであって、プロジェクトに所属するものではない、という意識が自然に出来上がっている場合が多いように思えます。確かに社外秘の情報があるような場合には、同じ会社の人だけで、というのはわかりますが、普通に話しているときには同じ会社かそうでないかはあまり関係ありませんね。会社に所属しているという結びつきよりも、一緒に仕事をしている、という関係のほうがよっぽど強い関係のはずです。会社というよりはプロジェクトに所属している、という感覚が出てくることがプロジェクトを成功させる上では重要ではないかと私は考えます。おととい、昨日とちょっとどたばたしていてブログが書けませんでした。昨年はKY(空気が読めない)という言葉が流行りました。確かに空気が読めるというのは重要なことで、読めないよりは読めるほうが良いに決まっています。空気を読むというのもいろいろなシチュエーションが考えられますが、人の顔色を伺う、という使い方で考えた場合、人の顔色ばかり伺っているようではだめですよね。日本は、やたらに人と同化したがる傾向が強い人が多いと思います。同化していると妙な安心感を得るのがその理由だと思うのですが、自分の主義・主張を言う、という部分を、その「空気を読め」という暗黙の了解が押し殺してしまっていたら、大きな損失なのではないでしょうか?で、今日の本題はKYではなく、GYです。Gとは「行間が」、Yは「読めない」。日本のシステムの仕様書などでは行間を読む、ということが古来行われてきました。仕様書にはすべての情報が明示されているわけではなく、システムを作る側が仕様書を読み解き、行と行の間に省略されているであろうことを嗅ぎ取る能力が求められました。最近のオフショア開発ではどうも2つの傾向があるようです。最初の、仕様書を書く側が行間を埋める方向というのは、国際スタンダードな方法に自分達のやり方を変える、という、通常のやり方です。面白いと思うのは、結構2のやり方を推進するケースも多い、ということです。GYなヤツは相手にしない、という方法です。確かに教育は大変ですが、長期的に見ると2のやり方のほうが理にかなっていると思われます。システム開発においては様々なフィードバックが開発現場側からもたらされます。行間を読める教育をしていれば、そのようなフィードバックが得られる可能性が高まるからです。問題なのは、行間を読み取れるオフショアのSEは、そう多くはなく、かつ成長すると他に移ってしまう可能性がある、ということだと思います。1.と2.の両方をうまく使っていくやり方が必要なのかもしれません。作成者:yasunaka昔、PM(プロジェクト・マネージャ)の研修を受けたときなどに、「仕切る」ことの重要性を習いました。境を作って他と区別する。隔てとなるものを設けて、いくつかの部分に分ける。ある範囲の物事を掌握し処理する。帳簿または取引の決算をする。相撲で、両力士が土俵中央仕切り線の所で、両手を土俵に下ろして立ち合いの呼吸合わせをする。(Yahooの大辞林より)PM研修のときに習った仕切るという意味は、上記のうち2を指しているように思いますが、実際には微妙に1の意味を含んでいると思われます。能動的に自分の身に引き受けて行う、という意味だけでなく、物事を「切り分ける」というニュアンスを強調するために、この「仕切る」という言葉を使っているように感じました。取仕切る、つまり自ら一身に引き受けて行うことも重要ですが、実はそれだけでなく、いろいろと、こんがらがったことを「切り分けてあげる」ことこそが、この仕切ることのポイントなのだと私は勝手に解釈しています。切り分ける、つまり物事を整理し、分類し、さらにはそれを皆に知らしめることまでの一連の行為を「仕切る」という一言で表現しているのだと思うのです。物事を切り分ける、とはすなわち、物事を構造化する行為です。これって実はかなり頭を使う行為なんですね。同時に「取仕切る」わけですから、そうして構造化して切り分けたことを皆に伝え、それで物事が回るように仕向ける。これは結構大変な仕事だと思います。作成者:yasunaka以前、同じタイトルでオーケストラとシステム開発の類似点というのを書きました。ドラッカー名言集の中の言葉で、「オーケストラが明日の組織のモデル」というのを紹介して、それとシステム開発プロジェクトとの類似性を書きました。「高い専門性をもった人たちが調和して進めるプロジェクトスタイル」こそが、明日の組織のモデルであり、それを具現化しているリファレンスとして、ドラッカーさんはオーケストラを紹介しているのですが、私はシステム開発も同じだ、と考えています。テレビの話で恐縮ですが、私はクラッシックファンで、「のだめ」というドラマが非常に気に入っています。先週末、その「のだめカンタービレ」のドラマスペシャルがあるということで、非常に楽しく見ていました。このドラマの主人公は男女の二人いて、男性側の主人公は指揮者を目指しています。今回のドラマスペシャルの1回目では、その指揮者を目指す男性側の主人公が指揮者コンクールに出て、オーケストラのメンバーとの確執などを通しながら最後はうまく纏め上げてコンクールに優勝する、というストーリーだったのですが、その最後にうまく纏め上げることができた最大の秘訣は、直接この言葉をドラマで使っているわけではありませんが、Respectすること、でした。プロフェッショナルの集団をうまくまとめるための秘訣とは、互いにRespectし合うこと、またそうできるように、切磋琢磨し、自分を磨き上げておくことなのだと、私はこのドラマを見て感じました。振り返ってシステム開発の現場も様々な役割をもったプロフェッショナルによる集団であり、プロジェクトマネージャーというコンダクターの下、システムを作り上げる作業に一致団結して望まなければなりません。このドラマのオーケストラのように、Respectし合えるようにしていきたい、と強く感じました。2007」の基調講演で、松原榮一氏が「グーグルのサーバ数は日本の年間サーバ出荷台数より多い」と語った話が載っています。