2020年11月14日のブックマーク (3件)

  • 勘違いしていないか?基幹系システムの要件定義は経営者の「仕事」に決まっている

    なぜ日企業の経営者は、ビジネスの根幹を担うシステムの開発をIT部門任せ、あるいはITベンダー任せにするのか。いわゆる丸投げをなぜ続けるのか。以前なら「社長はITに関心がない」あるいは「ITを分からない」がその理由だったが、空前のDX(デジタルトランスフォーメーション)ブームとなった今ではさすがに「関心がない」「分からない」と恥ずかしげもなく言う経営者は表面的には消え去った。 だけど、である。株主や投資家らに「我が社のDX」を熱く語る経営者であっても、それを実現するためのシステム開発では丸投げの場合が多い。さすがに「システム開発は専門家である君たちに任せた」と気持ち良く丸投げするケースは少なく、「私もオーナーシップを発揮して……」などと言ったりするが、何をもってオーナーシップを指すのかがよく分からない。で、オーナーシップはどこへやら、現場主導で粛々と開発が進み、愚にもつかないシステムが出来

    勘違いしていないか?基幹系システムの要件定義は経営者の「仕事」に決まっている
    lorenz_sys
    lorenz_sys 2020/11/14
    要件定義書は当該案件の発注側受注側の合意事項を示すことになるので発注側が単独で作成するのは本来おかしい。(たとえ社内案件であっても) 発注側(経営者)の最初の仕事はRFPを作成するまででよい。
  • 「UNIXという考え方」を読み直して、考えたこと - Magnolia Tech

    UNIXという考え方―その設計思想と哲学 作者:Mike Gancarz発売日: 2001/02/01メディア: 単行 前回エントリで紹介した「リモートワークの達人 (ハヤカワ文庫NF)」は何度も読み返すべきとして紹介してもらったのだけど、その時に同時に上がったのが「UNIXという考え方」という。 確かにこのは自分も何度も読み直している。 なぜおなじ、しかも技術書を読み返す必要が有るのだろう。 もうそこに書かれていることは分かっている。特に古いならなおさらだ。 この「UNIXという考え方」というは、原著が1996年に出版され、日でも2001年に出版された非常に古いだ。 まだLinuxは2.0の時代、商用UNIXの方が信頼度が高いとされていた時代。 もう書かれていることは何度も語られている、語り尽くされている。 それでも今でも読むべき技術書の上位に位置したままランクを落とさ

    「UNIXという考え方」を読み直して、考えたこと - Magnolia Tech
    lorenz_sys
    lorenz_sys 2020/11/14
    "「どこに一番関心を持つか?」というのが変わってくる。" 同意。自分の場合単なるノスタルジーで古い技術書を何度も読み返すということもあるな。もう古くて役に立たないけど捨てられない技術書が何冊かある。
  • ある言語に「統一」することはそもそも不可能なのだ 現時点で、国際語とな..

    ある言語に「統一」することはそもそも不可能なのだ現時点で、国際語となっている英語には、すでに多数のバリエーション(つまり方言)が存在しているのだ。イギリス英語アメリカ英語、オーストラリア英語が違うことはよくネタにもされるので普通に知っているだろうが、英語を母語とする話者が一定いる地域が誕生すればそこには必ず方言が誕生するのだ。仮に日が公用語を英語と定め、数世代あとに日人が英語を母語とするようになっても、気候、歴史文化等々が他とことなるこの地で話される英語は必ず「日英語」、ジャパニーズイングリッシュ、英語の日弁になってしまうのだ。つまり「統一」など最初からできないのだ。(そして、極めてリアルに想像すれば、方言である「日英語」は、英語話者の中では、おそらく社会的に差別される方言になるのだ。日でも、方言話者がどのように扱われるかを見れば、それは簡単に理解できるのだ。) 日

    ある言語に「統一」することはそもそも不可能なのだ 現時点で、国際語とな..
    lorenz_sys
    lorenz_sys 2020/11/14
    こういうレベルがひょこっと出てくるから増田は侮れない。社会言語学に精通されているが文体からして古いので学生ではないと思う。専門家でしょ。"~なのだ"という文体(口調)はアライさん口調と表現するのか。