ITmedia エンタープライズ：「下請け」から抜け出すIT戦略――親会社は顧客に数倍の見積もりを出していた！ (1/4)
「下請け」から抜け出すIT戦略――親会社は顧客に数倍の見積もりを出していた！：「IT経営百選」に見る理想の中堅企業像（1/4 ページ） 経済産業省と情報処理推進機構（IPA）は中小企業のIT化支援を目的に、2004年8月に「IT経営百選選考委員会」を組織した。そのいきさつと選定結果が「WPC EXPO 2005」で紹介された。 宍戸周夫 大企業であれ中小企業であれ、企業と名のつく限り、何よりもビジネス戦略が重要である。情報システムを構築するに当たっても、まず自社のビジネス戦略を明確に打ち出し、それに対して最適なツールを導入することがポイントになる。 当然のことだが、単に最新のITを導入すればいいという問題ではない。こだわりのビジネスモデルを構築し驚異的な売上高経常利益率を生みだして、「IT経営百選」で表彰されたような全国の中小企業の事例を見ても明らかである。 前回に続いて、WPCフォーラム
ソフトウェア開発をシンプルにする考え方のコツ ― ＠IT
ソフトウェア開発ではこれまで、できるだけ「シンプル」に設計・開発することの有効性が繰り返し提言されてきた。ソフトウェアをシンプルにすればするほど、設計は見通しが良くなり、開発は容易になり、メンテナンスも楽になる。 では、開発を＜シンプル＞にするというのはどういうことなのか？ 一体どうすれば＜シンプル＞になるのか？ これらの質問にあなたは即答できるだろうか。実際のところ、頭ではシンプルにすることが良いと分かっていても、現実には実践できていなかったりするのではないだろうか。 そこで本稿では、現実の開発現場でシンプルな設計・開発を行うための1つの手段として、その「考え方のコツ」を考察する。もちろんこのコツを身に付けることは、すべてのソフトウェア開発で役立つものだろうが、特にNAgile（エヌ・アジャイルまたはナジャイル）を実践していくうえでは、ぜひ知っておいてほしい（NAgileについての概要は
わたしが知らないスゴ本は、きっとあなたが読んでいる いきなりコンサルタントに抜擢されたSEが読むべき3冊
この記事のまとめ。また長文エントリごめん。“IT”コンサルじゃない、「ファーム」のコンサルタントと一緒に仕事をするハメになったら読む本。 「問題解決プロフェッショナル」を読めば、コンサルタントの土俵で話ができる SEとしての分をわきまえるなら「RFP＆提案書作成マニュアル」で準備しておく SEには、コンサルタントに無い視座がある。その強みを生かす「業務システムのための上流工程入門」 コンサルタントは、知識経験ないけれどキャラとハートがおおまかカバーすることはぶっちゃけありえない。そうなったらどうしようと思い悩む前にメモをどうぞ。 このblogは「それを知らなかった私にとって有益なもの」になるように心がけてる。つまり、その記事の知識・情報を知らなかったとして、「あ、こんな記事を見つけてラッキー」と思えるようなネタ。 で、この記事は一年前の私が見つけたなら「お、タイムリー」と思えるような内容
わたしが知らないスゴ本は、きっとあなたが読んでいる: 画面仕様書を「作らない」リスク
IT Pro の開発ドキュメントの最適化で笑わせていただいた。これ書いた人は画面仕様で酷い目に遭ったことがないんだろう。笑った箇所は次の通り。 画面仕様書をプロトタイプ・アプリケーションで代用する方法がある。Webシステムの場合は，HTMLの作り方を工夫すればプロトタイプで実際の入力手順や画面遷移も確認できるようになる。エンドユーザーにとっても，ドキュメントよりは実際の画面で確認した方が分かりやすいので，手戻りが減る。これは帳票にも同じことが言える。 あのな、HTMLで作る画面なんざ、紙芝居だよ。「ふいんき」をかもし出すだけで、そいつは「仕様」じゃねぇ！ボタン配置や文字色を目の前で変えられるものだから、いつまでたっても顧客は「ちょっとコレ直して」と言ってくるんだよ。気軽に直せるものとお金を頂戴しないと直せないものがあることをギッチリと顧客に理解していただくために、画面仕様書はどうしても必要
ソフトウェア工学とは何か
ソフトウェア設計とは何か？ （原文： What Is Software Design?） by Jack W. Reeves (c)C++ Journal - 1992 訳者まえがき この文書は，Jack W. Reeves 氏が1992年に C++ Journal に寄稿した記事の邦訳です。 本記事では，オブジェクト指向プログラミング言語の代表として C++ を挙げていますが，これは本記事が執筆された当時，一般的に利用可能なオブジェクト指向言語は C++ だけであったという事情があるためです。 今では C++ に加えて Java，Delphi，C# といったオブジェクト指向言語が利用可能となっていますが，そんな今でさえこの記事は古さを感じないものとなっており，ソフトウェア開発の本質，現状を鋭くえぐるものとなっています。 邦訳の公開を許諾していただいた Jack W.
ドキュメントレビューに役立つ40のチェックポイント ― 1/3 ― ＠IT情報マネジメント
プロジェクトを進めるうえで、トラブル発生による手戻りを未然に防止するほかに、進ちょくを測ったり、リスクを予測したりするためには、ドキュメントレビューが効果的である。ここでは、主要なドキュメントに対するチェックポイントを紹介する。 仕様書のチェックリスト 以下に仕様書の基本的なチェックポイントを紹介する（なお、第4回の「急がば回れ──質の良い仕様書の作り方」も併せて参考にしていただきたい）。 ソフトウェア開発というのは、意図するところを人間の言葉からいくつかの成果物（ドキュメント）を経て、コンピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水を途中でつぎ足すことは、なかなか難しいもの。早い段階──仕様書には“漏れ”がないようにしたい。 （1）題名は、システム名を明記しているか 仕様書の題名に「?システム仕様書」のように、システム名が明記されているか。“名は体を表す”
メタとは何か？ 自己言及の世界の危険と不思議そして語ることの重要性 - 哲学するIT ITする哲学 [ITmedia オルタナティブ・ブログ]
前回、『私は、XMLの"M"は、Markup (Language)の略でなく、Meta（Language）の"M" であるべきだと思っている。』と書いた。そこで、『メタ』についてもう少し、考えてみることにする。 ＜メタとは何か＞ メタ（meta）は、古代ギリシャ語のmetaに由来する接頭語であり、以下のような複数の意味を持ち、かつ複数の意味を結び合わせたものになっている。 （１） 後ろの、背後の（after, later, behind） （２）～を超えた、高次の、包括的な（beyond, higher, transcending） （３） ～ついて〔記述する〕（about, descriptive） （４） 変化（change, transformation） （５） 〔化学において使われて〕メタ… ←"～の間（between）" いくつかの接頭語メタ（meta）のつく言葉をあげて、上記
![メタとは何か？ 自己言及の世界の危険と不思議そして語ることの重要性 - 哲学するIT ITする哲学 [ITmedia オルタナティブ・ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/4e1d2cb9353ab49cda008e89be8bc704459e0e5a/height=288;version=1;width=512/https%3A%2F%2Fblogs.itmedia.co.jp%2Fmt-static%2Fsupport%2Fassets_c%2Fuserpics%2Fuserpic-356-100x100.png)
＠IT：明日からできるプロジェクト管理（4） - 単体テストの品質をチェックするには
明日からできるプロジェクト管理（4） 単体テストの品質をチェックするには 1page｜2page｜3page 高野敦 2006/1/12 実装・単体テストの品質をうまくチェックするにはどうすればいいのだろうか。本稿ではまず品質の考え方を概観し、その後、チェックを現実化するツールを紹介していく（＠IT編集部） プロジェクトマネージャ（＝PM）の石出さんは今日も悩んでいます。 石出さん談――。 今度のプロジェクトは実装・単体テストを一括発注することになった。でも一括発注だとどのように品質をチェックしたらいいのだろう。いつものように目の前で作業をしてくれれば分かるんだけれど……。 なるほど、石出さんは実装・単体テストの品質に関して悩んでいるようです。 ◆ 品質の考え方 品質には大きく分けて2つの考え方があります。製品（システム）そのものの品質と製品を作成するプロセス（作り方）の品質です。前者は、
強みの上に自らを築け － ＠IT自分戦略研究所
コラム：自分戦略を考えるヒント（26） 強みの上に自らを築け！ 堀内浩二 2006/1/12 堀内です。明けましておめでとうございます。 今回のタイトルである「強みの上に自らを築け」という言葉は、昨年亡くなった「マネジメントの父」、ピーター・ドラッカー教授の言葉として知られています。自分戦略を考えるうえでは「定番」といえる言葉です。 ただ、キャリア相談を受ける中でしばしば気になるのが、「強み」イコール「他人が口出しできないくらいの専門領域を持つこと」だととらえられていること。もちろんそれも強みを構成する要素ですが、それだけではありません。そこで今回は「強み」についてじっくり考えてみたいと思います。 ■強みとは何か （1）強みとは相対的なもの ある力が強みになるかどうかを決めるのは、非常に相対的な基準です。つまり需要と供給のバランスです。 需要＞供給の典型は、「ほかに分かる人がいないから」と
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
ビジネスプロセス・マネジメントのすすめ － ＠IT情報マネジメント
経営環境の変化に応じて、業務プロセスや情報システムを俊敏に変更できるようにする──という提案に異議を唱える人は少ないだろう。しかし、それを実践するのははなはだ困難だ。その理由と解決策としてのBPMについて解説する。（→記事要約<Page 2>へ） 企業経営の進化を継続するために、「BPM（ビジネスプロセス・マネジメント）は有効である」が本論のテーマです。 BPM適用領域についてはいろいろな意見があります。意見の違いはBPMを情報システム構築の手段として見るか、ビジネスプロセス・マネジメントという言葉の持つ意味から見るかによるものです。ここでは後者の立場で全体概要を説明します。 コミュニケーションが成り立たない！ 事業運営に情報システムが欠かせないことは、誰もが納得できるしょう。しかし、事業の推進と情報システムの構築の関係は水と油のごとく遊離しているように思えるのはなぜでしょうか？ 次のよう
ウノウラボ Unoh Labs: 共同開発を効率よく行う方法
尾藤正人です。 ウノウではおかげさまで順調にエンジニアの数が増えてきました。エンジニアが増えてくると、共同開発をいかに効率よく行うかが問題になってきます。n人の開発者がいれば開発スピードはn倍にはならず、n倍よりも落ちます。人数が多ければ多いほど、共同開発は難しくなり、ひどい場合には人数が増えたから開発スピードが落ちたということになりかねません。 ウノウでは共同開発を効率よく行うために様々な工夫を用いています。今回はウノウでどのようなステップで開発を行っているか紹介したいと思います。 subversion でソースコードを管理 ソースコード管理ソフトがなくては話になりません。ウノウではソースコードの管理に subversion を使ってます。subversion を使うことで過去の状態に簡単に戻すことができますし、個人の環境を完全に分離することができます。 subversion のコミット
「IT投資」という考え方そのものが間違っている - 分裂勘違い君劇場 by ふろむだ
JTBの元取締役CIO(最高情報責任者)の方が、ITシステム開発が設備への投資であるかのような前提で書いていますが、この前提は間違っていると思います。 ソフトウェアシステムの開発とは、経営行為そのものそのものであり、逆に言えば、江戸時代どころか、ローマの時代から、経営行為とは、ソフトウェアシステムの開発以外のなにものでもありませんでした。 たとえば、新しいビジネスを実現するための、新しい店舗オペレーションや配送システムの開発は、ソフトウェアシステムの開発そのものです。 あたらしいビジネスを立ち上げるために、設計すべきものは、たとえば: ●迅速で高品質な状況対応を可能とする意思決定メカニズムの設計。 ●現場で柔軟な対応が出来、かつ、従業員の士気があがるような、責任・権限メカニズムと、それと連動した人事評価・報酬システムの設計。 ●現実的に調達可能な人材と、十分な投資効果の見込める従業員教育シ
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「仕様」という言葉の罠を回避する
結論→ 「仕様」と「機能」を意識的に使い分けることで、顧客のテクニック「言葉のすり替え」を見抜くことができる。 客先での仕様調整の場で、新人が手もなくひねられている（騙されているともいう）。もう少し手加減してやればいいのに、顧客の脅しが酷すぎる。 あたりまえじゃないか、その機能が入っているのが仕様です なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです だから、その機能が入っていないのはバグなんです したがって、あなたは無償で今すぐこれを実装する必要があります テストフェーズ末期やリリース後、何らかの要求を満足していない場合、顧客より一方的に伝えられる最終通牒は、こんな論法だ。非常に強い口調で伝えられると、なんとなく「そうかも?」という気分になり、顧客が正しいという空気が場を支配する。 その結果、ほとんどの場合、泣く泣く自腹で実装していることだろう。ひとつひとつは小
意図が伝わる設計書作成の心得【第1回】：行きすぎた技術志向
設計書の書き方には絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなる。標準の設計フォームや設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。 一般によく言われることだが，設計書の書き方には「正解」や「こうしなければならない」という絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなり，完成した設計書の内容と質は設計者ごとに大きく異なる――といった結果に陥りやすい。 もちろん，標準の設計フォーム（ひな型）や設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。一
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 職業プログラマー入門: システム開発者を目指すあなたへ 設計からC言語コーディング、テストまで: 遠矢行史 (著), レッドフォックス (編集): 本
javaworld.jp
サービス終了のお知らせ
システム・エンジニアの基礎知識
究極のお仕事 : 404 Blog Not Found
