災害復興についてプログラマとして考えたこと-5

今日は プロジェクトの目標について、です。

  プロジェクトの目標は 「よいプログラムを作成する」こと ではありません。

もちろん良質であることに越したことはありません。しかしそこにプロジェクトの目標をおいてしまうと、究極的には

  「優秀なリーダーが、時間をたくさん使えば作ることが出来る」

訳ですから、リーダーが奔走してただそれだけで終わる。それでは意味が無い。

震災により受けたダメージは甚大です。数少ないリーダークラスの人間がすべての時間と才能を費やしたとしても、とてもカバーできる範囲ではありません。まさしく、猫の手も借りたい時です。僕のプログラマとしての腕はしょっぱいですが、猫の手ぐらいの価値はあるとおもうのです。
いまこそ、この猫の手を集め有効に使うべき時です !! でなければこの難局は乗りきれない。
だから僕のこの猫の手をリーダーたちにお貸しします。

ですから

  思う存分 肉球を楽しんでください !!
  さあ、プニプニしちゃってくださいw さあ !! さあ !!

… 若干の趣旨のズレを感じますが、長い人生脱線などよくあることです。

「あれ? 俺そもそも本線を走ったことあったっけ?」
と思わなくもないですが、気にしたら負けですw

話を戻しまして、もしリーダークラスの知恵をつかって、「猫の手活用法」を数多く生み出せれば、失ったものを速く取り戻せるようになるだろうし、そこからまた新たに生み出せるものも多く出てくるようになるはず。

だから、リーダークラスの労力をそういう方向に導きたい。その為にどうしたら良いか?

僕なりに考えて導き出した一つの答えが

  「リーダーの持ち時間は 月4時間位に制約する」

事なんです。

これは負担の軽減という意味もありますが、それよりもむしろ制約を設けることでリーダー同士の競争の力点が

  「いかに手間をかけず、いかに短い時間でチームの成長力を引き出すか?」

というところに移るのではないか、と考えたからです。

  短い時間と言っても 早口で勝負 !! とかそういうことじゃないですよw

例えばサブリーダーの力量を測るためにどんな質問をするか? という場面を想定してください。
長く時間をかけて質問すれば大抵の人は力量を測ることが出来るでしょう。

  でも、一言だけで判断しろ、と言われたらどんな質問を選びますか?

難しい問い、ですよね。あの人ならどんな質問をするだろうか?
とか考えたら楽しくなりません?

時間制約があるがゆえに リーダー達は、極限にまで切り詰めて言葉選ぼうとするわけです。
その苦悩を経て生み出された、言葉、そしてその選んだ過程には、その人が苦労して得た珠玉のノウハウが詰まっていると思うんです。

  知りたくありませんか?

僕は知りたいです。

あえて、時間を短く設定することで、重要だけどあえて外すものが出てきます。そんな厳しい戦いのなか残ることができた、その人が「最重要視している濃厚なエッセンス」が4時間に詰まってくるわけです。興味深くありませんか?
そんなエッセンスを引き出す為の制約でもある訳です。

  しかし、プログラムが目的でないのなら何が最終目標なの?

そうなりますよね、当然の疑問です。
まあ、微妙に触れていますからだいたいは予測できていると思うのですが

  「日本全体のIT業界の底力の向上を目的とした一冊の本を創り上げること」

が最終目標になります。

IT業界というと幅が広すぎかもしれません。SI業界位が適正でしょうか。たぶん実践的プロマネ本になるんじゃないかと思っています。そういう本を 一チーム一冊作成する事が必須の目標。もちろん2冊でもOKですけど。
一チーム30人いるわけですから人数割りすると、300ページでも一人あたり10ページですから、大した負担ではないと思います。2冊義務化でも余裕かもしれません。

もちろんプログラム作成を軽視して良い、という話ではありません。集まる人数にもよるのですが、結構な数が集まったら重複した機能を別言語で実装する、とか同じ言語でも違うフレームワークでとか、そんなことになるとおもうのです。
必然的に取捨選択が起き、捨てるプログラムも出てくるわけです。

しかし、プログラム作成を最優先にすると、プロマネ周りが雑になるでしょうから、そんなことが起こるくらいならプログラム作成を雑にして、書籍のクオリティを上げたほうが全体として有益になるので、それを防ぐため「あえてプログラム軽視を許容する」という形にしたいと思っているわけです。

ではどんなふうに進めていけばよいか?

本作りを目標としているので、時間ベースの細かいログを各自が付けていくようにしたらよいと考えています。

例えば前述のサブリーダーの力量を測る為の質問時なら

  どんなことを期待してどんな質問したか、そして返答をどう解釈したか、
  その後その判断はあっていたか、間違っていたか

とかの予測、反応、経過を、その人からの視点で記録していく感じ。あとは

  どんなタイミングで、どんな本を勧めたのか? その反応は?
  どんなタイミングで、どんなミーティングをスケジュールしたか ?

とか、そんな感じの記録を、それぞれの立場の人が、それぞれの立場からの感情をそれぞれ記録するようにして、のちの分析の材料として活用する。この記録は後日お互いで付きあわせて議論してもいいし、公開しないで自己検証してもいい。

大切な事は

  「同じ期間、人数という条件で、どれだけたくさんのプラクティス、成長力を引き出せるか」

が、競いあうポイントだということ。
その目的さえ達成出来れば、実はなんだって構わないということ。
そこら辺を意識しうる行動をうながすなにか、でありさえすれば全ては推奨される。

そんなふうに進めていけば、良質の書籍ができるだろうし、良質の書籍が作れるチームなら、きっと作ったプログラムも良質になっているはずです。

そんなふうに考えています。

大体の説明はできたのですが、もうちょっとだけ小ネタがあるのでそこらへんは明日。