ここで言うタレントとはテレビ番組をにぎやかに彩る職業ではなく、字義どおりの「才能（を持つ人）」のことだ。とはいえ、なんらかの技能ゆえに起用されるという意味で、芸能人とシステム開発者の間に本質的な違いはない。芸能人が所属する芸能事務所とシステム開発企業にも本質的な違いはない。問題は、システム開発企業（および派遣会社）に、自分たちがタレント商売をやっているという自覚がない点だ。 タレントは厳しい仕事 芸能事務所の営業は「タレントカタログ」を用いる。それを示しながら各タレントの持ち味や得意分野や実績を説明して、顧客の要望に沿った提案を絞り込んでゆく。タレントは金額ランク別に分類されており、売れっ子にバイネームで依頼が来るケースもあるが高ランクなので、有望な新人やコスパの良い人材を提供するためにカタログが欠かせない。結果的に、売れっ子であっても無名であってもバイネームで契約される。 契約を取るだけ

InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architect. View an example

「ソフトウェアの「詳細設計書」とはなんなのか」というブログ記事を読んで考えたこと。設計に関するプロセスとドキュメンテーションの関係性についての考えの整理。SI屋的な視点で。 2024/8/18追記：文中にあった雑な文系disが不愉快というご指摘を受けました。ご指摘の通りだと思いましたので訂正しています。大変失礼しました。 「詳細設計書」とはなんなのか nowokay.hatenablog.com こちらの記事では詳細設計書とは以下のようなものであると整理されている。 表現を変えたコーディング（の一種） 机上プロトタイプ（の一種） 分析資料 保守（のための）資料 （水平作業の場合の）作業指示書 （委託している場合の）契約資料 上記以外で考えられるのは次のようなものがあるだろう 利害関係者が要求している たとえば受託開発において発注者が要求している場合 ほかには連携している相手先システム側から

「設計書」というのは、作るものの構造を抽象的に表現したものと言うことができます。 ただ、ソフトウェアの抽象化の仕組みはプログラミングコード自体に備わっているので、ソフトウェア生成可能な抽象的表現というのはコード表現ができるはずですね。コードで表現しておくと、整合性のチェックとかも行いやすいです。 でも、コードではない「詳細設計書」というものが一部業界には必要とされているので、その「詳細設計書」というのは実際はなんなのか考えてみます。 ※ 最初はタイトルは「設計書」としてましたが、話を限定するため「詳細設計書」に変更しました。 追記：納品物に関する記述を追加しました。 表現を変えたコーディング ソフトウェア生成可能な抽象的表現というのはコード表現ができるわけですが、文字で表記する必要もなく、ダイアグラムで表現することもできますね。 代表的なのがER図やクラス図で、これは文字表現との相互変換が

多重下請けではエンジニアが育たないという話を前回のブログで引用していたのですが、そもそも多重下請けではまともなソフトウェアは開発できないんではないかという気持ちになりました。 多重下請けでは、上位受け会社の「SE」が「設計」を行い、下位受け会社の「PG」が実装を行うという役割分担があります。というか、今回の話はそういう役割分担がある多重下請けを前提とします。 そうすると、設計というのは会社間をまたがった契約文書であり、発注のための作業指示書であるということになります。ソフトウェア開発で本質的に必要な文書というよりは、ビジネス構造によって必要になったビジネス文書です。ちなみに派遣ではなく業務委託のはずなので詳細な作業指示になってはいけないのもポイントです。 ※余談ですが「設計は必要である」という人の話をきいてみると、必要なのは実装のための設計ではなく保守のためのドキュメントということがほとん

👋 Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover topics related to Big Tech and startups through the lens of engineering managers and senior engineers. In this article, we cover one out of three topics from today’s subscriber-only The Pulse issue. Subscribe to get issues like this in your inbox, every week. It’s 29th February, a once-eve

beyond-hardware-agile.connpass.com こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。 会の概要 会の様子 森崎先生からのオープニング 森崎先生からの補足つき同時視聴 発表後の感想戦 いろいろな品種と充足度 ハードウェア前提の狩野モデルをソフトウェアに適用する難しさ 狩野モデルの使い方 品質の定義に関する議論 アリストテレスにおけるクオリティとアジャイルにおけるクオリティ 会全体を通した感想 会の概要 タイトル通り、RSGT2024の狩野先生の講演を森崎先生の解説で同時視聴していくイベントです。 会の様子 森崎先生からのオープニング 及部さんから簡単にオープニングがあった後、森崎先生から話を聞く上での前提がありました。 今回の話は、非常に多くの示唆に富んでいる一方で、BFの3段階/ボブとメアリーの話に関しては、ジェンダーギャップに

QAの仕事のひとつとして大事なものに、ソフトウェアやサービスが期待と同じ動きをしていない事象を見つけたら報告して直してもらうことがあります。また、この様な事象を分析して原因を理解したり、再発しないようにしたりすることもあります。この事象は「バグ」「障害」「不具合」「欠陥」といったさまざまな用語が使われます。 この用語は、標準ごとに微妙に言い方がちがう場合があるため、「どの用語が正しいんだ！」というような議論をしても収集つかないと思います。 私のおすすめは、段階ごとの意味を理解してしまうことです、用語は、標準を参考にしていいと思いますが、最終的には、各組織で定義すればいいと思います。 では、段階ごとの意味としてどういうものがあるかを書いていきます。 1段階：期待結果と実際の結果が異なるテスト実行したときに、「あれ、これだめじゃん」ってなってしまうときのことです。例えば、本来はサービスでデータ

After reading this post, check out a more recent post: Bounded Context Canvas V2 How do we break a large system into smaller, more manageable modular components? This is the question I get asked the most, so I’ve put together this article describing a workshop recipe you can use. In Domain-Driven Design, a large system is decomposed into bounded contexts, which become natural boundaries in code as

This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages) The topic of this article may not meet Wikipedia's general notability guideline. Please help to demonstrate the notability of the topic by citing reliable secondary sources that are independent of the topic and provide significant coverage of it beyond a

Build Better Business Software by Telling and Visualizing Stories Storytelling is at the heart of human communication—why not use it to overcome costly misunderstandings when designing software? By telling and visualizing stories, domain experts and team members make business processes and domain knowledge tangible. Domain Storytelling enables everyone to understand the relevant people, activities

※品質保証のエンジニアである筆者が自省・戒めのために書いた記事になります 品質管理（Quality Control）、品質マネジメントは国内では製造業を中心に発展し、プロダクトの競争力向上に貢献してきました。 JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて、独立性を保った品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。 この品質保証部門が権力を持ち、品質ゲートの門番として振る舞う体制は、今であっても、ある面で恩恵を提供しています。例えば次のようなものです： 法規制対応、標準化対応、その他公的なガバナンス要求へ

今回は、要求仕様フェーズを進める時の問題点を解説します。ソフトウェア開発の全ての悪は、要求仕様書から生まれます。「パンドラの箱」のようなものですが、ちゃんと「希望」も残っています。 ⇒連載「山浦恒央の“くみこみ”な話」バックナンバー 2．要求仕様フェーズでは何をするのか 図1に、新しいソフトウェアのアイデアを思い付き、それを製品化するまでの流れを示します。 2.1 要求仕様フェーズ ソフトウェア開発の最初の工程が「要求仕様フェーズ」で、頭の中のアイデアを具体的に記述する工程です。製品にできることや機能を細かく書いた要求仕様書を作ります。「要求仕様書」と聞くと、「大統領所信表明書」のように物々しく感じますが、電気製品を買うと付いてくる「製品取扱説明書」と完全に同じものです。 取扱説明書は、一般ユーザー向けのドキュメントで、そこには「（1）以下の部品がそろっていることを確認してください……、（

2023-11-21 技術的負債に向き合う Online Conference https://findy.connpass.com/event/297813/