熱血！第三営業部
先日、オフショア開発の根底を考え直させる話がありました。話の相手は当ブログ既出の僕の友人、不動産関係者Ｓ氏。彼と建設業界とＩＴ業界のプロマネの話をしていたときです。ま、これは結構ぼくらの間ではロングランで語られているテーマなんですが、そこから派生した話題です。 「日本は人件費が高い」「だから人件費の安い国へ開発を発注するのだ」という仮説があります。これがそもそもオフショア開発という考え方の大元の発想ですよね。ところが彼の話を聞いて驚いた、っていうか気づけよ俺。そしてあなたも。 「そこがわかんないんだよなあ」 「だから、例えば日本のゼネコンが中国でプラント作るとすると・・・」 「ちょっとまて」 「なんだ？」 「日本の企業が中国でプラントつくるのか？」 「おう。おまえ聞いたこと無いか？」 「いや、あるある」 「で、話をすすめるけど」 「ちょっとまて」 「それはどうやって受注す
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
２１世紀の品質保証体制の構想
日本のソフトウェア開発は正念場に立たされています。一向に減らない仕様の変更や、リリースの度に発生するトラブルによって企業も大きなダメージを受けています。そこには、かつて80年代に築いた「品質大国」の面影はどこにもありません。わずか１５年で失ってしまった。 評論家諸氏に言わせれば、日本の品質は“まだまだ先進国の中では高い”という。だが、EUやNAFTA（アメリカ、カナダ、メキシコによる北米自由貿易協定）のような大きな市場を持たない日本の場合、ちょっとくらい品質が高い程度では競争力としては乏しい。第一、その程度ではすぐに追いつかれてしまいます。 それに、“まだまだ”という表現に、かつての様な特筆した状況にはないことを暗示しています。実際、日本のソフトウェアの開発現場は決して将来に希望を持てる状態ではありません。私の様なコンサルタントが忙しい状態というのは、決して望ましいことではないのです。でも
プロジェクトマネジメントとプロジェクトコントロール (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ ちょっと前の記事ですがnikkeibp.jpの"マネジメントとコントロールは違う"が面白かったです。 プロジェクトコントロールとは失敗しないようにすること 企業のリスクマネジメントの話なのですが、次の マネジメントの意味は、do right things、正しいことをする、である。これに対し、コントロールは、do things right、事を正しくする、である。 話を思い切り単純にして進めれば、マネジメントは企業が成長していくための活動であり、コントロールは企業が失敗しないための活動である。アイデアをうまく育て、売れる商品を作り出した企業は、マネジメントされていたことになる。逆に、製造現場をうまくコントロールし、高品質の商品を作ったとしても、それが顧客に受け入れら
ドキュメントレビューに役立つ40のチェックポイント ― 1/3 ― ＠IT情報マネジメント
プロジェクトを進めるうえで、トラブル発生による手戻りを未然に防止するほかに、進ちょくを測ったり、リスクを予測したりするためには、ドキュメントレビューが効果的である。ここでは、主要なドキュメントに対するチェックポイントを紹介する。 仕様書のチェックリスト 以下に仕様書の基本的なチェックポイントを紹介する（なお、第4回の「急がば回れ──質の良い仕様書の作り方」も併せて参考にしていただきたい）。 ソフトウェア開発というのは、意図するところを人間の言葉からいくつかの成果物（ドキュメント）を経て、コンピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水を途中でつぎ足すことは、なかなか難しいもの。早い段階──仕様書には“漏れ”がないようにしたい。 （1）題名は、システム名を明記しているか 仕様書の題名に「?システム仕様書」のように、システム名が明記されているか。“名は体を表す”
ビジネスモデリングと“見える化”のいま
＠IT「ITアーキテクト」フォーラム主催の「ITアーキテクト塾」。第1回は、いま注目される「ビジネスプロセス・モデリング」について、特にBPMN（Business Process Modeling Notation）の観点から3人のトップITアーキテクトがその有効性を論議した。 この1年で注目を集めた「ビジネスモデリング」 もともとモデリングとは、システム開発の対象となる業務の構造やシステムの構造、そして業務とITのかかわりなどを記述することだ。その表記法はさまざまで、例えば業務プロセスの中でどのようなデータが必要になるかを記述するDFD（Data Flow Diagram）や、データ構造を表すE-R（Entity-Relation）図、そして業務プロセスとエンドユーザー、システムの関係を記述するUMLなどが挙げられる。こうした意味では、古くからあるシステム開発の技法の1つであり、新分野と
ひげぽん OSとか作っちゃうかMona- - プログラマは必読かも 「Joel on Software」
Joel on Softwareposted with amazlet on 06.04.15Joel Spolsky 青木 靖 オーム社 (2005/12) Amazon.co.jp で詳細を見る id:ryoko_komachi:20051218:1135176719でも絶賛されている。 Joel on Softwareを買って読み始めました。 この本が出ることを教えてくれたのは、たしかid:naoyaだったと思うのですが、聞いた時点で買うことを心に決めていました。 というのも「プログラマのためのユーザインタフェースデザイン」で、Joel氏の文章を読んでいて、その経験に裏打ちされた内容がとても勉強になったからです。 というか、影響受けまくりました。 書籍版のJoel on Softwareは、上記のサイトの文章をまとめたものが大部分だそうです。 Joel氏はMicrosoftで働いてい
要件を要件として深追いしてはいけない - 設計者の発言
ユーザ要件は海に浮かぶ氷山のようなものだ。言語化可能な部分は海上に出たごく一部で、大部分は水没していて言語化どころか意識にのぼることさえない。このような要素をシステム設計においてどのように扱うかによって、上流工程のスタイルはまったく違ってくる。 ◆スクラッチ案件での要件の位置づけ 前回のエントリーで説明した「スクラッチ案件」において、要件はとくに重要視される。新システムを構想するためのレファレンスとなる現行システムが存在しないか、あっても貧弱すぎてアテにならないからだ。 そのような案件向けであっても、要件の扱い方は２つの流儀に分かれる。ひとつは要件全体を正面から定式化するやり方。もうひとつは言語化が困難であるような要件については深追いせずに搦め手（からめて）を用いるやり方。便宜上、前者を「Ａ方式」、後者を「Ｂ方式」と呼んで検討しよう。 ◆要件をじっくりモデル化するＡ方式 上流工程手法の多く
＠IT：ソフトウェア開発をちゃんと考える（2） 開発者の集合はどのように形作られているか
ソフトウェア開発の効率性を考えていると、いつかは必ず人の問題に突き当たる。プロジェクトチームという開発者の集合はどのように形作られ、どのように動いていくものなのだろうか。そこには必ず何らかの機構（メカニズム）があるはずだ。（＠IT編集部） アーキテクチャといえば、普通はプロダクトの、あるいはソフトウェアのアーキテクチャを思い浮かべるわけだけれど、システムやソフトウェアを作っていく過程ではプロジェクトのアーキテクチャ、つまり開発に主体的にかかわっている人たちの集合がどのように形作られるかも、とても重要な要素になる。 なんでこんなことをいい始めたかというと、たまたま「フューチャー・オブ・ワーク」を読んだからなのだ。なんで、こんな本を読んだかというと、 著者のマローンは米マサチューセッツ工科大学で「The MIT Process Handbook Project」［注］というプロジェクトをやって
道具箱の整理
はじめに この記事は、mymy-mycompany分室の2005年10月に1ヶ月をかけて書いたものです。ブログだと後から参照するのが大変なので、ここにまとめておきます。また、ブログでは時間の都合で書けなかった話も追加していく予定です。 私の道具箱 ここ１ヶ月ほど、私的Ｗｅｂサイトプロジェクトなるものに参加しています。オープンソース方式ではなくて伽藍方式。以前、オープンソースのカンファレンスに出たときに、そこで発表していた学生が、ちらと「実はオープンソースよりも伽藍のほうがクオリティが高いものができると思っているんだよね～」と話していたのが、非常～に気になってはいるのですが、そのあたりは、各自のモチベーションと時間の取り方の違いでしょうね。オープンソースでもコミットする人数（アクティブな人）が限られていれば伽藍に近くなるし、伽藍にしてもうまくいかないプロジェクトごまんとあるわけなので。 で、
自己組織化プロジェクトの育て方（1） ― ＠IT
混乱するプロジェクトを1から10までガチガチに管理するのではなく、うまくいくようにそっと手を貸してやること。そんな発想の転換が実はいまどきのプロジェクトを上手に運営するコツなのかもしれない。本連載では「自己組織化」という概念をプロジェクト運営に応用するノウハウをお伝えする。（＠IT編集部） 1. プロローグ～大火事プロジェクトの火消し役が計画した、あるひそかな実験 昨年、火が付いたプロジェクトに火消しマネージャとして参画することになりました。チームメンバーは連日の徹夜で疲弊し切っていました。マネージャ陣との信頼関係すら怪しい状況でした。クライアントからは怒声が飛び、連日のように詳細な進ちょく状況報告を求められます。報告作業自体が開発スケジュールを圧迫していました。データベースのテーブル定義でもめている段階なのにもかかわらず、カットオーバー予定日は目前に迫っていました。タフな判断と徹夜の作業
開発ドキュメントの最適化(2)
Part1●効率化を図る リスクを考えながら無駄をなくす ドキュメントを大幅に削減したいのであれば，開発プロセスを見直すのが最も効果がある。ユーザーや開発者同士の意思疎通が図られ，お互いの合意がとれているのであれば，ドキュメントは省略可能だ。この特徴を最大限に生かしたのが，XP（Extreme Programming）による開発である。 ただ，XPを含め，お互いの合意がとれている状態にするのはかなり難しい。規模が大きくなればそもそも困難になるほか，ユーザーの立場からするとリスク回避のためにどうしてもドキュメントが不可欠になる。開発プロセスの見直しが難しい場合は，合意がとれているものは省略する，できるだけ再利用する，などして地道にドキュメントを削減していくしかない。 開発プロセスを見直す 一般に，システム構築では要求→分析→設計→実装→テストといった手順を踏んでいくが，このようなプロセスでは
B3 Annex: グーグル、１０の黄金律
Newsweek最新号 (Issues 2006）に、Eric Schmidt（グーグルCEO）とHal Varian（バークレー校教授兼グーグル社コンサルタント）による「グーグル、１０の黄金律」（"Google:Ten Golden Rule"）が掲載されている。 必ずしも目新しくはないが、一応、日本語版をB3 Annex抄訳で。 ・採用は委員会方式で グーグルで採用面接を受ける人はすべて、少なくとも６人以上の管理者あるいは将来の同僚との面接を行う。すべての人々の意見が大切であり、このことで、採用のプロセスがより公平になり、採用基準の向上にもつながる。もちろん、それだけ時間がかかることになるが、その価値はあると思っている。すばらしい人材を雇い、その人を次なる採用のプロセスに集中的に組み込むと、さらにすばらしい人材を雇うことにつながる。 ・必要なものはすべてを供給せよ 私たちは、標準的な（
わたしが知らないスゴ本は、きっとあなたが読んでいる いきなりコンサルタントに抜擢されたSEが読むべき3冊
この記事のまとめ。また長文エントリごめん。“IT”コンサルじゃない、「ファーム」のコンサルタントと一緒に仕事をするハメになったら読む本。 「問題解決プロフェッショナル」を読めば、コンサルタントの土俵で話ができる SEとしての分をわきまえるなら「RFP＆提案書作成マニュアル」で準備しておく SEには、コンサルタントに無い視座がある。その強みを生かす「業務システムのための上流工程入門」 コンサルタントは、知識経験ないけれどキャラとハートがおおまかカバーすることはぶっちゃけありえない。そうなったらどうしようと思い悩む前にメモをどうぞ。 このblogは「それを知らなかった私にとって有益なもの」になるように心がけてる。つまり、その記事の知識・情報を知らなかったとして、「あ、こんな記事を見つけてラッキー」と思えるようなネタ。 で、この記事は一年前の私が見つけたなら「お、タイムリー」と思えるような内容
悪魔に心を売っても納期を守る！帳尻あわせの裏技術｜【Tech総研】
きっかけは私、つまりＴｅｃｈ総研スタッフのマイウェイマサシが知り合いのエンジニアから聞いた、何げないひと言でした。「納期？ いざとなったら要件を変えちゃっても、何とかするよ」。それがきっかけで300人のエンジニアに、「納期に間に合わないとわかったときに使う裏技術」を尋ねたわけです。 アンケート調査では納期に間に合わせるためのワザ以外にも、前提となる納期の厳しさや、現状への考え方なども聞いています。それが上の2つのグラフ。 「仕事が始まったときから納期達成が絶望的」（左）ってかなりむちゃな仕事ですが、仕事の半分がそうだというエンジニアが4割もいる。普通の仕事だってスケジュールは徐々にズレていき、結局は納期と戦う羽目になるでしょ。それなのに、例えば「最初から納期は絶望的」な仕事が8割という人が、10人に1人いるわけです。 そう考えると、「何が何でも納期は守る」というエンジニア魂が光りますね（右
コミュニケーションはリーダーシップの基礎 ‐ ＠IT自分戦略研究所
将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 ■リーダーシップの基礎はコミュニケーション 前回の「中心は『ココロ』、リーダーシップトライアングル」で、私が考えるリーダーシップのフレームワーク、リーダーシップトライアングルの概要を説明しました。 前回も各構成要素について簡単に触れましたが、今回は予定どおり、リーダーシップトライアングルの構成要素のうち、全体の基礎となる「Communication」（コミュニケーション）を解説します。 コミュニケーションはリーダー
ビジネスリサーチの心得
2．ビジネスリサーチの情報収集 デスクトップ調査 の基本〜アニュアルレポートなど公開情報から… デスクトップ調査 とは、主にインターネットなどを使用して、公開情報を調査して整理・分析を行うものです。「CIAも収集する情報の95％が公開情報」ということで、情報不足とい… 2021.01.28 2021.05.13 1915 view コラム〜リサーチャーの日常 人生を通じてマッチクオリティーを追求する 知識の幅が最強の武器になる という本で初めて知った「 マッチクオリティー 」という言葉は、経済学の用語で、ある仕事をする人とその仕事がどれくらい合っているか、その人の能力… 2021.05.04 2021.05.13 295 view 2．ビジネスリサーチの情報収集 日常的な情報収集・整理術（Feedly＋Dropbox） 【 ビジネス 情報収集 と 情報整理 の基本 】いま目の前にあるリサー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
無料で予定表の共有ができるスケジュール管理ソフト「アリエル・マルチスケジューラ」- Ariel Networks
http://sample-code.net/modules/xfsection/article.php?articleid=4