受託システム開発の主な登場人物
システムを開発する時に出てくる主な登場人物
（BtoBの受託開発です）
ユーザさん ：普段システムを触ったり、使ったり、参照したりする人
システムの担当者さん：ユーザさんの意見を元に開発する人に指示する人
開発の担当者さん ：いわゆるプログラマ
大きくはこの３者に分かれると思っている。
場合によって、関係者はもっといたり、もっと少なかったりはあると思うけど、”役割”で分けた時に、最低限３者だと思う。
でも必ず分かれる訳ではなく、例えば家計簿をつけようと思ってExcelで作り始めて、関数なんかを駆使して毎日の家計簿をつけている人は、この３者の役割を一人でやっている。
会社で例えると、全てを自社内で完結できるように、それぞれの担当者を抱えるような形式
でも、自分で家計簿を作っていた人が、会社の経費を管理するのに流用したものの、複雑な仕組みが必要になってしまって、自分では作れないマクロ作成を依頼する場合は、「ユーザさん」と「システムの担当者さん」は同一人物で、「開発担当者さん」が別の人になる。
会社で例えると、プログラミングが得意な会社への外部発注をするような形式
そうではなくて、家計簿作ってないけど頭の中でいつも計算している。でもだんだん金額が大きくなって、たまに何万、何十万単位の勘違いをするようになった。だから「家計簿欲しいな」と思うけど、自分のやり方は特殊で、どんな項目でどんな管理をしたらいいか全然まとまらない。
だから自分の話を聞いて、それをシステムにして貰う場合は、「ユーザさん」と別に、「システムの担当者さん」と「開発担当者さん」が同じ人だったり、「システムの担当者さん」と「開発担当者さん」も別の人になる。
会社で例えると、ユーザさんからの依頼を元にシステム開発を丸抱えしたり、それぞれ担当を変えて外部委託するような形式。
いわゆるSIer。
そしてよく問題視される多重請け構造
この構造は、上から順に下に行けばいくほど、指数関数的に金額が増える。
多重請けの場合、「システム担当者さん」は１社で十分なのに２、３社関わっていたりする。また、「開発担当者さん」も１社で十分なのに２〜５社ぐらい関わっていたりする。
なんでこんな風になるかと言うと、大体は納期の短さか、請ける側の自信のなさからくる。
短い納期で何とかしようとすると人を増やせば解決する（と思いがち）。これが”人月の問題”。「３人月で出来ますよ。１人月あたりの単価は●●円です」
ユーザや営業からすると、とても説明しやすい。数量×単価で説明できるから。でも人間なのでモノではない。だから同じ３人月でも、１人で３ヶ月かけてやる場合と、３人で1ヶ月でやる場合は負担が違う。大体３人増えると追加で１人必要だし、１０人以上になるとどんどん効率は低下する。
でもやらなければならない。
じゃあ人を集めよう。
今いないのに？
色々な所に声を掛けて人を集めるしかない！
発注元 → A社（うちにもいない） → B社（うちにもいない） → C社（います！）
多重請けの出来上がり。
ちなみに、短納期自体は特に問題なくて、リーン開発のようにそもそもの考え方自体が短期でモノゴトを進めていくのなら、悠長に進める必要はない。
問題になる短納期は、大体がシステム開発の関係者ではないところからの圧力。
こ、これはちょっと適当すぎたけど・・・
でもこんなイメージ。ただ、大体の場合はお互いのコミュニケーション不足も多い。
最後に、すごい特殊だけどこんなのもある。
最近多いかも。自社で全てを丸抱えしてたんだけど、経験者が退職してしまって若い人しかいなくなってしまったので、鍛えて欲しいとかの理由。
でもこの構造は一番問題を起こしやすい。仕事を発注してくるのもお客様だし、仕事の発注先もお客様だから。鍛えようとすればするほど悪者にされることがある。
こうやって書いてみると、一番上の構成が一番いいんだけどね。
問題は今の日本の上層部の情報リテラシーが低いところな気がするよ(｡･ω･)ﾉﾞ