システム開発において心がけてること - takeborutaのブログ
平凡な俺のようなものでも、事前に準備すればそれなりな システム開発ができるかもしれないのでいつも心がけていること を書き出してみた。 課題管理、スケジュール管理、体制、設計、開発など 課題管理がなされているか？５W１Hが管理されているか スケジュールが管理されているか、 見積もりの精度は十分か。タスクの粒度は都度できる限りに、細かくする プロジェクトのコミュニケーションルートが確立されているか メンバーが誰に聞けば問題や課題が解決するか把握できているか 開発体制が確立されているか 言った言わない、聞いてないとかって問題が出たときに、都度根本的に解決しようとしているか タスク管理redmineなどのツールを使っているか。管理工数を極力減らす努力がされているか。管理はツールができる 話合いが多すぎるのは、良くない。開発が安定してるときは、無駄なコミュニケーションは少ない事が多い。 新しいツール
SI案件で要件がはっきりしない時 - takeborutaのブログ
SI開発でよく起きる問題の１つ。エンドユーザーのシステム要件がなかなか決まらないというのが たびたび問題になる。 決まらないと、スケジュールを圧迫したり、開発工数を圧迫したりなどで、 スケジュールが遅延したりなどがたびたび起きて、開発者にとっては厳しい状況になりがち。 業界の慢性的な病気とも言えるかもしれない。 パターンを分類してみた エンドユーザー側の決定が遅れがち、大事なことを決断する力が弱い この場合は、PMや営業を通じて仕様決定者間で解決できない場合は、 会社同士のもっと上のレイヤーをうまく使う。現場でMTGしてる人がどうこうしようとしてるので、あまりうまく いってるのを見たことがないし。うまく行くなら、もっと前にうまくいっているような気がする。 開発側、請け負ってる側に要求管理する力が弱い この場合は、開発側にうすうすまずいと思ってるメンバーがいる場合は、気がついたメンバーが動く
求められるスキルを考えてみる - takeborutaのブログ
OJTとかを最近やっているので これぐらいあった方がいいっていうスキルポイントを書いてみる システム開発に限らないのかもしれないけど 最低限のレベル タスクを完了することができる。コーディングだったり、Doc作成だったり 業務を完遂するために必要な仕事上のコミュニケーションができる。 タスクの内容を十分理解していて、どこまでやれば終わりか分かっている。分からない部分は誰に聞けばいいか分かっている 求めるレベル 開発環境を自分で構築できる。環境構築の際の手順書とかトラブルシューティング対応とかもできるともっといい 次案件からは、これを使った方がいいなど提案とかする。改善する視点を持っている 仕事を自ら定義することができるし、ゴールも理解している チームで仕事をするやり方を心得ている スターがいない状況でも成果を出すことができる 常に必要とされるレベル スターではないことを十分理解していて、ス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
