システム開発の契約が民法改正で変わる
民法の契約に関する内容が、120年ぶりに改正される。明治時代に制定された法律が現在まで変わらなかったというのも驚きである。当然ビジネス形態やそれを取り巻く環境は大きく変わり、現状に沿った改正がなされることになった。民法は私たちの生活やビジネスに直結するため、大きな影響が予想される。 改正案は2015年に既に通常国会で審議され、2017年度の国会で可決されれば2019年頃に施行される見込みである。施行までに期間が空いているのは、周知に時間がかかり、かつ影響が大きいことを示している。 民法が改正される点は約200項目あり、その中でもIT業界はシステム開発委託契約が大きく変わると見られている。委託契約が多いIT業界においては広範囲で影響を及ぼす可能性があるため、事前にどのようなものか把握し対応する必要があるのである。 ※2016年7月22日に公開した記事ですが、リライト記事に必要な文言等を一部追
技術的負債を管理する
1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元本額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す
みずほ銀行のマルチベンダー化について解説する - novtan別館
はてブではすでにボロクソ言われてますね。フラグ立ちまくりと。ちょっとこれは解説せねばなるまいか… 以下はすべてとある人からの伝聞です。伝聞なんだってば。 みずほ銀行が次期システムの開発をマルチベンダー体制で進めることが日経コンピュータの取材で判明した。富士通、日立製作所、日本IBM、NTTデータの4社に分割発注する。 ［スクープ］みずほの次期システムはマルチベンダー、4社に分割発注 | 日経 xTECH（クロステック） 周知の話だけすると、現行システムにおいては 勘定系（ホスト）…富士通 営業店端末システム…富士通 インターネットチャネル（ダイレクトバンキング）…IBM 情報系システム…IBM 周辺系（中継系）…IBM 外部接続系…日立 コーポレート銀行勘定系…日立 等々、すでにここに出てきているベンダーがマルチベンダーの状態で仕事をしている。また、ここ重要なところだと思うけれども、ベンダ
構成管理 実践入門 第1章 構成管理入門 はじめに
第1章 構成管理入門 はじめに なぜ今構成管理に注目するのか 本特集で扱う内容 サンプルの準備 第2章 Subversionによるバージョン管理入門 はじめに クライアント環境の構築 インポート チェックアウト ソースファイルの変更に関連する操作 チーム開発に関連する操作 おわりに 第3章 Subversionベストプラクティス はじめに 帰ってきたO先輩 コードライン編その１ メインライン コードライン編その２ コードラインポリシー コードライン編その３ プライベートバージョン サードパーティライブラリのバージョン管理 リリース編その１ リリース管理 リリース編その２ 自動リリース 継続的インテグレーション 第4章 Maven2によるビルド入門 はじめに なぜMaven2なのか？ Maven2のインストール まずは試してみよう さらに開発を進めよう 第5章 Maven2ベストプラクティス
仕様変更を言い出すのは誰か？ - rabbit2goのブログ
ソフトウェア開発時の仕様変更は頭が痛い問題だ。限られた時間とリソースの中で開発を進めているのに、仕様変更に伴う追加作業は「既存工程の中で吸収する」なんて言う、いかにも日本人的な対処を余儀なくされることが多い。工程が延びても、コードを書き上げテストを行って動作確認までした成果物に再び手を入れなければならないという精神的なダメージも大きいと思う。 「お客さんの要望だから仕方ない」という理由は分かるし、「仕様変更しなければ製品が売れない」という理屈も納得できる。それは正論だ。しかし、だからと言って、何度も仕様変更を続けて、開発現場に負荷をかけるやり方が正しいとは到底思えないような気がする。モノには限度というものがあり、それを越えた仕様変更は然るべき理由と共に拒否するのが当然ではないかと思う。 そんな度重なる仕様変更に腹を立てて、仕様変更の要求が来る度にTracのチケットを起票したことがある。記載
SIビジネスの流れ - @ledsun blog
システムインテグレータ（SI）のビジネスは大きく以下のような流れで進みます。 集客 営業 要件定義 製造 検収・請求 フォローアップ 集客 どんなビジネスでも同じですが、まずは見込み客を集めます。システム開発に興味を持ったお客様を探しアポイントを取ります。よく使われる手法に商品・サービスの説明をするテレアポ、割引を謳ったDM、自社の推す技術のセミナー、役員が個人的に懇意にしている既存顧客の紹介があります。会社の規模やブランドにマッチした手法を選ぶ必要がありますが、会社が成長にするにつれ手法を変えていかなければいけないのが難しいところです。 営業 アポイントの取れたお客様に顧客に直接、自社の提供するサービス、商品の説明を行います。また会社の紹介も同時に行います。お客様がある程度の金額を掛けてソフトウェア開発を行いたいと意思表示をされた場合に次の段階に入ります。そこで現状の課題を聞き出します。
システム開発の要件定義に関する考察
Satohru Note(http://satohru.blogspot.jp/)では、ITに関する考察や作品（写真、小説、音楽）の掲載などを行っています。 新作小説『エクストリームセンス』連載中。 【案内】小説『エクストリームセンス』について 小説『エクストリームセンス』は、本ブログを含めていくつか掲載していますが、PC、スマフォ、携帯のいずれでも読みやすいのは、「小説家になろう」サイトだと思います。縦書きのPDFをダウンロードすることもできます。 小説『エクストリームセンス』のURLは、 http://ncode.syosetu.com/n7174bj/ 私は先日、KenichiroMurata氏のブログ「要件定義の怪物、ビジネスルールをいかにして仕様化するか？」を読みました。これは、システム開発の上流工程に携わる人々にとって、大きなテーマだと思います。 私は富士通グループの開発者と仕
Selenium
Selenium automates browsers. That's it!What you do with that power is entirely up to you. Primarily it is for automating web applications for testing purposes, but is certainly not limited to just that. Boring web-based administration tasks can (and should) also be automated as well. Selenium WebDriver If you want to create robust, browser-based regression automation suites and tests, scale and di
普通の業務系PGには意外と知られていないJavaとJavaScriptの相違点10選 - 達人プログラマーを目指して
以前はJava EEの普通のWebアプリケーションで、JavaScriptはあくまでも利便性のために補助的に使うものという認識がありましたが、さすがに最近では普通の業務系のSI案件でもテーブル表示や入力補助などで高度なAjaxライブラリーの使用が当たり前のように求められるようになりつつあります。サーバーサイドのJavaScript技術といったものもありますが、そういった新しい技術を使わないまでも、ごく普通にある程度大きなJavaScriptの作成が必要になってきているということです。 もちろん、JavaとJavaScriptはその名前にかかわらず、本来全く別の言語です。しかし、意図的に似た構文でロジックが書ける*1ため、兄弟の言語として認識している人も意外に多いのではないかと思います。しかし、使用できるライブラリーに違いがあるという点が一見してわかる最も大きな違いですが、基本的な言語の文法
長年、邦訳されなかった「思慮深いソフトウェア開発者全員の必携書」
「Domain-Driven Design」通称「DDD」の原著が出版されたのは、2003年のことだった。Kent Beck氏が賛辞に寄せた「思慮深いソフトウェア開発者全員の必携書」という言葉が示している通り、英語圏では圧倒的な支持を集め、出版から7年が経過した現在でも、Yahoo! Groupsのメーリングリストでは活発な議論が交わされている。 一方、日本では少し状況が異なる。識者の間では、有用な書籍として早くから知られていたものの、500ページ超という厚さと、文体の難しさが、多くの日本人エンジニアの挑戦を阻んできた（邦訳も待ち望まれたが、長い間出版されなかった）。 佐藤匡剛氏による「Domain-Driven Designのエッセンス」、徳武聡氏による「DDD Quickly 日本語版」をはじめ、日本語の情報は少なからず存在したし、国内での実践事例も徐々に蓄積されていたものの、本質的に
日本のソフトウエア産業、衰退の真因
ソフトウエア・エンジニアリングのリーダーの一人、エド・ヨードンは1992年に、『Decline and Fall of the American Programmer 』を著し、米国のソフトウエア産業の衰退と挫折を警告した。この本を出す少し前まで、彼は「この国が危ない（A Nation at Risk）」というタイトルで講演行脚をしており、同書はそれをまとめたものである。 この本の中で、ヨードンは日本をソフトウエア開発における優等生の一人として挙げ、インドの飛躍を予見している。本が書かれた時点では、インドのＩＴ産業はまだ黎明（れいめい）期にあったが、彼の予想通り、現在は英語圏で質の高いソフトウエア開発力が得られる国として、欧米から頼られる存在になり、ＩＴ立国を目指す他のアジア諸国からお手本と見なされるまでになった。 「この国が危ない」というヨードンの警告に触発されたのか、米国上院の「米国の
学び続ける姿勢 - Strategic Choice
Continuous LearningClint Shank学び続ける姿勢クリント・シャンクどういうこと？自分の市場競争力を維持するためには、「学び続ける姿勢」がとても重要です。どうして？学ぶことを止め、ずっと同じ仕事にしがみついていると、いずれ必要とされなくなる日が来ます。自分の仕事が、よりコストの安い誰かにアウトソースされることもあります。技術はすごい速さで変化していきます。学ばなければ置いていかれるのは確実です。どうすれば？学び続ける姿勢を保つための手段です。書籍や雑誌、ブログなどを読む。本当に身につけたい技術は、コードを自ら書き、手を動かして学ぶ。常に自分よりレベルの高い人と仕事をするようにする。レベルの高い人が周囲にいないようなら、転職を考える。自分の「良き師」になり得る人をネット上で探す。自分の利用しているフレームワークやライブラリに対する知識を深める。オープンソースなら、ソー
Clear and Present Scrum on Devlopers Summit 2011
This document appears to be notes from a presentation or seminar about agile development methodologies like Scrum. It includes definitions and descriptions of agile roles like Agile Coach and discussions of surveys about the use of agile practices in industry. Diagrams and statistics are referenced from other sources and there are recommendations to check additional resources on Scrum and agile me
ニッポンIT業界絶望論:江島健太郎 / Kenn's Clairvoyance - CNET Japan
日本のIT業界は救いようがない。絶望的としか言いようがない。 IT業界不人気なんて、この業界に重くのしかかる決して晴れることのない暗雲の氷山の一角に過ぎない。はてなの匿名ダイアリーにもどうせ理系出身者なんていらねえんだよ。なんて書かれていたけど、これが現実なのだよ、学生諸君。 ちょっと補足しておくけど、ここでIT業界っていうのは、SIerのことだ。お客さんの要件をヒアリングして、その要求に沿ったシステムを受託開発するっていうビジネスのことを指している。 ぼくもその昔、その世界のループに組み込まれていた。そして華麗なるコミュニケーション能力とやらをいかんなく発揮し、場の空気を読み、生意気なぐらいのチャレンジ精神で、それなりに仕事のできるよい子だったようだ。 いや、正直に言うよ。正直に言うとだね、結構楽しかった。 だって、考えてみてごらん。お客さんのところに出向いて行って、その業界のことをじっ
アジャイルモデルのエッセンス: アジャイルに作れる成果物
by Scott W. Ambler, Copyright 2003 効果的にアジャイルモデリングを行うには、さまざまな種類のモデリング手法を知っておく必要があります。残念ながら、これは口で言うほど簡単なことではありません。このページはまだ作成中ですが、さまざまなモデリング成果物の概要へリンクしています。各ページには、その成果物についの解説と、1、2の例、推奨文献へのリンクが含まれています。 モデリング成果物 ビジネスルール ビジネス/本質ユースケース 変更案 CRC(Class Responsibility Collaborator)モデル 制約事項 取り決めモデル データフロー図(DFD) 本質/ビジネスユースケース 本質ユーザインターフェースプロトタイプ ユーザ機能 自由形式の図 フローチャート 用語集 Logical Data Model (LDM) ネットワーク図 オブジェクトロ
UML入門 - IT専科
UML（Unified Modeling Language）とは、様々な開発現場で使用されている設計書の書式を統一する目的で規定された言語で、1997年にOMG ( Object Management Group ) により標準化されました。 但し、UMLによる標準化はあくまで表記方法であって、開発手法の方法論ではありません。 UML2.0では表記方法を以下のように分類しています。 構造に関する表記 振る舞いに関する表記 構造に関する表記 ・クラス図（Class Diagram） クラス構造を表現します。 ・オブジェクト図（Object Diagram） クラスをより具体化したオブジェクトで表現します。 ・パッケージ図（Package Diagram） クラスなどをグループ化し整理された関係を表現します。 ・コンポジット構造図（Composite Structure Diagram） クラ
BABOK 2.0を読んでみよう - ＠IT情報マネジメント
ビジネスアナリストも基礎能力が大事 連載：BABOK 2.0を読んでみよう（6） 今回はビジネスアナリストに求められるスキルセットをまとめて定義した知識エリア「基礎コンピテンシ」やBABOK認定資格を紹介する
ソフトウェア工学 (吉田誠一のホームページ)
Abstract Factoryパターン Adapterパターン Bridgeパターン Builderパターン Chain of Responsibilityパターン Commandパターン Compositeパターン Decoratorパターン Facadeパターン Factory Methodパターン Flyweightパターン Interpreterパターン Iteratorパターン Mediatorパターン Mementoパターン Observerパターン Prototypeパターン Proxyパターン Singletonパターン Stateパターン Strategyパターン Template Methodパターン Visitorパターン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Press Enter■
さらに分かっておきたいトランジスタの種類 − ＠IT MONOist