7pay問題を扱った記事に対し「それはウォーターフォール・モデルではない」との指摘 78
ストーリー by hylom
どんな手法も使い方による 部門より
どんな手法も使い方による 部門より
サービス開始後に不正利用報告が相次いだセブン＆アイ・ホールディングス系の決済アプリ「7pay」に対しては開発体制の不備も指摘されていたが、元マイクロソフトの中島聡 氏がこれに関連して次のように述べている。
日本のコードを書かない上流のエンジニアが設計し、コーディングは下請けに任せる、という開発手法（ウォーターフォール）そのものに大きな問題があると考えています。
今回の7payアプリの開発がこういった手法で行われているかどうかは不明で、氏は一般論として日本のIT企業がこういった開発体制を取っていると批判しているのだが、これに対して「上流のエンジニアが設計し、コーディングは下請けに任せる」というのがウォーターフォール・モデルというわけではない、またウォーターフォール方式の開発が悪いわけではない、といった指摘が出ている。
完全図解 (スコア:3, おもしろおかしい)
正しいウォーターフォールの説明はこちら [atmarkit.co.jp]。
Re: (スコア:0)
これは死人が出るわ
Re:完全図解 (スコア:1)
仕事はやめてもいいからニンゲンやめないで！
Re:完全図解 (スコア:1)
これの何が面白いって、新人君が「ウォーターフォール」と聞いてナチュラルに知ってる絵を出しただけなんだろうな、というノホホン具合と、トラウマ持ちにはピンポイントで刺さりそうな図だよな、という落差だよね
# 最近の食べ超、このレベルでアイロニー効かせたネタは減ってる気がする
Re: (スコア:0)
人間はやめてもいいから仕事辞めないで！
Re: (スコア:0)
業務中に逃亡したACさんについて、会社側は「期待を上回る38人を捕獲できた」と発表しました。
原因 (スコア:1)
＞ ごく初期的な設計上のミスがあったため生じた事件ですが
原因は設計だと言ってるにもかかわらず、問題を仕様じゃなく開発体制のせいにするエンジニア
Re: (スコア:0)
情報処理業界のことは良く知らないけど、誤った設計案が採用されてしまった≒スラドで頻繁に出て来る「レビュー」（多分ISO9000のそれと同じ筈）とやらを通過した≒レビューが機能していないのは、開発体制のせいじゃないの？
Re:原因 (スコア:1)
レビューで見つからなかったのならレビュワーのせい。
見つかったのにそもまま工程進めたのならマネージャーのせい。
いずれにしろ開発体制のせいではない＝開発体制を変えたとしても解決しない。
Re: (スコア:0)
レビューが存在しない～無力化したのなら、開発体制のせいじゃないの？
Re: (スコア:0)
> レビューで見つからなかったのならレビュワーのせい。
レビューする時間が用意できてない、レビュワーの能力不足(作業割り当ての問題)など、レビューが機能していないってことなので、開発体制の問題。
> 見つかったのにそもまま工程進めたのならマネージャーのせい。
問題があるのに何の対応もなくマネージャーの独断で工程を進められるのならマネージャの権限が異常。
問題への対応が別途あって工程をすすめたのであれば、人が足りなくて実行できないとか、対応方法が間違ってて意味がないってことであって、やっぱり開発体制の問題。
Re: (スコア:0)
ISO9000なんて事前の規定通りに行っているってだけで全く以て内容の担保なんぞしてくれないだろ。
挙句国内だと文書で指示したくないからと口頭で個人的意見だとか言い張っている人まで居るんでその規定どおりの手順かすら怪しいし。
Re: (スコア:0)
> 挙句国内だと文書で指示したくないからと口頭で個人的意見だとか言い張っている人まで居るんでその規定どおりの手順かすら怪しいし。
それはISO9000で規定した通りに運用されてないってことなんで、まずはISO9000維持しろよって話にしかならんのでは？
Re: (スコア:0)
ISO9000は品質保証をうたっているが、製品の品質をうたってるんじゃなく
ドキュメント管理や開発手続きの品質保証だぞあれ
Re: (スコア:0)
製品の品質ですよ……
私の知ってるウォーターフォールモデル (スコア:1)
工程をいくつに分けるかとかは規模でも変わってくるだろうけど
・バグ管理とかを工程ごとに分けてチェックして品質をきちんと確保できてから、下流のフェイズに移行する
というのが鉄則だろうと。
ウォーターフォールのメリットは、あとどれくらいでアウトプットが出せるのか、現時点でどれくらい遅れているのかが把握しやすいということ。
デメリットは、上流のバグが下流で見つかるととんでもない時間ロスをすること。なので、上流がいい加減だとそのプロジェクトは必ず火を噴く。
納期、予算を計画的に配分している場合はウォーターフォールのメリットが強く生きる。
一方で、後戻りさせたときのロスがひどいので、外部要因での変化が大きかったりで要件や仕様が頻繁に変わるような案件には向かない。
7payの場合、最上流を管理する立場の人たちの認識がお話にならなくて「工程を終わらせる」という作業ができていないまま次の工程に移り、しかも後戻りを認めていない……ようにしか見えない。
ウォーターフォールは上流でのミスが致命傷になるやり方なので、トップがあれだとそりゃあ下流は地獄を見ますわな。
かといって、あんな規模のものでお金がかかわるようなものをアジャイルで作れってのも無理があるし、トップがあれでは同じ間違いを延々繰り返して無限反復になりかねない。
開発形態のせいにするのはちと無理がある。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:私の知ってるウォーターフォールモデル (スコア:2, すばらしい洞察)
結局はオムニ７の脆弱性が問題だったわけで。
7payを作り出すときに
決済アプリを作りますよ。認証は既存システムのID使うよって言われたら
じゃあ認証の性能保証はそっちでやるんだ。うちの仕事じゃないなって思うもん。
え、そっちで担保してくれるんじゃないの？
そこでワザワザ、これから繋ごうとしてるシステムに問題がないかアセスメントなんかやんないよ。
想像だけどさ
Re: (スコア:0)
下請けがオムニ7の方も調べて問題点を報告しても、
その下請けが管轄外の、即ち無意味な報告出してきたって事で減点してお仕舞い、てなりそ。
開発体制 (スコア:1)
セブン&アイの取締役がプロダクトオーナーを直接つとめたアジャイルの成功例となるだろうといっとき息巻いてた気がする。
論点はそこじゃないのでは？ (スコア:0)
コードかけないやつが幅きかせすぎってとこだと思うんだけど。
Re:論点はそこじゃないのでは？ (スコア:1)
日本の開発現場はコード書けない奴しかいないのが普通だから、設計側にコード書けなくてもいいんだよ。
設計がきちんとしてて、その設計通りに作れるならね。
今回の大きな問題はそこじゃなくて、設計そのものが悪すぎる。一般人でも分かるぐらいの致命的欠点を多く抱えた設計のまま突っ走ったのが問題。
Re:論点はそこじゃないのでは？ (スコア:1)
日本の開発現場はコード書けない奴しかいないのが普通だから、設計側にコード書けなくてもいいんだよ。
設計がきちんとしてて、その設計通りに作れるならね。
「コード書けない奴しかいない」のに、設計通りに作れるの?
コーディングレス・ノンプログラミングが普通なの?
Re: (スコア:0)
Re: (スコア:0)
コード書けない奴が偉そうにするのが問題なのではなくて、設計できない奴が設計してるのが問題なんだろう。
経験的にも、コード書けないけど、設計は出来るってのは多いし、コード前提で考えないから設計がしっかりしてることも珍しくない。
逆に、コード書けるからといって、そいつが必ず設計できるってわけでもないしな。
Re:論点はそこじゃないのでは？ (スコア:1)
＞ 経験的にも、コード書けないけど、設計は出来るってのは多いし、
俺の経験と違う…
Re: (スコア:0)
プログラム設計は無理かも知れないけど、設計は出来るよ。
出来ること出来ないことや実装の難易度があるから言語は知ってた方が良いけどね。
Re: (スコア:0)
設計のレベルによるかなぁ。
基本設計ならアーキテクチャを押さえてれば言語の詳細など開発そのものの知識はなくて大丈夫。
詳細設計は無理かな。逆に詳細設計できるなら手が遅くてもその人は実装できる。
Re: (スコア:0)
むしろこんな巨大で金にストレートに繋がる案件で、下っ端プログラマが直接設計なんてしていたら、その時点で怖いわ。
いや足並み揃わずリリース出来ずにかえって傷が浅かった可能性も有るのか。
Re: (スコア:0)
出来るのはユーザーサイドでも出来るような、簡単な要件定義やUIの設計だけでしょ。
ネットワークに繋がるのがあたりまえの時代に、通信プロトコルの設計や、セキュリティーへの配慮など、根本的に大事なことを理解するにあたってコードが書けないなんてことは普通はありえない。
Re: (スコア:0)
そんなユーザーがいるなら設計は私がしますから屏風から出してください
Re: (スコア:0)
一山いくら的な人の管理してるプロジェクトだと、設計もコーダーが担当してたりするからね。
ロジカルに物を考える人は、コードも設計も出来る側になるし、ロジカルじゃない人はどちらも出来ない。
いわゆるホワイトなプロジェクトに行くと、コード書いたことないとか、趣味では書くけど仕事では書かないって人たちが設計してる感じになるよ。
ロジカルに物は考えるにしても、設計でとコードのレイヤで考える物事が別物になるから、ほどほどに両方できるってレベルの人は設計に関わったりしない。
Re: (スコア:0)
PGM言語ってのは手段であって目的じゃないってこととここで言ってる設計っていうのはPGM設計じゃないってことだよ
あんたの経験してきたとこは
・小規模案件でマルチでやらされてきた
・設計者がプログラマー上がりばかりだった
・表面的にはアジャイル風の開発ばかりだった
とかだったんだろ
Re: (スコア:0)
俺の経験とも違う。
レベル低いとこだと設計出来てないことに気づかれないのかも。可能性として
Re: (スコア:0)
そこの反論がうまく出来ないから些細なところを突いてるのかと
もちろん設計者がコード書かないのがダメなのではなく
コード書く能力もない人が設計してるところがね
でもサーバ側の大事なところほど優秀な人がコード書いた方が早いという意見もあるかもね
Re: (スコア:0)
それこそ論点ではない。
元々の仕様が腐ってんだから、下手すりゃバギーで固まった方が未だ損害が少なかった可能性もある。
メテオフォール+アウトソース=メテオソース型（7pay） (スコア:0)
メテオフォール型開発
https://developers.srad.jp/story/18/06/01/0510232/ [developers.srad.jp]
Re: (スコア:0)
https://www.businessinsider.jp/post-194302 [businessinsider.jp]
紛う事なきメテオフォールだわ。
自称 Windows は俺が作った、「中島聡」かぁ (スコア:0)
もう数人、日本人で「Windows は俺が作った」って方がいらっしゃいますがね。
テスト工程の開始が遅れるのがウォータフォールの問題 (スコア:0)
プログラムがひととおり揃わないことにはテストを開始できないのがウォータフォール型開発の問題点の一つです。動かしてみて上流工程の問題が発覚するのはよくある話です。発覚すると大きな手戻りが発生します。
さらに問題なのが、プロジェクトが遅延すると、その分テストの開始が遅れることです。
開始が遅れても、締め切りが延びません。本来、テストは知的な作業なのですが、工数不足のせいでこなすだけの作業になり、バグの見落としが発生します。結果として、品質にしわ寄せがいくことになります。
もっとも、今回の7payの問題はこれだけでは無いように思いますが。
Re: (スコア:0)
違うぞ
金、時間、人（質も含む） どれかが足りないだけだぞ
こんなことはIT業界だけじゃなくどんな職業だって存在する問題
Re: (スコア:0)
え？ 人質が足りない？
Re: (スコア:0)
どれか？おかしいなうちは全部足りないぞ？
中島さんは語弊のある言い方をしていると思う (スコア:0)
彼が言いたかった「ウォーターフォール型」ってのは、正確な意味でのそれではなくて、特に日本のSIerなどで物凄く良く見る上下流間の隔たりと、そこで本当に良く見る「言われたことだけやる人々」の事を指摘したかったのかなと忖度してみた。
自分は20年くらいしか開発業界にいないけど、それでも大手は本当に "このパターン" が多くて、実コードを書かないプロパーが設計して、設計に意見しないコーダがコード書くみたいなの本当に多い。
で、大事なポイントなんだけど、この「実コードを書かない設計者」って所は、何も「お前も書け」って言いたい訳じゃなくて「それだと、いまのチームメンバーのスキルや体制を踏まえた実際の開発の様子が汲み取れないんじゃないの？」と言う想像が出来そうなものなのにも関わらず、
それでもPLやPMはそんな「設計者側主体のヒアリングから」工数を決めたりする事が実際に本当に多いので、これを指して「何も考えない開発体制」を、例えばウォーターフォールと表現したんじゃないかなって思いました。
いま大手企業のSIer現場に常駐している現役の人なら、多分誰でも気づくはず。
Re: (スコア:0)
追記と言うかまとめると:
・コードの実態を経験や知識に基づいて判断できない人が設計してないか
・そんな設計者からのヒアリングベースで工数決めてないか（←ここ重要）
・前例踏襲やら特に考えや意見も無しに「決め」で進めて、指示に従って動いてないか
こんな所だと思う。言いたかったのは。
名称募集 (スコア:0)
＞「上流のエンジニアが設計し、コーディングは下請けに任せる」
良い名称は何でしょうね。
キャプスタンモデルなんてどうでしょう（あの奴隷がぐるぐる回してるやつのイメージ）
Re: (スコア:0)
ノーブルモデル？
両班方式？
Re: (スコア:0)
インパール作戦モデルでいんじゃないかな
ろくに理解していない上が原因で最終的に崩壊するし
Re:名称募集 (スコア:2)
インパールに迷惑じゃなかろうか
Re: (スコア:0)
7payメソッド または セブンメソッド ←永久不滅の汚名が困るなら会社畳め。
Re:名称募集 (スコア:1)