いろんな作業をする中で一番重要なのは準備。
なんでも準備がきっちり出来れば、
ある程度、できたも同然。
失敗する場合、だいたい準備がうまく
行ってないことが多い。
準備に必要なのが、前提知識。
前提知識が無いまま、準備を怠ると、
途中で絶対詰まる。
ぼくの場合、自分で見積した案件は、
あまり失敗した記憶が無い。
見積をするということはどういうことか
というと、システムの全容を把握して、
機能分解、それに必要な技術要素を洗い出す。
技術調査が必要なモノは、事前に技術調査。
この段階では、実装レベルの調査は不要。
お客さんが求めていることができるか
どうかのレベルでいい。
※ここでたまに、完全に把握しないと
気が済まない人もいるけど、それは
見積提示までにとても時間がかかる。
あくまで、「できる！」ということ
だけ把握出来ればいいのだ。
⇒その裏付資料は後で必要になるけどね。
その後、各工程で発生する作業を洗い出していく。
要求される機能の説明が足りなければ
お客さんに確認したりすることも有る。
その後で、機能ごとにどれくらいの時間で
プログラムができるかを考える。
自分の手持ちリソースでは、こういった
機能なら、どれくらいかかるか？という
ことを考えていく。
ある機能は、5日ぐらいで、作れそうだと、
思ったら、その日数を入れる。
※時間数の場合もあるし、月数の場合もあるけど。
で、その機能を設計するための日数はどれくらい
かかるか、テストにどれくらいかかるかを考える。
また、機能設計する前に、システム全体の
基本的な設計が必要となるので、それも
考えていく。
また、機能ごとのテストが終わった後に、
結合テスト、システムテストも実施する
ので、その日数も考える。
その後は、前提条件を考える。
例えば、PCがいつまでに用意できないと
いけないとか、プログラムに必要なソフト
ウェアを貸してもらわないと開発できない
とかいう制約条件のことよ。
大体これは、全体の大枠のスケジュールを
作成するときに、このタイミングで、何が
必要かを考えたり、作業場所はどこで実施
するか考えるときに、条件が出てくること
が多い。
こういったことを実施しながら見積を作る。
つまり、全体を俯瞰して何が起こるか事前に
考えることができるため、すでに準備が終わって
いるようなもんだ。
また、事前に前提知識も頭に入っているので、
途中で、その前提が変わった場合、仕切り直し
をお客さんに要求することができる。
なので、見積もった人間がシステム開発まで実施
する場合、あまり失敗しないと思う。
※失敗するのは、あまりきっちり内容把握
できないまま、見積もってしまった場合。
その場合は、想定したよりも、各フェーズで
時間がかかって、スケジュール遅延したり、
赤字になったりすることが多い。
話は変わって、ぼくが失敗するパターンは、
人が見積もったシステムの構築の場合や、
常駐して作業する場合が、多かった。
人が見積もった場合、前提条件が頭に入って
いないので、前提とちょっと違った場合の対応
が出来ないことが有る。
ま、その場合でも、徹夜してでも何とか
してきたけど・・・。
※一緒に作業してる人たちは辛いよねぇ。
常駐して作業する場合、ちょっと状況が変わる。
ぼくはどちらかと言えば、イケイケのSE。
それが常駐するとどういうことが起こるか？
言われたことは全部知ってるから、
「できますよ！」
状態で作業範囲がどんどん拡大していって、
作業量が半端無くなることがある。
昔そうなった時が有る。
その時は、あるSierに常駐して、お客さんの
SEと一緒に設計して、開発はぼくの会社から
協力会社に外注してプログラム開発した。
SierのSEは、基本設計だけ実施して、後は、
ぼくに丸投げ・・・。
開発規模は、VBのプログラム60本ぐらい。
そのうち40本は、事情が有って一ヶ月後に
使いたいとのこと・・・。
まだ、詳細設計ができてないのにね。
お客さんのSEもさすがに無理と思ってたようで、
「お願い！なんとか間に合わせて！」・・・。
当時、まだ30ぐらいで、体力に自信もあった
ので、やりましたよ。
協力会社に話をして、発注の3日後から詳細設計
を五月雨式に出すから、なんとか1ヶ月で40本
作って欲しいという話をした。
ちょっと渋ったけど、なんとかOKとのこと。
5人アサインして開発してくれることになった。
そこからはちょっとひどかった。
そんなに難しいプログラムはなかったのだけど、
最初は3日後に5本の仕様書を書かなければ
いけない状況。
だって、5人が待ってるんだもん。
その日は、そのSierの事務所に帰って、徹夜。
2本の仕様書を作成して、メール。
翌々日も徹夜して、残りの3本を上げた。
その足で、協力会社に行って、内容説明
して、作り始めてもらった。
残り35本の仕様書を10日ぐらいで必死に
上げた。
仕様書を作成しながら、続々と完成してくる
プログラムをもらって、その受け入れテスト。
それがまた、ひどい出来で、起動した瞬間に
プログラムが落ちたり、もっとひどいのは、
コンパイルも出来なかったりした。
しょうがないから、メインプログラマーを
呼びつけて、目の前で、コンパイルエラーを
潰してもらった。
ぼくはその頃、VBなんて全くわからない人
だったのだけど、さすがに、間に合わないと
しょうがないから、後ろで必死に見てたら
だんだんわかるようになった。
その後は、エラーが発生しても、ソースを確認
して、わかるものは、ぼくの方で修正して
メインプログラマーにソース送って最終確認
させたりした。
結果的には2日遅れの納品だった。
辛かった・・・。
さっきの協力会社のメインプログラマーだけど
結構頑張ってくれた。
最終週は、何日か徹夜してプログラム受け入れ
して、3時ぐらいに障害レポートメール送った。
彼からは、その30分後に修正モジュールが
来たりした。
よく頑張ってくれて嬉しかったから終わった
後に、二人で飲みに行った。
実は結構老け顔だったのだけど、
3年目になったばかり。
5人体制ってのは最初だけで、最後の1週間は、
その子だけで頑張ってくれたみたい。
お互いよく頑張ったと、褒め合った。
そういったこともあった。
ま、最後のエピソードは、準備と全く関係
なかったけど、準備は重要よね。
今、やってる作業も、常駐作業だけど、
まだ、準備段階。
前提知識を頭に入れてる状態。
もうすぐ、実際に作業になるので、きっちり準備
してから作業したいと思う。