わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ
プログラミングとは経営判断の集積である - 分裂勘違い君劇場 by ふろむだ
ソースコードの一行一行は、経営判断そのものだ。 どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるかは、そのソフトウェアステムを使って今後どのようなビジネス展開をするか、ということと一体不可分だ。プログラマーは、絶え間なく改変されていく部分と、財産として今後も使われつづけそうな部分を意識しながらコーディングする。そして、ここでいう財産とは、プログラマが財産とみなすものであるだけでなく、同時に経営的・財務的な意味においても財産であり、会社のバランスシートの「資産」の項目に登場するような性質のものだということは、多くのエンジニアが漠然としかいしきしていないように見える。 「このルーチンは、時間がかかっても、汎用的なライブラリやフレームワークにしておこう」、とエンジニアが「なんとなく」決めたとき、実は、そのエンジニアは
チームリーダー日記 : [メモ]日本人エンジニア派遣業
システム開発の日本人エンジニア派遣業は エンジニアのレベルに関係なく もうそろそろなくなるんじゃないかと感じる。 ＃何を今更、といわれそうなんだけど、 ＃両面とも臨界点に達した感じがする。 ---- これは悲しむべきことじゃなくて、 チャンスだと思ってます。 ---- 自分がどっちに転がるかは、自分の行動次第。 自分の周りがどっちに転がるかも、自分の行動次第。 ---- 今は、Web2.0とは何か？ なんてことを後付けで考えるよりも、 同時代、同年代のエンジニアとして こっちから切り込んだほうが感覚的にわかることが多い気がする。 就業形態とかそういう点。いやもっと前段の話か。 両者はたぶん、どっかで繋がる。 ---- なんというか、 ベテランの方はどちらも肌で感じ取ることができないらしい。 ---- 「目線は自分の進みたい方向に向ける。」 とオートバイの教習所と、スキー学校の両方で習ったな
CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyance：SaaS時代のベンチャー経営に求められる情報システムとは
現在発売中の月刊ComputerWorld10月号のSaaS特集に、著者の一人として寄稿しました。 「『サーバのないオフィス』でイノベーションを実感する」と題して全8ページ、渾身の記事です。 SaaSという言葉は、これまた例によって定義の広すぎるコトバですが、いわんとすることはソフトウェアを買ってきてインストールして使うというモデルからウェブ上にあるサービスをそのままブラウザ上でソフトウェア的に使うようになりますよー、という意味ですから、これまでの外しまくりな業界のバズワードに比べればリアルなトレンドをはるかにうまく捉えています。イメージ的にはWeb 2.0とも若干かぶるのですが、SaaSはどちらかというと「従来のガチなソフト屋から見たウェブへの進化願望」みたいな気分が表れたコトバだと理解しておけば間違いありません。（現にピュアでネイティブなウェブ界隈でSaaSというコトバが会話に出てくる
在庫引当から在庫推移へ（前編） - 設計者の発言
在庫管理分野でのデータ項目として「有効在庫（利用可能在庫）」と呼ばれるものがある。現在庫数量から「直近の出荷予定数量」を差し引いて得られる値を、事実上利用可能な在庫数量とみなして管理する。現在庫には直近の出荷予定が「引当」されていると考えるわけだ。式で表せば次のようになる。 有効在庫数量＝現在庫数量－Σ(直近の出庫予定数量) 現在庫が１００個だとして、直近での出荷予定が合計７０個だとすれば、有効在庫は３０個である。この時点で５０個の注文があったとする。有効在庫が３０個であることを知っていれば、すぐに出荷できる分３０個と、将来の入荷後に出荷できる分２０個とを分けて受注するといった事前の交渉が可能だ。いっぽう有効在庫を認識していないとすれば、すぐに出荷できる受注として５０個分をひとまとまりとして受け付けてしまうだろう。結果的に、出荷時点で欠品に気づいてあわてるハメになる。 在庫数量が規定レベル
勉強が出来ない奴はプログラマになれ！（バカだからできる勉強法） - IT戦記
どのくらいの人がこのブログを読んでいるか分かりませんが、 もし、勉強が出来ない人が周りにいたら、このブログを紹介してあげてください。 ふと 勉強が出来ない人は、プログラマになったほうがいいと思った。 僕はというと 自分でも驚くくらい勉強というものが出来ない。ものごとを知らない。 はっきり言ってバカなのである。 たとえば、 大学行ってない。 株式公開と上場の違いを知らなくて、一同ぽかーん。 つい最近まで、サイバーエージェントを知らなかった。（技術者には必要ない） 英語が一切読めない。 宮崎料理「冷や汁」を「冷や飯」だと思ってた。 基本的に会議とかでよく出る英語、「さじぇっしょん」とか、「あさいん」とか、「ぶらんでぃんぐ」とか、「うぇぶつーぽいんとおー」とか、よく分からん。 人力（じんりき）検索を入力（にゅうりょく）検索だと思っていた たぶん、まだまだあるけど、自分がバカだから気がつかないんだ
上流設計 - essence-s
会場が会社の近くだったのもあって、行ってきました「上流設計セミナー」。 またまた、いろいろ刺激になった。 どろくさいケーススタディがおもしろいですねー。 とりあえずキーワード。注釈はあとで。 経営戦略と施策からITへの要求定義への関連づけを見える化 要求が迷子のスキーヤーになる現象に注意 ITが目的のターミナル駅になる現象に注意 カスタムメイドではなくレディーメイドの準備 仕様変更は変更でないかもしれない→はっきりしただけで変更ではない。 そもそも、きっちり決める事できるんだっけ？ Asisならできるかもでも作る意味はない。ToBeの要求をどうしたらいいのか。 結局反復をちゃんとやろうよ。 ユーザーの要求粒度がまちまちなので既存のインフォメーションモデルはなりたたない ユーザーの要求粒度によって判断してはいけない 要件確定時ぬけおちる情報に変更可能性が隠れている 量の絶対値ではなく量の変化
仙石浩明の日記 「ソフトウェア開発」は「モノ作り」ではない
いつのころからか、 ソフトウェア開発がモノ作りに喩えられるようになった。 典型的なのは、製造業(例えば自動車製造)と IT 業界とを比較して、 前者が高度にシステム化されているのに対し、 後者がまるで家内制手工業のようだ、という批判である。 日経ビジネス online の記事に次のようなくだりがあった: 「というより、何といいますか、経営トップからすると、 ITはとにかく非常識な世界だ、としか思えないのではないかなあ。 例えば大きなシステム開発プロジェクトに取り組むと、 すぐ100億円を投資する、という話になってしまう。 100億円の経常利益を出そうと思ったら本当に大変。 ところが、100億円を投じたのに、期限までに完成しない、 出来上がってきたものが当初計画と違う、 直そうとするとさらに金がかかる。 こんなことが起きるわけですから、『一体なぜなんだ』と経営トップは思うわけです」 IT業界
「復活」果たしたITサービス業界がこの5年間で失ったもの：ITpro
法人向けのITサービスを提供するソリューションプロバイダが，久しぶりの業績回復を果たしている。 2002年2月から続く日本の景気拡大局面は，4年6ヵ月目に入り，継続期間では戦後2番目の記録を更新中だ。その中で，ずっと景気回復の波に乗り損なっていたのがITサービス業界だった。 しかし，主要ソリューションプロバイダ各社の2005年度決算（2006年3月までの1年間に迎えた決算を指す）は，「4年ぶりの復活」と呼べるような好調さを取り戻した。日経ソリューションビジネス誌が，売上高100億円以上のソリューションプロバイダを対象に毎年まとめている業績調査から，この5年ほどの動向を紹介しよう。 「業界の縮退」と「利益なき繁忙」の4年間 まず，2000年に起ったITバブル崩壊を受け，ITサービス企業の業績に陰りが見えたのが2001年度のことだった。当時の調査対象企業150社で見ると，平均の売上高伸び率はプ
複雑な条件を文章で書くべからず ― ＠IT自分戦略研究所
コミュニケーションスキルの土台となる図解言語。だが筆者によると、実はその裏に隠れた読解力、国語力こそがITエンジニアにとって重要なのだという。ITエンジニアに必須の国語力とはどのようなものだろうか。それを身に付けるにはどうしたらいいのか。毎回、ITエンジニアに身近な例を挙げて解説する。 ■実務的な国語力が必要とされている 前回「メタ情報とサマリーで『伝わる』ビジネス文」に引き続き、典型的な失敗のパターンから実務的な国語力を身に付けよう。 前回の記事で「こんな説明では分からない」10種類の失敗パターンを列挙した。以下のようなものである。 （1）メタ情報の欠落 （2）要点の分からない見出し （3）複雑な条件の文章表現 （4）分類を表さない名前 （5）過剰な言い換え （6）対称性のない表現 （7）指示代名詞の多用 （8）相互関連の分からない個条書き （9）時系列の乱れ （10）語感と実感のミスマ
Webデザイン エンジニアリング 第16回 ボタンを押させるテクニック：ITpro
対象とするユーザーの“慣れや知識”によって，画面の構成を変えたほうが伝わりやすいとするならば，画面上の「ユーザー・インタフェース（UI）部品」の色や形状も，ユーザーに応じて変えるべきでしょう。今回は，代表的なUI部品でありながら，なかなか作り手の思うように押してくれない「ボタン」について考えます。 わかりやすいボタンの形状はユーザーによって違う まず，前回とほぼ同じ絵を用います。Webシステムの操作方法への「熟知度（PCリテラシ）」を縦軸，「提供したいサービスに対する知識」を横軸とします。そして，それぞれの「軸」に対して，受け入れやすいと思われる「ボタン」の形状を例記しました。 上図の【A】や【B】のタイプに当てはまるPCリテラシの高いユーザーは，ボタンの“ラベル”に「submit」と書かれていようが「GO」と書かれていようが，ボタンを認識することはさほど苦ではありません。 しかし，PCに
40歳前後の技術者が不足！ そこからITサービス業界の事情を読む
最近、ある証券アナリストの人から、「ITサービス会社の年齢別の人員構成に着目すると、いろんなことが見えてくる」という話を聞いた。特に興味深かったのは、38～42歳の人員に凹みがあるITサービス会社が多く、プロジェクト・マネジャー不足の懸念があるというくだり。では、何故その世代の人員が少ないのか。その話を聞いて、私はピンと来るものがあった。 この世代の技術者が少ない理由を、彼らの新卒採用時にまで遡る必要はあるまい。15年前の1991年が「ダウンサイジング元年」で、オープン系への流れが加速するのはそれ以降の話なので、彼らの採用されたのは、まだ平和な“メインフレームの時代”だ。それよりも直近、ユーザー企業がIT投資額を抑制し、「ITデフレだ、オフショアだ」と騒いでいたころの出来事の影響の方が大きいだろう。 その頃、彼らの年齢はちょうど30歳台後半に収まる。そこで思い出されるのは、ITサービス業界
オフシェア開発の先としての自動生成を考える必要性が早まった？最近の国際情勢で！！ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 日経コンピューター２００６年７月１０日号Ｐ１８に オフシェア開発、大型案件に浸透 ”今欲しい”技術者確保に向け、発注量は前年度比２割増へ っていう記事があります。 オフシェア開発に大手さんは、大々的には向かっているようですけど、 でも、ここで、オフシェアの比重を増やしてコストダウンなんてことで、 安穏としていたら、次のコーナー回ったところで、時代遅れ、業績急低下！ になっちゃいそーですよねー（＾＾） なぜか、理由は２つ！ １つは、オフシェアの単価を、 国内の（北海道など）地方で経済がぼろぼろに崩壊してしまった地域の人件費と 比べると、そんなに差がなくなりつつある、 いや、将来的には逆転すらありえそうなこと。 上記の記事中にも、オフシェア開発の人件費が「単価４０万前後と」とあります
一気に分かる“XQuery”ハンズオン演習 1/3 − ＠IT
今年（2006年）はXMLデータベース元年といわれています。すでに製品を出していた企業を含む多くのベンダが、XMLを保存するのに適したデータベース管理システム（DBMS）を発表しています。そして何よりXML専用のクエリ（問い合わせ）言語であるXQueryが昨年11月にW3C（World Wide Web Consortium）のCR（Candidate Recommendation：勧告候補）にまでこぎつけました。 本記事では、XQueryをクエリ言語の標準であるSQLと比較しながら、どのような言語なのか概説します。 ■XMLはどのように保存されるべきか XML 1.0勧告が発表されてはや8年が過ぎ去ろうとしています。筆者自身が関与した開発プロジェクトでXMLを初めて使ったのは1999年ですが、それからすでに7年が経過しました。 これまでXMLを企業システムで利用してきた際にいつもつきまと
「ブレイク直前のLinux」を思い起こさせるRubyのマグマ
Ruby on Railsを利用したドリコムのDrecom Career Search。同社はB2CサービスでRailsを標準に採用している [画像のクリックで拡大表示] その熱気に包まれながら，なんだかこれとよく似た雰囲気を感じたことがあるような気がした。なんだったろう。そうだ。Linuxがブレイクする直前のあの熱気だ---6月に行われた日本Rubyカンファレンス（関連記事）で記者が受けた印象だ。 記者が最初にビジネス用途のソフトウエアとしてLinuxを意識したのは米Netscape CommuncationsがLinuxをサポートする方針を明らかにした時だったと記憶している。正直言って最初は「個人の名前を冠したソフトウエアなんて，どうせホビー用だろう」と思っていた。しかし，それではと調べれば調べるほど，Linux上のソフトウエアや，採用事例はまさに山のように出てくる。 売るわけでもない
再利用可能なコードを書くための10のコツ - memo.xight.org
Summary 1. DRY (Don't Repeat Yourself.) 2. class/method は1機能のみ． 3. ユニットテストコードを書き，テストを楽にする． 4. ビジネスロジック，メインコードはフレームワークに依存しないように書く． 5. より抽象的に考え，インタフェースとアブストラクトクラスを使用する． 6. 拡張することを意識したコードを書け． 7. 必要でないコードを書くな． 8. 結合度を弱めるようにしろ． 9. モジュール化． 10. 自分のコードが常に外部APIであるようなコードを書け． Reference A Funny Java Flavoured Look at the World: 10 tips on writing reusable code http://hoskinator.blogspot.com/2006/06/10-tips-on
よいSEにはよい報酬を，“人月いくら”はもうやめよう
少し前のIT Proニュースで，日本IBM・大歳卓麻社長の「ユーザー企業には，技術者の出席をとらないでいただきたい」，という発言が紹介されている（当該記事）。「技術者の頭数ではなく，成果物について対価を払っていただける商慣習に変えていくよう，広く呼びかけたい」，という主旨だ。 私自身も取材のなかで，技術者の数や開発にかかった時間でシステムの価格を決めるのはおかしい，という声を，多くのSEの方々からお聞きする。ベンダーに籍をおくSEからだけではなく，ユーザー企業の方からもである。 システム開発にかかる工数，すなわち“人月”は，価格見積もりの根拠として，現在でも広く使われている。仮に一月100万円のSEが10カ月働いたから1000万円，という見積もりがあったとしよう。では，そのSEが努力して生産性を向上させ，5カ月でシステムを開発できるようになったら，価格は500万円になってしまうのだろうか。
CNET Japan Blog - 江島健太郎 - Kenn's Clairvoyance：あらためて感じる、開発の進め方の難しさ
あらためて感じる、開発の進め方の難しさ 公開日時： 2006/04/16 14:43 著者： kenn 最近めっきり開発者モードへと還って失われた日々を取り戻しつつ目下急成長中（注：当人比）の江島でございます皆様いかがお過ごしでしょうか。 色々模索しながらやってきた新サービス開発プロジェクトですが、同僚のダニーがバックエンドのコードを書き、ぼくがUIの部分を担当するという大まかな分業に落ち着いてきています。 すでにpretrieve.comというパブリックレコード検索エンジンを開発してリリースした経験のあるダニーはともかく、ぼくは本格的なウェブのサービス開発というのは初めてなので、あちこちで頭をぶつけながら修行中です。 この手のウェブのプロジェクトは、一見簡単そうに見えて実際やってみるとスピーディにやるのは結構難しくて、とくに進め方についてはずっと暗中模索でちょっとずつ前進という
チームリーダー日記 : 開発現場の力を底上げするための活動は、誰が先頭切ってやるの？
開発現場の力を底上げしていくのは、少なくとも半年単位で継続活動していく必要があると思う。 結果が出るまで、実績は一時的に落ちたり伸び悩んだりする。 (中長期で見れば、大いに伸びる可能性があると思うけど) 結果が出るまでの投資(成果賞与の遺失分？)は誰がするのか？ 末端社員ですか？ 違うよね。 偉いさん？ 話が合う人ならいいんだけど、話が合わないひとが活動に加わると、アレなんだよね。 ■ さて、私事ですが、昨日、源泉徴収の紙を貰いました。 昇格したにもかかわらず、年収は微微増でした。 （このご時世、給料が出るだけでもいいじゃないか、という意見は置いといて） なぜかというと、残業が大幅に減少したからです。 残業を減らすことは良い事だと思って活動した結果、自分の収入は減りました。 時給は増えたじゃないか、とか言われてもね。 組織と個人の利益が一致してない、当社の仕組みです。 （短期的な視点だけど
チームリーダー日記 : 12/13(火) 明日からまた、見える化をやる。
2005年10月10日舵取りするときに欲しい情報の形式と粒度。 ↑ もっと実物を交えて丁寧に書き直さないとな･･･ 前回のプロジェクトの進捗等で大活躍した「見える化資料」をまた作りました。 （百聞は一見にしかず、なので、そのうち実物写真を載せたいなぁ。年内の宿題） 今回のプロジェクトでは模造紙を横にして、大きめの付箋をペタペタ貼ってます。 ■今回の特徴 チーム全員が私より年上である。 チームが傭兵部隊である。 導入の仕方、運用の仕方などで、また新たな知見が得られると思います。 この2点の知見は実際に活動する上で、極めて大事なことだと私は思っています。 ■キーポイント キーポイントを忘れないように→未来の自分 メンバーの手間を増やさないこと 各メンバーがチーム全体の状況を俯瞰で把握できること こまめにupdate(少なくとも朝会ごと) この3点をメンバー全員に体験として持ち帰ってもらうことが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
