SI業界叩く前に発注者のRFPを見直せ！ - SIer関連メモ書き
先日、RFP(提案依頼書)をいただいた。 この内容があまりに酷かったので、ダメな点をメモしておく。 SI出身者が社内SEになって、初めて書きました的なクオリティーだった。 SIerを否定する声は多いけど、こんな酷いRFPしか書けない発注元から正した方が良い。 守秘義務があるので内容には一切触れないし、作りたいシステムの中身はこのエントリーの主題とは関係ない。 何がダメなのか？だけを書いていく。 目的に数値がない RFPを書く人にKPIという言葉を知らない人が多い。 どんな数字を達成したいか、明記すべきだろう。 例えば既存社内システムからのリプレースなら、オペレーションの改善時間などは、当然書かれるべきだ。 それらの数字からROIが出せて、提案する側も予算感が見える。 曖昧な表現が多い 使いやすい、容易な入力、視認性が良い、ストレスなく動作する、etc といった曖昧な表現が多い。 そのように
PG・SEからPMへなるための5つの心得 - SIer関連メモ書き
最近、PG・SEからPM(プロジェクト・マネージャ)に変わるタイミングを迎えてる人に、意見を言う機会が増えたので、どうせならブログに書いておきます。 PMは忙しいから、手短に5つにまとめました。 1.プロジェクト管理の書籍を読んで実践する まずは、正しい知識をいれましょう。 最初にこれをやらない人が、多いことに毎回驚きます。 自分の知識だけで、なんとかなると思ってるんですかね？ また、運営してて困った事があったら、改めて読み返しましょう。 知識を入れて実践しつつ、自分なりに身に付けよう。 2.管理作業をメインにする 下に5人のメンバーがいたら、PM一人が頑張るより、5人を正しい方向に誘導した方が良い。 自分がプログラムを組んだ方が早いと言ってはダメ。 3.とは言え自分もやる メンバーにだけ作業をやらせて、自分は何もやらなくて良い訳ではないです。 むしろ、面倒な雑務、一番難しいところを、しっ
アジャイルさておき、システム開発で大失敗しない方法 - SIer関連メモ書き
下のエントリーがバズってたので、勢いで「システム開発で大失敗しない方法」を書いてみる。 成功する方法じゃなく、失敗しない方法でもなく、あくまで「大失敗」しない方法についてである。 ledsun.hatenablog.com 結論から書くと「まずは少額でシステムのコア機能の検証をやろう！」である。 この話は、色んな人が何度も話してたり、書いてたりするが、全然浸透していない。 開発手法以前に「システムの骨格作り」で、大体みんな間違ってる。 「当然やってるよw」って人は、ここで読むのをやめて、周りに啓蒙しましょう。 なんでやれてない(難しい)かと言うと、その理由が当然ある。 少額と言っても、そこはシステム開発なので、100〜500万円くらいはかかる、検証だけで。 それくらい出さないと判断できないことが多いし、期間も3〜6ヶ月かかる。 牛丼みたいに、早くも安くもない。 その金使って、その期間待って
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
