オフィス移転に伴う設備手配担当となり、上司から開発チーム用の机の購入を検討するよう頼まれた。チームは 4 名の開発者からなるのだが、上司は彼らを丸いテーブルに向かい合わせて座らせるのはどうかと提案してきている。このような配置は多くの場合、共同作業がスムーズになり生産性が高まるという。しかし自分としては、一つの机を囲むよう開発者を配置した場合彼らの気が散り、エラーが増え、結果として生産性が落ちるのではないかと懸念している。/.er の皆さまのご意見をお伺いしたい。 本家では「壁を向いている方が作業しやすい」とか「背中側は壁がいい」から始まり、開発者を部屋割りする場合は1部屋あたり何人が最適か、他の開発者らと上手くコラボレーションするにはどんな配置が適しているかといった意見が寄せられている模様。 チームの生産性を高める配置、/.J 諸兄方ならどう提案する ?

システム開発において「品質の向上」という標語がしばしば掲げられますが、 「品質の属性」については無頓着なケースが多いのではないでしょうか。 ひとくちに品質といっても多様な属性があります。 顧客と品質の話で揉めたことはありませんか？ 品質には多様な属性があり、単一の軸で良しあしを決められないという側面があります。 そのため、単に「品質」と言ってしまうと認識に齟齬が生じるのです。 Karl E. Wiegers氏が著書 「ソフトウェア要求」 で挙げた、すべてのプロジェクトが検討すべき12の属性は以下のとおりです。 可用性availability 動作可能時間の指標。システム故障までの平均時間MTTF(Mean Time To Failure)を 平均修復時間MTTR(Mean Time To Repair)とMTTFの合計で割った値。稼働率とも呼ばれる。 効率性efficiency 同じ処理性

アーキテクチャ選定ではメリットとデメリットを考える ではフレームワークやアーキテクチャの選定は合目的でなくてはならない、ということを言いましたが、 「システムの贅肉」という曖昧な概念を説明できていませんでした。 なんとなくイメージはできるんだけど、論理的な定義をうまくあたえれていない…。 骨格 ＝ 要件の大きさ まず、確認しておくことは、システムの規模そのものの大きさです。 要件定義・要件開発において、スマートになるように要件を決めよう、という話題ですね。 お客さんに「ちょっとここはこうなるようにしてほしい」とか言われたときに気にするのがこの点。 今の設計に無理なく乗るなら軽く「いいですよ」と返せるところですが、その一見小さく見える事象に対応するために 骨格がいびつになるような場合は悩んでしまいますね。 さて、そんな要件開発ですが、絶対値というか、要求される事象の大きさの下限は決まっていて

アルゴリズムであるとか、アーキテクチャというのは、必ずメリットとデメリットがあります。 プログラマは前提条件に合わせてメリットが活き、デメリットは表に出ないように考えアルゴリズムの選定します。アーキテクトがフレームワークやアーキテクチャを選定する時も同等です。 「大規模プロジェクトではどうするか」を考えるより、「大規模にしないためにはどうするか」を考えようというエントリに対し、私はネズミかゾウかではなくて、肥満か筋肉質かだろうと答えたわけですが、さて、では筋肉質なシステムとはどんなシステムか？という話になります。 思うに、筋肉質なシステムというのは、選定したアーキテクチャなり、フレームワークなりのメリットが活き、デメリットが隠れるようになっている、そんなシステムのことではないでしょうか。 だから、それが例えばCOBOLで新規開発という話だったとしても、「過去資産を活用する」というメリットが

もし、あなたがこれから10年間、土砂を運搬する仕事をするとしたならば、次のどの道具に投資しますか？ 手押し車 (10,000円～) 軽トラック (500,000円～。最大積載量は350kg以下) 中型トラック (ダンプで1,500,000円～。最大積載量は6.5トン未満) 大型トラック (10tダンプで10,000,000円～。) 多くの人は4を選ぶのではないでしょうか。あるいは大型免許を保持していない人は3を検討するかもしれません。 道具というのは仕事の効率に直結します。土木建設業などでは機械による効率化が目に見えてわかるため、 機械への投資とそのリターンが想像しやすいですね。 開発マシンを変えたなら 以前のプロジェクトで契約先会社から支給されたマシンで開発していたのですが、 Tomcat(JavaEEの実行環境であるWebサーバ)の起動に300秒以上かかっていました。 プログラムを修正

という数字が出されています。 エンジニアは「会って数分話をして」「1回のミーティングで」で併せて46%となりますね。 半数近くがこの程度の少ないやりとりで能力を判断していると答えているわけです。 これでは、じっくり時間をかけて相手の腕を吟味しているとは言えません。 その短いやり取りで何をチェックしているのでしょうか。 「その２ 初対面では相手のどこをチェックしている？」 を見ると、エンジニア/非エンジニアで大きく数値が違う箇所がひとつあります。 「話の内容」でエンジニアは30%、非エンジニアは15%と答えています。 我々エンジニアが相手を見る際は、話の内容で相手の技術の程度を測ろうとしているのです。 これは、対面での会話でもBBSやメールでの遣り取りでも、blogを読む時もそう。 エンジニアなんてのは技術があってなんぼの世界ですから、自然、技術力によるヒエラルキーができてしまいます。 もち

2009-09-26 北陸Scala第1回開催 2009-04-04 第十四回java-ja勉強会 - 第1回チキチキ 地方巡業withひがやすを飲み会in富山開催 2009-03-20 わんくま大阪勉強会#28 「ジェネリクスを使おう！」 2008-11-08 わんくま富山勉強会#1 開催 2008-08-09 わんくま東京勉強会#23 「C#登場前夜」 2008-04-01 *で始まるタイトルはエイプリルフールネタです 2008-01-26 わんくま東京勉強会#16 「ライブプログラミング」 2007-12-08 わんくま名古屋勉強会#1 「わんくま初めてのJava」 2007-07-28 開店 みねこあさんのところで挙がっていた、 静的オブジェクト指向と動的オブジェクト指向の軽さについての話題から。 Javaは経済的事情をうまく捉えて普及した プログラミングの効率と経済で書いていると

日本Javaユーザグループ主催で、クロスコミュニティカンファレンス(CCC)が、4/30日に行なわれました。 この稿ではそのうち「ITゼネコンをぶっつぶせ」というBOFについてレポートおよび考察となります。 講演者はSeasarの開発者として著名なひがやすを氏。会場は立ち見が出るほどの盛況ぶりでした(100人以上はいたと思われる)。 ITゼネコンをぶっつぶせ - ひがやすをblog ITゼネコンを倒す方法をみんなで考えよう - ひがやすをblog プログラミングファースト開発 - ひがやすをblog セッション資料はそのうち公開されるのではないかと思います。 本セッションはITゼネコンの問題点をまず挙げ、ひがやすを氏の考える打開案であるところの 「プログラミングファースト開発」についてのプレゼンといった流れ。 残念なのはひがやすを氏が契約の部分に対して解をもっていなかったという点ですね。

エンジニアの正義とは第一に正しさに誠実であることです。 第二により高みに上り詰めることです。 丁寧に解説されていようとも技術的に誤った文章は、躍起になって否定されるものです。 たとえ口が悪く礼儀知らずだとしても、技術的に正しく、そしてそこに容易には得難い水準の知見が詰まっているならば、 その文章は賞賛されえますし、肯定的な意味で引用され語り継がれるものです。 その知見が正しいかどうか。それがエンジニアにとって最重要な事項です。 誤った知見に基づいていては何も作り上げることは出来ないのですから。 エンジニアは正しさに対して誠実でなければなりません。 誤った情報を発しないように。発してしまったら訂正するように。 失敗することは悪ではありません。 エンジニアリングというのは多数の失敗を越えて行くことです。 失敗からいかにうまく知見を得るか。 取り返しのつかない失敗をしないようにコントロールしなが

「ひがやすを BOF ITゼネコンをぶっつぶせ」 に期待にて 技術力のあるところがプロジェクトを統括すれば、安く、早く、良いものを作ることができる。これは、技術を売り物に独立起業している人間であれば多くが「うちにやらせてくれるなら出来る」と言うことでしょう。この点はさしたる問題ではない。 などと言ったわけなのですが…。この点、IT業界特有のものでしょう。 IT業界には設備がいらない IT業界特有、というのはシステム開発において「設備」というものが重視されない点です。 自動車整備工の人が、自宅の方が設備がよいので自宅で作業したいと言うでしょうか？ 医師の人が、自宅の方が設備が良いので自宅で手術した方がいいのにと言うでしょうか？ しかしプログラマは「家のマシンの方が性能いいし、モニタもでかいし、本もあるし、 ネットも速いし、家でプログラム書く方がいいよね」と言う人が多い。 マシンが必要といって

「誰が書いても同じコード」は大事なことなのかで 語られている話は非常に興味深ものです。 SIerの言うところの「仕様書」というものはなんなのでしょうか。私のblogでも 内部仕様書はロジックを書くものではない で仕様書を話題に挙げたわけですが、仕様書の在り方を、システム開発の分業の在り方を今一度考えてみたいと思います。 「誰が書いても同じコード」になるためには コードとは何でしょうか。プログラミング言語で書かれたアルゴリズムの表記のことです。 プログラムするということはどういうことでしょうか。 ある目的を適える為のアルゴリズムを考え、プログラミング言語でそれを表現する過程を言いいます。 「誰が書いても同じコードになる」ということは、誰もが同じアルゴリズムを採用し、 そして、その表記さえも同じ書式になることです。 書式のブレは瑣末なことです（コード規約の自動チェックツールなどを導入すれば容易

「Step数を報告して」と言われると「Step数(笑)ですか」と言いたくなる今日この頃、 みなさん、いかがお過ごしでしょうか。 ところで、Step数って何が悪いのかを説明できますか？ その数字の示すところを知った上で正しく使うには問題ないのですが…。 Step数は規模に対して正の相関関係を持つ まず、Step数と規模にはなんらの関係もないわけではありません。 Step数は確かに規模と正の相関性を持っています。 ただし、誤差があまりに酷いというだけのことです。 Step数という指標の誤差には以下のような原因が考えられます。 コードのフォーマットによる誤差 マルチステートメントなどの記法による誤差 ロジックによる誤差 冗長性による誤差 他にもあると思いますが、挙げ始めるときりがありませんね…。 コードのフォーマットによる誤差 コードのフォーマットによる誤差は for (int i=0; i<1

シャノンさんのアイデアは 面白い試みだと思いました。一部で勘違いされる方もいたようなので要旨をまとめておきます。 その用語、実態はどうなの？ PG/SE論争というのがあります。PG(プログラマ)とSE(システムエンジニア)の仕事についての話題なのですが…。 @ITなどの掲示板では定期的に出てくる話題のように思いますね。 私も過去にエントリを書いています。 この論争の場合、ざっくりとまとめると 大手企業は利益率の良い「上流工程」を行いたがる 「上流工程」の上流というのは貴賓のことではなく、開発工程上のもので特に意味はない 上流工程を主に請け負いたいがために、社員教育の過程として下流工程→上流工程という過程を経る 出世の過程としても下流工程を行う役職(PG)→上流工程を行う役職(SE)という流れ 何を勘違いしたか下流工程を行うのは下賤な仕事という認識を持つ人が出てくる 根本的な価値観の違いが論

ここ３年ぐらい同一案件のアジャイル的な開発をやっているのですが、 見積もりについて経験則がまとまってきたので整理してみたいと思います。 まず、前提として以下のような作業を請け負っています。 顧客の要望を聞いて要件開発を行う 要件を元にシステムの設計を行う 設計を元にプログラムの製造を行う テストを行う 運用時に発生した障害の調査 開発は１期のスパンが２か月～３か月程度で、 開発した機能のリリースを行いながら順次機能拡張していくといった感じになります。 作業の見積もりはその作業の種別により分類されます。 建築での比喩で表現すれば、大きく分けると設計図面を引く前と引いた後です。 これに加え、突発的な飛び込み作業があるので、以下の３つに分類しています。 設計図面を引くまでの作業 引いた図面をもとに開発する作業 突発的に発生する作業 そして、それぞれの作業ごとに不確定要素（リスク）が存在します。

掲示板は何のためのシステムかでは 技術系のいわゆる電子掲示板と呼ばれるものは、実際には単なる「掲示版」ではなく、 知識の集積の機能と、議論のための機能が求められているのではないか、ということを述べました。 この稿ではそのための機能性についての案を考えたいと思います。 知識の集積に必要な機能性 カテゴライズ 投稿された質問などはネタ振りで、それを取り上げ知識の形にまとめて集積を行うというスタンスのシステムを考えましょう。 まずはネタ投稿。これは一般のスレッド式掲示板などとそれほど変わらないと思います。 ただし、ジャンルのカテゴライズは投稿者によってある程度事前の選定は可能ですが、 後にジャンル変更できるようにすべきと考えます。また、複数のジャンルに及ぶものもありますから、 複数のカテゴリをタグ付けするような方法論が適しているのではないかと思います。 とくに質問を投稿する方には初心者も多く、カ

Webデザイナーの話がはてなで取り上げられていたので、Webシステムの裏方を引き受ける業界からの忠告。 漫画に出す車の絵のデザインを考えるのと工業製品としての車のデザインはまるで違う。 違いは何かといえば、それは工業製品たらしめる 機能性をそのデザインにどう盛り込むかという視点の有無ですね。 工業製品であるからには当然ながら機能しなくてはならない。車なら走らなければならない。その上、いざ事故となったときの安全性や、居住空間の快適さ、荷物を載せる場合の利便性など、いろんなシチュエーションを想定して、工夫を盛り込まなくてはならない。 一方、それが漫画やアニメ、ゲームなどに登場する架空の車であれば、そんなことは一切お構いなし。どこにそんな機能の格納スペースがあるのかという突っ込みをするほうが無粋というモノ。 Webデザイナーに求められるのは飾りとしてのHTMLではない 静的なWebページならいざ

年末進行でいつもより投稿が落ちているProgramming SHOT BARへようこそ。 年末にすいているBARってのは危機的ですね:-( さて、プログラミングの教育の話題。 プログラムを学ぶには 本などから学ぶ知識 知識の使いどころを判断する能力 が車輪の両輪であり、片方だけでは成り立たないと考えています。 知識に関しては昨今Webでのずいぶん手に入るようになりましたし、 さらに書籍であればうまく取りまとめてあり、得ることはそれほど難しくはありません。 ただ、知識として「そういうプログラミングパラダイムがある」「そういうAPIがある」というだけでは プログラムはできないのですよね。 実際に自分でコードを書いて、試行錯誤をして初めて知識が知恵に昇華される。 知識の使いどころを学ぶ必要があるわけです。 そして、この知識の使いどころの部分。これを学ぶことは難しい。これを教えることも難しい。 知

C言語の学習において、ポインタはよく躓くポイントとして知られています。「Javaにポインタはない」などと表現されることがありますが、実際にポインタは存在します。 NullPointerExceptionという例外が存在することからもこれは窺えるのですが、 C言語のポインタとはちょっと違っており、名前も「参照」と改められています。 C言語のポインタが果たす3つの役割 C言語ではポインタには3つの役割がありました。 変数や構造体を指し示すもの 配列を表現するもの 関数を指し示すもの これらが渾然一体となって、コンピュータの低レベルな「アドレス」という値になって扱われるのです。これがC言語でポインタを理解することを難しくしているのではないでしょうか。 Javaではどのように置き換えるのか？ Javaではこれらの３つの機能は明確に分離されています。 まず、変数や構造体を「指し示すもの」としては「参

技術系のコミュニケーションにはミニマムコードは欠かせません。 現象を100の言葉を並べて説明するよりも動作するプログラムを1回動かしてもらう方がよく理解してもらえるのです。 まさに百聞は一見に如かずといったところでしょう。 ミニマムコードに求められること ミニマムコードとはなんでしょうか？「ミニマム」＋「コード」ですから、最小限のコードといった意味合いです。 最小限だけれども、それだけで動作する完全なプログラムである必要があります。 該当部分のコードの抜粋とは違うのです。 それだけで動作するコードであること テーマを再現できること テーマ以外が極力含まれないコードであること テーマと言っているのは、その時々で話題にしている議題のことです。 ある現象について話しているならその現象を起こせるコードということです。 コードは余計なものが含まれていないことが理想的です。 余計なコードがあると、本来

はてなの方に書いた奴を転載*1。 はてなの匿名ダイアリーでSIerの話題が出ていたのが元ネタ SIerをカモに金を稼ぐ方法はふたつある。 ひとつは、手配師になって頭数いくらの契約をとりつけ、無能なコーダを送りつける方法。 もうひとつは、３倍早くシステムを作れるようになって歩合給の契約を取り付ける方法だ。 前者は、労働の牛歩戦術を基本戦略とする。 仕事を積極的に進めてはならない。コーダにいかに多くの残業をさせるかがポイントだ。 残業分の請求は、通常の労働時間よりも多い金額をSIerに請求できる。 無能なコーダには成果を挙げないことを叱責し、サービス残業を強要すればよい。 そうすれば、SIerに請求した残業代はそっくりそのまま手配師の懐に入る。 SIerの機嫌をうまく取ることがポイントだ。 コーダは残業を必要とする程度には無能であるべきだが、SIerの逆鱗に触れるほど無能ではいけない。 しかし

ソフトウェアの品質と一口に言っても複数の属性が存在することは 先のエントリ でも触れましたが、この中の保守性に今回は焦点を当ててみたいと思います。 保守性が活きるかどうかは不確定 保守性というのは端的に言えば修正のしやすさを意味します。 仕様変更や追加の際の工数が小さい、その作業過程でのバグの出現数が少ない、といったところです。 さて、この保守性の高さというのは、いざ変更を行おうとする段にならないと効力を発揮しません。 例えば初期のデータ移行のためのバッチとか、そういった「使い捨て」のプログラムでは重要視されません。 つまり、将来発生するかもしれない変更に対して、工数が少なくなるように保守性を高めるということは、 アップサイドリスクである、つまり、発生するかどうかが不確かな利益であると言えましょう。 このアップサイドリスクは仕様変更があって初めて効力を発揮するものです。 そしてその価値は、

Programming SHOT BAR へようこそ。今回はリスクというものについて考えてみたいと思います。 そもそもリスクって何？ 日常でもリスクという言葉を使うと思いますが、そもそもどういう意味なのでしょうか？ 手ごろなところでWikipediaで調べると 「危険に遭う可能性や損をする可能性を意味する概念」とありますね。 基本的には 発生確率×損害の大きさ といった形で表されます。ここでは「損害」と書きましたが、金融用語では不確かさ、 つまり「発生確率」の部分を意味し損得に関わらず「リスク」といいます。 とくに不確かな利益についてはアップサイドリスク、不確かな損害についてはダウンサイドリスクといいます。 行動心理学的に人間は確率を過大評価もしくは過小評価する傾向があります。 端的には信じたいものを信じるわけですが、アップサイドリスクは過大に、ダウンサイドリスクは過小にという傾向が強い。

Programming SHOT BARへようこそ。今回は数字の話です。 学術でも仕事でもそうですが、世の中は数字というものが大好きです。 数字化するとはどういうことなのか考えて見ましょう。 数字化すれば誰でもわかる IT技術者であれば作ろうとしているシステムの技術的な難易度やそのボリューム感について おおよそ把握することができると思いますが、その感触を非IT技術者に伝えることは難しい。 しかし、（あまりよい方法ではないかもしれませんが）何人の技術者で何ヶ月かかりますという、 いわゆる人月というモノサシを用意して数字にすることで非技術者にもボリューム感を伝えることができます。 数字にすることで10と100なら100の方が10倍大変ということぐらいは伝わります。 定量化して数字にすることで誰にでもその分量が分かるようになるわけです。 数値化の罠 数字というのは非常に便利で、とても直感的に量を

開発工程を別々に担当してはいけない というblogエントリを見かけて違和感を覚えたので少々。 該当エントリを読んでもらうのが一番なのですが、概略として指摘事項は、 ウォーターフォールモデルでは工程別で担当を分ける場合に生成されるドキュメントが膨大になり多くの工数を消費する プロトタイピングのような手法が用いにくく、手戻りの工数が大きい。 個別のパーツの製造者は仕様に従って製造するだけで責任を果たせるため、最終的なプロダクトの利便性などを気に留める必要がない。 上流～下流の各工程に下請け発注の産業構造が重なり、下流は単価が安く利益にならない。 といった点を上げ、作業を分担するという方法が諸悪の根源ではないか、と主張されているわけです。 複数の議論を内包する議題は、議論の抽出を行うべき 該当のエントリでは、非常に多くの議題を内包しています。 工程分離によって生産性が高くなるのか、低くなるのか

Programming SHOT BARへようこそ。 完全なテストは不可能だ といってしまった手前、現実的なテストについて考えて見ましょう。 なお、今回は数学側への分岐だった メソッドは写像だ側の概念も含んでいます。 伏線回収だと思って読んでいただけると幸いです。 完全なテストのテストケース数 システムに対して完全な仕様書があると想定します。 こういう場合はこう動く、ということが明確に規定されているとします。 すると、テストというのは、実装が想定する動きと同じかを検証する行為ですから、 システムを関数Fで、仕様を関数Gで表現すると、 F(x) = G(x) であることを、全てのxについて確認することになります。 ここで、xの取りうるパターン数が、そのままテストケース数になることになります。 今、入力xがn bitの情報量だとします。 すると、テストケース数は2n となります。 入力bit数

非常に大きな反響のありましたこのシリーズ、とりあえず投げっぱなしはよくないので締めておきたいと思います。 その１では単純化したモデルではありましたが、 時間給である以上、労働の牛歩戦術が労働者が目先の賃金を多く得るには最適な戦略になってしまうという問題点を指摘しました。 労働時間が延びた場合に残業代として支払われる余剰金は、能力UPによる昇給よりも幅が大きく、短期的には残業を取るほうが特になってしまうのです。 その２ではIT業界の会社間の契約で 頭数x時間による派遣労働型の契約が多いことを挙げ、その場合にやはり労働の牛歩戦術が利益向上の最適な戦略になってしまうことを示しました。 また、そのような形態で仕事を請け負っている会社としては技術者の腕はあまり利益にならないことを挙げ、 派遣型IT企業は技術を欲しないことを指摘しました。 さらに、理想的な給与形態は 集団の利益を最大にする方向性と、個

前回の続きです。 前回は時間給の場合、労働者が最小の労力で最大の賃金を得ようとする場合、生産性を下げる戦略をとることになる、というお話でした。 賃金という労働者の利益を考えた場合、生産性の向上は労働者にとっては実はどうでもよいことだったりするわけです。 会社やグループといった集団の利益と労働者個人の利益とが相反する状況にあるということを指摘したかったのですが、論点がブレてしまっていましたね。 会社間契約における労働の牛歩戦術 IT業界では今でも派遣業そのもののビジネスモデルを展開している会社が多くあります。 この場合、XXプロジェクトに5人送り込んだ、契約上は一人60万×5人＝300万の月間売上、という形になります。 さらに、月間労働時間が超過した場合は残業時間分だけ別途請求するような契約になっていたりします。 要するに頭数と時間で利益が増えるという契約。 これは前回とりあげた労働の牛歩戦

今回は給与形態のお話です。 日本で主流の基本給+職能給という形態の問題点を考察してみたいと思います。 注意：以下の話は論理的な話であり、実務上は各種法令が関連してきます。本稿ではそのあたりは考慮からはずしてあります。 最小の労力で最大の賃金を得るには ここではまず理論的にどのような労働スタイルが賃金を多くするのかを考えて見ましょう。 まずは簡単のため月給が20万、1日8時間、月間営業日20日間、月間労働時間が160時間、 残業が160時間つくと残業代が20万となるケースを考えて見ましょう。 時間給というのは労働の密度に関係なく、時間で賃金が支払われます。 1日の製造ノルマが100stepだとします。100step/日の生産性だと月給20万円です。 ところが、生産性が悪く50step/日しかできなかったとします。すると残業を160時間して月給が40万円になります。 おや、生産性を下げると賃金

お見合い1勝99敗 (PHP新書) 【本の概要】◆今日お送りするのは、新聞記者という職業に就きながら、お見合いを100回どころか150回ほどこなしてゴールインしたという吉良友佑サンのご本、「お見合い1勝99敗」。 本書は「産経関西」の関連サイトでもある吉良さんのブログ、「お見合い達人の裏話」を1冊にまとめたものです。 内容的には、タイトルの「1勝99敗」そのまま、失敗談の連続。 ただし、その失敗の中からも「学ぶべき点」が多々あるため、今回はその中から6つご紹介してみます。 いつも応援ありがとうございます！ 【目次】第1章 お見合いを始める心構え 第2章 お見合いの場で 第3章 デートの作法 第4章 相手の見極め方 第5章 結論の出し方 第6章 結婚についての考え方 第7章 お見合い相談室 第8章 お見合い余話 【ポイント】■1.「フタマタ」OKの巻 ◆本書を読むまで、お恥ずかしながら全然知

今夜も絶賛ブログ炎上中（計画炎上じゃーないですよ！）、だけど年相応に日々鈍感力に磨きがかかるたぬきちです。そんなたぬきが14歳の中学生に戻ったかのようにｗｋｔｋした日の日記です。 ■剣豪登場 春らしい日和だが日が沈むと風は冷たい。会社を定時に出て電車を乗り継ぎ、都内某所の居酒屋に向かった。 今日は特別な、スペシャルな夜なんだった。 居酒屋の個室で同行の人たちとしばし待つ。何度かスイングドアが開いた後、お目当ての人が現れた。 佐々木俊尚さん、四十八歳（推定）。ＩＴジャーナリスト。プロフィールはもうみなさんご存じと思う。僕がリストラに応じて会社を辞める決心をした直接の動機は佐々木さんの著書『仕事するのにオフィスはいらない』を読んだことだった。今夜は一読者の僕が、その佐々木さんと会える日なのだった。もちろん、佐々木さんが僕に直接声を掛けてくれたんじゃない。間を取り持ってくれた人がいるわけでその人

[いがぴょんの日記v2,diary,igapyon] 新規赴任の開発者向け書籍 (Java 系を中心に) をメモしておきます。 新規赴任の開発者向け書籍 (Java 系を中心に) をメモしておきます。 ビジネス・スキル系 - 基本 中学生からの作文技術 出版社: 朝日新聞社 著者: 本多 勝一 amazon.co.jp: 402259862X ￥ 1,260.- 日本語作文技術の基礎を教えるために利用。この本には、システム・エンジニアに最低限必要な技術が載っています。 新装版 日本語の作文技術 出版社: 講談社 著者: 本多 勝一 amazon.co.jp: 4062130947 ￥ 1,470.- 日本語作文技術の基礎を教えるために利用。この本には、システム・エンジニアに最低限必要な技術が載っています。 13歳からの論理ノート 出版社: PHP研究所 著者: 小野田

ITポートフォリオの管理を正しく行っていれば、たとえ選んだ施策が最大のROI（費用対効果）をもたらすものでなかったとしても、企業目標の達成にIT投資を確実につなげられる。ここでは、ITポートフォリオ管理の基本原則や、より生産的なポートフォリオ管理を行う方法について解説する。 関連トップページ： IT投資／ROI 正しいITポートフォリオ管理が、企業目標達成への近道 意思決定の優先順位づけの基準を見直し、より効率的なポートフォリオを作る 2010/04/27 ITポートフォリオの管理を正しく行っていれば、たとえ選んだ施策が最大のROI（費用対効果）をもたらすものでなかったとしても、企業目標の達成にIT投資を確実につなげられる。ここでは、ITポートフォリオ管理の基本原則や、より生産的なポートフォリオ管理を行う方法について解説する。 ITポートフォリオ管理の基本原則は、まず最初にポートフォリオ

毎年恒例の技術者向け（有償）コンファレンス「ISE Technical Conference 2010」の内容が公開され、申込開始になっています。今年は6/3〜6/4で、場所は箱崎（水天宮前）です。 - IBM ISE Technical Conference 2010 - Japan 毎年ご好評いただいている、ISE Technical Conferenceですが、今年はIBM本社（箱崎）にて6月3日(木曜日)〜4日(金曜日)に開催いたします。 先進のソリューション、最先端の技術情報などをお伝えし、充実した技術者のためのConferenceとなるようスタッフ、講師とも全力で取り組んでおります。今年は昨年までにいただいたご意見を反映し、セッション内容のさらなる充実を行っています。 ISE Technical Conferenceは日本アイ・ビー・エム システムズ・エンジニアリング株式会社(