はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間

ソフトウェア製品の開発を念頭に、少しだけ悩みを書いてみます。綺麗なオチはないかもしれません。 ソフトウェア開発におけるアーキテクトの役割時既に遅し経験上、サービス要件や業務要件を詰めている段階には既にUIのナビゲーション基本設計に着手し始めていないと、プロジェクトとして手遅れになる可能性が高く、この辺りの感度と認識のズレをどのようにして解消できるのだろうかというような課題感がありまして、どれだけ案件を経験しても毎度難しいと感じます。 私はある職務上ではアーキテクトと名乗り、主にソフトウェア製品のUIの構造設計やアーキテクチャ構築を支援する仕事もしています。クライアントワークにがっつり取り組んでいた時期には、マネージャから呼ばれて現場サポートに赴いた時点ではもう既に基盤となる設計は終えているか、決裁者による承認を終えてしまっているかしており、要するに「デザインにおける手戻り不可逆点」を1つ越

デジタル社会を実現するためには、「共通ルール」の下で関係者が協働し、価値を生み出すことが重要です。 デジタル社会推進標準ガイドライン群は、サービス・業務改革並びにこれらに伴う政府情報システムの整備及び管理についての手続・手順や、各種技術標準等に関する共通ルールや参考ドキュメントをまとめたものです。 各ドキュメントの位置づけには、次の2種類が存在します。 標準ガイドライン（Normative）：政府情報システムの整備及び管理に関するルールとして順守する内容を定めたドキュメント実践ガイドブック（Informative）：参考とするドキュメントこれまでは、「デジタル・ガバメント推進標準ガイドライン群」という名称で各種ガイドラインを策定しておりましたが、デジタル庁として政府内部だけでなく社会全体のデジタル化を推進するという観点から、これらのドキュメント体系の名称について「デジタル社会推進標準ガイド

発注者ビューガイドラインとは何か 発注者ビューガイドラインというものをご存じでしょうか？ ソフトウェアテストに関する仕事をされている方には馴染みが無いかもしれません。 発注者ビューガイドライン（以下、ガイドラインと言います）とは、設計書の書き方のコツやレビューのコツをまとめたもので、「⁠実践的アプローチに基づく要求仕様の発注者ビュー検討会※1」（⁠以下、検討会と言います）が作成しました。 すべてのガイドラインがそろって公開されたのは、2008年3月18日です。ガイドラインは以下のホームページよりダウンロードできます。 http://www.nttdata.co.jp/cview/index.html このガイドラインは、私たち開発者の視点ではなく発注者の視点でさまざまなコツを集めています。「⁠発注者視点」これが大事です。開発者だけがわかる設計書ではなく、システムをあまりご存じでないお客様に

こんにちは、SOMPO Digital LabデザインチームのUIデザイナー・プロダクトデザイナーの金（https://twitter.com/seikei_kin ）です。 管理画面、SaaS、業務システムからto Cアプリにいたるまで、ウェブサイトやアプリケーションの中には、ただ情報を閲覧するだけではなく、数値や情報などのデータを表示したり登録したり操作したりする役割のものがあります、というよりそちらの方がむしろ多いかもしれません。 そのようなアプリケーションをデザインする場合、なんとなく見た目的にはそれっぽくデザインできても、いざ開発しようとするといろいろ考慮が足りなかったり、実際に使うユーザーの観点から振り返ると過不足があったり……、といった経験をしたことがあるデザイナーは少なくないのではないでしょうか。 今回のnoteではそのようなウェブサイトやアプリをデザインする上で、データの

2021年12月3日に本テキストブックを題材に、デザイン経営の考え方や導入方法、テキストブックの制作秘話などについて語るオンラインイベントが開催されました。下記のリンク先からアーカイブ動画をご覧いただけます。 詳しくはこちら（外部サイト） > 富士通のこれまでの実践から得られたノウハウと、イタリアのミラノ工科大学デザインスクールPOLI.Designの研究成果やフィロソフィーを組み合わせた、デザイン思考のテキストブック「Transformation by Design デジタルトランスフォーメーションに挑戦するデザイン戦略とサービスプランニング」（日本語版・英語版）を公開いたします。このテキストブックはPDFで閲覧可能です。またテキストブック制作の背景や制作チームの想いなど、制作のディレクターを務めた宇多村志伸と高嶋大介に話を聞きましたので、ぜひダウンロードの際に併せてお読みください。

はじめに システムの全容をわかりやすい絵で表し、エンジニア・プロダクト担当者・インフラ担当者間で共有・議論できる何かがあれば便利ですよね。 そんな課題を解決する方法の１つとしてロバストネス（分析）図を紹介いたします。 ロバストネス図は、ユースケース駆動開発／ICONIXプロセスの中でも登場する図です。 これはユースケースによる要求を理解し、理解した要求から曖昧さを排除し、要求と設計とのギャップを埋めるものとしています。 言い換えると、プロダクト側担当者の要求と、エンジニアの設計書を結びつけるための表現方法であるということです。 私はこの手法を長年愛用しておりまして、いくつかのアレンジを加えてきました。 なのでここで紹介するロバストネス図は、一般的なものとは異なっているのでご了承ください。 この記事はどんな人に読んでもらいたいか？ こんな思いがある方がいたら、本記事はお役に立てるかと思います

Shippioでプロダクトデザイナーをしている西藤です。 今年の6月ごろから、Shippioの社内オペレーター向けのプロダクト（貿易業務をサポートするためのShippio社内で使う管理画面）で、大きな改修を行っています。 Shippioでは、貿易業務をサポートする3つのプロダクトがあり、今回、改修を行ったのは真ん中の「社内オペレーター向け」プロダクト今回の改修は、セールス・パートナーセールス、オペレーターなどさまざまな役割の人が触る、非常に複雑な業務を対象としています。 管理画面を触る、Shippio社内メンバーのユーザーシナリオの一部。 「貿易業務の見積もりをお客さまに提示する」という流れだけでも、 1. 価格を見積もるメンバー 2. 見積もりから比較をし、ベストなプランをお客さまに提示するメンバー 3. 実際に貿易を行う船の予約など、オペレーションを担当するメンバー などなど、さまざま

Developers Summit 2021 Summer［A-1］アジリティを支える品質特性 講演日時: 2021年07月30日（金） 10:00 ～ 10:45 概要: ビジネスにとってITは、「あると便利」から「有効」、「不可欠」を経て「中核そのもの」になりつつあり、柔軟かつ俊敏にソフトウェアエンジニアリングを進める力は企業の競争力の源泉となりました。本セッションでは、そのような競争力あるソフトウェアを開発し続ける力を構成する要素を、品質特性等の側面から掘り下げていきたいと考えています。

はじめに 本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。 https://xtech.nikkei.com/atcl/nxt/column/18/01394/ 有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。 第1回：技術的負債はなぜ生じるか。 第2回：ソフトウエア開発を「制御」する意外な処方箋 第3回：技術的負債への取り組みはなぜ「２つのDX」につながるのか。 第1回：技術的負債はなぜ生じるか。 年間12兆円ものマイナスの影響をもたらす技術的負債（あるいはレガシーシステム）はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫り

最近何かと騒がしいクリーンアーキテクチャですが、丁度プロダクトで採用したところだったので折角なので情報共有ということで Qiita の初記事にしてみようと思います。 こちらの記事は GUI や CUI のアプリケーションを対象にしています。 Java コードの記事リンク：https://nrslib.com/clean-architecture-with-java/?preview_id=1263&preview_nonce=542ba7b70f&_thumbnail_id=1293&preview=true その他解説もしています。もしよろしければチャンネル登録をお願いいたします。 より実践的なコード（WEBアプリケーション）: https://github.com/nrslib/itddd/tree/master/CleanLike YouTube での解説（WEBアプリケーション）：

#asken_dev「設計の考え方とやり方」勉強会 https://asken.connpass.com/event/254709/ ・良い設計は悪い設計より変更が楽で安全である ・ドメインモデル方式のクラス設計 ・イミュータブル方式のテーブル設計 ・設計スキルの身につけかた ・設計のためのモデリング