ITエンジニアにとって文書作成技術は欠かせません。日常のメールのやりとりにはじまり、要件定義書、機能仕様書、企画の提案書など、上司やチーム、顧客などに対して、文章でコミュニケーションをとる機会がとても多いからです。 本連載では、論理的にわかりやすい文章を書く「ロジカル・ライティング」のノウハウを伝授します。ITエンジニアが日常的に用いるであろう文章を例に使い、どこが悪くてどう直せばいいのかといったポイントをわかりやすく解説します。実践すれば、誰でもすぐにわかりやすい文書が書けるようになるはずです。 連載目次 ●オリエンテーション ・ITエンジニアにとって「書く技術」とは？ ●文書の全体構成を組み立てられるようにする ・内容を大きく分けて項目を立てる ・適切な順番で項目を並べる ・話の階層をそろえる ●文章表現の基本ルールをマスターする ・主語と述語を対応させる ・修飾語と被修飾語をはっきり

Webサイトを構築する場合，通常は「設計書」を作成します。サイト全体の設計書であったり，ページ単体の設計書であったりするわけですが，今回は後者である「画面設計書」について考えてみましょう。 画面設計書を読むのは誰か Webサイトの構築では，対象ユーザーをできる限り具体的に決めてから開発を進めていきます。同様に，画面設計書にも「対象読者」を見定める必要があります。結論から言えば，かなり属性の異なる二種類の読者が存在します。 まず，発注者である「クライアント」です。クライアントは，技術的な難易度ではなく，自分たちのビジネス要件を満たすものが作られるかどうかを確認するために画面設計書を読みます。開発（プロジェクト）のゴールや，プロジェクトのメリット/デメリット，リリース後の顧客満足の予想などを，その設計書から読み取ろうとします。したがって，できる限り具体的なイメージが伝わるものが要求されます。

今回は，Webサイト構築プロジェクトのワークフローを俯瞰してみたいと思います。実際にクライアントから声がかかる場面から納品，つまり開発案件の完了までを12の「ステージ」に分けて図解してみました。思考のプロセス/人的配置/タスク/ツールなども一緒に記しています。少し大きな図になってしまいましたが，ご参考になれば。 図は，一番上は「4つのステップ/3つのタスク/12の要素（第62回　持続可能なWebサイト開発を支える12の要素）」。その下は，人的配置をロール(役割)ごとに記述しています。その下は，大まかなタスクのレベルです。それぞれの期間内に処理すべき項目を列挙しています。その下が，「ステージ」。プロジェクト全体を12のステージに分類して作業内容を整理しています。基本的には，その流れの順で進んでいきます。その下は，それぞれのステージのアウトプットのイメージで，更にその下にはよく使うファイルアイ

「データベースはブラックボックス。どんなSQL文を投げたらどんな結果が返ってくるかさえ知っていればよい」---そう思っている人も多いかもしれません。 しかし，本物のソフトウエア・エンジニアを目指すのであれば，データベースが動く仕組みを学ぶことは避けて通れません。パフォーマンスなどに問題が生じたときどこから手を付けていいのか皆目見当がつかない，といった事態に陥りかねません。 市販のRDBMSの内部はかなり複雑ですが，基本的な部分を理解するのはそれほど難しくありません。この特集でデータベースの動く仕組みを理解してください。 イントロ ●ブラックボックスのままでいいの？ 基礎から理解するデータベースのしくみ（1） Ｐａｒｔ１ ●SQL文はどのように実行されるのか 基礎から理解するデータベースのしくみ（2） 基礎から理解するデータベースのしくみ（3） 基礎から理解するデータベースのしくみ（4） 基

設計・実装から運用，メソドロジまで，最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」（アンチパターン）があるだろう。だが，その理由を問われると，うまく説明できないことがあるのではないだろうか。突き詰めて考えると，状況によっては「やっても構わない」こともあるし，技術の進化に伴い「やれるようになってきた」こともある。そこで設計，実装，テスト，運用，メソドロジの各分野について，取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル３～レベル１の３段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編

なかなかハードルが高く，多くの人が踏み出せないでいるカーネルのソース・コードの読解。本連載では，今までカーネル・ソースなんて見たことがないという人に，読みこなすコツをお教えします。今回は，どうしたらカーネル・ソースを読みこなせるようになるのか，筆者の経験をお話します。 Linuxユーザーなら誰しもカーネルのソース・コード（カーネル・ソース）を読んで，どのような処理を行っているのかを確認したり，自分なりの変更を加えたりしたくなるのではないでしょうか。しかし，カーネル・ソースの量は膨大な上，C言語で書かれているので，コンピュータ内部やOS（オペレーティング・システム）の仕組みを理解したプログラマでないとなかなか読みこなせません。そのため，カーネルを読むための第一歩を踏み出せない人が数多くいることは事実です。 本講座では，プログラマではないごく普通のLinuxユーザーが，カーネルをある程度自力で

技術や製品の多様化，不十分な要件定義の増加，オフショア開発の進展などにより，基本設計の難易度がますます上がっている。一方で開発の現場では，新規開発案件において十分に時間をかけて基本設計を実施するケースのような，ITエンジニアが基本設計のスキルを磨くチャンスが減っている。そうした要因により，ITエンジニアの基本設計のスキル不足が叫ばれることも珍しくない。 そこでここでは，基本設計の基礎を解説する。Part1では，基本設計を取り巻く環境の変化を改めて示したうえで，基本設計とは何か，ITエンジニアが身に付けるべく基本設計のスキルとは何かを提示する。Part2とPart3ではそれぞれ，DOA（データ中心型アプローチ）とオブジェクト指向による基本設計の基本を解説する。さらにPart4では基本設計で用いるパターンを，Part5では基本設計フェーズのドキュメントのレビュー方法をそれぞれ取り上げる。 Pa

今回は、パターンを1つだけ紹介します。「Mediatorパターン」です。GoF本では、それぞれのパターンの「目的]「背景」「効果」などが明示されています。私も、ちょっと真似をしてみましょう。複数のオブジェクトを組み合わせてプログラムの機能を実現するという目的において、オブジェクト間の関連がゴチャゴチャになってしまうという背景（問題）があり、Mediatorパターンの採用によって関連をキレイに整理できるという効果があります。説明だけでは、何のことだかわからないと思いますので、具体例をお見せしましょう。 図1[拡大表示](1)をご覧ください。これは、UML（Unified Modeling Language、ユーエムエル）と呼ばれる表記法で記述されたプログラムの設計図です。UMLでは、四角形の中に下線付きで名前を書いてオブジェクトを表し、関連のあるオブジェクトを矢印で結んで示します。ここで関連

創造には常に破壊が伴う。 今、企業情報システムの世界には、「マッシュアップ」による大変革が訪れつつあり、旧来のシステム構築のあり方が破壊され始めている。 もちろんシステム開発が消失するわけではない。破壊の後に誕生するのは、マッシュアップ、つまり外部のサービスやコンテンツをネットワーク経由で組み合わせる開発の時代である。破壊と創造に挑む企業も現れている。 07年4月、日本大学は10万人の学生が利用するメールシステムに米グーグルの「Gmail」を選んだ。SaaS（ソフトウェア・アズ・ア・サービス）形式の同メールの利用コストはゼロである。単に安いからGmailを選んだのではない。日大は、「システムの可用性やセキュリティ、使いやすさを検討した結果、Gmailを選んだ」（吉田誠 総合学術情報センター情報企画課課長）のである。 自らがサービスを取り込むだけでなく、社内のシステムやデータをサービスの形で

「Code Reading―オープンソースから学ぶソフトウェア開発技法」（毎日コミュニケーションズ発行，写真1）という本があります。私はこの本の監訳者ですから，やや自画自賛になってしまいますが，ソースコードの読み方を主題にした本はほかにはあまりありません。技法からツール，データ構造，アーキテクチャ，さらには実際にコードを読んで利用する実例まで紹介している網羅的で良い本だと思います。 この本の「はじめに」で「達人プログラマー」として知られるDave Thomas氏は以下のように書いています。 他人の作品を読まなかった偉大な作家，他人の筆づかいを研究しなかった偉大な画家，同僚の肩越しに技を盗まなかった腕のよい外科医，副操縦席で実地の経験を積まなかった767機長――果たして，そんな人たちが本当にいるのでしょうか？ たしかにその通りです。ソフトウエア以外の領域では修行することとはすなわち，他の人の

ビジネス・モデリングなどのモデリングを始めてはみたものの，なかなか上手くモデリングできない…そんな悩みを持っている方も多いと思います。そこで，今回はモデリングを上達させるための「モデリング・リファクタリング」という方法をご紹介します。 モデリング・リファクタリングとは 「モデリング・リファクタリング」とは筆者が考えた造語です。（すでに誰かによって提唱されているかもしれませんが）筆者が発明したものではなく，モデリングに慣れている方なら自然とやっているようなテクニックです。 もともと「リファクタリング」というのは，小さなプログラム（例えばクラス）を作るときに，プログラムの外側の仕様（使われ方）は変えずに，中身の構造だけを変えることです。 なぜそんなことをするかというと，とりあえず仕様は満たしていたとしても，中身が汚い設計のままでは，変更に弱く，保守性も悪いからです。そこで，小さなプログラムを作

出典：日経NETWORK 2006年11月号 35ページより 記事は執筆時の情報に基づいており、現在では異なる場合があります。

DIコンテナは，「DI（Dependency Injection：依存性の注入）」と呼ぶデザインパターンに基づいて作られたコンポーネント群を集中管理するためのソフトウエアです。 DIは，コンポーネント（クラス）間の依存関係をソースコードから取り除くことで，プログラムの実行時までコンポーネント同士が依存関係を持たないようにするデザインパターンです。 例えば，あるクラスAの中で別のクラスBのインスタンスを生成して利用しているとき，AはBに強く依存してしまっています。つまり，Bを別のクラスに差し替えたときなどにはAも変更しなければなりません。このような依存関係は，AとBを別の人が作っている場合などに特に困ります。 こうした依存性をクラスから取り除くのがDIパターンです。Bへの依存性をAから排除するには，まずBの機能を抽象化したインタフェースIを定義し，Iを実装したクラスとしてBを作ります。 Bの

株式会社DTS ネットワーク事業本部 プロジェクトマネージャ。Javaを中心にフレームワーク開発や開発プロセス定義など幅広く活躍中。StrutsIDEコミッタ。著書「まるごとEclipse!　Vol.1」（発行：インプレスコミュニケーションズ）。 この連載では，現場のJava開発者が気になるJavaフレームワークを詳細に解説します。今後利用実績が伸びそうなフレームワーク，多少メインストリームから外れているけど，ユニークで注目に値するフレームワークなどを，一つずつ取り上げてじっくり解説していきます。今すぐでなくても，いずれ仕事に役立つはずです。ぜひ読んでください。 第1回では，最近人気のAjaxアプリケーションを簡単に作れるフレームワークを取り上げます。Ajaxは，Webアプリケーションにリッチなユーザー・インタフェース（UI）をもたらす仕組みとして非常に注目されています。基礎的なアーキテク

自分の管理するシステムが不正アクセスされた場合には，影響範囲や原因を特定するために攻撃者の“痕跡”を調査する必要がある。対象システムがWindowsマシンであれば，レジストリの解析は不可欠。しかしながら通常のログ・ファイルと異なり，レジストリの調査は骨が折れる作業となる。そこで本稿では，不正アクセスを受けたシステムにおけるレジストリの解析方法をまとめた。 なお，Windowsマシンにおける失われやすい情報（揮発性の高いデータ）の証拠保全については以前の記事でまとめているので，そちらを参照していただきたい。 レジストリの分析は容易ではない Windowsマシンが不正アクセスを受けた場合には，通常，以下の3種類のファイルを調査することになる。 （1）Windowsのイベント・ログ （2）各種アプリケーションのログ （3）レジストリ （1）と（2）については，通常の運用においても馴染みが深いので

皆さんは，業務や研究などでソフト開発を行う際に，どんなプログラミング言語をお使いでしょうか。試しに筆者が勤務する会社の知人に聞いてみると，COBOL，FORTRAN，C，C++，C#，VisualBasic（VB），Java，ABAP＊1といった答えが返ってきました。皆さんの中には，これらの言語のほかにPerlやPHPといったスクリプト言語をお使いの方もいるかもしれません。 ここで紹介するRubyについて名前だけは聞いたことがあるという方も多いと思います（カコミ記事「Rubyの特徴」参照）。PerlやPHPと同じスクリプト言語です。ただし，Rubyはオブジェクト指向を意識して設計されているので，オブジェクト指向スクリプト言語と呼ばれることが多いようです。そのため，オブジェクト指向設計（Object Oriented Design）に基づいたプログラミングをする際にRubyは大きな効果を発揮

前回は，私が人材指導において，なぜ「長い説教より論理的な5分」と言っているのか，その理由をご説明いたしました。 今回から，私が行っている5分間指導の具体的な話を紹介していきます。 「抽象的な言葉は禁止だ！」 もう，数年前のことです。その頃私は，ある企業でスタッフとして一人で気ままな仕事をしていました。普段はあまり仕事はないのですが，会社で何か問題が起ると，そこに投入されて短期間で問題を解決するという仕事をさせられていました。そう，この頃の数年は，私は部下を持たず，気楽な生活だったのです。 そんなあるとき，会社である問題があり，私はその仕事に投入されました。仕事は，大手企業との商品供給提携のための交渉でした。私一人では厳しいので部下を何人かもらって，久しぶりに部下を指導をすることになりました。 私は，提案資料を部下の岡田に命じました。しかし，1日たっても何もでてきません。そこで，どんな内容に

これまで2カ月に渡って，「説得力をもった文書」をテーマに事例やテクニックを紹介してきました。 他人を説得するための文章術 (1)文書の説得力とは？ 他人を説得するための文章術 (2)説得力がない文書とは？ 他人を説得するための文章術 (3)文書を駄目にする10の原因 他人を説得するための文章術 (4)“しつこい”と思うくらいに説明しよう！ 他人を説得するための文章術 (5)顧客が嫌がる文書 他人を説得するための文章術 (6)説明不足に陥らないための工夫 他人を説得するための文章術 (7)まだまだある“駄目な文章表現” 他人を説得するための文章術 (8)上司や顧客に“駄目出し”される表現 私がこれまで実施してきた添削経験から，どんな表現が説得力を弱めているのかを分析・整理し，「これはまずい」という駄目表現を選び各回で解説しました。今回のシリーズでご紹介したもの以外にもたくさん駄目表現はあるの

このパートでは，プログラミングを勉強するうえで欠かせないアルゴリズムの中でも定番中の定番を紹介します。ソート（並べ替え）やサーチ（検索）などの機能は今では標準のライブラリとして提供されています。実用的なプログラムを作るときにそのものずばりをいちいち書く機会は少ないかもしれません。しかし定番のアルゴリズムは，様々に形を変えて普段のプログラミングに登場します。 解説を読んで仕組みがわかったら，ぜひそれをプログラムにしてみてください。読んだだけではプログラムを書けるようにはなりませんし，プログラムを書いてみて初めて，実は十分に理解できていなかったと気付くことがよくあります。しかもアルゴリズムは特定のプログラミング言語に依存しないので，一度身に付ければ，後でどんな言語を学ぶ場合でも役に立ちます。 1番目から6番目まではソートのアルゴリズム，7番目から9番目まではサーチのアルゴリズムです。一つひとつ

今回は，ユーザー企業が納得する提案書の作り方を解説する。ITエンジニアが起こしがちな失敗事例を具体的に挙げつつ，顧客を論理的に最適解に導くデシジョン・テーブルの作成方法を伝授する。 提案書はITベンダーのビジネスの中で大きな意味を持つ。顧客が抱える問題や課題を事前に収集・分析し，自社の提供する商品・サービスに適合するかどうかをビジネスと技術の両面から検討，解決策を導き出す――これがITベンダー側の視座から見た提案活動の基本である。提案書は解決策を集大成したものであり，その内容は顧客の期待と興味を喚起するものでなければならない。 そうでなければ顧客の意思決定，つまり受注には結びつかない。これは顧客がITベンダーに提案を要請した場合でも，ITベンダーが積極的にアプローチして提案した場合でも同じである。 せっかく苦労して提案書を作っても，受注に結びつかなくては報われない。訴求力と魅力のある提案書