コンピュータにおける「データ表現」の基礎
この講座のテーマは，2進数，浮動小数点数，BCDなどの「データ表現」です。皆さんは「そんなこと，分かりきっているよ！」と思われるかもしれませんが，はたしてそうでしょうか。小数点以下の2進数を10進数に変換できますか。「けた落ち」が生じる原因と，その対策を説明できますか。なかなか，自信を持って「できる」と言える人は少ないでしょう。データ表現は，コンピュータを取り扱う上で，基本中の基本となるものです。 信じられないことかもしれませんが，コンピュータを使っていると，数値が突然プラスからマイナスに変わってしまったり，誤差が生じて思い通りの計算結果が得られないことがあります。データ表現を知っていれば，このような問題に遭遇しても，原因を究明して適切な対策を施すことができるのです。16進数のダンプ・リストを見たときに，それが10進数でいくつなのかも瞬時に判断できるようになります。コンピュータを使っている
本質的でないレビュー指摘を減らすための試行を紹介した日経ITproの記事：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
要求ドキュメントや設計ドキュメントをレビューにおいて、誤字脱字の指摘の割合が高く本質的な欠陥の指摘が少ないというのは、どのような組織、プロジェクト、チームにおいても共通の悩みでしょう。 そのようなレビューを改善することを目的として、レビューで検出すべき欠陥の条件を変えて実務者の方にご協力いただいて検出結果を比較する試行をしました。 結果は論文で報告しています（S. Morisaki Y. Kamei K. Matsumoto: Experimental Evaluation of Effect of Specifying a Focused Defect Type in Software Inspection: PDFはこちらから）。ほぼ同じ内容の記事を以前に日経SYSTEMS（雑誌）に寄稿していました。昨日Web記事として日経ITproのサイトにも掲載いただきました。こちらから読めます。
NTTデータの松田氏が語る，「コンペ敗退で気付いた，企業ネットの“第3の目的”」
「まずは，最近びっくりしたことをお話したい」。NTTデータ 法人コンサルティング＆マーケティング本部の松田次博ネットワーク企画部長は，2008年9月10日に都内で開催されたイベント「ザ・ネットワーク・ロードマップ・2008」で講演に立ち，こう切り出した。 同氏によると，最近提案したデータセンターのコンペで他社に負けてしまったのだという。「びっくりした」というのは，その敗退理由である。松田氏としては「かなり勉強して」安めの価格で提案したのだが，それでも採用に至らなかった。提案を募った企業にコンペ後に聞いてみると，最終的に選んだ提案は米国のデータセンターを利用したもので，価格は松田氏の提案の半分以下だったという。「米国では，データセンターは地方に置かれる。土地は日本に比べるとタダ同然。電力料金は日本の半分の水準。しかも人件費が安い。これなら，差がついて当然」（松田氏）。さっそく海外拠点でのデー
［進捗管理編］あいまいな報告を認めてはいけない
通常，プロジェクト・マネージャ（PM）は，自分の担当するプロジェクトにおいてサブリーダーや担当者などから進捗報告や結果報告など多岐にわたる報告を受ける。その報告内容に基づいて状況を判断し，場合によっては重大な決断を行うことも多々ある。 報告される内容があいまいであったり，虚偽が含まれていたりすると，その後のプロジェクトの運命を大きく左右することにもなりかねない。あいまいな報告が定常的となっていたために途中までうまく行っていたはずのプロジェクトが突然失敗するケースも少なくない。 「進捗率90％」の意味は？ 筆者の知り合いのベテランPMが失敗した例を紹介しよう。Cさんは社会人生活20周年を迎えるベテラン技術者である。Cさんの勤めるZ社は，大手プロバイダであるY社からWeb経由でユーザーが直接自分の情報を更新するシステムの開発を受注した。 今回の開発は，そのシステム要件から高いセキュリティが要求
第1回 Tracをオススメする，これだけの理由：ITpro
Tracの便利さに惹かれるが，インストールに煩わしさを感じ，Tracを簡単にインストールできるTrac Lightning（旧Trac月）の開発を行う。また，日本のTracコミュニティであるShibuya.tracにてユーザー補完プラグインなどのプラグイン開発にも携わる。 チーム内のタスクや分散開発におけるタスク管理の手段として，プロジェクト管理ツールのTracが注目を集めています。Tracは，Ruby on RailsやSpring IDEなどでも利用されています。本連載では，開発現場を交通整理するために，Tracを利用したプロジェクト管理の効率化を，Tracの基礎から紹介していきます。 ソフトウエア開発において，プロジェクト管理はガントチャート・ベースで行われることが多いでしょう。しかし，ガントチャート・ベースの管理では，詳細を報告するために作業報告書を別途作成する必要があります。 ま
第4回 会議は段取りで決まる！～事前シミュレーションの徹底～
今回は，「会議は段取りで決まる！」と題して，会議前にどんな準備をしておくべきかについて解説したい。 早速，前回のケーススタディの続きから，スタートしよう。 経営企画部長から，次期基幹システム再構築プロジェクトのリーダーに任命された情報システム室主任の山田さとし。山田を含めて7人のプロジェクト・メンバーが決まり，メンバーの1人である製造部門の高田工長が，サブリーダーとして山田を補佐することになった。いよいよ，山田のプロジェクトが本格始動する・・・ デスクにて。 山田:「プロジェクト・チームのメンバーは決定したし，高田工長をサブリーダーに迎えることもできた。これからは，プロジェクトをどう進めていくかを考えよう。まずは，みんなに集まってもらって，顔合わせのための『キックオフ・ミーティング』を開催しよう。でも，キックオフ・ミーティングで何をしたらいいんだろう？部内ミーティングのリーダーの経験はある
プログラム間にボタンを掛ける「DI/AOP」（前編）
「DI（Dependency Injection）」および「AOP（Aspect Oriented Programming）」と呼ばれる技術が注目を集めている。これらはオブジェクト指向プログラミングにおけるプログラムの単位であるクラスを，互いに結び付ける新たな技術である。システムへの機能変更ニーズが高くなり，さらに開発期間が短くなっている開発の現場において，開発の効率化や品質向上を実現する新たな手段として期待されている。まずはオブジェクト指向プログラミングにおける課題を明らかにし，DIやAOPがそれらをどう解決できるのかを見よう。 DIでクラスを容易に付け外す オブジェクト指向プログラミングの一つ目の課題として，「変更時にクラスの修正が必要になる」ことがある。そもそも，オブジェクト指向で開発したプログラムは，オブジェクト指向ではないプログラムと比べ，機能の削除や変更が容易であることが特徴だ
プロジェクトの「見える化」は全社展開してこそ意味がある
システム開発プロジェクトの開発プロセスを改善したり，品質を向上させたり，トラブルを未然に防ぐために有効なのが，バグやプログラム規模，進ちょくなどプロジェクトに関する様々なデータを収集して分析する，「プロジェクトの見える化」であることに異論はないはずだ。ただし通常，プロジェクトのデータを収集するためには，現場のエンジニアがデータを入力しなければならず，開発現場に負荷がかかる。このため，「必要なことは分かるがなかなかできない」というのが実態だろう。 この「開発現場でデータを入力する手間」を省くために，「プロジェクトのデータを自動的に収集する」というコンセプトで開発されたのが，プロジェクトの「見える化」ツールである「EPM（Empirical Project Monitor）ツール」（関連記事）だ。構成管理ソフトの「CVS（Concurrent Version System）」や「Subvers
第30回 プロジェクト内のあらゆる「無駄つぶし」に注力せよ
PMO（プロジェクトマネジメントオフィス）を「コストセンター」だと思っているプロジェクトは，「プロジェクトマネジメントオフィス」という呼び名を止めるべきである。PMOは，開発/マネジメント・プロセスやコミュニケーションの無駄を省き，結果的に利益を生み出す責務を担っている。プロジェクトの生産性向上に寄与しない仕事には，手を出してはいけない。 田口正剛 マネジメントソリューションズ 取締役 PMOの役割・責任については，これまでに繰り返し述べてきました。しかし，IT業界やプロジェクトマネジメントの世界で確固たるイメージや理想像が存在するかといえば，答えはノーです。PMBOKガイド（A Guide to the Project Management Body of Knowledge）発祥の地である米国でも同じ状況です。 プロジェクトメンバーもPMOに対していろいろなイメージを持っていることでし
第3回 成果物や組織の管理方法「マネジメント・パターン」
二つ目のマネジメント・プロセスに関するパターンについては，「構成管理（Software Configuration Management）パターン」と「導入（Introduce）パターン」の二つがある。前者はソースコードのバージョンや構成をどのように管理するかについて示したパターン。後者は，組織内に新たな概念（アイデアや技術など）を導入する際のパターンである。 構成管理パターンは，Stephen P. Berczuk氏とBrad Appleton氏が「Software Configuration Management Patterns: Effective Teamwork, Practical Integration」という本にまとめたパターンである。邦題は「パターンによるソフトウェア構成管理」（翔泳社刊）。 構成管理パターンは，ソースコードのファイル（ソース・ファイル）の集まりである「
5分で人を育てる技術 (35)“仕事が速い人”の7つの特徴(後編)
前回は，仕事が速い人"の7つの特徴(中編)として，具体的な「話の固め方」について説明しました。 仕事では，自分で考えたこと，アイデア，企画を他人に説明し納得してもらわなければなりません。いつも他人に批判されていれば「仕事ができない」，「仕事が遅い」という厳しい評価を受けてしまいます。 仕事で成果を出すためには，他人に批判されない「固い話」を考える必要があるのです。ぜひ，前回ご紹介した手順で「話を固める」ことを実践していただきたいと思います。 今回も前回の続きとして"仕事が速い人"の7つの特徴を部下の小島に説明したときのエピソードを紹介します。今回も，“仕事に役立つ7つの科目”の「(2)仕事の段取り」がテーマです。 なお，今回は「芦屋式『仕事が速い人の7つの特徴』シート」を付録としてPDFファイルで用意しました。ぜひご活用下さい。 "仕事が速い人"の7つの特徴
コミュニケーション・スキル講座：聴く力と話す力を磨く！：ITpro
ITプロフェッショナルに求められるヒューマン・スキルは多岐に渡っており，そのすべてを習得し，実践できるようになるのは難しいものです。 そこでこの連載では，多岐に渡るヒューマン・スキルの“基本”となる「聴く力」「話す力」に焦点を当てます。 第1回 「聴くことと話すこと」を日頃からもっと意識しよう 第2回 相手の話の聴き方 第3回 相手の話を正しく，より深く聴くために 第4回 相手の話の内容や感情に理解を示す 第5回 相手が受け入れやすい伝え方，意識していますか？ 第6回 よりポジティブな言い方を意識してみよう 第7回 部下・後輩へのコーチングは，訊いて聴く！ 第8回 相手から考えや要望を引き出すインタビュー・スキル 第9回 日頃から相手に「伝わる話し方」を意識しよう 第10回 相手に納得・合意してもらう「説明力」を身につける 第11回 自ら“Action”を起こす 第12回 参加者が「納得感
「要求分析ツリー」を使って要求の構造をとらえる
システム構築プロジェクトの開始段階では，課題や要求を獲得する手段として，インタビューやヒアリングを使用するケースが多くあります。 企業活動のシステム化に際しては，オーナーである経営層から，実際にシステム操作をする現場の担当者まで，多くのステークホルダーが存在します。経営層と現場担当者では，当然のことながら視点や価値観が異なるので，同じ質問をしても聞く相手によって様々な回答が返ってきます。 例えば，現状の課題や新システムへの要望を質問した場合，経営者からは，「売上増加（3年後に年商120億にする）」とか「パート比率を上げることにより，人件費を削減したい」など，財務的な視点からの抽象度の高い要求が多くあげられます。一方，現場担当者からは，「在庫管理画面で他店の在庫を表示して欲しい」とか｢××システムのレスポンスが遅いので速くしたい｣など，自分の担当する業務に直結した具体的な機能要求があげられま
第8回 ウォークスルーとインスペクション--設計・開発の早期に欠陥を発見・除去し品質を作り込む
「ウォークスルー」と「インスペクション」は，システム開発の早い段階で欠陥を発見・除去するための方法である。開発者自身やチーム内の「モデレータ」と呼ばれる調整役が自主的に運営することが特徴だ。今回は，品質向上に欠かせないウォークスルーとインスペクションの具体的な実施手順を解説する。 布川 薫／日本IBM 前回は，プロジェクト遂行段階における品質のトラッキング方法（品質保証活動）の概要を説明した。今回は，システム開発において最もポピュラーで効果的な品質保証活動の1つである「ウォークスルー」と「インスペクション」の進め方を，読者が今からすぐにでも実行できるよう，具体的に説明しよう。 欠陥の発見が遅れれば遅れるほど，修正作業の手間がいたずらに増えることは，この連載でも再三強調してきた。肝心なのは，設計・開発の初期段階から，頻繁に欠陥の発見・除去活動を行い，テストの段階までに持ち越される欠陥を最少限
連載 Web 2.0時代のソフトウエア開発手法---目次：ITpro
Web2.0とは何かを定義するのは難しいが，大きな流れとしてテクノロジからビジネスへと多くのエンジニアが視点を移していることは間違いないだろう。言語，設計，コンパイラ，ライブラリ，といった要素技術から，SOA（Service Oriented Architecture）の視点，例えばGoogle APIをどのように使ってサービスをミックスし，新しいビジネス価値を提供できるか，というサービスの視点がより時代に合ったものになっていると思う。エンジニアがビジネス・モデルに関心を示し，ビジネスの言葉で技術を語るようになってきているのだ。さらに，アジャイル開発の考え方が浸透し，「ビジネス価値（Business Value）」を開発の最優先とする考え方が広まっているという背景もある。 この連載では，このような時代におけるソフトウエア製品開発にはどういった視点が必要か，また，その開発はどのような手法によ
第7回 問題管理と変更管理--プロジェクトで生じた問題と仕様変更をコントロールする
プロジェクトが，「品質」，「スケジュール」，「コスト」，「リスク」の観点から計画通り 順調に進行しているかどうか。この状況を継続的に把握するのが「トラッキング」だ。計画から外れていれば，対策を立てて計画に沿うよう「コントロール」しなければ ならない。いずれも，プロジェクトの遂行上きわめて重要な作業だ。 布川 薫／日本IBM これまで5回にわたって，情報システム開発における「プロジェクト計画」について解説してきた。今回からは，プロジェクトの遂行段階における「トラッキング」と「コントロール」の詳しい説明に進みたい。 トラッキングとは，プロジェクトの状況を的確かつ継続的に把握する作業のことだ。一方のコントロールは，プロジェクトの状況（実績）が本来あるべき姿としての「計画」から外れたときに，その原因を解明して適切な対策を講じるプロセスのことである。 的確にプロジェクトのトラッキングとコントロールを
ITエンジニアの「やってはいけない」---目次：ITpro
設計・実装から運用，メソドロジまで，最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」（アンチパターン）があるだろう。だが，その理由を問われると，うまく説明できないことがあるのではないだろうか。突き詰めて考えると，状況によっては「やっても構わない」こともあるし，技術の進化に伴い「やれるようになってきた」こともある。そこで設計，実装，テスト，運用，メソドロジの各分野について，取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル３～レベル１の３段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編
ソフトの「価格下落」は止まらない日本のIT企業は構造変化を見逃すな
「ソフトウエアのコモディティ化は避けられない。目指すべきはソフト製品とサービスのハイブリッド企業だ」。日米のソフトウエア産業を長年にわたり研究してきたマイケル・クスマノ氏は、こう主張する。日本のソフトウエア企業がハイブリッド企業に脱皮するには、品質と生産性のマネジメント、グローバルな視点でのリソース活用が必要と指摘する。（聞き手は桔梗原 富夫） 『ソフトウエア企業の競争戦略』という著書のなかで、「ソフトウエアのコモディティ化が進んでいる」と指摘していますね。ソフトウエア産業の現状をどう見ていますか。 現在のソフトウエア産業は、新しい競争の局面を迎えていると言えるでしょう。最も大きいのは、売り上げ構造の変化です。ソフト製品の販売でどうやって儲けるか、ビジネス・モデルを確立するのがますます難しくなりつつあるのです。 実際、多くのソフトウエア企業では、ソフト製品の売り上げが減少しています。代わっ
【Web 2.0 Expo】OECDも注目する「データ版YouTube」，その名は「Swivel」：ITpro
「データベースのYouTube」「データ分析の概念を変える存在」－－。そう呼ばれるサービスをご存じだろうか。ユーザーが自由にデータをアップロードして，グラフを作ったり統計分析を行ったりできる「Swivel」だ。4月17日（米国時間）に行われた「Web 2.0 Expo」の基調講演に，米SwivelのCEOであるBrian Mulloy氏が登壇して「現在われわれは，OECD（経済協力開発機構）からもデータの提供を受けている」と強調した。 SwivelのMulloy氏（写真1）は，「これまでWebで入手できるデータは，非常に使い勝手が悪かった」と指摘する。例えば写真2は，Googleで「Bankruptcy Stats（破産統計）」と検索して最初に表示された，米国の裁判所が発行している統計データの例だという。紙で配っている表をただPDFファイルにしただけで，見栄えや再利用性は良くない。 「イン
プロジェクトマネジメント入門
プロジェクトの進め方の巧拙は企業の競争力に大きな影響を与えるが，プロジェクトマネジメント手法の基本を理解することはそれほど難しくない。本連載では，経営者，実務者，技術者など，職種や年齢を問わず誰でも理解できるように，プロジェクトマネジメント手法の基本をかみくだいで解説していく。 第1回 手法の基本はだれでも理解できる 第2回 カギとなる用語をまとめて覚える 第3回 マネジャの任務は良いチーム作り 第4回 四つの基本ステップを把握する 第5回 開始前にやるべき内容を定義 第6回 実行計画をチームで作る 第7回 日程・予算・リスク計画を立てる 第8回 現状を常に把握しリスクを確認 第9回 必ず起こる問題に対処する 第10回 顧客が成果物を引き取ってこそ終了 第11回 経験をノウハウとして記録する 第12回 「成功」のカギはコミュニケーション 最終回 優れたマネジャの育成に取り組む
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
