情報システムの障害状況ウォッチ（2016年後半） - 勘と経験と読経
SEC Journal48号で2016年後半の情報システム障害状況まとめが公開されたので読んでみる記事。いろいろあってすでに2017年も4分の1が過ぎてしまったので今更感もあるのだけれど。 過去に書いた関連記事は以下の通り。 情報システムの障害状況ウォッチ（2016年前半） - 勘と経験と読経 情報システムの障害状況ウォッチ（2015年後半）、ポストモーテム - 勘と経験と読経 情報システムの障害状況（2015年前半）あるいは検死解剖 - 勘と経験と読経 SEC Journal最新号の入手はこちらから。 最新号とバックナンバー：IPA 独立行政法人 情報処理推進機構 情報システムの障害状況ウォッチ（2016年後半） 詳細はSEC Journalを確認いただくとして、掲載されているトラブル事例をいつもどおりニュース記事などとザックリ照らし合わせてみた。例によって調べているとお腹が痛くなる事案
情報システムの障害状況ウォッチ（2016年前半） - 勘と経験と読経
SEC Journal46号で2016年前半の情報システム障害状況まとめが公開されたので読んでみる記事。2015年度の分については以下のエントリを参照。生々しい話を読むと、自分がトラブルを引き起こす確率が減るんじゃないかと思っている。 情報システムの障害状況ウォッチ（2015年後半）、ポストモーテム - 勘と経験と読経 情報システムの障害状況（2015年前半）あるいは検死解剖 - 勘と経験と読経 SEC Journal最新号の入手はこちらから。 最新号とバックナンバー：IPA 独立行政法人 情報処理推進機構 情報システムの障害状況ウォッチ（2016年前半） 詳細はSEC Journalを確認いただくとして、掲載されているトラブル事例を例年通りニュース記事などとザックリ照らし合わせてみた。例によって調べているとお腹が痛くなる事案ばかり。 [1601] 緊急速報メールで誤報(津波) 「大津波」
ウォーターフォール型開発プロセスの有効性 - 勘と経験と読経
牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ
ITアーキテクトとは何か - 勘と経験と読経
割と身近なところで頻繁に「ITアーキテクト」という単語か飛び交っていて、もやもやしたので情報を整理しながら書く記事。オチはない予定。 photo by SantiMB.Photos ITアーキテクトの定義 例えばIPAの共通キャリア・スキルフレームワークでの(システムアーキテクトの)定義はこんな感じ。 http://www.ipa.go.jp/jinzai/itss/csfv1.html システムアーキテクト 人材像の役割 ビジネス戦略 に対して最適 なシステムを デザインする。 IT戦略を受け、ソリューションを構成する、又は組込み製品開発に必要となる要件を定義し、それを実現するためのアーキテクチャを設計する。 情報処理技術者試験における(システムアーキテクトの)定義は次のとおり。 IPA 独立行政法人 情報処理推進機構：制度の概要：システムアーキテクト試験 情報システム戦略を具体化するた
マークアップ、Excel方眼紙 - 勘と経験と読経
自分の所属がSIerだからなのかもしれないけれど、一定比率で「文書はExcelで書くのが効率的」と主張する輩が周りに出現する。Excelはやめてと言っても聞いてもらえない。いわゆるExcel方眼紙。とはいえ、SIばっかりやっていて、おバカになってるのだけが理由とも思えないので、いろいろ考察してみたりした話。ちなみに自分は反Excel派。 公務員が公開するネ申Excelが日本の生産性を落としている話 - Togetterまとめ 「ネ申 Excel」問題 - 奥村研究室 - 三重大学(PDF) ExcelがWYSIWYGなのじゃないか仮説 Excel派の話を聞いていると、なんとなくExcelこそがWYSIWYGだと思っているような気がする。 Wordは、思ったように資料を作りにくい。文書構造を意識したり、各種のワードプロセッシングが煩い。あと罫線引いたりが難しい PowerPointは、自由自
思考停止ワードとコミットログとコードコメント - 勘と経験と読経
古い記事になるのだけれど、バージョン管理ツールにコミットログのNGワードを登録するという話が面白かった。ソフトウェアは思考がそのまま品質につながるようなところがある。思考停止に近しいワードを禁止してしまうのも手かもしれない。 コミットログのNGワード 注意するのも疲れるし、大抵の場合は注意しても直りません。 そんなわけで、私が面倒を見ている環境だとpre-commit-hooksを使って、規定のバイト数のコメント書かないとコミット出来ないようにして対応しています。 コミットコメントを意地でも書かせたい - almost nearly dead 単にコメント無しを規制するだけではなく、思考停止してしまうようなワードを禁止しているのが素敵。 また、これに加えて会社名や人名も禁止してしまうのはうまいやり方だと思う。人の名前が出てくるとそこで情報が隠蔽されてしまうし、「問題 VS 我々」のスタンス
タコマ海峡橋（タコマナローズ橋)のこと - 勘と経験と読経
用事があって久しぶりにマコネルのCode Completeを読み返していたら、タコマ海峡橋の写真が目に入った。タコマ海峡橋と言えば、有名な工学的失敗事例で、フレデリック・ブルックスの本でも写真が掲載されていた。というわけで興味が出てきたので、改めてどんな事故だったのかを調べてみた。 タコマ海峡橋（タコマナローズ橋) タコマナローズ橋（タコマナローズきょう、Tacoma Narrows Bridge：タコマ橋）はアメリカ合衆国ワシントン州のピュージェット湾口の海峡タコマナローズ（Tacoma Narrows）に架かる吊り橋である。 初代の橋は設計上の問題により、架橋後間もない1940年11月、予想に満たない強風の影響で落橋する事故を招いた。この事故は、技術史の中でも共振が生じた結果の被害現象として、たびたび実例に挙げられている。 タコマナローズ橋 - Wikipedia Wikipediaで
ソフトウェア・エンジニアと武士道、騎士道精神（アジャイル話じゃないよ） - 勘と経験と読経
SIerがオワコンだったり新人SEが絶望する今日この頃。組織を憂う前に自分が技術者として終らないようにするほうがよっぽど建設的だと思っている。ひとこと「勉強しよう」というのは簡単。それよりも先に、職業倫理について考えてみるのはどうだろう。 職業がプロとして成熟した証の一つは、倫理規定または職業上の行為の水準が存在することである。 ソフトウエア開発プロフェッショナル 第20章 専門的職業の倫理規定（P239） マコネルの会社のエンジニアが最初に学ぶこと コンストラックスは、Code Completeで有名なスティーブ・マコネルの会社である。同社の専門技術者育成プログラムがソフトウエア開発プロフェッショナルに紹介されていて興味深い。英語版は以下からダウンロードできるようだ。 Construx Professional Development for Software Organizations
顧客レビューのうまいやり方 - 勘と経験と読経
お客様から発注されたソフトウェアを請負で開発する場合に悩ましいのが、顧客(発注者)レビューの扱いだ。そもそもソフトウェアの設計をレビューすること自体が難しいアクティビティである。その難易度に加えて、ソフトウェア開発の専門家ではない顧客(発注者)に要求や設計をレビューするのだから、相当難しい。結果として、大量の顧客(発注者)指摘事項が出てきて途方に暮れる、というのがソフトウェア開発の現場でよく見る風景だ。顧客(発注者)レビューのうまいやり方というのは無いのだろうか。 指摘に苦しめられた（？）特許庁システム 膨大な指摘で苦戦する話、で思いだすのは2012年初めに報じられた特許庁基幹システム刷新中止の件だ。公開されている議事録別紙資料などを見ると目眩がするようなグラフが書かれている。スライド9ページあたり。 特許庁情報システムに関する調査委員会報告書(技術検証チーム)ご指摘に関する状況について(
日本型ソフトウェアファクトリーこそ真の敵 - 勘と経験と読経
最近ネットで話題になったスライド「ウォーターフォールの歴史」を見ながら、むしろ皆の仮想敵はウォーターフォールではなく、日本型ソフトウェアファクトリーなのではないかと考えた次第。 最近アジャイル界隈でよく聞く話 「自分の現場がウォーターフォールで全然ダメで それをアジャイルなら変えられないかと思って」 いったい誰と戦っているんだ・・・・・・ History of WaterFall - Speaker Deck 真の敵はこいつだ！ ソフトウェアファクトリ software factory / ソフトウェア工場 / ソフトウェア生産工場 組織的ソフトウェア開発アプローチの1つで、ソフトウェア開発に関する手順、手法、ツールを標準化してノウハウや知識、成果物の蓄積と再利用を促進し、厳格な工程管理・品質管理を適用することで、ソフトウェア開発の生産性と品質を向上することを目指すコンセプトのこと。また、
ソフトウェア開発プロジェクトで見落とされがちな作業について - 勘と経験と読経
ソフトウェア開発プロジェクトは定形化しにくい。常に進化する技術、物理的な制約をほとんど受けないソフトウェアの特性などが原因の一つだ。定形化できないので個別に計画を立てる必要がある。そして計画時に「本来は必須の作業」の考慮を漏らして、あとで後悔することになる。後悔先に立たずの果て。 5．作業を計算に入れ忘れる テストのような必要不可欠な作業を計算に入れずに決められたた めに、破られた締め切りがいくつあったことか。これが、作業を部分的なタスクに分割しないままスケジュールが決められた仕事を決して引き受けてはならないもう1つの理由だ。そのスケジュールの見積もりには、なにか重要なことが抜けている可能性がある。 ソフトウェア開発プロジェクトを蝕む10の典型的な過ち - CNET Japan CNET 「ソフトウェア開発プロジェクトを蝕む10の典型的な過ち」 - カレーなる辛口Javaな加齢日記経由で発
前任者の見積りを信用しない - 勘と経験と読経
他人が担当したプロジェクトを引き継いたり引き取ったとき、私は「前任者の見積り」を信じないようにしている。自分で情報を改めて収集整理して見積もり直してみる。前任者の見積りと大きな差が無ければ問題ないが、差があればマネジメントなどに必要なエスカレーションをして、差を小さくするための作戦を考える。 そもそも「見積り」というものは危険な爆発物なのだ。他人の精錬したブツに命を預けるなどということは恐ろしくて考えられない。 「前任者の見積り」に潜むリスクはたとえばこんなもの。 見積りを行った時の状況がわからない。3ヶ月かけてじっくり検討した結果なのか、「明日までに見積もって」と顧客から言われて算出したものなのか 見積りの暗黙的な前提がわからない。重要なインプットや前提はだいたい明記されているけれど、関係者間の「あたりまえ」が抜けていたりするので怖い 見積りをした人のスキルや能力が読み切れない 見積りの
ソフトウェア開発プロジェクトは「負ける」宿命なのか - 勘と経験と読経
「どうやったらプロジェクトの失敗を防げるか」について話していたら、後輩の一人が面白い事を言った。「システム屋は最初から負けている」。くわしく聞くと、こういうことらしい。 ソフトウェア開発プロジェクトの総予算は早い段階で確定していて、増額は困難である。 早期に全ての要求を見通すことは不可能であり、プロジェクトを始めていくとスコープは少しづつ増えていく。原価も増えていく。 プロジェクトを開始した以上、途中でバスを降りることは不可能である。収益が悪化しても走り続けるしかない。 故に、われわれシステム屋は「負ける」宿命を負っている。 いろいろとツッコミどころはあるのだけれど、想う所を整理してみたい。 じゃあビジネスアジャイルだ、ということではない アジャイル脳的な反応が容易に予測できる。 最初に大きく計画し一括で開発しようとすること自体が誤り。リスクを極小化しビジネス価値を最大化するために、アジャ
永遠なるソフトウェア工学の諸問題 - 勘と経験と読経
マイケル.A.クスマノの「ソフトウエア企業の競争戦略」という本の中で紹介されている、1968年(!)に発表された「ソフトウェア工学の諸問題に関するNATO報告書」の内容を知って絶望したことについて。 ちなみに、「ソフトウェア工学」という言葉そのものも、ほぼこのあたりが発祥らしい。つまり、これから紹介する諸問題は「ソフトウェア工学」のはじめからあったということ。 たぶん原典はhttp://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDFだけどちゃんと読んではいない。 ソフトウェア工学の諸問題に関するNATO報告書（１９６８年） 顧客と設計者側のシステム要件に対する理解の欠如 見積もり技術の未熟さが原因の、経費および時間に関する大きな予実差異、要件変更に対応する期間延長の不履行、および作業分割の内容が十分に理解されないうちに実施され、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
