上手く行っていませんよね。幻影旅団の組織運営。幻影旅団は頭を含めてメンバーを入れ替え可能な仕組みで運営しようとしている団体です。なぜそうしようとしているかというと、そうなることで初めて組織が持続可能なものになるということでしょう。ある人がいなくなったら続かない仕組みではなく、誰がいなくなっても代わりが出てきて持続していく仕組みが求められています。 それはその目的が、流星街の子供たちを守るためだからでしょう。子供たちが未来永劫守られる仕組みを維持するためには、属人性を排除しなければなりません。 しかしながら、幻影旅団は上手く行っていません。それは団長のクロロを筆頭に、今時点では、とても属人的に運営されているからだと思います。団長がクラピカの念能力によって団員たちと接触できなくなったときにも、クロロの代わりの団長が選ばれるのではなく、クロロを除念によって再び団長にすることが選ばれました。 幻影
3. Copyright©2016 NTT Corp. All Rights Reserved. 3 • よくわかってない人でもCloudera Managerをダウンロードして1時間後 には巨大なHadoopクラスタを立ち上げてYARN, HDFS, Spark, HBase などで遊ぶ事ができる。 • 世の中では分散システムが必要以上に喧伝されている • 「コンピュータ1台よりも2台の方が高速」という直感に対して反論するの は意外と難しい • あなたのそのシステム、本当に分散システムじゃないとダメ？ 分散自体を目的にしない事 4. Copyright©2016 NTT Corp. All Rights Reserved. 4 L1 キャッシュ参照 分岐予測ミス L2 キャッシュ参照 Mutexのlock/unlock メモリ参照 1KBをZIP圧縮 1Gbpsで2KB送る メモリから1
システム開発紛争事例を，争点別にまとめました。非常に乱暴に要約しているので，詳細はリンク先または判決文をご確認ください。個別のエントリを追加したら随時インデックスも更新します。 契約の成否 契約締結上の過失 契約の個数・性質 仕様の認定・契約の内容 プロジェクト中断の責任 システムの完成 瑕疵（契約不適合） 追加費用・仕様変更等の報酬算定 費用の減額 過失・責任論 損害論 合意解約 その他 契約の成否 ■システム開発請負契約は，ベンダから仕様書，見積書等が提示され，これをユーザが承認して発注することにより相互の債権債務の内容が確定した段階で成立する（名古屋地判平16.1.28） http://d.hatena.ne.jp/redips+law/20100108/1327130292 ■システム開発総額の見積書が提示されたものの，開発範囲はFit&Gapの結果によって決まるなどの記載に照らす
「BeSTAを最大限に生かすことを考えた時の答えが『統合バンキングクラウド』だった」。NTTデータで金融分野を担当する取締役副社長執行役員の鈴木正範氏はこう強調する。 NTTデータは2024年4月から、統合バンキングクラウドの開発に着手する。これは同社が開発した勘定系アプリケーション「BeSTA」などを稼働させるためのプライベートクラウド基盤で、「銀行専用クラウド」といえるものだ。 NTTデータは地方銀行向けに4つのシステム共同化を展開しており、これら全てに統合バンキングクラウドを適用する意向だ。第1号ユーザーが京都銀行や西日本シティ銀行などが参加する「地銀共同センター」で、移行時期は2028年1月を予定する。地銀共同センターに続く形で、横浜銀行が中心の「MEJAR」が2030年ごろの移行を見込む。将来的に、第二地銀が多く名を連ねる「STELLA CUBE」や「BeSTAcloud」にも統
ここでは、以下の観点で、エンタープライズアーキテクチャ（EA）について解説します。 エンタープライズアーキテクチャ（EA）とは エンタープライズアーキテクチャ（EA）の重要性 エンタープライズアーキテクチャ（EA）の構成 エンタープライズアーキテクチャ（EA）設計の考え方 EAベース開発の実践的アプローチ エンタープライズアーキテクチャ（EA）に関する書籍 エンタープライズアーキテクチャ（EA）資料のダウンロード なお、EAをベースにしたビジネスマネジメントについては【実践！DX】実践的ビジネスマネジメントを参照してください。 エンタープライズアーキテクチャ（Enterprise Architecture）を一言でいうと、企業の業務とシステムの設計図です。 Enterprise Architectureのことを略してEAといいます。 アーキテクチャ（Architecture）とは、設計思想
LLMのRAG（外部知識検索による強化）についての調査結果が報告されています。 基本フレームワークと各構成要素の詳細、評価、そして今後の発展について言及されており網羅的です。 本記事では、その報告内容を抜粋してお届けします。 【告知】AIDB HRの人材側登録者全員に対し、業界研究の手間を削減できるように「AI事業を行う企業リスト」を配布します。無料登録後すぐに閲覧とダウンロードが可能です。▼ 参照論文情報 タイトル：Retrieval-Augmented Generation for Large Language Models: A Survey 著者：Yunfan Gao, Yun Xiong, Xinyu Gao, Kangxiang Jia, Jinliu Pan, Yuxi Bi, Yi Dai, Jiawei Sun, Haofen Wang 所属：Tongji Univers
ＥＣサイトにおけるクレジットカード情報漏洩事故が、決済代行業者から提供されたモジュールの不具合があったという場合において、開発ベンダの責任がモジュールの仕様・不具合の確認まで及ぶか否かが問われた事例。 事案の概要 Ｘが運営するＥＣサイト（本件サイト）において、顧客のクレジットカード情報が漏洩した可能性があるとの指摘を受けて、Ｘは、本件サイトにおけるクレジットカード決済機能を停止した（本件情報漏洩）。その後、Ｘはフォレンジック調査を依頼し、不正アクセスによってクレジットカード会員情報が漏洩したこと、クレジットカード情報はサーバ内のログに暗号化されて含まれていたが、復号することが可能だったこと、漏えいした情報は最大で約6500件だったこと等が明らかとなった。 Ｘは、本件サイトを、Ｙとの間で締結した請負契約（本件請負契約）に基づいて開発したものであって、本件サイトの保守管理についても本件保守管理
最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に
ホーム 全記事 ニュース Steamレビューにて、「トピックのずれた不評」を評価から除外するシステム導入へ。低評価爆撃問題にテコ入れ Valveは、Steamにおけるユーザーレビューを再考し、新システムを導入する予定があることを発表した。その内容は、「トピずれの（論点のずれた）レビュー荒らしを特定し、レビュースコアから除外する」というもの。Steamでは、販売されているゲームに対しユーザーがレビューをすることが可能。レビュー内容は、ゲームプレイに関するものからバグに関するもの、ローカライズの有無やゲームの価格、サービスについての賛否まで幅広い。そうしたレビューにおける、論点のずれたレビューをスコアから除外するというのが今回の趣旨だろう。 Valveは以前より「プレイヤーがゲームのレビュースコアを下げる目的で、短期間に大量のレビューを投稿すること」をレビュー荒らしと定義し、問題視してきた。そ
ビジネスは基本的に成長していくものだし、拡大していくことが前提で、しかも最近だと「システム」が付いてくる。全部人力で作り上げるビジネスなんてあるのか。いや、ない。あるとしても小規模だろう。人だけで成り立つなんてビジネスを放置しても、きっともはや、人が集まらない。コンピューターによる自動化はない。全部人力だ。さあ仕事しなさいって、それは原始的だろう。あらゆる仕事場で自動化ありきの人間の仕事が増産されているのであり、人々もそういう職場を狙っている。時代遅れの職場で、かつそういう人力の仕事は生産性も低く給料も安いので、どんどん敬遠されるようになる。 さて、じゃあシステム化しました、と。システム化するための要員はまだいるようだ。各社ベテランが腕を奮っている。DXの掛け声でクラウドもあって生産性は上がり、システムと名の付くものが量産されている。わかっている、システム構築のスピードは10年前と比べると
ソフトウェア設計を行う場合、必ずエラーや障害などの用語が飛び交うことがあるが認識がずれていることが多いので、以下に簡単にまとめてみた。 ソフトウェアの非正常を表す概念 ソフトウェアのエラーや障害などの非正常を表す概念の定義をいくつかピックアップしてみた。 JIS X 0014:1999の定義 出典: ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版) 誤差・誤り(error) 計算，観測もしくは測定された値または状態と，真の，指定されたもしくは理論的に正しい値または状態との間の相違。 障害(fault) 要求された機能を遂行する機能単位の能力の，縮退または喪失を引き起こす，異常な状態。 故障(failure) 要求された機能を遂行する，機能単位の能力がなくなること。 JIS X 0014では、意図しない結果を引き起こす人間の行為は、「間違い、人的過誤(mistake,
サーバ周りの勉強していると、たまにselectとかepollとか言葉が出てきて、理解できてなかったので調べてみた。 I/Oの多重化 例えばサーバ周りの実装を、特に何も考えずにやると、I/Oでブロッキングが発生し、一つのクライアントとしか通信できないということが起こります。これを解決するために fork threads I/Oの多重化 非同期I/O といった方法があります。 この中のI/Oの多重化を実装するためのシステムコールとして、select, poll, epoll, kqueueなどは実装されているようです。 少し調べてみると、次のような記述のような機能をそれぞれが実装するようです。 プログラムで複数のファイルディスクリプタを監視し、 一つ以上のファイルディスクリプタがある種の I/O 操作の 「ready (準備ができた)」状態 (例えば、読み込み可能になった状態) になるまで待つ
この記事はGoodpatch Advent Calendar 2022 18日目の記事です。 ソフトウェアエンジニアの 池澤です。 ここ最近はテクニカルディレクションとして仕事に関わることが増えました。その中で要件定義を作ったりデザイナーとエンジニアの橋渡しをする機会が多く、メンバーみんなが同じゴールを認識して制作できるようなより良い要件定義方法はないものかと探していました。 今回はそんな中で見つけたモダンな要件定義手法の一つ、RDRA（ラドラ）について、理解しやすくなるコツやカスタマイズしている内容についてお話しします。 なお、RDRAの詳細解説をするととても書ききれませんので、RDRA本体の詳細については公式サイト等をご参照ください。 RDRA（ラドラ）とは？ 概要 RDRAのバージョン これまでの要件定義でよくある問題 期待される要件定義の姿 公式サイト おすすめの学び方 実際のRD
いよいよD&DとMTGがコラボした新パック『フォーゴトンレルム探訪』の発売日が迫っている。 このパックはMTGプレイヤーをD&Dへと案内する導線になると同時に、 D&Dプレイヤーをマジックの世界へと連れてくるきっかけにもなっている。 さて、そんな中で非常に興味深いD&Dからやってきたプレイヤーのツイートを見た。 「なんでマジック：ザ・ギャザリングってデッキが６０枚もあって、土地なんていうものがあるんだろうか？」 この疑問は非常に興味深く、地雷原の上でのタップダンスでもある。 なぜ地雷原の上のタップダンスなのかをD&Dで例えると恐らくこんな感じだ。 「MTGってなんでデッキ６０枚で土地システムがあるの？」って 「D&Dってなんであんなに魔法使える回数が少ないの？ 最近の国産TRPGみたいに気軽に魔法を撃てた方がよくない？あと距離の単位もメートルにした方がいいよ」みたいな主張なので、まあ。怒る
あるデータベース（DB）でインデックスの容量が上限値を超えた――。みずほ銀行で2021年2月28日に発生したシステム障害では、運用上のささいなミスが巨大なトラブルに発展した。ATMが通帳やキャッシュカードを5244件も取り込み、多くの顧客が数時間も立ち往生した。みずほ銀行に何が起きたのか。障害拡大の真因を分析する。 本特集の第1回で紹介したように、みずほ銀行が2021年2～3月に起こした4件のシステム障害は、システムの設定に関する見落としやプログラムのバグ、ハードの故障といった避けがたいよくあるトラブルが起点だった。しかし金融機関ではあり得ないような問題点が35件もあったため、顧客に大きな影響を与えた。 そうした問題点はなぜ発生したのか。本誌はみずほフィナンシャルグループ（FG）が設置した「システム障害特別調査委員会（第三者委員会）」の報告書を基に、疑問点を12個抽出した。その中から今回は
背景 近年,新型コロナウイルス感染症 (COVID-19)の蔓延によるリモートワーク利用の加速化やクラウド活用の増加により,社外から社内システムに接続する機会が増えてきています。 現状のセキュリティ対策は,境界型防御が主流であり,社内を「信用できる領域」,社外を「信用できない領域」として外部からの接続を遮断しています。しかし,昨今の社会変化により,社内のシステム環境へ社外から接続を行う機会が増えているため,境界型防御を元に検討されていたセキュリティモデルではサイバー攻撃の脅威を防ぎきれない状況になってきています。 これらに対するセキュリティ対策として,「ゼロトラスト」という概念が提唱されています。これは,社内外すべてを「信用できない領域」として,全ての通信を検査し認証を行うという考え方です。 しかし,ゼロトラストを導入しようと調査を進めると,多種多様な用語の説明からはじまり,多数の文献,製
クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここで原氏が「技術的負債とステークホルダーと説明責任と」をテーマに登壇。まずは、技術的負債とは何か、組織における技術的負債返済までの構図について紹介します。 組織と個人それぞれの技術的負債の解消方法 原トリ氏（以下、原）：こんにちは！ 今日はこんな話をします。（スライドを見て）なんだか面倒くさそうなキーワードばかり並んでいますね。どれも避けて通りたくなるものばかりです。 はじめまして。こんにちは。Tori、あるいは原トリと言います。ふだんはAWSという会社で、AWSのコンテナサービスをよりよいものにするために、いろいろな仕事をしています。 今日はタイトルのとおり、こんな話をしていきます。まずは「技術的負債って何でしたっけ？」という話を軽く整理していこう
設計者は分割が発生したとき一貫性と可用性のどちらかを選ぶ必要がありますが、分割の扱い方と分割の復旧には柔軟な対処方法があります。現在のCAPの目的は特定のアプリケーションが必要とする一貫性と可用性を最適化することでしょう。このような方法には分割発生中の計画や分割の復旧計画が組み込まれています。したがって、設計者はこのような方法を採用することで、従来受け取られてきたCAPの限界を超えてCAPについて考えることができます。 なぜ"3つのうち2つ"がミスリーディングなのか CAPを理解する最も簡単な方法は分割の両側にひとつずつノードがある場合を考えることです。片方のノードだけ状態を更新できるようにすると、2つのノードに一貫性がなくなります。つまり、Cが失われます。一貫性を維持しようとすれば、一方のノードは利用できない状態であるかのように動作しなければなりません。この場合、Aが失われます。一貫性と
この記事は Brendan Conoboy による How RHEL is Made の翻訳です。 今週、Red HatはCentOS Stream 8に全力を注ぐ計画を発表し、その結果、1年後にはCentOS Linux 8が廃止されることになりました。 CentOS Streamはもともと2019年9月に発表されたもので、開発や検証が進むとすぐにアップデートを提供するRHELの継続的なリリースです。 現在CentOS Linuxを使用している多くの人は、CentOS Stream 8が自分の使用に適したディストリビューションになるのかどうか、テストされているのか、安定しているのか、などを疑問に思っています。 CentOS Stream に何が期待できるかを知るには、Red Hat Enterprise Linux がどのように構築されているかを知ることが一番の出発点となります。 それで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
