記事へのコメント75

    • 注目コメント
    • 新着コメント
    ma38su
    ma38su 設計図面と施工図面というたとえはしっくりくる。建築がうまくいってるかというとそうでもないとは思うけど。

    2024/07/17 リンク

    その他
    cocelo
    cocelo 何をもって設計書とするのかが設計書を読む人のスキル、主観によるところが大きいのが話をややこしくしていると思う。慣れた言語ならコード直読みした方がいいだろうし、そうじゃない言語だとdesign docは欲しくなる

    2024/07/17 リンク

    その他
    Eiichiro
    Eiichiro 建築士を客先(納品物のビル)常駐はないが修繕担当部門はあるしビル管理士もいる。SESはビル管理士なんだろう。簡単なメンテや監視をし、アラートを本社に上げる。ビル管理士が建築士になれないのはそりゃそう。

    2024/07/17 リンク

    その他
    harist
    harist ソフトウェアはコードによって動くのであって、設計書ではないところが議論を生むややこしい点ではある。ただ遠くない将来、AIが設計書とコードをほぼイコールに結びつけてくれるのかなと思ってる

    2024/07/17 リンク

    その他
    korint
    korint 自分らで作れば経験も技術も格段に上がる、他人に任せるのは勿体ない。

    2024/07/17 リンク

    その他
    whg_res
    whg_res この辺の本とかおすすめですよ https://www.amazon.co.jp/EMPOWERED-普通のチームが並外れた製品を生み出すプロダクトリーダーシップ-マーティ・ケーガン/dp/4820729241?dplnkId=25282af4-e75c-4e44-8cf9-c1a2b00cf0b0&nodl=1

    2024/07/17 リンク

    その他
    tettekete37564
    tettekete37564 “建築や造船でソフトウェアのソースコードに相当するのは施工図面” < なるほどね

    2024/07/17 リンク

    その他
    jiro68
    jiro68 設計の粒度が語る人によって異なるので何とも言えないが、要件定義が詳細にあれば良いとはならない。その要件をどう実装するかを決めるまでが設計。ソースコードが設計図と言う人はバグも仕様って言う人かな?

    2024/07/17 リンク

    その他
    kagehiens
    kagehiens SIerがカス実装を修正せずに上げてくる構造になっているせいで、ピンポイントに性能向上させたかったら自分でリファクタリングする以外の選択肢がどこにもない。その部分を開発するのに相当する代金返せと言いたい。

    2024/07/17 リンク

    その他
    gaudere
    gaudere 「実装してみないとわからない」「アイデアは実装時に浮かびがち」日曜プログラマや趣味的にコーディングする学生さんが陥りがちな陥穽。あなたが真に独創的で新規性のあるソフトを作っているなら、そうかもね。

    2024/07/17 リンク

    その他
    bellonieta
    bellonieta アジャイルマニフェストとその背後にある12原則はもう20年以上前なのか

    2024/07/17 リンク

    その他
    hexcap
    hexcap そもそも建築業や製造業は完璧を目指しておらず代わりに公差や許容差という概念があります。不完全な成果物の積み上げによる品質のゆれの総和が許容範囲内であればヨシとします。まあ下請けの管理と選別はするけど。

    2024/07/17 リンク

    その他
    sato0427
    sato0427 この業界の人たちって自らエンジニアと名乗るくせに土建屋とは違うという無駄な自尊心抱えてるよね。前工程にフィードバックできない仕事なんていくらでもあるのに、だからいい仕事ができませんって寝言は寝て言えよ

    2024/07/17 リンク

    その他
    tekmak
    tekmak 設計しないPGなんてほとんどいないし、コード書けないのに非機能押さえられるSEもほとんどいないんじゃない?

    2024/07/17 リンク

    その他
    toro-chan
    toro-chan 設計とは、か。規模によるが、PGができないのは要件定義。逆に要件定義が「詳細」にあれば設計はいらない。ソースコードが設計書。ソースコードがわからないのは単に無能に過ぎない。まぁ設計書がないと外注は無理

    2024/07/17 リンク

    その他
    zakinco
    zakinco 『そんな複雑なソフトウェアは請負で作成すべきものではなく、SIの範囲外』ですよねー。そんな仕事を営業が取ってくるアホSI企業とSIに丸投げしようとするアホユーザー企業は全て滅んでください。

    2024/07/17 リンク

    その他
    xlc
    xlc SIの世界に30年以上いるが、業務アプリで “実装してみないとわからないことが多く” などという事態に直面したことはない。そんな複雑なソフトウェアは請負で作成すべきものではなく、SIの範囲外だ。

    2024/07/17 リンク

    その他
    alpon
    alpon いいソフトウェアとは?

    2024/07/16 リンク

    その他
    Sakana_Sakana
    Sakana_Sakana 要は作っている物に対して当事者として自分らの責任で作っているのか、他から命令されて作らされているかの違いで命令されて作る場合は良い物が出来づらいって事だよな、日本海外関係なくそうだと思う。

    2024/07/16 リンク

    その他
    Gka
    Gka 建設の多重下請は分業の結果であり中抜き構造ではないんだよ。ゼネコンの立場で少しでもコストカットしたいなら実際に施工する業者に発注したほうが良いに決まってる。

    2024/07/16 リンク

    その他
    prograti
    prograti アプリケーションアウトソーシングの最大のマーケットはアメリカなのだけど、日本の多重下請けと何が違うのか気になりますね

    2024/07/16 リンク

    その他
    hyperash
    hyperash 実装者のクリエイティビティというか職人芸?に依存するのが「いいソフトウェア」なんだろか。何をもって「いいソフトウェア」とするのか、さらには「技術力」をどう計測するか、という要件定義が必要そう。

    2024/07/16 リンク

    その他
    twainy
    twainy 中小SIにいた時、納品のためにソースコードを元に設計書起こしてたけど、ソースコードの方が読みやすかった。設計書は説明のために一断面を切り取るなら有用だけど全部を設計書で説明するならコード読んだほうがマシ

    2024/07/16 リンク

    その他
    skypenguins
    skypenguins 比喩に限界はあるけど自動車業界で言うクレイモデルがソフトウェアで言う設計書なのでは

    2024/07/16 リンク

    その他
    shun_libra
    shun_libra 設計というかドキュメントは、コードだけでは見えにくい情報を補足する存在でかしかなく、グランドデザインとして必須ではあるが、それ以上細かいことはコードを読めとしか。それこそ書いた通りに動くものだから。

    2024/07/16 リンク

    その他
    kazuppo01
    kazuppo01 結構しっくりきた。つまり建築でいえば施工図面ではなく、アイデアレベルの絵とか模型を渡されて、現場で施工図面作りながら溶接してるのか そりゃ、想像通りにいかないわ

    2024/07/16 リンク

    その他
    R2M
    R2M プロダクトマネージャーがいる企業ってどれだけあるんだろう?

    2024/07/16 リンク

    その他
    nisisinjuku
    nisisinjuku だが、上流は手を動かしている時間がない!!(ドン

    2024/07/16 リンク

    その他
    sigwyg
    sigwyg 建築や造船の話でよく聞くのは、ハードウェアの製造ってほぼ調達コストなので「ほとんどが物理の限界で決まる」ってとこ。ソフトウェアの生産は人力なので、ほぼ全てが変動コスト。要はソフトウェアはアナログだと。

    2024/07/16 リンク

    その他
    yojik
    yojik 最悪なのは設計と実装で一旦契約が分かれて実装からフィードバック出来ないパターン。最低要件定義ぐらいで切ってくれ。要件定義でクソみたいな画面定義、テーブル論理設計(余計なお世話)されて詰む事も多いが

    2024/07/16 リンク

    その他

    注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

    アプリのスクリーンショット
    いまの話題をアプリでチェック!
    • バナー広告なし
    • ミュート機能あり
    • ダークモード搭載
    アプリをダウンロード

    関連記事

    多重下請けでは構造的にいいソフトウェアが作れない - きしだのHatena

    多重下請けではエンジニアが育たないという話を前回のブログで引用していたのですが、そもそも多重下請...

    ブックマークしたユーザー

    • hiiino342024/12/29 hiiino34
    • odakaho2024/09/03 odakaho
    • techtech05212024/08/15 techtech0521
    • knj29182024/08/01 knj2918
    • J1382024/07/22 J138
    • lugecy2024/07/21 lugecy
    • lEDfm4UE2024/07/21 lEDfm4UE
    • hm_hs2024/07/19 hm_hs
    • tamuraki2024/07/18 tamuraki
    • yug12242024/07/18 yug1224
    • no_makibou_no_life2024/07/18 no_makibou_no_life
    • non_1172024/07/18 non_117
    • yugui2024/07/18 yugui
    • syug2024/07/17 syug
    • stntaku2024/07/17 stntaku
    • takur8192024/07/17 takur819
    • k_oshima2024/07/17 k_oshima
    • gamu10122024/07/17 gamu1012
    すべてのユーザーの
    詳細を表示します

    同じサイトの新着

    同じサイトの新着をもっと読む

    いま人気の記事

    いま人気の記事をもっと読む

    いま人気の記事 - テクノロジー

    いま人気の記事 - テクノロジーをもっと読む

    新着記事 - テクノロジー

    新着記事 - テクノロジーをもっと読む

    同時期にブックマークされた記事

    pFad - Phonifier reborn

    Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

    Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


    Alternative Proxies:

    Alternative Proxy

    pFad Proxy

    pFad v3 Proxy

    pFad v4 Proxy