アカウント名:
パスワード:
金融系システムとかでは、「詳細仕様」まで作られており、プログラマがやることは詳細仕様に沿ってコードを書くこと(詳細仕様をつくるエンジニアがプログラムのことを考えて詳細仕様を作るので、本来のプログラマの仕事が減ってる)
ところが、金融系以外の多くのシステムでは、たとえ名前に「詳細仕様」とあっても、金融系の詳細仕様とは違い、プログラマが自分であれこれ考えないといけない場合が多いのでプログラマの仕事は単純作業ではなく、プログラマも仕様作成に関与したり、「仕様はコードを見ろ」みたいな部分も数多くある
つまり、そのレベルの完璧な詳細仕様を書くのがヤマト運輸の目指す「内製」だ!…と言ってるのかと思ったら、訂正されたところを見ると、そうじゃないんでしょうね。DX担当役員にしてこのレベル…まあ、DXのメインはDでなくてXなんだろうけど…
> DXのメインはDでなくてXなんだろうけど…
ヤマト運輸の場合、X は transformation じゃなくて transportation でしょうね。
金融系以外でも、20年前のSIerではそんな詳細設計書書かされました。まあ設計書書くのもプログラマーだったんで、みんなプログラミングしてから設計書に起こすんですが…。もっと前の時代だと、開発環境的な理由でコーディング自体が一苦労だったと言うので、その頃の文化の残りなんでしょうねぇ。
開発用コンピュータの価格・台数と、人件費やプログラマの人数のバランスによって最適なのが変わってくるのでは?
コンピュータが高価で台数も少ない場合、人があらかじめ詳細仕様まで作ってプログラミングコストを抑えるのが最適で、コンピュータの価格が下がって一人一台開発環境を持つようになると、従来の詳細仕様にあたるのは作らないのが最適なのでは?
gitみたいな集団開発をサポートするシステムによって、さらにその傾向が加速した
そんなの保守できないよ。何を作るのか認識を合わせるための仕様書だからな。個々人が勝手な思い込みだけで作るなっての。
仕様書の代わりにソースコードを見て認識を合わせれば良いのでは?ソースコードが読めない奴が仕様書見ても、何も問題点には気付けないのだし、無駄無駄。
こんなことやってるから、日本のソフトウェア産業は海外と戦えないんだよな。
昔、少しだけ手伝った金融系の仕事も、そんな感じでしたね。ローカルな変数名までガッチリ決まってました。
一般システムの仕様書 「朝10時に秋葉原駅電気街口に集合」と結果だけ指示
金融システムの仕様書 「〇駅の〇番線から〇時〇分発の電車の〇号車に乗る、〇駅で降車して〇番線に移動、〇時〇分発の電車の〇号車に乗る・・・」と途中経路も細かく指示
こんな違い
金融がみんなそんなにお堅いと思ってもらっちゃあ困るぜ。外国為替証拠金取引のシステムやってるけど詳細設計どころか下手すりゃコード値表すらまともにありませんや(とても辛い)。
まあ、システム業界で「金融系」といってまず出てくるのは、投資金額が大きい商業銀行ですよね。
でもその商業銀行でも、トレーディング部門のシステムなんかは、プログラマがその場のアドリブでコードをガンガン変えたりするので文化が違う。
業界の雰囲気も、銀行、証券、ファンド、カード、消費者金融それぞれでかなり違いますからね(短資とかは見たことないから知らない)
FXトレーダーですが、いつもありがとうございます。お疲れ様です。あなたのおかげで生活できてます。
その割にバグだらけでバグ出ると設計者ではなくプログラマに直せと言ってくるのは何故?w
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
金融系の「詳細仕様」まで作ってある場合は単純作業かも (スコア:0)
金融系システムとかでは、「詳細仕様」まで作られており、プログラマがやることは詳細仕様に沿ってコードを書くこと
(詳細仕様をつくるエンジニアがプログラムのことを考えて詳細仕様を作るので、本来のプログラマの仕事が減ってる)
ところが、金融系以外の多くのシステムでは、たとえ名前に「詳細仕様」とあっても、金融系の詳細仕様とは違い、
プログラマが自分であれこれ考えないといけない場合が多いのでプログラマの仕事は単純作業ではなく、
プログラマも仕様作成に関与したり、「仕様はコードを見ろ」みたいな部分も数多くある
Re:金融系の「詳細仕様」まで作ってある場合は単純作業かも (スコア:1)
つまり、そのレベルの完璧な詳細仕様を書くのがヤマト運輸の目指す「内製」だ!
…と言ってるのかと思ったら、訂正されたところを見ると、そうじゃないんでしょうね。
DX担当役員にしてこのレベル…まあ、DXのメインはDでなくてXなんだろうけど…
Re:金融系の「詳細仕様」まで作ってある場合は単純作業かも (スコア:2)
> DXのメインはDでなくてXなんだろうけど…
ヤマト運輸の場合、X は transformation じゃなくて transportation でしょうね。
Re: (スコア:0)
金融系以外でも、20年前のSIerではそんな詳細設計書書かされました。
まあ設計書書くのもプログラマーだったんで、みんなプログラミングしてから設計書に起こすんですが…。
もっと前の時代だと、開発環境的な理由でコーディング自体が一苦労だったと言うので、その頃の文化の残りなんでしょうねぇ。
Re: (スコア:0)
開発用コンピュータの価格・台数と、人件費やプログラマの人数のバランスによって最適なのが変わってくるのでは?
コンピュータが高価で台数も少ない場合、人があらかじめ詳細仕様まで作ってプログラミングコストを抑えるのが最適で、
コンピュータの価格が下がって一人一台開発環境を持つようになると、従来の詳細仕様にあたるのは作らないのが最適なのでは?
gitみたいな集団開発をサポートするシステムによって、さらにその傾向が加速した
Re: (スコア:0)
そんなの保守できないよ。
何を作るのか認識を合わせるための仕様書だからな。
個々人が勝手な思い込みだけで作るなっての。
Re: (スコア:0)
仕様書の代わりにソースコードを見て認識を合わせれば良いのでは?
ソースコードが読めない奴が仕様書見ても、何も問題点には気付けないのだし、無駄無駄。
Re: (スコア:0)
こんなことやってるから、日本のソフトウェア産業は海外と戦えないんだよな。
Re: (スコア:0)
昔、少しだけ手伝った金融系の仕事も、そんな感じでしたね。
ローカルな変数名までガッチリ決まってました。
Re: (スコア:0)
一般システムの仕様書
「朝10時に秋葉原駅電気街口に集合」と結果だけ指示
金融システムの仕様書
「〇駅の〇番線から〇時〇分発の電車の〇号車に乗る、〇駅で降車して〇番線に移動、〇時〇分発の電車の〇号車に乗る・・・」と途中経路も細かく指示
こんな違い
Re: (スコア:0)
金融がみんなそんなにお堅いと思ってもらっちゃあ困るぜ。
外国為替証拠金取引のシステムやってるけど詳細設計どころか下手すりゃコード値表すらまともにありませんや(とても辛い)。
Re:金融系の「詳細仕様」まで作ってある場合は単純作業かも (スコア:1)
まあ、システム業界で「金融系」といってまず出てくるのは、
投資金額が大きい商業銀行ですよね。
でもその商業銀行でも、トレーディング部門のシステムなんかは、プログラマがその場のアドリブでコードをガンガン変えたりするので文化が違う。
業界の雰囲気も、銀行、証券、ファンド、カード、消費者金融それぞれでかなり違いますからね(短資とかは見たことないから知らない)
Re: (スコア:0)
FXトレーダーですが、いつもありがとうございます。お疲れ様です。あなたのおかげで生活できてます。
Re: (スコア:0)
その割にバグだらけでバグ出ると設計者ではなくプログラマに直せと言ってくるのは何故?w