■
スケジュールを引くにあたって、気をつけることがある。
仕様が確定していない機能をある程度作成している場合、
新たに決まった仕様はどの程度のものであるか？
SE:( ´∀｀)ノ＜新しく決まったから今までの納期内でやってね〜
っと言いたくなるのが仕様提示側だが、そのとおりにやっちゃってはいないだろうか。
やっていたら、そのプログラムはいつまでたっても終わらない可能性に包まれることになる。
どれだけ作っても「仕様が未確定」というステータスが取れないのであれば、
どれほど実装しても「完了」になりはしない。
ということは、確定した仕様が従来の延長線にある事柄か、
実は仕様変更となるべき事柄なのか、仕様追加であるべき事柄なのかの区別がつけにくくなる。
客：( ´∀｀)ノ＜いや〜。実はこ〜だったんですよね〜
この言葉にいつまでつきあうのかが問題となるのだ。
こちらとしても、未確定部分があると思っていれば、なかなか断れるきもちになれない。
延長線か、仕様変更になるかをビシっと言い切れない思いに捕らわれるのもさることながら、
(´-`).。oO(このくらいならやってもいいかな・・・・)
っと実装してあげたいきもちがでてくるからである。
ずるずると行ってしまうが、いいことなどない。
ゼニを出してくれるならともかく、
そうでないのにいつまでも時間を取られるわけにはいかんのである。
プログラムはいつまでたっても「完成」しないのである。
ではどうすればよいのか？
確定した仕様をスケジュール上、新たな項目として新設するのである。
この機能はいつまでに実装する。実装しきった結果、約n％の進捗がはかどると。
そんな管理をお勧めする。
毎回提示された仕様をプログラム化したらそこで一応作業完了とする。
100%にならない仕様が提示されればそれは追加か変更として扱えるようになるのだ。
おいらの嫌いな人日単価の話ではこんな言い方ができるだろう。
前提状況はこんな感じとしてみよう。
作業項目：なんたら画面作成
予定工数：5人日
現在進捗率：80%
＜1回目＞
お客：(,,゜Д゜)＜こんなことが出来ないとわが社の用件は満たせないのでつくってくれたまい。
おれ：( ´∀｀)＜提示されました仕様を実装するのに2人日くらいかかりますが、それでこの作業項目は完了となりますか？
お客：(,,゜Д゜)＜ん〜それでいいとおもうよ。
おれ：( ´∀｀)＜おげ。
これで終わることはまずない。
＜2回目＞
お客：(,,゜Д゜)＜やっぱりあんな機能も必要だった。つくってくれたまい。
おれ：( ´∀｀)＜前回完了言われましたやん。とりあえず、作業項目として進捗率100%を越えるので予算とスケジュールをください。
お客：(,,゜Д゜)＜え〜。なんとかしてよぅ。
おれ：( ´∀｀)＜ほな他の機能の余剰分があればそれを割り当てさせていただきます。
が、それでも無理そうであれば〜〜よろしくお願いしますね。
うまくいこうがいくまいが、こんな言葉を投げかけておくのが要である。
自分の言った言葉に対してこちらの作業状況がどうかわるかを提示しつづけていれば、
予算と機能は自ずと考えるようになるものだ。
それでも、機能が足らずに次の回にお願いすることになることがあるのだが・・・ヽ(´ー`)ノ
作業項目：なんたら画面作成
予定工数：5人日 →余り1人日
作業進捗率：100%
全体進捗率：80%追加機能：2人日 →余り-1人日
作業進捗率：100%
全体進捗率：100%？
＜3回目＞
お客：(;゜Д゜)＜あの〜。やっぱりこんな機能も必要だったのですが〜、作って？
おれ：( ´∀｀)＜予算がありまてん。もうむりぽ
お客：(；゜Д゜)＜そこをなんとかお願いできませんかねぇ。
おれ：( ´∀｀)＜現在こんなスケジュールで進んでいます。んでこれはもう100%となってます。
以降は仕様変更扱いしていただかねば予算がありません。
ぶっちゃけ予算とスケジュールをいだだければいつまでも作りましょうとも。
お客：(；゜Д゜)＜う・・・・・・考えます。
っとことがうまく運ぶようになる可能性は高くなると思われる。
ここにいたって、上記のように区切りをつけない方法での進捗はどうなるか？
作業項目：なんたら画面作成
予定工数：5人日
現在進捗率：95%
きっとこんな感じになるのではなかろうか。
100%でなく、それでいて
ヽ(`Д´)ノ＜あとの5%ってなんやねん！！
って個所付き。すでに予定工数はオーバー。でもいつまでも95%。
ちょっと状況やばいぞって空気はわかれども、
営業的にはなんだかものが言いにくいふんいき。
そしてずるずるといき、納期が迫ったときにこっちのモノが出来ていない状態。
出来ていない理由は先方にあるにしろ、「出来ていない」というステータスがこっちにあるがために、
こっちのせいにされたりする。*1
スケジュール調整役のそんな状況だけで話は終わらない。
プログラマ的にはどうなるのか？
プログラムはどんな形になっていくのか？
まずは進捗率がいつまでも95%のほうから。
何回も仕様が変わると、前回との矛盾点や不整合が必ず起こってくる。
プログラムの流れ上、どーしても作りなおさなきゃいけない状況が出てくる。
そんな時に、また変わるかもしれない仕様のためにわざわざ作り直すだろうか？
いいや、そんなはずはない。
現状のプログラムになるべく手をつけずに、今回の仕様との調整をするだろう。
つぎはぎで何とかするという手法をとる。
悪い意味でのパッチプログラムが出来上がることになる。
次回、また次回と変更追加が繰り返されれば繰り返されるほど
つぎはぎが多くなり、一貫した流れが消えていく。
不思議なロジックが増えていく。
前提としては、変更が入ったときに全体の見直しを行わないことが要因となっているのだ。
簡単にまとめると以下のようになる。
仕様が変わる
→ またどーせ変わるんだから今きっちり作ってもしゃーないやん
→ とりあえず今は今の対処しちゃえ
→ あとのことはまた次回〜ヽ(´ー`)ノ
この論法でいくと、まとまりが無くなる。
完成の日がきたときには、クサレソースになっていることが予想される。
少なくとも洗練されたシンプルで美しいプログラムであることはま〜無いだろう。
続いて区切り区切りをきっちりつけていく方式の場合
何回も仕様が変わる。
が、その都度スケジュールが引きなおされて目標が明確になる。
いついつまでにこれだけ完成させればバッチリという状況。
前回との矛盾点も不都合も「今」直さねば後が無いかもしれない状況。
こうなると、直さなしゃーないってな気持ちも芽生えてくる。
気持ちが芽生えればモチベーションがあがるため修正作業がやりやすくなる。
ゆえに修正作業をやる。
対処もきっちりした形で作られやすい環境になる。
モチベーション次第で生産性が明らかに違うプログラミングという作業において、これは大きい。
簡単にまとめると以下のようになる。
仕様が変わる
→ またどーせ変わるにしろ、今きっちり作らなしゃーない
→ がんばる
→ 今回の分きっちり完成っ
→ 後はなんぼでもこんかい(゜Д゜)!!
なんとなく後回しってのが無いだけに、遅れは遅れとして明確にあげられる。
このためウソもごまかしもきかないのだ。
なればこそ、気持ちよく目標に向かっていける。
スケジュールがあいまいなままだとスケジュール管理者がサボっていると感じられるもの。
管理者がサボっているのにわしらだけ忙しいってのはおかしいと思うもの。
そうなるとわしらも手を抜きたくなるのは必然となっていくのだ。
手を抜くと品質は必ず落ちる。
そうではなく、管理者がきっちり管理者の仕事をしていると感じれば
それに答えたくなるのが心意気。
手を抜くことは粋に背く事になるのだ。かなり気持ちよくない。
品質を保ったうえで納期も守る。結構気持ちよい。
この気持ちよさを味わわんがためにいろいろやる。試してみる。
そして最高効率を追い求めるのだ。( ´∀｀)
仕様追加変更時。
プログラムを見直し、再実装も辞さない気持ちであるべき姿を考えること。
ビギナーはもとより、プログラム作りが楽しくなってきたころの若僧どもはこの作業ができない。
忙しかろうがそうでなかろうが、やらないから連日残業という
よりひどい目にあっているにもかかわらず。である。*2
あるべきものをあるべき姿に保っておく。
至極まっとうに聞こえるだろうが、おいらはこれを「楽するために」やっている。
作業項目という命題をクリアしつつ、納期という名の時間制約をクリアしつつ、
なおかつ「自分が楽をする」という重要項目を満たすにはそれが一番だ。
今のところはそれが一番だと思うようになった。
