title.png

^<< 2024.03/1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 >>$

Trackback の仕組みはありませんので、コメントにでも残していただくと嬉しいかも、です。

ExtremeExperience

はじめに

エンジニアマインド Vol.2


本ページは、技術評論社の雑誌「エンジニアマインド」の Vol.2 に掲載された記事 『Extreme Experience「誰と」重要』を、 編集部の承諾のもと、公開するものです。まずは快諾をいただいた、編集部に感謝致します。

雑誌に掲載された記事であること、また、2006年12月に刊行された雑誌であること、などの背景があり、 Web上の文章としては不自然な箇所もあるかもしれませんが、ご了承下さい。

お読みになった感想などをいただけると、幸いです。

それでは、記事をどうぞ。

Extreme Experience 「誰と」重要

筆者について

名前
天野 良
所属
XPJUG
筆者紹介
都内の某メーカー系ソフトハウスに勤務するエンジニア。保有資格は、もう長らく操縦していないけれど熱気球のパイロットライセンス。大学の専門は昆虫生態学だったのでナチュラリスト属性もある。XPJUGスタッフ。好きなPFのツールは「偏愛マップ」。

ある日脳梗塞に

筆者は2004年の年末から職場に復帰する2005年6月初頭までの 5ヶ月強の期間、脳梗塞という病気で入院していました。 脳梗塞の中でも脳幹部分にダメージを負ったタイプです。 幸か不幸か大脳などの高次脳には影響はほぼ無かったものの、生命維持に深く関わる箇所だった為、一時は死の淵をさまよいました。 しかし、本稿ではつらかった話をしたいわけではありません。 普通は出来ない経験ですし、もちろん皆さんには絶対してほしくもない経験ではありますが、 このような Extreme Experience とその後の生活を経て、筆者が得たものを少しでも皆さんと共有しようというものです。

誠実であること

2006年9月6日、エクストリーム・プログラミング(以下、XP)の父、ケント・ベック氏の来日記念セミナーが開催されました。 氏の講演にはよい話がたくさんありましたが、随所で繰り返されていたのが

「誠実であること」

でした。 これはXPに限らず、業界全体に言えることなのではないかと思います。 岡島幸男さんの著書『現場リーダーの「技術」』にもありますが、

「正直は割に合う」

のです。

中でも筆者がエンジニアの皆さんにまず最初に心に留めてほしいのは「自己評価」に関してです。 自己評価に関して誠実であることとは、つまり

「過大評価も過小評価もしないこと」

です。 出来ないことを出来ると言ったり、出来ることをできないと報告し続けることは、 実務の面ではチーム全体に、個人レベルでは精神的にコストがかかる為、長くは続けられないのです。

前述したように筆者は高次脳にダメージがほぼ無かった為、エンジニアの仕事で必要になる思考活動に支障はありません。 一方、やはり多少の後遺症の為に負荷を軽減してもらったり、他の人にお願いしている事柄もあります。 ただし、それをエクスキューズにしないことだけは心がけています。

さて、一時的に無理をして仕事を進めても、それが持続可能でないことはよく理解できると思います。 では、過小評価がやはり持続可能ではないとはどういうことでしょうか。 筆者はプロジェクトを成功させる為にはメンバー同士の信頼関係が重要と考えていますが、 この信頼の中には「他のメンバーがベストを尽くしていることを疑わない態度」が含まれていると思います。 そしてそれは、他ならぬ自分がベストを尽くす必要があるということです。

メンバー全員が自己評価に対してまずは誠実であってほしい理由がおわかりいただけたでしょうか。

トラックナンバー

筆者は入院時、救急車で運ばれてそのまま入院となりました。 プロジェクトから見れば、ある日突然それも佳境期に、なんの引き継ぎ作業もなくメンバーが1人居なくなったことになります。 当時のプロジェクトではリードエンジニアを自認していたのですが、まさにトラックナンバー(コラム参照)を身をもって計測することになったのです。 結論から言うと、プロジェクトのトラックナンバーは少なくとも1より大きいことが証明されました。 すなわちほぼ予定通りのQCD(Quality, Cost, Derivery)でリリースされました。

さて、では何故そのように出来たのでしょうか。 筆者が感じている中で大きいと思う理由を3つを挙げてみます。

  • もともと手離れの良い状態になっていた
  • 筆者に代わって開発をリードしてくれるメンバーが居た
  • 筆者の代わりに加わったメンバーが大いに貢献してくれた

お気づきの通り、3つのうち2つはメンバーに関するものになっています。

多少ラディカルに書くのならば、プロジェクトにおいて「人は交換可能」です。 このように書くと、「人員は組織の歯車」「代替可能な部品」「単純な人月計算で割り出される」という話が頭をかすめるかもしれませんが、筆者が主張したいのはまったく逆のことです。

これは職場に復帰してしばらくしてから聞いた話です。 筆者の代わりにプロジェクトに入ってくれた Sさんや Mさんは、最初に打診があった時には断ったそうです。 しかし、理由が筆者の入院にあると聞き、その穴を埋めるということならば協力したい、とマネージャに言ってジョインしてくれたそうです。

そう、筆者の言う

「人交換可能」

とは

「あの人の穴なら私が埋めてもいい」

と思われるような土壌があってはじめて成り立つものなのです。 そしてメンバーの自律的な動きを信頼すればこそ、「人交換可能」と敢えて言います。

もちろん個々人にはその人の持ち味とでも言うべきものがあり、そこの部分は代替不可能で、だからこそ部品ではないのですが、それを解決するのはプロジェクトの中に(場合によっては外にも)多様性をどれだけ仕込めるかにかかっているというのが最近の筆者の考えです。 多様性については、機会があればどこかであらためて考えをまとめたいと思いますので、またお目にかかることがあるかもしれません。

「誰と」重要

言うまでもなく、私たちの目的は「価値のあるソフトウェアを作り、提供し続ける」ことです。皆さんも、そのためには良いメンバーを確保したり、良い仕組み(プロセス)を採用したり、良いツールを使ったりと、いろいろな方法を模索していることでしょう。この雑誌を手にしていること自体、その模索の一環なのではないでしょうか。

しかしプロジェクトは開発者・マネージャー・顧客といった複数の人間が関与して進められて行く以上、「誰と」一緒に仕事をしているかがキーであり、モチベーションに直結する問題になります。ここで言うモチベーションとは、良いものを作りたい、そして、良い作り方をしたい、両方の想いに対するものです。

ここまで、誠実であることや人交換可能とはどういうことなのかを書いてきましたが、それらも踏まえて、次のような質問をさせてください。

  • あの人と一緒に働きたいと思う人がいますか?
  • そう思える人と一緒に仕事ができていますか?
  • 自分もそう思われていますか?

プロジェクトの成功にとって、「銀の弾丸はない」ことはよく言われることです。 裏を返せば、プロジェクトの成功には必ず泥臭い実践の数々があるわけです。 泥臭い実践を一緒に行っていくには、先ほど挙げた質問に「はい」と答えられる環境にいた方がやっていきやすいと思いませんか? いいものが作れそうな気がしませんか?

筆者が入院時にやっていたプロジェクトのメンバーとは、現在は直接は同じ仕事をしていません。 けれど、お互いに信頼があると感じますし、なによりまた一緒に仕事をしてみたいと強く感じます。 一緒に仕事をしたら、よい成果を残せるという確信があります。

もし、ここまで本稿を読んで少しでも共感していただけたのなら、そして今いるプロジェクトをもっと良くしたいと思っているのなら、まず皆さん自身が主体となって動いてみることをおすすめします。

どう動いたらいいか

けれども、どう動いてよいかわからないという人もいるでしょう。 身構える必要はありません。 一緒に働きたいと思える人を見つけよう、まずはそう心がけながら仕事をするだけでも、随分違ってくると思うのです。

そして次に、他の人に対して何かアクションをとりたいけれど、きっかけが欲しい方へ。 そんな方にはひとつの切り口として、平鍋健児さんが提唱している「プロジェクトファシリテーション(PF)」という言葉を紹介します。 まずはこの言葉をネットで自分なりに調べてみて下さい。(その他、もちろん筆者にメールをいただくのでも構いません) あなたが動き出す為のヒントが、きっところがっていると思います。


本稿では、筆者にとっての Extreme Experience から得た気づきを元に話を進めました。 この気づきを与えてくれた、まわりの友人・同僚・そして家族に感謝します。 皆さんも健康にはくれぐれも気を付けて!

コラム:トラックナンバーとハネムーンナンバー

トラックナンバーとは「プロジェクト・メンバーのうち、トラックに轢かれたらプロジェクトの継続がままならなくなる人数」のことです。 例えば、キーメンバーが一人欠けただけでプロジェクト遂行が困難になるような状態は「トラックナンバー=1」で、つまり最悪のケースとなります。 プロジェクトの中に、トラックナンバーが自然と大きくなるような仕組みを入れておくのが、リスク軽減につながります。 換言するなら、本文にも書いた通り、手離れの良い状態を保つ仕組みです。 XPのプラクティス「ペア・プログラミング」などはその最たるものと言って良いでしょう。 実際、筆者が入院時に関わっていたプロジェクトは XPスタイルで行っており、筆者が突然抜けてもプロジェクトが成功と言える終わり方をした一因にもなっていると信じています。

なお、プロジェクトにとってはトラックナンバーは大きいほど好ましいのですが、「トラックに敷かれてもいい人が多いほど良い」というのは直感的に嬉しいことではありません。 そこで、水越明哉氏が提唱しているのが「ハネムーンナンバー」です。ハネムーンナンバーの詳しい計算方法や、その背景にある考え方の楽しい解説を氏のサイトで読むことができます。

ツッコミ

shizu あまにょくん、元気ですか?コメント書こうか迷ったのですが、書いておきます。
私も、去年の9月から、4ヶ月間自宅療養し、2ヶ月間リハビリ出勤し、3月から1日8時間以内の勤務という制限付きで、復帰してます。(このコメントを読むのがあまにょくんのみであれば、もっとこまかいことも書くのですが、わからないのでこれくらいにしておきます)
9月には、4つくらいのプロジェクトのまとめ役というか、交渉役をしていたのですが、上司が全部ほかの人に振ってくれました。振られた人が、どういう気持ちだったかまでは、わかりません。「あの人の穴なら私が埋めてもいい」とまで思ってくれたかどうかはわかりません。でも、「倒れちゃったんなら仕方ないですね、やります」みたいな感じだったんだろうと想像します。
やはり、私のみに依存する事項が少なかったために、うまくいったのだと思います。
その辺が、トラックナンバーorハネムーンナンバーが大きかった、ということなのですよね。

「ただし、それをエクスキューズにしないことだけは心がけています。」
というのは、よくわかります。
私は子供のころから色々病気をしていたので、病気を理由にいろいろなことから逃げていました。
それじゃダメだって気がついたのは、大人になってからですけどね。
逃げちゃダメだけど、無理もしてはいけない。難しいですね。

多分、私もあまにょくんも、再発の可能性のある病気をしたのだと思います。
なので、これからの仕事の仕方も、健康管理も、注意深くなりますね。
お互い健康には気をつけて、やっていきましょう。 (2007/07/05 11:21:16)

shizu コメントがかかれていなかったのは、まだ誰も書いてなかっただけだったんですね。
思いっきりアドレス書いちまった(笑)まあいいや。 (2007/07/05 11:29:08)

あまにょ shizuさん、コメントありがとうございます!そしてお久しぶりです(^^
#メールアドレスは修正しておきました(^^;

B社のどなたかが社内で宣伝して下さったのでしょうか。ともあれ嬉しいです。
また、おかげさまで、今は体の調子もよく、どうにかフルタイムで働いております。

shizuさんも、大変な経験をなさったようで、いつかお会いする機会をつくって話せるといいですね。
私もまだまだ未熟で、一緒に働きたいと思われるように日々精進の毎日です。
逆に「一緒に働きたい!」「ペア・プログラミングしたい!」と思える人はどんどん増えていきます。

体調に気をつけつつ、名指しで指名されるようなヒトになれるよう動いていきたく思っています。
もちろん shizuさんも無理せず、そして活躍されることをお祈りしてます(^^
せっかくなので、これからもよろしくお願いします! (2007/07/05 13:23:06)