タグ

システムに関するhigedのブックマーク (60)

  • システム開発で曖昧な要望を形にしていく方法 - arclamp

    このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約(プライム) 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的:達成すべきこと 戦略:目的を確実・効率的に達成するためのシナリオ 戦術:戦略を実行するための具体

    システム開発で曖昧な要望を形にしていく方法 - arclamp
  • メンタルモデルとは何か?マッチングアプリのUIデザインから読み解く4つの概念|Goodpatch Blog グッドパッチブログ

    ユーザーに行なって欲しい操作や行動を導くインターフェイス/インタラクションのデザインを行うために、デザイナーはどんな意識をもつ必要があるのでしょうか。 今回は意識するべき概念の1つとして、メンタルモデルを紹介します。 Goodpatchでは、新規サービスの立ち上げやサービス・プロダクトの改善のご相談も受けております。 ⇒【資料ダウンロード】事業の提供価値を素早くカタチにし価値検証を回すフレームワーク「デザインスプリント」とは? 観客からすれば、映画に夢中になると、光の点滅やスプロケットのことなど忘れてしまう。というより、多くの観客は、映写機の仕組みだとか、それがテレビの仕組みとどのように違うかといったことなどまず知らない。観客は、単純に大画面に動く写真が映し出されているだけだというイメージを持っている。 (引用元:アラン・クーパー『About Face 3 インタラクションデザインの極意』

    メンタルモデルとは何か?マッチングアプリのUIデザインから読み解く4つの概念|Goodpatch Blog グッドパッチブログ
  • 意思決定と業務執行をシームレスにした話(概要編) - LayerX エンジニアブログ

    ご挨拶 毎々お世話になっております、LayerXから三井物産デジタル・アセットマネジメント(以下、MDM)に出向中の片桐(@akinama3)と申します。 普段は象のアイコンで活動しつつ、ねぎしを世の中に広める仕事をしています。 MDMの概要については、昨日@peroyuki_ がご紹介しているので、ぜひご覧ください。 tech.layerx.co.jp さて、世の中には「銀の弾丸」と思しきデジタル化のバズワードが溢れかえっておりますが、 実際には「業務とはなにか」をひたすら考えぬき、徹底的にSaaSを活用したり泥臭く自分でシステムを作ったりして改善するしか幸せになる道はありません。 というわけで、MDMで徹底的に拘って取り組んだ社内業務効率化の事例として、「意思決定機関である稟議」と「稟議に基づく業務の自動執行」について、ご紹介したいと思います。 実はこのときの実装経験がMDMで進めてい

    意思決定と業務執行をシームレスにした話(概要編) - LayerX エンジニアブログ
  • 認証と認可と課金とコアドメインを分離したシステムは勝てるという話 - まっちゅーのチラ裏

    自分が複数のシステムの開発を経験して得た確信として、「認証と認可と課金とコアドメインの分離がめちゃくちゃ重要である」というものがあるので、コレを整理してアウトプットしていく 分離するモチベーションとは Microservice文脈でいうと、デプロイ独立性だったり、リソースの最適配分だったり、障害の局所化だったり、開発組織とのマッピングだったりがメリットとして語られることが多い。 だが、ここで取り上げたいのは戦術的DDD的観点でのコンテキスト分離の有用性である。 ※ちなみにコンテキスト分離のみであればモジュラモノリスだけで実現可能。 戦術的DDD的観点での関心事の分離によるメリットとは コンテキストが分離されていることによって、境界をまたぐ際に「このI/Fは正しいのか?」を都度考えることを強制することができる。 境界がなければ意図しない密結合を生みやすくなってしまう。 もちろん、境界を超える

    認証と認可と課金とコアドメインを分離したシステムは勝てるという話 - まっちゅーのチラ裏
  • コンテナ・デザイン・パターンの論文要約  - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Brendan Burns, David Oppenheimerらの論文「Design patterns for container-based distributed systems」を読んで、コンテナを活用したシステム設計や開発に、とても有用と感じたので、図を中心にした要約にしてみた。 要約内容に誤りや理解不足な部分もあると思うので、原文も参照していただきたい。また、自身の理解のために、論文中に無い図を加えた点、独自の注釈も加えている。 背景 コンテナ化されたソフトウェアコンポーネントから構築されたマイクロサービスアーキテクチャの人

    コンテナ・デザイン・パターンの論文要約  - Qiita
  • 政府情報システムにおけるゼロトラスト適用に向けた考え方 | 政府CIOポータル

    サイトは、過去のIT総合戦略室の情報発信サイトです。2022年6月30日に更新を停止しました。 現在のデジタル政策に関するデジタル庁の公式サイトはこちらをご覧ください。 境界型セキュリティの限界を示し、ゼロトラストと呼ばれるこれからのセキュリティの考え方を紹介し、政府情報システムにおけるゼロトラストの適用の取り組みを取りまとめました。 パブリック・クラウドの利用、働き方改革、APIによる官民連携等が政策上の大きなテーマとなっていますが、これらを推進するには、これまでの境界型セキュリティの考え方だけでは、その実現が困難です。 文書では、上記のとおり境界型セキュリティの限界を示し、ゼロトラストと呼ばれるこれからのセキュリティの考え方を紹介し、政府情報システムにおけるゼロトラストの適用の取り組みを1)パブリック・クラウド利用可能システムと利用不可システムの分離、2)システムのクラウド化徹底と

  • なぜ10万円給付に時間がかかるのか|東修平(四條畷市長)

    特別定額給付金(いわゆる10万円給付)について、住民の方々から、毎日のように「いつ振り込まれるのか」というお問合せをいただきます。 連日、この10万円給付については様々な報道がなされていますが、特徴的な側面のみを取り上げていることが多く、全体像を俯瞰しづらいかもしれません。ですので、なぜもっと早く給付できないのかという疑問を持たれるのは当然だと思います。そこで記事では、 市町村は、いったい何をしているのか なぜ、給付に時間がかかっているのか について、自治体の長として説明を試みます。 なお、理解しやすくするため、説明のなかで概念化や単純化をしている部分もあり、完全に記載どおりの内容を行っている訳ではないことは、念のためお伝えしておきます。 1 記事の対象 特別定額給付金については、ご存知のとおり紆余曲折を経て現制度に着地しました。そのため、議論すべき論点は複数あるかと思います。 しかしな

    なぜ10万円給付に時間がかかるのか|東修平(四條畷市長)
  • NTTとIPAの「シン・テレワークシステム」はラズパイだった。1ユーザーあたり月14円で運用可能

    NTTとIPAの「シン・テレワークシステム」はラズパイだった。1ユーザーあたり月14円で運用可能
  • プラットフォームの上でものを作るということ

    プラットフォームの上でものを作るということ Amazon EKS Advent Calendar 2019 の最終日です. みなさまご存知の通り、AWS には Amazon ECS と Amazon EKS という2つのコンテナオーケストレーションに関するサービスがあります. ECS は2014年に発表された AWS ネイティブなコンテナオーケストレータ、EKS は OSS のコンテナオーケストレータである Kubernetes をマネージドな形で提供するサービスで、2017年に発表されました. 今日はこの Amazon ECS と Amazon EKS という2つのサービスについての話を書こうと思います. // 読んでくださっているみなさまをミスリードしないための DISCLAIMER 記事の著者は AWS に勤めています. また、この記事には僕個人の意見や想いも強くこもっています.

    プラットフォームの上でものを作るということ
    higed
    higed 2020/05/10
    Kubernetes クラスタ自体を短命なものにしようとすると、そのクラスタから作成された長寿命なクラスタ外リソース(ALB や RDS)のライフサイクルとの整合性が取れず、奇妙な運用をやることになってしまう.
  • 要件定義~システム設計ができる人材になれる記事 - Qiita

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

    要件定義~システム設計ができる人材になれる記事 - Qiita
  • Webシステムアーキテクチャの地図を描く構想 - ゆううきブログ

    この記事は第5回Webシステムアーキテクチャ研究会の予稿です。 はじめに Webサービスにおいては、スマートフォンの普及によるアクセス増加に対してスケーラビリティを持ち、個人向けだけでなく企業向けサービスの可用性の要求に耐えられるようなシステム設計が必要とされている。 さらに、Webサービスが人々の生活に浸透したために、Webサービス事業者はサービスを長期間運用することが当たり前となっている。 その間、新機能開発、ソフトウェアの実行効率化、セキュリティ向上などを目的に、システム管理者は自身が管理するソフトウェア群を更新しつづける必要がある。 このような多様な要求を満たすために、Webサービスを開発・運用するエンジニアには、OSやデータベース、ネットワーク、分散システム、プログラミング言語処理系などのコンピュータ工学における広範囲の基礎知識と、ミドルウェア、オペレーション自動化のためのソフト

    Webシステムアーキテクチャの地図を描く構想 - ゆううきブログ
  • みずほ銀行の新システムがIBM×COBOLで昭和っぽさあるとおもったら逆で、みずほだけが「脱・昭和」できてたのか - in between days

    日経 xTECH(クロステック)で「35万人月、みずほ銀行システム統合の謎」というシリーズ記事が公開されている。 tech.nikkeibp.co.jp 出典は「日経コンピュータ」誌の2019年9月5日号で、32ページにわたる特集を全19の記事で構成している。 みずほシステム統合の謎、参加ベンダー「約1000社」の衝撃 | 日経 xTECH(クロステック) 有料会員向けの記事ということもあるんだろうけれど、上記のような一部記事だけが微妙なかんじでバズっていて、その記事を読むと、まあこういう感想になる。 みずほシステム統合の謎、参加ベンダー「約1000社」の衝撃 | 日経 xTECH(クロステック) 今年って昭和何年だっけ? “基盤とアプリ開発のベンダーが異なることで特有の難しさも生じた。富士通はIBMの基盤上で動作するCOBOLプログラムを開発しなければならなかった”2019/09/10

    みずほ銀行の新システムがIBM×COBOLで昭和っぽさあるとおもったら逆で、みずほだけが「脱・昭和」できてたのか - in between days
  • 100億円キャンペーンで学んだ“教訓” PayPayのスケーラブルな巨大決済システムを支える工夫

    100億円キャンペーンで学んだ“教訓” PayPayのスケーラブルな巨大決済システムを支える工夫 PayPay 100億円キャンペーンのシステム構築 #2/2 2019年6月12〜14日、幕張メッセにて「AWS Summit Tokyo 2019」が開催されました。アマゾンウェブサービス (AWS) に関する情報交換や、コラボレーションを目的として行われるこのカンファレンスでは、140社以上の利用企業による先進事例セッションをはじめ、数々のイベントを実施しました。プレゼンテーション「PayPay 100億円キャンペーンのシステム構築 」に登壇したのは、PayPay株式会社プロダクト部の山啓介氏とShilei Long氏。スマホ決済アプリとして新規参入した同社が展開し、日中の話題をさらった「100億円キャンペーン」の技術的背景について語ります。後半パートとなる今回は、Shilei Lo

    100億円キャンペーンで学んだ“教訓” PayPayのスケーラブルな巨大決済システムを支える工夫
  • 秒間100万リクエストをさばく - Googleの共通認可基盤 Zanzibar - 発明のための再発明

    はじめに Googleの提供するサービス郡が共通して利用している認可システムにはZanzibarという名前がついています。ZanzibarはGoogleDrive・Google Map・Youtubeなどの巨大なサービスにも使用されています。 そのため、利用量も凄まじく 数10億のユーザー 数兆のACL(access control list) 秒間100万リクエスト もの量をさばいています。 にも関わらず、Zanzibarはこれを10ミリ秒以内に返します(95パーセンタイル)。 この記事では、そんなZanzibarの内部構造に関する論文「Zanzibar: Google’s Consistent, Global Authorization System」の中から、主に大量のリクエストをさばくための工夫を紹介します。 ちなみに、以前Googleの社内システム用の認可システム「Beyond

    秒間100万リクエストをさばく - Googleの共通認可基盤 Zanzibar - 発明のための再発明
  • PayPayエンジニアが明かす「100億円キャンペーン」のシステムの舞台裏 数々の問題を解決するためにやったこと

    PayPayエンジニアが明かす「100億円キャンペーン」のシステムの舞台裏 数々の問題を解決するためにやったこと PayPay 100億円キャンペーンのシステム構築 #1/2 2019年6月12〜14日、幕張メッセにて「AWS Summit Tokyo 2019」が開催されました。アマゾンウェブサービス (AWS) に関する情報交換や、コラボレーションを目的として行われるこのカンファレンスでは、140社以上の利用企業による先進事例セッションをはじめ、数々のイベントを実施しました。プレゼンテーション「PayPay 100億円キャンペーンのシステム構築 」に登壇したのは、PayPay株式会社プロダクト部の山啓介氏とShilei Long氏。スマホ決済アプリとして新規参入した同社が展開し、日中の話題をさらった「100億円キャンペーン」の技術的背景について語ります。前半パートとなる今回は、山

    PayPayエンジニアが明かす「100億円キャンペーン」のシステムの舞台裏 数々の問題を解決するためにやったこと
  • マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング

    この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス(外部サービスも含め)が提供する各種決済手段を利用して、上位層のサービス(メルカリ、NFC,コード払いなど)に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき

    マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
    higed
    higed 2019/06/07
  • Erlang/OTP と ejabberd を活用した Nintendo Switch(TM)向け プッシュ通知システム 「NPNS」の 開発事例

    任天堂 ネットワークシステム部 わたなべ たいよう 渡邉 大洋 私たちは、家庭用ゲーム機 Nintendo Switch (TM) 向けに、プッシュ通知のシステム「Nintendo Push Notification Service (NPNS)」を開発・運用しています。 NPNS には常…

    Erlang/OTP と ejabberd を活用した Nintendo Switch(TM)向け プッシュ通知システム 「NPNS」の 開発事例
  • システムの障害対応時に心がけること - orangeitems’s diary

    はじめに 世の中のシステムの数は間違いなく増え続けるばかりですので、障害対応の絶対数も増え続けることが宿命です。経験したたくさんの障害対応の中で、いくつか心がけることをおすすめしたいことがありますのでまとめます。 心がけるべきこと まず、復旧することを優先すること システム障害が発生したときに、迷うのは情報を採取するべきか。関係者に連絡を行うべきか。もしくは事前に決められた復旧手順を行うか。この3点です。 間違いなく、事前に決められた復旧手順を実施するべきでしょう。例えばミドルウェアの再起動、OSの再起動、ハードウェアの再起動などです。できれば一次障害対応手順書としてまとめられていた方がよいでしょう。ただし、この手順が複雑ではいけません。コマンドにして数行であるべきです。もし、複雑な手順を行わなければいけないとしたら、即時の復旧は無理ということです。 システムは利用者がいるため、連絡や情報

    システムの障害対応時に心がけること - orangeitems’s diary
  • システム障害との向き合い方 @sinamon129 #tokyogirlsrb

    これまで大小様々なシステム障害に遭遇してきましたが、障害対応から学ぶことは沢山あります。 いろんな習熟度のフェーズで障害発生を学びに変えるための行動事例や、webアプリケーション開発において障害対応を減らすためにできることなどをお話しできればと思います。 TokyoGirls.rb Meet…

    システム障害との向き合い方 @sinamon129 #tokyogirlsrb
  • システム方式設計で実装の実現性を見極められないエンジニアには設計させられないよね - 室長のひとりごち

    システム方式設計なので、まぁ、基設計だと思ってもらえればどの工程かはイメージが合わせられるでしょうか。この工程までは、所謂、上流工程ですからここでシステムデザインを間違えると後続の工程への波及効果はとてもインパクトがあるのです。 ですから、システム方式を設計する際には、要件に沿った実現仕様、つまり、これから実現しようとしているシステムへの要件を満たすための実装を考慮した方式を選択しなければ、システム方式設計である基設計工程から“やり直し”をせざる得なくなるのですね。 このことを意識してどれだけのエンジニアが設計しているかはちょっと疑問かも、です。製造構築工程や試験工程でのどんちゃん騒ぎを横で見ていると。1-2回でいいから、有識者を入れてウォークスルーのレビューかませておけばいいだけなのに。 システム方式設計での実現性の必要性 でも、「ホントに必要なの?」なんて疑り深い人がいるかどうかは

    システム方式設計で実装の実現性を見極められないエンジニアには設計させられないよね - 室長のひとりごち