  |
はてなキーワード: システム開発とは
Twitterは会社的には禁止なんだけど、技術情報の交換が便利なのでなし崩し的に使わせてもらってる。
ある日の出来事。
となりの島のチームが大声で打ち合わせしてる。内容も雑談っぽい感じに移っていきだんだん声が大きくなる。
私にはちょっと騒がしいなと感じるレベルで特に不快ではない。そもそも普通のオフィスなので話し声は聞こえて
当然だと思うし。
すると私のとなりの席の人が「チッ！」と舌打ち。
あー、また始まった...
となりの人は大きなため息をつきつつTwitterに盛大に愚痴ってる。
あのなぁ、実名＆顔写真登録してるIDでよくそれだけ会社への文句が書けるね。社内の人があなたのTwitterID知らないとでも思ってるの？
会社へのイメージダウンを考えると冷蔵庫に入って写真をとってるバカッターと何も変わらない。
普段勉強会に参加しているフォロワーさんだけが「うちらの世界」とでも思ってるんだろうね。
そしてなにより腹立つのが、Twitterに愚痴るより隣のチームに注意に行くほうが解決が早いのにそうしないこと。
web系を中心にSIer無いわー論は大きいのだけど、多分この業種はなくならない。
ユーザー企業でもシステム担当はいるけれど本業にリソースを割くべきで、
その結果、好んでシステムのお守りをする人は出てこないため、アウトソーシングが前提となる。
アウトソーサーに要員調整や技術習得コストを押し付ける方が経営的にもよい。
大手企業の中には、情報システムの子会社を持って擬似アウトソーシングをしてるけど、成功してるのはごくわずか。
結局コストセンターなので、IBM、NTTデータ、日立製作所あたりに資本を入れさせて損切りするので、SIerの飯の種になってる
こんなシステム作っといてと決裁さえとって発注してしまえば、責任はSIerに押し付けられる。
アレコレと悩んで失敗して自分の責任を問われるリスクをヘッジできるので使わない手はない。
但し、SIerが安泰かというとそうではなく、稼ぎどころが減っており非常にマズい状態にある。
様々な利害調整を行うPM(プロジェクトマネージャー)は評価されて高額で契約される存在なんだけど、
http://anond.hatelabo.jp/20131003212934
うんうん、そうですね。
何もIT知識のない素人企業を、スキあらば適当な見積もりでボッタクろうとするシステム屋ばかりでここはひどいインターネッツですよ。
世知辛い世の中です。
システム屋を呼ぶときにノー資料ではいけません。思いつくまま口頭で話しても、彼らは都合よく曖昧に解釈するだけです。できあがるシステムはそりゃあもう役立たずですよ。
箇条書きで良いので、システム化したい業務フローは全部書き出しましょう。正常な業務フローだけじゃなくて、イレギュラーパターンもちゃんと明記しておかないと、実装の際に彼ら絶対サボりますよ！
整合性の取れたそいつで彼らの頬をペチペチ叩いてやれば、彼らはあなたのことを素人のカモとは見なさなくなります。
システム化に当たって用意してる予算は、５０万なのか、３００万なのか、１０００万なのか。
話の冒頭で、バシッと宣言しましょう。
これ以上はビタ一文出さないという気迫を伝えれば、彼らが桁違いのボッタクリ価格で見積もりを出すことは無くなります。
契約締結に際してどういった書類が必要かは、会社によって大きく文化が異なるところです。予め伝えておきましょう。
特にお尻のスケジュールが決まってて動かせない場合、注意が必要です。あなたが決裁権限を持ってるなら良いですが、部長や社長と言ったお偉いさんの鶴の一声が必要であるならば。
大半のシステム屋は不誠実極まりないので、開発契約書にハンコが押されるか、あなたの会社の決裁権限者から契約内示が取れるまでは、システム開発人員の手配をしようとしません。そして、正確な詳細見積もりの確定には、システム開発人員が必要です。
もちろん、詳細見積もりも無しに金額の大きな契約なんて発注側からしても怖くてできないので、賢い企業は、要件定義から詳細見積もり提出を第一フェーズとして契約したりします。本開発契約と分けるんですね。
上に挙げた諸々、大変面倒くさいですね。ただでさえ本業が忙しいのに、こんなのやってられません。
彼らは、不信感のカタマリです。内示が出てて後は本契約締結するだけの案件が理不尽にご破産になったり、手間ひま掛けた詳細見積もりが単なる相見積の当て馬に使われたり、開発したシステムの納品後に値引き要求されたり、システムリリース後に瑕疵担保対応という名の新規追加開発を延々要求されたり。色々な辛酸を舐めてます。
あなたがそういった酷い発注者では無いという信頼感さえ与えてあげれば、ふわっとした要望でシステム開発を与えても、あなたの会社にとって役立つシステムを適正な価格で作ってくれることでしょう。
ノブレス・オブリージュ。今後もあなたがよき発注者たらんことを！
追記：
いずれにせよ貴方はシステム屋にボッタクられる
http://d.hatena.ne.jp/Yamashiro0217/20131004/1380855545
ほぼ、考えることだ。
これは正しい、正しいがゆえに
場合によっては駒の重さが30kgぐらいある。
どんだけ優れた将棋指しでも、30kgの駒を100回とか動かしたら、
30kgもある駒を動かすのは大変だ。
開発環境工夫したり、色々して駒を軽くする。
Googleなどの世界的な企業で活躍する、畏敬する人々は得意な道具こそあれ
なぜならは
ほぼ、考えることだ。
ということだから。
研究であれば重要な仕事の殆どは調査や新しいアルゴリズムの考案だし、
システム開発であれば設計こそが最も重要な作業ということになる
手を動かす段階になれば、時間がかかる仕事や重要な部分の殆どは終えている。
その段階で慣れた道具か？そうでないかの差で生まれるパフォーマンスの違いは
それほどの割合にはならない。
出来るエンジニアが最も求めるのは、深く考える事が出来る環境と、
周到な議論を繰り返せる優れた同僚に他ならない。
道具などは、プレゼン用や出張用に貸与されるようなノートPCに、そこらのエディタですら困らない訳だ
もちろん慣れた道具があれば越したことはないけど、それが全てでも最重要でも全くない
手を動かす作業が早くなることが能力の証明＝所詮はコーダーのドカタさんorただの社二病
プログラマになりたてのお子ちゃまが、無駄にテンプレートやデザインパタンを使いたがって
パフォーマンスの悪い糞コードを乱発するくらいに質が悪く、筋が悪いことだ。
ということで
聞く人が聞けば、鼻で笑われて、相手にされなくなる
はあ。メモ帳とコマンドプロンプトだけでIDEと変わらない効率でコード書けるってことですか。そりゃ優秀ですなあ。/酷い道具でも効率落ちないのって無能過ぎて既に効率が0だからじゃないの？
DDD位は使わせてくれるんなら余裕でできるよ。
プリントデバッグのみじゃ、さすがに苦しいけど、その環境に叩きこまれたらバグ出さないように手を動かす前に考えぬけばいいだけ
そもそもエラーハンドリングなんて、IDEなくたって幾らでもやりようあるだろ
おめえエクセルでテキストボックスひとつ動かすのに5秒掛かるPCでガントチャート作ったことあんのか？地獄だぞありゃ。／経営者の皆様、社員の方々にはちゃんとした道具を使わせてあげてください。
その段階になったら、普通はプログラム書いてエクセルをコントロールしてチャートを作るんだよ
何エクセルのGUI使って直接作ることにこだわってんだ？だから、エクセルがサクサク動く環境でなければダメなんて奴は無能なんだよ
ところが実装してみなければ分からない問題ってのが往々にしてあるわけで、だからPDCAサイクルといった手法があるのよね。設計だけしかやってないSE（笑）だったら道具にこだわらなくてもいいのかもしれないけど。
設計が簡単だと思ってる時点で笑える。しかも実装しなければ、分からないって、手を動かす前に考えろよ無能ｗ
だからそう言ってるだろ、あればあるに越したことはない、慣れた道具で作業すれば楽にはなる、が大事なことじゃない
良い道具を知らない人ほど、道具に拘るなと主張する。
色んな道具を知ってるから拘らないんだよ
もちろん、慣れた道具で作業できればそれに越したことはない
ま、こんなところか。
システム開発の受注側がプロ対プロを前提にしているからこそ元増田のような問題がおきる。
IT化したい企業がシステム開発を依頼するという形態はプロ対素人だ。
なぜならシステム開発を依頼することは発注側にとっては通常業務ではなく始めてのこと。知識がなくて当たり前。
というかねぇ
「こっちは原材料と製品イメージを出してるんだから、製品なんかすぐ作れるし、金額だってすぐ出るだろ」
と思いがち（思われがち）なんだけど、システム開発費用って、原材料から製品を作る作業の費用じゃなくて
ソフトを知らない人間には想像できないと思うけど、ソフトはハードに比べて物理的性質という制約がかなり少ない分、格段に自由度が高い上に複雑なので、ぶっちゃけた話、作りながら細部を決めていくんだよ。
言い換えるなら、走りながら考える仕事かな。
なので、システムの要件やそのシステムで業務フローがどう変わるかとか、大まかな画面とかデータの流れとかを考える時点で、既に開発の何割かの作業をしていることになるわけで、それを見積もりの段階で時間をかけて行うというのは、作る方からしたらタダ働きしているも同然。
これは問題を解析しきっていないのに見積もりを出すという、絵に描いたようなどんぶり勘定であり、長年システム開発が炎上しやすい原因の一つになっているんだけど、業界では「銀の弾丸はない」などと揶揄される始末で、即ち根本的な解決策は見つかっていないと。
その金額差の理由は、あなた(の会社)のことをシステム屋がまだ知らないからです。
システム開発ってのは、どういうものを作るかっていう設計書が「きちんと」かけてしまえば、もうほとんどすべての仕事が完了したって言えるものなんだよね。
自動車に例えると、コンセプトデザインから設計図から工場から何から何までほとんど全部がシステム開発に相当し、最後に納品されるサーバとかDVD-ROM一枚とかが、自動車そのものに相当するわけ。だから、「こういうのがほしい」「じゃあそういうのを作りましょう」ってのがきちんとわかるのは、最後の最後なの。
「ここで日付と金額と担当者名を入力すると……」みたいな部分があった時に、金額は数字だけ受けつければいいのか、カンマで三桁毎に区切って入力したら(綺麗に表示されたデータを画面からコピペするとよくそうなる)エラーにするのか、全角文字の数字はどうするか。
担当者名は、結婚して姓が変わった時に、担当者レコードのデータを新しい姓に変更することはできるけれど、姓の変更後に過去のデータを表示させた時には、やっぱり結婚前の姓が表示されないと困る？(ってことは担当者ごとに名前の履歴を持たないといけない)
日付として(いまどきあり得ないけどテキストで入力するとして)12月32日が入力された時にどういう動きをするべきか。カレンダーを表示させてクリックすれば入力できるようにしたい？祝祭日は赤で表示しましょうか、じゃあ会社の創立記念日は？え、社長の誕生日は一献染(いっこんぞめ)色？ログインユーザごとに直属の上司の誕生日と結婚記念日も覚えさせて色を変えたいたいだって？(直属の上司って「必ず」「単数」で存在すると仮定していいの？)
ログイン画面で間違ったユーザ名か間違ったパスワードをいれた時に、ユーザ名かパスワードが違うからログインできない旨を表示するエラー画面に「遷移するまでの時間」が書いてある？時間が短いと、悪党が社内に侵入した時にブルートフォースアタックされやすくなっちゃうけど大丈夫？
そこまで明確に記述されてるものが「きちんと」書かれた設計書って意味ね。そういうありとあらゆることを決めて行くのが、システム開発。
「そういうのはどっちでもいいし、カンマを受け付けないならそういう風に運用しますよ」って言ってくれるなら、(そして12月32日問題その他もすべて任せてくれるなら)金額は安い方で収まる。ただし、本当にそれでシステムが使い物になるのかは誰にもわからない。
そのような事柄すべてに対して、あなたの会社独自のルールを載せて行くなら、金額は高い方になるか、あるいはそれじゃ済まなくなる。
システム屋さんは、あなた(の会社)がそんなことをたくさん要求してくるかもしれないという可能性を捨てきれない。まずないとは思ってても、絶対はない。「あの客はまだわかってないから、この程度のシステムでいいって言ってるけど、きっとxx取引の入力が成されたらそれをメールでも伝える仕組みを入れてくれって言ってくるぞ。その方が絶対便利だし、予め価格に入れておこう」っていう親心みたいな理由で高い値段を見積もることもある。
だから金額には幅があるし、あなたはどこかで「えいやっ」っと信頼できそうなとこに任せるしかない。
odesk
はてなブックマーク - Lancers - 個人に仕事を売ったり買ったり - 仕事マーケットプレイス - ロゴ作成・システム開発・ホームページ制作などをクラウドソーシング
どっちの言い分もわかる気はする。
発注側はどんなものができるか製品がわからないのに製品代を出したくない。
受注側は製品を設計する事は片手間でなく本業のうちだから設計の代金が欲しい。
すれちがう原因はお互いにあって、
発注側は大量生産品や「設計済み」の受注生産品を買う認識でいること。つまり設計の労力を過小に見積もっている。
受注側は相手がシステム開発の発注について熟知してることを前提にしていること。つまり設計の手間が工業製品とはまるで違い、設計が仕事のメインだと顧客に認識させずに話をすすめている。
これが原因だ。
要望を満たすために「顧客が事細かく話した内容をシステムに落とし込んだらどうなるのか、どんな画面でどんな印刷物がでて、顧客ごとのの入金の流れとか、その他諸々がどんなふうになるのか」を考えることがシステム開発のメインとなる作業だ。
この工程は工業製品や建築のようにあらかじめ開発したユニットをくっつけるだけではうまくいかない。
建築では界壁の構造や窓、屋根など、大きな単位ですでに設計されている。どう作られるのか、どの材料を使うのか、どんな施行をするのかが決まっている。だからおおまかな間取りで全体の材料や工程が出せるのだ。やるのは細かい調整のみ。
だが、システム開発は、建築でいうなら木材の種類やネジの長さが決まっている程度の細かい部分しかあらかじめ用意されていない。その程度しか共通設計として使えないくらい案件ごとに設計が大きく変わる。だから手間がかかる。
それぞれが自分の認識で相手を見ているから相手の言い分がとても奇妙にみえ、悪いのは相手だと思うようになってしまう。ということかもしれない。
経緯ははこっちのまとめを見てもらうとして。
本番データを使って何回かテストしてた、というシステム開発やってる人間から見たら噴飯物の言い訳をかましてるのが信じられない。
ツイートページの表示テストがしたいなら、DJ hogeさんみたいなテストデータでも作ってそれでやればいい話であって、
既に投票が行われている本番データを使ってやる正当な理由は無い。
票数が減ったり不自然に増えたりした時点でその投票の信頼性が土台から揺らぐのは当然である。
それにしてもこの件について擁護している奴等の意見もまたフワフワしてんなー。
やっと内定を貰えたけれど。
偏差値60前後の地方私立文系男が中小SIerなんかに行ってやっていけるんだろうか。
システム開発やインフラ構築にちょっと興味はある。適性試験と面接はパスできた。でも、その程度。
基本情報すら持ってなくて勉強中だし、プログラムはC言語で素数を数えたりする程度しか書けない。
仕事としては、製造や金融系の一次・二次請け(？)案件をこなす客先常駐型のSEになるらしい。
会社について「社名 ブラック」でぐぐってもそれらしい情報は出てこない。
転職会議での評判を読むと、給料は業界平均よりやや安いくらいで、残業代や休暇はちゃんとしてるとか。
とてつもないブラックではないらしい。
しかし、
「適性のない人間がSEやPGになるから本人も現場も不幸になる」というような話を聞く。
2chでIT業界への呪詛を吐きながら早く脱出したいという人をみると、将来の自分なのではないかと思う。
「もし会社がいまいちでも若いうちに技術を身に付けて、もっとマシな労働条件で転職すればいい」という話も聞いた。
中にはそういう人もいるんだろう。自分がそうなれるという自信はほぼない。
よく誤解されるのだけど、素朴な概念同士を組み合わせていくと矛盾を避けることができなくなるのはむしろ当たり前のことだ。
素朴な概念は、複雑な現実世界(巨大情報量)をアバウトな方法(情報量小)で分類などを行うものなので、ある一面からみると合理的になっているようにみえても大抵恣意的なルールが潜んでいる。
だから別な切り口の素朴な概念を組み合わせようとするとほぼ必ず矛盾がでてくるのだけど、文部省の教育要綱が悪いのか、素朴な概念は例外処理も少なくて良い等と思う輩が多くて閉口する。
現実の問題を整合性をもって「正しく処理」するための適切な方法は、基本的にそれなりに大きな複雑性のある概念(情報量中大)で切り分けていってそれなりに多い手順の運用で回すしかないってことを、いい加減みんな理解してくれないものか。
もちろんリソースは有限なので、本来「正しく処理」できることというのはひとつの組織の中でも非常に限られてくる、というところまで理解されている必要がある。
そうして初めて「それなりの正しさ」で妥協するということの価値を理解してもらえるわけで・・・、業務システム開発者の苦悩は深い。
ITというかSI屋というのは、こんなに時間がないものなんだろうか。ずーっと追われていて、とてもではないけど未来をコントロールするなんて手が届かない。
日曜に休むのは、単に月曜からいい仕事をするためだけであって、まだ余裕がある証拠だろう。半年前は土日ともに出勤だった。
増田にずーっと仕事の愚痴ばかり書いてしまう。なんの役にも立たないとわかっているのだけれど、もしかすると同じ境遇の人がいるかもしれないと思って。その人に届いたからといってなにも変わらないけどさ……。
国民総背番号制で一兆円のシステム開発案件がどうとかいうニュースを読んだ。国家規模で殺人とはね。十重、二十重の下請構造で原発とおなじになると思う。
