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

本記事について 国内の IT 業界について、ネット上では「SIer」VS「Web系」の構図がしばしば見られる。本記事は前者、SIer の世界観をひとりの当事者として雑多にまとめたものである。記事としては読み物、特にポエムの類。 対象読者 以下を想定する。 ITエンジニアまたはその卵で、 SIerを知らないWeb系の人 SIerに入社した新人や中途入職者 SIerにてSEまたはマネージャーして働いている者 SIerにてSEではないが裏方で働いている者（開発、研究、調査、教育、管理など） 学習や就労の初歩として参考にしてもいいし、議論やキャリアのダシに使っても良いだろう。 筆者について 吉良野すた: https://stakiran.github.io/stakiran/ 国内の大手 SIer に勤めるサラリーマン。現場には出ておらず、裏方で支えてメシを食べている。SI にも IT にもさほど

米ガートナー「ソフトウェアエンジニアリングのハイプサイクル2023年」を発表。「生成AI」や「プラットフォームエンジニアリング」は過度な期待のピーク 米調査会社のガートナーは、「Hype Cycle for Software Engineering, 2023」（ソフトウェアエンジニアリングのハイプサイクル2023）を発表しました。 ガートナーのハイプサイクルは、技術の登場から安定までを5つのステージに分けて説明したものです。5つのステージは、「黎明期」から始まり、「『過度な期待』のピーク期」「幻滅期」「啓発期」「生産性の安定期」まで。この途中で消えていく技術もあります。 毎年8月頃に「先進テクノロジーのハイプサイクル」が発表されているのはよく知られていますが、同社はそれ以外のさまざまな分野におけるハイプサイクルも発表しています。今回発表されたのもそうしたものの1つで、ソフトウェアエンジニ

2023年度リクルート エンジニアコース新人研修の講義資料です

独立行政法人情報処理推進機構（IPA）は、経済産業省からの要請を受けて、重要情報を扱うシステムにおけるサービスの安定供給にあたって、そのシステムのオーナーである管理者が、必要な対策を策定できる「重要情報を扱うシステムの要求策定ガイド」を公開しました。 概要 通信や電力などをはじめとした重要情報を扱うシステムには、サービスの安定供給が強く求められ、非平常時でも自らの統制力を確保する「自律性」が要求されます。一方で、ビジネス環境や技術環境がめまぐるしく変化する今日では、変化への対応力など「利便性」を備えたクラウドサービスなどへの要求も高まっています。そこでIPAは、重要情報を扱うシステムの構築・調達・運用時に、管理者が「自律性」と「利便性」の双方を両立したシステムの要求仕様を策定できるようガイドを定めました。 本ガイドは管理者が環境の変化を捉え、それに伴う問題・リスクや利便性の要素を整理し、対

PRESS RELEASE 2023年6月19日 株式会社みずほフィナンシャルグループ 富士通株式会社 〈みずほ〉と富士通、システム開発・保守に生成AIを活用する共同実証実験を開始 株式会社みずほフィナンシャルグループ（執行役社長：木原 正裕）と富士通株式会社（代表取締役社長：時田 隆仁、以下「富士通」）は、富士通が有する生成AIの活用を通じて、〈みずほ〉のシステム開発・保守フェーズにおける品質向上やレジリエンス向上を目指す実証実験を、本日から2024年3月31日まで共同で実施します。 〈みずほ〉では、システム開発・保守フェーズにおける品質向上やレジリエンス向上に継続して取り組んでおり、富士通では、2023年6月9日より、AIプラットフォーム「Fujitsu Kozuchi (code name) - Fujitsu AI Platform」を通じて生成AIコアエンジンを提供開始しています

2023年6月10日に発売の拙著「人が増えても速くならない　～変化を抱擁せよ～」は、経営者やマネージャの方々がソフトウェア開発の経験がなかったとしても、その本質を掴めればと思って書きました。 今や経営や事業をしていく上でITを使ったシステムは欠かせなくなっており、関わらないわけにはいきません。特に、事業そのものにソフトウェアを内包している場合において、ただ使うだけでなく開発して活用していく必要があります。 そこでソフトウェアと、ソフトウェアを作るエンジニアたちをマネジメントしていかねばならないとき、従来通りのマネジメントをしていると、うまくいかないときが出てきます。 ソフトウェアとエンジニアのマネジメントは、ともすれば直感的なものから外れていることがあります。本のタイトルにある「人が増えても速くならない」のも、その一つです。 本書では章の目次ごとに、そうした直感とは違っているソフトウェアな

近年のソフトウェア業界では、テスト関連活動を担うエンジニアを「QAエンジニア」と呼ぶようになっています。ただQA（品質保証）という言葉は、旧来から二つの定義が共存しているほか、業界内の通例で更に別の意味付けが行われた結果、定義が曖昧になり誤解を生みがちな状態となっています。 そこで今回は、日本語圏で、QA（品質保証）の言葉がどのように定義されているか、整理して解説します（結論からいうと三流派あります） 国際標準規格での定義：品質マネジメントシステムの実証 IEEEやISOといった国際的な標準規格、およびそれに準拠した知識体系や標準では、古くから体系立てて品質マネジメント、品質保証、品質管理の定義を行っています。 有力な文献として、品質マネジメントの標準規格である、ISO 9000：2015の定義を紹介します。 まずISO 9000では、品質保証の前提として品質マネジメントという用語を使って

# ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す https://www.youtube.com/watch?v=PSCmjrrbNkg # Howだけ考えると複雑さを導入して仕事が増える https://soudai.h…

タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す

先日 OpenAI からChatGPTが Beta 公開された ChatGPT ではどんな質問に対しても何かしらの回答を生成してくれるのだが、ソースコードに関しても中々の筋が良さそうな雰囲気のコード片を生成してくれるということで少し話題になっていた こうしたプログラムを生成してくれる AI が発展していく中でどういう具合にプログラマの仕事が奪われていくのか興味がある 特に以下ではweb アプリやモバイルアプリなどのアプリケーションの開発においてという文脈で考えることにする まず AI がプログラマの仕事を奪うまでにはいくつかの段階があると思う コード支援レベル 現状はGitHub Copilotのようなコーディング支援を行うレベルの AI はある程度実用レベルになっている 自分は Copilot が生成したコード片をプロダクションコードに含めるのは権利関係の問題もあり様子見している しかし

バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。

こんにちは丸山@h13i32maruです。つい先日、devchat.fmというポッドキャストに出演して、「ドキュメント」というお題について話しました。なぜこんなニッチなお題について話したかというと、Ubie Discoveryに入社して5ヶ月の間にいくつか*1まとまったソフトウェアドキュメントを書いたので、自分の中でホットな話題だったからです。 #devchatfm 33回目は、Ubie DiscoveryのSWE @h13i32maru にドキュメントを書くことで得られるメリットや、ポイント・工夫などを聞きました！ #33 チームの生産性を上げるドキュメントのすすめ with@h13i32maruhttps://t.co/TrmZd13D91— 久保 恒太 / Ubie CEO (@quvo_ubie) 2021年8月12日 これらのドキュメントは個人的にわりと良く書けたと思ってますし、

最近はいかにエンジニアリングの立場でプロダクトを成長させられるかについて考えている。そこで、現代のソフトウェア開発やアジャイルについて学ぶため、同僚にオススメされた「正しいものを正しくつくる」を読んだ。 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について 作者:市谷聡啓ビー・エヌ・エヌ新社Amazon なぜ現代ソフトウェア開発は難しいのかから始まり、現代ソフトウェア開発の不確実性へ対処するためにアジャイルを利用するという流れになっていて非常にわかりやすかった。また「正しいものをつくる」ことと「正しくつくる」ことをうまく切り分けて説明してくれたので、自分の中で論点を整理しやすかった。 「正しくつくる」部分に関しては、これまで自分も注力してきたところであったので、かなり経験知を言語化できた。一方「正しいものをつくる」部分に関しては、まだ経験が

※ヘッダー画像引用：「国内の銀行間振込業務におけるブロックチェーン技術の実証実験に係る報告書」（ブロックチェーン研究会, 2015） 先日、下記の記事で告知した決済システム勉強会を開催しましたので、その内容をベースにして、記事化しました。 周知の通り、2020年に入ってから、公正取引委員会の報告書が発端となって、全銀システムの改革の検討が進んでおり、また、中央銀行によるCBDCの実証実験の検討も具体化しており、決済システム周辺の動きが加速しています。 今回取り扱うテーマである「決済システム」は、ニッチな領域かとは思いますが、上記のような金融改革の動向を理解するための一助になればと思い記事にしました。 先日の勉強会では、DTNS・RTGSという主要な決済システムの類型に関しても触れましたが、長くなりますので分割して、この記事では前段の「決済の基礎」と「決済のリスク」について書きます。 日銀ネ

いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・　良い仕様書がもたらす 5 つの効果 ・　仕様書の重要性が増していく 2 つの理由 ・　仕様書に含めたい 14 の項目・実戦編 ・　仕様書作成時に心に留めたい 3 つのこと ・　具体的な仕様書サンプル（

2012年に Heroku のエンジニアによって提唱された「The Twelve-Factor App」は素晴らしく，アプリケーションをうまく開発し，うまく運用するための「ベストプラクティス」として知られている．2020年になった現在でもよく引用されていると思う．日本語訳もある． 12factor.net Beyond the Twelve-Factor App とは？ クラウド化が進むなど，提唱された2012年と比較すると技術的な変化もあり，今までの「The Twelve-Factor App」で宣言されていた観点以外にも必要な観点やベストプラクティスがあるのでは？という意見もある．そこで，2016年に Pivotal のエンジニアが「Beyond the Twelve-Factor App」を提唱した．The Twelve-Factor App にあった「12項目をアップデート」し，新

エンジニリング組織の作り方 @ Sansan Innovation Lab @yuuk1t / id:y_uuki https://sansan.connpass.com/event/125822/

「開発の丸投げやめて」　疲弊するAIベンダーの静かな怒りと、依頼主に“最低限”望むこと：これからのAIの話をしよう（覆面AIベンダー編）（1/5 ページ） AI（人工知能）開発を丸投げするクライアントの「いきなり！AI」に苦悩するAIベンダー。データサイエンティストのマスクド・アナライズさんに、AI開発現場の実態と、依頼主に最低限望むことを聞いた。 「AI（人工知能）は触ったことないし、プログラムも書けません。でも社長が“AIをやれ”って言うので何とかしてください」――こんな困ったオジサンたちを、ユーモアたっぷりの愛と皮肉で表現する人物をご存じでしょうか。 その名は「マスクド・アナライズ」さん。正体は一切不明でソーシャル上のアイコンは覆面マスクと、一見イロモノ系アカウントに見えますが、Twitterでの発言は多くの人たちから「あるある」「共感する」と絶賛され、ときには何千回、何万回とRTや

あなたたちは、本当に「AI開発プロジェクト」をやる気があるのか？：真説・人工知能に関する12の誤解【特別編】（1/3 ページ） データもない、分析技術もない、開発するエンジニアもいない――。AIを開発しようという企業には「3つのカベ」が立ちはだかるといわれていますが、それよりももっと根本的な「当事者意識」の問題があるのを知っていますか？ 第3次AIブームを背景に、最近では多くの企業がAIの導入を検討しています。今や大企業の4社に1社がAIを導入しているという調査もあるほどです。メディアを通じて成功事例が知られるようになってきましたが、AIの導入はそんなに簡単な話ではありません。例えば、次の会話のような状況でプロジェクトを始めると、どうなるでしょうか。 A：AIで新製品の需要予測をしたいんですけども、どうしたらいいですか？ B：予測して、その後どうするんですか？ A：えっ……分析してから考え