ウィリアムのいたずらの場合、現在は、最底辺の人間だし、以前も、管理する側にいたことはあるものの、上の人たちとは、立場がちがうわけです。
そういう人間が、この業界の上の人たちのブログをみると、下の世界のわたくしとは、まったく違う考え方をしているので、面白く感じることがあります。
（なーんてかくと、けんか売ってるように読めるかもしんないけど、そんな意図は、まったくないっす。本当に面白く感じた。。）
最近、スケジュールを分刻みにするかどうかという話がでてますね。
これ、下の人間は、開発規模うんぬんでなく、納期前かどうか（＝開発段階）できまります。
開発段階で、流れる時間（単位、ペースメーカー）を意識的に変えます。
ただし、「大きいシステムは、納期前、分単位で管理せざる終えない」という理由を説明するのはやさしいですね。
具体的にいうと、大きいシステムでは、ＣＶＳでは管理できず、make(antでもいいけど）でビルトして管理します。
この理由は、だれだったかの日記に、「セキュリティに問題なければ、バージョン管理サーバーは、見えるところに置くべし」みたいなことが書いてあったけど、そのとおりで、ＣＶＳみたいなサーバーは、みんなが見えるところにないと、更新に矛盾がでるので、意味ない。でも、セキュリティ上、そんなことは、大手でゆるされるわけもなく。。。っていうのが１つ
あと、勝手に更新されると、リグレッションテスト（回帰テスト）をやるタイミングは、どーするの？という問題が１つ。
あと、これはちょっと説明すると長くなるので、今回は省略するけど、もう１つ理由があります（ＩＴ２の場合、ＰＴとＩＴ１を行わないといけないところからくる制約）。
もちろんＣＶＳに詳しい人からすると、反論はあるんだろうけど、現実的には、構成管理の係の人がいて、makeでビルトし、変更したいモジュールがある場合は、構成管理の係に、申請書を出すという形になっているのが現実な気がします。
このような場合、納期前に、バグ修正を行うと、プロジェクトマネージャーは、分単位で管理せざる終えません。その理由を、具体的なお仕事内容をしめして、説明します。
まず、ビルトは、ふつう１日２回以上走ります（朝皆がくる前に走らせ、その後、テストする。１日の定時の終わりにもう一度走らせる。もし、そのとき、おかしかったら、一晩かけて直すみたいなノリ）。
多いときは、１日４回から、最高６回くらい（これ以上になると、事実上、不定期になる）。
６回だと、（２４時間開発しているので）１回のビルト感覚は４時間になります（これが限界だと感じている）。
さて、次の構成管理に、バグ修正したいものを載せたい場合の手順は、一般に以下のとおりです。
■■ プログラマ
・プログラムソースを修正し
・コンパイルをして
・単体テストＯＫとなっているとして
（１）最後のビルトで出来たもので確認する
（２）マネージャーにわたす
（３）（マネージャーがやらない場合）申請書を書く
■■ マネージャー
（１）プログラマの（２）の物を受け取る
（２）ＩＴ１を行うため、関連するプログラムのマネージャーに配布
（３）（２）の結果を関連するマネージャーから受ける
（４）更新すると決定したら、申請用紙を記入
→プログラマがやる場合や、あらかじめ書いておく場合あり
（５）構成管理に申請
プログラマの（１）、マネージャーの（２）、（３）、（４）、（５）の順に流れます。ステップが５つで４時間（＝２４０分）なので、１工程４８分ということになります。
でも、これを１工程４８分でできるか？と監視すると、そうはいかないわけで、（２）から（３）の工程に、かなりの時間がかかり、（４）、（５）の工程は、分単位で管理する形になりますね。
実際には、（３）のうける報告が、何時何分までに報告がこなかったら、次のビルトに載せるのは見送ると、分単位で、自分の心の中では決めています（株でいう損切りラインに相当します）。
つまり、（４）、（５）をあわせて１０分として、３時にビルトなら、２時５０分に報告を受けるのがデット、なので、２時４０分までに回答が無ければ、こちらから確認、２時４５分には回答の有無にかかわらず、終わらなかったらつぎまわし。
こんなかんじで、納期前は、分きざみで管理です。
ただ、こんな状況は、３ヶ月も続かない。。。よねえ（＾＾；）
逆に、大きいプロジェクトはもちろん、小さいプロジェクトでも、開発初期は、相手の（とくに偉い人の）打ち合わせが取れる時間に、開発が左右されます。
なので、下の人間は、細かい時間管理は難しいですね。
もちろん、この場合でも、個人としては、別に細かい時間で計画していっていただいてもいいわけなんですけどね。
なんで、偉い人の場合は、時間の計画レベルを、開発規模なんかで、分にしたり、時間にしたりするかもしれないんですが（個人に流れる時間を開発管理時間とし、まわりに、「それにあわせろ」といえるから）、下の人間の場合は、開発に流れる時間（基準となる時間、ペースメーカーとなる時間）の単位を、開発の場面、人によって変えます。
場面によってかえるのは、上記のとおりなのですが、人によっても、おおきく変えますね。
細かい時間単位に指示しないと、指示まちになるやつとか、
１日単位に指示しないとやる気を損ねるやつとか、
そもそも、分単位に、契約上、縛れない場合もあるわけで（お持ち帰りの請負仕事。法律上は当然しばってはいけないし（情報処理試験のお勉強で出てくるとおり）のこと、実質、縛れない）。
ただ、基本的には、どこの会社も、ＰＤＳまたはＰＤＣＡのしくみによる、スパイラルの管理をするわけで、この場合、暴走させないためには、個人計画をチェックする仕組みが必要になってきます。そのため、そのチェック機能であるＳないしＣの部分を決定すると、それに対して、Ｐ（計画），Ｄ（行動＝開発作業）のタイミングがきまってくるわけで、その範囲で、計画を立ててくれれば、いいようにします。
スクラムの場合、デイリースクラムによって、Ｃを確認（＝成果チェック）することになりますから（くわしくはここ)開発管理時間は、１日単位で、それにあわせて計画（Ｐ）をつくり、作業（Ｄ）してもらうことになります。
その間の個人的な作業時間に関しては、自分の中に流れる時間に、基本的にはまかせます。
（新人の場合や、自分のなかに流れる時間が極端に違うやつ、うつ病っぽい人の場合は、管理方法がちがう。スクラムは、うつ病患者対策を教えてくれてはいない。うつ病の人にスクラムの価値基準である「専念」を強要すると、悪化するよね！）
で、現場では、構成管理と、朝会、夕会、昼会などの状況確認が、開発管理時間になります。
（そうしないと、報告するネタがなくなるので、そうせざる終えない。。）
そのため、１日よりも、短い時間（たいてい４時間くらい）で、Ｐ（自分の計画）を作ってもらわないと、マネージャーは、毎日朝会でＰＤＣＡが回ってないとおこられないといけなくなるので、
「強制です。自分の人間性うんぬんにかんけいなく、４時間単位で、計画をたてて、それにもとづき粛々と作業をすすめてくださいね！」
なんてことは、まちがっても、メンバーにいえないので、ここも、うまい管理法があって（今度紹介するかも、面白い話があるんで）それをつかって管理します。
そして、スクラムより、短い時間で管理することとなるので、スクラムでいう、スクラムマスター（現場的には、チームリーダーがこれにあたる）の役割が重要になります。
。。。なんで？って、疑問に持っちゃうよねえ。。
説明すると長いんだな、これが。。なんで、今日は、もう帰りたいから省略ぴょ！
ではでは
アクセス
トータル
ランキング
