タグ

システムと開発に関するhigedのブックマーク (10)

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

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

    システム開発で曖昧な要望を形にしていく方法 - arclamp
  • コンテナ・デザイン・パターンの論文要約  - Qiita

    Brendan Burns, David Oppenheimerらの論文「Design patterns for container-based distributed systems」を読んで、コンテナを活用したシステム設計や開発に、とても有用と感じたので、図を中心にした要約にしてみた。 要約内容に誤りや理解不足な部分もあると思うので、原文も参照していただきたい。また、自身の理解のために、論文中に無い図を加えた点、独自の注釈も加えている。 背景 コンテナ化されたソフトウェアコンポーネントから構築されたマイクロサービスアーキテクチャの人気が高まり、分散システム開発においても同様の革命が起っている。 コンテナの境界の壁は、分散システムの基的なオブジェクトの境界に適している。そこで、コンテナを活用して、コードの低レベルの詳細を抽象化し、アプリケーションやアルゴリズムに共通する高レベルのパター

    コンテナ・デザイン・パターンの論文要約  - Qiita
  • 要件定義~システム設計ができる人材になれる記事 - Qiita

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

    要件定義~システム設計ができる人材になれる記事 - Qiita
  • Erlang/OTP と ejabberd を活用した Nintendo Switch(TM)向け プッシュ通知システム 「NPNS」の 開発事例

    任天堂 ネットワークシステム部 わたなべ たいよう 渡邉 大洋 私たちは、家庭用ゲーム機 Nintendo Switch (TM) 向けに、プッシュ通知のシステム「Nintendo Push Notification Service (NPNS)」を開発・運用しています。 NPNS には常に1000万台超のデバイスが接続していますが、日々安定してさまざまな通知を送り続けています。 NPNS の全体像およびインフラ面の構成については別の機会にお話ししたことがありますが、今回の Erlang and Elixir Festでは、特に NPNS の常時接続部分の基盤技術として採用している Erlang/OTP、およびその上で動作する OSS である ejabberd に重点を置いて説明します。 具体的には、NPNS に求められる要件に対して、 ・Erlang/OTP および ejabberd

    Erlang/OTP と ejabberd を活用した Nintendo Switch(TM)向け プッシュ通知システム 「NPNS」の 開発事例
  • システム更新の見積もりが億単位? ならば自分たちの手で 信州ハムはどうやって9カ月で基幹システムを内製したのか (1/2) - ITmedia エンタープライズ

    信州ハムもかつては、基幹システムの構築、保守を外部のIT専門企業に任せていたが、20年以上運用してきたシステムが老朽化したため、新規システムの見積もりを依頼したところ、出てきたのは「億単位の提案」だったという。持続的成長に向けた投資も検討しなければならない中、「これではとうてい手が出ない」――。やむにやまれぬ状況で対応策を探す中、ある展示会で目にしたのが「FileMaker」のプラットフォーム上でカスタムAppを構築する方法だった。 当時、情報収集に当たっていた信州ハムサービス 取締役開発部長の土屋光弘氏は「2014年のFileMakerカンファレンスで実際に品メーカーで活用している例があることを耳にして、『これならできそうだ』という感触をつかみました」と振り返る。 土屋氏と一緒にカスタムAppの開発に当たったのが、信州ハムの生産管理部 生産管理課で係長を務める織部航氏だ。デザイン思考

    システム更新の見積もりが億単位? ならば自分たちの手で 信州ハムはどうやって9カ月で基幹システムを内製したのか (1/2) - ITmedia エンタープライズ
  • [特報]27億円の賠償巡り新たなIT裁判始まる、文化シヤッターが提訴

    アルミ建材大手の文化シヤッターが、販売管理システムの開発が頓挫した責任は委託先の日IBMにあるとして、約27億4000万円の損害賠償を求めて日IBMを提訴していたことが、日経コンピュータの取材で明らかになった。 文化シヤッターは2017年11月に東京地方裁判所へ訴訟を提起した。同社は2017年度第2四半期決算(2017年7~10月)で、販売管理システムの開発継続断念に伴う17億4500万円の特別損失を計上済み。同システムの開発委託で日IBMに支払った費用などの返還を求める。 文化シヤッターが既存の販売管理システムを刷新するプロジェクトを始めたのは2015年3月のことだ。文化シヤッターは日IBMに提案依頼書(RFP)の作成を委託。そのRFPに基づき複数のITベンダーから提案を受けたうえで、日IBMをシステム構築の委託先として選定した。 日IBMの提案は、販売管理システムの構築にE

    [特報]27億円の賠償巡り新たなIT裁判始まる、文化シヤッターが提訴
  • 業務改善とシステム化を一緒にやってしまう「業務ハッカー」という新しい職業 | Social Change!

    前々回の記事『理想の働き方改革より現場の業務改善を 〜 現実的で効果的な「業務ハック」のはじめ方』では、業務改善とシステム化を一緒にやってしまう「業務ハック」というコンセプトについて書いた。 そして、今週末には業務ハックの初の勉強会が開催される。おかげさまで好評なため、大阪でも開催することに。(業務ハック勉強会@東京、業務ハック勉強会@大阪) 今回の記事では、そんな「業務ハック」に取り組む職業「業務ハッカー」、すなわち業務改善とシステム化を一緒にやってしまう仕事について書いた。 業務改善とシステム化を兼業する「業務ハッカー」の土壌 「業務ハック」では、現行業務の分析と見える化を行い、ボトルネックを発見し、もっとも効果的な部分から小さく始めていくことを特徴としている。そして、なんでもかんでも作るのではなく、便利なツールやプラットフォームを駆使して、もっとも費用対効果の高いところだけをプログラ

    業務改善とシステム化を一緒にやってしまう「業務ハッカー」という新しい職業 | Social Change!
  • 超高速な開発ができるわけ | Yakst

    あるひとりの人がシステムを作ったが故にそのシステムに精通している場合に、最も生産的な開発が行われる。しかしこれは、ひとりの人がシステムの面倒を見ることを超えてシステムが成長する時には矛盾してしまう。 ある状況下において、特定の開発者たちが他の人の10倍生産性が高くなることがあるのはなぜかについて議論してみましょう。 ヒント : 開発者の話ではなく、状況が大きなカギ。 生産性が非常に高いことにウキウキした気分になるのはいつでしょうか。新しい機能が指先からあふれ出てくる時?それは、私たちが関わるツールのことを知り尽くしている時、あるいはもっと決定的に言うと、自分がシステムを変更しつつある時に起こるのです。自分のバックパック、それも自分で詰め込み、そしてひとつひとつの小袋の中まで何年にもわたる旅行を経て調整してきたバックパックの中身を知っているように、システムを知ることです。それぞれのモジュール

    higed
    higed 2017/08/10
    テストを書いてください。テストは、意図せず何かを壊してしまうことを恐れている人が、今からやろうとしていることを試す方法です。
  • 電力自由化システム、大トラブルの真相:日経ビジネスオンライン

    気になる記事をスクラップできます。保存した記事は、マイページでスマホ、タブレットからでもご確認頂けます。※会員限定 無料会員登録 詳細 | ログイン 電力広域的運営推進機関(広域機関)は2017年6月に、ある報告書をまとめた。全国の電力網の司令塔ともいうべき「広域機関システム」の開発トラブルを総括したものだ。 広域機関は外部の専門家による第三者評価委員会を設置して、報告書を作成。プロジェクトの実態をつまびらかにした。そこには、システム開発を発注した広域機関と、受注した日立製作所の混乱の様子が記されていた。電力小売り全面自由化のスタート時に混乱の火種となった同システムの開発は、希にみる“凄惨”なプロジェクトだった。 システム開発にトラブルは付きものだ。プロジェクトの実態と、広域機関の対策を他山の石としたい。 関係者35人、計70時間のインタビューで実態を明らかに 広域機関システムは、電力の安

    電力自由化システム、大トラブルの真相:日経ビジネスオンライン
  • 事業者と開発者の壁はどう壊す? リクルートテクノロジーズの大規模プロジェクトメソッド

    2016年11月16日、株式会社リクルートテクノロジーズがプロジェクトマネジメント勉強会を開催しました。数多くの事業領域を持ち、複数プロジェクトを同時進行するリクルートグループのシステム開発はどのように支えられているのか。前半に引き続き、同社プロジェクト推進部の辻純一氏が、プロジェクト遂行時の組織作りやシステム開発にとどまらないプロジェクトマネジャーの役割について紹介します。 開発側と事業側の役割の違い 辻純一氏(以下、辻):みなさんへの質問なのですが、プロジェクトを実施する際、要件定義フェーズの前に、「この案件の目的はそもそもなんだっけ?」という、検討フェーズを設けている方はいらっしゃいますか? 回答者1:私自身は担当していないのですが、別の担当が企画構想というかたちで、プロジェクトのターゲット、目的、KPIを発表して、承認をもらって進めています。 辻:システム企画の人が1人で全部書きあ

    事業者と開発者の壁はどう壊す? リクルートテクノロジーズの大規模プロジェクトメソッド
  • 1