システム開発で曖昧な要望を形にしていく方法 - arclamp
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約（プライム） 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的：達成すべきこと 戦略：目的を確実・効率的に達成するためのシナリオ 戦術：戦略を実行するための具体
ビジネス・アーキテクチャとシステム・アーキテクチャ - Runner in the High
うちのコンサルが「システムアーキテクチャを決めるためには、ビジネスアーキテクチャを先に固めることが必要」と言ったら、お客様が「事業構造の変化が激しすぎてビジネスアーキテクチャを固めることが難しい」と仰った。 そうだよなぁ。システムの寿命よりビジネスの寿命のほうが短くなってるのかも— ボム / SIer (@bombombomb2017) 2021年8月29日 これにめちゃくちゃ共感した。 よくあるアーキテクチャ設計では、ドメイン層と応用層を分離することで応用層におけるコントロール不能な変化をドメイン層に及ばないようにさせたりする。しかし、現実のプロダクト開発ではDBやフレームワークなどの応用層で起きる変化よりもドメイン層の変化のほうが圧倒的に多い。システムにおけるすべての中心にあり、あらゆるところから依存されているドメインが頻繁に変化するとなると非常にツライ。 とはいえ、ビジネス・アーキテ
「運用組織」の考え方と設計 〜 運用組織論 2021 / 20210310-ssmjp-operation-organization
ssmjp ssmonline #8 "第三回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/206074/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
シリコンバレーの「何が」凄いのか
シリコンバレーのスタートアップを数多く取材する中で気付いた「シリコンバレーにおけるディシプリン（規律）の存在」や「General Electric（GE）やIBM、SAPといった老舗企業が必死になってシリコンバレーのスタートアップを真似している理由」、そして「日本企業がイノベーションを実現するための処方箋」について解説します 詳しく知りたい場合は「GE 巨人の復活」をご覧下さい。 http://www.nikkeibp.co.jp/atclpubmkt/book/17/P55110/ 今後の記事は「シリコンバレーNext」をご覧下さい。 http://itpro.nikkeibp.co.jp/siliconvalley/ Read less
ある日曜日に突然かかってきた、スティーブ・ジョブズからの電話 | fladdict
GoogleのVic Gundotraによる、スティーブ・ジョブズのエピソード。 ジョブズ引退によせて、グーグルとジョブズのやりとりを開陳。 グーグルのモバイルアプリ責任者のもとに、日曜日に突然かかってきた電話とは？ とても面白い内容だったので、電車内でiPadで訳してみた。 ———- アイコン急患 2008年1月6日、ある日曜の朝、携帯電話のバイブが振動したとき私は礼拝に参加していた。 即座に携帯をチェックすると電話には非通知と表示されていた。私は無視することにした。 礼拝の後、私は家族と一緒に車に戻りながら留守電をチェックした。 そこに残されたメッセージはスティーブからだった。「ヴィック、私の家に電話をくれるかい？ すぐに議論しなきゃならないことがある」 車に辿り着く前に、私はスティーブに電話をかけなおした。私はGoogleのあらゆるモバイルアプリの責任者であり、職務の一環としてスティ
世の中には「ウェブコミュニティ設計者」という職業がある - jkondoの日記
少し前に映画『ソーシャル・ネットワーク』を観ました。 映画を観た後3時間くらい興奮が収まらず、気を落ち着かせるまでに随分苦労しました。興奮もようやく収まりましたので（笑）、感想を書こうと思います。 なぜそんなに興奮したのか。 1人のプログラマが創ったウェブサービスが世界中に広がったことに対する、プログラマとしての共感。マーク・ザッカーバーグが会社を大きくし、金銭的に大きな成功を収めた事に対する、起業家としての共感。自分の境遇と重なるこうした要素が、他人事では無いストーリーとして、面白かったのです。 しかし、映画を観た他の人の感想を眺めるうちに、他の人が言及していない部分に自分が強く反応していたことに気付きました。「ウェブコミュニティ設計者」としての共感です。ザッカーバーグも自分も、「ウェブコミュニティ設計者」という同じ職業の人間だ！、と強く思いました。 世の中にウェブサイトと呼ばれるものは
日本の家電メーカーが出す商品はなぜ”もっさい”のか - キャズムを超えろ！
もっさい 標 準 語：かっこ悪い・ダサイ 使 用 例：なーんかあれはもっさいよね 意 味：なんかあれはかっこ悪いよね http://inadani.jp/c13/dt/001265.php twitterで @shi3z さんと喧々囂々と話していたネタが面白かったので軽くまとめてBlogネタに。 実は日本だけでなく、世界のどの会社も、Apple以外はiPhoneが作れなかった。それは経営者が美的感覚を軽視し、それを磨くことを怠っていたからだ。 by shi3z というtwitをきっかけに んー。形状判断を意思決定者がデザイナーあるいはデザインセンスのある社員に権限委譲できればいいはず。大手メーカーはできてないけど。 by warenosyo なんてふらりと突っ込んだのが運の尽き（笑） @warenosyo 結局、形状の判断は性能や価格の判断に比べて優先されない。これは最終的には意思決定者
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
広告β:ユニクロと無印と「普通」の想像力
SPA（自分で作って自分で売る業態）の雄、ユニクロと無印。 一時期、似た立ち位置にあるように見えた2つのブランドが、動いている。 ユニクロは記号性を高め、流行を発信しようとしている。 バストイレ系のアイテムでは「ホテル」というコンセプトを打ち出し、 雑誌のようなスタイル提案を始め、サイト制作においても業界の スタークリエイターを片っ端から起用している印象がある。 タレント広告も、以前からやっていたが、露骨さを増した気がする。 いつでも、どこでも、だれでも着られる、 ファッション性のある高品質なベイシックカジュアルを 市場最低価格で継続的に提供する。 そのためにローコスト経営に徹して、 最短、最安で生産と販売を直結させる。 （ユニクロ−ミッション＆ビジョン）これらの方針は、同社の世界戦略から影響されているのかもしれない。 世界に目を転じれば、H&Mなどのメガブランドが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://s3-ap-northeast-1.amazonaws.com/team-lab.com-wp-src-backup/uploads/media/NE070924.pdf