カオスエンジニアリングを組織にも適用。アンチフラジャイルなシステムを目指してユーザベースが発見した問題とは？ - はてなニュース
Netflixがシステム運用に取り入れている、カオスエンジニアリング（chaos engineering）という手法があります。例えば機能を冗長化したシステムでも、いざ障害が起きたときに別系統が想定どおり機能するか分からない。そこで実際に動いているシステムで意図的に障害を起こし、挙動を確認してシステムの改善につなげる考え方です。 株式会社ユーザベースでは、アンチフラジャイル（antifragile、反脆弱）なシステムを目指してカオスエンジニアリングを導入しています。システムだけでなく、エンジニア組織においてもカオスエンジニアリングを応用した改善プロセスに着手しています。キーパーソンがいなくなってもプロジェクトはうまく動き続けるか、実際に外れてもらって確認するのです。 このチャレンジングな取り組みについて、CTOの林尚之さんと、システムでも組織でもカオスエンジニアリングを体験したエンジニアの
設計書・仕様書のレビュー方法を定めたJIS規格登場 チェック体制を標準化しやすく
経済産業省は11月22日、システム開発時に使う設計書・仕様書などの「作業生産物」のレビュー工程についてJIS規格を制定したと発表した。仕様書などの見直し方や観点などを規格化し、ソフトウェアの品質向上や開発の効率化を促す。 「JIS X 20246」は、設計書・仕様書の見直し作業を「計画作業」「レビューの立ち上げ」「個々人のレビュー」「要検討項目の共有および分析」「修正作業および報告作業」の順に整理し、実行するべきタスクや手順を規定するもの。システム開発や試験、保守などの場面で作るあらゆる仕様書に適用可能。 レビューの曖昧さをなくすため、「目的」「役割」などのレビューの観点10種、「執筆者確認」「同僚との机上確認」などのレビュー手法9種を定めた。JIS制定により、組織や個人のノウハウに依存することなく一定水準のレビューができるようになり、ソフトウェアなどの制作物の品質向上につながるとしている
20年間ソフトウェアエンジニアとして働いて学んだ20個のことまとめ
By Sergey Galyonkin ソフトウェア開発企業・Simple Threadの創設者であるジャスティン・エセリッジ氏が、ソフトウェアエンジニアとして20年活動した経験を基に、学習において重要なポイントやコーディングにおいて意識するべきポイントなどを20個にまとめて公開しています。 20 Things I've Learned in my 20 Years as a Software Engineer - Simple Thread https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/ ◆1：自分がまだ多くを知らないことを自覚する エセリッジ氏は、たとえ何十年間ソフトウェアエンジニアとして働いたとしても、それぞれのエンジニアが持つ知識には違いがあり、他のソ
みずほ銀行システム障害に学ぶ
みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては（
形式手法はなぜ流行っていないのか - Qiita
はじめに みなさん形式手法をご存知でしょうか？ 名前くらいは聞いたことあるけどいまいち何かわからないという方が多いのではないでしょうか。 その通りです。形式手法はアカデミアではそれなりに研究されているものの、 一般の（特にWeb系）ソフトウェア開発者が携わることはなかなかないのではないかと思います。 この記事ではソフトウェア開発に形式手法が導入されないのはなぜなのかを考察します。 この記事ではアジャイルソフトウェア開発において形式手法を導入する際のハードルについて考察します。 追記 本記事について、「形式手法は流行っていない」というのは正確ではないのではないかという指摘をいただきました。組み込み系や社会インフラ系等バグを絶対に出せないシステム開発では形式手法がよく使われているそうです。 ちょっと古いデータですが活用事例です。 誤解を招く紹介となっていたことをお詫びします。 さらに追記 ku
【独自インタビュー】リクルートが自社開発に踏み切った「規約同意管理システム」設計のツボ | クラウドサイン
プライバシー保護体制の見直しを発表したリクルート。その取組みの中で特に注目したいのが、どのユーザーが・いつ・どのバージョンの規約とプライバシーポリシーに同意したのかを管理する「規約同意管理システム」の存在です。このプロジェクトを担当された森様・渡部様・馬場様に、取材に応じていただきました。 350超のサービス規約＆プライバシーポリシーの表示・同意記録をシステムで一元管理するプロジェクト —本日の取材にお時間を割いてくださいまして、誠にありがとうございます。 リスクマネジメント担当役員 森様： こちらこそ、先日弊社のプライバシー保護に向けた取り組みをメディアで詳細に取り上げて下さり、うれしく思いました（関連記事：「なぜリクルートは組織再編日にプライバシーポリシーを改定するのか」）。私たちも、リクナビDMPフォローの件以降、一段と襟を正していかなければという思いでおりますし、今日も可能な限りオ
認証と認可と課金とコアドメインを分離したシステムは勝てるという話 - まっちゅーのチラ裏
自分が複数のシステムの開発を経験して得た確信として、「認証と認可と課金とコアドメインの分離がめちゃくちゃ重要である」というものがあるので、コレを整理してアウトプットしていく 分離するモチベーションとは Microservice文脈でいうと、デプロイ独立性だったり、リソースの最適配分だったり、障害の局所化だったり、開発組織とのマッピングだったりがメリットとして語られることが多い。 だが、ここで取り上げたいのは戦術的DDD的観点でのコンテキスト分離の有用性である。 ※ちなみにコンテキスト分離のみであればモジュラモノリスだけで実現可能。 戦術的DDD的観点での関心事の分離によるメリットとは コンテキストが分離されていることによって、境界をまたぐ際に「このI/Fは正しいのか？」を都度考えることを強制することができる。 境界がなければ意図しない密結合を生みやすくなってしまう。 もちろん、境界を超える
政府CIOの「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」が とても良かったので紹介したい - Qiita
これって何？ 政府CIOとは、内閣から任命され日本行政のシステム全体を統括する「日本政府のCIO」です。この政府CIOをサポートするのが各省庁を担当する50名近い政府CIO補佐官からなる政府CIOチームです。（組織としては、内閣官房 情報通信技術（ＩＴ）総合戦略室というようです） この政府CIOチームがとりまとめた政府職員向けのIT調達とシステム導入に関する標準が「デジタル・ガバメント推進標準ガイドライン」です。 このガイドラインは「本編」「解説書」「実践ガイド」の3点構成になっています。 中でも今日ご紹介したいのが上図一番右の「実践ガイドブック」です。 これを読むと何が手に入るのか？ 一言でいえば、「システム開発プロジェクトの歩き方」です。（一言でいう必要なかったか） 組織で商用のシステムを企画して開発・導入・そして維持運用していくための基本所作（型）を知ることができます。 （あくまでも
クレジットカードのオーソリゼーションのお話。 - メモ代わりのブログ
この記事を見かけたので。 naoki440.info TL;DR ・オーソリゼーション（仮売上処理、「オーソリ」）の有効期限は最大60日間と定められている為、60日を超過するとオーソリゼーションが無効になり、売上が非成立となる。 ・予約商品では60日以内に再度オーソリを行うことで、実質的に決済の有効期限を延長している。 ・Lenovoが一回目のオーソリ返金完了前に再度オーソリを行ったのは正常な挙動。 ・クレジットカードの場合、オーソリではなく売上確定処理後に請求を行う為、この問題は発生しない。 ・Kyash側で2重に引き落としされた＆チャージ元クレジットカードへ返金ができないのは正常な挙動。 ・クレジットカードのシステムにプリペイドを突っ込むとこの挙動になってしまう。つまり仕様と言える（各種プリカ発行会社もユーザーに告知している）。 一般的なカード決済の流れについて オーソリゼーション（仮
コロナで大打撃を受けた宿泊業のエンジニアの逆境との闘い
DevelopersSummitKansai 2020の登壇資料です。 星野リゾートでは、企業の発展とともに、開発の内製化の促進を進めており、2020年は大量の新規開業、システム刷新など巨大なプロジェクトが待ち受けていた。 しかし、新型コロナウィルス感染の拡大により、母体の宿泊業は業界全体が壊滅的な状況になり、多大な影響を受けた。 もちろん、その影響はシステム開発の現場にもあり、以下のような混乱した状況になった。 ・半年以上かけて練り上げてきた計画はすべて白紙になる。 ・計画は週に2、3回変わる。 ・緊急案件が次々と入る。 この逆境の中、組織としてどのような取り組みを行い、エンジニアが学びを得て、成果を上げているのかをご説明いたします。Read less
AWS システム構築 非機能要件ヒアリングシートを公開してみた | DevelopersIO
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日本国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が本格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと
プレス発表 DX推進に向け、アジャイル開発版の「情報システム・モデル取引・契約書」を公開：IPA 独立行政法人 情報処理推進機構
IPA（独立行政法人情報処理推進機構、理事長：富田 達夫）は本日、アジャイル開発を外部委託で行うケースを想定したアジャイル開発版「情報システム・モデル取引・契約書」を公開しました。 URL: https://www.ipa.go.jp/ikc/reports/20200331_1.html 経済産業省が推進するデジタルトランスフォーメーション（DX）の時代では、その中核となる情報システムの開発にも、ビジネス環境の変化への俊敏な対応が求められます。そのため、技術的な実現性やビジネス成否が不確実な状況でも迅速に開発を行い、顧客の反応に基づいて素早く改善を繰り返すという、仮説検証型のアジャイル開発が有効となります。このような観点から、同省が2018年9月に公開した「DXレポート」では、DXの進展によるユーザー企業とITベンダー（ベンダー企業）の役割変化などを踏まえたモデル契約見直しの必要性が指摘
日本史に残る巨大 IT プロジェクトから学べること『みずほ銀行システム統合 苦闘の19年史』
大規模 IT プロジェクトの成功事例と、大規模システム障害の失敗事例を合わせた一冊。読み手に応じ、さまざまな学びが得られる。 困難な状況で、プロジェクトを成功に導く教訓を学ぶこともできるし、史上最悪のシステム障害がどのように発生し、波及していったかを生々しく読めるし、二度と起こさないための再発防止策を具体的にピックアップすることもできる。 「東京スカイツリー7本」の ITプロジェクト なぜアズイズ（As-is）が問題なのか プロジェクト推進体制を強化する具体的な方法 2002年と2011年の大規模システム障害の顛末 IT システムの赤の女王説 日経コンピュータの「演出」 1. 東京スカイツリー7本分 IT業界のサグラダファミリアと呼ばれてきた、みずほの勘定系システム「MINORI」が、2019.7月、ついに完成した。 4,000億円という巨費を投じて 富士通、日立製作所、日本IBM、NTT
ディペンダブル・システムのための形式手法の実践ポータル
このサイトは、形式手法の普及促進を目的として、経済産業省「新世代情報セキュリティ研究開発事業」の成果やその後の関連動向等を掲載しています。
DDD Alliance レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡
30年間、事業を支えてきた業務システムをDDDで刷新する。 そのためには、組織的、エンジニアのレベルなど多くの問題があります。 その壁をどう乗り越えたのか？ そして、壁の向こうで得た恩恵とは何のか？ 5年という期間を経て、得ることのできた気づきや組織的な変化をお伝えしたいです。
Chaos Engineering やっていく宣言 - クックパッド開発者ブログ
技術部のヨシオリです。 Netflix が Chaos Engineering の論文を公開して 2 年ほど経ちました。 クックパッドは最近、 Chaos Engineering を導入する事を決めました。 この記事ではその背景を紹介したいと思います。 そもそも Chaos Engineering とは Netflix では Failure Injection Testing として、営業時間中に意図的に障害を起す事をやっていました。Chaos Monkey というインスタンスとサービスを落すものから Chaos Gorilla、Kong という availability zone や region 単位で障害を発生させるものなどです。 その経験から Chaos Engineering というものが提唱されました。 Principles of Chaos Engineeringによれば C
1行直すだけってそんなに大変なの？
どこの会社でも「1行直すだけでしょ？ そんなに大変なの？」ということを何度も聞かれる (もしくは言外にそのニュアンスを含められる) ので毎度説明するのだけれど、「いや、そう思うだろうけれど大変なんですよ」以外に答えられていなくて、自分でもあまりうまい答えではないなと感じるのでまじめに考えてみた。 まず大前提として1行を修正するのに本当に言われるがままにその1行を直すのであればそれは作業者で世の中にエンジニアなんて職業はいらないわけで、ぼくらの付加価値は1行を直すときに1行の外にあるものを想起できるから価値があるわけです。 じゃあ、どんなことを考えているかというと、まずたいていそんなすぐに安請け合いできないシステムというのは1行を直すときに影響を受ける行数というのは10行や20行ではないことが多い。そこで影響範囲を考えます。途端にこれが1万行になったりする。すると、1万行へ影響が出るのにこれ
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
