Q&A
発注側の観点からのみのご質問になっていますが、細かい要求仕様に応える対価（報酬）は問題にならないのでしょうか。工数と結果に値する報酬は、外注に支払う前提ですか。（私自身は回答はせず、コメントのみですので、必ずしもお答えいただかなくても結構です）
現在の悩みと経緯について
Python3でバックエンド開発を行っており、複数の協力会社にモジュール作成を依頼しています。
その際に上がってくるモジュールに各社個性が大きく、二度手間が多い問題に困っています。
外注は並行作業で開発時間削減を目的に行っていますが、
①仕様書を細かく作るほど時間を要し、時間と品質のトレードオフが課題です。
②協力者の開発の創意工夫ややりがいも尊重しつつ、適切な制限を課して品質を確保したいとも思っております。
なお、現在は、API、インターフェースだけ制限をつけ実装は裁量にお任せしています。
この課題に一定の基準を見つけて解決をしたく、この度質問に至りました。
現在の理想の納品モジュールは以下のような要件です。
１．当然だが使われることを想定して各関数またはメソッドにDocが揃っている。使い方がすぐに理解できれば形式は自由。
・形式まで指定すべきか？指定されたいか？
・指定するならどのような形式がいいか？
２．用途に応じてsetup.py、各種設定ファイル一式（定番のもの）も用意してほしい。すぐに使い始められる状態で納品を希望。
・必要な際、いちいちsetup.py等の要求をすべきか？
・自己判断はどこまで可能か？何を基準に判断しているか？
・逆に一般にどのような時setup.py等を用意しようという認識があるか？
３．pycを削除している外部企業もあるが、削除はしないで欲しい
・削除しないということは常識ではないか？
・通常削除するものなのか？どういうときは削除を考えるものなのか？
４．クラスで作るか非クラスで作るかの判断はこちらで指定したい。
・依頼するのが一定のまとまりのモジュール群の場合、クラス使用・不使用まで口を出されるのは自由度を狭めやりがいを削ぎすぎないか？
・実務でのPython開発でクラスで作るか非クラスで作るかの判断において一定の基準・慣例はあるのか？
５．自分が発注をして、上がってきてイラッとしないモジュールを考えて作って欲しい。
・各開発者、組織ごとにそれほど基準のばらつきがあるものなのか？
・一定レベルの開発者ならこうするといったプラクティスはあるのか？
６．頼んだ通りでなくとも、意図を汲み取って設計の修正や追加作業をしていただけるとまた頼みたくなる。
・サービスを強制せず、双方の利益拡大や働きがい考慮ができるよう協力したいが、
Pythonモジュールの外注では開発者側で最低限これだけは指定してほしいといった要件があるのか？
・逆に、ここまでは指定しなくていいといった要件とは？。技術力の不信感強調、自由度減によるやりがい減等は避けたいです。
助けていただきたい事
上記の関係で質問やお伺いしたい点が数多くありますが、
お答えいただける範囲で構いません。
それぞれについて理想の納品モジュールが備えるべき基準、それらの疑問へのご回答、
ほか不明な点などありましたらお聞かせ下さい。
言語はPythonを想定していますが、幅広い分野の方のご回答も視野を広げる上で大いに役立つと思っています。
コーディング文化は違いますが、Ruby, JavaScript等Web関連の言語からそうでないものまでのご経験をお持ちの方も
それぞれの視点からのご回答をいただけましたら幸いです。
ビジネス上の制約はありますが、
頂いたご回答は広く一般にも開発のやりがいと協力のしやすさについて指針を与え、
同じような悩みを抱える多くの方々に希望を与えるものと思います。
なお、ベストアンサーの基準が付けにくい質問のため、
1週間以内の回答で個人的に一番納得する答えだった場合にベストアンサーとさせていただきます。
ここまでお読みいただきありがとうございました。
皆様のご回答、お待ちしております。
宜しくお願いいたします。
コメント頂きありがとうございます。
記載漏れのご指摘の件、工数と結果に値する報酬は十分に支払う前提になっております。
報酬が十分でもここまでは要求仕様過大と思う点や、
逆に報酬が十分と感じない場合において、過大な要求仕様は言わずもがなとして、意図的に通例必要な最小限度の要件（些細なことのようで使う側にとって重要なこと等）を行わないということは考えられるのでしょうか。
開発者はどこまで行うのがビジネスマナーといえるのでしょうか。
当方が挙げさせていただいた点が最低限押さえていただきたい点と考えますが、不足や過剰、勘違いがきっとあるのではと思っております。その際はお手数おかけ致しますがご指摘いただけましたら幸いです。
作る側として感じたのですが、
＞６．頼んだ通りでなくとも、意図を汲み取って設計の修正や追加作業をしていただけると
正直言って、これはやりたくないです。
今までの経験から言って、勝手に作った場合、「それはいりませんでした」「そういう風に指示した覚えはない」「作り直してください」
となるのが目に見えているため、必ず確認してから作るか、もしくは確認されたくないと発注元さんが考えているのであれば、要件として書かれた通りにしか作らないようにしたいです。
つまらない開発者だと思われるかもしれませんが、意味のないリスクは取りたくないです。
他の項目については、pythonモジュールを他社さんに提供したことがないため、私もわかりません。。。
---
報酬が十分であれば、厳しい制約やドキュメント要求があっても開発します。
むしろ、丸投げで「自分で考えてよ」、みたいな発注者の仕事は受けたくないです。
後で、「期待に達してないから受け入れできません」と言われても困るので、受け入れ条件が明確であるほど安心して開発できます。
回答2件
0
一般的なSierです。受託開発も開発の委託もする立場です。
pythonではなく一般論としての意見です。
その際に上がってくるモジュールに各社個性が大きく、二度手間が多い問題に困っています。
普通かどうかは判りませんが
- ドキュメントのレイアウトや記述レベルは発注者が指定する
フォーマットと粒度が判るようなサンプルを渡します。
- コーディング規約を明示する
命名規則やタブは空白いくつとか、イラッとすることの無いレベルまで指定が必要です。
- 納品して欲しいものは成果物として粒度も含めて契約時に合意する
setup.py、pyc、など契約時に指定して合意しておく
- 「意図をくみ取って指示の無い作業」が必要であれば見積時・契約時に詳細に合意が必要
「当社の仕様書は必要十分な記述が行われていないので、常識に照らし合わせて都度確認すること」などを契約書に盛り込む。→恐らく「常識」の範囲で揉めると思います。
- 「自分が発注をして、上がってきてイラッとしないモジュール」
イラッとするかどうかは個人差が有りすぎて合意は難しいと思われます。
- 「クラスで作るか非クラスで作るかの判断はこちらで指定」
発注時に指定できます。
企業の規模にもよりますが上記のような契約を明文化せずに取り交わすと下請法に抵触する可能性があると考えます。
発注者側から「そんなの常識でしょ？」と言われたら、受託者は不利益を被ってしまいますからね。
そこは相互の信頼関係と言っても上手く行かないと思いますが。。。
後々揉めそうな案件(条件)であれば、受注者はリスクをかなり積んでくるので発注側としてもコストアップで苦しむことになります。
また、複数の企業に発注する場合、様々な規約などで品質を揃えておかないと、稼働後の保守時にメンテナンスが大変になります。保守担当者がそれぞれ分けられるのであればなんとかなるかも知れませんが、社内のローテーションも進まなくなります。
開発者はどこまで行うのがビジネスマナーといえるのでしょうか。
契約書に書かれたことのみをするのが開発行為のビジネスマナーではないでしょうか？
不足も過剰もマナー違反では？
ちょっと辛辣かも知れませんが、属人性に頼るような仕事はビジネスとして良くないと考えます。
当然お客様の仕様が矛盾しているとか、必要な画面が漏れているとかあれば確認はしますが、
工数が増えるなら契約追加・納期変更となります。
投稿2019/10/05 13:43
総合スコア799
0
＃ 雑談程度の意見として受け取ってください
質問文を読んでいて、次のようなステップになっているとスムーズに行きそうだという感想を持ちました。
(1) テストコード（または呼び出し側の擬似コード）を発注側が書く。これを受け入れ条件にする
(2) テストコードにも考慮もれがあるだろうから、設計の段階で開発者と詳細を詰める
(3) 正式な開発依頼
「上がってきてイラッとしない」 や 「クラスにするかどうか」 のくだりは (1) で解決しそうな話のように思える。
「意図を汲み取って」のくだりは、 (2) の段階で出てきてほしい話((3)だとアウト)かなと思いました。
また、 (1) が難しいなら、(2) の段階で話を詰めて、作ってもらってレビューする。
設計(2)と開発(3)が別契約になっているとリスクが少ないように思いますが、それが現実的かは分からないです。
「テストコード」の部分は「テスト仕様書」でも良さそうな気もしますが、
モジュール使う側も開発者なら、テストコードのほうが手っ取り早かったりしないかな、と。
投稿2019/10/05 17:31
総合スコア484
あなたの回答
tips
プレビュー
