いわゆる受託開発における「プログラミングは簡単な部類」は本当なのか - Qiita

上記ツイートについて、いわゆる「受託開発企業」で働く私の印象としては、本当にその通りだな〜と思います。 そして、これまであまり意識しておりませんでしたが「受託開発における納品（完了）までの各フェーズ出し」をしてみようかと思います。 受託開発における納品までの各フェーズ出し １. 問い合わせへの返答 「お問合せいただきありがとうございます。それでは早速Webミーティングにて詳細を」 ２. 第１回Web打ち合わせ「お互い紹介」編 会社スライドにて自社紹介。依頼内容の確認・質問。 できればここで「依頼内容に対してのざっくりの予算感」をさりげなく聞きましょう。奇想天外な予算を想定しているパターンもあります。 ３. 見積もりの作成 できるだけ素早く見積もりを作成し提出すると吉。（早いと喜ばれやすい） 保守費用についても記載してくださいね。（後で聞かれるパターン多い） 見積もり項目は細かい方が信頼度は

[huusen20]

決まった要件とスケジュールがまともな場合な

[taguch1]

プログラミング以外がすげー大変すぎて相対的にはそう。

[turanukimaru]

そうだな。作れと言うだけなら簡単だし言われたままに作れば良いなら…何を作れば良いか解ってるか…逆にどうでも良いなら簡単だな。

[hogeaegxa]

その通りなので、SIerとかでは真っ先にコスト削減としてオフショアを使う。ただ「簡単＝ケチっていい」ではないので、この簡単な部類のとこから以降の全ての崩壊が始まる。

[n2sz]

まあ設計がちゃんとしてればプログラミングは楽に出来るだろうね。穴だらけだと相当苦労するけど。

[peperon_brain]

枯れ果てたフレームワークで委託先全員慣れてるなら「簡単な部類」だろうが、いまやモバイルはFlutterでWebはReactでグラフはd3使って下さい→「触ったことないので勉強から…」→クソコード→プロパーが全部書き直し泣

[kagerou_ts]

×プログラミングは簡単な部類に入る ○(その他がめんどくさすぎて相対的に)プログラミングは簡単な部類に入る(技術的な話はしていない)/勝敗は戦う(プログラミング)前に決まってるみたいな話でもあるな

[burabura117]

これはめちゃくちゃシンプルなパターンで、顧客や業界、対象システムによってはこんなもんではないんだよな。受注までの手続きもこれの10倍ぐらい迂遠だし、開発工程もまったくもってこんなものではない。

[mr_yamada]

プログラミング前後の工程が完璧なら、「簡単な部類」にはいるけど、そんなケース稀だからなぁ。

[cl-gaku]

設計のセンス次第

[Karosu]

セルフプロデュースできる役者が演じることは簡単な部類というのと対して変わらん考えだと感じた。

[deep_one]

理想的には（笑）／たいていは「設計のミス」がその段階で露呈して突如として最難関と化す。「設計が間違っていましたが、もう設計は変わりません。」

[tyamamoto]

良い設計が出来ていれば簡単だろうね。

[lorenz_sys]

小規模案件と思われる本記事例のように先に見積出さなきゃいけない案件では予算内に要件が収まるよう合意に持って行くのが最大の難所となる。会社の立場からしたらそれに比べりゃ実装工程は気が楽ってことだよ。

[sds-page]

言われた通りに穴を掘る簡単なお仕事だけど他が拙いと職人芸で完璧に掘った穴を埋め戻してまた別の場所に掘ったり埋めて緩くなった穴が崩れないように気を付けつつに横に別の穴を掘ったりという作業が延々と

[Cald]

ネットワークやストレージの設定も簡単だよねって同じ理屈で言える。

[nakag0711]

まずはその簡単に作ったコードを見せてください

[findup]

簡単なCRUDとWebUIのアプリくらいならそうかもだけど、もっと規模の大きいオーダーメイドの業務システムなんかだと辛いよ。納期だけ決まってるから設計終わらないうちに製造とかザラで後から炎上な。

[queeuq]

要件がまともじゃなかったとしてもプログラミングが難しくなることはない。工数としてはプログラミングを使ってるかもしれないがやることは要件定義・設計だから。

[aceraceae]

受託開発ってやったことないけど要するにプログラミングが工程としてあとは書くだけになって「製造」とされてるような仕事の場合でしょ。理論的にはそうでも現実的にはそうなっていないことが多いみたいだけど。

[yuu-yuiken]

23辺りで仕様変更が入るんだよ、スケジュールは維持で

[dodecamin]

業務で通用するプログラミングは普通にむずいと思う。発注側がエムスリーレベルのエンジニアリング企業なら、レビューを突破するのすらかなりキツイと思う。

[remonoil]

自動運転とかロボットとかスパコンの何かとかそういうのと比較すりゃプログラミングもここに並んでる糞も等しく簡単

[operator]

プログラミングそのものが業務の中で難易度が高いエンジニアは受託開発じゃないからな。。。動作するとか機能するとかじゃなくて、性能を上げることに何億円も使える業種

[for-my-internet-demo]

変にプが優秀(なつもり)でもお留め技の属人性上げてるだけみたいなことも多々あるので理想だけはそうなんだろう

[snailcat]

わかるけどプログラミングも期間短かったり予期しない技術的問題とか見つけたり設計の不備見つけたりするから簡単に終わったことないという印象

[mohno]

これはよい受託開発。/プログラミングのことまで（考えられる人が）考えて要件定義や設計がなされているべきだよね。/現実は、そんな事例ばかりではないから問題が起きるんだけど。仕様のないシステムの移行とか。

[PrivateIntMain]

プログラミング自体は決まったこと書くだけだから大変でないとは言わないけど簡単よ。でも決まらないと何もできないので決めるのに時間かかったり金なかったりしてると地獄よ。

[lb501]

なぜ、うつ病になったり、逃亡したりするんでしょう？結局人間関係の問題？

[Flume]

ま、その1〜13をしっかり時間と金掛けてやってくれるとこなんて、今時そんなにないと思うけどな。あと保守と新規で全然違いますね。

[kei_1010]

最近画像生成AIを始めとした色んなAIを試すのが面白くて毎日PC弄ってるから「ちょっとエンジニアとして仕事してみようかな」とか思う時もあるけど、この記事を見て「うげぇー」ってなるから、やっぱやめとこ。

[tadatada1980]

このフローは下っ端プログラマーor三次請四次請とかだと意識できないことが多いので一度説明してほしい内容かも。

[chess-news]

分野によって大変の方向性が違ったりしそうだな。

[harumomo2006]

どこの会社の誰が作ったのか分からないようなソースコードを渡されてこういう風に改造しろとか言われることが多いので他人のプログラムを読むのが得意かつ言われたことを淡々と具現化できる能力があれば楽

[peketamin]

設計は大変だと思う。実装は…シンプルで分かりやすい書き方はムズイ。全然簡単ちゃう。

[cloverstudioceo]

いやいや、そりゃプログラマー視点だからでしょ。プログラミングは難しいからこそ受託ってビジネスが成り立つんじゃねーのか

[otihateten3510]

そんなことはない、コーディングしかしない人がどんどん難しくして行ってるし、技術の刷新サイクルが早い。