実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
プログラマーを解雇して新しい人員に置き換えることがソフトウェアにとって致命的になり得るという指摘
IT業界は人材の入れ替わりが激しいことが知られており、有能な開発者は好待遇を求めてさまざまなチームを渡り歩いているほか、企業側も不景気時には積極的に人員整理を行います。ところが、ソフトウェア開発チームの運営に関する複数の著書を持つBaldur Bjarnason氏は、「プログラマーを解雇して新しい人員に置き換えることは、ソフトウェアにとって致命的になり得る」と主張しています。 Theory-building and why employee churn is lethal to software companies – Baldur Bjarnason https://www.baldurbjarnason.com/2022/theory-building/ Bjarnason氏はソフトウェアのプログラマーを庭師にたとえた上で、「ソフトウェアは一時的な庭であり、その運命は庭師と密接に関わっ
現代のソフトウェア工学を示す「継続的デリバリーのソフトウェア工学」 - Shin x Blog
年末年始に「継続的デリバリーのソフトウェア工学」を読みました。新年を迎えて、気分を一新して開発を始めるのに良い本でした。 ソフトウェア開発に役立つプラクティスを示した本 学びのエキスパート 複雑さ管理のエキスパート 実践的なツール データに基づく指標 ソースコードに限らずに広く適用 ソフトウェア開発者としての矜持 TDD あちら側とこちら側 「継続的デリバリー」は 1 要素 さいごに ソフトウェア開発に役立つプラクティスを示した本 ソフトウェア工学とは、ソフトウェアの実際的な問題に対する効率的、経済的な解を見つけるための経験的、科学的アプローチの応用のことである。 1.2 「ソフトウェア工学と何か」 本書では、ソフトウェア開発の現場で役立つプラクティスを、ソフトウェア工学としてまとめています。ここでいう科学的アプローチとは、「特徴づけ」「仮説の定立」「予測」「実験」という形で思考を組み立て
ソフトウェアを完成させる - blog.8-p.info
Why is building the Ruby environment hard? の、 ソフトウェアは何もしないと壊れる というのは事実ではあるんだけど、それが良いことかというと、どうなのかなあと思う。ほかにも、我々プログラマはつい「ソフトウェアは完成しない」とかいってしまうし、それは雇用のためには良いことなんだろうけど、でも本当に完成しないんだろうか。 Go の logrus の README には、こんな段落がある。 Logrus is in maintenance-mode. We will not be introducing new features. It’s simply too hard to do in a way that won’t break many people’s projects, which is the last thing you want fro
システム開発の内製化って本当に必要なのだろうか - novtanの日常
comemo.nikkei.com そもそもの話としてなんですが「システム」という言葉が主語デカなんですよねえ、というところから話をスタートしたい。 本来、システム開発の歴史をたどると、初期の大企業（銀行とか）はまあまあ内製化からスタートしていることが多いと思うんですよね。ただ、ここでいう内製化ってのは全部をその会社に所属している人が作っている、というわけでは当然ながら、ないです。ハードウェアはベンダーに依存しているし、開発自体もSIerの手を借りることは多かったはず。ただ、自分たちで要件を決めて、仕様を検討して、設計して、テストする、という意味においては間違いなく内製化をしていたはず。 そういう基幹系システムがコンパクトに中小企業に展開されるようになると、そんな体力は当然ないので実質パッケージみたいな形で導入されていったというところでしょうか。 こういう企業内システムはいわゆる「電算化」
中田の質問箱です
みずほ関係者の方でしょうか。連日のように繰り返されるシステム障害とその批判を目の当たりにして疲弊しているのだろうとお察しします。ただ、仰っている内容はどれも妥当性に乏しいので、公言されるとますます批判の声が強まってしまうことが危惧されます。ご自身の反論が有効かどうかを検証する有力な方法は「他の2メガバンクではこのロジックは通用するか？」という考え方です。以下、すべてこのアプローチでご説明します。 まず「銀行リテールの利益は250億円しかなく赤字のこともあるのだから莫大な設備投資をすることは株主にとって妥当ではない」というのは論理が全く逆で、莫大な設備投資をしたのですからもっと稼がなければならないのに稼げていないことが問題なのです。MUFGやSMFGをご覧頂ければ銀行リテールだけでも1,000億円単位で儲けていることがわかるでしょう。しかもシステム統合に要した費用はMUFGで3,300億円、
COCOA騒動メモ
COCOA が動いていなかったことで大臣が謝罪してひと騒動起きている件について、開発者視点からのメモを残してみます。 なぜこのメモを書いたのか 世間的には不正確な情報で叩ければOKの風潮が強くてしんどいので、正しいと思われる情報を拾い集めたものです。中抜きwww 王子wwwww Xamarin wwwwwwww みたいな人にはあんまり興味ないかと思います。 調べ始めたきっかけはこのツイートと引用されたblog記事ですが、記事の内容が違うことはすぐに指摘されて撤回されていたのですが、実際どうだったのかさらに調べてみました。 接触通知アプリ COCOA とはなんなのか 仕組みとか何かは公式サイトでもみてもらうとして。この件で煽っている人でも一部理解できていない人がいるようなのですが、直接的な効果としては 保健所が濃厚接触者追跡をする際の手助けとなるためのアプリ ということになります。アプリをイ
COBOL技術者を絶滅させても何も問題は解決しない | おごちゃんの雑文
最初はもっとキャッチーなタイトルにしようと思ったんだが、そんなしょうもないことしてもしょうもないんで。 そろそろCOBOL絶滅のシナリオを考えようか 「語るに落ちる」とはこのことである。この人はCOBOLに親でも殺されたのだろうか？ こんな炎上芸で問題が解決したら、何の苦労もない。 COBOLのメリットを一々挙げて反論する気はない。しかし、事実として現にCOBOLは多くの場所で使われている。その理由は何か。 あれこれあるのであるが、最大のメリットにして最大のデメリットとして挙げたいと思うのは、 後方互換性の高さ である。 後方互換性が高いことについてのメリットは、誰でもわかることだろう。COBOLもそれを売りにして来た。「古いCOBOL」のコードであっても、現代の最新のCOBOL規格から見てvalidであって、正しく同じ動作をするバイナリが出て来る。COBOLは実に60年近い歴史があるのだ
最近のソフトウェア工学に思うこと - bonotakeの日記
なんかこのブログに記事書くの、ほんと久々だなと思うんですが。 最近ずっと思ってたことがあったので、つい勢いで書きなぐってしまいました。若干炎上商法かもしれませんが、まぁたまには？いいや。 長文ですがお付き合いください。特に、ソフトウェア工学の研究している皆さん。 昨日、とあるソフトウェア工学のシンポジウムにて、機械学習モデルをWebサービスにデプロイするためのハンズオン、という企画がありました。 僕が運営委員やってるMLSEとの共同企画で、僕は発案者の１人ですが、当日は1人の参加者として中に混じっていました。 4人グループに分かれての作業だったんですけども、僕以外の3人は、いずれもソフトウェア工学の研究をしている修士の学生さんでした。 で、ハンズオンも後半になって「Dockerの使い方」の演習になったのですが、その3人ともDockerに触ったことがなさそうな雰囲気でした。いちいち確認したわ
技術的負債というメタファ - みねこあ
技術的負債についてはじめて知ったのは、マーチン・ファウラーの「技術的負債」というエントリーでした。 技術的負債 システムに新しい機能を追加するとしよう。2つのやり方があるはずだ。ひとつは、早いけれど、ぐちゃぐちゃになるやり方（将来、変更が困難になることは分かっているよね）。もうひとつは、キレイな設計だけど、導入に時間のかかるやり方。 「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は（ファイナンなどスの負債と同じく）技術的な負債が発生する、ということになる。 通常の負債と同じく、こちらの負債も利子を払う必要がでてくる。 (中略） このメタファーを使うと、早いけれど汚い方法がなぜよく使われるのか、ということを説明できる。ビジネスの世界で市場機会の優位性を得るために負債
Kazuho's Weblog: 「技術的負債」は避けるべき？ - 割引率を使って考えてみた
「技術的負債」をコントロールする定量評価手法への期待 からの続きです。 ソフトウェアサービス企業における技術責任者の最も重要な仕事のひとつが、エンジニアリングの効率化です。そのためには、サービスの初期開発コストだけでなく、運用コストを織り込んだ上で正しい技術的判断を行っていく必要があります。 「技術的負債」という言葉は、この運用コスト最適化の重要性を指摘する上で、とてもキャッチーなフレーズだと考えられます。しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。 初期開発コストと運用コストのバランス注1を、どのようにとっていけば良いのでしょう？ 同等の機能を提供する「ソフトA」と「ソフトB」を考えてみます。ソフトAは、初期開発工数が6だが、２年目以降の維持工数が毎年4かかるとします注2。ソフトBは、初期開発工数が1
糞システムにしないため、私ができること『はじめよう！ 要件定義』
「なぜ糞システムができあがるか？」の答えは、「一つ前の仕事をしている」に尽きる。 詳しくはリンク先を見てもらうとして、まとめるなら、自分の仕事のインプットが出来てないので、仕方なく前工程の仕事を代行しているうちに、リソースと気力がどんどん失われているからになる。これはプログラマに限らず、SEからPM、テスタや運用を入れても、当てはまる。「何をするのか」が決められない経営層が糞だから、あとはGIGOの法則（Garbage In, Garbage Out）に従う。 では、どうすればよいか？ 「“何をするのか”を決めてもらう」という回答だと、連中と同じ肥溜めに落ちている。なぜなら奴らの“目標”とは、「売上を○％ストレッチする」とか「新規市場を開拓する」といった、現状を裏返した願望にすぎないから。売上アップ／新規開拓のために、どこに注力して、何にリソースを使い、そのために必要な道具（システム）を“
Shibu's Diary: 「納品をなくせばうまくいく」を読んでません
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 「納品」をなくせばうまくいくという本が流行っているみたいです。僕はまだ読んでいませんが、タイトルを一目見れば、倉貫さんファンからすると内容を想像するのは難しくないでしょう。きっと今まで倉貫さんが語ってこられてきたことの集大成であろうと想像しています。 「納品をなくせばうまくいく」の感想part1～ソフトウェア業界のビジネスモデルが抱える問題 こちらのブログにはこのモデルを採用することでいろいろ問題が解決するよね！ということが書かれていますが、こちらに書いてない話で、「なぜダメと分かっている方法論がまかり通っているのか」をまとめてみたいと思います。もしかしたら倉貫さんの本にすでに書かれているかもしれませんが。 ムダのない予算管理がムダを生む ダメなモデルを使い続けているのは、基本
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
C#によるクライアント/サーバーの開発言語統一がもたらす高効率な開発体制 ～プリコネ！グランドマスターズ開発事例～