パスワードを忘れた? アカウント作成
13960687 story
ビジネス

7pay問題を扱った記事に対し「それはウォーターフォール・モデルではない」との指摘 78

ストーリー by hylom
どんな手法も使い方による 部門より

サービス開始後に不正利用報告が相次いだセブン&アイ・ホールディングス系の決済アプリ「7pay」に対しては開発体制の不備も指摘されていたが、元マイクロソフトの中島聡 氏がこれに関連して次のように述べている

日本のコードを書かない上流のエンジニアが設計し、コーディングは下請けに任せる、という開発手法(ウォーターフォール)そのものに大きな問題があると考えています。

今回の7payアプリの開発がこういった手法で行われているかどうかは不明で、氏は一般論として日本のIT企業がこういった開発体制を取っていると批判しているのだが、これに対して「上流のエンジニアが設計し、コーディングは下請けに任せる」というのがウォーターフォール・モデルというわけではない、またウォーターフォール方式の開発が悪いわけではない、といった指摘が出ている

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 完全図解 (スコア:3, おもしろおかしい)

    by Anonymous Coward on 2019年07月18日 14時17分 (#3653662)

    正しいウォーターフォールの説明はこちら [atmarkit.co.jp]。

    • by Anonymous Coward

      これは死人が出るわ

      • by Sukoya (33993) on 2019年07月18日 17時20分 (#3653799) 日記

        仕事はやめてもいいからニンゲンやめないで!

        親コメント
        • by Anonymous Coward on 2019年07月18日 19時17分 (#3653923)

          これの何が面白いって、新人君が「ウォーターフォール」と聞いてナチュラルに知ってる絵を出しただけなんだろうな、というノホホン具合と、トラウマ持ちにはピンポイントで刺さりそうな図だよな、という落差だよね
          # 最近の食べ超、このレベルでアイロニー効かせたネタは減ってる気がする

          親コメント
        • by Anonymous Coward

          人間はやめてもいいから仕事辞めないで!

          • by Anonymous Coward

            業務中に逃亡したACさんについて、会社側は「期待を上回る38人を捕獲できた」と発表しました。

  • by Anonymous Coward on 2019年07月18日 14時38分 (#3653681)

    > ごく初期的な設計上のミスがあったため生じた事件ですが

    原因は設計だと言ってるにもかかわらず、問題を仕様じゃなく開発体制のせいにするエンジニア

    • by Anonymous Coward

      情報処理業界のことは良く知らないけど、誤った設計案が採用されてしまった≒スラドで頻繁に出て来る「レビュー」(多分ISO9000のそれと同じ筈)とやらを通過した≒レビューが機能していないのは、開発体制のせいじゃないの?

      • by Anonymous Coward on 2019年07月18日 15時26分 (#3653717)

        レビューで見つからなかったのならレビュワーのせい。
        見つかったのにそもまま工程進めたのならマネージャーのせい。
        いずれにしろ開発体制のせいではない=開発体制を変えたとしても解決しない。

        親コメント
        • by Anonymous Coward

          レビューが存在しない~無力化したのなら、開発体制のせいじゃないの?

        • by Anonymous Coward

          > レビューで見つからなかったのならレビュワーのせい。

          レビューする時間が用意できてない、レビュワーの能力不足(作業割り当ての問題)など、レビューが機能していないってことなので、開発体制の問題。

          > 見つかったのにそもまま工程進めたのならマネージャーのせい。

          問題があるのに何の対応もなくマネージャーの独断で工程を進められるのならマネージャの権限が異常。
          問題への対応が別途あって工程をすすめたのであれば、人が足りなくて実行できないとか、対応方法が間違ってて意味がないってことであって、やっぱり開発体制の問題。

      • by Anonymous Coward

        ISO9000なんて事前の規定通りに行っているってだけで全く以て内容の担保なんぞしてくれないだろ。
        挙句国内だと文書で指示したくないからと口頭で個人的意見だとか言い張っている人まで居るんでその規定どおりの手順かすら怪しいし。

        • by Anonymous Coward

          > 挙句国内だと文書で指示したくないからと口頭で個人的意見だとか言い張っている人まで居るんでその規定どおりの手順かすら怪しいし。

          それはISO9000で規定した通りに運用されてないってことなんで、まずはISO9000維持しろよって話にしかならんのでは?

      • by Anonymous Coward

        ISO9000は品質保証をうたっているが、製品の品質をうたってるんじゃなく
        ドキュメント管理や開発手続きの品質保証だぞあれ

        • by Anonymous Coward

          製品の品質ですよ……

  • 工程をいくつに分けるかとかは規模でも変わってくるだろうけど

    ・バグ管理とかを工程ごとに分けてチェックして品質をきちんと確保できてから、下流のフェイズに移行する

    というのが鉄則だろうと。

    ウォーターフォールのメリットは、あとどれくらいでアウトプットが出せるのか、現時点でどれくらい遅れているのかが把握しやすいということ。
    デメリットは、上流のバグが下流で見つかるととんでもない時間ロスをすること。なので、上流がいい加減だとそのプロジェクトは必ず火を噴く。

    納期、予算を計画的に配分している場合はウォーターフォールのメリットが強く生きる。
    一方で、後戻りさせたときのロスがひどいので、外部要因での変化が大きかったりで要件や仕様が頻繁に変わるような案件には向かない。

    7payの場合、最上流を管理する立場の人たちの認識がお話にならなくて「工程を終わらせる」という作業ができていないまま次の工程に移り、しかも後戻りを認めていない……ようにしか見えない。
    ウォーターフォールは上流でのミスが致命傷になるやり方なので、トップがあれだとそりゃあ下流は地獄を見ますわな。
    かといって、あんな規模のものでお金がかかわるようなものをアジャイルで作れってのも無理があるし、トップがあれでは同じ間違いを延々繰り返して無限反復になりかねない。
    開発形態のせいにするのはちと無理がある。

    • by Anonymous Coward on 2019年07月18日 15時09分 (#3653699)

      結局はオムニ7の脆弱性が問題だったわけで。

      7payを作り出すときに
      決済アプリを作りますよ。認証は既存システムのID使うよって言われたら
      じゃあ認証の性能保証はそっちでやるんだ。うちの仕事じゃないなって思うもん。
      え、そっちで担保してくれるんじゃないの?
      そこでワザワザ、これから繋ごうとしてるシステムに問題がないかアセスメントなんかやんないよ。

      想像だけどさ

      親コメント
      • by Anonymous Coward

        下請けがオムニ7の方も調べて問題点を報告しても、
        その下請けが管轄外の、即ち無意味な報告出してきたって事で減点してお仕舞い、てなりそ。

  • by Anonymous Coward on 2019年07月18日 18時15分 (#3653865)

    セブン&アイの取締役がプロダクトオーナーを直接つとめたアジャイルの成功例となるだろうといっとき息巻いてた気がする。

  • by Anonymous Coward on 2019年07月18日 14時06分 (#3653655)

    コードかけないやつが幅きかせすぎってとこだと思うんだけど。

    • by Anonymous Coward on 2019年07月18日 14時35分 (#3653677)

      日本の開発現場はコード書けない奴しかいないのが普通だから、設計側にコード書けなくてもいいんだよ。
      設計がきちんとしてて、その設計通りに作れるならね。

      今回の大きな問題はそこじゃなくて、設計そのものが悪すぎる。一般人でも分かるぐらいの致命的欠点を多く抱えた設計のまま突っ走ったのが問題。

      親コメント
      • 日本の開発現場はコード書けない奴しかいないのが普通だから、設計側にコード書けなくてもいいんだよ。
        設計がきちんとしてて、その設計通りに作れるならね。

        「コード書けない奴しかいない」のに、設計通りに作れるの?
        コーディングレス・ノンプログラミングが普通なの?

        親コメント
    • by Anonymous Coward
      本題と関係ないところで「オレ様に文句いう(オレ様が優秀だと認めない)ヤツはみんなクソだ」と喚く土方が一番のガンだとなぜ分からないのだろう?
    • by Anonymous Coward

      コード書けない奴が偉そうにするのが問題なのではなくて、設計できない奴が設計してるのが問題なんだろう。
      経験的にも、コード書けないけど、設計は出来るってのは多いし、コード前提で考えないから設計がしっかりしてることも珍しくない。
      逆に、コード書けるからといって、そいつが必ず設計できるってわけでもないしな。

      • by Anonymous Coward on 2019年07月18日 14時53分 (#3653690)

        > 経験的にも、コード書けないけど、設計は出来るってのは多いし、

        俺の経験と違う…

        親コメント
        • by Anonymous Coward

          プログラム設計は無理かも知れないけど、設計は出来るよ。
          出来ること出来ないことや実装の難易度があるから言語は知ってた方が良いけどね。

          • by Anonymous Coward

            設計のレベルによるかなぁ。

            基本設計ならアーキテクチャを押さえてれば言語の詳細など開発そのものの知識はなくて大丈夫。
            詳細設計は無理かな。逆に詳細設計できるなら手が遅くてもその人は実装できる。

          • by Anonymous Coward

            むしろこんな巨大で金にストレートに繋がる案件で、下っ端プログラマが直接設計なんてしていたら、その時点で怖いわ。
            いや足並み揃わずリリース出来ずにかえって傷が浅かった可能性も有るのか。

          • by Anonymous Coward

            出来るのはユーザーサイドでも出来るような、簡単な要件定義やUIの設計だけでしょ。
            ネットワークに繋がるのがあたりまえの時代に、通信プロトコルの設計や、セキュリティーへの配慮など、根本的に大事なことを理解するにあたってコードが書けないなんてことは普通はありえない。

            • by Anonymous Coward
              >ユーザーサイドでも出来るような、簡単な要件定義やUIの設計
              そんなユーザーがいるなら設計は私がしますから屏風から出してください
        • by Anonymous Coward

          一山いくら的な人の管理してるプロジェクトだと、設計もコーダーが担当してたりするからね。
          ロジカルに物を考える人は、コードも設計も出来る側になるし、ロジカルじゃない人はどちらも出来ない。

          いわゆるホワイトなプロジェクトに行くと、コード書いたことないとか、趣味では書くけど仕事では書かないって人たちが設計してる感じになるよ。
          ロジカルに物は考えるにしても、設計でとコードのレイヤで考える物事が別物になるから、ほどほどに両方できるってレベルの人は設計に関わったりしない。

        • by Anonymous Coward

          PGM言語ってのは手段であって目的じゃないってこととここで言ってる設計っていうのはPGM設計じゃないってことだよ
          あんたの経験してきたとこは
           ・小規模案件でマルチでやらされてきた
           ・設計者がプログラマー上がりばかりだった
           ・表面的にはアジャイル風の開発ばかりだった
          とかだったんだろ

        • by Anonymous Coward

          俺の経験とも違う。
          レベル低いとこだと設計出来てないことに気づかれないのかも。可能性として

    • by Anonymous Coward

      そこの反論がうまく出来ないから些細なところを突いてるのかと

      もちろん設計者がコード書かないのがダメなのではなく
      コード書く能力もない人が設計してるところがね
      でもサーバ側の大事なところほど優秀な人がコード書いた方が早いという意見もあるかもね

    • by Anonymous Coward

      それこそ論点ではない。
      元々の仕様が腐ってんだから、下手すりゃバギーで固まった方が未だ損害が少なかった可能性もある。

  • メテオフォール型開発
    https://developers.srad.jp/story/18/06/01/0510232/ [developers.srad.jp]

  • by Anonymous Coward on 2019年07月18日 14時39分 (#3653683)

    もう数人、日本人で「Windows は俺が作った」って方がいらっしゃいますがね。

  • プログラムがひととおり揃わないことにはテストを開始できないのがウォータフォール型開発の問題点の一つです。動かしてみて上流工程の問題が発覚するのはよくある話です。発覚すると大きな手戻りが発生します。

    さらに問題なのが、プロジェクトが遅延すると、その分テストの開始が遅れることです。
    開始が遅れても、締め切りが延びません。本来、テストは知的な作業なのですが、工数不足のせいでこなすだけの作業になり、バグの見落としが発生します。結果として、品質にしわ寄せがいくことになります。

    もっとも、今回の7payの問題はこれだけでは無いように思いますが。

    • by Anonymous Coward

      違うぞ
      金、時間、人(質も含む) どれかが足りないだけだぞ

      こんなことはIT業界だけじゃなくどんな職業だって存在する問題

      • by Anonymous Coward

        え? 人質が足りない?

      • by Anonymous Coward

        どれか?おかしいなうちは全部足りないぞ?

  • by Anonymous Coward on 2019年07月18日 15時45分 (#3653726)

    彼が言いたかった「ウォーターフォール型」ってのは、正確な意味でのそれではなくて、特に日本のSIerなどで物凄く良く見る上下流間の隔たりと、そこで本当に良く見る「言われたことだけやる人々」の事を指摘したかったのかなと忖度してみた。

    自分は20年くらいしか開発業界にいないけど、それでも大手は本当に "このパターン" が多くて、実コードを書かないプロパーが設計して、設計に意見しないコーダがコード書くみたいなの本当に多い。

    で、大事なポイントなんだけど、この「実コードを書かない設計者」って所は、何も「お前も書け」って言いたい訳じゃなくて「それだと、いまのチームメンバーのスキルや体制を踏まえた実際の開発の様子が汲み取れないんじゃないの?」と言う想像が出来そうなものなのにも関わらず、

    それでもPLやPMはそんな「設計者側主体のヒアリングから」工数を決めたりする事が実際に本当に多いので、これを指して「何も考えない開発体制」を、例えばウォーターフォールと表現したんじゃないかなって思いました。

    いま大手企業のSIer現場に常駐している現役の人なら、多分誰でも気づくはず。

    • by Anonymous Coward

      追記と言うかまとめると:
      ・コードの実態を経験や知識に基づいて判断できない人が設計してないか
      ・そんな設計者からのヒアリングベースで工数決めてないか(←ここ重要)
      ・前例踏襲やら特に考えや意見も無しに「決め」で進めて、指示に従って動いてないか

      こんな所だと思う。言いたかったのは。

  • by Anonymous Coward on 2019年07月18日 18時01分 (#3653848)

    >「上流のエンジニアが設計し、コーディングは下請けに任せる」

    良い名称は何でしょうね。

    キャプスタンモデルなんてどうでしょう(あの奴隷がぐるぐる回してるやつのイメージ)

typodupeerror

アレゲは一日にしてならず -- アレゲ見習い

読み込み中...