システム開発で曖昧な要望を形にしていく方法 - arclamp
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約（プライム） 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的：達成すべきこと 戦略：目的を確実・効率的に達成するためのシナリオ 戦術：戦略を実行するための具体
2040年問題とITエンジニア - DevLOVE Xに寄せて - arclamp
エモいことで有名なDevLOVEの10周年記念イベントDevLOVE X 〜 それぞれの10年、これからの10年 〜で「エンタープライズ、アーキテクチャ、アジャイルのこれから」という講演をしてきました。資料は以下。 Togetter - #DevLOVEX 鈴木 雄介「エンタープライズ、アーキテクチャ、アジャイルのこれから」 #DevLOVEXC Day2-7C 10年間の振り返り 10年間の振り返りとして10年前に書いた記事や講演資料をみたのですが、わりと一貫していて安心しました。たとえばクラウドを超えた先の企業システム像 20091008 JJUG CCC では、 ・インターフェースによる分業 ーマルチパラダイム ・個々のシチュエーションでは1つの最適な道具（パラダイム） って、まさにマイクロサービスのことだし。日経SYSTEMS 2009年2月号の特集１「10年後も通用するスキル」で
大きなアーキテクチャ設計と小さなアーキテクチャ設計 - arclamp
2017/12/15（金）にエンタープライズアジャイル勉強会2017年12月セミナーで「アジャイル開発を支えるアーキテクチャ設計とは」という話をしました。資料は以下から。 アジャイル開発を支えるアーキテクチャ設計とは 僕の話したかったのは「アーキテクチャ設計といっても『大きなアーキテクチャ設計』と『小さなアーキテクチャ設計』というレベルがあり、後者はチーム内で解決すべきだが、前者はチーム外で解決すべきだ」ということです。 大きなアーキテクチャ設計：システム間連携のレベル→アジャイルチームの外で実施 小さなアーキテクチャ設計：システム内連携のレベル→アジャイルチームの中で実施 なぜ分けるのか、というと、それぞれのレベルで求められる性能も可用性も保守性も違うからです。 小さなアーキテクチャ設計は「チームが好きにすればいい」わけですが、大きなアーキテクチャ設計は「チームをまたがって企業内でそれな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
おじさんにも分かるITトレンド説明と日本のエンプラITの限界 - arclamp