Loading...

社内システム開発日記:その23

前書き

お疲れ様です!
小手投げです。

昨日は誕生会が行われました。先月は9人だったのに今月は2人てのも偏りが激しいです。

今回は打ち合わせの様子です。

打ち合わせ

部:(大線表を見て)終わりが一月近く延びているのか。理由は
担:人事側のタスクが想定よりかなり多く、CASTに7割の時間をかける予定が現状2割程度しかかけられていない。
  そのため1.7人で見積もっていたところを1.2人として引き直した

部:それはトップダウンの考え方、何人いるからどれくらいの作業が出来そうという
  ボトムアップで考えたのか、それぞれの作業にかかる時間を合算して出してみたのか

担:していない
部:理由は
担:先述の通り時間が取れなくて

部:優先度として、スケジュール、検討、確認、作業の4つの順序がある
  そのスケジュールができていないので時間をとってやる必要がある
  フィジビリティを確認しながら細目が増えていくものだ

担:WBS程度の粒度で線表を作るという認識か
部:そう。そこまでブレークダウンできないなら確認するべき

部:昔からいる人には言ったけど、できることを確認せずにやっても評価しない
  できないのが普通、できなそうなことを確認せずにやってダメでしたが最悪
  チームでは私はこう思ってましたが一番困る。私で終わっているから
  ・経験があって類推できること
  ・経験がないが予測と能力でできそうなこと
  ・経験も予測もなくできなさそうなこと
  ・経験も予測もゴールもない、できないこと
  2個目3個目は思考やオペレーションを共有してやればできるようになる
  4個目はそもそもゴールがないのでそこから

部:リファクタリングに11日とってあるけど長いと思う。理由が知りたい
  ダメに見えるコードでも自分が直したイケてるコードよりは良いコード、なぜなら本番で動いた実績があるから
  リファクタリングは大体コーディングの1/4程度の時間
  関数に関する部分の修正として簡略化で半分、共有化で半分、合わせて1/4
  もちろんダメなコード、変数等直すならもっとかかるが
  なんとなくで置くのが良くない

部:フレームワークの目的は調べた?
小:目的は調べていないが特徴として早さをアピールしている
部:早さいるか?他のフレームワークは無かったか
小:活発な開発をしているのが他にあまり見当たらないのと、おすすめされたので…
部:おすすめならそれで良い

後書き

スケジュールを引くのはこんなに難しいんですね。

ダメなコードでも動いた実績があるというのは納得させられました。
修正していて動かなくなることは結構あったので。

ではまた次回。

情報戦略テクノロジー