江戸から続く、 迷子になる旅館。 「木屋旅館」は江戸時代の頃から三朝の地を見守ってきた。当初は庄屋と旅籠の兼業で営業を始めたが、明治の頃から旅籠が専業になり今に至る。玄関で客を出迎える木の看板は、その当時から受け継がれてきたもの。１００年前の窓ガラスも現存しているなど、建物自身がその歴史の深さを物語っている。そんな木屋旅館を訪ねた客は、まず館内の地図を渡される。明治、大正、昭和と、時代ごとに増築を繰り返してきた建物は、とても複雑な造りになっているためだ。 「温泉施設を作ってから、それを保護するようなかたちで増改築を繰り返しているので、間取りが迷路のようになってしまって。２０１０年には全館が登録有形文化財に認定されました。携帯で館内から『迷ってしまったので迎えに来てほしい』と電話をかけるお客様もいらっしゃいます」と、木屋旅館の御舩利洋さんは言う。実際に地図を見ると本当に迷路のようだ。三階建て
委託したシステム開発が頓挫したとして、野村ホールディングス（HD）と野村証券が日本IBMを相手取って計約36億円の損害賠償を求めた裁判。プロジェクト失敗はベンダー側に非があるとした2019年3月の一審判決から一転、2021年4月の控訴審判決はユーザー企業側に責任があるとした。工数削減提案に十分に応じなかったり、プロジェクト途中で追加要件を多発したりした野村側の姿勢を東京高裁は問題視し、逆転敗訴の判決を下した。 関連記事 野村HDが日本IBMに逆転敗訴の深層、裁判所が問題視した「X氏」の横暴な変更要求 野村HDが日本IBMに逆転敗訴のワケ、「工数削減に応じず変更要求を多発」と指摘 東京高裁が特に問題視したのが、システムの仕様を策定するうえで重要な役割を担っていた野村証券のユーザー部門「X氏」の振る舞いだ。 当時、投資顧問事業部（判決文では「投資顧問部」）の次長だったX氏は、パッケージソフトに
太古の昔から、タールの沼に落ちた巨大な獣が死にもの狂いで岸に這い上がろうとしている光景ほど、鮮烈なものはない。恐竜やマンモス、それにサーベル・タイガーが、タールに捕らえられまいとしてもがく様が目に浮かぶ。激しくもがけばもがくほど、タールは一層絡みつき、どんなに力強い獣でも、また賢く器用な獣でも、ついには沈んでいってしまう。 大規模システムプログラム開発は、過去十年以上もの間そうしたタールの沼のようなものだった。そして、多くの強大な獣たちが、その中へ乱暴に突き落とされてきた。たいていは稼働システムを作り、這い上がってきたものの、目標とスケジュール、それに予算にかなったものはほとんどなかった。 規模の大小、また大量動員あるいは少数精鋭であろうとも、開発チームは次から次へとタールでがんじがらめになってしまう。問題を引き起こす原因は、一つだけではないように思われる。原因が一つだけなら、足のどれか一
行政のデジタル化に向け各省庁が民間企業などと結んだ契約について会計検査院が調べたところ、競争入札にもかかわらず、70％以上の入札に1業者しか参加していなかったことが分かりました。価格競争が働きにくい状況で、検査院は「競争性を確保する工夫が必要だ」とする報告書を国会に提出しました。 会計検査院は、行政のデジタル化に向け各省庁が平成30年度に民間企業などと結んだ「情報システム」の契約状況について、国会の要請を受けて調べました。 その結果、423件で「競争入札」が行われていましたが、このうち入札に1業者しか参加しなかった「1者応札」が73.9％を占めていたことが分かりました。 予定価格に対する平均の落札率は96％と高止まりしていて、複数の業者が入札に参加したケースより13.5ポイントも高くなっていました。 価格競争が働きにくく契約金額が割高になった形で、特にシステムの「改修」に関する契約はほとん
「要件定義を難しくする」とクローズアップされてきたのが“非機能要件”の存在である。非機能要件とは，性能や信頼性，拡張性，セキュリティなど，機能要件以外のもの全般を指す。これらはユーザーへのヒアリングからだけでは洗い出しにくい。漏れがあると，稼働後のトラブルの種になる。こうした事態を未然に防ぐ，非機能要件の見極め方を探る。 旅行代理店のアールアンドシーツアーズは，今年10月末に予定しているホテル予約システムの稼働に向けて，今，開発の真っ最中だ。このシステムは，仕入れた航空券の在庫や宿泊の空室情報を管理するホストに，2次代理店からインターネット経由で送信されてくる予約データを受け渡すもの。 開発を主導する大平雅義システム部長は，「機能要件はほぼ固まったが，性能に関する非機能要件が懸案として残っていて悩ましい」と語る。 予約データはインターネットを介してやり取りされる。そこに含まれる顧客情報は暗
Domain-Driven Design (DDD) で、アンチパターンとして取り上げられている Smart UI 。 ある文脈( context ) では、Smart UI はとても優れている。（と、エバンスも書いている） 実際、私たちが、取り組んだ５年前の開発プロジェクトでは、徹底して、Smart UI でがんばった。 プロジェクトの背景 ・短期間に既存のアプリを作り変えたかった ・中核メンバーは、寄せ集め。（ 設計や実装について、経験や考え方が見事にばらばら ) ・多数の作業者は、一年目のジュニアたち ・既存システムのソースコードは、ない。 Visual Studio で、画面量産 既存システムがあるわけだから、とりあえず、 ・画面の一覧、すべての画面のＨＴＭＬ ・テーブル一覧、テーブル設計と実データ は、そろっている。 ４００画面くらいをメンバー１０人に割り振って、ひとりあたり、４
2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー
この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り
コモンクライテリア（Common Criteria, 略称 CC）とは、コンピュータセキュリティのための国際規格であり、 ISO/IEC 15408 である。 IT 製品や情報システムに対して、情報セキュリティを評価し認証するための評価基準を定めている。 正式名称は "Common Criteria for Information Technology Security Evaluation"（情報技術セキュリティ評価のためのコモンクライテリア）である。 ISO/IEC 15408 の規格名は "Evaluation criteria for IT security", JIS X 5070 としての名称は「情報技術セキュリティの評価基準」である。 2019年3月時点においては「バージョン3.1 リリース5（2017年4月）」が最新版である。 日本ではコモンクライテリアまたは CC と呼ば
倉貫さんから直接献本をしていただいきましたので感想がてらに。 本書はいわゆる“アジャイル”を清く正しく実践している実績と、その仕組みを丁寧に解説した本です。しかも、開発体制は「事業会社の内製化」ではなく「外部のソフトウェア開発企業を継続的に利用する」というスタイルであることに大きな意味があります。 （ソフトウェア開発企業という名称ですが、もはや「ソフトウェアだけを開発している」わけではないので、本来は「ITサービスを開発している」企業というような名称が最適なのですが、ここでは一般的な名称として使います） これまでアジャイル開発方法論は「事業会社における保守運用フェーズの内製開発」に最適であるとされてきました。実際、多くのウェブ企業が社内にエンジニアを抱え、継続的な保守運用の中でイテレーティブに開発を行うスタイルを実践しています。 しかし、実際には世の中の大半の企業が“優秀なエンジニア”を雇
その昔、僕が客先常駐ソルジャーだった頃、そこには辺り一面炎上プロジェクトばかりでした。 当時僕の参加していたプロジェクトでは、 SQLで書いたら数秒〜数分で済むであろうバッチ処理をなんちゃってEJB 1.0のような独自フレームワークを使って数時間かけて処理し、挙句に朝までに終わらないと問題になって作り直したり なぜかすべてのバッチがSQL*Plusを叩くシェルスクリプトで実装されており条件分岐で済むようなケースがすべて別ファイルとしてパターン数分用意されていたため処理を少し修正するだけでも数百のシェルスクリプトを修正しなくてはいけなかったり はたまたオンラインの処理では1人のユーザがボタンを押すだけで200M以上のメモリを消費しこれ想定ユーザ数での使用にどう考えて耐えられないでしょみたいなものがあったり ResultSetをJSPまで持ち合わしてどこでもクローズされていなくてJMeterで
ビットコイン買うだけ屋のメタプラネット、MSワラントによる約7674億円の超大規模株券印刷でビットコインと心中覚悟の引くに引けない勝負を始める
IPAX 2008を見に行ってきた - 発声練習 @ITの記事は、発言の意図をねじまげて強調しているという指摘があった。確かにこのエントリを見ると、かなり印象が違う。id:next49さんの方が、パネラーの発言の真意をよく理解してまとめている気がする。 しかし、私は、このエントリを読んでますますIT業界に絶望的な気分になった。 多分西垣さんの言いたいことはそうではない。西垣さんが引用した言葉は「10年泥のように働き、次の10年で人材管理などを十分勉強してもらい、次の10年で学んだことを発揮してもらう」というような意味合いだった。言いたい言葉の意図は「業務を体に覚えさせ、体で覚えた業務をもとに人材管理を学び、そして、管理・運営を行える人材となる」ということだと思う。 これは、個人に対する心構えとしては、納得できる部分もある。 実際、私はほぼこの時間割通りに生きてきている。83年に就職して93
このエントリは 達人出版会から昨年出版された電子書籍「開発現場に伝えたい10のこと」のうち、私がヌーラボの開発の進め方について紹介させていただいた章を出版社の許可を得て転記したものです。その他の章も関西を中心に活躍しているエンジニアの経験にもとづく知見にあふれたものになっておりますので、本エントリを読んで興味をもたれたらお手に取って頂ければ幸いです。 では、少し長文になりますがおつきあいください。はじまりはじまり！ 「どうすれば価値を生み出すか」を知るためにヌーラボで行っていること 私が所属する株式会社ヌーラボは20名ほどの小さなソフトウェア開発会社です。私たちが自社で開発、運営しているウェブサービスには以下があります。 プロジェクト管理ツール Backlog オンラインドローツール Cacoo これらのサービスは、国内だけでなく海外でも沢山のユーザに利用いただき「使いやすい、楽しい」とい
分量がある文書を作成する際には、文書全体の「アウトライン（骨格、構成）」をきちんと作り上げてから内容を記述する必要があります。今回は、「読みやすく分かりやすい提案書」にするアウトラインの作成方法について紹介します。 読みやすい文書は「階層構造」をしている 読みやすい、分かりやすい文書は、全体が階層構造になっています。文書は、一般的に下記のような階層で構成されています。 大見出し（章） 中見出し（節） 小見出し（項） 階層構造は、複雑で大量の情報を含んだ文書の内容を、分類・整理するために必要不可欠です。階層化した文書は、各トピックで記述される範囲が決まっているため、焦点を絞って読むことができます。このことは、読者の理解を大いに助けます。 階層構造の方法について、順を追ってみていきましょう。まず「大見出し」の層に分割します。その後に各「大見出し」を「中見出し」の層に、さらに必要であれば「中見出
システム開発は、いくつかの開発プロセスと呼ばれる工程に分けて行うのが通例です。 開発プロセスの分け方は、各コンピュータメーカーやSIerによって若干異なります。 開発プロセスの基本 システム企画 通常、受注をする前に営業やITコンサルタントが、エンドユーザのシステムに関する要望や、現状システムの問題点などをヒアリングします。要望や問題点を踏まえて企画を立て、エンドユーザにプレゼンをして内容のすり合わせを行います。 要件定義 要件定義では、エンドユーザの現状業務をシステム分析し、業務要件とシステム化するために必要なことを定義します。また、要件定義を、システム方式設計と呼ぶ場合もあります。 エンドユーザは、システムについて詳しくない場合もあります。要求が曖昧だったり、矛盾することもあります。実現可能なものとして、エンドユーザの要求をITコンサルタントやSE（システムエンジニア）がとりまとめてい
| トップ扉 | 思考支援 . ネット革 . ＵＩ考房 . 設計技術 . シス開発 . 道具活用 | 自己紹介 | | 最近更新 | 思考方法 . 議論手法 . 説明技術 . 知能教育 . □□□□ . □□□□ | 著作更新 | | 総合目次 | 社会進歩 . 市民運動 . ジャナ革 . 未来社会 . 一流仕事 . 組織構築 | 独り言？ | | 補助索引 | 心の階段 . □□□□ . 芸術奥覗 . 残り物達 . リンク集 . 脳ぐちゃ | 推奨用語 | ソフトウェアを中心としたシステム開発では、規模が大きくて複雑なほど、いろいろな技術が必要となる。高度な設計技術はもちろん、分析技術や管理技術などもだ。これらの技術を活用できれば、難易度の高い開発でも成功の可能性が高まる。本格的なシステム開発に役立つ技術を、活用ノウハウも含めて紹介する。 ・システム開発には様々な技術が必要 ・力ずくから
情報システムの信頼性 非機能要求グレード報告書 ソフトウェアメトリクスの高度化 産業構造・市場取引の可視化 「情報システムの信頼性向上のための取引慣行・契約に関する研究会」 ～情報システム・モデル取引・契約書～ 情報サービスソフトウェア産業における下請適正取引等の推進のためのガイドライン ADR（裁判外紛争解決手続） 情報システムにおける価値の可視化 「IT投資価値評価に関する調査研究」（試行版） 情報サービス・ソフトウェアを巡る取引構造・産業構造の不透明性が、ベンダ間、ユーザ・ベンダ間、ユーザ内に存在しております。 また、不透明な取引構造・産業構造は、ベンダの産業構造転換の遅れ、情報システムの信頼性問題の温存、ユーザ・ベンダ一体となった生産性向上の阻害の要因となっています。 このため、各局面の取引構造を透明化するツールを整備し、これらを普及することで、ベンダの産業構造転換、情報システム信
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: なぜ、システム開発は必ずモメるのか?: 細川義洋: 本
