アジャイルを考えたやつの死を願うスレ [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
アジャイルって単語を聞くと必ず現れるステロタイプのカス
ほんとクズすぎるわ
スクラム組むならSMは必要だ！SMは管理者ではなく支援だ！開発チームとは平等だ！！
そうしないと失敗する！！
ではPLではダメな理由はなんなんですかね？という問いの回答はくっだらねえ精神論
はああ？多くの優秀な部隊は有能な指揮官と明確な指事系統によって作られてるんじゃ禿げ
おまえのいう開発チームってのはカスが混じらない前提やろが
理想は夢の中でだけで語れよ！
ほんとアジャイルとか害悪やわ
考えたやつは火炙りでいいレベル どう考えてもプログラマが要件定義、設計、実装全部やった方が速いですね! アジャイルは発注側が何もしなくてもいいからね。
全て口頭で指示するから、その場その場でころころ変わる。
永久に仕様が変わり続けると言う恐ろしい仕組みだ。
発注者は、何もしないでずーっと遊んでて、
責任を全て下請に転化できるんだからこんなに便利なものはない！
トヨタの役員もアジャイルがいいと言ってたが、
今のトヨタの役員って、全員が高学歴で弁が達者なカスばかり。
まあ、社長が私立文系の馬鹿ボンボンだからな。
馬鹿じゃないのにアジャイルを推進するのは、
会社を崩壊させたいからだ。
トヨタの役員は、一度トヨタの製造部を崩壊させて、
創業家の関係者を全て追い出して、
東大閥が支配する大企業にしたいと望んでいると言ってた。
まあそうなんだろうな。
アジャイルにすれば企業は崩壊する！
トヨタ崩壊も近いだろう。 ■ユーザ
実際本当のエンドから何を求められてるか全くわかってないカス
■設計担当者
ユーザがアフォなので実力を発揮できない
最近はプログラマがやることが多い
■プログラマ
ユーザに何を聞いても困ってしまってワンワンワンワンワンワンワンワーン
アジャイルで解決!
するわけないｗｗｗｗ その昔、ウォーターフォールが当たり前だった頃、
これじゃあ出来上がりまでシステムの問題点が分からないってんで、
プロトタイプが用いられて、ある程度問題点を修復してから全体を仕上げられると喜ばれたが、
そのうち、プロトタイプの機能まででいいから納品してってケチな顧客がたくさん出て来て、
いつの間にかプロトタイプを積み重ねて作り上げて行くアジャイルが生まれた。 アジャイルは開発手法では無く、顧客の金回りの都合で、何回にも分けて納品して行くってだけの商売方法だしな。 仕様が決まってないからアジャイルで～
でもカシ責任は明確にしたいので請け負い契約で～
ほんとアジャイルってクズですわ
この世から消えて欲しい アジャイルなんて糞を考案したやつは地獄へ落ちろ
短期高速開発のなかでもアジャイルは飛び抜けて糞 >>10
いいですよ～（仕様書もねぇのに訴えられるもんならやってみろよグズが）
よろしくお願いします～ アジャイル撲滅運動があれば参加するで
そもそも開発者の地位が低い日本には合わん
それもわからずPOだーSMだーと叫んでるバカにはヘドがでる アジャイルを説明しているものを読むと大抵抽象的な表現が多いよな
具体的にそれが何をもたらしてどのような効果があるのか誰もわかってないんじゃないかという気すらしてくる アジャイルなんて考え方を導入したら
設計専門のSEが要らなくなってしまうから
一生導入しない >>15
だって出てくる登場人物にファイナルアンサーができる人間がいないもの アジャイルは内製でのスタイルだから
お前らの大半関係ない >>18
そう思ってるのは君だけじゃないかな？
下請けにアジャイルで発注するって、
某F社の担当者が俺の目の前で言ってたぞ？ こんなくだらねえことやってる暇があったら
要件定義しっかりやれ >>18
最近はアジャイル風な請け負いという謎の発注が増えてるんだよなあ
アジャイルでやれば費用も安く仕様も後で決めればいいってイメージを作ったアジャイルはマジ糞やわ 別にアジャイルが悪いわけじゃなくて、仕様決められないベンダと、それにかこつけて今まで使えないとわかりつつ無駄なソフト作ってきた請け負い両方が未だに生きてる日本が悪いって話じゃん 一発で書類だけでシステム設計するってのが間違いなんだよ >>22
アジャイルなんていう銀の弾丸に見せかけた銀メッキのゴミクズを考えた奴が一番わるい >>26
考えたやつはバカに金出させて儲けようとしてるだけだけどなw
銀の弾丸なんて毛頭思ってないわw >>27
開発中に仕様変更に柔軟に対応できるアジャイル！
WFよりもコスト安い！
とても魅力的じゃん？
そのイメージだけでごり押ししてくる。実態は>>18であるゴミクズであることなんて考えもしない 客の言いなりになると成功しない
無茶な要望は切り捨て前提で、優先度低のストーリーで合意しろ
期間内に最低限の要望を聞いて実装して納品する 日本はプログラマーの価値が低いため中堅になると管理職になりプログラマーはスキルが低い若手に集中する
そのような日本で開発チームに明確な指揮系統がないアジャイルなんて適用できるはずもない
日本でアジャイル推進してのは頭が弱い証拠 そのような日本でスクラムマスター名乗ってるバカって生きてて恥ずかしくないのかね おれもスクラムマスターの人にスクラムのメリットを聞きたいな アジャイルというか、そもそも日本のSI系のレベルが低い事が問題なのでは？
平均以上のエンジニアを揃える事が出来る自社サービス系は良いだろうけど。 >>32
只で女子のコカンに頭つっこめるんだぞ？スクラムしたくないのかお前？ Java9のリリースは延期されている
自社サービスだから出来ることか？
日本の受託開発じゃこうは行かないよな >>33
ま、まさかアメリカや欧州なんかの
バグだらけのぐちゃぐちゃのソースの、
ああいう仕事がいいっていうの？
一部の著名なツールはバグが少ないかもしらんけど、
うちの会社で使ってる米国・欧州製のソフトは、
マジバグだらけでまともに動かない。
それでも外人はそれが普通だと思ってつかってるから
口あんぐりだよ。
まじ日本のソフトは品質高いと思う。
もちろん海外でも一部のソフトは評価高いけど、
結局調べてみると日本人がかかわってたりする。 Huluの日本版のシステム切り替えは失敗した
開発会社はろくに動画も見れない未完成品を納入するなんてどうかしている
これはアジャイルとかじゃなくて一発勝負？
そんな物を納入するぐらいなら延期でもした方が良いと思うが
マジで不具合に気づかなかったのか
気づいてたけどもうどうにでもな～れって感じなのか
損害は大きそうだが損害賠償請求とかされるの？ >>37
マジで言ってるの?日本のSI業界を見てレベルが高いと
自らの仕事に誇りを持つ事は良い事だが、現実を見ないと行けない
>うちの会社で使ってる米国・欧州製のソフトは、
>マジバグだらけでまともに動かない。
どうしたら日本製ツールの品質が相対的に高いと言えるのか?
サポートが海外製品に比べ良いだけで、ビックリする位低品質な物が多いじゃねーか。
あと日本製ツールで海外で使用されている物自体殆ど無いのは何故?
>結局調べてみると日本人がかかわってたりする。
具体例を上げてみてくれ。
因みにベイエリアのIT企業に勤めるの日本人の比率は中国系、韓国系に比べ低い
そもそも、世界で成功してる日本のIT企業って何だろなー
既にSI代表NTTデータは日本式を輸出しようとしてボコボコにされましたとさ >>39
研究分野でも遅れてるぞ。
特に機械学習周りの遅れがやばい。 日本で委託するとオブジェクト指向もへったくれもないメンテナンス性の低いコードが、納品基準を満たすようにスパゲティされて出てくる
外国に委託するとそれなりにオブジェクト指向されて、考えられたコードがでてくる、ただし品質基準やプロダクトの目的明確にしないとバグバグ
後者の方がレビューして直すの楽
のでやっぱり外国のほうがレベル高い印象
おまいらベトナム人に負けてるぞ 日本の場合、業務系の文化が特殊でエンジニアが育たない
出来る奴は直ぐ見限って他分野に行くしな 日本でスクラムやりたくても1レベルのやつしかいなくて、どういう理念かを説明しないといけない。なんで教育コストをこっちが払うんだよ、知っとけよプロだろ。 アジャイルがドカスな理由はアジャイルが適用できる条件を明文化してないことだ
もともとプロダクトが社内で完結するかつ定期的にデプロイするような極めて限られた条件でやるもの
それをクライアントアプリとか請負とかに適用しはじめたバカがどこかにいる
死刑 クライアントアプリは普通に良いだろ。
日本固有の請負構造には向かない気がするが。 この国の開発スキームはWFかアジャイルしかねーの？
頭悪すぎね とりあえずSMなんていう無駄なポジションはいらないからアジャイル ver2で削除すべき
そして開発チームはピラミッドの最下層という本来のポジションに戻そう
バックログとスプリントは使いやすいから採用でいいよ
むしろそれ以外全て削除でよろしい それアジャイルとアジャイルプロセスを混同してるやん >そして開発チームはピラミッドの最下層という本来のポジションに戻そう
それはお前ら日本のSIerだけやw
まあアジャイルは構造的にSIerに合ってない気はするな >>50
アジャイルプロセスってスクラム等、
アジャイルな開発を実践する為のプロセス例を纏めた物でしかなくて
当然そのプロセスは状況によって適用しにくいものもある
アジャイルってのは本来アジャイル宣言にある原則の事で
もう少し抽象的な物なんや
ttp://agilemanifesto.org/iso/ja/principles.html
因みに中身読んだら分かるけど、そもそも日本のSIerには実践するのが難しい原則になっている そういう中身のない精神論的抽象的表現がアジャイルの糞さを物語ってるな
そんな糞から生まれたスクラムやXPは糞を越えて下利便なのは当然やわ 上記日本語訳だと確かに精神論に見えん事もないな
原文読んでみろ印象が違うから
まあ、そもそも効率を求める改善プロセスとか
非効率の塊でもあるSIerの文化とは相容れないだろう
本気で効率を求めて改善していくと請負構造の利害関係が崩れるしな ソフトウェア面だけ見るとむしろ初期は下がるよ
チームの一番下の人のレベルに引きずられる
ビジネスまで含めて考えられるなら無駄なソフト書かなくなるから効率良い アジャイルが失敗するパターンとしては
ウォーターフォールを短いスパンで繰り返すっていうやり方になったときだな 内製やアジャイルだとソフトウェアが本当に必要かどうかの査定がない
とりあえず作り始めて、使ってみてから無駄な労力だったねという評価がくだる
反面、ウォーターフォールには無駄がない >>58
被害は小さいけどね
ウォーターフォールは100%莫大な額を使うから失敗したら、失敗と評価されたくないので、失敗作を使うことになる 内製に勝てる開発手法はないよ
ただし、維持するには、上層部がずっとプログラマの貴重性と戦力性を理解し続けるという鬼門があるけど >>56
そりゃスクラムの有効性とは別の話だろ
単純に短期イテレーションでWFなんてバカな真似をしてたから失敗してるだけ
短期イテレーションがスクラムである必要とはまるで関係ない 実際大手ユーザ企業を中心に内製化を進める流れがあるが
SI業界にとってやばない?この流れ
アメリカで内製化が進んだ時と同じ事が起きるのであれば
食ってけなくなるSIerもかなりでてくる ウォーターフォールは昔からある基本的な進め方のことだ。
だがうまくいかない。
要件定義が未完成なのに、それに気づかず基本設計に入る。
というか気が付くようなイベントがないから。
要件定義はテストできないし、動作確認できないから。
もちろん、絶対にできないということはないが、
それをやるだけの能力のあるSEがもういない。
そして基本設計が未完成なのに詳細設計にはいる。
詳細設計をやる連中は全体が見えてないから、未完成部分が
あちこちに残ってしまう。
そして開発フェーズへ。どうなるか予想つくでしょ？
いくらプログラマが直そうとしても、もう無理となってしまう。 結局アジャイルってプロダクト考案から開発まで１組織で完結できてプロダクトの最適化から開発コスト圧縮まで全ての利害が一致している内製でしか通用しないんだな
そりゃ内製なら同じ開発チームを何年も維持できるし何年も同じチームでやってりゃ開発チームが指揮官なしに独立してもそれなりになんとかなる
何年もやってりゃSMみたいなくだらない相談役も必要か
そもそもスパイラルやWFと同じ開発スキームとしてテーブルに乗ってるのがおかしい っていうかユーザの業務プロセスとシステムが複雑化してる状況で
大昔みたいに全てを見通して設計するのは無理じゃね?
ユーザ企業だって必要十分な要件定義できないでしょ うん
だからプロダクトを細分化して短期で少しづつ作っていこう
厳密な工程というものを踏むのはやめよう
これは間違ってはいない
だからアジャイルで！スクラム組みましょう！
↑意味不明 この世界にはWFとアジャイルしかないんですか！
どっちも糞やん >>67
要件定義は客の仕事じゃないしもちろん君の仕事でもないのだよ？
無駄な心配しなくていいよ無能コーダーくんw クライアント企業の競争力を支えないといけないSIerが逆に足を引っ張り始め、
プロセスを改善しようとしてアジャイルに目をつけたが、
そもそもSI業界の従来の元請け、下請けやらの利害関係と相反する代物で、
身動きが取れないがんじがらめ状態が今って事かな >>70
もう外部のSEに俺たちの要件定義は無理と見限って、社内にSE抱えているユーザ企業は大手を中心に多いんやで
小さな案件しかやれない人には関係ないだろうけど >>72
そんなもん昔から連綿と続いておるわ
そしていつの時代も変わりなく詳細設計しかできんのだよ社内SEという人種は >>73
ちゃうちゃう、そんな情シスに毛が生えた程度の連中の事じゃない
経験ないか?客先行ったら元同僚が出てきたとか
人間関係によってはホラーになる(苦笑 >>74
つまり情シスに毛が生えた程度じゃないかお前の同僚ならw
むしろ毛が抜けたぐらいじゃね？ >>76
お前は上流から始まった一部内製化の流れで危機感を覚えないのかと
今年度に入って一部ユーザはさらに一歩進めてきたというのに
まあ元請けに勤めてないなら分からんか >>77
内製でも満足できる程度の仕事は元々やっとらんからなｗ
どうぞ自由にアジャイルごっこやってれば？って感じ
まあ失敗して泣きついてきたらしっかり要件定義したるわｗ >内製でも満足できる程度の仕事は元々やっとらんからなｗ
ほんまに知らんのだな、ユーザにとって重要(規模の大きい)案件こそ
ユーザ側のSEと一緒に要件定義を作りましょという流れがあるのに
ユーザ企業の人間の方が要件が分かるというのは
一応理にかなった言い分なので 、受け入れざるを得ないが利害関係がぶつかる事も・・・
>内製とか単価合わなくて無理だろ
結局またアメリカで起きた事を二週遅れ位で追う事になるから
今の日本とアメリカの状況の何処かの中間点で落ち着くだろうけど問題は何処で落ち着くかだ アメリカで次々とエンジニアが解雇されていくニュース映像なつかしいな
内製化＆アウトソーシングの波が日本に来なかったのは、日本語の壁があったからだけど
いよいよ、日本をターゲットに人材育成をはじめた国が増えてきたから
もう業界地図が一変するだろうね
ただ、日本語でITをがんばっても輸出先がないのがアメリカと決定的に違うところだね >>80
要件定義の重要性と規模は関係ないわw
むしろ業務が安定して大きな変革を望まないシステムの方が
現行業務とシステム要件との乖離が少ない分専門家の必要性は低くなる程だぞw
何度も言うがそんなもんどうぞご自由にアジャイルでどうぞw
本当に要件定義が必要とされる仕事は他にいくらでもあるからなw
そういう仕事では
> ユーザ企業の人間の方が要件が分かるというのは
> 一応理にかなった言い分
これは絶対にないw
客がそもそも要件が分かってないから我々が必要とされとんのやで 既に経済規模に対してエンジニアの割合が多いっていう話もあるしなー(要するに極めて非効率な状態
何処かで調整局面が来るのは仕方の無い事だろう ITゼネコン構造のうち、要件定義する層が移動するだけであって
SEやプログラマが多重派遣なのは変わらんでしょ
それともSEやプログラマもユーザー企業が直接雇用しようって流れなの？ どこで人が足りなくなるか?ってとこだね
外注出せばいつでも頼めるだろって状況だと今の状態が続く
もういっそ自社で作るか?ってぐらい外注が捕まらないなら
内製化もあるはあるかな? >むしろ業務が安定して大きな変革を望まないシステムの方が
>現行業務とシステム要件との乖離が少ない分専門家の必要性は低くなる程だぞw
あのな、規模の大きい安定志向の業界こそ現行業務が30年前の汎用機ベースでもう限界とか、
普通にあるんだぞ。そんな状況で現行システムとの乖離が少ないと言えるのか?
>何度も言うがそんなもんどうぞご自由にアジャイルでどうぞw
別にアジャイルが日本のSIerにとって完全な処方箋になるとは思わないが
現行のプロセスに限界が来ているのも確かだ
その上、ユーザ企業が力をつけようとしている状況で今の開発効率を良しとしてたら、本当にそのうち食えなくなるぞ
まあ、元請けに従うだけのSEとかだと分からんだろうけど
>それともSEやプログラマもユーザー企業が直接雇用しようって流れなの？
アメリカはそうだけど日本で何処まで進むかはまだ分からない 客からの案件まとめようにも具体的な技術的事がわかってないのでキッチリとした仕様書が書けないで仕事が果たせない
それでトラブルが起きると客や下流がわるいと責任転嫁
その癖やってやるという上から目線 >>86
どこで人が足りなくなるか?ではなく
どうすれば自社の競争力にとって一番効率が良い投資になるか?という視点になると思う
仮に大手がエンジニアを直接雇用して、今外注しているシステムの内製化を進めた場合
それに関わるエンジニアの数は今の外注先の規模と比べ大幅に少なくなるはず アジャイルは工数に対して随時費用が発生して初めて成り立つ
金額は変わらないのに仕様変更しまくりはすでにアジャイルではない エンジニアシェアリングが崩壊するから3分の1ぐらいになっちゃうかな?
潰れるところは一気に潰れるだろうね >>87
業務が変わらんなら要件は変わらんわw
> あのな、規模の大きい安定志向の業界こそ現行業務が30年前の汎用機ベースでもう限界とか、
> 普通にあるんだぞ。そんな状況で現行システムとの乖離が少ないと言えるのか?
なにこれ？完全にプログラマの視点だけどw要件の問題じゃねえよw >>91
因みに所謂ITゼネコン勤務の自分としてはこの流れは不安
給料だけは良いから稼ぐだけ稼いでヤバそうならユーザ企業に転職したい・・・ >>92
はぁ？ユーザがビジネスを行う上で業務プロセスを変えたい要求があるから更新するんだろうが
結局古いシステムで業務を行なっていると、本当は〇〇したいけど現行システムでは無理だから別途XX対応している。
とか普通に有るわけよ。お前は現行の業務フローとシステムに対してユーザが我慢している事とか調査しないのか? >>96
金出して修正すりゃいいじゃんって普通に思う >>87
ついでにお前の勘違いが丁度いいので言っとこうか
アジャイルは開発効率が良いのではない
まともに要件定義をできる人がいない多くの開発の現場では
最初に全てを決定してしまうウォーターフォールよりはマシなだけだ
あくまでも人的リソースの不足を補うための応急処置的な手法にすぎん
「何作ればいいのか分からんけどとりあえず作って直してけばいいんじゃね？」ってなw
つまり
ユーザーの現行業務との乖離が大きい程、ゴール地点の方向するらわからなくなり
そのシステムの規模が大きくなる程、システムの全体像を把握できないままスタートするため
アジャイルでの開発は困難になる
そういう時こそ要件定義の出番なのだよ >>96
うん、だからそういう局所的な目線が実にプログラマ的なんだけどw >>97
自分も本来、業務プロセスに変更が必要になった時に随時投資を行い
システムを改修するのが良いとは思うのだが、保守的な所は運用であれこれ延命を計るんや
それで30年近くツギハギで業務をしていたりな・・・
そもそもその30年の間に統廃合してたりするのにビックリやで >>98
そもそもお前は自分は完全な要件定義が出来ると言っているのか?
中小企業のパッケージ化されてそうな規模の業務だと大きな見誤り無く行けるだろうが
業界最大手とかだと世界中でまだ彼らしか遭遇していないだろう問題とか出てくるんだぞ
それすら見通せると言っている?
もちろん要件定義はするさ、ただ全てを見通すのは無理
今までは無理やり納品という手も使えたが、大手ほどユーザ企業が知恵と力を付けて来ている状況では
その手も難しくなって来ている
そんな状況下で現行のWFベースのプロセスは限界に来ているのだが
前述したようにアジャイルも業界構造の問題で処方箋にはなり得ない
結局そのような中どうにか中間点で落とし所を模索するしかないんやで? >>101
> 業界最大手とかだと世界中でまだ彼らしか遭遇していないだろう問題とか出てくるんだぞ
> それすら見通せると言っている?
うん、それを見通すのが要件定義だけどw
業務が変われば客の抱える問題も本質的に変わる
それを新しいシステムに置きかえて将来客が遭遇するであろう問題点を
シミュレーションするのが要件定義なんだよ
今現在客の抱える問題なんかクソくらえや
そんなもん業務が変われば自然消滅やでwww >>101
そんな高度なレベルでできるできないの話じゃなくてそもそもクソなんだろ
クソを細切れにしても所詮はクソって話は俺も理解できる ちまちまパアポで日程浪費して
仕様書ｗ書かれるよりはマシ >> 業界最大手とかだと世界中でまだ彼らしか遭遇していないだろう問題とか出てくるんだぞ
>> それすら見通せると言っている?
> うん、それを見通すのが要件定義だけどw
まじかwwwそれが完璧に出来るんだったらSEなんて即辞めちまえ
自分でビジネスするなり投資なりで大儲け間違いなしじゃねーかwww
>今現在客の抱える問題なんかクソくらえや
>そんなもん業務が変われば自然消滅やでwww
そりゃ要求と要件に差があるのは当たり前よ
だが要求は要件を探るための手がかりだからな >>105
なんか煽り口調になりすぎたから書きなおすw
つまり俺が言いたいのは
1. 要件定義とは、現時点の客の問題を解決するだけではなく
2. 新システム、新業務における客の問題を解決する事
が要件定義の必要条件
2.の意識のないやつが多すぎるから要件定義がうまくいかない
逆に2.の意識を持ってされた要件定義はウォーターフォール開発において
今のような惨状は引きおこさないしw
プログラマ頼りのアジャイルの有用性も薄れる
> まじかwwwそれが完璧に出来るんだったらSEなんて即辞めちまえ
> 自分でビジネスするなり投資なりで大儲け間違いなしじゃねーかwww
まあコンサルが皆自分で商売して大儲けできるわけじゃないしなw
適正の問題だよwわかるだろお前もw >>106
具体的にどういう契約になるの?
小サイクルで回すってことは前回の開発の終了はいつ? >>106
自分の考えをまとめると
>1. 要件定義とは、現時点の客の問題を解決するだけではなく
>2. 新システム、新業務における客の問題を解決する事 が要件定義の必要条件
上記に関しては首肯出来る
俺たちのミッションはユーザ企業の競争力を支える事だからな
>逆に2.の意識を持ってされた要件定義はウォーターフォール開発において
>今のような惨状は引きおこさないしw
だが上記には首肯しかねる
それはやはり完璧な要件定義を行うのは無理という前提があるから
>プログラマ頼りのアジャイルの有用性も薄れる
自分は業界構造上、日本のSIでアジャイル的な開発は本質的に無理だと思っているが
ユーザ企業の競争力を支えるというミッションを進める上で、現状が健全な状況ではない事も分かっている
その上でより競争力になれるようなプロセスを求めた時に、PGの役割が大きくなる事も
仕方のない事だと自分の立場でも思う(そんなPGが今業界に居るのかは知らないが)
ただ、それによって自分たちの価値が落ちるとも思わない
例えば仮に本格的にアジャイルプロセスを導入した場合、Systems Analystという立場はより重要になる事が
アメリカの状況でわかって居るし(競争も激しくなるだろうけど)。
って所かな 1ヶ月ぐらいでワンサイクル回す?
①見積り
②設計
③実装
④テスト
⑤納品
⑥検収
⑦修正
ってやるじゃん?
この内金が出るのって②～⑤だよね?
それぞれ工数出すと内容に関わらず アジャイルを絶対に使ってはいけないケース
・請負
・低レベルなお仕事プログラマしかいない日本企業
はい、アジャイルは全く役立たずでした 下請けのプログラマーってのは90%はガチでゴミだからな
残り10%の優秀なプログラマーのフォローでなんとか体をなしているだけ
そんなゴミどもと対等の関係でやったところでゴミしか出来ない ①見積り 3d
②設計 5d
③実装 5d
④テスト 2d
⑤納品 1d
⑥検収 2d
⑦修正 3d
のトータル21dだけど
金が出るのって②～⑤で
⑥～①（次サイクル）の約２週間って
金出んよね?
なんかどう考えても評価派遣でも出した方がいいと思うけど
お前のいる部署って採算割れちゃうんか? >>113
いや、かかってるコストがゼロになるわけじゃないで
つまり小回りを聞かせた分オーバーヘッドがデカイ
さらに従来のwfは設計実装テストの人員を期間で配置できたので人件費はグッと下がるはず
そう考えるとなにもいいことないで 開発会社からすると単に無駄の多いいクソ重い開発になってる さらにさらに開発が終わり本来別の案件に着手できたプロマネやプログラマも拘束するし
テスト要因も常に抱えてないといけない
内製であっても駄目だろコレ
得に評価部隊なんて大半がスキル無しでいいんだし無駄やで 開発会社はそもそも早く検収終えて回収したいだろうしなー。
そのそもこの時点でアジャイルと合ってない。 でてねーよw
なぜか外注でアジャイルやろうとしてるバカ企業続出中www >>119
いいや外注も内製もないよ
単にコストが無駄にでかい
単純計算２倍じゃすまんと思うで
wfで１回作って、失敗したとこや変更したとこメモっておいて
もう一度開発できそうｗｗｗ
このぐらい無駄 害虫でアジャイルなんてできるわけねー
だってぱよぱよちーんかもしれないやつを社内に何ヶ月も入れるなんてできるか？ >>120
スーパープログラマー集団を常に一定数抱えてそのベロシティ内で開発しつづけられるような内製ならアジャイル最強
見積り、設計、納品なんてやってる時点アジャイルの価値なし >>122
実際テスト部隊とかどうすんの?
ずっと抱えておくの? >>122
スーパーまでは必要ないよ。ある程度レベルの高いプログラマは必要だけど大多数は並で良い。 >>123
スクラムはイテレーション毎に該当機能をdeveloper自身でデプロイ可能な品質まで持っていくからテスト部隊など無い >>125
まあその並以上だけで6～10人揃えることも日本企業にはほぼ無理なんやけどな >>125
無駄多いなぁ
プログラマ抱えっぱなしじゃん
テスターでええのに 並の人間を10人揃える為には100人発注しないといけない
それがITゼネコンの罪 >>129
実際戦力になるのなんて少ないから
空いてたらテスターやってもらうってのも
いい調整になってた面あるよね >>127
そうか？
試験書も作らんし事前に決められた仕様通りになってることの確認だけをさっとやって仕様決める奴にさっと見せて終わりやで
だから仕様通りに作れないゴミプログラマーはアジャイルには不要
逆に仕様にない事は全て知らんというスタイル
テスターなんていらんよ >>129
ほんとこれ
多くはそれを前提に生産性という集団のアウトプット平均値を下げてごまかしてる
アジャイルなんて出来るわけがない >>126
SI業界だとキツイな。ソシャゲを初めとする自前サービスで食べてる業界だったら問題ないのだろうけど。
それなりの給料を払えるだろうし。 多能工のほうが効率がいい
ただ、それは成熟した工場の話
スキルアップやチームレベルでの効率化が語れない現状では
テスターはスクリーンショットをエクセルに貼りつけるべきだし
プログラマはコーディングだけする。ビルドするなんてとんでもない
SEは設計が終わったら暇だからPGたちの管理やインフラを整える
日本のITはそうやって回してきたんだ
ずっと同じ技術を使い続けるならともかく
プロジェクトごとに違う言語、違うDB、違う開発手法を使うような現状では
1人が複数のスキルを担当するのは教育コストがかかりすぎる
ずっとVBとPHPだけで開発していく覚悟があるなら
ゼネラリストやフルスタックといわれるエンジニアを揃えてもいいだろう
（もちろん言語は他でもいい。ただしRubyOnRailsのような進化しつづけるフレームワークでは目的は達せない） テスターとかいってるけど
テストコード書けよ
イテレーションするのにマニュアルテストなんてやるわけないだろ >>131
ランニングも負荷テストもやんねーの?
キチガイだろ
UI周りの試験とかホント誰でもいいじゃん
これも全部PG使うの?
技術者だって余りまくってるわけじゃねーぞ アジャイルは品質保つの大変そうだね
通常は完成後に1回テストすればいいだけなのに
少し機能追加するたびに全てのテストをやり直しでしょ？
自動化しないとやってられない側面もあるし
逆に毎週のように機能追加や仕様変更があるんだったら
テストコードや自動化の仕組みも更新が必要
アジャイルのテストってどんな手法がベターなの？ >1人が複数のスキルを担当するのは教育コストがかかりすぎる
SI系「教育コストが掛かり過ぎて無理」
Web系「え?出来て当たり前でしょ?」
この差は何なのだ...
いや多くのWeb系は最初から出来る人しか取らず、教育コストを払っていないのも有るのだが。 >>136
ランニングや負荷といったアベイラビリティ要件が必要ならそれが仕様に明記されていることが必須
じゃないとdeveloperはなにもしないね
UIの試験って言っても作りながら要件通りになってることを確認するだけやしいちいちテスターなんて使わんよ
時間かかる試験はdeveloperは設計保証にして必要に応じて外注にするのが正解やな
もしNGがあれば次のイテレーションで改善するスタイル 自動化テスト自分で書くのってそんな難しい？
そもそも自動化テストを別のプログラマーに分割する意味はあるのか
コミュニケーションのコストが生じるだけで良い事無いような気がする テストを自動化するだけで生産性が1/3になると思うんだけど
（テストを書くのは元コードの2倍程度はかかるだろうという前提。ここおかしいなら指摘して）
アジャイルみたいな機動的な開発手法だと致命的じゃない？
テスト書き直しも多いだろうし・・・・
もしくは重要なところだけテスト書いて、他は手動でやってるの？ 短期間で見ればテストコード書くよりマニュアルでやったほうが早くね
テストコードの必要性はイテレーションするからという長期のメリットで考えないといけない
しかもそのテストコードの品質を保つためにも開発にゴミが混じらないようにする必要がある
アジャイルとか無理ゲーやろww >テストを自動化するだけで生産性が1/3になると思うんだけど
>（テストを書くのは元コードの2倍程度はかかるだろうという前提。ここおかしいなら指摘して）
成らない。それどころかテストコードを書いたほうが生産性が高い事の方が多いよ。
分かりやすい例だと起動に時間がかかるシステムでは、修正→起動→確認という何度も繰り返す作業に時間が掛かるわけだ。
そこで事前にテストを書いて置くと、通常単体テストはシステム全体の起動無しに実行できるのでその分、開発効率が上がる。 ゴミのようなテストコードを見つけたら君が何とかしてくれ
ゴミのようなテストコードだと間違っていても通ってしまうかもしれない
コケてくれれば良いけど 単体テスト以降の試験はどうすんねん
フロントエンド側の試験のテストコードなんて書く位なら目で見た方が早いやろ そもそも動作確認ってどうしてるのさ？手動で確認するとか非効率だろ？なのでまず簡単な動作確認用の簡単なコードを書いて、
実装を進める内にそれに肉付けしてテストコードにするんだよ？ 単体テストを書けないというのは
入出力の仕様を把握していなかったり
結合度が高すぎるせいなので
その時点である程度糞コードを排除出来る >>147
フロントエンドも普通に書くぞ。そしてCIツールがコミットする度に実行してくれる。 https://arstechnica.com/information-technology/2014/08/how-microsoft-dragged-its-development-practices-into-the-21st-century/4/
MSは品質保証（QA）の部門は今でもあるが
プログラムで自動化されたテストを行うのは開発者で
QAはより実世界での利用に近い状況でテストを行うって
GUIがエラー弾くかをチェックするとか
そういうのだけならUI Automation使えば良いんじゃない？ >>153
違う、従来のシナリオテスト的な物。
フロントエンドを何で書いているかは知らないが、今時UIテストフレームワークは大体揃っているよ。 >>156
全然Web限定じゃないぞ。独自の仕組みを使ってUIを描画しています!!とかなら別だがw アジャイルってイテレーション周期２週間とかだろ？
その２週間で単体からシナリオまでテストコード組むの？w
実質機能作ってる期間2、3日しか無さそうなんだがwww >>157
マジか？それプロセス跨がって信頼性のあるテストできるような代物なんか？ まともなコード書けるやつより、まともなテストコード書ける奴10人を集める方が難しくねw 一度テストを書いたら何度も使えるんだし
書けるのなら書かない手は無いだろう？ >>158
だから何でそんなにテストコードの実装期間が長い見積もりなの？
テストの仕組みがない状態で仕組みを作るのには時間がかかるが、一度作った仕組みを使うのにそんな時間は掛からないぞ。
>>159
何でUIを実装しているのさ？UIテストの仕組みが無い処理系(and UIフレームワーク)で書いているの？ >まともなコード書けるやつより、まともなテストコード書ける奴10人を集める方が難しくねw
多分、ちゃんとテストコードを書けるエンジニア2人の生産性と、
まともにテストコードも書けないエンジニア10人の生産性を比べた場合、
同じ位か下手したら後者の方が低いぞ... >>164
でも日本の下請けって10人いたら1人は新人、3人は2～3年目、3人は使えない派遣、まともなやつは残りの3人程度やしなあ まともなコード書けるのにまともなテストコード書けないって仮定が狂ってるわｗ junitとかの単体テストまでしか使ってない奴は多いんちゃうか
カスが作ったシナリオテストコードの網羅性や正確性は誰が保証すんねんて話やで
結局、一部の有能なプログラマーが製品コードだけならずテストコードまでレビューおわれて全体の生産性が落ちる姿が目に浮かぶわ >>139
Web系もカスばっかりでしょ
一部の優秀で声のでかいWeb系のおかげでそういうイメージになってんのかもしれないけど Web系というか景気良く給料払える稼いでる会社に集まってるだけじゃね？ >>158
なんか帳尻合わないよね
それも絶対不可能なレベルで合わないよね
～すればできるだろなんてレベルじゃない
普通に作るんだって下記みたいになるわけで
ここからテストいくつ必要なんだっけ？
議論するのもくだらないレベルで不可能だよね
①見積り 3d
②設計 5d
③実装 5d
④テスト 2d
⑤納品 1d
⑥検収 2d
⑦修正 3d
のトータル21dだけど
金が出るのって②～⑤で
⑥～①（次サイクル）の約２週間って
金出んよね? >>172
リアルな話やろ
夢でしか語れないのであればアジャイルなんていらんやろ 自動テストもやれてないという話に驚愕だわ
こりゃ滅亡するわ >>174
自動テスト何日で作るの?
例えば5日で作ったものの自動テストって作成期間は何日の想定?
俺は最低でも5日以上はかかると思う >>138
基本的には「動作確認っつっても画面から手入力するのがめんどくさい、何とかならないか」
を考えればいいと思う
そのために
・UI直下のメソッドではバリデーションと表示だけやる（まぁバリデーションも飛ばしていいかも）
・UI直下のメソッドからビジネスロジック持ってるクラスに入力値全部まるっと渡す
・表示するものはそのクラスからもらってUIにポイ
という作りを徹底する
コントローラとかイベントに中途半端にロジック盛ったらあかんで
そうすれば
・ビジネスロジックもってるメソッドを蹴るクラスを作って
・好きなタイミングでそのクラス蹴れば「手入力」と同等のことが瞬殺でできるし、それ以上のこともできる（気になるテストを3～4盛るとかね）
ということになる
どのくらい厳密にやるかは主義によるが
初めは「マの手入力」程度、オプションでアクセシビリティ系なりSeleniumの導入で検収用テストサポートくらいか
海外だと「クラシックスタイル」と言われる奴だが、基本こっちでいいと思う
別のスタイルとしては「ユニットテストレベルでテストとして厳密であること」くらいだが
こっち工数増える そもそもプロジェクト初期に2日ぐらいで自動テスト環境作ってビルド,テスト環境へのデプロイ,単体テスト,結合テスト,統合テスト,テスト結果の可視化,本番環境へのデプロイを自動化しとく
5日で作るものの範囲をどう想定してるのかは知らんが、作ったら当然テストコードも一緒に書いてるはずだから構成管理に適宜コミットしてれば自動テストはすでに完了してる
5日の途中途中で自動テストが失敗したら、全力で失敗しない状態に持っていく でそれやんのにどれくらいかかるの?
例えば工数5日で作ったものとかなんだけど? 組み込み系だと自動テスト環境作るのはわりかし大変だから、2日とはいかないがシュミレーター作ったり、実機でも電源のon/offも最近はソフトでできるしなんとかなるし、そっちの方が楽 >>178
5日でやった作業に含む
Excelのボックスをイジって見栄え正しいか確認する時間を
コードに回せば足りるよ >>180
いや、日本語不自由なの?
ギリで5日で組んだものに対してどのくらいかかるか聞いてるの?
工数ゼロでできるって言ってるの? >>179
なんでどのくらいかかるか聞いてるのに違うこと答えるの? >>182
なんか、「作る」の前提が違いそうだね。
おまいの「作る」にはテストコードとレビューは含まれていないんじゃない？
こっちの「作る」には当然含まれてる。だから自動化の工数とか言われてもほぼ0でしょという答えになる。 >>183
じゃあそれでいいよ
実装5日でテストレビューも別換算でそれぞれいくらかかるの?
ワンサイクル２週間で回すんだろ?
さっさと答えろよグズが >>184
ふーん頑張って苦しい環境で開発してねー
教えねーよｗｗｗｗ >>185
苦しいのはお前だろｗｗｗｗ
徹夜しても終わんねーぞコレｗｗｗｗ もしくは採算割れだな
まったく利益出してないのに
働いた気になってる典型
数字出してみるとあらびっくり社内のお荷物は君でしたってね
常駐派遣だと月単価で確実に収入あるから利益比べたときに下手すると負けるで
それどころかイテレーション毎に契約してるようなとこは下手したら
派遣の人間の半分いかへん テストコードとプロトタイピングは
アジャイルの必修項目
これも無いのにアジャアジャ言ってるSEってバカ >>189
プロトタイピングは既成のもの使うよ
テスト漏れしたらテストコードもアジャイルの中に居る で?イテレーション１つの具体的な工数はどうなってるの?
純粋な実装5日ぐらいの規模とした場合の話ね >>192
内製だと工数計算しないの?
スケジュール管理すらしないの? >>193
工数は計算しないわ
仕様乗せて？
あいよこんなんでよいかなあ。
で大体一日ぐらい >>176
アニメーションとかデザインワイヤーフレームの確認はどうすんの
そのアニメーション中の割り込みとか目視以外無理やろ >>193
マジでしないよｗ
要望を細かく聞いて、５分で実装。
で、次の要望は？って感じだから。
で、人塊になったところで使用感を体感してもらって、インターフェースを直す。
外注なら１年かかるものが内製ならマジで３日で終わる。 >>199
わずか５分で要求定義から外部設計、内部設計、テスト、運用までいく。
くっっそはやい。 >>200
テストは5分じゃ終わらんよ
テストが長い。 SIerが100人月とか言ってる億レベルの案件も、アジャイルで回せば10人月で終わる
エンジニアの単価を2倍にしても人件費8割減 >>197
ホンコレ
動画プレイヤー周りの処理とかめんどくせー
Mock作ってDependency Injectionとかできる環境じゃないと、自動化できないやん
と思う今日この頃 MSはアジャイル導入と同時にオフィス環境も変えた
他に欠点があってもコミュニケーションがしやすくなるって理由から
プライベートオフィスをやめて
オープンプランオフィスを採用した
でも内向的な人には辛そう あと
ドキュメントジェネレータも
煩い奴には必要かもな ま、ずっと手でやり続けるよりモック作ってDIできる環境作った方が楽だけど
全部手作業でテストはありえないw ここ見ると日本のSIerって何にでもExcel方眼紙使ってて技術力や効率軽視のゴミばかりのように見える
そうじゃないまともな所なんてあるのか >>198
お前がやってるのってアホジャイルだったんじゃね? >>193
横からだが内製の時の工数計算って、ザクッと感じで厳守ってほどじゃぁないなぁ
なんだかんで問題発生するし、厳守してたらブラックな環境になるわ 今の時代、企業の価値はアジャイルやってるかどうかで決まるよ アジャイルやってるくらいで企業価値が下がるわけねえだろタコw >>212
ポシティブと思いきやネガティブってどうなの >>212
企業価値ってお金の話でしょ？
そういうことじゃないんだよなぁ
売り上げは大したことなくても、アジャイルでお客さんに満足していただくことができる
顧客満足度＝企業の価値 >>211
そう勘違いしてる奴等が請負でアジャイルやって炎上してるww >>212
いいや
この様子だと銀行はまず金貸さないよ
利益率どんだけ低いんだよ >>215
アジャイルできない奴の話はしてない
成功してない奴のことをアジャイルとは言わない >>217
アスペか？
>>211みたいな勘違いによりアジャイルをやる事が目的で無理やりアジャイルもどきをやってアジャイルやってます宣言しているバカ企業が多いという話をしているだけだ
つまりアジャイルは糞 バカ企業としか関わりがない奴は、失敗事例たくさん見られていいですね
成功事例を見る機会がないのは可哀想だけど >>219
そうなんだよ
日本トップ10に入る大企業がそのザマだからな
アジャイルはほんと糞
内製の限られた条件だけでかってにやっててくれ 絶対採算割れだって、
他のチームからも苦情くるわ
パフォーマンスだけにしろチーム単価の半分も行ってない開発とか
学生のバイトの延長で始めた居酒屋にも負けそうｗｗｗｗ 学生のバイトの延長で始めた
キックスターターに負けるのが
日本のソフトウエア開発 日本でアジャイルやろうとするなら
客の労働環境下で開発のスペースを確保することになる
ぱよぱよちーんみたいなのから、就職できない底辺がやる仕事みたいな位置づけのプログラマを
そんな極秘スペースに入れるわけがない MSとかGoogle様がアジャイルできるのは有能な契約プログラマーを大量に抱えてるからやで >>139
Sierとか文系専門高卒の素人低知能集団だからな >>224
客先常駐ってよくあることと違う？
xxx業向けパッケージソフトのカスタマイズ専門企業で
働いてるなら知らん可能性あると思うけど アジャイルはウォーターフォールよりマシって物だろ
で、アジャイルが駄目というならそれよりマシな物を考えてみろよ だからこの世にはウォータースライダーとアジャコングしかないのかよ >>187
ウォーターフォールで大きくやってみたら
お客さんが途中で大きめの要件変更を数発やらかし
納期ぶっ飛び確定なんだけど納期遅延はこちらの責任となり瑕疵担保の対象で
損害遅延金支払い確定（あるいは裁判でモメてよくて数か月時間を取られる、運が悪いと1年くらい）
というリスクは減るわね
要件が安定してて瑕疵担保条項の内容がユルいなら
ウォーターフォールでもいいと思うけど
そこまでITわかってはるお客さんならもうシステム入れてるで 糞なのはアジャイルではなくスクラム
XPは歓迎すべきもの
ただしペアプロを除く >>232
クリーンルームもあるで
ウォーターフォールに近いけど極端なくらいコードレビューやるやつ
レビューで通らなかったら手戻り
バグレスを目指すものだけど、予算・納期・人員についてはお察し 常にペアプロって意味あるのかね
たまにならありそうだけど常時とかきついっす >>>237
本義的にはもう片方が「人間lint」になることが期待されている
実際そんなことないんで
OJTの一環でたまにやるくらいでいい気がする >>238
> 人間lint
同等の力ならスッゲー喧嘩になりそう >>239
そこでワイガヤしましょう、相手にも納得してもらえるコードを書け、という思想
たぶん無理ぽ >>241
まぁ無理だよなぁ、宗教だし
ヨーダ形式好きだけどさ、lintで決まってるんだから、それはダメとか言われたらぶん殴りたくなるわ
if (0 < hoge && hoge < 100) {}
とかダメで、
if (hoge > 0 && hoge < 100) {}
とかしないとあかんのだろ
死ねばいいのにとか言うわ 日本のSI業界って本当にこんなアホばっかなの?本当ならその内まじで崩壊しそう。 >>242
コーディング規約の関係で
if (0 < hoge && hoge < 100) {}
か
if( 0 < hoge && hoge < 100 ){}
かで揉めたことがあるわw
その規約は未だに残ってるよ 内製アジャイル最強
受託ウォーターフローは底辺奴隷 みんなgooglelint使ってるものとばかり思ってたわ。
ホント日本ヤバイな Googleなんてアジャイルの世界においては権威でもなんでもない >>239
linqで組んでないからゴミｗｗｗｗ
ラムダ式使ってないからやり直しｗｗｗｗ
ガチで喧嘩になった
ﾊﾞｶｼﾞｬﾈｰﾉ ここfor文じゃなくてStreamAPIでやって
なんでですか？ そっちのほうが速く動くから
C言語野郎はなんでもforで回したがる バカ「こういうとこParallel使ってよ～!ｲﾗｲﾗ」
バカ「レベル低いな～!ｲﾗｲﾗ」
俺「逆に遅くなりました」
バカ「組み直して」
俺「（は?）どのように組んだらよろしいようで?」
バカ「知らないよ!そのぐらい自分で調べろよ!ﾊﾞﾝ!ﾊﾞﾝ!（机強打）」
流石にサヨナラしたわｗｗｗ 同期オーバーヘッドがあるので
何でもかんでも並列forにすれば良いと言うものではない >>223
契約書や要件範囲を明確にしないからそうなる
強気に出れないならその会社のブランド力がなさすぎ >>257
でたーww請負でなんちゃってアジャイルやってアホwww >>257
でもそんな喧嘩腰でアジャイルって意味わかんないよね
その態度なら契約書バシッときってwfでやった方がよくね?
そういえばアメ公が作ったにしてはやたら気持ち悪い手法だよね?
アジャイルって
ちょっと昔の「お客さまは神様です!」って日本みたい アジャイルが媚びるための手法と思ってる時点でセンスなさすぎてお話にならない おまえらってアジャイルなのに予算と納期がつくよね
ウォーターフォールと何が違うの？ 予算と納期はあるに決まってんだろw
アジャイルを何だと思ってんだよアホ 請負でなんちゃってアジャイルやってる企業は己の無知さに恥じるべき >>264
予算と納期は仕様に対して評価した工数から算出するもんでしょ
アジャイルは仕様が変わっていく
予算と納期はどこから計算してるの？ >>263
ウォーターフォールは頭からケツまで全部だけど
小さいアプリを段々でかくしていこうってアプローチでしょ?
まあブツ切りwfの理解でいんじゃね?
俺もそれ以上頭に入らなかった
くだんなくてｗｗｗｗ >>263,
ウーターフォールはシステムに対して金払うのに対して
アジャイルだとそれこそ人月で払うんじゃねーの
まぁ会社それぞれだろうけど >>267
>>268
それだと予算か納期が決まらないよね
例えば50万の人間が12か月だから600万という予算はでるかもしれないけど
納期は決められないよね、仕様が変わるんだから
逆に納期決めたら仕様変更で工数変わるから予算決まらないよね なんか精神論が多い点がこの手法の不味さを象徴してるような気がしてしょうがないな
んでもってイテレーション２週間って割には自動テストからシナリオテストまで全部作るとか言ってるやつもいてキチガイだよね
設計書も書かないのかな?
すべてが２週間の作業の設計書でも記述してレビューして修正するだけで２日は見て欲しいけど
ホントにこれうまく行くんかね?
うまく組めてないときのリカバリも効かない気がしてな >>269
納期までにできることを優先度高い順にやるんだよ
つーか、さすがに普通はある程度最初にざっくりとどこまでやるかくらいまでは決めておくだろ
仕様を変更する場合は、何かとトレードオフになるというだけの話 268=271だけど、
機能毎に予算・工数を見積もり、どの機能をどういう風に組み合わせるかを客に選択させるって～のが一般的だと思います >>273
仕様変更・追加などで客側に明らかに瑕疵があるようなら、金積むない限り当然そうなるわな
見積もりのミスなどの場合は契約次第じゃねーの？
まぁ納期までに云々って話なら、少なくても優先度高いものからやっておけば全部が納期までにまにあう必要はないでしょって～のがアジャイルだからな >>270
スクラムは糞だけどXPくらいは学ぶべき
設計書？時代遅れやで >>274
言ってることが請負だな
スクラムは基本瑕疵なんてものは無い
だって人契約だもの
イテレーション内で予定通り終わらなかったらチームが糞だったと反省して改善していくだけ 納期になってから「システムが動かないから金を払わない」と客が言い出すのがアジャイルだよ
逆に客の立場からすれば「優先度高いところはやりました。全部作るとは言ってないです」って言われるのがアジャイル
移行期間になってはじめてシステムがボロボロだと気付く
開発会社は「アジャイル期間中に実際に触って貰ってフィードバックくれなかったから・・・」と言い訳をして
客は「未完成品じゃないか。我々はテスターじゃない」とキレる >>277
それだからバカな日本企業はアジャイルだけど請負で～なんて糞発想になるんだよなあ
アジャイルはほんと糞やわ >>276
書いたコードが設計書なら誰がレビューすんの?
組んだ通りに動くんだから不具合も設計通りになっちゃうの?
そもそも不具合って存在するの?
テスト仕様書はどうやって作るの? >>276
これを会社で主張した奴には消えて貰おう
脳みそがもう駄目だろう そういやアジャイルって設計と実装とテストコードの関係がよくわからんな
少なくとも詳細設計書なんて作らないでしょ？
基本設計ぐらいは契約時に作ってるかもしれないけど、仕様変更があっても更新しないだろうし >>280
いや要件はあるに決まってるだろ
それは設計書ではなくユーザストーリーのdone条件としてプロダクトオーナーが定義する
設計書といってるのは内部設計の話だ
まずテストコード書いてそれをレビューする
それがテストドリブンって奴だ >>281
ダメなのは時代遅れのお前の会社やろww
詳細設計とか未だに書いてる企業とか存在価値ねーからww ソースコードが設計書だって言ってんだからなんにも無いんだろうな
動作環境とかどこに書いてあるんだろうな?
動いたらジャスティス!? >>235
嫌いというかペアプロって相互支援が基本だがカス通しがペア組んでもカスしか出来ない
これもまたアジャイル特有のそれなりに出来るレベルのやつしかこの世にはいない糞前提 使用ライブラリとか突然のGPLGNUも当然設計書通りだな
要求仕様書
こんなものを作って下さい
設計書
じゃあ、こう作ります
って役割だったけど
客にソースコード読めって言ってるわけだよね?
俺にはキチガイに見えるんよ >>288
プロダクトオーナーの定義するdone条件よりはおまえのいう要求仕様書よりもっと全然細かい
開発するもの全てといっても過言ではない
少しは勉強してから発言せーや
相手にするのもめんどくせー 要求に対して完成品で見せるわけだから客にとってはわかりやすい
ただ、実装しちゃってるわけだから、もし手戻りが発生した場合には最も工数を無駄にするパターン >>289
え?
設計書に当たるものを書くって言ってるの? スクラムはプロダクトオーナー=(請負でいうと要件定義する客)も開発の責任の一端を大きく担う
つまり開発失敗の責任は開発チームだけが原因ではないことを精神論含めで事前に明確にしないといけない
ここが内製や人契約派遣じゃないとうまくいかない理由の一つやな
アジャイル糞過ぎ >>291
おまえの言っとる設計書ってなに？
くわしく教えて 結局、アジャイルって顧客が開発リーダーやってる客先常駐のことでしょ？ 257の発言はWF擁護というか、正しいFWとXPのありよう
要件安定してるならWF。
現実は要件ふわふわで、じゃあどうするかというと、本来コンサル料相当もらうのが筋。
要件定義を一旦fixしないで下流に進むのは追加料金なしナシで変更対応するって言ってるのと同義なんで
ってのが大前提
それをしないのに請負でなんちゃってアジャイルとか言い出すから意味わかんないことになる
アジャイルで準委任契約にするか、WFで請負にするかどっちかしかあり得ないはずねん
で、そんな契約できないお金ない案件なら、そもそもベンダークライアント間のパワーバランスが完全に崩壊してる案件ってこと 詳細設計書を作って客に見せて作るものの合意を得たほうが
のちのち手戻りが少ない場合は詳細設計書を作ることもあり得る。
大抵は要件定義より詳細なメモという程度で詳細設計書ではないけどな。
名前だけ。 >>296
日本は大企業ほどガチガチにルールがあるから企画納期予算を明確にしないと稟議通らんのよ
だからソフト開発において瑕疵が不明瞭な人契約なんて基本出来ない
でもなんかアジャイルって凄そうだからやりたい
その結果請負でアジャイルという謎の開発が生まれる
発注するほうも受ける方もバカなことには代わり無いな >>289
でもxpって調べたら発案者がすでにキチガイで
コイツ、ソースコードが設計書だからって言ってんじゃん
すでに「いや、違いましたごめんなさい」って謝ってるのコイツ さしあたってこのぐらい書かせて貰えれば嬉しいのですが?
って反省文でも提出しないとこのｘｐのバカは一旦死んだほうがいいよｗ >>299
いまだに詳細設計なんて書いてる老害はもう引退したほうがいいよww
もうテストコード書いて自動試験する時代だからお前の出番はないwww テストの自動化なんて認めてくれないよ
結局は人間が納得するか？だから 状態のテスト自動化まではできるけど、GUIになると難しくなるんだよなぁ
結局、手動かよ、みたいな
まぁテスト書いときゃロジックを事前に発掘できるけどね 2年くらい前からスクラムしようぜって言ってる社員が居るけど、そいつ一人しかやる気が無いから試しに導入すらしてないわ アジャイルで儲けましたっていう話を聞いたことがない >>306
お前みたいな観測範囲の狭い奴はどうせ「WFで儲けました」って話も聞いたことないんだろw UIテストの完全自動化なんてやってるやついんの？
出来ても静的な画面だけだと思うんだが APIテストの自動化はやってるけど
UIテストの自動化はまだだなぁ
もう少し時間に余裕があれば取り組みたいけど UIテストが自動化って、ロボットハンドでも使ってるんじゃないかな？
イベント生成する治具つかってもそれは何をテストしてるんだい？
ってきちんと対象把握してないと、無意味なテストになるからなぁ >>315
webブラウザならサーバーが反応しないとか必要な項目だけど、そんなん知らんなんだろうなぁ
あくまでもブラウザが動くかのテストなんだろ？
通常のアプリだともっと事情が違って、連打したり処理中になんかボタン押したりってのが重要なテストになるんだが、
そう言うのってアプリからのトリガーで動くテストだと意味が無いんだよ。 >>317
そうなんだよな
通信中のキャンセルとかもそうだがそういう競合系を自動でどうやるんやろ 画面の遷移が正常に行われてるかぐらいは自動テスト出来るはず
Googleの公式アプリは遷移がなんかおかしい気がするけどテストされてないんだろうか
アプリ履歴から開くとなぜか前に検索で開いたページが出たりとか
一回だけChromeの新しいタブが出てきたし >>317
100%自動化するだなんて極端な考えに走っちゃう人ってまだいるのね 自動化出来ない部分は人に頼れ
ただ技術力ない所や意識の低い所は一切自動化せず最初から人力に頼ろうとする
人力テストに頼る前に自動化されたやり方でバグを防ぐ努力をすべき
CSRFやSQLインジェクション、XSSのような
Webアプリケーションの脆弱性チェックはツールでも出来る
これで見つからなかったからと言って100%安全という訳では勿論無いが
しないよりマシ
二重送信ぐらいは最初から出来ないように作っておけよ >>320
２週間でどうやるんだ?
って話から始まってるから完全自動化でないと辻褄が合わない これ手動でやったらワンイテレーション２週間はその時点で嘘じゃん
話のはじめが完全自動化でやるって言ってたのにそこは手動なんて話が出ちゃうのは話が違うじゃん 誰も二週間で不具合なしの完全版作れなんて言ってない件 は？アジャイルは２週間とかでデプロイ出来る品質のものを作るんだが？ ウチはUIテストも60-70%位は自動化してるなー(対象はWeb,iOS,Android)
手動部分はエンジニアが直接行う。大規模なアップデート時には外部のテスターを使うけど。
あと、2週間でどうやって作るんだ?とか言ってる人はそもそも勘違いしている。
まずスプリントは必ず2週間にする必要は無い。
そもそも実装が1週間とかで確実に終わるプロジェクトだとイテレーションしようが無いだろう。
作業チケットを洗い出す位はするけど。
自動テスト環境の構築に時間が掛かるという話は、
ウチだと必要な開発環境の多くは既にdockerコンテナ化されているので、
新規プロジェクトが始まる時にpullしてきて、プロジェクト固有の変更を加えて完了(大体1時間位)。
まあ、そもそもテストを自動化する技術も経験も無いって所は、
テスト手法と基盤を根付かせる必要があるから大変だろうね。
多分テスト基盤開発というプロジェクトを単体で立ち上げるのが正解かな?
受託系とかで、金が出ない社内プロジェクトは無理って言うのであれば詰んでるけど。 ウォーターフォールで高品質のプログラムを開発するのは神にしか出来ない
必要な機能と工数を一切コーディングせず
設計書のみを使い
一回で推し量る必要がある このスレを見ると技術格差が会話が成立しないぐらい広がっている事が分かるなw テスト完全自動化も嘘だったし
イテレーション２週間も嘘だったし
工数の簡単な見積りすらできる様子ないし
すべてが矛盾に満ちてるね たとえ大きく間違っていても一発勝負で工数を見積もらないと作業を始められない
奴隷商人から奴隷を集める都合があるからな >>334
いや、wfでも不明な箇所は不明にして明確になってから再見積りするように話つけろよ >>333
だからエスアイヤー（笑）混じえた話ではないので >>331
煽り目的のネタじゃなくてマジで言ってるの？
2週間という枠組みの一例を全てだと思ってたり、分解したタスクのポイント見積もりを知らなかったり、
聞きかじった情報に踊らされすぎでは？マジなら技術力以前に思考能力が欠落しているぞ。 UIのテストも自動化している所に聞きたいのだが、皆の所のUIテスト自動化率はどの位？
上にも書いたけど、ウチはWeb,iOS,Androidで60-70%位で、
新規の更にコードベースが新しいプロジェクトだと70-80%位はある。
だた、最近は更に上げる余地が出てきているので運用基準を変えようか検討している所。 >>328
ワンマン内製？ の時はほとんどUI層からのテスト
ユニットテストとUIテストの両者を維持する余裕がなかったので片方捨てた
内製？ というのは……「お客さんにアプリ安く売って営業しやすくして、本業の仕事取りたい」
という理由から社外向けWebアプリと、社内の各部署向けのWebアプリ書いてたから 社外のは営業の人が拾ってきて「ひと月くらいかなー」とか
「早めに触りたいって言ってるから一週間でお願い！」とか
あんまり参考にならんと思うがUIテストにガン振りするモードもあるっちゃある 完全でなければ使い物にならない
だからウオーターフォール
なんだかな 仕様書駆動開発？ が好きならWagby・いんでぶ・楽々あるいはGeneXus使えばいいのに
なんでしないのかが疑問
Web Performerはお勧めしにくいけど（Struts1からSpringへの移行ができたのか承知してない）
単に知らんのか、年100万/人のライセンス料が払えないのか、経営陣の人月商売うまし度が高いのか 1970年代に用語ができた時から既に疑問の目を向けられていた
それがWF
2017年になってもまだ有難がって使っている所があるとは思わなかった もともとのWFは「手戻り」の矢印があったんだけど「手戻り」の図を誰かが消した
……だったけなあ
「ウォーターフォールモデルの起源に関する考察」論文にあったと思うのだが違うかもしれん
小樽商科大学が論文見えなくしたので確認が取れない プロトタイプでアジャイルして
とりあえず仕様確定したら
実働環境にWFしたらええやん 方法論にこだわりすぎるやつは今取り扱ってる問題を見てないことがおおい
知識だけで現実の経験を欠いているために、ものごとの具体的な結果を想像できないのだ
だから信仰のように方法論をふりかざすだけになる 今日のコミットを
テスト仕掛けて定時で上がる
アジャイルの優雅な一日 >>346
それアジャイルである必要あんの？
スパイラルでええやん アプリ屋さん大変そうねw
ゴリゴリの組み込みに来ればいいのに
軍事、航空機、鉄道車両、自動車
作るものが決まらないとか途中で変わるとか有り得ない世界においでよw
単価も楽に倍以上だろww >>345
無駄じゃん
請負酷いことになるよ
次開発にまわして見積りからやってよ >>349
設計書もテスト仕様書も書かんでできたゴミなんか形になるのか? 設計書は神である
設計書無しで書かれたプログラムは全てゴミ >>355
すまんな。ウチは設計書もテスト仕様書も書かないで作ったサービスで爆益やわ
社員一人当たり利益はなんぼだったかなー?海外拠点をを含めて計算しても
SI業界とは比べ物にならならんぞ >>358
パズドラ?
ゲームって意外と取説とかしっかりしてるけどね
ダメージ計算なんて一桁まできっちり出るし OSSは設計書なんて作らない
でもそうして作られたソフトウェアを皆ありがたく使ってるじゃないか >>355
テスト仕様書の内容如何だろうけど、業務系だと、CSV的表現するなら
No, イベント内容, 期待結果, 実施日, 実施者, 合否
1, 商品コードで検索する, 該当する商品が画面下部に表示される, 2017/6/5, 太郎丸 次郎, 〇
2, 存在しない商品コードで検索する, 画面下部に「商品は見つかりませんでした」と表示される, 2017/6/5, 太郎丸 次郎, ×
3, 画面下部に表示された商品をクリックする, 該当する商品が個数画面に表示される, 2017/6/5, 太郎丸 次郎, 〇
こんな感じのテスト仕様書多くね？
たぶんなくてもできるぞ
マトリックスでやってる仕様書はめったに見たことないというか
件数が爆裂して手だと破綻する気はするが >>360
すげードキュメントしっかりしてんじゃん
なんかこれあれば作れるわってぐらい >>362
あれ書いたあとで作ってんじゃ無いの？
実際に動くコードなしでサンプルコードとかAPIリファレンスとか
ちゃんと書ける？ >>359
違うよ。でもゲームも前職で経験あるけど(有名なタイトル)、ゲームこそプロトタイピングの繰り返しやぞ
事前に仮説は立てるけど、実際にテストしてみないとユーザにどの様な物が訴求するか分からないじゃん？
プロトタイプ作成->ユーザテストの繰り返しで設計書とかなにそれ？の世界 >>361
それはお客さんとの約束やぞ
そこに書いてある手順でそこに書いてある動作を保証する契約書やぞ
それがテスト仕様書やぞ
無くて困るのは客だけじゃないで
自分らの身を守るのにも役立ってくれる
手間ばかりのもんだと思ってるなら大間違いやぞ >>364
俺もゲーム開発経験あるけど
ちゃんと書いてたけどね
他社の類似ゲームの攻略本の画面やスクリーンショットの貼り合わせみたいになってたけど
すげーやりやすかった
そもそも一定以上の会社って攻略本の資料を作り慣れてたよ
残業地獄で辞めたけど >>365
申し訳ないけどこれテストとして不完全すぎる
例えば、どの入力項目に対して何の値を取りえるかの一覧表ないでしょ
もっと具体的には「商品コード」が全角半角混在（ER－１０１０１とか）の場合救うの？ 救わないの？ みたいなのが
まるっと漏れてることはよくあるわけで
まあもっと入力値が多かったら「商品コード」と「商品登録日」の組み合わせテストとかさ
どっちかっつと「お客さんとの約束」じゃなくて
「テストの不備をテスターに押し付ける（外注なら値下げさせる、社内なら怒鳴りつける用）」として
機能する方が多い気はするんだが、どうか？ >>366
コンセプトを説明するパワポ数枚とかではなくて？
そもそもゲームに限らず今時のサービスは、システムがA/Bテストの結果とかでUIを中心に刻々と変わって行くので、
詳細な設計書を書いても直ぐゴミになる。 んーなんだったらコードでこのテストやりまさって明記してぶん回した方が早いというか
手入力うざし 最近はBDDって言って自然言語に近い形式で書かれたテスト仕様書から
テストケースを生成できるツールがあるらしいので
それを受け入れテストに使え
他のテストは普通のやり方で書けば良いんじゃね >>355
設計書ないと作れないゴミプログラマーはアジャイルにはいらないんだよなあ そのうちだんだんそんな詳細な設計書を作るのが面倒になり
設計と実装の乖離が始まる
設計書を作るとしても、詳細には書かない
自動生成ツールに頼るなどして
そのような手間を掛からないようにしろ >>367
そんな話は自社の中の話じゃん
俺がしたのはお客さんと自社の話じゃん
関係ない話をされても困るｗ
でもあったほうがテストが漏れてることがわかるだろ?
「あ、コイツ全角数字のテストやってねーよ」って
何もないとなにもわからんよ
こういう資料を無駄だと思う奴は資料を活用できてないんだと思うね
客も自分らもまあ客がバカだと開発もバカになっちゃうんだけどさｗ >>373
ごめんやけど書類を売るのが仕事ならそれでいいんじゃね？ >>374
まあ当然書類も納品対象だよね
同時に検収対象でもある
これでOK出したら客も逃げられんし知らんふりもできん
アジャイルみたいな形だとおそらく客と喧嘩になったときになんも資料がないとなにも身を守る物がないで? 検収通ったって瑕疵責任が無くなるわけではないけどな
アジャイルは人契約だから瑕疵なんてありませーん
それこそレビューでOK貰ったら終わり >>376
それはアジャイルじゃなくて単に
派遣契約と請負契約の違いだろ?
派遣契約は休み時間まできっちり
向こうにダメ出しされるで
請負契約（偽装請負）はその分気は楽だけどな
仕事ないときは半休って言って帰っても有給減らんしねバレなければｗ >>377
だからアジャイル自体がそもそも請負でやる仕組みになってないから請負と派遣の話でもありWFとアジャイルの違いでもあるわけ >>377
ごめん準委任契約知らん？
客の指揮命令系統に入らない、報酬は指定期間ごと、
「xxx業務に関する自動化の要件定義書」が期限までに提出されること
みたいなやつ >>379
それアジャイルできんの?
パクられたときちょっと言い訳苦しくない?
無理だと思うよ アジャイル組はちゃんと用語集つくらないから
勘違いによる手直しも多いんだろうな >>381
これ偽装請負じゃないよって言っても言い訳できないよね アジャイルやってるとこって遵法精神が薄いよね
経験則だけどね >>384
準委任は成果物の納品が必須じゃないわりに、客の命令に従わなくてよいというもの
成果物の性質が未定義か、未定義箇所が大きいか、追加の変更が結構あると予測されるか、の場合はコレ
ひどい時の対応として「BTS鯖はこちらで用意し、要望あらばチケット切ってもらう」ということにはなるかも
偽装請負って、事業主が客の命令指揮下に入っているけど雇用契約じゃない（労働基準法適応外）ってことでしょ
タイムカード必須とかなんちゃら部長の指示で日報書かされるとかもアウトだし
ナニナニ課長が「前の話なんざ知るか、もっと早く出せぇ」と言ったらその指示に従う必要があるかないか
それだとこっちじゃなくて相手がパクられる？ んじゃない >>386
まあアジャイルじゃ無理だよね?
だってモロ指示出してんじゃん
なんでこの話題出したの?
大丈夫だと思ったの? 客の命令に従わない上に成果物も出さない
どうやって金貰うの？ ・アプリがあんたのビジネスで本当に使えるもんになるまでお付き合いしますが、変動費がどうなるかは最悪その時次第
という話か
・事前に合意した通りにしかしませんよ、使えない？ 知らんがな、ただしリクツ上一発納品で変動費の予測は容易
実際のところ絶対に要件変更はねじ込まれるが
という話か
スタイルだろうが、前者を選ぶ奴がいたっていいだろう
客にも選ぶ権利はあるだろうし >>391
事前に取り決めた月額、もしくは一定期間ごとの報酬
ごめん本当に知らんかったんやな 仕様変更したら作ってたコードは全て捨てないと
真のWFとは言えない >>391
派遣しかしたことないからわからないのかな？ >>386の言ってること自体は正しいだろ
派遣以外の方法の業務委託先に対して日報の強要や残業の強要は偽装請負で法律違反
現実がどうあれその意識がないのは色々問題やで ぶっちゃけ客と喧嘩することを前提にして仕事するの嫌じゃん
相手もそれを望んでるなら、それ相応の説明すればちょっとアレな契約でも飲んでくれる
あとはやるだけでいいでしょ ぶっちゃけSIerって、作ったシステムをユーザが業務の中で運用し効果を発揮させる事が目的ではなく、
とりあえず納品する事が目的になってるよね?そのシステムが実際に効果を発揮するかは別問題と。 >>399
それなら地獄の道しかないか
「要件定義は自由だけど納期確定」
逝ってよし（それ本当に逝くよねって意味で） 月ごとで切っていこう系の人には問題ないけど
一発勝負の人は死ぬわな >>398
それが海外勢から非効率なIT投資とバカにされる所以だからな 仕様が変われば納期も伸ばすし
WFはすべてガチガチと思ってる奴多すぎなw >>403
それを本当に無制限にかつ迅速にできるんだったら本質的にはアジャイルと変わらんなw
因みに日本のSIerが海外(特にアメリカ)と比べ競争力があると思ってる人いるの？
競争力が無いと思っているのであれば何が問題だと思うのさ？ >>398
ゴールドラッシュでツルハシを売ってた道具屋に同じこと言ってみろよ >>404
競争力ないと思う
原因としては3つ仮説はある
マの側が「あんたの仕事を厳密にすべて把握してるわけではないから出来たもののすり合わせは必須」
というのを相手に納得させられなかったのか
客の側が「めんどくさいからとにかくこっちの仕事楽にするソフトくれや！ マジカみたいなのすら書きたくないわ、アプリを出せ！」という
思考放棄か
それとも別の理由かはわからんが、相当に低レベルのところで躓いてる気はしている >>405
あん？ツルハシは採掘者の役に立って機能してたんだろう？
それとも不良品を売ってたのか？ 別の理由は結構あるよ
「現場としてはシステム導入なんて望んでないけど
経営者がIT好きでシステム入れるって話になったので
現場的には担当の企業にはコケてもらわないと困る」
というピンポイントの仕事とかな
「社長に依頼されたプログラマーなんすけどね、なんか書かなあきませんで」とヘラヘラしてたら
現場のほうでゲロってくれるから、その場合こっちは費用負けて撤収、二度と関わらんことになる 日本が競争力ないのはコンシューマ向けの話だよ
そりゃ英語版を出さないから市場は限られるよ
英語、中国語を出さないと日本人の人口の壁を越えられない コンシューマ向けの方が検討してるだろう。主にゲームだけど。
SIerの海外進出はNTTデータが大失敗してる。 >>410
DoCoMoの失敗と混同してないか？(似た様な物？)
NTTデータはDell Systems Corporationを買収する勝負に出たが、まだ失敗とは言えない。
大統領選の結果とかで幸先悪そうな感じになってる様だけど... 日本のSIerは異質だからなー
インドの様なオフシュア拠点の国でもないのにベンダー数も無駄に多いし色々無理はきてるだろうな
雇用規制があるからUSの様にドラスティックには行かないが
ここ10年ぐらいで色々変革を迫られるんじゃない？ >>393
でもこれでアジャイルやったら違法じゃん
お前犯罪者だよ 奴等の作るものの品質は
これでどこをテストしたんだよ?
ってぐらいとにかく動かないじゃん
有名なソフトは概ね動くが（それでもどうしてこんなんで止まっちゃうの?は多々ありだよね）
業務用マイナーソフトは全く動かない >>404
アメリカのエンプラが競争力あるかどうかなんて知らないw
海外とじゃなくて国内で競ってればいいし IT業界はなぜ法律を守らないのか？
先進的なサービスで法整備が追いつかない面もあるのは理解できる
雇用についてはもう肯定的な解釈ができない >>420
データのそこそこ優秀レベルの奴よりお前のが劣ってるだろ何言ってんだw >>421
いやそれはデータをわかってないよ
どんな優秀な奴も無能になれます!
コレ 日本のプログラマ＝偏差値４０未満、Fランク、まともな就職が出来なかった奴がタクシーかプログラマかで選んだ先、基本的に奴隷派遣。
世界のプログラマ＝基本数学、物理学、生物学などの専門家が、手段＆表現方法としてプログラミングをやる。 上が月収18万で
下が月収15万だね
ベンチャーは給料が激安だし >>423
日本も世界も平均は似たようなもんでしょ >>425
海外はコンピュータ科学の学位か実績ないと相手にされない >>426
日本は学位も実績もなくても相手される？ itの実績って何?
関わったプロジェクトが全部失敗とかオカルトit部門でトップに立てる? なんでもいいから底辺文系、専門卒、高卒をかき集めて人月としてアサインして安い給料で働かせて、中抜きをする。これが正しい日本のSIです。 内製アジャイルを超えるものはない
システムの維持は考えない
都度、どんどん作っていく つまりは適材適所だから
WF命請負は仕様書作るのに
アジャイル採用してみたら？ >>429
メンバー割りで一人当たり50万の利益を毎月上げてりゃ誰も文句言わんやろ 毎月一人50万の利益って給料分にもなってないじゃねーか
SIerってどんだけ薄給なんだ... 別に素晴らしいシステムを作りたいわけじゃない
楽して食っていけるのがいいプロセス とりあえず資金調達したベンチャーでも20代後半、年収500-600位が目安だぞ。
っていうかアーリーステージのベンチャーこそ良いエンジニアを集めないと即行き詰まるし。 >>435
利益と売上を一緒に語ったらダメじゃないでしょうかね？ いや利益50万で少ないだろう。売り上げだったら終わってる。
給与+厚生年金会社負担分で50万以下なのかよ... 時給換算してコンビニバイトより高ければいいかな
ずっと座ってられるからコンビニより楽だし 家でもコード書いたり本読んだりして技術力上げれば給料も上がるのはわかるけど、正直そこまでしたくないww
のんびり開発したいね >>438
良いエンジニアはそれでも給料落としてるからな
自分の能力の自信があって、失敗しても食うには困らないって奴が挑戦するし >>444
だから棲み分けできてるじゃんw
ガツガツしたのが好きな人は、ガツガツした会社で頑張ってるんでしょ？ >>440
売上(1人月) - 人件費(給与、社会保険など) = 利益 だろ？
間違ってる？ ある意味SI業界ってワーキングシェアが実現されている業界だからw >>445
大体給料低いんだよな
そういうとこって
頑張らせる割にはケチなの もし本当に構造変化が起きちゃったら、効率化されて食っていける人減ると思う
一人当たりの収入は増えるだろうけど この業界まだまだやらなきゃいけないことてんこ盛りだからどうだろうな? アシモフのロボットの世界が来るから大丈夫
Googleがマシーンを作成中 月収30万でいいから死ぬまでのんびり働けるといいな >>431
維持はあるよ
ただ、内製のほうが極端なスライドができる可能性が高いってこと
予想に反してアプリが育ちすぎて（＝予想外に高評価のを何年か回してて）Railsじゃ手に負えなくなった
移行はC#かJavaでいく、みたいな奴
大規模に化けるって予想できるなら人員確保の面でも定評があり
ミスりにくい言語を選ぶでしょう？
システムが一時的に（大きな分類では）二チームにばらけることがあり得る
ペイしてるなら「保守チーム」と「移行チーム」の二部隊構成になるんじゃないだろうか
動かないもんをボンボン出すこたぁ許されんと思う、どこでも
動くものと、もっと改修が容易な奴だけど開発中、の並列 内製が一番プログラマを評価してくれるんだよ
だってプログラムを作ることで目の前であっという間に作業の効率化ができるってのが目に見えて理解できるから
目に見えないところで現場の不満爆発のソフト作ったって評価なんて得られるわけがない 内製出来るだけ
プログラミングの閾値が
下がってんだよ >>453
あり得ない妄想なら、そもそものんびりだって働きたくないな いま月収30万でのんびりやってるから、こんな感じが続けばいいなってこと アジャイルで開発してます。とか言うの恥ずかしいよね？ >>460
何をもってアジャイルなのか見解がバラバラだからビジネスで出すのはやめたほうがいいかも アジャコングが開発していますとか、アジャコングを開発していますとか、アジャコングに開発されていますとか。 MSもアジャイルやってるから別に恥ずかしくない
反対に未だにドヤ顔でウォーターフォールで開発してます( ｰ`дｰ´)ｷﾘｯっとか
言ってる奴の方が恥ずかしい アジャイルってのは、スマホアプリとかみたいにフレームワークがしっかり揃ってて、機能実装だけをひたすら行うだけの開発でしか使えないんだよな。
新規ハードの開発でデバイスドライバーも無い様な状態からじゃさすがにアジャイルは無理だからなぁ
そこはウォータースパイラルでやって、アジャイルっぽい方法に見せる事くらいが関の山 仕様が決まってればアジャイルする必要はない
逆に言うと決められない奴がアジャイルにすがる みずほみたいな巨大なプロジェクトをアジャイルで成功させた事例教えて 研究者が自分でコードを書く
セルフアジャイルが一番早い >>471
逆、だめぽみたいのこそ、アジャイルのほうがいい。
というか、もともとは小さいシステムだったはず。
どんどん、新しい契約方法を作っていって継ぎ足し継ぎ足しした結果、ユーザーがシステムをぶん投げて、仕様を覚えておかなくていいなんて
錯覚を犯したのが今回の主たる原因 >>473
仕様をわかってる人がいないならもうプロセスの問題じゃないような
> だめぽみたいのこそ、アジャイルのほうがいい。
なぜアジャイルの方がいいの？ >>474
客(やりたいことを指示する人間)が仕様（契約内容）を理解できてないのを理解できるからｗ だめぽ職員「プログラムから仕様を起こして」
プログラマ「それって・・・銀行員は契約おぼえてないって自白してますよねｗｗｗ」
銀行員とかプライド高そうだから発狂しそうｗｗｗ >>471
まーありえないね
そもそもスクラムは6～10人くらいを想定していたはず 100人で一つのモジュール作るとかどうやっても無理じゃね
どうすんの？ 100人で一つのモジュールとかどんな方法でもクソコード確定だろ 実際のところ、みずほってどうしてあんな風になっちゃってるの？
政治的問題で色々あったのは想像できるが。 まあやっぱり俺らが想像するより遥かにでかいんじゃね?
機能の目次だけで100ページいくようなアプリと対面すっとやっぱりこれまでの自分の方法が通用しない場面って出てくるよ
オブジェクト指向と相性が悪いな
クラスの枝葉の１つ１つが重要であった場合にトップダウンで作っちゃうと身動きが取れない
なのでざっくりクラスを作ってそれが保持してるのがこのクラスで・・・
なんてやると必要な情報に全くアクセスできない 世界有数の経済大国である日本のメガバンクだからね
ここにいる意識高い系じゃ手も足も出ないだろうね だからってメンバーを全部パブリックにしたりとかしたら
オブジェクト指向の意味ないじゃん。
カプセル化はオブジェクト指向の重要な概念の一つだ。 既存のライブラリ？で
どうやっても目的の処理をカスタマイズ出来ない時は
もっと細かくカスタマイズ出来るライブラリを使うか
自分で書くしか無いでしょ
それか、
そのライブラリのソースを少し書き換えれば解決するなら
作者にプルリクエストやパッチを送れば良いんじゃない？ スパイが入り込んでるんだろ
何をしたらシステムがぐちゃぐちゃになるか知ってるやつら 1つのモジュールを100人でとか
どっちみちやらないんでしょ？
じゃあアジャイルとやらで良いじゃん
何か問題ある？ >>487
いや多分それなにもやらんで金もらえるわ 百人で作るなら、100のモジュールに分ける。
話はそれからだ。 モジュールを分ける前のシステム設計が糞だったらどうにもならんな
おそらくそれがみずほ みずほのは仕様書からコード吐くジェネレータ使ってて結合テストコケるとか
とても意味不明 ジェネレータの雛形になるコードがデシジョンテーブル(直交表でもいい）全件網羅程度の品質すらなかったとか
勧銀と富士がもめてベンダー間の仕様が微妙に違うとか
そんなのだろうか >>492
結合なら普通だろ
単体でこけなかっただけまし みずほのかしらんけど
F通のワークフローからコード自動生成するシステム使わされたことあった
あまりにも生産性が悪すぎるせいで、みんなファイルコピーしてハッシュをいじって成果物作ってた
自分のとこもツールの吐くXMLを自動生成するツールを作るという意味不明な状況に
条件分岐は小さな設定ウィンドウの奥深くに隠されてて
注意深くひとつひとつウィンドウを開いて確認する必要がある 反面、建前だけ改善案を吸い上げて
それをかたっぱしから握りつぶす会社のシステムは上手に出来上がってる。
スパイに騙されでもしなけりゃこんなもん誰も使わない
スパイじゃなかったらF通がスパイ >>494
ごめん結合でコケるとかないわ……プログラマーズテストの時点でつぶしてないとか…… 不実は天才こじらせてよく訳のわからないもの作るんだよな
つかまされる側もどうかしてるが あのとき現場にいた奴いるか
なんかのキックオフの時、開発主任だかなんだかが
「会社の99.99%が３０年以内につぶれるんです」
「はっきりわかる違いはすぐ追いつかれるけど、なんだか分からない差はなかなか縮まらないんですよ！」って自慢気に
つまりは権力者に付け入ったり、国を売り飛ばしたりして
外部から便宜を図ってもらってるんでないか
そいつのテンションがやけくそすぎて当時からそういう感想しかなかった >>482
あそこ勧銀と富士がいまだに政治闘争してらっしゃりはるうえ
MUFG程度のわかってる情シス部隊が内部にいるわけでもないから
いろいろきびしいかもしらん まあもう入社した時から失敗続きで
負け犬根性細胞でしか構成されてないよなあの周辺にいる奴らって
成功体験なんて人生でしたことあるんだろうか? 日本は仕様書至上主義者が多いのでアジャイルは導入出来ない 仕様書作成工程がないとSE様の仕事ないだろうが。
詳細設計完！ＰＧ募集(～７末)
あ、これは無理だな。案件情報だけで状況がわかってしまう。 >>505
そうは思ってないさ。
ただ、仕様書を書かない馬鹿だけが
アジャイル賛成なので、
結果としては同じになる。
お前も馬鹿なｗ 詳細すぎるガチガチの仕様書はどっちみち不要
そんな物書いてる間に作れてしまう 作るだけならできるだろうけど、
メンテナンスはどうする？
作った人が退職したらどうする？
そんな簡単なことさえ考えられないのは
あまりに馬鹿過ぎる >>510
詳細過ぎるガチガチの仕様書が、その問題を解決出来るかどうかは疑問
経験上、工程範囲を越えて詳細過ぎる資料は誤り率が高くなるので、誤情報から正しい情報を選別する作業をしなければ役に立たなかった。
無いよりマシだが。
詳細過ぎるガチガチの仕様書よりは、ちょうど良い粒度の仕様書の方が良い。まあ、当たり前だけど。 >>510
極端な話だけど、ド素人が仕様書を見ることによりJavaのコードを
改修できるようになったとか、そんな話聞いたことない
改修できる程度にわかってるなら仕様書なくてもできる >>510
外注しても同様のことがダメポで起きたわけで・・・・ 仕様書があるからこれ見て改良してねと言われてまともな仕様書だった試しがないわ OSSから開発技法を学べ
詳細過ぎる仕様書なんぞより必要なのはOSSのような
APIリファレンスや
使い方を簡単に示したサンプルコードや
テストコードだ
詳細過ぎる仕様書なんて用意しても役に立たない >>515
書きたきゃ勝手に書けよwwww
何わけのわからん事言ってんだお前w >>515
診療報酬をOSSの説明書のようにしてみて >>512
仕様がわからないとなにが正しいのかわからんだろアホw
仕様書がなくてどうやってテストを起こすんだ？コード見てテスト起こすの？ >>518
バグのない仕様をどうやって自然言語で記述するんだ？ 富士通ってソースコード日本語訳したような仕様書作ってんの
それは流石に狂気の沙汰 >>515
だから、詳細過ぎる仕様書、って定義した段階で悪い要素を仮定するんだから比較にならないんだよ >>518
仕様書がなければ仕様が分かる人に聞くことになる。
仕様が分かる人が発注者の代理の代理の代理の代理くらいまで権限と判断力があれば、そこそこなんとかなるかもしれない。 WebのAPIは仕様書がある
ブラウザ間で違う動作をしたら困るからな
ただ全てを網羅した完璧な仕様書が出来上がってからAPIを実装しているかと言うと
全くそんなことはない
まず実装が作られてから詳細な仕様が書かれるだろ
大体どんな機能が必要かコーディング始める前の段階で全て分かるわけ無いじゃん
APIの実装終わった後すら機能が追加され続けるし WebAPIのような不特定多数がいろんなアイデアを追加していくものは
時間の経過により機能が変わっていく
ただ、俺らが作っているアプリのほとんどは一度作ったら一生直さないものがほとんど
いや、直し続けてるよという主張もあると思うが
それは最初に間違って作ってしまったものを正しい姿に直しているだけだ 書かないで作ったものより書いて作ったものの方が数段レベルが高いな
ドキュメントもソースも >>529
ゴミのお前らが作ってるんだからそれはどうしようもない 業務システムでも同じじゃね？
100個ぐらいの関数で構成されたプログラムを作るとして
アジャイルならこのようにして最初から詳細仕様をガチガチに固めない
1. テストを「一つ」書く
2. 適当な実装を作りテスト失敗を確認
3. 実装する
4. テスト成功を確認
5. 1～4を100回ぐらい繰り返す
6. 詳細仕様書を作る
共通APIか欲しいとかで詳細仕様書が必要になり作るとしても、まず一つの実装を作り実際に動かして
ある程度必要な機能が定まってから作る
こうすれば仕様書を何度も書き直すのを防げる
仕様通りか自動的に確認するためのテストスイートももう最初の段階で用意されてる
これに対してウォーターフォールは
仕様書に必要な関数100個を書いてから（そもそも実際にコーディングしないでこれは困難）、
テストと実装を100個分作る
仕様変更があったらまず仕様書とテストケースを書き直さないと再びコーディングに入れない（怠ると仕様と実装が一致しなくなる）
どちらが効率良いかなんて一目瞭然だろ 皆さん、これがFuzzy Test Driven Developmentですw >>531
それってオール成功ケースだろ?
ところが60-80番までの仕組みは他と異なり
すでに作成済みの1-59までも修正が必要になった
ってときwfは辻褄を合わせるから1-59の修正は発生しないよね? >>533
えっいつもどんなクソコード書いてるの・・・ WF信者は仕様書が完璧な前提で話しているが
そもそもそんな完璧な詳細仕様書を一発でなんて無理でしょ？
関数一個追加削除するのにも出戻り発生して効率が悪いだけだ 実際作ってみたらこの設計やっぱ駄目でした！ってそんな珍しい事？？ >>537
完全にダメってのはまずないだろ
手戻りは出るがなおせるレベル お前らの言ってるのは仕様書じゃなくて詳細設計書なんだよ
なんでそこで微妙に盛るかなw WFで詳細設計をするのは実装寸前でしょ？
派遣集めて規模が膨らんだあと 詳細を書いて細部項目を網羅しないから
あの引数が足りないとか、この値まだできてないとかいう問題に
実装中にぶち当たるんだ 詳細設計って関数の設計までする？
簡単なフローチャートとIOまわり程度だよ フローチャートなんてものをまだ作ってるのことに驚きを隠せないwww だいたい詳細設計してないと他人と分業できんじゃないか
機能のインターフェースどうすんのよ
一人でやっても昨日の自分と意見が合わなくてしばしば破たんするのに W3CのAPI仕様書にフローチャートなんてもの出てこない
あれはプログラム書けない人向けだ SIerは適当な仕様書作ってあとは下に丸投げでロクにレビューもしないからそれで成り立つよ 仕様書っつっても、例えば「入力値・出力値をデシジョンテーブルで全件網羅」
じゃなかったらそれ仕様じゃないじゃん、ただの打ち合わせ資料
確実になんか漏れてる
直交表みたく「要素的な意味で固定」のブツがあるなら複数個を1コにすることあるにせよ
業務系の仕事でそこまでやってるのは一件も見たことない
厳密じゃなくていいんでしょ？ なら仕様書いらなくね？
って思うんだが それはテスト仕様書だ
そのデシジョンテーブルを渡されてコード組めるか？
本来の意味をまたそこからデコードして解釈しないといけないとか
勘弁してください >>553
業務系じゃなくていいならやったことある
仕様書書くなとは言わんけどお漏らししてる自覚は持たないと
テスト工程でビッグバン（死ぬ方の）するかも
>>554
プログラミング言語系開発の案件に関わったときに覚えた >>181
ロジックの複雑さによるし
入力の組み合わせにもよるし
5日というのが基準じゃないだろ
5日かけて糞コードしか書けない奴
1日で多機能大規模なコードを高品質書く奴
色々 仕様書って聞いて関数の仕様の羅列をイメージする奴がいるなんて、話が噛み合うはずもないな >>558
「関数の仕様の羅列をイメージする奴がいるなんて、話が噛み合うはずもないな」
って言われても
それ、仕様（入出力・サイドエフェクトの網羅）じゃない
としか言いようがないというか「俺の言いたいことを察しろ」ってならたぶん企画書やで
企画書なら絶対にすり合わせが発生する
その辺の意識があるんなら構わないと思うけど……たまにいるでしょ、俺の文章は完璧だっつって
文言に沿って表書いたら漏れまくってる人 人文学的な意味での仕様っつったらたぶん「なんでこうしなきゃいけないのか」の理由の説明になると思う
清水義男の説明は「そういうのでいいんだよ（孤独のグルメ的表現）」ってなるが
あの水準の「自称」仕様書は見たことない
「お客さんはプリンタのインク切れでイラっとしたことがあるから、インク切れ検知機能つけろと言った」
みたいな、あの本の説明
ああいうのが分かるとすげぇ楽 清水義男じゃなくて「吉男」だった
[入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか？
に記載がある要求仕様なら文句出ねぇと思うんだが、この水準のはみたことない あるいは（旧）スターロジックの「マジカ」
コードジェネレータ開発してた企業が「あ、お客さんは自分で何してるかわかってないわ」と気づいて
業務フローと、そのフローができた理由を簡単に書けるカードを考案した
そういう所まで言ってるんでない自称仕様書にはウンザリしてんだよ
自分自身の失敗もそりゃ含むけどさ、だから強くは言えんけど 全般的にイミフなお客様なら短期にリリースをやる方式で対応するしかない
よく訓練されたお客様なら仕様書でキッチリやるほうがベター
くらいのことを言いたいのだが、全部「仕様書駆動」とかだと、前者が相手の時（最悪）裁判になるじゃん
ンなの面倒だし嫌だわ だいたいの場合、よく訓練されたお客様はいない
訓練されたお客様だと「DebianのJessieで」とか言い出すらしいが……俺は見たことないし
物流と小売だとえげつない人はいる
システムの良しあしでしか差がつけられない世界にはそういう人材がいるわけだが
まぁすげえレアだな
だいたいの人はふわふわだし、そりゃ当然だから、使ってもらってすり合わせ（契約は月額方式）のほうがたぶん楽
相手が飲まないで「要件は後で変更可能だけど仕様確定してて」系のアレは、もう俺には無理
24耐 → 3時間寝る → 24耐が数か月くらいは年のせいでムリ
「まず二週～ひと月を区切りとしてbeta1を触ってもらって、レスポンスをもらったらbeta2で練り上げる」を
アジャイルというならアジャイルなのかも知らんが
ケント・ベックが言うようなアジャイルはやってない DBのテーブルだけはキッチリ1フィールドも漏らさず書いてもらわないと困るな
idとかキーになるものがフワフワしてるのはこまる
作ってみて帳尻を合わせる形でこれを合わせるのは危険
こっちではid+日付でやっててこっちではidのみでやってて
とか破綻した設計でも表面化するまである程度動く
詳細な設計書なり仕様書なり作らないと絶対にできないと思う >>568
fixしないと
テーブルAのデータでテーブルBからデータは取得できるけど
テーブルCのデータだとテーブルBから取れるデータと取れないデータがあるね
なんて状況になるよ アジャイルってWBSもないんでしょ？
このプロジェクトいつ終わるの？
って聞かれて
なんとなくこんぐらいですとか答えて予算つくの？ アジャイル開発の得意とする状況
クリティカルではないシステム (顧客の業務に重大な支障をきたす可能性がなく、人命に関わらないシステム)
熟練した開発者が参加する場合
開発中に頻繁に要件が変わる場合
開発者が少ない場合
混沌とした状況に対しても意欲的に取り組む組織的文化
計画重視開発の得意とする状況
クリティカルなシステム (顧客の業務に重大な支障をきたす可能性がある、もしくは人命に関わるシステム)
経験の浅い開発者が多い場合
開発中に要件がほとんど変わらない場合
開発者が多い場合
秩序を重視する組織的文化 >>549
詳細設計をしないことと詳細設計書を書かないことはイコールではない アジャイルは上流が裏切ったら下流は死ぬ
身を守る術もない >>553
仕様書からテスト仕様書を間違いなく作れるか？って話じゃないの？
仕様書で定義されていないことは、どう解釈・実装しても正解！ってことに出来れば、WFモデルも成り立つんだけどね～。
日本は下流工程で忖度を求められるから アジャイル：間違っても直せばいいよ。時間切れになったら完成しなくてもいいよ。そもそも完成が定義されてないよ。
ウォーターフォール：完成しないと金払わないよ。納品後も気に入らないところはバグとして修正させるよ。
アジャイルって開発者に有利すぎじゃね？
発注側がアジャイルを選ぶ理由って何かあるの？ >>568
アジャイルだってイテレーション内ではfixさせるでしょ
次のイテレーションで変わるかもしれないけど >>576
その定義だとウォーターフォールが開発側に不利過ぎて、請負える企業が減った。
顧客が望むものであろうがなかろうが完成したと宣言して、あとは裁判で争う能力があるところしか残らなかった。 テーブル構成が変わったらSQL書き直しでしょ？影響範囲でかすぎない？
チューニングも無駄になる可能性あるし・・・ >>570
アジャイルの方がいつ終わるかは明確でしょ
予算が尽きたら終了
アジャイルが不明確なのは何が出来上がるかだよ
ウォーターフォールは何が出来るかは明確
いつ出来るかとそれが本当に欲しかったものかは不明確 >>579
変わったら影響範囲が広過ぎるのは、テーブル定義だけじゃないんで、そういうリスクの管理のうまさがアジャイルにおける開発能力の差になるんじゃないの？ >>566
フワフワしてるが困ると思うなら、重要なタスクとして含めて最初のイテレーションで解決する
もちろんフワフワしていない事をテストでも保証する >>582
アジャイルだとフワフワしてることに疑問は持たないと思うな
この仕組みで1-59を作ってるときに60-80の疑問を持つことは不可能よ イテレーション5のテストでイテレーション1,2,3,4の不具合が出て来たらどうすんだ?
これを修正しないとまずい的な
結局wfと似たようなモグラ叩きになんじゃね?
wfでデスマになったときって開発自体は終わっててあとは大量の不具合修正だろ?
優先順位付けて逐次修正ってなんかアジャイルに似てるじゃんｗ >>583
1-59の範囲でフワフワしている事を証明できるテストを思いつけなければ対応は不可能だろうね
でも、ウォーターフォールからアジャイルにやり方を変えたからって、人間の能力が変わるわけじゃないんだから、フワフワしてるなって感じれる人は感じれるでしょう。
疑問を持つことも可能
イテレーション期間内に具体的なデメリットを示せない限り、対処ができないというだけ ところで、フワフワしてるって何？
定量的に説明してくれないと、影響が分からないよ。 要件が頻繁に変わるならいずれにせよリファクタリングが避けられない
その場合はアジャイルの方が向いてるんじゃね アジャイルでも統一した方針を作る必要はある
会議で擦り合わせの出来ないコミュ障にアジャイルは難しい 各々が好きにコーディングするだけなのは
カウボーイコーディングと言うらしい DB設計もアジャイルに変化していくのがアジャイル
逆に言うと、DB設計が最初に決まるならそのデータを操作する機能も決まるので、WFでもなんでもいいよw
少なくとも、データ中心の業務アプリにおいては 要するに、難しい事は分からないけどとりあえずコーディングしたいです！ってゆーのがアジャイル 誰もカウボーイコーディングの話はしてないのにどうしたんだ急にコイツｗｗ >>594
テストもイテレーション1から全部やり直しだね!
でもお客はアジャイルだから（笑）で出してくれるんだ? 流行りの言葉使わないと仕事来ないよな?
アジャイル! >>598
ウォーターフォールの場合は一つでも仕様変更があれば最上流からやり直しだけどね やり直しするのが正しいに決まってるじゃないか？
プログラムよりドキュメントの方が難しいんだ。
それはドキュメントが大切だから。
普通は、プログラムよりドキュメントの方がエ数かかる。 >>598
要求の変更なんて受け入れられないから、最初に要件定義をしっかりやって仕様を確定した方がいいよな
後から変更があれば、その分の追加費用はもちろん頂く
あれ、WFでいいじゃん！？ >>603
ウォーターフォールでもなんでも良いから来月までに新しいバージョンで動くもの見せてよ
仕様は今あるやつとだいたい同じで良いからさ だから作る前から要件定義をしっかりなんて
無理に決まってんでしょ？ >>605
えー、それ、無理?
俺は別にみずほの件要件定義の問題だとは思ってないんだけど
だってモデリングソフトやドローソフトじゃあるまいしデザイナ（宇宙人と思って良い）相手にしてるわけじゃないよ
銀行だぜ、もうバグだけは勘弁して
余計なことは絶対しないでって連中
しかもすでに動くアプリがある状態でのシステムの移行だろ?
単純にjavaっていう不出来な言語と
オブジェクト指向っていう欠陥思想が規模に耐えられなかったんじゃないの? staticおじさん「オブジェクト指向は欠陥思想」 テストやり直しだねｗｗ
とか言ってるけどテストはコミットごと毎回やり直す
そこが噛み合わないよね みずぽは
そもそも仕様がよくわからないらしい
COBOLコードを読み解いて行くしかないって >>609
俺はこれが絶対不可能にしか見えないんだな
wfで曲がりなりにも全体をみて作ったものならまだしも
アジャイル（全体は見えない）で作ったものでテストをいちからやり直すってそれもうプロジェクト終わっちゃうよね?ｗ >>612
機能単位で作り込むんだからその機能だけテストすりゃいいんだよ 仮実装、仮システムすら作らず、一発で机上で全部の仕様書を作る
ってがWFの実態だからな。客からみたら。
そんなもん、うまくいくはずね～。 >>614
わかる
仮定のうえに仮定を重ねて仕様書にアホほど時間かけて結局PGに尻拭いさせるよな あーでもないこーでもないって
FW設計をレビューするのを
コンピュータ内でやるだけなんだけどな 自動テストも継続的インテグレーションも知らないおじさんがまた来たのか でもさ、ちゃぶ台返しされるの前提でコード組むのはともかく、テストファーストやらされるのは精神的にきついよ
めんどくさいことこの上ない 客側から、ハンコをもらったら実装開始。客は、書面でひたすら確認するしかない。
しかも客はシステム開発なんてしたこともない。
成功するわけがない。満足するシステムを納品してもらえるわけがない。
フリーウェアの細かなバージョンアップを見ればわかるが、
作って、あ、ここ改善したい、あ、ここ改善したい、あ、やっぱここ変えよう。
これがプロでも現実だろ。
それを素人に一発でやれというなら、お前ら鬼や。 >>613
だからそうはならないんだって
イテレーション1～これまで全部の変更がかかるときもあるんだって
そもそもアジャイルだと機能1-3を作ってるときに8-10は見えないからね
プロジェクト終了も止む無しでしょコレ >>612
そりゃ当然可能な範囲のテストしかしないんだろうから、君が必要だと考えてるテストが不可能だと言ってるだけだよね
だからこの場合、テストが不可能だと主張するじゃなく、全体としての品質を担保するのが不可能と主張しなければならない >>622
うーん、普通さ
類似のアプリってあるもんでさ
設計をパクるっつーか必要なものを全部洗い出すわけよ
んでウォーターフォール（笑）ってお前ら言うけど
俺はこれがデスマの原因の本質だとは思えない
んで既にできてるものを真似できるわけで基本設計からすでに駄目ってのはないと思うんよ
設計自体やってないとか担当者が記述するので精一杯でレビューしてないとかな
本当にウォーターフォールが原因だったのだろうか?って検証をしたのか?って話
なんとなくノリでウォーターフォール（笑）なんじゃない?
お前らって んでアジャイルが優れているか?っていうと
これまでのやりとりでもひとっつも優れてる箇所なんて見当たらないね
全体を把握するのなんて疲れるのでやりませんはねぇよ
機能1～3だけの設計ではアリだった方針Aも機能8-10を考慮すると
方針Bに変更せざるを得ませんって
それって完全に損なだけじゃない? >>625
自分が客側の立場のもので考えてみよう
君は、スマホをカタログスペック表だけで満足度わかる？
実際に触ってみないとわからない。ってのがパターンでしょ。
仮に設計書から何から何まで見せてもらっても、わからんでしょ？ 初めの段階で工数や納期決めたら
もうテコでも動かないって方式を取っているのがデスマーチの原因
今まで作った経験の無い物ほど工数は予想するのは難しい
更に大規模化すればする程その悪影響は大きくなる >>626
巨大システムと言われていても、実は、小さなパーツの集まりでしかない。
だから、ちっちゃいのを作って作ってしていくのがいい。
いきなり、ゼロから書面だけで巨大システムとして組み上げるなんて、超絶難度。
まして、システム開発経験ゼロの客にそれを求めるのは酷ってもんでしょ。
だからこそ、アジャイルのような感じで小さく聞いて小さく作って、形にしていくのが正しい。
WFは、小さなシステムを作るならいいけど、中規模程度以上から急激に無理ゲー 極端なんだよね
アジャイルとウォーターフォールの中間程度で良かったのにね 問題は、顧客がパーツだけ見せても、チンプンカンプンなんだが。 >>630
だからさ、ウォータースパイラルだって言ってるじゃん。 >>630
そういう契約や開発方法を売りに起業してみたら？
>>631
そんな顧客に一発の超分厚い書類を見るだけでGOサインのハンコ求めるこの業界ってどうなの？ってことだね 最初、詳細設計直前までウォーターフォールで作成して
そこからアジャイルで設計からやれれば上手く行きそうなんだけどね
設計工程ダブるけど >>623
>イテレーション1～これまで全部の変更がかかるときもあるんだって
それはGoサインだした責任者の問題だな
普通はプロトタイプ作って検証してるから全部の変更なんてありえない
>そもそもアジャイルだと機能1-3を作ってるときに8-10は見えないからね
WFなら1-3も見えてないな グダグダ言っても、今の日本の体制だと、内製以外無理じゃね？？？？
SIerが許さないだろ。自分たちが実はいらない存在だってバレるから。 多分、アジャイルを、100機能を順番に実装していくものだと考えてるとそう思うだろうね。
それは、たんにウォーターフォールを分割しただけでアジャイルではない。
アジャイルは100機能あるか必要なのかどうかも分からないとい前提で実施する。
仮に80機能目が出来てから全てをひっくり返すような誤りが見つかった場合、それは80機能を実装したおかげで検出できたと考える。
もし、ウォーターフォールだったら100機能全部を実装しなければ検出出来なかった問題を80%の段階で検出出来たから良かったと言える。
逆に、その問題をウォーターフォールだったら上流工程の段階で検出出来てたのなら、ウォーターフォールの方が優れていると言える。ウォーターフォールは下流工程にいくほど後戻りリスクが増大する方法だから当然だけど。 >>635
それはおかしいでしょ
ウォーターフォールならひとまず機能1-10は見れるはずよ
見ない奴は論外だけど
すべての細かい問題を解消することができないだけで
大元の放心ミスだけは防げる >>630
モデルなんだから極端の方が分かりやすいでしょ
そのまんま適用してしまう方が間違ってるだけだよ Google ChromeはBeta、Canary、Releaseと安定度別に分けたり
安定していない新機能は次のリリースまで先送りって事をやってるが
受託開発じゃそんな事出来ない
納期までに全ての機能を実装して納品する必要がある そもそもお前ら自分がアジャイルに作ったシステムが良くできた素晴しいシステムだと思ってるの？
それとも別な理由でアジャイルしたいの？ だから本当はうちらに必要なのは新しい契約方法であって開発方針じゃないんだよな
営業の問題を技術者に吹っ掛けようとしてるのがそもそもの間違いだよな
大手が一歩も譲らなかったら請負なんかできないんだよ
ってことだよね
派遣社員ばかりになるしかないね テストテストっていってるがWFのほうが最後の最後にならないとテストできないんだから致命的だろ
うまくいくはず（願望）を地でいってる >>645
それはそれでいいんだよ
理屈上ではやってれば終わる
でもアジャイルのは最終イテレーションから２回遡るだけでも場合によってはとんでもないテスト量にならないか?
では本当に追加箇所のテストだけでいいのか?と聞いたときに
みずほ銀行とか笑ってるから例に出すけど果たしてそうやって作ったものの納品を銀行が許すでしょうか?
って考えると絶対無理じゃん
だからこんなの想定するだけ意味ないんだよ ここって、WFしかやったことない奴が「経験上WFはうまくいかないけどアジャイルならうまくいきそう」ってノリで話してるだけだよな？
答え言ってやろうかw
うまくいかないのは開発手法ではなく単にお前らの実力不足だから、アジャイルにしたところで結局うまくいかんよw 「調整」ってどんな職人でもやる作業なのに
システム開発だけは「調整」のチャンスを一切もらえない 何故か実装と一致してない仕様書がみずぽでも発生していた
少なくとも何かおかしい所がある >>651
こんな風に秘密漏洩を平然とやる派遣がいるわけで。
害虫でアジャイルなんて夢のまた夢 >>650
いいじゃん
派遣の定義が特定派遣事業許可証の取得なら本社の情シスぐらいじゃね?
派遣じゃないのって >>647
>651みたいに実装と仕様書が乖離しててもみずほ銀行はおっけー？ 営業「アジャイルでやるわ」SE「ほーん」
営業「アジャイルなら要件定義も設計もしなくて良いよ」SE「え？」
営業「だからアジャイルなら安くなるよ」SE「え！？？」
営業「当然請負だよ」SE「はぁっ！！?」 でもアジャイルで請負やったときって何を担保すればいいの?
堂々と帰れるんじゃない? 仕様書が嘘どころか存在しない（COBOLソースだけ）って書いてる奴も居た
そら何をやっても移行なんて無理だろう WFでちゃんとやれる人が、より顧客の変化する要求に応えるために取り入れるのがアジャイル
WFで毎回ヒーヒー言ってるヘボPGの救済策じゃねえからw >>647
理屈上w
ソースが遡ったらテストコードも遡るだろ
なにをいってんだ？ >>658
発注してから納品まで、現場は変化しないと思ってるんだよ。
シグマのようにｗ うちの会社プログラム組んでから仕様書書くやつが大半なんだがこれもWF？
WF破綻してない？ Webの認証システムだったかな
納品物としていやいや書いてた >>658
WFでPGがヒーヒーいうのは大抵SEのせい >>657
いやそれは嘘だろ
動いてる機械はあるんだからやってみりゃいいだろ
cobolをどうやってjavaに移植するのか真剣に考えなかったんじゃね? 散々言われているけど内製に帰結するんだって
開発期間が設計等々を含めて数カ月とかいう時点でダメ
要望から２，３日でエラーチェック等々はざっくりの仮システム。１週間で運用可能品。
くらいの速度でやってくんないと なんか話が段々エクセルマクロレベルになってきてるんだけど
いいんかこれでw 自動デプロイ出来るようにして顧客がいつでも最新版をテスト出来るようにしよう >>669
究極的な開発スタイルは自分で作成だけど、次点がエクセルマクロ(他の言語でもいいけど)をバリバリ組める社員が隣の机にいて作ってもらえる状態だと思うわw excelマクロって舐めてるけど、ほぼなんでもできるぞ？適切かどうかは別として。 excel万能バカはずれてる
アセンブラでもなんでもできるわ 木にタイヤの絵のやつだな。
客が本当にほしい機能は、実はエクセルで十分だったというｗ ExcelでWebサーバ作ってください
Excelで弾幕STGやりたいです
ExcelでYoutubeみたい
Excelで ここで言語に重きを置くようだとウンコ。
お客様がほしいのは言語ではなく、役に立つシステム。 >>667
どんだけちっちゃなミニミニシステムを想定してんだよw ミニミニじゃないとユーザーは説明しきれない
ミニミニを積み重ねてデカくする
いや、デカくならないようにする そんな超ミニミニミニミニミニミニの超短期間のスパイラルやらプロトタイプやらアジャイルやら、なんでもできるのが内製の強み ユーザーの利便性も大事だけど、どうやって収益あげるかが一番大事
ボランティアでやってんじゃねえんだから WFだと、必要のない機能まで付けようとするんだよねえ
小さな機能で現実に必要なものを順々に付けていくのが一番良い ユーザーが細かく指示してもスパゲティになるようなら
ユーザーが一気にゼロから書類だけで指示できるわけがない 会議で余計なことを喋ったせいで
なくても別段業務に支障ないけどやらないと恰好悪い的な機能の実装が増えてしまった… 大枠つくって必要なとこだけ徐々に品質あげていく→アメリカ流アジャイル
必要最小限の機能をきっちり作って徐々に機能が足されていく→日本流アジャイル 進捗が悪いからといって出てきた代替案が
性能的にいまいちなだけじゃなく工数も増えてるっていう
よくわからない方向に舵を切ることになってしまった
客との間に人が多いとほんと何が起きてるかわからん
アジャイルは全員が客としゃべるべきだな >>689
違う違う、ユーザーのせいじゃなくて、お前らに複雑な仕様を整理する能力がないからだよ >>693
WFを持ちあげたい
WFのプログラマは有能設定
アジャイルのプログラマを無能設定
アジャイルを持ちあげたい
WFのプログラマは無能設定
アジャイルのプログラマを有能設定
こんな自分が認めたほうだけ有利な設定をつけて理論を展開しようとしているお前はアホだろｗ つまり、職業プログラマに依頼せず自分たちで作りましょうってことだ >>695
レッテルはってるわけじゃないじゃん
だって今のところアジャイル派の言うことは支離滅裂でとても仕事なんて頼めないレベルなんだから アジャイル派は内製でそ
請負にアジャイルは依頼できんわ そんな採算度外視で開発なんかされたら困るな
でもアジャイルって客も一緒に開発するんでしょ?
内製じゃその客って誰? 組み込み内製ソフトウエアなら、
製品を買ってくれるのがお客様 部分的にアジャイルでも良いんじゃね
バックエンドはWF
フロントエンドはアジャイル >>702
その人がどうして?
時間割いてくれるの?
請負じゃね?それ >>699がWFは、問題が発生してないという根拠をおねがいしますｗ >>701
ユーザーそのもの
ユーザーが開発に加わるってのは、質問に時間をあけず回答してくれるし、
開発中のモニターを指差して、ここのデザインはこれをこっちに持って行って、
カーソルが自動的にこの順番で動いていくようにして・・・。と即答して、
それを反映している間に、その場で自分が要望した内容を書面修正する。 >>705
俺はwfが問題じゃなくてそもそも設計をやっていないことが問題だと思ってるんだよね
wfが問題だって資料ある? >>706
え？ちょっとよくわからない
その客とはどういう契約してるの? 例えば、プログラマは「ここのリストは、こうやって出すんだけど、参考までに今ってどうやってここのデータを作って、このデータを次に使ってるの？」
ユーザー「今は、A部署から、こんな感じの伝票が届いて、それを入力して、データをメールでCSVでB部署に送ってる・・・」
とかその場で教えてくれるから
プログラマ「なら、ここは、ここの情報を共有してしまって、相互チェックできるようにしたら？」
とか逆提案もその場でできる。
お前らが一番嫌っている「御用聞き」がいない状態で、即答で返ってくる。
ユーザーはプロジェクトとして参加してるから、可能な限り成功させて出世して、
早いところ現場に帰ろうと思ってるから、いつまでもグダグダとはならない。 >>709
内製に契約もクソもあるかいｗ
開発者とユーザーは、同じ会社の人間だ。
※よくあるのが、開発会社は１００％子会社とかの体制だけど、これは厳密には内製とは言わない。
子会社とはいえ、一応は別組織だから。 >>704
？
パッケージソフトを内製するとして
お客様はソフト買ってくれる人
じゃないの？ >>712
その人がどうして時間を割いてくれるの?
パッケージじゃ「ナニコレクソ」で終了ちゃうの? プログラマ⇔「御用聞き」⇔お客様
ですね
良く完成できますねコレ。
余程業務知っててノウハウないと無理 俺が言ってるのはそれって請負とどう違うんだよって話 客もプロのプログラマ、請ける方もプロのプログラマの1対1の状態だとしても、
仮プログラムとか作ることなく、
全部最初から最後まで「机上の書類だけ」で、一度決裁印を押したら二度と修正せず
「一発」で書類上の内容が完全に要望を満たしていて、さらに使い勝手の良いインターフェース
や信頼性等々も完璧、ユーザーの不満が一切無いシステムを構築するとか、無理ゲーすぎるwwwwww
その無理ゲーを顧客に迫るのが今の日本のIT業界のシステム開発。 >>716
俺は時間さえくれればできるからいいんだよ >>718
客は客で上司からプロジェクトを任されて、完成予定日を指定されて担当するんだから
そんな時間なんて無限にくれるわけねーだろ。 アジャイルでもリリース前の仕様の凍結→安定化は必要
納期ギリギリまで仕様変更してたらキリないじゃん なるほど
WF契約締結後に
客がガンガン仕様変更かけてきて
それを御用聞きが全部ロハで受け付ける
請負とアジャイルの違いは何か？
というご質問ですね WFでもある程度の仕様変更はあるだろ
工数越えない限りはやってあげるよ シェアウェアのバージョンアップが
最初のリリース直後は、バージョンアップが頻発するのはなぜでしょう？
メジャーバージョンアップが、入るのはなぜでしょう？
顧客＝開発者＝自分のシステムで書類を作ることなく意思疎通をすることなく実装１００％でいけるのに
それでもバージョンアップするのはなぜでしょう？
形にしてみたらイメージと違った、形にしていく途中でモットいい方法を思いついた・・・。
プログラマ自身が一回で完成版を作れてないのに、システム開発の素人であるお客様はそれを求められる・・・。
なんつ～自分に甘く他人に厳しい酷い連中だ。非正規派遣プログラマってのは。 >>725
WFも作っておしまいじゃないじゃんw
二次開発とかするでしょ普通にw 日本においてウォーターフォールとアジャイルに差なんてない
時間的な長短を表現しているだけであって、内容は同じ >>726
だね。
で、開発期間が毎回、半年以上から数年ｗ
開発完了時には現場の運用変わってて無意味ｗ
外注WFと内製アジャイルの差はこの点が圧倒的すぎる。
害虫アジャイルはありえないから>>651みたいに情報漏えいするから 新規性のあるもの作ってるならともかく、どうせお前らがやってることなんてただのCRUDでしょ
それですら最初に仕様をまとめきれないなら、アジャイルでやったところでどうせ失敗するよ
あとから建て増し建て増しのひっでぇプログラムになるだけw 例えばこのスレでの表記だって
途中からウォーターフォールをWFって書くようになったでしょ？
そうやって常にカイゼンしていくのがアジャイルなんだよ
WF脳だとウォーターフォールをWFと略すなんてけしからん、規約違反だって言い出すよ >>729
そうそうｗ
だからそんな単純な機能の組み合わせしかプログラミングできないのに
クソみたいに開発時間がかかって、糞システムしかできないんだから
外に投げないで必要分を自分たちで作ったほうが良いってことだ >>730
アジャイルって言葉使ってるだけで自分が賢くなったと錯覚してそうだけど、プロのWF>>>>>>アホのアジャイルだからな >>732
このように、人間の質に絶対的に差をつけて自分の理論を正当化しようとする癖ってのは抜けないのねｗｗｗ
プロのWFとプロのアジャイルを比べてくれやｗ アジャイルではプログラマー自身に高い設計能力やコミュニケーション能力が要求されるのは確か
人の意見を全く聞かないカウボーイコーダーや
コピペコーダーやには仕事を任せられない >>731
WFかアジャイルか
内製か外注か
別の議論だろアホ >>732
少なくとも数千万～数億円規模の案件しかない大手WFならともかく
アジャイルって予算100万しかないけどアマゾンと同じネットショップ作ってよっていう世界だよ
WFでやれるとは思えないよ >>733
アホのWFしかできないお前にはアホのアジャイルしかできないんだって
お前こそずっとアホのWFとプロのアジャイルを比べてることに気づいてないの？
アホのWFとアホのアジャイルで比較しろや 俺が仕様だ
詳細仕様書ファーストの開発形態なんて滅びろ >>738
アホのWFは莫大な費用と時間の末に失敗
アホのアジャイルは途中で失敗に気づき終了
アホのアジャイルのほうがいい 最近、内製って言葉がよく出てくるけどどこまで自社でやったら内製なの？
・発注先が連結子会社
・自社で要件定義、設計までして丸投げ
・開発している場所が自社内。請負業者や派遣に来てもらって作業
・100%自社の正社員（契約社員やバイト等含む直接雇用）のみで作る
正直、内製ってエクセルVBA程度ぐらいしかありえないと思ってるんだど
なんちゃって内製じゃなくてピュア内製やってるとこって本当に存在するの？ >>737
その数千万～数億円規模ってのも、単なる言い値だけどなｗ アジャイルは作ってから直す
つまり、設計、製造、テストまで終わって検収の時点でOK/NGの判断が出る
NGが出たら設計～テストまでの工数は全部無駄
開発は工数を無駄にし、発注元は毎週検収に時間がとられる
変更対応への反射神経はいいけど、生産性は低くなるよね WFは必ず失敗する
アジャイルはプログラマがそれほど優秀じゃなくてもとにかく成功する >>741
むしろ、ピュア内製のほうが歴史は長い。
メインフレームなんて内製の最たるもの。そして失敗も明らかになってるけどｗ
内製とはいわない
・発注先が連結子会社
＝完全100%の子会社でも別会社・別組織だから
・自社で要件定義、設計までして丸投げ
＝官公庁なんてほぼこれ。元請けSEは超ラクチン。書類のコピーを下に投げるだけ。
内製
・開発している場所が自社内。請負業者や派遣に来てもらって作業
・100%自社の正社員（契約社員やバイト等含む直接雇用）のみで作る
>>745
その「作って」が完璧なやつではなく、ざっくり版だからなあ >>745
アジャイルは変更に俊敏に追従するやり方であって、早く完成させるやり方じゃないから だから
プロトタイピングと自動テスト
が必須なんよ >>743
MS-DOSは買い取っただけ
グーグルマップは外注
MySQLもオープンソース
はい、論破 アジャイルが理解できない
↓
他のやつらもどうせできてないだろ！(怒)
みたいなやついるな アジャイルのようなスタイルの開発現場に行けない！いつまでも使い捨ての末端！
↓
俺が置かれた立場の開発スタイル意外認めない！
だと思うわ
アジャイルしか経験のないやつってまずいないだろうから。アジャイルやってるやつはwfもやったことあるだろ。
wfしか経験のないやつはたくさんいるだろうけど ろくな仕事ができないのは俺が無能なのではなく周りが無能だから！
↓
聞いた感じアジャイルならうまくいきそう！アジャイル最高！
みたいな奴もいるね WFは必ず失敗する
アジャイルはプログラマがそれほど優秀じゃなくてもとにかく成功する
WFの製造工程はカッチリ分担されてしまうから脱落した部分からプロジェクトが壊れる。
アジャイルはできない奴の分は出来る奴がやってしまうのでわ？
要するに連帯責任であいまいに分担されて作業する方法だろ。ﾜﾛｽ
WFでも、「○○さん（俺）、○○君の分やってもらえるかなぁ～？」と
おねぇリーダーが仕切ればうまく行くよ。
池メンリーダーだとその辺ができない（俺の経験）。 俺はコミュニケーション能力に自信があるからアジャイルなら必ずうまくやれると確信している
アジャイルやる機会さえ与えられればなぁ… ウォーターフォールで仕様変更にまともに対応出来ない人が
アジャイルだと出来ると考える理由が理解出来ん
夢があるんだねアジャイルって
てかそもそもアジャイルは仕様変更対策の開発手法じゃないし >>758
WFで仕様変更に対応するのが難しいのは、プログラマの資質ではなくプロセスと契約の問題
アジャイルならプログラマは鎖から解き放たれる
そうなったときのプログラマの生産性はすごいよ そりゃアジャイルの半分はスパイラルでできてるんだから当然そうなるでしょ スパイラルはウォーターフォールの積み重ねだけどな。 自分自身で作るのが最強なんだから
それに近い体制であればあるほど優位なのは確定だろ
ＷＦでも客が開発現場に居て、その場で細かい仕様や要求を聞けてテストもお願いできる体制なら行けるよ。
それが結局アジャイルだろって言われるわけだがｗｗｗ アジャイルはネトゲの大型アップデートみたいに最小限の完成品から機能追加する手法。
ここまでは動きますで客先で定期的に現物プレゼンするのはスパイラル。 アジャイルやったことないくせに、とか言ってくる奴がいるが、そこは問題じゃない
やったことなくてもわかる
どう考えてもWFよりはいいものができる >>710
理想はそうなんだろうけど、現実は他の業務をしているときに割り込みで
聞きに来られても困るし、ものによっては曖昧な記憶で即答しろみたいな
ふいんきにされたり。 逆提案にしても現場に近いところは自分の業務の
範囲内での近視眼的な見方しかできないし、現場から離れると何故か
ポエマーが増えて、死ねこいつらとか精神が摩耗させられたり。
自分の業務範囲にとらわれることない視点を持ち、あらゆることに
他人事ではない意識をもって仕事に取り組むってのが必要なんだが、
安い給料でそれを押し付けられてもねえというのが本邦だろうね。 >>767
コミュ力がない奴は地味に組み込みでもやってろってこった >>768
コミュ力でポエムや他人の記憶をどうにかできるんならいいんですけどね。
どんだけお前のコミュ力はすごいねんっていう。 コミュ力どころか普通の業務の会話でしかないのに、おまえら、それすら出来ないの？
もはや障害者だろ 高卒叩き上げの理系エンジニアから搾取するジャップは許さない？
アジャイルなんて客先いっておべんちゃらでへいこら
ジャップに頭下げるなんてゴメンだね
ちゃんと金払えよ
∩＿＿＿∩
| ノ ヽ/⌒) ジャアアアアアアアアップ
/⌒) (ﾟ) (ﾟ) | .|
/ / ( _●_) ミ/ ∩―－、
.（ ヽ |∪| ／ ／ (ﾟ) ､_ ｀ヽ
＼ ヽノ / / ( ● (ﾟ) |つ
/ / | ／(入__ノ ミ じゃあああああああっぷ
| / ､ (＿／ ノ
| ／＼ ＼ ＼＿＿＿ ノﾞ ─ｰ
| / ) ) ＼ ＿
∪ （ ＼ ＼ ＼
＼＿) 結局1の言うとおりだったな
アジャイル派は火あぶりでいいレベル WFってコンパイルするのに大金かかってたころの名残だよな >>775
丸投げするのにちょうどいいから、日本では未だに最先端な手法ｗ >>777
準委任による開発を飲めるクライアントがいないから日本では無理ってことやな！ >>780
米と比べてITでは明らかに無能な日本のIT下請け開発は残業やら徹夜やらでなんとかやってる
これが準委任だと何も出来上がらない >>770
プログラミングで集中してるときに
日常会話のモードに切り替わらんよ
いろんな業務を切り替えて行える人は尊敬するよ >>780
SES=準委任契約って聞かされたけど
日本の派遣ってほとんどSESでしょ？ >>781
外人の作るもんなんて超絶バグだらけじゃん >>787
最終的にバグが無ければその開発者の技術力が高いとか勘違いしてる人？
日本が優れてるのは試験品質やで ぱよぱよちーんがいるかもしれないから
そんな連中に仕事投げるなんてできないわ >>790
ねーほうがいいに決まってるじゃん
しかも奴らの作るもんって
「おいおいこれマジでテストしたのかよ」
ってぐらい動かねーじゃん 確かに仕様がなけりゃそりゃバグもないわなｗ
こりゃ一本取られたわいｗ >>793
「入力に使う項目」と「入力したらこんな結果が欲しい」のすり合わせはするよ
それなかったらどうしようもないからな
それが帳票の類か、Excelのアレか、CSVなテキストか、XMLか、スクレイピングしたHTMLかは知らないが
記録的には（俺の場合）Redmineに残る感じ
・シーケンス図をVisioで書いてExcelの仕様書に張り付けとか、ER図見ればわかるドキュメントの作成はしない
・相手がやりたい要件を絞り込み、相手が重要視するものをまず実装する
・結合は極力前倒しにする、最後に一発でできることを祈ったって無理
ケント・ベックを崇拝せよっていう気は無いしな
回し方として「最後に一発で結合できることを祈り無事死亡」が嫌なら自然と短期間回すことにならんか？ >>794
WFでも今時ビッグバンインテグレーションを進んで選ぶ奴はいないよ。
あっちはあっちで機能を切り分けプロジェクトを分散させ大失敗を
小失敗程度に抑えるくらいの頭はある。
アジャイルに関してはふわふわとしたポエムで夢を語られても
現実的なものを作るのは非常に困難なだけですよと。
言ってる側はきちんとしたことを言っているつもりなんだろうが、
聞く側からするとお前も当事者なんだからもうちょっときっちり
考えるか、時間と金よこせよとしか言えないような奴が多い。
客のポエムなら耐えれるけど、同僚のポエムは耐えられんて。 お客様がよく訓練されてて「既存のアプリのこの辺をどう変えたい」を逐一説明できるなら
仕様書ベースのほうが望ましい
実際のところそんな人殆どいないでしょ、物流とか精密機器の中の人なら居るけど
あなたが全部分かってるべきでしょと責めるつもりはないけれど
こっちもあなたが何を求めてるのかわからんので
短い期間（たとえばひと月）リリースするのを3～4か月ですり合わせ、の形でやらせてもらえませんか
契約もそれ相応のでやらせていただけませんか
「そりゃ無理ですわ」って言ったら
ほかの会社さんをお探しくださいって言うだけで終わりなわけだし >>795
ポエムというか、理想的すぎる例ばっかりが書籍にあるのは同意する
実際のところ「あと一回クリック減らしてもらえたら（特定の処理をこっちで請けてくれたら）イケてるんですけどね」レベルまで
細部を煮詰めてキッチリやりたいなら
ある程度フィードバックもらわんと厳しいところがあるから
なるべく早めのリリースで80点狙い、たたき台ができたら細部を煮詰める話がしやすくなる
少なくとも全然設計しないでテキトーに書いてるのがイケてる、なんてことはないと思う 「あともうちょいここ煮詰めてくれたら」の話がでたら
ファイナルリリースの時期か
お互いわからんものがあるから本当に実務で使える最低限の叩き台作って
それ基準で細部詰めませんか？ くらいの話
プロトタイピングっつってイベントだけの奴だとお客さんはまずわからん
実際に動くものを触って初めてどこを詰めてほしいかがわかるって印象
初めからお客さんが本当に望むものなんてわかってるよ
なんてエラソーなこと言えないもの 客に使ってみてもらわないと客の欲しいものが分からないって素人かよ
客はどういうシステムが欲しいは分からないけど、どういう業務が必要かは分かってる
業務を聞いて、それを実現するのに最適なシステムを作り上げるのはプロであるエンジニアの仕事だよ 使ってみてもらわないとわからないって操作性とかそういうレベルで言ってるなら素人もいいところ
使ってみないとどういう業務がしたいとかどういうデータが必要かわからないとしたら、その客大丈夫？
そういうアホな客を相手にして小銭を稼いでるのかな？ >>799
要件変更がなかった案件はあるか？
あるならそれ最適なシステムじゃなかった、と言える
>>800
現場レベルだと「ええそれですいいですね」と会議で言って
実際に触ったら「あ、大口顧客への割引率と料金はこっちで
別表に書いてたんですけど……なんとかこれまとめられません？」
みたいな謎のコトがある
現場の人が触った瞬間に判明する謎の要件がある >>799
なら、スマホ作ってる連中は素人だなｗｗｗｗ >>802
WFの最難関って、客と元請けが書類で完成させるというところなんだよな。
プログラマでこの点がわからないアホが多すぎ。
超分厚い仕様書を受け取ってプログラミングを開始したら
開発中「コンパイル」は一回だけしか使えない。って縛りでシステムを一発で完成させてみろと。 >>805
別にいいじゃん
書いてないとこは開発任せでいいんだし
こまんねー程度の動作が書いてあればいいはずだぜ
んで漏れたとこは追加で金もらえるべ こいつらは
追加変更で金がもらえないのを
アジャイルって言ってるだけだからな 偏差値40未満のFランクの就職できないやつが行き着く底辺多重派遣プログラマにそんなことできるわけがないw 偽装請負多重派遣業界搾取SE結婚相手の犠牲対策
巨額搾取させて結婚妨害するな！
無能残業して共働き妨害するな！
・IT社長に贅沢資金を搾取させるな
・客先経営資金削減の犠牲になるな
・平均年齢40歳未満の会社は辞めろ
・6時間/日以上PC使用の会社は辞めろ
・1,000万円/年以下の会社は辞めろ
・100万円/月以下の契約は辞めろ
・5,000円/時以下の契約は辞めろ
・100万円/月以下のプログラムは作るな
・プログラムの料金以上に作るな
・プログラムの利益を搾取させるな
・プログラムの報酬を搾取させるな
・多重契約は止めろ
・不利益な依頼は断れ
・知的財産を渡するな
・客先指示に従うな
・生産利益を上げろ
・生産効率を上げろ
・契約外作業期日に従うな
・時間外労働違反は止めろ
・残業見積りは止めろ
・残業しないで学習しろ
・残業しないで副業しろ
・残業しないで家事やれ
・偽装請負多重派遣は通報しろ
・損害賠償訴訟を怠るな
【IT業界】独身が多い職業の象徴として「ITエンジニア」が取り上げられる
http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/110200713/?ST=spleaf 7次請けまで行ったら
もう元請けが何を欲しかったのか
分かんなくね？ >>799
こっちはこっちで過剰な能力を前提とするポエムだからな まず多重下請け構造を破壊して少数精鋭でやり始めないと
日本の大手IT企業に未来はない >>809
そのとーり
アジャイルの狙いって伝言ゲームをやめようぜ
ってとこだろ
業務の複雑な仕様の伝言ゲームなんて(ヾﾉ･∀･`)ﾑﾘﾑﾘ >>811
7次請けでやってる奴なんて、1次でやったところで客の要件なんて汲み取れないよ
下請けだから無能なんじゃなくて、無能だから下請けなの >>814
そしたらお前いらなくなっちゃうけど大丈夫？ 下請けがやっていたような仕事は
中国やベトナムのオフショア開発をしている会社に奪われ
日本の技術力のない下請けは次々と潰れる >>817
そう思ってるのはお前のようなプログラム作ったことのない馬鹿だけ。 その辺りが最終責任会社で、実動員はそこら中からかき集めたゴミ
ゴミは多重派遣かもしれんw 青銀->青銀直系->わけわからんIT->超零細IT->何の会社なの->人売り->俺
現場入場でわけわからんITを名乗り、超零細ITの指示を受け、人売りから工賃もらう。
これだと５次かな。 >>823
いや最後の人売りは派遣やろ？零細企業が最終的な責任もってて3次じゃね なぜ、いまだ7割のITプロジェクトが失敗するのか？ 「再生人」が明かす炎上メカニズムと立て直しの知恵 - エンジニアtype | 転職＠type
http://type.jp/et/feature/233 要するに発注側がクソなんだな
何をやりたいのかも分からないまま一方的に仕様だけ押し付けてくる
そんなんだから開発側も発注側が何をしたいのかも分からないまま開発を続行
結果、ある程度開発が進んでから「違う、そうじゃない」とか言われて仕様変更が繰り返され
開発が遅れデスマーチに
そこに大企業の力で大量のトーシロを投入し更に炎上と
アジャイルだけ取り入れてもコミュニケーション取れなければ一緒と言うのも良く分かる 要求側は、素人
その素人に書類だけで完璧なものを渡せとかw
そんなことできるならおめーらに頼まず、自分で作るだろwww ハードメーカーからの外注依頼もモヤモヤっとした夢物語しか無いがな。
素人じゃ無い分たちが悪い。 発注側は素人なんだという意識のままだから、で失敗するってことだろ。アジャイルなら
なおさらに。
まあ、アジャイルに限らないが素人なら素人でそういうことを考えて行動すればいいが、
実際には自分が不利になると素人を振りかざすだけだからな。 現行の業務フローを書いてもらってそこからitにできる
箇所を提案するところからやらせて貰えればいいけどな
客がこれ作って!って言ってきたのはもう初手から駄目だからな SIerが「脱・人月ビジネス」を実現するには？PM歴20年以上のベテランに聞く3つのポイント - エンジニアtype | 転職＠type
http://type.jp/et/feature/210 >>827
客がITの素人なのは仕方ないとして実装側も素人に毛が生えた程度のもんだからなw 発注側がクソ×
契約書がクソ◯
クソなクライアントはこっちから切れる契約にしないと 客先に飛び込んでまで業務を把握するのは中々やるのが難しいから
要件がふわってしてる時はお断りするのが良いんだろう 無能実態派遣残業して時間報酬相場下げるな！
【知的財産と契約料金の生涯損害促進者ばかり】
［偽装請負多重派遣搾取業界の従犯SEを追放すべき］
偽装請負多重派遣SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者
偽装請負多重派遣SEの迷惑
無償プログラム提供
事前面接
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
時間外労働違反
低予備工数見積
残業見積
無料追加
学習不足
裁判苦手
対人障害
健康障害
孤独死
偽装請負多重派遣SEの代償
低収入低技術
非婚離婚
鬱病早死 仕事受ける時は相手がバカだという前提でやらないとダメ
小学生に下手で指導してやる意気込みで仕事するのがよろし WFだから失敗するのではなく、上から下まで無能揃いのチームだから失敗するんだよ
アジャイルにすればなんとかなると思ってるならおめでたすぎる アジャイルにすれば失敗してもプログラマの責任に出来るじゃないか。 エスアイヤー（笑）がアジャイルの話に入ってくんなよ 少なくとも、アジャイルで失敗すれば、それは新しい失敗だ
どうせ失敗するなら新しい経験をした方がいいと考えるか、どうせ痛い思いをするならよく知った苦痛を選ぶのか、という違いだ エスアイヤーを排除できるだけでも
アジャイルの意味はある アジャイルいうのも恥ずかしいが、SIerいうのも恥ずかしい。
決して、会話では使われないよね？ >>844
転職先では外人交えて1年仕事しているけど、
アジャイルもSIerも社内では一度も聞いたことないな。
設計書は、必要なもの作るが
不必要なものは作らない。
「それ必要。それは不必要。」が明確で気持ちよい。
みんな綺麗なソース作るから分かりやすいし、
コメントも丁寧に入ってる。
ただ、ひとりだけ例外がいて
むちゃくちゃ汚いソース書いて理解不能なんだ。
そういうのみると、やはり個人技術の
集合だと思う。
SEの仕事は力量を見抜いて
レベルの低いやつに作らせないこと。
レベルの高い人を面接で見分けること。
それだけ。 >>847
でも日本ってもう人手不足なんだよね
レベルが高いだの低いだの以前にこんなブラックに人が集まるかな?（笑） レベルの高低ではなく、
そもそも伝言ゲームが無理ゲー 伝言ゲームなら工数はクソ取られるけどQA表ちゃんとメンテしておけばよくね? 数千ページの仕様書を作っても、実際、必要な部分だけにすると
１００ページもないんだよねｗ 会社でプログラムを発注するという話が今日急に出て、
書類作れって命令を受けたから、何をやりたいのか整理するために
仮プログラムをVBAで４時間ほどで作ったら、課長「これでよくね？」で終わったｗｗｗｗ いや・・・どうだろうｗ
これメンテしなきゃならんの俺になるだろうし(;_;)
ま、壊れる要素が殆ど無いんだがｗｗｗｗ ケース1: 会社「MS Office使うのやめます。」
ケース2: MS「VBA廃止します。」 Excelマクロだからって資料を書かないやつはボッコボコだぉう! それは
内製だがアジャイルじゃない
これから地獄アジャイルがが 客側が仕様書を作る能力があるなら、すなわち自分たちで作れる
仕様書が作れないと要求や確認はできない
仕様書がないとシステムの外部委託開発はできない
これが導き出す答え⇒自分で作らない限り、成功したシステムにはならない そういやそうだな
ソフトなんて誰でもできるのに
なんで客は自分でやんないんだ？ 誰でもできることをやらせるために社員を雇えないからに決まってるだろう >>861
ウッセーな
今、アクオス作るのに忙しいんだよ > ソフトなんて誰でもできるのに
プログラムなんて誰でも書けるのにというのはよく見るが、
ソフトなんて誰でもできるとかどういうことなんだろう？ >>866
表示する値の具体的な計算方法がどこにも書いてないとかどうするの?
書いてあったとしても一つ一つの変数がどっから取ってきたどの値なのかわからない
さらに単位にどうやら変換が必要なようでそれの係数もまたどっから取っていいのかわからない
結局組めるぐらい詳細に書いてもらわんと実は動けないよ 普通は表示では表示以外の処理はしない。
もしリアルタイムに反映する表示があっても、それは
表示担当の作業範疇では無い。
表示は計算処理をを呼ぶだけだ。 >>868
必要なデータや設定値は最新値をDBやファイルから読む仕様多いけど大丈夫?
嘘表示しない? そもそもよく読んだら計算に使うマスタータイマーが別サーバーじゃんとかありがちだよ
設定値はローカルのファイルから読むつもりだったけど
使用してるドメインが実行してるプログラムのローカルデータのアクセスをことごとく禁止してるとか
詳細な計算式が出きらないと判明しないぜ 表示はパッシブな動作しか出来ないか。
あくまでも入力を伝えて、再び表示を指示されるからその時の値で表示するだけ。だな。 トヨタの役員たちは
下請けにはアジャイルで
発注しないといけない、と言ってるから
二度とトヨタの仕事はしない >>876
ほう、あの下請イジメで有名なトヨタですか? トヨタなんてテストの自動化もやっと着手し始めたレベルなのにｗｗ 何度仕様変更しても
追加料金はありません
それが下請けアジャイルです 業務プログラムって、経営戦略プログラムなんだよな
普通、経営トップの秘書くらいの近さで経営トップから直々にシステム（戦略）を指示されて
それをソフトウェア等として形にするのが正しい姿なのに
なのに、子会社として外部会社にしてしまう
経営戦略なんてアウトソーシングでいいって意味と同義で、経営者は自分で自分の評価をさげているようなもの 実際海外は情報システムの役員はCEOの次のポジションだけどな コンサルという名のハゲタカを入れないと
よそからハブられる
競争とか資本主義とかうそっぱち
権益握ってる連中がむしってるだけ まあ、要件定義やPMやると、コンサル自体は本当は必要なんだろうな、とは思うよ
頭おかしくないクライアントはほぼ皆無 >>881
大手はメインフレームとオフコンで帳票発行の電子化やりきったからな
日本は世界一メインフレームに熱心で、当時の需要は帳票発行の電子化だった
仕事がなくなったものの大きくなった情シス部隊をどうするか
子会社に切り出して外販で利益を上げるよう指示し、できたところは残った
ダメだった会社は情シス子会社をSIerに売った
そもそも経営云々なんて求められん時代のを今でもだいぶ引きずってると思う 頭おかしいコンサルもおるけどな
システムの知識ゼロでやっとる事は請求の値切り倒しだけ
活躍の場は会議と書類整理
合意内容の取りまとめを一字一句確認して仕様変更による工数発生を全てただで業者にやらせる為の下準備しかしていない
悪徳コンサルおるから注意しとけや
○○カ○ン○あたりの奴はやばい 日本でアジャイルやってるとこなんて、内製以外でないだろ どんな巨大システムも基本は個別の業務ごとにわかれる。
内製でキッチリ一つ一つ作っていくのが、一番満足度も、必要性も、機能性も、何もかもが高い。 内製では大きなシステムが…っていうけど
某検索会社のシステムより大きいシステム持ってる会社なんてどのくらいあるの？
そしてそれらのシステムって片手で数える範囲の天才プログラマが作ってる現実はどう説明するの？
データ調整とか写真撮影部隊とかアルバイトでもできる仕事の功績もでかいけどさ。 >>895
Googleにできることがお前にもできるわけじゃないんだから、例に出す意味ないだろアホw >>896
天才に対抗するために、バカを数集めれば対抗できるってのは、どういう根拠で？？？ 日本にある巨大システムの大半は内製時代に作ったものなんだけどなあ 無能は連鎖する
無能は自分以下の無能を次々と雇い
プロジェクトを崩壊に追い込む >>895
確かに大きいシステムを作ることの大変さって、ほとんどが
・大人数で作業することの大変さ
・少人数で大量の作業をすることの大変さ
のように思える。
ウォーターフォールが前者の大変さを解決するための手法だとするならば、アジャイルは後者の大変さを解決してくれなければ、結局小さなシステムにしか有効ではないということになるね。 >>900小さなシステム(業務)の塊が大きなシステムであると>>894が言っている… つまり小さな個人商店が集まるとイオンになるわけですね >>902
イオンも実際、テナントが入ってくれなきゃただのでかい箱だからなあw >>903
いきなり文脈から大きく外れたレスありがとう
何を言いたいのかもう少しくわしく説明してくれないか イオンは小さなテナント（モジュール）の集まりで出来てると言いたいのか？ >>901
どうかなー?
ユーザ数200万で設計したものが
ユーザ数1億2000万に耐えられると思わんなぁ
よく考えるとお国の仕事って前人未到だからやめたほうがいいよ >>901
それが解決策なら、小さなシステムである人間を大きなシステムにする組織化はもっと上手くいくはず >>897
お前Googleに対抗してんのかよw
で、どんだけいい線いった？ >>895
あるとしたら物流 or 小売？
とにかくシステムの良しあしと単価がリンクする業界
例：DHL、クロネコヤマト、Amazon
意外にローソンも頑張ってるが（たぶん）Googleほどではない
>>900
正直大規模アジャイルは厳しいと思う
イメージとしてはHibernateとGlassFishとSpring、みたいな感じになるんだろうが
人給・在庫管理・会計・生産管理その他、が大体APIっぽくなってるような現場ってないかも >>906
その例えの意味がわからんｗユーザー数設計を変えるだけじゃね？ WF多段丸投げの末端でしか働いてない連中が語るのが間違いなんだって。
客を見たこともない連中は丸投げの前の現場を知らないから。 客
↓
要望を設計しました
↓
使えないので設計し直しました
↓
使えないのでアジャイルしました まん、たんなる改修作業だよな。いわゆるアジャイルって。 >>915
使えないのでアジャイルしました。⇒役に立たないのでexcelVBAで作ったほうをみんな使ってます。 >>918
まあ数による工数爆発がなかったらダメポのサグラダファミリアもあそこまで長くはならなかっただろうね >>919
ユーザーの現場にVBAが大量にあるのって、コレだよね
基幹システムが役に立たないから、手前味噌でシステム作って対応 >>913
ユーザー数設計を他の機能と独立に保つのが難しいという話じゃないのか
しかし、ユーザー数1億2000万は日本人全員が使う想定ってことで、かなり前提条件が変わってきそうだな 募金かなんかで、想定がクソ甘くて、数日間止まらなかったっけ？w 多重化等々はあるが、そこまでソフトはかわらんが…？ 200ユーザーの場合の利率と1億ユーザーの利率の計算式が違うの? 人手っていっぱいあっても瞬間瞬間を見てみると「待ち」状態とかで、ぼ～っとしてる人が８割
みたいなときあるよねｗ クラウドや外部業者に任せっきりだと
>韓国のサーバーレンタル業者がランサムウェアに感染。バックアップまで暗号化され、身代金の支払いへ。
>http://hayabusa9.2ch.net/test/read.cgi/news/1497656403/
みたいになっちゃったとき、どうするの？
まもなく復旧します！の言葉を信じて１ヶ月くらい業務停止すんの？ｗ 規模が小さいときには問題にもならなかったボトルネックに次々とぶつかる 自社運用してれば、自社の分だけ復活させればいいけど、
こういうとこだと、複数社のデータを持ってるから
全部が復旧できないとダメになる。
そうすると、全部の会社分が対応できるまでシステムが稼働しない。
自社運用なら当然自社分しかないから、自社のシステムを復旧させたら即時稼働できる。
これも、クラウドやデーターサーバーを利用する際のリスクだよね。 >>935いや実際そうだよ
先に復旧した会社があるってわかった場合、他の契約してる会社が怒るから
なんでうちを優先しないんだ！！！って 韓国の三流企業と天下のAmazonを一緒にするな！
Amazonの技術力は世界一イイイイイ！！ >>925
まあ、歩いてアメリカ行くって言ってるようなもんだよね
最低限目的地を国際空港に替えないと １００の業務で構成されるシステムをWFで仕様書がようやく出来上がってプログラマの手に渡ったときには
少数精鋭で作ってる連中はすでに１００のシステムをそれぞれユーザーの評価を受けて平均５回ほど作り直しして完成して、完成品をもとに将来のための仕様書として作成している。
って感じ >>925
どーせスケールアップかスケールアウトしかしないんだから同じようなもんだ
そしてこれらは人数いらない まず末端派遣はプログラマとしてシステム開発を語る資格ないって条件をプログラマ板全体につけるべきだな 偽装請負多重派遣業界搾取SE結婚相手の犠牲対策
巨額搾取させて結婚妨害するな！
無能残業して共働き妨害するな！
・IT社長に贅沢資金を搾取させるな
・客先経営資金削減の犠牲になるな
・平均年齢40歳未満の会社は辞めろ
・6時間/日以上PC使用の会社は辞めろ
・1,000万円/年以下の会社は辞めろ
・100万円/月以下の契約は辞めろ
・5,000円/時以下の契約は辞めろ
・100万円/月以下のプログラムは作るな
・プログラムの料金以上に作るな
・プログラムの利益を搾取させるな
・プログラムの報酬を搾取させるな
・多重契約は止めろ
・不利益な依頼は断れ
・知的財産を渡するな
・客先指示に従うな
・生産利益を上げろ
・生産効率を上げろ
・契約外作業期日に従うな
・時間外労働違反は止めろ
・残業見積りは止めろ
・残業しないで学習しろ
・残業しないで副業しろ
・残業しないで家事やれ
・偽装請負多重派遣は通報しろ
・損害賠償訴訟を怠るな
【IT業界】独身が多い職業の象徴として「ITエンジニア」が取り上げられる
http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/110200713/?ST=spleaf 偽装請負多重派遣業界搾取SE結婚相手の犠牲対策
巨額搾取させて結婚妨害するな！
無能残業して共働き妨害するな！
・IT社長に贅沢資金を搾取させるな
・客先経営資金削減の犠牲になるな
・平均年齢40歳未満の会社は辞めろ
・6時間/日以上PC使用の会社は辞めろ
・1,000万円/年以下の会社は辞めろ
・100万円/月以下の契約は辞めろ
・5,000円/時以下の契約は辞めろ
・100万円/月以下のプログラムは作るな
・プログラムの料金以上に作るな
・プログラムの利益を搾取させるな
・プログラムの報酬を搾取させるな
・多重契約は止めろ
・不利益な依頼は断れ
・知的財産を渡するな
・客先指示に従うな
・生産利益を上げろ
・生産効率を上げろ
・契約外作業期日に従うな
・時間外労働違反は止めろ
・残業見積りは止めろ
・残業しないで学習しろ
・残業しないで副業しろ
・残業しないで家事やれ
・偽装請負多重派遣は通報しろ
・損害賠償訴訟を怠るな
【IT業界】独身が多い職業の象徴として「ITエンジニア」が取り上げられる
http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/110200713/?ST=spleaf >>944
いや末端派遣は実際システム開発知らないじゃん >>946
末端もクソも間に入ってる会社なんて丸投げなんだから末端しか把握できてないだろ 客、ユーザーと直接話て開発した経験のないやつは駄目 末端派遣はガチでクソ
3回に1回は10行で済むことを50行くらい書いてくる
ソース見てこうしろって言ってる間に実装終わっちまうやろが！ >>948
それな
自分で金稼げるならともかく、会社にぶら下がってるだけな奴はいらんわって思う ユーザーと開発者の間の問題点
開発者と開発者の間の問題点
開発会社と開発会社の間の問題点
これらの問題解決なんだから経験すらしたことないやつが語るのがホント間違い
派遣はこの辺の経験があることはありえない >>949
だってこの好景気で売り手市場な時代でも就職できないやつが派遣プログラマやってんだもん >>951
あるよー
打ち合わせまで平気で丸投げしてくるもん >>954
つかアレだよお前
仮に組みもしないやつが1ヶ月も消費して仕様を決めたとこで邪魔でしかないかんね
どうせ1ヶ月も消費するならプログラマに使わせた方がいい
丸投げするのが１番いいことを知っているから丸投げしてるって現状だからね >>955
それならもう上の奴要らなくね？
何故かリストラで追い出されないのが不思議の国ニッポン 俺に丸投げしろ
その通りに作ったら動きもしない
ベタベタな設計書ばっかよこしやがって 大手の正社員が設計とかやりだしたら絶対逃げたい
そもそも作れるレベルに届くわけない
資料作成遅れまくってもこちらの納期は変わらないとか最悪 自分の為のコードって他人に崩されると一気に汚れてしまう 資料になんの記述もないクラス作ったやつは俺のサンドバック
「書いてないクラス資料に書いて」
メールで逃げられないように偉い人書いて送るわ クラス内クラスにしてprivateにしときゃ解決だな >>968
書いてないクラスを全部書いてって言ったんだけど? なんだどっちにしても同じなら
堂々とpublicクラス作れるな！ しかも上司にアピールしてくれる
資料を送れば仕様書も作ってれる
実はすばらしい >>970
書けばよろしい
作った理由も書いてもらう
汎用性とか言い出しやがったらその効果も数字で説明文書かせる >>971
いいやむしろ漏れであるわけで評価は上がらんね >>973
どうかな
そこは上司の物事の捉え方次第
効果はモジュールでの使用箇所洗い出して個数示せばいい
単体テスト数の削減を示せばOKだろう
問題は数字で説明文を書くことだけだ >>967
ソースコード以外に資料つくらせてるの？ >>976
だってソース読む手間が省けるじゃん
そもそも俺の工数じゃないし本来あるべき資料なので書いてもらいます
今回の改修に影響なければ放置でいいし影響あるならどこで何やってるかわかるじゃん 報告：製造過程での新規クラス作成による影響
工数見積もり：トータル－５人日
実績：＋１０人日
差異の理由：リーダー指示による資料作成のため＋１５人日を消費したため
完璧 新規のクラス作るなとか頭の悪い奴の作るルールだからなあ。
フレームワークでビジネスロジックだけ作ってろとかいう設計にして
似たコードやコピペコードをばらまかれるのがこのパターンだな。 >>980
作るななんて言ってないじゃん
資料に漏れなく書けって言ってるだけ >>982
アセンブラ以上になると仕様書から実装起こすと絶対漏れる
仕様書書いてる側にその認識があるんならいいんだがほとんどありゃせんぞ 以上、だと閉区間というか「含む」になるな
「アセンブラより高級の言語での開発前提で仕様書ベースだと」が正しいか >>983
はぁ?クラス書けって言ってるだけなんだけど?
アセンブラ?どっから出てきたの? >>983
言っとくけど書きにくいから見逃してとか意味不明なんだよ
全部かけ書けないもの使うな
そう言ってるだけよ >>985
仕様書を自然言語（日本語か英語かフラ語かドイツ語かは知らん）で書くなら
絶対漏れる
この説明で構わんだろうか？
ある一時期だけは仕様書をアセンブラで書く時期があった、パンチャー向けにな
その時期だけは仕様書と実装が一致していたが、Cレベルになったらもう漏れ漏れ クラス図とNoteだけで全部網羅とか無理じゃねえかな、といったほうがよかったんだろうか
とは言え発注側がそれなりに配慮せずフザけたこと抜かすのにいら立つことは
そりゃあよくある
クソ野郎ならとっとと逃げてもっといい仕事を探してみるのも手かもしんにゃい >>987
はぁ?
お前の都合じゃん
doxygenでもなんでも使えよ
この猿頭大丈夫かよ >>989
不満があるなら転職していい仕事とってきたほうがよくね？
まあ自己責任のところはあるがそこは自身の決断とせざるを得ないが（仕事とれない時期があって苦しんだとか）
とお伝えしようと思ったんだが >>990
ごちゃごちゃうっせさっさとやれよ
できない言い訳はいいからよ >>9
俺はお前の上司か顧客か、じゃなくてタダの名無しさんや
そんだけイラっとするなら仕事変えちまえよ、って言ってるのだけはお伝えしたい >>991
酔っぱらってるとｱﾝｶｰおかしーネー
なんっつって
とにかく、なんか現在の職場がアレすぎるなら別世界っつか別の会社か自営かに旅立ってええんやで？
くらいのことを仕えたかったのだとご理解頂きたい
俺はお前の上司 or 顧客じゃないし、お前さんのことなんざ知らん、怒られても困るで >>993
はぁ?
つかお前が設計してクラス作ったんじゃねぇの?
なんでそのドキュメントを書くのが嫌なの? javadoc や doxygen で良ければマシ
フローチャート書かせる部署もあるらしい 仕様書なんて中韓SEの自己満足だからな
ソース読む役には立たんよ 実装と仕様書に差異がある可能性は高い
しかし、毎回ソースから仕様を読み解いていったからといって、漏れがないとは限らない アジャイルは期日を切ってからやるケースが多いから
客も何回か修正は要望しても、それが無限になることはないからいいよね。
客もこれ以上やってると、他の部分に割く時間がなくなるってわかってるから。 このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 15日 23時間 51分 10秒 ２ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/
▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
