ごく当たり前の事ですが、基本契約書(委託)や、諸条件がかかれた発注書を出した後、それに同意した請負の返書はもらっておいた方が多いと思います。
リスクという面では倒産や開発スキル不足、よくあるのが納期遅れです。
この3セットをくらうことはザラにあると思いますが、最悪の場合を想定するなら、もう1社どこか同じ仕様が発生すると声をかけておけばいいかもしれません。
納期はエンドユーザーに提出する日よりも、可能な限りバッファをみておいた方がいいです。
作業者が逃げる場合もありますから、さらに重要なシステム開発の場合は、ガンジガラメてことで、公正証書なんかもいいと思います。
URLはダミーです。
小さい、大きいに限らずシステム開発には人・物・金によるリスクが必ずあります。
人・・・開発に適したスキル(技術)があるか、担当一人ではなくもし事故や怪我があった時に代替手段があるか
物・・・開発に必要な器材や資産(サーバーやPC)がすぐに入手できるようなものか、入手困難なものや高価なものでないか
金・・・期間内に予算内に開発が完了できるか
ご自分(やご自分が属する組織)で上記を管理・把握できない場合にトラブルが発生することがあります。
URLはダミーです。
回答が重複しても仕方が無いですので、違う視点から。
小さい会社の場合、会社によってのスキルのばらつき具合の幅が大きいように思います。
(技術レベル、対人能力、問題発見力、品質、納期、セキュリティ、等)
本当に少数精鋭で高スキルな会社もあれば、仕事をこなすためにアルバイトを雇っている
ような会社もあるでしょう。(アルバイトがすべてだめとは言いませんが、モラルや
セキュリティ面などを考えると不安な部分もあるかと思います。)
無論、大きい会社なら大丈夫と断言できるわけでもありませんが、、、
♂です。
以前経営批判をして、システム部門に飛ばされ、システム設計をしていた中で、最低限必要と思われる事項について、記載します。
①システムは、要件確定方法として、スパイラルとウオーターフォールという方法がありますが、システム屋は業務知識が少ないため、業務要件とシステム要件がずれてしまい、システムが機能しないケースがあります。
→多少時間がかかりますが、システム設計者の中核となるSEに対し、業務知識教育をすると要件調整が適格になります。
②システムで使用するデータ形式にもよりますが、百万単位のデータ更新が必要な場合は、コボル等の3次言語を使用するため、バグの発生率が高まります。
→①同様要件設定の前に業務知識教育が必要です。
→中小企業の場合、請負業種に偏りが合ったり業務知識不足が多々あるため、業務知識取得機会を設けるのが前提と考えた方がいいでしょう。
具体的なアドバイス有難うございました。たしかに業務知識教育は重要ですね。
http://www.hatena.ne.jp/ダミー:detail]
システム開発に関わらず、小さい会社は内部の人間関係がすごいことになっている場合もあるかと。
組織としての安定感に不安があるので、内部事情や周辺の噂などをできるだけチェックしておいて損はないかと思います。……漠然とした話ですみません。
小さな会社ではいわゆるプロジェクトマネージャのような
進捗管理をする人間がプログラマー、ということが多々あります。
このため勤務時間の不規則なプログラマを捕まえるのに
苦労することがあります。
対策ですが携帯電話の番号を聞いておく
というのはよいことではありません。
まずでません。
なので定期ミーティングを開催すること
その際の議事録を書いてもらうことです。
http://s2.artemisweb.jp/cggirls/index.html
sexy CG girls
相手方から著作権や特許権侵害との主張をされること 対策としては契約で権利関係を規律しておくこと
有難うございます。大変参考になりました。