『アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明』は不明瞭 ~書籍「Impact Engineering」を読んでみた感想 ~アジャイルポエムプロジェクト管理メンタルケアコミュニケーション 「アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明」 という記事が話題になっています。 言及している著書がCEOを務めているイギリスの調査・コンサル会社であるEngpraxが挙げている元の記事はこちら（その調査自体を行なったのもEngprax社） 記事に書かれていることの考察や要約は下記で分かりやすく纏めて下さっています。 記事への反応 記事への感想・反応はだいたい下記のパターンのどれかに該当すると思います。 失敗の定義は？ そもそもアジャイルできてなくね？ 下記が失敗するのはアジャイルかどうかとは関係

江崎グリコのシステム障害によりプッチンプリンなど一部商品の出荷が停止している。4月にはゆうちょ銀行で入金遅延が起きた。なぜ企業のシステムトラブルが相次いでいるのか。麗澤大学教授の宗健さんは「システムを発注している日本のユーザー企業にはITのプロがいないことが背景にある」という――。 続出する企業のシステムトラブル 今に始まったことではないが、企業のシステムトラブルは思ったよりも多い。2023年10月に発生した全銀ネットの障害では数百万件の送金が滞り社会的にも大きな影響があり、2027年に稼働を見込んでいた次期システムの検討作業も停止に追い込まれた。 最近も、江崎グリコのシステム障害によりプッチンプリンの出荷が止まり（※1）、ゆうちょ銀行でも100万件を超える入金遅延が起きた（※2）。 ※1 日本経済新聞「プッチンプリン出荷再開を延期 グリコのシステム障害」（2024年5月1日）4月3日のE

金融機関どうしの資金のやり取りを担う全銀ネット＝「全国銀行資金決済ネットワーク」のシステムに不具合が発生した問題で、運営団体はシステムが復旧し、遅れが出ていた振り込みの処理もすべて完了したと発表しました。 全国銀行協会の関連団体の全銀ネット＝「全国銀行資金決済ネットワーク」は、10日から不具合が続いていた金融機関どうしの資金をやり取りするシステムについて、12日午前8時半から正常に稼働していることを確認し、復旧したと発表しました。 今回のシステムの不具合では10の金融機関で振り込みが遅れるなどの影響が出ましたが、システムの復旧を受けて三菱UFJ銀行やりそな銀行、商工中金など各金融機関で通常通りの利用ができるようになったということです。 全銀ネットによりますと、10日から11日までに処理が遅れた取り引きはあわせて500万件を超えたということですが、12日午前中までにすべての処理が完了したとい

「ラクス Advent Calendar 2022」 12月23日（金）担当のインフラエンジニアです。今回は知られざるインフラエンジニアの仕事について触れてみたいと思います。 はじめに 最近（でもないけど）twitterなどで駆け出しエンジニア？の方のツイートをよく目にするようになりました。 「駆け出しエンジニア」というと文字面からは1年目のなりたてエンジニアのような印象を受けますが、どちらかというとこれからエンジニアを目指すために勉強をしている方を指すことが多いようです。 そういった方のツイートを見ていると9割以上はプログラミングの話。実際に業界内で働いてみれば要件定義など単純にプログラミングしていればいいだけの世界ではないことは重々承知かと思いますが、未経験の方にはエンジニア＝プログラミング、エンジニア＝開発、というイメージがやはり強いのでしょう。はたまたインフラエンジニアなんて世界に

この前AWS公式のYouTubeチャンネルにて、面白そうなライブ配信がありました AWSの動画コンテンツといえば、BlackBeltのようなサービス紹介の動画が真っ先に思い浮かぶ方も多いと思います。 自分もその一人ですが、この動画はプロダクトではなく「Infrastructure as Code（IaC）という概念」にフォーカスしたコンテンツです。 Twitterで学びメモを書きましたが、ちゃんと記事として学びをまとめておこうと思います。 また、動画の内容に関連した補足事項を記事の後半にまとめておきました。 ↓動画本編はこちら↓ ↓資料はこちら↓ IaCをなぜ使うのか 純粋にIaCは楽しい、手順書作成は楽しくない リリースのたびに手順書更新 or 新規作成するのは、果たして楽しいのか IaCのほうがリリースまでのリードタイムが短い 運用する上での教育はどうする？ そもそも「教育」はIaCじ

【Public Notes】とはミレニアル世代のシンクタンクPublicMeetsInnovationがイノベーターに知ってもらいたいイノベーションとルールメイキングに纏わる情報をお届けする記事です。 前編はこちら。 契約関係から見えてくるCOCOAの課題これでCOCOA契約に至るおおよその全体像が浮かび上がってきました。しかしここでまた次なる疑問が沸いてきます。 果たしてパーソルはCOCOA開発の受託先として適切だったのでしょうか？ うえで述べたとおり、委託先がパーソルに決定した背景には、COCOA開発にとってパーソルが最適なパートナーだったから、というより、時間的制約、技術的制約（HERSYSとの連動）があるなかで、消去法的に選ばざるを得なかったという事情が垣間見えます。パーソル側もどの程度この受託に積極的だったのかは正直分かりません。 実際、うえでご紹介したパーソルにCOCOA開発も

普通は役所のシステムって構築してから5年とか7年は塩漬けにして使うもので、一度やらかしてしまうと名誉挽回の機会なんて向こう数年は与えられないんだけど、こと本件に関しては高市総務大臣から「今すぐ私がマニュアルなしでも使えるように直しなさい」と叱責いただいて、しっかりと予算的なサポートも得られたことで、たったの数ヶ月で立て直すことができた。 この数ヶ月は外部のセキュリティやPKIの専門家の方から様々なサポートをいただいて何とか実現したんだけれども、役所のシステム開発としては非常識というか、極めて難易度が高い案件だった。「え？単にChromeやSafariをサポートするだけでしょ、難しい訳ないじゃん」と思う諸兄は、もうしばらくこの話に付き合って欲しい。 もともとマイナポータルは日本を代表するITベンダーと通信キャリアの3社が開発したんだけど、大臣からの叱責を受け「ちゃんとお金を払うから直してよ」

何週間か前のこと、急にエンプラっぽくないAIベンチャーの社長さんからメッセで飲みに誘われ、秋葉原の焼き鳥屋さんでDXとやらについて聞かれて、とりあえずこのレポート読んどけと返しつつも考えちゃった訳です。Direct Xとか、よくテレビに出てるマツコの方じゃなくて「2025年の崖って実際どうなんだ？」とか何とかオッサンたちから相談される話あるじゃないですか。あれって何なんですかね？オンプレをクラウドにリフトしたらDXなのか。華麗にk8sやらコンテナ使いこなしてCIパイプライン組み立ててテスト自動化したらDXなのか、だいたいDigital Transformationなのに、どうしてDXなのか。SAP R/3とCOBOL PL/Iを捨てて、どこぞのSaaS入れてSparkぶん回してPythonとか書いたらDXなのか。おいおい、そんな話だっけ？って心配になっちゃう訳です。 内製内製って簡単に言う

昨年、メルカリのようなサービスを、10万円で作る方法を考えてみるというnoteを書いたところ、6万回近く読んでいただけました。ノーコードというプログラミングのコードを書かずにいろいろなwebサービスやアプリを作れるツール群についてのnoteだったわけですが、その中に下記のようなツイートを貼り付けていました。 メルカリみたいなサービスを作ってみたhttps://t.co/lXe5towLjp 決済はできないようにしてるんだけど、実はこれ 一切コードを書かずに作ってます。 これから新規サービスを始める方は、プログラムを書いて作るか、ツールを使って作るかよく考えた方がいいかも。 pic.twitter.com/CzjpEil1Px — しんじ🇻🇳NoCodeスクール (@__shinji__) October 14, 2019 こちら、Bubbleというノーコードツールを用いて作ったのですが

NECとLINEの両極端な決算 NECが最近いい話ばかり聞くと思っていたらやっぱり調子が良いようです。 tech.nikkeibp.co.jp NECは2020年1月29日、2019年4～12月期の連結決算（国際会計基準）を発表した。売上高に当たる売上収益は前年同期比6.9％増の2兆1756億円、営業利益は779億と前年同期の4.7倍に増えて増収増益だった。2019年3月期までに取り組んだ人員削減などの構造改革によって、固定費が減少したことが大幅増益に寄与した。森田隆之副社長兼CFO（最高財務責任者）は「想定に対して（これまでの）9カ月間の累計で売上収益は1000億円、調整後営業利益は150億円上振れている」とした。 こんな強気の発表はもう思い出せないくらい久しぶりで、何が起きているんだろうとおもったら逆にLINEの決算が厳しいことに。 nlab.itmedia.co.jp LINEが1月

ユーザーはなぜ、自社のシステム開発に協力しないのか：本業が忙しいから、お手伝いはできないよ（1/4 ページ） 複雑怪奇なIT“業界”を解説する本連載、第1弾はIT業界にまん延する多重下請け構造と偽装請負について、第2弾は多重下請け構造が起こる仕組みについて、第3弾はシステム開発プロジェクトには複数の契約形態が混在することを説明した。 今回は「ユーザー」の謎を解説する。彼らはなぜ、いつも当事者感覚がないのだろうか――。 お任せ体質ユーザーの末路 私はこれまで、システム開発のトラブルに関する連載や研修などを行うために、さまざまなIT訴訟について調べてきました。 悪い意味で印象的だったのは、ある清涼飲料水メーカーの在庫管理システム構築に関するトラブルです。ユーザー企業の担当者たちの知識不足、そしていわゆる「お任せ体質」がベンダーの作業を遅らせ、ついにはプロジェクトを破綻させてしまった事件でした。

SIerが得意としてきた「工数ビジネス」は、いまや限界になりつつあります。その流れを推し進めているビジネス環境の変化を踏まえつつ、理由を解説します。 この連載は カップめんを待つ間に、電車の待ち時間に、歯磨きしている間に“いまさら聞けない”ITトレンドが分かっちゃう！　いまさら聞けないITの最新トレンドやビジネス戦略を、体系的に整理して分かりやすく解説する連載です。「この用語、案外、分かっているようで分かっていないかも」「IT用語を現場の従業員にもっと分かりやすく説明できるようになりたい」――。情シスの皆さんのこんな課題を解決します。 ※この記事は斎藤昌義氏のブログ「ITソリューション塾」より転載、編集しています。 情報システムの開発や運用では、作業量に応じて費用を支払う「工数ビジネス」が一般的です。このような業務を担うシステムインテグレーター（SIer）は、作業量に応じて人員をユーザー企

3月29日に国立弘前大学（青森県弘前市）から「ウェブアクセシビリティ向上のための弘前大学公式ホームページ，機能整備について」という報道発表があった。 次がポイントである。 平成29年度にPC版の文字の大きさ変更機能（小・中・大），背景色切替機能（白・黒）を整備し，今回，背景色切替機能に青色と黄色を追加，スマートフォンでも同機能をご利用いただけるようになりました。 障害者差別解消法が施行され、第7条で行政機関等にアクセシビリティ配慮が義務付けられた。弘前大学の機能整備はこれに対応したように見える。 しかし考えてほしい。文字を大きくして閲覧したい、背景色を反転させ閲覧したい障害者はどのようにして弘前大学サイトにたどり着いたのだろう。検索サイトを開いた時点から文字を大きくし、背景色を反転させていたからたどり着けたに違いない。ブラウザあるいはOSにはそんな支援機能が装備されているので利用したわけだ

藤原かずえ @kazue_fgeewara 毎日新聞 元号の変更に伴う官民のシステム改修は短期間での綱渡りとなり、混乱を招く可能性は少なくない 30年も猶予期間があったのにITはまだ年号のモジュール化ができていないのですか。元号がすぐにわからないと生活に困るという実例を挙げて下さい mainichi.jp/articles/20190… 2019-01-05 11:17:41

エンジニア（ここでは主にプログラマー）に必要な知識や経験って、ざっくりベース、カテゴリ、実行環境というレイヤー分けられると思ってて、それぞれに対してはだいたい以下のような定義で考えている。 ①ベース コンピュータサイエンス(CS)などの理論的なもの低レイヤー②カテゴリ フロントエンド / バックエンド / クライアントアプリなど③実行環境 特定のプログラミング言語や開発環境やツール、フレームワークやライブラリなど最近の潮流で言うと、③の部分から入る人が多いと思う。 ③は比較的習得が楽なこともあって、初心者がプログラミングを始める際には一番コストパフォーマンスが高い。中身はブラックボックスであってもなんとなく動くものは作れるので、自己満足にしろ仕事にしろ成果として見えるものにはなる。 ただし、流行り廃りが速く、手を動かし続けないとキャッチアップしていけない。 ①は習得するのに時間かかる。その

オープンソースの「ゼロサムゲーム」に終止符？ ―MicrosoftがGitHubを75億ドルで買収 MicrosoftとGitHubは6月4日（米国時間⁠）⁠、Microsoftが75億ドル（約8230億円）でGitHubを買収したことを発表しました。Microsoftは全額をMicrosoft株で支払い、2018年内には買収をクローズさせる予定としています。買収完了後、GitHubのフィナンシャルはMicrosoftのインテリジェントクラウドセグメントに帰属することになります。 買収のニュースを伝えるGitHubのブログ記事 A bright future for GitHub | The GitHub Blog GitHubの輝かしい未来（上記記事の日本語抄訳） サンフランシスコのGitHub本社内にある「考えるオクトキャット」 買収後もGitHubの企業としての独立性は維持されること

システム開発において発注者責任の自覚やその能力が無く、丸投げしかできないにもかかわらず、お客様は神様であることを信じて疑わず、買い叩くことだけに血道を上げる。しかも開発プロジェクトの最中に要件はどんどん膨らむが、追加料金は出さないし、納期厳守も要求。当然プロジェクトは破綻を来すが、その責任の全てをITベンダーに押し付ける。 こんな危ない客がいたら、ITベンダーはその開発案件を取りに行くだろうか。普通はスルーだ。諸般の事情で商談に参加しなくていけなくなったとしても、“法外な”高値を提示するなどして、間違っても受注しないように努力するだろう。そもそも今どき、そんなとんでもない客がいるのか。それが、いるのである。官公庁をはじめとする公共機関だ。 公共機関だとすると、冒頭に書いた客としての振る舞いは、その多くが「とんでもない」ではなく正当な行為となる。公共系システムは国民・住民からの税金などで作る

「詳細設計書F**k」「SIer、Sxxt」的なお話は定期的に（日常的に？）ネットやTwitterのタイムラインを賑わせているように思います。つい先日もそんな感じのblogエントリが少しバズっているのを目にしました。 よくdisられる感のある詳細設計書*1。これは作られるのでしょうか。必要だから？ではなぜ必要？ 『最近の開発では詳細設計書は必要ない』というニュアンスの発言も耳にします。では昔は必要だったのでしょうか。そもそも何のために生まれたのでしょうか。 ……話しは変わりますが、今私はちょうど、年度末のアレコレでとても現実逃避したい気分だったりします。ということで、気分転換に、昔のことを思い出しながら与太話を書いてみたいと思います。 これから書くお話は、以前 ― 正確な時期は覚えていませんがおそらくは10年前くらい ― 私がSIerに勤務していたころ、今でも尊敬している大先輩のエンジニア

わたしは、情報システムと呼ばれているものを作った経験がないので、よくわからないのだが、世の中には詳細設計書というのがあるらしい。 下記参照。 http://gm7add9.wordpress.com/2012/11/30/%E8%A9%B3%E7%B4%B0%E8%A8%AD%E8%A8%88%E6%9B%B8/ プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。 プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。 そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、