技術本(コンピュータ関連)

February 06, 2009

SI力! IT社会を切り拓くプロフェッショナルたち

SI力! -IT社会を切り拓くプロフェッショナルたち
SI力! -IT社会を切り拓くプロフェッショナルたち

キーワード:
 小林 秀雄 / 伊澤 偉行、SI、大規模開発、NTTデータ、事例紹介
NTTデータグループの大規模システム開発事例が示されている本。以下のような目次となっている。
  1. 序章 優れた情報システムを生みだす力とは?
    第一章 【課題解決力】 企業や社会が提示する課題に情報システムで応える
    第二章 【チーム力】 組織体制とリーダーシップでパワーを最大化する
    第三章 【継続力】 「顧客と共に歩むこと」が信頼の絆を強くする
    第四章 【構築力】 時代を超越した「原理原則」の理念に基づく
    第五章 【品質力】 真摯に"バグの根絶"を追求する
    第六章 【突破力】 決してあきらめず困難な状況を打開していく
    第七章  【進化するSI力】 未来につなげるパワーを整備し育んでいく
(目次から抜粋)
この本の概要は以下のようなステップで示すことができる。
  1. 情報システムが社会生活でなくてはならない社会インフラになっている
  2. その社会インフラを支えるシステムインテグレーター(SI)のSI力が求められている
  3. SI力はシステム開発の技術だけでなく、プロジェクトマネジメントなどの人間的な部分も重要であるという考え
  4. SI力について、数多くの取材からまとめて一般化してみよう
そして、取材対象として、NTTデータグループが取り上げられている。以下その部分を抜粋。
 今回、取材のフィールドとして選択したのがNTTデータである。NTTデータは前身である電電公社の時代までさかのぼれば日本で最も歴史があり、国内有数の実績を持つシステムインテグレータである。「きっと、SI力への理解を深める情報を与えてくれるに違いない」と私たちは考えた。
 以降の各章では、情報システム構築の現場で豊富な経験を持つプロジェクトマネジャーをはじめ多くの技術者の人々にインタビューし、彼らの持つ能力に対して様々な角度から光を当てることを試みた。彼らの持つSI力を明確にすることができれば、情報システムの構築・運用に携わる人々にとっても、またCIOをはじめ情報システムと関係を持つ多くの人々にも、そのSI力を共有することができる。
(pp.6)
SI力に焦点が当てられているが、正直そこにはあまりぴんとこなかった。むしろ、競合他社のシステム構築事例として読むと結構面白いと思った。示されている内容は、大規模なシステム開発事例で、大抵は一筋縄ではいかない困難なものである。そのときに、技術的な部分だけではなく、洞察力、構想力、行動力、リーダーシップなどをまとめ合わせたヒューマンスキル的なSI力でそれらのシステム開発を成功に導いた、ということが多く示されている。例えば、構築事例としては、以下のようなものが挙げられる。
  • りそな銀行の巨大システム統合プロジェクト
  • iモードのサービスを支えるシステム「CiRCUS」
  • カード決済システムCAFIS(CAFIS - Wikipedia)
  • 医薬品業界の商取引データをやり取りするJD-NET
他にも事例が多く示されているが、いずれも何百人月という大規模システム構築事例となっている。

なんだかプロジェクトX風で、記事の内容的には、日経コンピューターのシステム構築事例に近い。それらのシステムの概要や起こりうる問題、そしてそれらの問題にどう対処したのかという部分がとても勉強になった。

ひとつ特に面白いと思ったのは、バグをゼロにする品質向上のアプローチだった。システムのバグをいかになくすかを考えたときに、設計工程に鍵があると仮定し、設計書のミスを徹底的に根絶したようだ。そこから、プログラム工程でのバグをプログラム工程で根絶していくことで、運用時にバグが発生しないとある。

詳細設計書の品質向上には、「なぜなぜシート」というものを使用するらしい。これは、問題が発生したときになぜその問題が発生したのかの原因分析や対策が示されていくものらしい。これが、プロジェクトチーム全体にバグ情報として共有され、品質が向上していくようだ。これはなるほどなぁと思った。

他にもNTTデータの社内体制や人材育成の仕組みなどが示されていて、SIトップ企業はやはり教育投資がすごいなぁと思った。PM社内資格認定制度や事業に必要となる人材像とコンピテンシーが定められたプロフェッショナルCDPというものが示されている。

正直、この本は、NTTデータの宣伝みたいなものだが、競合他社の大規模システム構築事例をプロジェクトX風に知ることができるという点では、価値があると思った。また、NTTデータに対する偏見が若干あったけど、少し見方が変わった。

大規模システム開発には、ヒューマンスキルが重要であるということもそれなりにわかってよかった。



SI力! -IT社会を切り拓くプロフェッショナルたち
SI力! -IT社会を切り拓くプロフェッショナルたち

読むべき人:
  • 大規模システム開発事例を学習したい人
  • プロジェクト管理に行き詰っているマネジャーの人
  • データは基本的に丸投げしかしないと思っている人
Amazon.co.jpで『SI』の関連書籍を見る

bana1 役に立ったらクリック☆  にほんブログ村 本ブログへ


February 02, 2009

SEのための図解の技術、文章の技術

SEのための図解の技術、文章の技術
SEのための図解の技術、文章の技術

キーワード:
 谷口功、SE、図解、文章読本、デザインパターン
SEのための文章や図解の基本的な表現方法が示されている本。以下のような目次となっている。
  1. 第1章 SEがユーザ/顧客に提示する文書
  2. 第2章  文書がユーザ/顧客にわかってもらえない理由
  3. 第3章  文書を構成する要素
  4. 第4章  平易で読みやすい文書の「構成」と「展開」
  5. 第5章  読みやすくわかりやすい日本語表現の基本技術
  6. 第6章  読みやすくわかりやすい文書にする図解表現技術
  7. 第7章  文書別の表現技術
(目次から抜粋)
この本は、読みやすくわかりやすい文書にする基本的な表現の方法/技術やルール、文章の構成、展開の方法/技術が示されている。以下にこの本の概要を引用。
 本書は、SEがユーザ/顧客に提示する文書を、読みやすくわかりやすいものにする指針の提供を意図しています。SEは、ユーザ/顧客だけでなく、開発グループの技術者に向けても、設計仕様書などの文書を作成します。本書の対象をユーザ/顧客を中心に捉え、彼らに向けて作成する文書をメインに置いたのは、開発グループの技術者向けの文書に比べて、「表現」が重要になるからです。また、ユーザ/顧客は、文書をシビアに見るために、それに応えることができるようなレベルの文書表現技術が必要になるからです。
(pp.4)
このように、ユーザに正しく理解してもらうことを主眼において、この本が構成されている。その方法として、分かりやすい文章の書き方、図解のパターンなどが示されている。

図解、文書についての示し方の本を読んだので、今回は練習もかねて図解を取り入れておく。

3,4,5章は分かりやすい文書の書き方が示されており、これは別にこの本でないと得られないものではない。特にこの本で重要なのは、システム開発業で作成される文書の種類とその目的について解説されている部分になる。以下、1章のまとめを自分なりに図解してみた。

文書の種類と目的

このようにドキュメントのタイプ別に書くべきこと、気をつけるべきことが示されている。

また、以下は、図解と文書の長所、短所についての自分なりの図解になる。

図解、文書の長所と短所

文章表現だけでは、冗長になりすぎたり、イメージがわかなかったりするが、図解を使えば全体像やイメージが把握しやすい。しかし、それぞれに一長一短があるので、それぞれを補完するように両方をうまく使いこなす必要がある。

図解を使うときに、図解の役割を明確にする必要があると示されている。以下のうち、どれなのかを考えるとよいようだ。
  • パラグラフで伝える内容を図解で表現し、それを補助的に説明するために本文を記述するのか
  • パラグラフで伝える内容を文で記述し、その内容をわかりやすく視覚化するために補助的に図解を使うのか
  • 図解と文を相互協働させ、相乗効果的にパラグラフの内容を分かりやすく説明するために図解を使うのか
    (pp.118)
そして、図解をパラグラフの中でどのような役割で使うのかは、そのパラグラフの内容によるらしい。これらの視点はあまりなかったので、とても勉強になった。何でもかんでも図解にすればいいというものではなく、文章、図解のどちらかをメインにして説明するかが重要なようだ。

文書の書き方も多く示されている。文章の構造や起承転結、読点の適切な位置、なるべく肯定文を使うといったことが示されている。特に修飾語を短くして分かりやすいものにすべきというのは、耳が痛いなぁと思った。このブログの文章は、割と長文の傾向がある。それは『〜の〜の〜の〜は』といった修飾語を一文で多用しすぎているということになる。これは気をつけようと思った。

この書評ブログで書評を書くときに、長文で示しているのは、文章作法のためという側面が強い。つまり、適切で分かりやすい文章をアウトプットするトレーニングということになる。優れたSEや技術者は、分かりやすく正しい日本語が書ける必要があるので。

設計書を書いて、上司にレビューしてもらうと、表現があいまいでどちらのことを示しているのかよくわからないと言われたことが多い。設計書は、自分たち作る側の人間だけが分かればいいというものでもない。設計書も納品成果物となっている場合、当然顧客もその内容を読む。顧客はもちろんITの専門家でないことが多いので、そのような人たちにも理解できるように示す必要がある。設計書やパワポの資料は、誰が読んでも一意に理解できるようなものを作れ、といつも上司にダメだしされていた・・・。

仕事であまりパワポを使ったりすることはないけど、いつそのような仕事が回ってきてもいいように図解のパターンを習得しておく必要があると思って、この本を読んでみた。図解だけでなく、基本的な文章作法やシステム開発業に必要な文書の書き方が示されており、とても勉強になった。

若手SEの人は絶対これは読んだほうがいいと思う。適切な文章を書いたり、図解で示せるようになるまで、これは何度も読み返そうと思う。

図解パワポ書評もありかなと思ったが、工数がかかりすぎる・・・。このエントリは2時間もかかっている。



SEのための図解の技術、文章の技術
SEのための図解の技術、文章の技術

読むべき人:
  • 文章を書くのが苦手な技術者の人
  • パワポで優美で分かりやすい資料を作りたい人
  • いつも上司のレビューでダメ出しされすぎている人
Amazon.co.jpで『谷口功』の他の本を見る

bana1 役に立ったらクリック☆  にほんブログ村 本ブログへ


January 22, 2009

中小企業向けAccess 開発実践ノウハウ

中小企業向けAccess 開発実践ノウハウ (DB Magazine SELECTION)
中小企業向けAccess 開発実践ノウハウ (DB Magazine SELECTION)

キーワード:
 前野好太郎、Access、DB、アップサイジング、ポテンシャル
中小企業向けのAccessを使用したDBシステムの開発方法が示されている本。以下のような目次となっている。
  1. 1部 Access流のDB設計
    1. 1章 AccessのDB機能を再確認しよう
    2. 2章 画面/帳票設計
    3. 3章 データ型を極める
    4. 4章 テーブル設計の勘所
    5. 5章 クエリを上手に使おう
    6. 6章 共通モジュールをしっかり作る
  2. 2部 Access流の開発テクニック
    1. 7章 クエリとVBAによるトランザクション処理
    2. 8章 AccessからSQL Serverへのアップサイジング
    3. 9章 パススルークエリによるSQL Serverへの接続
    4. 10章 パススルークエリによるSQL Serverへの接続
    5. 11章 テスト技法と運用環境
  3. 付録 DBのプロが明かすExcel活用の極意
    1. DBサーバーのクライアントとしてのExcel活用術
    2. ▲如璽進析ツールとしてのExcel活用術
(目次から抜粋)
この本の概要が『はじめに』に示されている。以下に抜粋。
 本書ではAccessならではの視点から、テーブルを作成するためのデータベースの基本から、クエリの活用方法、フォームやレポートの作り方、コーディングの方法などをまとめています。また、データベースとしての可用性や基本機能を高めるために、SQL Serverをバックエンドとして利用する方法も紹介しています。そのためにあまり取り上げられることがない、AccessデータベースからSQL Serverにアップサイジングする手法についても紙面を割いています。
(pp.iii)
この本を読む前は、Access、そんなMS製のおもちゃみたいなDBなんか使えないでしょ?と若干思っていた部分があるが、読了後はAccessはかなり使えるのではないか!?と思った。それだけ、自分はAccessのポテンシャルについて把握していなかったことになる。

この本は、Accessの基本的な特徴から、画面設計/帳票設計から内部のコーディングやSQL Serverとの連携まで幅広くまとまっている。結構知らなかったことが多く示されていた。以下、自分が特に勉強になった部分を恣意的に抜粋。
  • Accessのデータベース容量は最大2GB
  • Accessのネットワーク負荷の回避方法は、インデックス/クエリ/SQL文の配置、ローカルテンポラリテーブルの作成/再抽出、検索項目分割などのテクニックがある
  • テキスト型フィールドの1文字は1バイトではなく、半角でも全角でも1文字としてカウントする
  • Accessでの開発を進めるにあたって、一番重要なことは「限界を把握すること」
  • できる限りサーバー側データベースとの接続時間を短くするために、ワークテーブルを利用するようにする
  • Accessによるシステム開発のメリットとして、打ち合わせ時に作成した画面や帳票をそのまま利用できること
  • アップサイジングとは、DBエンジンをAccessに付属のDBエンジンであるJetからSQL Serverに移行することを言う
  • アップサイジングウィザードを実行すると、DBエンジンのアップサイズだけでなく、フロントエンドのAccessのファイル形式も「mdb」から「adp」に名称が変わる
  • Accessのmdb形式のファイルは、サーバーからクライアントにデータをすべて拾い上げてしまうので、ネットワークトラフィックが増大してさまざまな障害を引き起こすという特性を持っている
実際に仕事でAccessで作られたシステムのメンテナンスをやったりするけど、特にAccessは使えねーよ!!と思ってしまうのは、最後のネットワーク越し経由でDBをいじる処理を実行するときだ。そもそも、Accessはネットワーク越しに複数利用者のアクセスを想定していないつくりになっているので、数百件のデータを抽出する単純なSELECT文でもうんざりするくらい時間がかかってしまう。この本ではネットワーク負荷を軽減する方法としては、SQL Serverにアップサイジングすることと示されているが、単純なSQL文見直しやインデックスの効果的な貼り方などは示されていない。その部分が特に知りたかったが、残念だ。

やはりこの本の一番の特徴は、SQL Serverへのアップサイジング手順が示されている点だと思う。この本によれば、既存システムとしてAccessが使われている場合、もっとパフォーマンスが出るものにしたいとか、システムを一新する場合、ベンダーなどはAccessを破棄し、違う言語やDBシステムで一新するらしい。そのため、このようなアップサイジングについてまとまったものは殆どないようだ。そして、この本では、業務を知り尽くしているユーザーが自前で構成したAccessからSQL Serverへのアップサイジングこそが、中小企業の情報化への決め手となり、最良のシステムを構築する1つの方法論であると示されている。これはなるほどと思った。

他にも、Accessの位置づけとしては、プロのエンジニアからしてみれば容易なものだが、素人にとっては難解で、中間層がいないようだ。そのためAccessの技術者は極端に少ないようだ。

さらに、IT業界という大きな枠組みの中に大規模な基幹システムがあり、汎用ソフトウェアがあるとすると、それ以外の部分を埋めるのがAccess市場だと示されている。曰く、『かゆいところに手が届くシステム』と示されている。規模の小さいものでかつ導入コストがそこまで高くないので、タイトルにあるように中小企業向けとあるのだと思う。

各章の最後に、コラムが示されているが、そこがとても勉強になるし、おもしろい。著者のAccess開発経験の話や、Accessの市場の優位性、Accessのポテンシャルが熱く示されている。ここだけでも読む価値があり、このコラムによってAccessに対する印象がかなり変わった。

ただ、一点この本でダメな点は、サンプルプログラムのフォントが小さすぎて読みにくいこと。サンプルプログラムのコメントも薄いオレンジ色をしていて、本当に読みづらい・・・。プログラムを1ページに詰め込みすぎているからしょうがないといえばしょうがないが。

AccessとかVB.NETなどのMS系の技術や製品に対する偏見があったけど、最近、自分なりに勉強したり実際にプログラミングをしてみると、結構便利だったり、ちゃんと設計をすればよいものができるんだなぁということが分かりつつある。特にAccessに関して言えば、自分でDBの勉強をかねてシステムを作ってみようと思う人にはいいと思う。GUIベースでプログラミングを極力省略できて、分かりやすいし。すくなくとも、いきなりOracleのアーキテクチャを学ぼうと思って挫折するよりもいいと思う・・・。AccessからSQL Serverと自分の技術もアップサイジングすればいいと思う。

中小企業向けのAccessでのシステム開発をする人は、ぜひこの本を読んだほうがいい。

それにしても、技術本はやはり速く読めない・・・。この本は大体1週間近くもかかった・・・。毎日の通勤時間に読んでいたのもあるし。また、プログラムの細かいところまで考えながら読むので、どうしても時間がかかる。それはそれでしょうがない。



中小企業向けAccess 開発実践ノウハウ (DB Magazine SELECTION)
中小企業向けAccess 開発実践ノウハウ (DB Magazine SELECTION)

読むべき人:
  • Accessの基本を学習したい人
  • Accessなんか使えねーよ!!と思っている人
  • 中小企業向けのシステム開発をしている人
Amazon.co.jpで『Access』の関連書籍を見る

bana1 役に立ったらクリック☆  にほんブログ村 本ブログへ


January 15, 2009

はじめて学ぶソフトウェアのテスト技法

はじめて学ぶソフトウェアのテスト技法
はじめて学ぶソフトウェアのテスト技法

キーワード:
 リー・コープランド、テスト、テスト設計、入門書、引用
テスト設計のためのさまざま事例と手順が示されている本。以下のような目次となっている。
  1. 第1章 テストのプロセス
  2. 第2章 ケーススタディの説明
  3. Section  ブラックボックステスト技法
  4. Section  ホワイトボックステスト技法
  5. Section  テストのパラダイム
  6. Section  支援技法
  7. Section  最後の考察事項
(目次から抜粋)
この本の目次の構成があまりいけてないが、そのまま抜粋した。

この本は、さまざまなテスト設計の技法がまとめられたもので、ソフトウェアテストの設計だけに焦点を絞っているようだ。そして、この本の目的は以下のように示されている。
 システムの規模がどのようなものであっても、すべての異なる論理パスの組み合わせと、すべての異なる入力データの組み合わせに対してテストを行うことは不可能です。リソースの制約があるので、それぞれテストするなんらかの意味を持つ無限の選択肢の中から、テスト担当者がほんの小さな部分(サブセット)を選んでテストする以外に、方法はありません。この書籍の目的は、このようなサブセットを分析、設計、選択して、欠陥をより多く検出できるテストケースを作成できるように読者を支援することです。
(pp.1)
このように、テストケースを自分で作れるようになるのが最終目標のようだ。

では、どのようなテスト手法があるかというと、大きく分けると、ブラックボックステストとホワイトボックステストに分類できる。これはテストを良くやっている人、もしくは情報処理試験を受けた人ならすぐに定義が思い浮かぶだろうが、一応自分の復習のために、以下に定義を示しておく。まずはブラックボックステスト。
 ブラックボックステストは、要件と仕様書だけをよりどころにしたテスト戦略です。ホワイトボックステストとの違いは、ブラックボックステストではテスト対象ソフトウェアの内部パス、構造や実装に関する知識を必要としないことです。
(pp.26)
次は、ホワイトボックステストの定義。
 ホワイトボックステストは、テスト対象ソフトウェアの内部パス、構造、実装に関する知識をよりどころにしたテスト戦略です。ブラックボックステストとの違いは、ホワイトボックステストを実施するには通常、詳細なプログラミングのスキルが必要になることです。
(pp.126)
これだけではなんのことかいまいち分からない人は、以下を参照。そして、ブラックボックステストの対象は、単体テスト、統合テスト、システムテスト、受け入れテストといシステム開発のすべてのレベルで適用できるとあるのに対し、ホワイトボックステストの適用対象は、単体テスト、統合テスト、システムテストまで適用できるとある。ホワイトボックステスト=単体テストとして分岐、ループチェック、SQL文の抽出、結合条件チェックをするだけだと思っていたが、それはホワイトボックステストの1つの側面に過ぎないとあった。曰く、ホワイトボックステストは、単なるコードのテストというよりもパスのテストであり、同じ技法をサブシステム内のモジュール間のパス、システム内のサブシステム間のパス、さらにはシステム同士のパスにまで適用できるとあった。これは自分の知らないことだと思った。実際の現場では、ホワイトボックステストはそこまで広範囲には適用していないような気もする。テスト工数を削減するために・・・。

ブラックボックステスト技法として、以下のようなテスト方法が示されている。
  • 同値クラステスト
  • 境界値テスト
  • デシジョンテーブルテスト
  • ペア構成テスト
  • 状態遷移テスト
  • ドメイン分析テスト
  • ユースケーステスト
絶対抑えておかなければならないのは、同値クラステストと境界値テストだろう。これだけは、いつでもすぐにテストケースを作れるようになっておかなければならない。逆に、ペア構成テストとかは初めて知った。これは、変数の取りうる組み合わせのうち、すべてのペアをテストするというものらしい。

ホワイトボックステスト技法としては、以下が示されている。
  • 制御フローテスト
  • データフローテスト
  • スクリプトテスト
  • 探索的テスト
  • テストの計画
耳慣れないのは、スクリプトテストと探索的テストだろう。スクリプトテストは、『仕事を計画し、計画に従って仕事をする』というようにウォーターフォールモデル的にテストを実施していき、テスト計画書、テスト設計仕様書、テストケース仕様書などを作成していくアプローチらしい。対して、探索的テストは、計画的ではなく、テスト担当者がテストケースを実行しながらテストケースの設計をコントロールするようなアジャイル的なアプローチらしい。これは知らなかった。規模の大きなエンタープライズシステムではどう考えても、スクリプトテストしか適用できないと思った。探索的テストを実行すると、テスト工数が見積もれないし、納品成果物もおかしなものになりそうだ。しかし、XPのようなアジャイル的でドキュメントレスで、小規模な開発では有効かもしれない。

この本の面白い部分は、各章の引用にある。このようなアメリカ人の書くコンピュータ技術書は、気の利いた、各章の言い当て妙な引用が載っていることが多い。著者はこのような引用はもう出尽くした感があると思ったらしい。そこで、各章の引用に世界最悪な小説の冒頭部の文書を作るというコンテストで入賞したものを載せているようだ。著者が示しているように単なる面白さ狙いで、全く各章の内容を反映していないらしい(笑) 1つだけ、これは最悪だ!!と思ったものを示しておく。
戦いでボロボロに傷つき死に瀕したミュータント蜂の軍団は、羽根をあたり一面に共鳴させながら脚を宙に上げて必死にもがいており、虫番将軍は自分の巨大な飛行アブラムシにまたがってこの腐臭ただよう凄惨な戦場を一瞥すると、上官にむかってこう言った。「閣下、社会の窓があいております」
(pp.117)
これは最悪だwww逆にこの続きが読みたくなってくるから不思議(笑) どの章の引用も、一文がくどいほど長く説明的で、文の最後には文頭から想像できないところに終着する。どれも最悪で、あまり買って読みたい小説にはならないだろうね。

まぁ、引用はさておき、各テスト技法がそれなりに分かりやすく示されている。特に例題などが参考になる。演習問題もあるが、その答えがどこにも載ってない。自分で応用できるようになれということだろう。

テスト技法の基本を網羅的に理解したい場合にはいいが、各テスト技法の詳細について知りたい場合には、この本だけでは足りないと思われる。これを出発点に、さまざまなテスト本を読んでいけばいいと思う。

入門書としては、以下もお薦め。テストは新人技術者がやるようなイメージだが、本当はテスト専門部隊とか作ってかなりしっかりやるべきなんだよね。



はじめて学ぶソフトウェアのテスト技法
はじめて学ぶソフトウェアのテスト技法

読むべき人:
  • ソフトウェアテストの基本を体系的に学習したい人
  • 単体テストだけは極めたい人
  • 世界最悪の小説の冒頭部を読みたい人
Amazon.co.jpで『ソフトウェアテスト』の関連書籍を見る

bana1 更新頻度低下中クリック☆  にほんブログ村 本ブログへ


January 10, 2009

SEのための価値ある「仕事の設計」学

SEのための価値ある「仕事の設計」学
SEのための価値ある「仕事の設計」学

キーワード:
 森川滋之、SE、キャリア論、スキル論、最短距離
ITコンサルタントによって最短距離でSEのキャリアを築く方法が示されている本。以下のような目次となっている。
  1. 第1章 背中が煤けていませんか?
  2. 第2章 将来性がないなんて、とんでもない!
  3. 第3章 市場価値の高いスキルとは?
  4. 第4章 ぼくはどうして突破できたのか?
  5. 第5章 これが最短距離だ!
  6. 第6章 これからSEが目指すべき道は?
(目次から抜粋)
この本はITコンサルタントである著者によって、キャリアなどの人生設計がうまくできていない30歳前後くらいのSE向けに、最短距離で現状を脱却できる方法が示されている。

この本はとても真摯にかつ丁寧に書かれている本だと思った。今年1年、技術力を高めていこうと思う自分にとってはとても勉強になる内容だった。

線を引いた部分があまりにも多すぎて網羅性を示せないので、気になった部分などを恣意的に取り上げていくことにする。

これからのシステム構築のキーワードとして、『ユーザー主導』というものがある。これは、著者によれば、以下のように定義されている。
 エンドユーザーが中心となって業務設計をし、提案依頼書を作成して、ユーザー企業側の管理者が主体的にプロジェクト管理をし、システム開発をすること。
(pp.50)
これはつまり、システム構築を請け負うベンダーの言いなりになっていれば、本当に必要なシステムができることはないということであり、ベンダー依存体質から脱却しなければならないということになる。これからは、ベンダー任せではなく、ユーザー企業が積極的にシステム構築に関わっていくことになるようだ。

そして、その時に求められるIT人材はどういう人かというと、専門能力が高い人と示されている。たとえば、どこの企業でも会計知識は必要なので、公認会計士出身のシステムコンサルタントは今後もくいっぱぐれないとある。また、ファシリテーターや概念データモデルなどを作成できるデータアナリストも重要になっていくと示されていた。しかし、これらの専門性の高い職種はSEからなるのは難しいとある。

そのため、SEから上級職を目指すなら、システムグランドデザイナーとプロジェクトマネジャーが有望だとある。プロジェクトマネジャーなら誰でも聞いたことがあると思うが、システムグランドデザイナーという聞きなれないものは、著者の造語らしい。これは、一言で言えば、システム方式設計とソフトウェア方式設計ができる人らしい。そして、このような人材は本当に人手不足で、このような能力のある人の将来性がない、ということはないようだ。

システムグランドデザイナーに必要なスキルセットは以下のように示されている。
  1. ソフトウェア方式設計力
  2. インフラ設計力
  3. 業務理解力
それぞれをブレイクダウンしていくと、以下のようになる。まずは、ソフトウェア方式設計力
  • 開発言語、フレームワークになどに関する知識
  • データ構造とアルゴリズムに関する知識
  • 基本ソフトに関する知識
  • パターン化&と統合能力
  • 開発規約作成能力
次にインフラ設計力。
  • ハードウェアに関する知識
  • ネットワークに関する知識
  • データベースに関する知識
  • セキュリティに関する知識
  • アーキテクチャ選定能力
  • 規模見積もり能力
最後は業務理解力。
  • 一般知識
  • インタビューノウハウ
  • 業務フロー作成能力
  • データ分析能力
このように多岐にわたる知識や技術が求められる。プロジェクトマネジャーも同じように示されているが、今回は省略。上位レベルだけを示すと、プロジェクト管理に関する知識、ビジネススキル、人間力が求められるようだ。そして、これらのスキルセットのまとめ表が示されているので、自分には何が足りないか、どれを身に付けていくべきかがよくわかる。自分自身に関しては、インフラ周りと業務理解が特に弱いと思う。なので、ここを重点的にレベルアップしていきたいと思う。

技術者のあるべき理想像が示されているが、この本で特に重要なのは4章5章だと思った。4章からは著者のエンジニア人生が示されている。失敗経験やうまくいかなかったことなど、隠さずに赤裸々に示されている。それらは、自分も同じような経験があることもあるし、著者独自の大変な経験も示されている。

そして、5章こそが著者が1番伝えたかったこととあとがきに示されている。5章は、人が幸せになれるのは、自己実現をしているときというスタートから、技術者として自己実現するための14のステップが以下のように示されている。

自己実現までの14段階

これはとても参考になる。他の技術本にはこのようなものが示されていないので、この本はすごくSE、IT技術者のことを良く考えられていると思った。どれも細かく示しておきたいけど、これは実際に本を読んで確かめて欲しい。

ところどころに著者の仕事経験のコラムなどがあり、読み物としても面白い。また、各章の冒頭には必ず格言が示されている。著者は、矢沢永吉がお好きなようだ。

300ページくらいあるので、じっくり読んで1週間くらいかかってしまった。しかし、この本はどうしてもフォトリーディングで読み飛ばしていきたくなかった。本当に真剣に技術者のことを考えられて書かれている本だと思ったので。将来自分もこのような本を書きたいと思った。

新年、IT技術者として生きていくと決断するうえでとても勇気付けてくれる本だと思った。30歳前後くらいの読者を想定しているが、この本を早くに読めたことを幸運に思った。そして、システムグランドデザイナーを目指してみようと思った。

IT技術者として将来に悩んでいる人は絶対読んだほうがいい。



SEのための価値ある「仕事の設計」学
SEのための価値ある「仕事の設計」学

読むべき人:
  • IT技術者に将来性がないと思っている人
  • どのようなスキルを身に付けていいか分からない人
  • ITコンサルタントを目指している人
Amazon.co.jpで『SEのための』の関連書籍を見る

bana1 役に立ったらクリック☆  にほんブログ村 本ブログへ


January 05, 2009

アメリカ国防総省直伝 プロジェクト・マネジメント実戦教練ブック

アメリカ国防総省直伝 プロジェクト・マネジメント実戦教練ブック
アメリカ国防総省直伝 プロジェクト・マネジメント実戦教練ブック

キーワード:
 岩田治幸、PM、国防総省、戦略、EVM
自衛隊出身の著者によって、戦略的プロジェクトマネジメントが紹介されている本。以下のような目次となっている。
  1. 1章 プロジェクト・マネジメントとは何か
  2. 2章 何をどこまでつくるのかを決める(統合能力調整開発システム)
  3. 3章 方向性を誤らないよう行動方針を分析する
  4. 4章 仕事を柔軟に分担する(WBSの作成)
  5. 5章 コストの見積もり方
  6. 6章 スケジュール管理の仕方
  7. 7章 EVMを活用してできるだけ安く仕上げる
  8. 8章 リスクマネジメントの仕方
  9. 9章 使う人の身になって考える(信頼度・整備性の設計、品質管理)
  10. 10章 ジャストインタイムで提供する
  11. 11章 スパイラル開発手法でより良いものをより早くより安くつくる
(目次から抜粋)
著者は防衛大学出身で、自衛隊に入隊後、米国の軍事学校に留学していた人で、軍事的な観点からプロジェクト・マネジメントの方法論が示されている。以下、この本の目的を抜粋。
 本書は、米国陸軍兵站管理大学に留学し、プロジェクトマネジャー養成コースをトップクラス(Honor Graduate)で卒業した著者が、戦略的プロジェクト・マネジメントに必要な基礎知識、さまざまな事例、例題をわかりやすくまとめたものであり、一読すれば実践(戦)的な力が身に付くはずである。
(pp.4)
アメリカ国防総省の事例が多く出てくるので、軍ネタがとても多い。

まず、プロジェクト・マネジメントの目的を引用しておく。
 プロジェクト・マネジメントの目的は、組織内の壁を越えた横断的なチームによって一つの大きな目標を組織一丸となって達成するにあたり、スケジュール、リソース、そしてパフォーマンスのバランスを図ることにある。
(pp.16)
何気なく仕事でプロジェクト、プロジェクトと言っているけど、その最終目標は組織で何かを構築したり研究開発をしたりすることだと改めて認識させられる。そして、プロジェクト・マネジメントというと、プロジェクトで発生するスケジュール、人、物、金を管理することだということになる。さらに、プロジェクトにはかならず責任者としてのマネジャーが存在する。プロジェクトマネジャーの仕事は以下のように示されている。
 そこでプロジェクトマネジャーの仕事は、スケジュールの中で資源配分を適切にし、コストを抑制することによって、コストパフォーマンスに優れたものを開発し、それをユーザー(顧客)に提供することである。
(pp.13)
コストパフォーマンスに優れた開発を行うには、リソースやスケジュール、コストのバランスを図らなければならないようだ。

本書で取り上げられているプロジェクトは、従来の企業戦略やコンセプトが弱いプロジェクトを指すのではなく、戦略やコンセプトに主眼を置いた『戦略的プロジェクト・マネジメント』と定義されている。

軍事ネタが豊富で、その事例を眺めているだけでも面白いかもしれない。プロジェクトの工程管理などに使用されるWBS(Work Breakdown Structure - Wikipedia)の事例として無人偵察機や地上車両システムといった軍事兵器が出てくる。他にも、著者の自衛隊時代の教官としての話などもあった。これらは面白い事例で、他のプロジェクト本には出てこないものだと思った。

この本は、EVMの学習のために読んだ。EVMとは何かが示されている部分を以下に抜粋。
 アーンド・バリュー・マネジメント(EVM)は、その名前が示すように、実際に得られた成果に基づき、プロジェクトの進捗を管理する方法である。
 それは、得られた成果をコストに置き換えることによって、プロジェクトの進捗を定量的に評価して、スケジュールの改善すべき部分を「見える化」する。つまり、EVMは完了したタスクの価値を決定し、傾向をつかむための手段である。この情報は、プロジェクトマネジャーが賢く資源を活用することを可能にする。
(pp.142)
このEVMの事例が、プロジェクトマネジメントと旅行の対比で示されていて、わかりやすかった。EVMについて知りたい人は、Wikipediaの記事を参考にすればいいと思う。この本は、そこまで難しいことが書いてあるわけではないので、割とすんなりと読めると思う。ただ、1ページあたりの文字量が多目なので、読むのには時間がかかる。特に朝の通勤電車で細切れで読んでいたので、そう感じた。

プロジェクトマネジメントに良く出てくる、WBS、PERT、CPM、ガントチャート、コスト見積もりなどが割りと分かりやすく示されている。一度読んだだけでは体感的には分からないかもしれないけど、そのうちプロジェクトマネジメントをする立場になれば、これがよく分かると思う。なので、もう少しクラスが上がったら再読する必要がある本だと思った。

プロジェクトマネジャーに近々なりそうな人は読んでおいて損はないと思う。



アメリカ国防総省直伝 プロジェクト・マネジメント実戦教練ブック
アメリカ国防総省直伝 プロジェクト・マネジメント実戦教練ブック

読むべき人:
  • プロジェクト・マネジメントについて勉強したい人
  • 軍ネタが好きな人
  • マネジャーに昇進したい人
Amazon.co.jpで『プロジェクト・マネジメント』の関連書籍を見る

bana1 役に立ったらクリック☆  にほんブログ村 本ブログへ


November 21, 2008

これならわかるネットワーク

これならわかるネットワーク ― インターネットはなぜつながるのか? (ブルーバックス 1599) (ブルーバックス 1599)
これならわかるネットワーク ― インターネットはなぜつながるのか?

キーワード:
 長橋賢吾、ネットワーク、インターネット、ルーティング、ブラックボックス
インターネットのブラックボックスを「なぜ」という観点から解きほぐそうとする試みの本。以下のような目次となっている。
  1. 第1章 ネットワークとは?
  2. 第2章 インターネットはなぜ生まれたのか?
  3. 第3章 インターネットの約束ごと、TCP/IP
  4. 第4章 インターネットの郵便番号、IPアドレス
  5. 第5章 情報のバケツリレー、ルーティング
  6. 第6章 インターネットの電話帳、DNS
  7. 第7章 インターネットの渋滞とTCP
  8. 第8章 インターネットのこれから
(目次から抜粋)
たまには技術者らしく技術本も読まなければね、ということでネットワーク本。ブルーバックス(ブルーバックス)。実はブルーバックスの本を買ったのが、これが初めてではないかな。自然科学系の本はあまり買わないので。大学時代に図書館で読んだことはあったが。

この本は、小飼弾氏が『それでも、あえて言う。プロを目指すなら、読むべきはこちらだと。』と主張されていたので、読んでみた。(404 Blog Not Found:わかってどうするかが問題 - 書評 - これならわかるネットワーク

この本の特徴は以下のように示されている。
 本書は、このインターネットというブラックボックスを「なぜ」という視点から解きほぐそうとする試みです。従来のインターネットに関する解説書の多くは、トップダウン式に、「こうしたプロトコルがある。それはどういうものかというと・・・・・・」というアプローチでした。しかし本書では、ボトムアップによるアプローチ、すなわち「いままでの技術では解決できない問題点があり、それを解決するためにこのプロトコルが誕生した」という視点から、インターネットのブラックボックスに迫ります。
(pp.8)
この本は、ネットワークの発展の経緯がしっかりと示されていたので、わかりやすかった。既存技術では使えない部分があるので、それをどんどん発展していったところに今のインターネットがあるのだということがよくわかった。

以下、勉強になった部分を少しだけ列挙。
  • インターネットが他の通信ネットワークと比べて革新的なのは、郵便・電話以上に効率のよい通信ネットワークを提供しているから
  • インターネットの誕生の背景は、1957年にアメリカの軍事・宇宙技術を結集した組織、APRAによるもので、ARPAの課題は、旧ソ連からの衛星を経由した核攻撃にも耐えることができるネットワークを構築すること
  • インターネットとは、ある組織と別の組織が接続されているネットワークと定義することができる
  • 「インターネットはネットワークのネットワーク」という意味は、ネットワーク同士がゲートウェイを通じて相互接続していると言い換えることができる
  • 「障害に対する透過性」を提供するのが本来のルーティングの役目と言い換えることができる
もっと示しておきたい部分、例えば、TCP/IPのプロトコルの細かいところなど、たくさんあるんだけど、このブログの読者にとっては需要が少ないのでここまで(笑)

郵便局とインターネットの比較が特に分かりやすいなと思った。IPアドレスと郵便番号の対比で、ネットワーク上のパケットがどうやって配送されるのかが分かりやすい。こういう風に既存のものに例えられる説明が分かりやすいのだと思った。

この本は朝、電車の中で読んでいた。山手線で人身事故が起きて、列車が止まり、別ルートで目的地に着かなければならなかったときがあった。そのとき、自分自身がネットワーク上のパケットになり、障害の透過性を体験している気になった。つまり、インターネットではネットワーク上の障害に対応するために、動的ルーティングが要求され、一部の回線が切断されるなどの障害が発生した場合は、自動的に経路を変更する方式=(ダイナミック)ルーティングが求められるということ。これを感覚的に体感した。

ただ、ネットワーク上のパケットと自分自身で違うのは、ルーティングアドレスはルーターに保存されており、パケットはそのルーティングアドレスを基にルートを選べばいいが、自分自身は自分で目的地を決定しなければならないことだった。さらには、パケットが途中で消滅したら、再送されるが、自分自身が途中で消滅!?しても再送されないこと(笑)当たり前だが。そんなことを頭に思い浮かべながら、仕事先に何とかたどり着いた。そんな擬似ネットワーク体験。

著者は、日本のインターネットの伝道師である、村井純氏(村井純 - Wikipedia)に師事を受けたようだ。なので、このネットワーク本は信頼におけるものだなと思った。

ネットワーク本は、一度読んだだけでは分かった気になるが、本質を理解するには何度も読み返す必要がある。一番いいのは、自分でルーターの設定とかやればいいんだろうけど。



これならわかるネットワーク ― インターネットはなぜつながるのか? (ブルーバックス 1599) (ブルーバックス 1599)
これならわかるネットワーク ― インターネットはなぜつながるのか?

読むべき人:
  • インターネットの基本を知りたい人
  • ルーティングプロトコルがいまいち分からない人
  • 電車の路線図を眺めるのが好きな人
Amazon.co.jpで『長橋賢吾』の他の本を見る

bana1 役に立ったらクリック☆  にほんブログ村 本ブログへ


October 27, 2008

できるポケット 仕事に使えるAccessクエリの便利ワザがマスターできる本

できるポケット 仕事に使えるAccessクエリの便利ワザがマスターできる本 Access2003/2002対応 (できるポケット) (できるポケット)
できるポケット 仕事に使えるAccessクエリの便利ワザがマスターできる本 Access2003/2002対応

キーワード:
 国本温子、きたみあきこ、Access、クエリ、SQL
Accessのクエリ操作が分かりやすく示されている本。以下のような目次となっている。
  1. 第1章 クエリの基礎知識
  2. 第2章 クエリの基本ワザ
  3. 第3章 条件を指定してデータを取り出すワザ
  4. 第4章 テーブルのデータを操作するワザ
  5. 第5章 データの集計や分析に使えるワザ
  6. 第6章 文字列を操作するワザ
  7. 第7章 日付や数値を操作するワザ
(目次から抜粋)
マイクロソフト製品のAccess(Microsoft Office Access ホーム ページ - Microsoft Office Online)はDBソフトであるが、WordやExcelほどなじみがなく、案外直感的に使えないなぁと思うことがある。例えば、「Accessデータベースからこんなデータを抽出したい」、「こんな計算や集計をしたい」といった要求を満たすには、クエリ(クエリ - Wikipedia)の知識が必須になってくる。この本は、Accessを使用するときに必須のクエリの便利ワザが図解で分かりやすく示されている。

便利ワザが154個示されている。いくつか便利ワザのタイトルを列挙。
  • テーブルとクエリの関係は
  • 参照整合性の制限を緩和するには
  • クエリを実行するには
  • デザインしたビューのレイアウトを調整するには
  • クエリ上で計算するには
  • クエリの実行結果を編集できないようにするには
  • 平均以上のデータを抽出するには
  • 指定範囲外のデータを抽出するには
  • 特定の文字を含むデータを抽出するには
  • フィールドのデータを一括で削除するには
  • ユニオンクエリを作成するには
  • 複数のテーブルを利用して計算するには
  • 文字列を操作する関数とは
  • 日付や数値を操作する関数を入力するには
  • Null値と「””」を区別するには
このように『〜するには』という形式で質問が載っており、その答えが図解で示されている。

Accessはデザインビューでクエリを作成したりして、実際にSQL文をじか書きして実行するということはあんまりなさそうなイメージがある。なので、このデザインビューを含めたAccess特有の使い方を最初にマスターしないと、データ抽出や集計がうまくいかないのではないかと思う。

この本は、ポケット判で持ち運びやすいものとなっている。Accessクエリ全般の基本的なことが網羅されていると思う。どちらかというと、Accessを使用していて困ったときに、辞書的な使い方をするとよいと思われる。自分は、電車の中で概要を理解するために最初から全部目を通したが。辞書のような本でも、目を通しておくことで、テーブルにインデックスをはったように、後でほしい情報が載っているページに直感でたどり着きやすくなると思う。

Access全般やデータベースの基本概念までは詳しくは書かれていないので、本当にAccessでクエリ操作を頻繁にする人向けの本だと思った。

読むべき人:
  • Accessクエリがよくわからない人
  • デザインビューなどの操作がいまいち分からない人
  • 文字列操作に詳しくなりたい人
Amazon.co.jpで『Access』の関連書籍を見る

bana1 毎日クリックありがとうございます☆  にほんブログ村 本ブログへ


October 13, 2008

Access VBAプログラミング開発工房 入門・基礎編

Access VBAプログラミング開発工房 入門・基礎編
Access VBAプログラミング開発工房 入門・基礎編

キーワード:
 緒方典子、VBA、Access、初心者、入門書
AccessのVBAプログラミングの基礎がわかりやすく示されている本。以下のような目次となっている。
  1. Chapter 序章 VBAの覚え方―VBAなんてコワくない!
  2. Chapter 1 プロシージャの基本
  3. Chapter 2 値の代入の基本―値の代入なんてコワくない!
  4. Chapter 3 条件分岐処理の基本―条件分岐なんてコワくない!
  5. Chapter 4 繰り返し処理の基本―ループなんてコワくない!
  6. Chapter 5 イベントの基本―イベントなんか怖くない!
  7. Chapter 6  ADO/DAOの基本―データベースへの接続なんてコワくない!
  8. Chapter 7 まとめのプロシージャを作ろう―VBAの骨なんかコワくない!
(目次から抜粋)
この本は、Access(Microsoft Access - Wikipedia)のVBA(Visual Basic for Applications - Wikipedia)についての本格的な解説書ではないが、初心者の人にとって取っ掛かりとなるような本となっている。そのため、VBAの習得の仕方にスポットが当てられており、文法一つ一つとっても丁寧な説明となっている。

以下、完全に自分専用のメモ。自分の勉強になった部分を列挙。
  • VBAを使うために顧客管理データベースを作るのではなく、お客様の対応をできるだけスムーズにするために顧客管理データベースを作り、顧客管理データベースをスムーズに動かすためにVBAを使う
  • データベースを学ぶにしても、SQLを学ぶにしても、VBAを学ぶ場合でも、常に「目的」を意識してみる
  • オブジェクトとは、状況に応じて名前がついていて、操作が可能なもののことすべて
  • VBAのとっておきの修得方法は、VBAの構文の解説を、料理や英会話、車の運転など何か他のものに「例える」こと
  • Publicプロシージャはデータベース(mdbファイル)の中であればどこでも使えるが、Privateプロシージャはそのオブジェクトの中でのみ使用可能
  • Functionプロシージャは戻り値を返すプロシージャ、Subプロシージャは戻り値を返さないプロシージャ
  • Publicプロシージャは、イミディエイトウィンドウでテストするとよい
  • バリアント型(Variant)は、何でもありの型で、数値の場合は倍数精度浮動小数点型と同じで、文字の場合は、文字列型と同じ
  • 『Dim aaa, bbb, ccc As Integer』と宣言すると、変数bbb, cccはVariant型になってしまう
  • 日付型の表示書式は、『MsgBox #8/14/1975#』のように「#」で囲む
自分は、VB.NET(Microsoft Visual Basic .NET - Wikipedia)もある程度使いこなせるし、ExcelのVBAも基本文法を把握しているので、この本のすべてが網羅的に役に立ったわけではない。しかし、VBAの本を一通り目を通したわけではないので、やはりネットだけでは知りえなかったことがしっかり書いてあって、勉強になった。

特に、変数宣言の方法とかは、VBA特有だなぁと思った。『Dim aaa, bbb, ccc As Integer』で、すべてInteger型にならないのは、普通に使っていたらまず気づかない。なぜなら、この宣言の後で、bbbにInteger型のデータを格納しようとしてもエラーにならず、普通に使えてしまうから。これは、暗黙的に型変換されているから。こういう部分はコードエラーにならずに一見楽に見えるけど、後で致命的なオブジェクトエラーを引き起こしかねないので、型宣言に甘い言語ほど自分で管理して型を使うべきかなと思った。

また、Access特有のフォームの設定の仕方、プロパティの設定の仕方も図解入りで入っているので、そこは知らなかったので勉強になった。こういうのは、ネット情報だけでは少し物足りないので。

VBAの基本文法だけなら、基本的にネット情報で網羅できる。自分はVBAの文法だけならほぼ1日で基本的なことを理解したが、それは他のプログラム言語をある程度知っているからで、初心者となると、そうはいかなない。そういったことから、この本の説明は、プログラムの文法の話の前に、現実世界のたとえ話があり、かなり丁寧なのでわかりやすく、プログラミングをやったことのない初心者にとってよいと思う。逆に、VB.NETやその他プログラム言語を習得している人にとっては、この入門書の説明は冗長に感じられる。なので、初心者以外は、本当に必要な部分や知らない箇所だけ重点的に読めばいいと思う。自分の場合は、復習もかねてある程度網羅的に読んだ。

サンプルプログラムのCD-ROM入りとなっている。サンプルデータには、巨人軍のメンバーや、こんぼう、てつのつめ、どくけしそう、やくそう、まんげつそうといったドラクエでおなじみアイテムが使用されていて、著者の嗜好性がわかって自分的にはツボだった(笑)。自分も技術本を書くときには、このようにサンプルデータで密かに自己主張してみたいと思う。

AccessとVBAの基本を学習するにはよい入門書だと思った。

以下、VBAの3分で作ったサンプルプログラム。
Public Sub sample()

  Dim strTxt As String
  strTxt = "クリックお願いします!!" & Chr(13) _
            & Chr(13) & "m9(・∀・)ビシッ!!"
  MsgBox strTxt

End Sub
実行結果はここ。しょうもないプログラムだが、こういうメッセージ出力ができるだけでも初心者にとっては面白いと思う。ちなみに、『Chr(13) 』は改行記号(キャリッジリターン)になる。

読むべき人:
  • AccessとVBAの基本を学習したい人
  • Accessを使用したデータベースを学習したい人
  • 巨人軍とドラクエが好きなプログラマの人
Amazon.co.jpで『VBA』の関連書籍を見る
Amazon.co.jpで『Access』の関連書籍を見る

bana1 役に立ったらクリック☆  にほんブログ村 本ブログへ


October 03, 2008

受託開発の極意


受託開発の極意―変化はあなたから始まる。現場から学ぶ実践手法(WEB+DB PRESS plusシリーズ)

キーワード:
 岡島幸男、受託開発、基礎、教科書、誠実
受託開発の基本的なことが網羅されている本。以下のような目次となっている。
  1. 第0章 「受託開発」を楽しむには
  2. 第1部 受託開発の手ほどき
    1. 第1章 「お客さま」に関心を持つ
    2. 第2章 サービスは「見積り」から始まっている
    3. 第3章 「要件」さえつかめば大丈夫
    4. 第4章 保守性にこだわった「設計」・「実装」・「テスト」
    5. 第5章 「運用」が最上流
    6. 第6章 「計画」と「スケジュール」の管理
    7. 第7章 「チーム」で成功を目指す
  3. 第2部 人と組織を変えること
    1. 第9章 「仲間」を増やす
    2. 第10章 「組織」を変える
(目次から抜粋)
この本は、著者によれば、ソフトウェア、システム開発業において、プロフェッショナルな仕事をしたい、楽しく仕事をしたい人のために、受託開発で気をつけなければならないこと、意識したほうがよいことが示されている。著者の思いが詰まった部分が『はじめに』に示されているので、その部分を抜粋。
 一つのプロジェクトの成功や満足な仕事ができた喜びだけにとどまらず、そこで得られたことを次の世代の種として蒔くことができる。プロジェクトがうまくいかなかったのであれば、技術を改良し次のチャレンジでは成功させたいと努力できる。ソフトウェア開発の現場にそんな開発者をもっと増やしたい。それが私の目標であり、この本がその一端を担えれば幸いです。
(pp.7)
著者の受託開発の経験から、受託開発業をよくしていきたいという思いが全編にわたって示されている。

受託開発は、おおまかに、「見積もり」、「要件定義」、「設計・実践・テスト」、「運用」という流れで進んでいくが、この本では、最初に「お客さま」に焦点を当てているのが特徴になっている。他の本ではあまりここに焦点が当たっていないときがあるが、この本では、ここが一番重要だと思った。

「お客さま」の接し方を学んでおくことは、要件定義や設計といった仕事のやり方を身につける以上に重要だという考えからくるもののようだ。これはなるほどと思った。技術者としてキャリアを積もうと思ったときは、どうしても開発方法論やサーバ、インフラ、プログラミング言語、フレームワークなどの技術に意識が行ってしまい、「お客さま」という視点が薄れてしまう。しかし、お客さまに関心を持つことで、より仕事を楽しみ、より優れた成果を残すことができるようだ。

お客さまに対してのプロ意識が示されている部分があるので、以下その部分を抜粋。
 お客さまに対しても同じことなのです。コミュニケーションの問題が発生したなら、すぐにでも関係を修復したい。お客さまのやりたいこと(要件)をきっちり理解したい。偏った情報に惑わされず、最適な技術を適用してあげたい。お客さまに関心を持ち、このような問題意識を持つことが、受託開発を生業とするプロになるための第一歩なのです。
(pp.25)
そして、お客さまに関心を持てない理由は、「コミュニケーション量の少なさ」だと示されており、お客さまと接する機会をもっと増やし、コミュニケーションの絶対量を増やすべきだとある。その具体的な方法も示されている。コミュニケーション量を増やすというのはそうだなぁと思った。プログラミングをしていて、これは誰のために作っているのかなぁと思うことがあり、それは上司のためではなく、システム利用者のお客さまということだということが忘れがちになる。しかし、お客さまの要望を実際に会って聞くと、あぁ、この人たちのために作っているのだということが実感できる。

あと、「設計・実践・テスト」部分でもなるほどと思うところがあった。著者によれば、設計とは、以下のようなことらしい。
そして「設計」とは、定義された要件を満たすための実現手段を具体的に検討することで、品質を作りこむ作業です。
(pp.72)
また、受託開発で重要なのは保守性であり、「設計・実践・テスト」においては、それに着目したやり方が必要だと示されている。具体的には、基本設計書、ユースケース記述、テーブル定義書、テストケースなどについて言及されている。

受託開発の流れに沿って、重要なことや気をつけなければならないことが網羅的に示されているほうだと思う。しかし、著者自身『受託開発の極意』と書いていながら、すべての受託開発をカバーしているものではなく、主に中小規模の業務系システムを対象としているようだ。

また、第2部の自分、仲間、組織を変えていくというのは、XPの思想に近いものがあるなぁと思った。

結局、受託開発で重要なことは、瑣末な技術よりもプロジェクト体制であったり、一緒に働く仲間であったり、お客さまであったりと機械系よりも人間系を意識するということなのではないかと思った。

受託開発の基礎を学びたい人にはお薦め。

読むべき人:
  • SEの人
  • 技術にばかり関心があり、お客さまに関心が薄い人
  • プロジェクトマネージャの人
Amazon.co.jpで『岡島幸男』の他の本を見る

bana1 役に立ったらクリック☆  にほんブログ村 本ブログへ


September 04, 2008

日本のソフトウェア産業がいつまでもダメな理由


日本のソフトウェア産業がいつまでもダメな理由

キーワード:
 久手堅憲之、ソフトウェア産業、ダメだし、課題、プロ
IT業界のダメな点、課題などが鋭く指摘されている本。以下のような目次となっている。
  1. ソフトウェア産業に起きていることを今語ろう―プロローグ この業界の酸いも甘いも知っている男たち
  2. 第1章 技術がよりどころのソフトウェア会社がエンジニアの足を引っ張る―会社のここがダメ
  3. 第2章 仕事から生み出す価値が自分のところで止まっていないか?―エンジニアのここがダメ
  4. 第3章 「優良産業」を名乗れる日ははるかに遠い―業界のここがダメ
  5. 第4章 発注企業はこのパターンにはまって「ゴミシステム」をつかむ―ユーザーのここがダメ
  6. 神の手という名のプロフェッショナリズム―エピローグ
(目次から抜粋)
この本は、日本のソフトウェア産業が衰退に向かっていて、現状ではいろいろな問題点や課題が多くあると示されている。そして、その課題や問題点から、エンジニアに提言を、ユーザーには警鐘としてメッセージが示されている。

これはとても勉強になった、というよりも、なるほどなぁ、と改めて自分の所属しているIT業界の本質を知ることができてよかった。とても考えさせられることが多かった。それにしても、表紙の英語の副題が『18+ Reasons Japanese Software Industry Always Said Hopeless』って、いつも絶望的だってwwwまぁ、これを読めば確かにその通りなのかなと思ってしまったが・・・。

1,2章は主にこの業界で働くエンジニアに向けてのメッセージが示されている。例えば、プロジェクトでは一番有能な人間が失敗の責任を負わせられたり、仕事が一方的に押し付けられたりして潰れてしまう。さらにはそんな失敗プロジェクトの火消しに生きがいを感じたりする人もいるようだ。そこで著者は以下のように、エンジニアに提言している。
火事場と呼ばれる問題プロジェクトで生きがいを探す前に、組織の再発防止策をチェックしよう。でなければ、一生火事場暮らしになりかねない。
(pp.29)
なるほど、と思った。ソフトウェア産業だけが、常に失敗プロジェクトから反省もなく、同じような失敗を繰り返していると随所に示されている。

2章では日本のエンジニアに対するダメだしが示されている。例えば、日本製のソフトウェアが海外で売られていないわけとしては、日本のSEは勉強不足で、国内市場だけでなんとか利益を出せている現状があり、ぬるい状況に甘んじていてプロフェッショナル意識が低いからだと。そして、日本のエンジニアには以下のような弱点があるようだ。
  • プロとして働くこと、自分を伸ばすことの意欲が低い
  • 外国製のソフトウェア製品を使う立場に甘んじている
  • 自社製品、自国製品を海外に売り込む意識が低い
確かに日本製のエンタープライズ向けのパッケージ製品はあまり聞いたことがない。大抵はOralce、SAPなどを筆頭とする外国製の癖のある製品だなぁと思った。そして、このような現状では、オフショア開発がさらに進み、外国人エンジニアとの国際競争力では負けてしまうとある。

さらに、エンジニアたちを取り巻く問題は以下のようなものがあるようだ。
  • 大学時代から多くを学んでこなかった
  • 大学教育も企業ニーズとどこかズレている
  • 経験がなくてもSEで通用した
  • サラリーマンだから評価は横並び
  • どうせ評価されないから自分の殻にこもる
  • 顧客視点・ビジネス視点で価値を考えることは苦手
  • 組織の均質な兵力にはなりたくない
以上のような問題点から、著者は以下のように提言している。
エンジニアの道を追求するのなら、自分の足で立つべきだ。今にあっては腕だけで食えるのはよほどの場合だけだから、もう一度、誰にとっての自分の仕事の価値とかいう視点に立ち返ってみよう。
(pp.89)
なるほどと思った。

3,4章は、システム構築などをエンジニアに依頼する立場のユーザーに対してのダメだしが示されている。3章では、システム開発費を払っても、バグッたものや使いにくいものだったり、企業利益をもたらさないような、欲しいと思っていたものが手に入るかどうかわからないアヤシサを野放しにしているこの業界について鋭く解体している。

例えば、お金の話として必ず根拠として使われ、この業界のスタンダードになっている『人月』という単位などは、どこまでいっても売り手目線でしかないとある。結局、人月計算による価格の計算は、
「お客さんが何をやりたいのか検討もつきませんけど、とりあえずウチからは4人のプログラマを3ヶ月お貸しします。好きなように使って何でも適当に作っちゃってください」
(pp.122)
ということに等しい。結局それは、人材斡旋業でしかないと、ばっさり切り捨てている。そこで、著者はユーザーに以下のように警鐘を示している。
要求開発や設計の前にコストをきちんと算定することは不可能に近い。人月単位の開発計画は、信憑性を疑ってかからなければならない。
(pp.124)
なので、ユーザーもベンダーにまかせっきりにするのではなく、経営層からこのようなシステムをいくらで作ってくれと要求をしっかりまとめることが重要であるというようなことが示されていた。

4章では、そもそもIT企業とはどのようなものがあるかということが示されていた。それによると、本質的にIT企業と呼べるものは、ソフトウェア会社などやネットサービス企業ではなく、金融、エネルギー、運輸など、IT基盤なくして業種が成り立たなくなっているインフラ企業のみだとある。ソフトウェア会社は何重にもよる下請け構造により、ただの人材斡旋会社でしかなく、ネット企業は技術が強みではなく、ビジネスモデル屋や金融業でしかないとある。これはなるほどなぁと思った。

他にもいろいろと紹介したいが、この辺まで。

自分もIT業界に身を投じているけど、ここまでとは思わなかったなぁ。IT系雑誌を見たり、2chのSE、プログラマ、IT業界のスレをよく覗いたりするけど、似たようなことが多く示されているなと思っていたが。それがこの本でよくまとまっていて、IT業界とはどういう状況か?、エンジニアの働く組織とはどういう状況か?そしてIT業界全体に未来はあるのか?ということが示されている。自分自身も個人レベルでエンジニアとして意識なければいけないことが多く示されていると思った。

このままIT業界にいてはダメな気もするが、自分の所属する組織から日本のIT業界を改革していくというのも野望の一つとして挙げるのもアリかなと思った。

この本は、SEやプログラマ、システム開発を発注するユーザーなど、IT業界に関わる人誰が読んでも得るものがあると思う。特にSE、プログラマなどIT業界で働く人は絶対必読!!な一冊だと思った。

みんなでこれを読んでIT業界をよいものに変えていこうぜ!!っていうような本だと思った。

読むべき人:
  • IT業界で働いている人
  • システムを発注するユーザー企業の人
  • IT業界のダメさ加減を知りたい人
Amazon.co.jpで『久手堅憲之』の他の本を見る

bana1 クリック感謝です☆  にほんブログ村 本ブログへ


August 28, 2008

ソフトウェア技術者の仕事力


ソフトウェア技術者の仕事力 〜対話の重要性とその心得

キーワード:
 増田智明、エンジニア、対話、そもそも論、問答法
対話形式で、ソフトウェア技術者の仕事観が示されている本。以下のような目次となっている。
  1. 1章 え?
    1. 1-1 お先真っ暗?
    2. 1-2 何が大事なの?
    3. 1-3 何が必要なの?
    4. 1-4 できる人って?
    5. 1-5 技術大国?
  2. 2章 技術って何?
    1. 2-1 その技術って何に使うの?
    2. 2-2 最新技術って誰が作るの?
    3. 2-3 何ができるの?
    4. 2-4 技術って何?
    5. 2-5 自分に向かって使ったことあるの?
    6. 2-6 もしかして薬漬け?
    7. 2-7 普段は何しているの?
    8. 2-8 好きなものを作れるの?
    9. 2-9 なんで解決策を拾ってくることばかり考えるの?
    10. 2-10 自分で編み出したりしないの?
    11. 2-11 でも駄目なんでしょ?
  3. 3章 どんな風にやっているの?
    1. 3-1 どんな人がいるの?
    2. 3-2 どんな風にやっているの?
    3. 3-3 後戻りって何なの?
    4. 3-4 お客が喜ぶようなものはできているの?
    5. 3-5 どうしてお客の話を聞かないの?
    6. 3-6 それでどう,難しいの?
    7. 3-7 できる人って結局何なの?
    8. 3-8 その環境ってどんなものなの?
    9. 3-9 甘ったれんじゃないわよ
    10. 3-10 結局のところ何が嫌なの?
  4. 4章 なんでやらないの?
    1. 4-1 普通にやるのって大変ですよ
    2. 4-2 間違いだらけ
    3. 4-3 井の中の蛙?
    4. 4-4 ソリューションって何?
    5. 4-5 議論する以前の問題
    6. 4-6 チームワークって何?
    7. 4-7 技術の進歩って…
    8. 4-8 鶏が先か卵が先か…
    9. 4-9 エンジニアってそもそも何?
    10. 4-10 何ができる人のことなの?
    11. 4-11 実のある技術って何?
    12. 4-12 好きなことすれば?
    13. 4-13 知識って何?
    14. 4-14 何も考えていないんですもの
    15. 4-15 最低限?
    16. 4-16 なんでやらないの?
  5. 5章 作ってみてよ
    1. 5-1 チラシの裏
    2. 5-2 何かやってみる?
    3. 5-3 あんたが持ってきたこれは何?
    4. 5-4 できる人だったらどうするの?
    5. 5-5 人の話を聞けって!
    6. 5-6 やればできるじゃん
    7. 5-7 目的は作ることなんでしょ
    8. 5-8 間違いだらけ
    9. 5-9 それ以外のときにいつ使うのさ
    10. 5-10 SE?プログラマ?
    11. 5-11 腹が立たなくなってきましたよ
    12. 5-12 結局やることやるだけ
    13. 5-13 優秀なエンジニアさんって
    14. 5-14 おわりに
(目次から抜粋)
ちょっと目次の分量が多いが、この本の場合は、全て示しておかないと何が書いてあるのかさっぱり分からない。だって、1章のタイトルが『え?』って(笑)。さすがに、今までいろんな本の目次を抜粋してきたけど、これはないwww

この本は、10数年IT業界で働いてきた著者である増田さんと、行きつけの飲食店の店員アキさんとのソフトウェアエンジニアの本質についての対話が示されている。そのためすべの文章が口頭語からなっている。

本の中の増田さんは、ITエンジニアとしてそれなりに働いてきたが、どうも最近自分の仕事に行き詰まりを感じていて、IT業界そのものにたいしてお先真っ暗と感じているようだ。そこで、何とか相談したくて、なぜか飲食店店員のアキさんに話をしに来たという設定になっている。

なるほどなと思う対話部分をいくつか抜粋。『3-4 後戻りって何なの?』から。
アキ 「そもそも、そのお客と話をしているの?」
増田 「もちろん、してますよ。そりゃ」
アキ 「ところでさ、私あんたが使うカタカナ文字とか、要求だの設計だの全然意味が分からないのだけど、もちろん全部説明しているんだよね?」
増田 「・・・・・・。一応は・・・・・・」
アキ 「でも、実際は自分では不味くて食べられないご飯を押しつけていたんでしょ」
増田 「そうですね」
アキ 「それで、使えるか使えないか自分でもよく分かってないものを使っているのに、お客にきちんと説明できるの?」
増田 「・・・・・・」
アキ 「それってお客と話をしているって言えるの?」
増田 「でも、そういうもんですから」
アキ 「はあ?技術を自慢している人が、そんなことやっていいと思っているの?恥を知りなさいよ」
(pp.54-55)
という感じ、アキさんは完全にツンツンキャラで、増田さんは常にアキさんから突っ込まれている始末wwwアキさんにデレは終始ないwww

それはおいといて、本質的な部分でいうと、これはついつい忘れがちなことを的確に突っ込んでいるなぁと思った。どうしても技術者本位の言葉を語りがちで、本当にお客さんが分かる言葉で説明しているかというのは自分も反省するところだなと思った。お客さんがどの程度の知識があるかを把握しながら説明するのは結構難しい。

他にも『4−4 ソリューションって何?』から。
アキ 「ところで、このパンフレットに書いてあるソリューションってなに?」
増田 「ソリューションってなんなのですかね?」
アキ 「さあ、言うならばそんなの馬鹿な客を騙すための嘘よ、嘘」
増田 「そんなこと言われたら実も蓋もないですよ」
アキ 「だってそうなんだから仕方ないでしょ。じゃあない?このパンフレットに書いてあることは全部本当のことなの?」
増田 「いえ、そうならないときもあります」
アキ 「じゃ、嘘じゃない」
(pp.83-84)
これもあるあるwwwとか地味に自分も突っ込みながら読んだ。就活中にいろんな企業のパンフレットを見たけど、いろいろな美辞麗句が載っているが、本当のところどうなんだろうなぁと思ったもので。これも、アキさんがユーザーの視点から鋭く突っ込んでいる。

本当はもっと色々紹介したいが、これは読んでからのお楽しみで。そもそも、エンジニアとは何をする人なのか?とか、どういう風にシステム開発の仕事をしているのか?、なにを武器に仕事をしているのか?、顧客満足は何か?といったことに関して、アキさんが増田さんのグチっぽい相談に的確に突っ込みながら答えを引き出している。正確には、増田さんに考えさせるように仕向け、読者自身も一緒に考えられるようになっている。それはまるでソクラテス時代の問答法みたいな感じで、アキさんはそのような役割を担っている。

この本の評価は確実に二つに分かれるだろう。この書評時点では、Amazonでは評価はまだないけど、評価のばらつきが出ると予想される。この本をダメだしする人は、たぶんこの本に示されている本質が読みきれておらず、感覚的に分かっていないか、もしくは高い意識を持つプロフェッショナルで、エンジニアの仕事に充実感を持って意欲的に働いているようなかなりデキル人だと思う。後者ならいいと思うよ。しかし、これはどうかな・・・?と思ったとき、この本質が読み取れるほどSE業の仕事とは何か?を考えたことがあるかどうかを振り返る必要があると思う。つまり、この本は、示されている内容は一見単純だが、読み手のエンジニアとしての成熟度を試すような内容と言える。それだけに、書評が難しい本でもある。

あえて突っ込む部分があるとすると、増田さんのグダグダ感は結構読んでいて疲れる。こっちも突っ込みたくなる。いや、突っ込みたくなるように著者が意図的に書いているのだろうけどね。

他にも、これは誰のために書いたものか、どういう人に読んで欲しいのか?ということがまえがきにもあとがきにも載っていなかった。これは少し説明不足な感じがする。

この話の内容は、半分は実話で半分はフィクションらしい。実際に著者とアキさんが激論を飛ばしていたこともあったようだ。こんな人がいるバーとかあったら毎日でも通っちゃうなぁ。
(;´Д`)

ページ数も少なく、ところどころにデフォルメしたイラストもあり、1ページ30秒もかからないで読める。しかし、読みやすいが本質はかなり深い。この本を読んで、自分自身のエンジニアの成熟度を計ってみるというのも一興だと思う。

この本で、『技術本(コンピュータ関連)』の書評50冊目だ。節目にふさわしい本だと思った。

読むべき人:
  • エンジニアとして行き詰まりを感じている人
  • システム開発業とは何かを考えたい人
  • ドM体質のエンジニアの人
Amazon.co.jpで『増田智明』の他の本を見る

bana1 おかげ様で上位をキープ中★  にほんブログ村 本ブログへ


August 26, 2008

ITエンジニアのための仕事を速くする9の基礎力と7のエクササイズ


ITエンジニアのための仕事を速くする9の基礎力と7のエクササイズ

キーワード:
 芦屋広太、プロジェクト、論理思考、書く技術、仕事術
仕事を速くするための方法が示されている本。以下のような目次となっている。
  1. 第1章 プロローグ 会話で理解する「仕事が速い人」の特徴
  2. 基礎編 第2章 仕事を速くする9の基礎力
  3. 実践編 第3章 仕事を速くする7のエクササイズ
  4. 第4章 「仕事を速くする」説得・交渉のテクニック
  5. 第5章 リーダーのための「仕事が速いチーム」の作り方
(目次から抜粋)
この本のコンセプトは、「仕事が速い人を作る」、「仕事が速いチームを作る」という2点のみであり、その具体的な方法が示されている。そして、以下のようなことが示されている。
 筆者は、「仕事を速くする」ために必要なのは、個人が9つの基礎スキルセットと7つの応用スキルセットを習得すること、それを実務で実践することだと結論付け、さらにチームで力を発揮するためには別途チーム向けの「ルール」が必要なのだと考えています。本書では、これら「スキルセット」、「ルール」に関するコンテツンを、今日から実務でのそのまま使えるように取り上げています。
(pp.iii)
著者も実際にシステム開発やシステム統合、遅延プロジェクトの改善などをやってきた経験があるようだ。そういった観点から、実践的な方法が示されている。

まず、仕事を速くするための9つの基礎力とは何かというと、以下のようになる。
  1. 論理的思考力
  2. 理解力
  3. 構造化力
  4. 目的達成行動力
  5. 説明力
  6. 説得力
  7. 断る力
  8. 意見通し力
  9. 文書力
正直、論理的思考力から説明力に関しては、この本でなければ得られないものがある、ということはなく、他の本のほうが分かりやすいと思った。特に、論理的思考力、構造化力に関しては、『ロジカル・シンキング』、『考える技術・書く技術―問題解決力を伸ばすピラミッド原則』のほうがはるかに濃い内容で分かりやすく、ためになったと思う。また目的達成行動力も、仕事ハック系の本を読んだほうが良いと思う。唯一他の本と違うのは、例題がシステム開発関連となっている点。そういう部分にとっつきやすい人にはいいかもしれない。

しかし、説明力、説得力、断る力、意見通し力は結構参考になるところが多かった。特になるほどと思ったのは、断る力。これは、お客さんや利害関係者に諦めてもらうための6つの方法が示されている。
  1. 相手の主張を否定せず、まず肯定し、一緒に問題を解決する雰囲気を醸す
  2. 相手のニーズ、立場、スタンスを正確に把握する
  3. 相手に諦めさせる情報を伝える
  4. 断るための情報は、自分が経験したものを使う
  5. 説得力を高めるための話法を工夫する
  6. 相手が納得するまで情報を与える
例えば、相手に諦めさせる情報を伝えるための例としては、お客さんから無理な要求をされたときは、『現状ではベストなものを提供できないので、かえってお客様に迷惑をおかけするので、そんな状態で提供するわけにはいかない』と。ポイントは自分の都合を前面に出すのではなく、相手にとってデメリットになることを前面に出す必要があるようだ。これは、かなり使えると思う。システム開発の経験上、どうしても短い納期でこうしてくれということが多々ある。そういうときは、これを使えばいいと思う。この断る力は、システム開発プロジェクト特有の内容だなと思った。

実践編として、仕事を速くする7つのエクササイズが示されている。それは以下になる。
  1. 意見を通す
  2. 根本検証
  3. 企画力
  4. クリティカルチェック
  5. 文章を短くする
  6. 文章の記号表現
  7. 結論から話す、書く
それぞれのエクササイズで、まずダメな例が示されており、その次にどうすればよいかが示されており、その後ダメな例の模範解答が示されている。この7つのエクササイズで特に勉強になったのは、根本検証に関して。これは、何かを論じるときに、以下のことを考える必要があるようだ。
  • そもそもそれは必要か
  • なぜ必要なのか
  • ないと何が問題なのか
これらを考え、その「何か」が間違いなく存在すべきであり、論じられているべきであると判断できるとき、「必要性を根本的に検証できた」ことになるとあった。具体例として、ドキュメントの整備が挙げられていた。
  • どうしてドキュメントを整備しなければならないのか?
  • そもそも、ドキュメントは必要なのか?
  • なぜ、ドキュメントがあるのか?ないとシステムは開発できないのか?
このようなことはよく自分も上司に言われる。常に『それって何のためにやるんだっけ?』や『そもそもそれは必要なんだっけ?』とか。特に『そもそも』という単語が頻出する。もう自分も完全に刷り込まれた。なので、絶対普通の会話でも『そもそも』と言ってしまうと、以前同期たちと盛り上がったことがある(笑)。それだけ常に根本を検証しろということだろう。そうじゃないと無駄な工数を使ったり手戻りを発生させてしまうので。

示されていることを全て読む必要はないと思った。『はじめに』のところで、著者自身も最初から最後まで読む必要はなく、実務をする上で必要なところだけ読むだけでよいとあったし。なので、必要に応じて必要な箇所、自分ができていない部分を読めばいい本かなと思った。自分の場合は、ある程度復習という感じで読んだ。かといて、全て満足いくレベルでできているわけではないので、できていない部分に関しては、勉強になった。

ただ一つ気になるのは、いくら著者の実体験から書かれている本だといえども、何かしらこの本を書く上や、日々の仕事で参考にしてきた書籍があるはず。それが、参考文献やお薦め書籍としてまったく示されていない。そのため、示されていることの信頼性が低下すると思った。

この本に示されていることの本質は、他の本でも代替可能だが、示されている例題などは、システム開発業特有だと思うので、自分の仕事の場合はどうかといったことを意識して読みやすいと思う。また、ITエンジニアだけに限らず、普通にプロジェクトベースで仕事をするような人も参考になる部分が多いと思われる。

読むべき人:
  • ITエンジニアの人
  • 仕事を速くしたい人
  • お客さんの無理難題を波風立てずに断りたいと思う人
Amazon.co.jpで『芦屋広太』の他の本を見る

bana1 クリックありがとうございます☆  にほんブログ村 本ブログへ


August 14, 2008

小飼弾のアルファギークに逢ってきた


小飼弾のアルファギークに逢ってきた [WEB+DB PRESS plus]

キーワード:
 小飼弾、ギーク、インタビュー、プログラマー、楽習
アルファギークであるプログラマとしての小飼弾氏のインタビュー本。以下のような目次となっている。
  1. #0 Ruby on Rails開発者 David Heinemeier Hansson
    「アーキテクト」って言葉を使ったら負け
  2. #1 (株)はてなCTO 伊藤 直也
    良いサービスを作るのに,マネジメントはやはり重要
  3. #2 Perl開発者 Larry Wall
    優れたソフトウェアも,文化を持たなければ普及しない
  4. #3 livedoor 池邉 智洋/谷口 公一/ma.la
    ネットは個人の人生に何をもたらしているか
  5. #4 Twitter Co-founder Evan Williams
    大事なのは「好き」を貫けること
  6. #5 The Seasar Project チーフコミッタ ひが やすを
    世の中の根底にあるニーズに合ったものを提供したい
  7. #6 『達人プログラマー』著者 Dave Thomas
    コーディングを続けるという情熱が重要。それ以外は取るに足りない
  8. #7 Pathtraq / Japanize 開発者 奥 一穂
    自分は,コミュニケーションの形態を考えてる。ウェブは手段
  9. #8 Mozilla Corporation / jQuery開発者 John Resig
    自分が興味を持っているものに集中し,最適化を加える
  10. #9 「Binary 2.0」「スルー力」提唱者 高林 哲
    ハッカーに一番重要なのは,「深追い」できること
  11. #10 Perl Mongers Ingy dot Net / Dave Rolsky / Jesse Vincent / C.L. Kao
    今どき正気の人はいない。大事なのは役に立つ狂気かどうか
  12. #11 『IT戦士』 天野 仁史 & こんにちはこんにちは! はまちや2
    勢い重要。脆弱性とか気にしないでシンプルにリリースすべし
  13. #12 夫婦対談. (株)はてな 近藤 淳也・令子×小飼 弾・直美
    行動を起こしたほうに情報はついてくる
  14. #-1 スペシャル対談:前編 きたみりゅうじの 小飼弾に逢ってきた
    アルファギークとSEの現実と
  15. #-2 スペシャル対談:後編 きたみりゅうじの 小飼弾に逢ってきた
    知られざる小飼弾の歴史
(目次から抜粋)
この本で、404冊目の書評となる。404といったら、HTTP 404 - Wikipedia、404で思い浮かぶ人物といったら、404 Blog Not Foundの小飼弾氏しかいないだろ、ということで、404冊目にこの本を意図的に読んだ。

内容自体はあまり言及しないでおこう。別にポイントを絞る必要もないと思う。内容の紹介などは、『はじめに−−アルファギークとは?[小飼弾のアルファギークに逢ってきた(WEB+DB PRESS plusシリーズ)]|gihyo.jp … 技術評論社』などを見ればいいし、内容自体は『連載:小飼弾のアルファギークに逢いたい♥|gihyo.jp … 技術評論社』でほぼ同じものが参照可能である。

では、この記事に何を書いておくかというと、単純に同じIT業界でプログラマー(正確にはSEに近い)として働く身として、この本を読みながら考えたこと、感じたことを示しておくことにする。ほとんど自己分析みたいな内容になると思うが。続きを読む


August 07, 2008

オンリーワンになるためのエンジニアプロ論


オンリーワンになるためのエンジニアプロ論 (開発の現場セレクションSpecial)

キーワード:
 SE編集部、IT技術者、プロ論、モノ作り、ロールモデル
IT業界を牽引するトッププレイヤーによる、エンジニアのためのプロ論。以下のような目次となっている。
  1. パート1 技術者としての誇りを胸に
  2. パート2 失敗、挫折、試練を越え
  3. パート3 新しい時代を切り開く
  4. パート4 素晴らしい仕事、魅力ある業界にするために
(目次から抜粋)
この本はITエンジニアのための専門誌『開発の現場』において、業界のリーダー、エキスパートの人のインタビュー記事などがまとまったものとなっている。IT業界のエキスパートは、以下の19名となっている。肩書きや役職は、各記事の最初のページから抜粋。
  1. 柏原彰(日本アイ・ビー・エム株式会社 IBMディスティングイッシュト・エンジニア/ITアーキテクト)
  2. 平鍋健児(株式会社チェンジビジョン 代表取締役社長)
  3. ひがやすを(株式会社 電通国際情報サービス 開発技術センター Seasar2技術開発推進グループ プロジェクトディレクタ)
  4. 漆原茂(ウルシステムズ株式会社 代表取締役社長)
  5. 小野和俊(株式会社アプレッソ 代表取締役副社長/CTO)
  6. 梅田弘之(株式会社システムインテグレータ 代表取締役社長)
  7. 羽生章洋(株式会社スターロジック 代表取締役社長/NPO法人Seasarファウンデーション理事(当時))
  8. 萩本順三(株式会社豆蔵/プロフェッショナルフェロー/技術戦略支援室 室長)
  9. 大西建児(株式会社豆蔵/ES事業部シニアコンサルタント)
  10. 山本啓二(ウルシステムズ株式会社 主席コンサルタント)
  11. 市原俊治(株式会社NTTデータ 基盤システム事業本部 オープンソース開発センタ)
  12. 鈴木雄介(フリーアーキテクト/株式会社エーティエルシステムズ チーフソフトウェアアーキテクト兼テクノロジーディレクター/稚内北里学園大学 客員助教授)
  13. 河村嘉之(オープンソースCRM株式会社 シニアコンサルタント)
  14. 近藤秀和(Lunascape株式会社 代表取締役兼CEO)
  15. 守安功(株式会社ディー・エヌ・エー 取締役ポータル・コマース事業部長)
  16. 最首英裕(株式会社イーシー・ワン 代表取締役社長)
  17. 細川努(株式会社アーキテクタス 代表取締役)
  18. 野津和也(株式会社スマートスタイル 代表取締役社長/MySQLパートナー会 会長(当時))
  19. 内野弘幸(ウイングアーク テクノロジーズ株式会社 代表取締役社長)
自分も一応IT技術者の範疇に入るので、この19人のうち何人かは知っているし、所属企業なども聞いたことがあったりする。そのうちの何人かは、独立して会社を起こしている人が結構いる。

この19人に共通していることは、IT業界での仕事に対して誇りを持っており、IT業界に対して明るい未来を期待している点だなと思った。みな、IT業界の3Kだとか7Kだと揶揄されている現状に対して危機感を持っているようだ。だからこの現状ではだめなので、何とかしようという意気込みも感じられる。また、それぞれが若い頃は必死で勉強して働いていたということも多く示されていた。

特に若い人向けに技術者の心構えみたいなものが多く示されている。何人かの主張の一部を抜粋しておく。まずは、IBMの柏原彰氏の意見。
 とにかく「ソフトウェアエンジニアリング」をしっかりと学ぶべきだと思います。それは不要と考える人もいるようで、Web上で論争になったりもしていますが、知識と経験は補完し合うもので両方必要なのは自明です。ソフトウェア開発の効率やプログラミングの得手不得手、ソフトウェアを稼動させるためのインフラ設計といった幅広い経験と、知識レベルの「ソフトウェアエンジニアリング」の両輪をうまく回していくことが重要だと確信しています。
(pp.19)
自分はソフトウェアエンジニアリングの基礎は体系的に学んだつもりだが、どうしてもインフラ回りに弱いなと思う。インフラ、基盤はどうしても遠慮してしまう。

アプレッソの小野和俊氏から会社に就職して、ミスマッチが起こったときにどうするかということに関して。
 ところで、「会社に入ってみたら自分のやりたいことと違った」と言う人がよくいます。でも、これこそチャンスなのです。肉屋をやりたいのに八百屋に入ってしまったと嘆くのではなく、その肉屋をやりたいという得意を八百屋でこそ活かすのです。八百屋で肉屋をやろうなんて人間はそうそういないはずなので、そこで自分が手を挙げて頑張れば間違いなくトップに立てます。これは詭弁ではありません。
(pp.74-75)
これはプロジェクトでも同じかなと思う。必ず自分がやりたいと思う技術領域をできるわけではない。そのときにどうするべきか?ということが、この八百屋で肉屋をするという姿勢なのだと思う。実際は難しいと思うが。

システムインテグレータの梅田弘之氏からは勉強について。
 あえて厳しいことを言いますが、「家に帰ってまでコンピュータを触りたくない」なんて言うのは、言い訳だと僕は思っています。もちろん他の仕事だったらプライベートではTVを観たりして気楽にするのもいいでしょう。でも、技術革新の著しいコンピュータ分野のプロになろうと思ったのならば、仕事だけでは十分な技術を習得することができない、と覚悟すべきです。コンピュータ技術の世界をワールドワイドの観点で見た場合、プロとして立っていこうと思ったら、まったく甘くない世界です。もしこの記事を読んでいる方が、自分はプロとして成功するんだと思うなら、家に帰ってでも勉強し続けなくてはダメなんです。
(pp.87)
これは正直耳が痛い・・・。全然家に帰ってから勉強していないなぁと。ビジネス書とか自己啓発書は読むけど、技術本をあまり読んでいない・・・。また、実際仕事以外でほとんど家でプログラミングなんてしていないし・・・。最近、それではやはりダメなのかなぁと思いつつあるので、もっと激しく勉強しようかなと思うしだいで。

この19人は、IT技術者のロールモデルとなりえる人ばかりだなと思う。そして、若い頃の働き方が語られているが、自分と同じ世代のときは激しく必死で働いていたとある。それを読むと、自分はこの人たちのようにITに入れ込んでいないのではないかなと思った。それだけ熱中していないなと。それではIT技術者として頭打ちになり、そこで限界になってしまうのかなと思った。ある意味危機感を覚えるが、それと同時に、そこまで自分がITに関心を持てていないことに失望感みたいなものも感じる。そのときはそのときで、方向転換をするべきなのかなと思ったりもするが、まだ入社して3年もたっていないので、もっと激しく勉強して仕事に熱中してみれば、何かが変わるのかもしれないということを期待して頑張ろうと思った。

若手IT技術者は読んで置いて損はない一冊だと思う。IT技術者として生きていく覚悟みたいなものを感じられると思う。逆に、このような考え方にまったく賛同できなければ、IT技術者はあきらめたほうがいいと思う。そんなことを考えさせられる本。

読むべき人:
  • 入社3年以内のIT技術者の人
  • IT業界に就職しようとしている大学生の人
  • IT技術者としてプロを目指したい人
Amazon.co.jpで『プロ論』の関連書籍を見る

にほんブログ村 本ブログへ bana1 ランキングへ


July 30, 2008

Visual Basic2005逆引きクイックリファレンス


Visual Basic2005逆引きクイックリファレンス―Windows XP/Vista対応

キーワード:
 きたみあきこ、VB、リファレンス、逆引き、サンプル集
Visual Basic 2005のテクニック集。以下のような目次となっている。
  1. Chapter1 Visual Basic 2005の基礎知識
  2. Chapter2 文法の基礎知識
  3. Chapter3 エラー処理とデバッグ
  4. Chapter4 コントロールとイベントの基礎
  5. Chapter5 基本のコントロール
  6. Chapter6 その他の便利なコントロール
  7. Chapter7 フォームとプロジェクト
  8. Chapter8 文字列・数値・日付と時刻
  9. Chapter9 プロシージャとクラス
  10. Chapter10 ファイル操作
  11. Chapter11 データベースの操作
  12. Chapter12 グラフィックスとマルチメディア
  13. Chapter13 印刷
  14. Chapter14 システム・ネットワーク・プロセス
  15. Chapter15 アプリケーションの制御と仕上げ
(目次から抜粋)
Visual Basic 2005でWindowsアプリケーションを作成するためのテクニックが346示されている。この本の特徴は以下のようになっている。
  • 文法の基礎から、オブジェクト指向の概念、コントロールの使い方、データベース操作、グラフィック操作、印刷、ネットワークとプログラミングのテクニックを幅広く紹介している
  • やりたいことを逆引きできるように、各Q(Question)に「○○するには」というタイトルがつけられている
  • それぞれのテクニックは単純なサンプルコードが示されている
また、各Qのページ構成は以下のようになっている。
  • Q番号:全項目の通し番号
  • Q(Question):VB2005を利用する際に生じるやりたいことや疑問を取り上げている
  • 書式・キーワード:そのQで解説しているVB2005の書式やキーワードを示している
  • 本文:取り上げている事項について説明している
  • ページツメ:各Chapterのタイトルが入っている
  • サンプルコード:具体的なサンプルコードが示されている
  • 実行結果:サンプルコードを実行した結果を図示している
  • メモ:そのQの内容の補足が示されている
具体的なQをいくつか列挙。
  • Visual Basic 2005とは
  • イベントハンドラを作成するには
  • 変数の有効範囲を指定するには
  • メッセージボックスを表示するには
  • Try Catchステートメントで例外処理を行うには
  • マウスポインタの形を変更するには
  • リストボックスにアイテムを追加するには
  • カレンダーのクリックで日付を入力するには
  • フォームのタイトルバーの文字列を設定するには
  • 2つ目のフォームを開くには
  • 数値を指定した書式の文字列に変換するには
  • Subプロシージャを作成するには
  • クラスのメンバを定義するには
  • テキストファイルに一括して書き込むには
  • データベースからデータセットにデータを読み込むには
  • ボタンのクリックで図形を描画するには
  • [印刷]ダイアログボックスを表示して印刷するには
  • TCP/IPでサーバーとメッセージを送受信するには
  • バックグラウンド処理の進捗を表示するには
このようなQが346も示されている。

本屋でVBのリファレンス本をいくつか見比べてみて、これを選択した。この本が一番見やすい構成になっているかなと思った。ページ内のメリハリがあり、またサンプルの多さもよいと思う。画面イメージも載っているのでわかりやすい。

ただよろしくないのは、内容に間違いがある点。サポートページには正誤表が載っていないが、いくつか発見した。153〜155pのリストボックスの書式・キーワード部分に間違いがある。本文のサンプルとは違っていて、書式の通りにはならない。一つだけ間違いを示しておくと、Q118の『リストボックスのアイテムを選択するには』で、書式では
リストボックス.Items.SelectedItem = アイテム (アイテムを指定)
(pp.155)
となっているが、本文のサンプルには
Private Sub Button1_Click(ByVal sender As System.Object, _
  ByVal e As System.EventArgs) Handles Button1.Click
  ListBox1.SelectedIndex = 3 ・・・・1
  ListBox2.SelectedItem = "総務部" ・・・・2

End Sub
(pp.155)
となっている。2番の部分が書式と違っており、実際に試してみると、書式の『Items』が要らない。技術本でこのような間違いがあると、信頼性が低下する。しっかり校正していないのがよくわかる。この本はわかりやすいだけに、少し残念な気もする。

全体的にVBで必要なことが網羅されているので、コーディング中にあれどうやるんだっけ?というときにとても重宝する。いちいちググったりするよりもこっちのほうがよいときもある。

VBで本格的にアプリケーションを作るときに、手元に一冊あって損はないと思う。

読むべき人:
  • VBのリファレンス集が欲しい人
  • フォームなどのプロパティ値のサンプルが欲しい人
  • わかりやすいテクニック集を求めている人
Amazon.co.jpで『Visual Basic 2005』の関連書籍を見る

にほんブログ村 本ブログへ bana1 ランキングへ


July 16, 2008

3時間で「専門家」になる私の方法


3時間で「専門家」になる私の方法

キーワード:
 佐々木俊尚、情報収集、ネット、クオリア、セレンディピティ
インターネット時代の情報収集術が示されている本。以下のような目次となっている。
  1. 第1章 激変した「情報をめぐる環境」
  2. 第2章 新聞記者は無意識に「マトリックス」を描く
  3. 第3章 クオリアを身につけよう
  4. 第4章 実践・3時間で専門家になる
  5. 第5章 ニューロン型情報収集のノウハウ
  6. 第6章 セレンディピティを実現する
(目次から抜粋)
インターネットを駆使して、3時間で専門家並の知識を手に入れる方法が示されている。本書が目的としているのは、インターネットの情報の海から膨大な情報をうまく拾い上げ、自分の知らなかった分野のことであっても専門家に匹敵するほどの知見を取り込み、立派な企画書や資料、論文を作成できるようにするというものらしい。情報収集術自体は、自分も既にある程度やっていることが示されていて、新規性はあまりなかったかなと思う。しかし、著者の新聞記者時代のマトリックスを使用して、常に俯瞰図を作って仕事を進める点などはなるほどと思った。

以下、簡単に自分が参考になった部分を列挙。
  • 情報がインフレしている状態でわれわれがやるべきことは「膨大な量の情報の中から、いかに的確に情報を選別し、他を捨て去るか」
  • マトリックスを描くということは、その分野の全体像を把握するということ
  • 検索結果の見出しを並べ、その本文も拾い読みし、その行間にある雰囲気をすくい上げることがインターネット時代のクオリアの本質になる
  • 情報収集時には、「どんどディープに、しかし領域も少しづつ狭めて」を意識する
  • ブログは「人々が特定の分野のことについて、どのように感じたり、考えたりしているのか」をダイレクトに知ることができる貴重なツール
  • 2ちゃんねるは人々の心情の吐露や業界の濃い事情が分かるので、非常に貴重な情報源
  • 検索エンジンで情報収集をしていると、偶然思いもよらなかった有用ページに出会ったりするということがあり、それこそがセレンディピティとなる
  • はてなブックマークはセレンディピティを実現するサービスとしてきわめて有用
  • ブログのエントリーは、ステレオタイプから脱却し、思いもよらなかった新たな視点を獲得し、その視点によって世界の見方が突如変わってくるというセレンディピティを体現している
  • セレンディピティによって、わたしたちは「情報のタコツボ」に陥ることなく知見の幅を広げていくことができる
  • クオリアによって世界の成り立ちを常に自分自身の中に感性的に受容していくことができる
また、情報収集時には以下の4つのインターネットのソースを順番に当たればよいらしい。
  1. 新聞記事・雑誌記事などオフィシャルなデータベース
  2. 一般のウェブサイト
  3. 個人や企業のブログ
  4. 2ちゃんねるなどネット掲示板の書き込み
この順番である理由は、自分のまったく知らない分野であれば、情報に対する真贋を見きわめるリテラシーが身についていないからとある。また、リテラシーが身についていないうちからディープな情報を仕入れてもその有用性が分からないからとあった。なるほどなと思った。

特に『少子高齢化』をキーワードに、実際に情報収集の手順が示されているのが参考になると思う。

インターネット時代の情報収集は、慣れると便利だけど、慣れないうちは情報の海におぼれることになるなと思った。自分は、ストレングスファインダーの強みで、『収集』と『分析』があるので、ネット上の情報収集もかなり得意なほうかなと思う。特に2ちゃんねるを有効活用しているほうかなと思う。2ちゃんにいけば、自分の知りたい情報がかならずまとめサイトや初心者スレにまとまっているから、最初にそのスレに当たることが多い。

情報収集能力を身につけたい人はぜひ読んだほうがよいと思われる。

読むべき人:
  • ビジネス企画を考えたい人
  • 論文やレポートの材料をうまく見つけたい人
  • 2ちゃんねるはゴミ情報しかないと思っている人
Amazon.co.jpで『佐々木俊尚』の他の作品を見る

にほんブログ村 本ブログへ bana1 ランキングへ


June 22, 2008

ひと目でわかるMicrosoft Visual Basic 2005アプリケーション開発入門 (マイクロソフト公式解説書)


ひと目でわかるMicrosoft Visual Basic 2005アプリケーション開発入門 (マイクロソフト公式解説書)

キーワード:
 上岡勇人、Visual Studio 2005、VB.NET、入門書、公式解説書
Visual Basic 2005のマイクロソフト公式解説書。以下のような目次となっている。
  1. 第1章 統合開発環境の使い方
  2. 第2章 時計とタイマの作成
  3. 第3章 テキストエディタの作成
  4. 第4章 テキストファイルの読み書きの実装
  5. 第5章 印刷機能の実装
  6. 第6章 検索/置換機能の実装
  7. 第7章 ツールバーの仕上げ
  8. 第8章 カレンダーの作成
  9. 第9章 日誌の作成
  10. 第10章 画像ファイルの操作
  11. 第11章 HTMLファイルでの出力
  12. 第12章 Webブラウザの作成
  13. 第13章 アプリケーションの仕上げ
(目次から抜粋)
Visual Basic 2005の入門的な内容となっていて、サンプルプログラムとして、テキストエディタ、カレンダーと連動した文書と画像が記録できる日誌、Webブラウザをひとつにまとめたアプリケーションが示されている。CD-ROMつき。『はじめに』でこの本の特徴が以下のように示されている。
  • 操作しながら学習できる
  • .NET Frameworkのさまざまなクラスを利用
  • さまざまなユーザーインタフェースを紹介
  • よく使われるテクニックをひとつのアプリケーションに網羅
マイクロソフトの公式解説書は結構読みやすい内容だなと思う。ページ内に文字量が多すぎず、図と文章のバランスがよいのでかなりわかりやすい。ページの中に示されている、補足情報としてのヒントやコラムが特に参考になる。それ以外は、サンプルアプリケーションの作成手順が示されている。

各章のはじめに『この章で学習する内容と身に付くテクニック』というものが示されている。例えば、2章は以下のようになる。
  • フォームデザイナでフォームにコントロールを追加してプロパティを設定する操作
  • Timerコントロールとイベントプロシージャの設定
  • コードエディタでプロパティやメソッドを使ったプログラミング方法
  • 日付や時刻を扱うDateTimeクラスの基本的な機能
  • 変数やIfステートメントを使ってアラームタイマを実現する方法
  • プログラムが起動したときに実行されるフォームのLoadイベントとプロシージャの使い方
  • Buttonコントロールでボタンをクリックしたときの動作を実現する方法
  • メッセージを表示する方法
  • 数値と文字の基本的なデータ型と日付型の使い方とデータ型を変換する方法
  • ステータスバーとプログレスバーの使い方
  • 独自のダイアログボックスを作成してフォームとやり取りする方法
    (pp.18)
こういうような構造を先に示してくれるのは、読む側にとってとても有益だと思う。技術書を最初から最後まで読むという人以外は、このような内容紹介を先に読んで、自分が知りたいところだけを読んでいけばいいからね。

Visual Studio2005からは、フォームザデザイナで設定した内容は、Form1.Designer.vbというファイルに保存されているらしい。内容としては、Form1ならば、Form1というクラスの定義が保存されているようだ。これは知らなかった。最近Visual Studio2005をいじってみる機会があり、Form1.Designer.vbはなんだろと思っていたので、勉強になった。また、このコードをコードエディタで編集するとアプリケーションとして成り立たなくなってしまうので、うっかり変更しないように注意しろとあったので、参照するだけにしよう。

入門書レベルの内容で、サンプルプログラムを作って概要を理解するという内容なので、クラスやメソッド、プロパティの辞書的な使い方にはあまり期待できない。それはMSDNのヘルプや他の辞書的なサンプル集などの本を読んだほうがよいと思う。

統合開発環境を使用したプログラミングは、開発環境の学習からしなければならないといったデメリットがあるが、慣れてしまえば便利なものだなと思う。また、VBのようにGUIアプリケーションを作ると、機能が目に見えやすいので、バッチプログラムとかよりも何かを作っているなという達成感のようなものを得られると思った。

暇つぶしにVBで何かサンプルプログラムでも作ってみようかなと思った。

読むべき人:
  • Visual Basic 2005の概要を知りたい人
  • サンプルプログラムを作ってみたい人
  • マイクロソフトの公式解説書が好きな人
Amazon.co.jpで『Visual Basic』の関連書籍を見る

にほんブログ村 本ブログへ bana1 ランキングへ


June 16, 2008

だれも書かなかったVisual Basicプログラミング入門


だれも書かなかったVisual Basicプログラミング入門―Visual Studio2003準拠 だれよりも効率よく開発するために

キーワード:
 西田雅昭、VB.NET、Visual Studio2003、入門書、アラーム時計
Visual Basicの入門書。以下のような目次となっている。
  1. 第1章 Visual Basic.NET入門
  2. 第2章 プログラムの基礎技術
  3. 第3章 コーディングが楽しくなる操作の秘訣
  4. 第4章 クラスとオブジェクトを理解する
  5. 第5章 クラスを作ってみる
  6. 第6章 データベース処理の初歩
  7. 第7章 コントロール
(目次から抜粋)
Visual Basicの入門書で、Visual Stuidio .NET2003までの対応となっている。この本の特徴をはじめにの部分から抜粋。
本書は,主として,ある程度のプログラミングの経験のある方を対象として,Visual Basic 6.0(本書ではVB6と略記)の世界からVB7の世界に,たやすく移行できることを目指しています.しかも,生産性の高い,読みやすく,訂正が簡単で,しかもユーザにやさしいアプリケーションを生産する手法について,詳しく説明したつもりです.
(はじめにから抜粋)
技術書っぽく、句点がピリオド、読点がカンマになっている。

第1章ではいきなり文法の説明からするのではなく、サンプルコードとしてアラーム時計の作成方法が示されている。これは実際にコードをなぞっていくと、アラーム時計が作れるようだ。

第2章では、文法の話で、変数の使い方、プロシージャ、命名規則、データ型などが示されている。

第3章はIDEであるVisual Studioの便利な使い方が示されている。普通のVisual Basicの入門書は、Visual Studioの使い方まで示されていないような気がする。なので、この本は他の本とちょっと違う。

第4章は、オブジェクトやクラスの定義と継承、名前空間、参照設定などについて示されている。

第5章は、クラスのサンプルとコレクションについて示されている。

第6章では、主にADO.NETの使い方について示されている。

第7章では、MessageBox、ラベル、テキストボックス、データグリッドのプロパティなどが示されている。

このように、プログラミングをやったことがある人を対象としている内容だが、初心者でも体系的に学習できるようになっている。

デバッグの使い方まで示されているのはVB初心者にとってはかなり重宝するのではないかと思う。VBでつまづくのは、エラーが出たときのデバッグ方法だと思われるので。

また、コピーアンドペーストを多用するとバグが減る、配列の値渡しに注意、特定のキー入力をできなくする方法といったTipsも多く示されている。

著者の文体は、読者に語りかけているような内容なので、プログラミング本にありがちな無機質な感じがあまりなく、分かりやすい内容となっている。また、全体的に網羅されており、結構基本的なことやVBプログラミングで気をつけなければならないことまで示されているので、勉強になった。

ただ、現状のVBの最新バージョンはVisual Basic 2008となっているので、本書の対象バージョンではもう古くなっている。Visual Studioも同様2008が最新版となる。この本を読む場合は、そのへんの注意が必要となる。

今回は、完全にVBの復習として読んだ。

読むべき人:
  • Visual Basicの基本を学習したい人
  • Visual Studioの基本的な使い方を知りたい人
  • アラーム時計を作ってみたい人
Amazon.co.jpで『Visual Basic』の関連書籍を見る

にほんブログ村 本ブログへ bana1 ランキングへ


June 09, 2008

無料ブログSEOバイブル


無料ブログSEOバイブル

キーワード:
 中嶋茂夫、SEO、Youtube、ポッドキャスト、マーケティング
無料ブログを使ってアクセス数をアップし、アフィリエイトで収益を上げるための方法が示されている本。以下のような目次となっている。
  1. Part1 「無料サービスは集客に使えない」の嘘、無料サービス徹底活用テクニック
  2. Part2 無料ブログSEO対策テクニック
  3. Part3 YouTube&ポッドキャスト/ビデオポッドキャスト対策テクニック
  4. Part4 メールマガジンとSNSを使った集客テクニック
(目次から抜粋)
この本は、無料ブログを使用し、運営サイトの集客を伸ばし、成約率をアップさせるための方法が示されている。特に自分が知らなかったことや、これはやってみようと思ったもののポイントを列挙する。
  • YouTubeを利用し、YouTubeからアクセス数を増やす
  • iTunesのポッドキャストに動画などを置き、そこからブログのアクセス数を稼ぐ
  • 検索エンジンは、ドメインあたりの総ページ数が多い、個々のページにオリジナリティがあるサイトを評価する
  • フェレットの月間検索回数のおよそ600分の1から300分の1の回数が1日あたりのアクセス数になる
  • 無料ブログにあるコメント、トラックバック、カレンダーなどの機能はSEO的に不利になるので削除する
  • 個別記事のtitleタグはブログタイトル:個別記事タイトルとするのではなく、個別記事タイトル:ブログタイトルとするほうがよい
  • ソーシャルブックマークなどSMO(Social Media Optimization)で、アクセス数を増やす
  • livedoorクリップを使って自分のブックマーク情報を発信して、そこからアクセス数を増やす
大体こんなところか。300ページにも渡る分量なので、既知の部分も多かったし、知らないことも結構あった。勉強になった。

アフィリエイトで儲けるには、SEO対策をする前に以下の手順を考えることが重要らしい。
  1. 誰に向けて情報発信をするのか?
  2. 訪問者に伝えたいことは何か?
  3. 訪問者に情報を伝えたあとにどうしたいのか?
  4. 3のアクションをとるための具体案を作る
  5. 商品、サービスの成約につなげる
    (pp.232)
これは、普通にビジネスにおいてのマーケティングと同じだなと思った。アフィリエイトで儲けようと思ったら、ブログを作る前にかなり考えて、自分なりに調べたりする必要があると思った。そのため、この書評ブログのように、そもそもアフィリエイトを主目的にしていないようでは、儲からないはずだと思った。テーマを絞ることが重要だとあったので、この書評ブログのように拡散しているようではだめなようだ。

そして、SEO対策の手順として、以下のように示されている。
  1. 販売するサービス/商品、ターゲットを決定する
  2. 適切なキーワードを選択する
  3. 運営サイトの順位のチェックと競合サイトを調査する
  4. サイトの修正とコンテンツの修正/追加をする
  5. 被リンク獲得のために関連キーワードにもとづいた複数のブログを構築する
  6. 修正した結果を評価する
  7. 1から6を繰り返す
    (pp.232)
検索結果で1位を獲得することではなく、あくまで利益を上げるためとあった。なるほどなと思った。

他にも基本的な無料ブログの特徴や、CSSの基本、Livedoorブログの独自タグ、サイドメニュー、htmlの最適化など幅広く載っていた。各ブログの場合具体的にどのように設定するかということまで載っている。初めてSEO対策を考えるという人には、よい内容だと思う。

ただ、ページ内に図や写真が多く載っているが、逆にそれらがわかりづらいものとなっている部分がある。単純な箇条書きで良い内容を、わざわざブラウザの絵の中に横に並列にしているのは、正直わかりにくい。ページ構成があまりいけていない。そのため、速読するときに、ページ内の一番重要な部分どこか?ということがつかみにくかった。どちらかというと、じっくり読むべきなのだろうけど。

YouTubeやポッドキャストを利用するとよいとあったが、そもそもこの書評ブログに合う動画コンテンツなどないに等しいので、自分の場合は使えないかなと思った。

とりあえず、自分自身の書評ブログの戦略としては、記事数をもっと増やすことだろうか。あとは地道に相互リンクを増やすとかしようかな。

アフィリエイトで儲けるというのは、やはりマーケティングの勉強になるなと思った。ネットで儲けたい人は読んだほうがいいと思われる。

読むべき人:
  • アフィリエイトで儲けたい人
  • ブログのアクセス数をアップさせたい人
  • YouTube、ポッドキャストを有効利用したい人
Amazon.co.jpで『SEO』の関連書籍を見る

にほんブログ村 本ブログへ 役に立ったらクリック☆  bana1


May 27, 2008

アフィリエイトSEO対策テクニック


アフィリエイトSEO対策テクニック

キーワード:
 矢代竜也、アフィリエイト、SEO、テクニック、マーケティング
アフィリエイトで儲けるためのノウハウが書いてある本。以下のような目次となっている。
  1. アフィリエイターに必要なSEO知識って何だ!?
  2. PART 1 アフィリエイト入門
    1. CHAPTER 1 アフィリエイトの最新事情
    2. CHAPTER 2 ブログではじめるアフィリエイト
  3. PART 2 アフィリエイト基本編
    1. CHAPTER 3 無料ブログサービスからMovable Typeへステップアップ
    2. CHAPTER 4 儲かるアフィリエイトサイトのテーマとキーワードの選び方
    3. CHAPTER 5 賢いアフィリエイトサイトサービスプロバイダーの選び方とコンテンツ作成手法
  4. PART 3 アフィリエイトSEO編
    1. CHAPTER 6 アフィリエイトサイトのアクセス解析
    2. CHAPTER 6 アフィリエイトSEO / SEMテクニック
    3. CHAPTER 7 個別ページにもSEO対策をする
    (pp.4-8)
著者の経歴がまず特殊で、大学時代に就職活動をしていたが、どこからも内定を取れず、1年ニートをしながらアフィリエイトで月収100万円稼げるようになったようだ。そして、それまでのアフィリエイトの失敗経験を基にどのようにしたら売れるかが示されている。以下、ポイントを絞って内容を列挙。

最初の章の『アフィリエイターに必要なSEO知識って何だ!?』は著者とカリスマSEOコンサルタントで、SEO本の著作がある鈴木将司氏との対談が載っている。面白かったのは、今後ネット関連企業の採用条件にアフィリエイト経験があるかどうかが重要な判断になるらしい。曰く、アフィリエイトサイトで成功するということは、営業/経営センスがあるということの証明になるかららしい。なるほどと思った。

PART1の部分は実際に無料ブログを使ってアフィリエイトをはじめるところから、アクセス数アップの基本的な方法が示されている。図解があるので、初心者にも分かりやすい。

この本で特に重要なのはCHAPTER4と5になる。以下エッセンスを抜粋しておく。
  • アフィリエイトは、「コツ」さえ掴んでしまえば、誰でも稼げる
  • まずはユーザーが集まるサイトを作る
  • 稼げるキーワードをチェックする
  • 競合が少ない市場を探してそこで勝負する
  • 経験に基く文章を書く
  • ユーザーに納得してもらう文章を書く
特に重要なコンセプトは、ブログサイトなどを『作った』から『稼げる』のではなく、『稼げる』市場があるから『作る』ということになる。つまり徹底的にアフィリエイトで儲かりそうなテーマやキーワードを調査してからそれに見合ったサイトを作る必要があると示されている。これは今までの自分にはまったくない考え方だなと思った。そして、サイト作成の前に以下のことを考える必要があるようだ。
  1. 競争相手の調査
  2. キャッシュポイントの確認
  3. サイトテーマの設定
  4. キーワードの設定
ここまでやるからこそアフィリエイトで収益を得ることができるようだ。

実際に著者の作ったサイトが具体例として説明されている。『住宅ローンの基礎知識を1から学ぶ!』というサイトで、住宅ローンというねらい目キーワードを設定して、実際にこのサイトで毎月10万円ほどの収入があるようだ。ポイントは、キーワードアドバイスツールなどを使用し、ねらい目キーワードを探し出し、ネットユーザーが望むような情報を提供することらしい。また、住宅ローンなどのアフィリエイト料は高額で、しかも住宅ローン情報は頻繁に更新する必要がないので、1度ある程度作ってしまえば、あとはコンスタントにアフィリエイト料が稼げるらしい。これはなるほどと思った。

また、ユーザーがコンテンツに納得してもらうような文章を書くだけでアフィリエイト料が2倍も違うということが示されていた。これはなるほどと思った。ただオススメと示すのではなく、実体験を示し、客観的によいところも悪いところも示すとよいらしい。これはとても勉強になった。

なんというか、この本はWebのマーケティングの本という感じに近い。いくらネットで人と対面なしでアフィリエイト料で儲けるとはいえ、サイト訪問者であるお客さんを第一に考えなければならないのだなということがよくわかった。つまり、いかに多くお客さんを呼び込めるか、そして競合他社が少ない場所で商売し、訪問してくれたお客さんにいかに納得してもらって商品なりサービスを買ってもらうかがしっかり示されている。これはどの商売やビジネスでも本質は変わらないのではないかと思った。なので冒頭の対談で、アフィリエイト経験が営業と経営センスを磨くことになるということになるのだろうと思った。

また、著者の失敗経験が載っているのもよい。どこでつまづいて、その後どう改善したら儲かりだしたかという部分も示されていて、とても勉強になった。

一点あまりよろしくないなと思うのは、本のタイトルにある『SEO』という部分。SEOに関してはHTMLのstrongやh1などのタグの使用の推奨や、Yahooカテゴリに登録する、ページランクの高いサイトからリンクをしてもらうなど、初歩的なことしか書いてない。分量もそんなに多いものでもないし、ネットで十分手に入る情報が多い。この本のメインはSEOではなく、アフィリエイトマーケティングなので、マーケティング的な意味合いを持たせたほうがよかったのではないかと思う。まぁ、派手な表紙のSEO系の内容の本が、同じ出版社からいくつも出でいるからしょうがないのだろうけど。

アフィリエイトといえど、サイト訪問者の立場に立って情報を提供するということが重要だとわかった。ちょっと自分のブログを見直す必要があると思った。儲け方の本質が示されているので、買いの本だと思った。

ちなみに、著者が就活に失敗し、ニートになった後にアフィリエイトなどで儲けたという話は、『親より稼ぐネオニート―「脱・雇用」時代の若者たち』に詳しく書かれている。企業が雇ってくれないなら、自分でネットを武器に年収1000万円以上を達成し、有限会社まで作った過程が示されている。これを読んでもよいと思われる。

読むべき人:
  • アフィリエイトで儲からない人
  • ブログのアクセス数があまりあがらない人
  • ネットのマーケティングについて知りたい人
Amazon.co.jpで『アフィリエイト』の関連書籍を見る

にほんブログ村 本ブログへ 役に立ったらクリック☆  bana1


May 25, 2008

HTML&スタイルシートレイアウトブック 改訂版


HTML&スタイルシートレイアウトブック 改訂版

キーワード:
 外間かおり、HTML、CSS、段組、レイアウト
HMTLとCSSについて、ウェブページのレイアウトに特化した本。以下のような目次となっている。
  1. 1段組の基本的なレイアウト
  2. 1段組レイアウトの応用
  3. トップページのデザイン
  4. 左揃え2段組(固定&リキッド)
  5. 中央揃え2段組(固定&リキッド)
  6. 両側サイドバー3段組(固定&リキッド)
  7. 両サイドバー中央揃え3段組(固定&リキッド)
  8. サイドバーの装飾(付箋・ボタン・タブ・ボーダー)
  9. メインを2段組に
  10. リンク&パーツデザイン
このブログのデザインを変更するときに、CSSについて知らないから買って読んでみた。結論から言えば、この本が直接役に立たなかったような気もする。この本のよいところ、あまりよくないところを示しておく。

よいところは、基本的なWebページの1段組のからだんだんと2段組、3段組と前のページの内容をどんどん発展させていく形になっているので、一つ一つを実践していくことで、CSSによるWebページのレイアウトを学べること。この本で、巷のウェブページの大体の構成は学べると思う。画像ファイルを利用したナビゲーションバーの作り方などは、自分はまったく知らなかったので勉強になった。また、前頁カラーなので見やすい。

あまりよろしくないところは以下になる。
  • 記述ミスがある
  • CSSの基本的な概要の説明がない
  • 文章にインデントがない
この三つか。記述ミスは、CSSの閉じ括弧がないところがあった。そいうのは、技術本としては評価が下がる要因になる。自分が見つけたのは一箇所だけだが。

次に、CSSの基本的な概要説明がないのは、たぶん想定読者は、CSSの基礎知識がある人だからだと思われる。とはいえ、優良な本の場合は、最初方のページでCSSの基本構成くらいは説明される。この本では、CSSの基本であるセレクタに関しては、コラムで1ページに書いてあるだけ。正直これだけではわかりにくいので、ネットで検索して概要をつかんだ。

もうひとつあまりよろしくないのは、改行して文意が変わるときに段落になるのだが、その段落の最初の文字がインデントされていない。これは正直読みにくい。特に速読をして全体を把握しようとするとなると、トピックセンテンスがつかみづらい。これはあまりよろしくない。

この本でレイアウトの作り方は学べたが、基本的なことはほとんどネットたよりだった。この書評ブログのデザインを変えるときに、あまり有効利用できなかったかな。有効なウェブサービスを使ったこともあるし。しかし、ウェブページの構成を考えるときには有効かもしれない。特に自分はブログの3段組に関して特に知りたかったので、その部分は満たされたと思う。

この本は、CSSのクラス指定やID指定など基本的なことを理解している人向けだと思う。CSSについてまったくわからない人には有効活用するのは難しいと思われる。

読むべき人:
  • ブログのレイアウトを変更したい人
  • 3段組のウェブページを作りたい人
  • ウェブデザイナーの人
Amazon.co.jpで『CSS』の関連書籍を見る

にほんブログ村 本ブログへ 役に立ったらクリック☆  bana1


May 20, 2008

生産管理・原価管理システムのためのデータモデリング


生産管理・原価管理システムのためのデータモデリング

キーワード:
 渡辺幸三、生産管理、原価管理、データモデリング、DB設計
生産管理の諸問題をデータベースの設計の問題として解説している本。以下のような目次になっている。
  1. データモデリング入門
    1. データベースとデータモデル
    2. エンティティ関連と正規化
    3. システム設計に関する知識
  2. 生産管理システムのデータモデル
    1. 部品表と肯定表
    2. 未来を見通す在庫システム
    3. 入出荷と製造
    4. 月次計画と原価計算
自分が実際に生産管理や原価管理システムを作ったことがあるわけではないので、細かいところのよしあしは判断できないが、勉強になった部分を示しておく。

2章の正規化のところでは、第五正規形まで6段階まで示されている。一応各正規形のポイントを示しておく。
第n正規形正規形ポイント
第一正規形エンティティ内にデータモデリングが明示的に扱う以外のデータ構造を存在させない
第二正規形識別子の一部から属性項目への関数従属性の排除
第三正規形属性項目同士の関数従属性の排除
ボイス・コッド正規形属性項目から識別子の一部への関数従属性の排除
第四正規形無意味なドメインを規定する無意味な識別子の除去
第五正規形あるべきドメインを規定するあるべき識別子を追加
ここまでやって正規形が完全なものになる。一般的なテーブルの正規形の解説では第三正規形までで十分とあるが、著者によればそれは根拠がなく、開発・保守しやすいデータ・ベースシステムにしたいのなら、少なくとも論理モデルの段階では「識別子全体から属性項目に対するもの以外の関数従属性」はすべて排除されなければならないとある。なるほどと思った。また、正規形を実際に行うには、以下の3つのルールを覚えておけばよいとある。
  • ルール1.入れ子構造の解消
     エンティティ内のデータ項目の繰り返し構造やデータ項目内の内部構造は解消されなければならない。
  • ルール2.不要な関数従属性の排除
     エンティティの識別子全体からそれぞれの属性項目に対するもの以外の関数従属性は排除されなければならない。
  • ルール3.有効な識別子の網羅
     すべての有効な識別子のみが一覧され、それぞれの識別子毎にエンティティが最低1個は用意されなければならない。
    (pp.55)
これら3つのルールに従えば、完全正規形になるようだ。

データモデリングの具体例だけでなく、生産管理や原価管理の業務についても詳しく解説が載っている。例えば、在庫管理で使われる「ロット」や生産管理で使われる「カンバン」、原価計算など。今までロットはただの製造単位のことだと思って詳しく理解していなかったけど、ロットを使用することによって、不良品が発生したときに影響範囲を限定できるというメリットがあるようだ。勉強になった。

あとがきのほうで新人技術者は「上流へ向かって常に匍匐(ほふく)前進することを忘れるな」とある。これは新技術ばかりを追従していては疲弊してしまい、35歳定年説を実現してしまうことになる。しかし、上流工程の技術は、世の中の流行の変化に影響を受けにくい核の技術であるからと示されている。以下、その部分を抜粋。
 とはいえ、上流工程向けの勉強をし続けることは「技術者の生き残りの戦略」としてはすぐれています。なぜならそれらの学びは「技術者の発展や流行の切り替わりにともなって消費されるもの」ではなく、「将来に向けて蓄積されるもの」だからです。また、匍匐前進のようなゆっくりとしたペースでもかまいません。とにかく上流へ進んでいると意識できるだけで、いざ上流工程を担当することになったときの抵抗や恐れが軽減されるでしょう。
(pp.302)
また、下流工程の技術も軽視してはいけないとあった。このような業務システムを作るエンジニアを続けるのであれば、だんだん上流を目指すべきなのだろうなと思った。けれど、自分は下流を重点的にやって、技術を極めるというのもありかなと思う。その技術が廃れていったらどうしようもないが・・・。

どちらかというとこれは入門書というよりも、生産管理、原価管理の業務知識を踏まえたモデリングの具体例が示された教科書だと思う。なので、一般的なデータベースのモデリングを初歩から学びたい場合には適さないと思う。本当に現場で生産管理や原価管理システムを作る必要性がある人にとっては、すぐに役立つだろうと思われる。Amazonでのレビューの評価はかなり高い。

同じ著者のより初心者向けの本で『業務別データベース設計のためのデータモデリング入門』があるので、先にこっちを読んでおくべきだったかなと思った。

読むべき人:
  • 生産管理システムの設計者
  • 原価管理システムの設計者
  • 生産管理、原価管理の業務知識を身につけたい人
Amazon.co.jpで『データモデリング』の関連書籍を見る

にほんブログ村 本ブログへ bana1 ランキングへ


May 15, 2008

新入社員が知っておくべきパソコン文書作成のオキテ


新入社員が知っておくべきパソコン文書作成のオキテ

キーワード:
 山田祥平、パソコン、MS Office、文書作成、ルール
新入社員向けのWord、Excel、PowerPointの正しい使い方が示された本。以下のような目次になっている。
  1. 誰も教えてくれない仕事に通用する文書作成のオキテ
  2. あなたの生産性をアップさせるオキテ
  3. 上司や仲間に喜ばれる文書作成のオキテ
  4. ケアレスミスを少なくするためのオキテ
  5. 見栄えのする文書に仕上げるためのオキテ
  6. 何度でも使いまわせる文書作成のオキテ
  7. 評価されるビジネスマンになるためのオキテ
ビジネス文書を自己流で作成していては、チームで作成しなければならない成果物の更新や修正に影響を与えてしまうことがある。例えば、インデントをスペースで設定していたり、パワポでテキストボックスを多用していたり更新履歴がなかったり。そういう文書を他の人が修正した場合に、文書の見栄えが悪くなるどころか、修正時間の浪費になってしまうので、そうならないように正しいOfficeアプリケーションの使い方を新人のうちにマスターしましょうという内容。さすがに自分はもう新人ではないので、示されていることの8割がたは既知だった。内容を見ずに買ってみた本だけど、一応復習のために読んでみた。

一応参考になったものを示しておく。
  • 上付き文字
  • セルの配置
  • 変更履歴の記録/[変更履歴]ウィンドウ/コメントの挿入
  • ドキュメント内のすべてのコメントを削除
  • 集計
  • 連続データの作成
  • インデントマーカー/段落
それぞれの内容は詳しく説明しないので、気になったらググってみるとよいかも。一番へぇと思ったのが、Excelで連続データの増分を指定して作成できること。いや、以前にExcelの本を一冊読んで知っているはずだったんだけど、普段使わない機能なので忘れてしまっていたようだ。他にもWordの更新履歴の機能はほとんど使ったことがなかったので参考になった。普段はWord自体そんなに使用しないしなぁ。

文書のオキテが示されている部分があるので、その部分を抜粋。
 ビジネスの現場で活用される文書は、文学作品でもなければ、商業出版でもありません。毎日の作業による成果物として、長期にわたって、職場の内外で繰り返し参照され、再利用される文書を作れるようになること。それが、厳守すべき文書作成のオキテです。
(pp.19)
ということらしい。作業効率をアップするためにも、職場の文書ルールを守ることが重要らしい。

各Tipsに対して文章で説明があり、ダメな例、よい例が図で示されており、さらによい例にするにはアプリケーションの機能をどう使うかが図示されているので分かりやすいと思う。ファンキーなひげ社員のイラストもあるし。Word、Excel、PowerPointの本当によく使う機能のみを厳選して紹介しているのだと思われる。

この本は三菱商事のCIOオフィスが作成している社内研修資料が基になったらしい。ちなみに、三菱商事はどのパソコンも文書保存専用に同じ名前のフォルダが同じ位置に用意されていて、原則として必ずそこに文書を保存するようにしているらしい。へぇーと思った。自分の会社はそんなものはないなぁ。

分かりやすい内容で、本当に新入社員向けだと思われる。そのため、Word、Excel、PowerPointの各機能の網羅性はないので、細かい機能を知りたい場合は個別の書籍などでカバーする必要があると思う。特にExcelなんかは一度分厚い本を一通り読んでおいたほうがよいと思われる。

読むべき人:
  • 新入社員の人
  • 文書作成時の体裁を整えるのに時間がかかっている人
  • Wordのインデント設定にイライラしてしまう人
Amazon.co.jpで『山田祥平』の他の本を見る

にほんブログ村 本ブログへ 役に立ったらクリック☆  bana1


May 14, 2008

プロとしてのデータモデリング入門


プロとしてのデータモデリング入門 (Oracle現場主義)

キーワード:
  林優子、データベース、データモデリング、設計、入門書
データベースのデータモデリングが分かりやすく解説されている本。以下のような目次になっている。
  1. INTRODUCTION データベース設計の重要性
  2. 基礎編 はじめてのデータモデリング―データ中心アプローチによる概念設計
    1. データモデリングとは
    2. エンティティの種類と定義方法
    3. パターンでおぼえるリレーションシップ
    4. 正規化
  3. 実践編 現場で使えるデータモデリング―パフォーマンスを考慮した論理設計
    1. 論理設計とは
    2. 索引の基礎知識
    3. 索引の設計
    4. 導出項目と重複項目
    5. 非正規化
    6. 制約―ビジネスルール
  4. APPENDIX 主要ER図表記法対照表
基礎編と実践編があり、基礎編でデータモデリングの概要とE-R図の作成手順や作成時に気をつけなければならないこと、さらにテーブルの正規化なが示されている。実践編ではパフォーマンスに考慮して索引の基本から索引をどこに設定すべきか、さらにはSQL文レベルで索引の活かし方、また非正規化を行うことでパフォーマンスを上げることも出来るなどといったことが示されている。

以下、自分が特に勉強になった部分を示していく。

そもそもデータモデリングとは何か?という部分が示されているところがあるので、その部分を抜粋。
 データモデリングとは、現実の世界をモデル化し、データを考えるための安定した基盤を作る手法のことです。企業の全情報を共有するために、データを一元管理し、ハードウェア、ソフトウェア、アプリケーションから独立した、変化に絶え得るモデルを作ります。一般的には概念設計のフェーズを主にデータモデリングと呼びます。
(pp.23)
ポイントは変化に絶え得るということろ。データベースというのは、一度構築されれば途中の仕様変更や拡張を行われながらも長く使われていくものなので、現在の情報システムの問題点として、既存システムの変更要求に対応することに時間がかかり、新しいシステム開発に時間を費やせないということがある。そのため、変化に絶え得るモデルが必要になる。

また、プロセス中心アプローチの設計により、業務単位で作業を進めてきてしまい、システム全体を眺めると同じようなデータが存在してしまっているという問題もあるようだ。そうなるとデータの一元管理ができないので、プロセス中心アプローチの設計からデータ中心のアプローチで設計しなければならないようだ。データ中心アプローチというのは、データを先に考え、1つの自称を1箇所で管理する方法ということらしい。なるほどと思った。

データ中心アプローチのデータモデリングの手順は以下のようになる。
手順概要
1モデリングの方針決定トップダウンかボトプアップかなど、データモデル作成の方針を決める
2概念データモデルの仮説の作成方針にしたがいデータモデルのたたき台を作成し、疑問点や不明点を洗い出す
3概念データモデルの詳細化手順2で作成した仮説モデル(たたき台)のレビューを行い、必要な情報を得て、詳細化していく
4概念データモデルの検証機能面などからデータの過不足について検証する
(pp.24)

また、トップダウンアプローチでE-R図を作成する手順は以下のようになる。
  1. エンティティを洗い出す
  2. リレーションを洗い出す
  3. 属性を洗い出す
  4. オカレンスを識別する属性または属性の組合せを見つける
しっかりこの手順を守ることがよい概念モデルを作るコツらしい。この手順は具体例をもとに丁寧に解説されているのでかなり分かりやすい。今まで感覚的に設計をしていたことを反省した。

他にも3章でE-R図のカーディナリの設定の仕方もとても勉強になる。多対多のリレーションシップがある場合は、設計からもれているエンティティが存在するといことらしい。これは知らなかったな。

実践編のほうはよりDB設計に深く関わる人向けだと思う。しかし、プログラマレベルでは、SQL文ではHAVING句よりもWHERE句の方がパフォーマンスがあがる、索引が定義されている列で計算をしたり関数を使用すると索引が使用されないといったことなどは知っておくべきだと思う。今までパフォーマンスを考慮したSQL文を書いてこなかったので、少し反省。

データモデリングは、データを分析するスキルが必要で、これは業務スキルがないとできないと示されていて、なるほどなぁと思った。業務が分かっていないとよい設計なんかできないなと改めて思った。データモデリングはかなり上流よりだなと思った。

全体的に図も多く、メリハリがついた内容でかなり分かりやすい。何よりも何度も開きたくなるような紙質がいい。技術本は内容も大事だけど、物理的な紙質も重要な気がする。

入門者からそれなりに精通した人まで対象範囲は広いと思う。ただ、さすがにデータベースの基本事項が分かっていないと示されていることの設計のポイントなどは分かりにくいと思う。

この『プロとしての〜』シリーズはかなり分かりやすいものが多いと思う。『プロとしてのOracle PL/SQL入門』も分かりやすくて何度も読み返している。こっちもお薦め。

今回は無駄にtableタグを使用してみた。体裁を整えるのに時間がかかった・・・。テンプレ化して使いまわそう。

読むべき人:
  • テーブル設計の仕方が分からない人
  • E-R図が思うようにかけない人
  • パフォーマンスを考慮した論理設計が必要な人
Amazon.co.jpで『データモデリング』の関連書籍を見る

にほんブログ村 本ブログへ bana1 ランキングへ


May 13, 2008

コンピュータの名著・古典100冊


コンピュータの名著・古典100冊

キーワード:
 石田晴久、コンピュータ、古典、必読、ブックガイド
コンピュータ分野に興味を持つ若手エンジニアや学生のための指南書となる名著、古典が100冊紹介されている本。以下のような目次となっている。
  1. 歴史
  2. 人物・企業
  3. ドキュメンタリー
  4. 思想
  5. 数学/アルゴリズム
  6. コンピュータサイエンス
  7. アーキテクチャ/OS
  8. コンパイラ/言語
  9. プログラミング
  10. ソフトウェア開発
  11. データベース/ネットワーク
コンピュータの古典や名著が上記の分野からそれぞれ選ばれており、専門家がその本の解説を2ページにわたって示している。100冊すべて列挙するのはさすがに面倒なので、ここは自分の専門分野らしく、示されているもので自分が読んだことがあるものを挙げてみる。紹介文はそれぞれの紹介ページから抜粋している。また、括弧内は紹介されている章の分野を示す。


それがぼくには楽しかったから
リーナスが語るLinux誕生の秘話(人物・企業)

ハッカーズ
コンピュータ文化を作り上げたハッカーたちの物語(ドキュメンタリー)

メディア論―人間の拡張の諸相
メディアは、それそのものがメッセージである(思想)


アルゴリズムとデータ構造
プログラミング学習の王道にして必読書(数学/アルゴリズム)


OSの基礎と応用―設計から実装、DOSから分散OS Amoebaまで
オペレーティングシステムを作ってみたいと思いませんか(アーキテクチャ/OS)

UNIX原典―AT&Tベル研のUNIX開発者自身によるUNIX公式解説書
モダンOSの原点であるUNIXのコンセプトを理解する(アーキテクチャ/OS)


プログラミング言語C ANSI規格準拠
何人もの人生を変えたプログラマの「バイブル」(コンパイラ/言語)


プログラミング作法
よいプログラミングの手法が詰まっている「カーニハン3部作」(プログラミング)

構造化プログラミング
プログラミングの歴史を変えた記念碑(プログラミング)


C言語による最新アルゴリズム事典
LHAのアルゴリズム開発者によるアルゴリズムの集大成(プログラミング)


人月の神話―狼人間を撃つ銀の弾はない
ソフトウェア開発の永遠の課題の核心を突く15章とさらなる4章(ソフトウェア開発)

100分の11冊か。少ないな。まぁ、以上の読んだ本は、全て詳細に読み込み完全に理解したというものではない。大学時代に図書館にあったものを暇つぶしに眺めていたという表現のほうが近い・・・。なので、どれほど自分の糧になっているかは不明。たぶん潜在意識にしっかり取り込まれているはず。たぶん・・・。

他にもたくさん紹介されていてるので、改めて技術を学ぶ必要があるときは、古典、原点をしっかり学んだほうがよいと思われる。そろそろ自分も入門書から卒業しなければならないかなという状況なので。とりあえず、気になった本をAmazonのほしいものリストに入れておこうか。


改訂新版 コンピュータの名著・古典100冊
あと、この本は自分は旧版を読んだが、改訂版が出ている。旧版を買ってしばらく積読状態にしていたら、改訂版が出てしまって地味にショックだった気がする・・・。内容はそんなに変わらないと思うけど。

古典名著以外にもコラムでコンピュータが出てくる小説なども紹介されている。他にもコラムでRubyの開発者であるまつもとゆきひろ氏のおすすめコンピュータ書が示されていたりして、他の技術者が何を読んできたのかがわかって面白い。

各書籍に対して、インターネット上募集した読者コメントが載っており、これを読んでいないやつはダメだとかこれにすごく影響されたとかいろいろ載っていたりして、あぁ、自分は全然読んでないやと反省してしまった・・・。一応大学時代の専攻もコンピュータ関連なんでね。

久しぶりに専門分野を学習しなおそうかなと思った。しっかりとした技術を身に付けたい人はぜひ読もう。

読むべき人:
  • コンピュータ関連の技術に関心がある人
  • 技術書の入門書から卒業したい人
  • ハッカーになりたい人
Amazon.co.jpで『コンピュータ』の関連書籍を見る

にほんブログ村 本ブログへ bana1 ランキングへ


May 12, 2008

アナリシスパターン―再利用可能なオブジェクトモデル


アナリシスパターン―再利用可能なオブジェクトモデル

キーワード:
 マーチン・ファウラー、オブジェクト指向、設計、パターン、概念モデル
オブジェクト指向でのモデルそのものがパターン化されて示されている本。目次は以下のようになっている。
  1. 導入
  2. 責任感系
  3. 観測と測定
  4. 企業財務の観測
  5. オブジェクトへの参照
  6. 在庫管理と会計
  7. 会計モデルの利用
  8. 計画
  9. トレーディング
  10. デリバティブ(金融派生商品)
  11. トレーディング・パッケージ
  12. 情報システムの階層化アーキテクチャ
  13. アプリケーションファサード
  14. 型モデル設計テンプレートのためのパターン
  15. 関連パターン
  16. あとがき
  17. 付録A 技法と記法
  18. 付録B パターン一覧表
2章から11章までが第1部でアナリシスパターンの領域になり、12章から16章までが第2部でサポートパターンの領域になる。16章以降は第3部で付録になる。この本の目的が示されている部分を序文から抜粋。
 本書は,分析におけるパターンについて書いている。ここでのパターンは,実際のソフトウェアの実践というよりも,ビジネスプロセスの概念構造を反映したものである。多くの章で,さまざまなビジネス問題領域のパターンについて検討している。
(中略)
本書では,概念モデルをソフトウェアに変換するために使えるパターンを提示する。そして,そのソフトウェアを巨大な情報システム用のアーキテクチャに適合する方法ついて論じる。さらに,パターンを使った具体的な実践のコツついても議論する。
(pp.xi)
以上のような構成になっており、オブジェクト指向設計のモデリング手順が示されているというよりも、目次にあるようなさまざまなビジネスプロセスのモデルそのもが具体例とともに示されている。

アナリシスパターンというのは、取引、測定、会計、組織的関係性といった問題領域からの抽象概念を提供するものであり、対象ビジネスを人々がどう捉えているかを表現している概念的なものになる。また、サポートパターンというのは、ビジネス部分に主点をおいているアナリシスパターンをどのように情報システムアーキテクチャに適合させるか、概念モデルをどのように実装に変換するかといったよりコンピュータシステムよりのパターンである。

フォトリーディングし、全体にざっと目を通しただけなので、それぞれのパターンのよしあしなど細かいところまでは把握していない。著者も序文で示しているように、この本は最初から最後まで通して読む本というよりも、モデルのカタログといったほうがよい。また、本書の読み方も示されており、それによると、第1章の『導入』を先に読んでから、各章で気になるところを読んでいけばよいとあった。

また、想定読者も示されており、それによると『オブジェクト指向のコンピュータシステム「分析者および設計者」,それも分析に近い方に携わっている人たちであると想定している。(pp.xiii)』とある。なので、正直自分は想定読者側の人物ではないと思った。

示されているパターンのモデル図にはUMLではなくOdellという人の記法が使われている。UMLを使っていない理由として、UMLは実装モデルに力を入れているが、本書で示したいことは概念モデルなので、もっとも概念的なモデリングができるOdellの記法を選択したようだ。Odellの記法はUMLやE-R図に似たような感じで、型とクラス、関連、属性、集約、汎化、ルールと意味宣言などいろいろある。これらは付録に詳しく示されている。モデル図に慣れていないと、意味を読み取るのに時間がかかるかもしれない。しかし、E-R図やUMLなどを使ってモデリングできる人は問題ないと思われる。自分は多重度の読み取りが苦手だなと思った。

上流工程で業務をモデリングしたりする必要性に迫られている人には得るところが多いと思われる。しかし、自分のようにまだ下流専門のプログラマーにとっては、少し敷居が高いように思えた。もっと上流でオブジェクト指向設計が必要になったら改めて読み返そうと思った。

読むべき人:
  • 業務のモデリングパターンを知りたい人
  • ビジネスをモデル化する必要のある人
  • 業務知識を勉強したい人
Amazon.co.jpで『マーチン・ファウラー』の他の本を見る

にほんブログ村 本ブログへ bana1 ランキングへ


May 08, 2008

オブジェクト脳のつくり方


オブジェクト脳のつくり方―Java・UML・EJBをマスターするための究極の基礎講座

キーワード:
 牛尾剛、オブジェクト指向、デザインパターン、アジャイル、攻略本
NEC勤務で超美人かつ性格がよく野望を持った女性の恋人募集中である著者(著者紹介より)による、オブジェクト指向の攻略本。以下のような内容となっている。
  1. 不完全主義のススメ
  2. たったこれだけでいいオブジェクトの基礎――だけど究極
  3. 演習:社長命令・起立!
  4. 先人は偉い、超手抜きパターン習得法
  5. もう一歩進んだオブジェクト脳になるために
  6. なぜオブジェクト脳の人はそう考えるのか
  7. オブジェクト脳に変えるトレーニング
  8. ようこそC3Jプロジェクトへ
  9. 最終イテレーション、そして最強の課題
  10. 付録A オブ脳外伝 EJBのススメ――EJBポイント解説
  11. 付録B 実践C3Jプロジェクトのユースケースシナリオ例
  12. 付録C オブジェクト脳度チェックリスト
  13. 付録D ステレオタイプの定義
オブジェクト脳というのは、オブジェクト指向が感覚的に理解できている状態と示されており、この本はオブジェクト指向の解説書であり、また、オブジェクト指向をマスターするための勉強の攻略本と著者が示している。そして、どちらかというと、詳細の厳密性よりも、オブジェクト指向の概念把握を主題にしているので、完全無欠なものではなく、イメージをつかみやすいものにしているとある。なので、仙人のイラストとか著者のおちゃめな写真とか砕けた文体が多く載っており、楽しい構成となっている。

オブジェクト指向の基礎であり、かつオブジェクト指向の究極の要素は以下の5つらしい。
  • オブジェクト
  • クラス
  • 継承
  • カプセル化
  • ポリモーフィズム
これだけの要素をマスターすればよいが、これらをちゃんと説明できる技術者が日本にはあまりいないと示されていた。それぞれの説明がトータルで16ページでされている。説明は小学生でも分かるように、コンピュータのシステムを一切考えずに本質的なところだけを簡単に説明している。例えば、オブジェクトとクラスの関係の部分についての説明の一部。
 具体的に存在するもの、例えば「牛尾くん」とか「あなた」とか「あなたのPC」「牛尾くんのPC」はオブジェクトで、それらをひとくくりにした定義、例えば「人間」「PC」がクラスになります。
 はい、「クラスとオブジェクト」修了。コンピュータのことさえ考えなければとっても単純です。
(pp.17)
といった感じで、普通のオブジェクト指向解説本ならもっと詳しく書くべきところをあえてこのように単純化している。

また、ポリモーフィズムを理解できたときにオブジェクト脳が芽生えると示されている。そしてその説明には、つい立を隔てた社員と社長の図で示されており、なんだか感覚的に分かった気になる。単純な説明のほかにちゃんとサンプルコードも載っている。

4章はよく使うデザインパターンが示されている。デザインパターン自体は23個ほどあるが、必要なのは基礎となる4つだけらしい。
  • ステイト/ストラテジー (State/Strategy) パターン
  • ファクトリーメソッド (Factory Method) パターン
  • コンポジット (Composite) パターン
  • テンプレートメソッド (Template Method) パターン
あまりJavaでコーディングしたことが無かったので、このようなデザインパターンは勉強なる。

著者によれば、1章から4章までが一番重要な内容となっているので、4章までをマスターすればこの本の役割は終わりとある。5章はオブジェクト指向の設計方法の例が示されている。あとは読み物として6,7章が参考になる。

6章では、オブジェクト指向の利点として、ドキュメントレスでシステムの把握が楽になり、変更に強くシステムの変化を受け入れやすいとあった。そしてオブジェクト指向はどちらかというとアジャイルな設計方法なので、設計書など最後に書いてしまったほうがよいとあった。また、大規模システムでも問題ないと。

ただ、問題点としてオブジェクト指向を理解させるための教育コストがかかるということと、システム開発の契約形態が従来型のウォーターフォールなどの手法で標準化しているので、イテレーション型開発をするときに問題になるとある。確かに各フェーズごとに設計書などを納品する必要があるというときに、イテレーション型開発をしていたら納品物が不完全なままになってしまうなと思った。個人的には、プログラムよりも設計書ばかり書いていて変化に柔軟ではないウォーターフォール開発よりも、アジャイルでドキュメントレスな開発のほうが楽しいし面白いなと思う。アジャイル開発を経験したことがあるだけに。

7章では、オブジェクト指向をマスターするために必要なことが示されている。以下はオブジェクト脳に変えるための基本的な考え方らしい。
  1. 教えるときは詰め込みすぎない
  2. 最初から最適化することを考えない
  3. 相手がわかっているかどうかは相手の反応で判断する
  4. 相手の理解度によって、教え方をかえる
  5. 「〜すべき」「〜で当然」を適用しない
  6. 教えるのに時間がかかることを恐れない
  7. ほめる
著者のこの基本的な考え方は、とてもやさしくまた新人技術者にとっては健全な成長ができるものだなぁと思った。これを実現するには、最初にプロジェクト配属前に2週間はトレーニングを行うようだ。自分もこのような環境で働きたいなと思った。自分の組織だけとは限らないと思うけど、プロジェクトは大抵タイトスケジュールで、ゆっくり教育を受けている余裕も無く、戦場で独力でサバイバルしているようなもので・・・・。なので、自分の下に人が来たときはこれを忘れないようにしよう。

この本はオブジェクト指向の概念を理解するにはよいと思う。説明を見て分かった気になる。けれど、分かった気になる反面、実際にコーディングするときは迷うと思う。そこは著者も示すとおり、実際に自分でコーディングして理解していくしかないとある。なので、自分もがんばってオブジェクト脳を完全なものにしたいと思った。

前提知識としては、Javaの基本文法は理解していることだと思う。また、オブジェクト指向の要素やデザインパターンの要素を厳密に知りたい人はこの本では足りないと思う。あくまで、Javaの基本文法を理解したうえでオブジェクト指向の概要を知りたい人向けだと思う。そのような人にはよい本だと思う。

技術本は読んでいて退屈なものが多いけど、これは読んでいても楽しめるものなのでよいと思う。

読むべき人:
  • いまいちオブジェクト指向がわからない人
  • デザインパターンがわからない人
  • アリスター・コーバーン/マーチン・ファウラー/ケント・ベックの3人のなかで、はげていないのは誰かを答えられない人
Amazon.co.jpで『オブジェクト指向』の関連書籍を見る

にほんブログ村 本ブログへ 役に立ったらクリック☆  bana1


May 07, 2008

業務システムのための上流工程入門


業務システムのための上流工程入門―要件定義から分析・設計まで

キーワード:
 渡辺幸三、業務システム、上流工程、基本設計、モデリング
上流工程の重要性から基本設計時の業務モデリングの方法が示されている本。以下のような内容となっている。
  1. 上流工程の困難
    1. ボトルネックは「分析・設計・検収」
    2. システム開発フェーズ分け
    3. 上流と下流の分業体制
  2. 上流工程の進め方
    1. 要件定義と「トリアージ」
    2. 拡散型思考過程としての基本設計
    3. 基本設計のための図法
    4. ビジネスシステムの特性
    5. 現状分析の意義と限界
  3. 基本設計入門
    1. 基本設計の進め方
    2. 概略設計で大枠をとらえる
    3. データモデリング
    4. 業務モデリング
    5. 機能モデリング
    6. とりまとめとレビュー
  4. モデリングパターンと用例
    1. 業務フローのパターン
    2. データモデルのパターン
    3. 機能モデルのパターン
    4. サブシステム分割のパターン
以下、勉強になった部分を紹介していく。

システム開発における、上流工程とは何かいうと、著者によれば以下のようになる。
  • 分析:ユーザーの抱えている問題を明らかにする
  • 設計:適切な業務プロセスやコンピュータシステムの仕様を考案
  • 検収:妥当性をユーザーに納得してもらうこと
そして、この上流工程がシステム開発のボトルネックになるようだ。なぜならば、システム開発者とユーザーにはシステムに対する認識のギャップがあり、システム開発者がそのままユーザーになる場合は使いやすいシステムを作りやすいが、ユーザーはプログラムなどのシステムの内部動作にはあまり関心がないことが一般的であるので、実際には作りながら使ってもらい、その都度修正が必要になる。さらにシステムの対象ユーザーは数人という規模ではなく、会社組織全体といったように、組織間の相互関係まで考慮に入れて分析、設計、検収をしてもらう必要があるので、さらに困難さが増してしまうようだ。そしてこのボトルネックは、上流と下流を両方経験した技術者以外には見えないのが普通らしい。よって、上流工程について学ぶには、この困難さを理解することが第一のステップになるようだ。

また、上流工程の成果物は以下の2つを同時に満たす必要があるらしい。
  • コンピュータシステムに関して素人であるユーザーにとってわかりやすい
  • プログラマが仕事を引き継げるほどに具体的かつ厳密
これは、上司にもよく言われたことだなと思った。上流工程の成果物には基本設計書があるが、これはユーザーにも納品するので、不明確な部分やあいまいな表現はなくす、また文言は統一しろとよく言われた。さらに、基本設計書を作った人がそのまま詳細設計書を作成し、プログラムするとは限らないので、基本設計書を見ただけで他の人が詳細設計書を書ける内容のものでないといけないと言われたので、これはそのとおりだなと思った。

上流工程の初期段階で、設計書を書くときにははじめからツールを使ってきれいに書こうとすると、何かを作ってしまった気になってしまうので、紙に手書きで試行錯誤するのがよいと示されていて、なるほどなと思った。

基本設計の進め方は以下の4つので順になるようだ。
  1. 概略設計――業務フローを作成
  2. モデリングセッション――ビジネスシステムの3要素(データ、仕事、道具)が視覚化するモデリング作業
  3. とりまとめ――大量の手書き図面を整理しながら設計情報の管理ツールに登録するための作業
  4. レビュー――とりまとめの結果を関係者に検証してもらうための手順
勉強になった。

特に実践的に使えそうなのは、4章のモデリングパターンと用例だと思った。ビジネスシステムでよくモデリングされる4つのパターンが示されている。また、データモデルのパターンも示されており、データベース設計にそのまま活かせる部分だと思った。ただ、ここで示されているデータモデリング記法はIE方式というもので、これを使用すると、モデルに具体的なレコードの例を併記できるので、この表記を採用しているようだ。この表記自体は見たことがなかったので、少し戸惑ったが、慣れればキーの親子関係などもすぐに分かると思われる。

上流工程から基本設計のモデリング方法まで具体例を示しながら解説されているので、わかりやすいほうだと思う。ただ、業務モデルの図がいまいちごちゃごちゃしているかなと思った。

他にもコラムが載っており、上流工程で役立つ資格や上流工程へのキャリアパスについてなどが著者の経験から示されていて、なるほどなと思った。ちなみに上流工程で役立つ資格は簿記らしい。

上流工程に関わったことのない人で、これから関わることがある人はぜひ読んでおくべき内容かなと思った。とても勉強になったので、何度も読み返そうと思った。

ちなみに、この本はAmazonでは評価が高い。

読むべき人:
  • 上流工程に携わりたいシステム開発者
  • システム開発者に仕様を伝えるユーザー
  • 過度の長時間労働を武勇伝として語ってしまっている人
Amazon.co.jpで『渡辺幸三』の他の本を見る

にほんブログ村 本ブログへ bana1 ランキングへ


January 16, 2008

Oracle E‐Business Suite入門 テクニカル編


Oracle E‐Business Suite入門 テクニカル編

キーワード:
 日本オラクル、Oracle、EBS、パッケージ、フレックスフィールド
Oracle社が発売しているOracle E‐Business Suiteの入門書。以下のような内容となっている。
  1. E‐Businessを支えるOracle E-BusinessSuite 11i
  2. アーキテクチャ
  3. 操作
  4. システム管理
  5. フレックスフィールド
  6. 拡張機能
初版が2002年だが、すでに絶版でAmazonを筆頭とするオンラインショップはほぼ在庫なし。定価は2800円だが、どうしても読んでおく必要があると思ったので、Amazonのマーケットプレイスで1万円で購入。1万円を出す価値があったのか?と言われれば、うーん・・・。まぁ、技術書に金をケチっていたら技術者として頭打ちになると思っておこう。

あんまり書評することもないような本なので、以下、自分の勉強メモ。

そもそもOracle E‐Business Suite、通称Oracle EBSとは何かというと、Oracle社が提供する、ERP、CRM、SCM、BIの統合パッケージシステムで、以下のようなモジュールが存在する。
  • プロキュアメント
  • サプライチェーン管理
  • プロセス管理
  • 生産管理
  • プロジェクト管理
  • 統合会計
  • Business Intelligence
  • 人事管理
  • テクノロジ
  • サービス
  • マーケティング
  • セールス
そして以下のような特徴を持つようだ。
  1. End to Endソリューション
  2. シンプル&完全統合
  3. オープンで柔軟
End to Endソリューションというのは、顧客からサプライヤまでをつないだ、全体的に包括したE-ビジネスソリューションを提供するということらしい。

あと、個人的に役に立ったのはフレックスフィールドについて。以下メモ。
  • キーフレックスフィールド(KFF)・・・勘定科目体系や品目番号など、基幹業務のキーとなるデータを取り扱うためのデータ・フィールド
  • 付加フレックスフィールド(DFF)・・・現行業務上必要なデータであるのに、EBS11i上で取り扱うように定義されていないデータを追加して格納するためのデータ・フィールド
  • 値セット・・・実際の値の定義ではなく、データ型や書式などの値の枠組みの定義のこと
  • クオリファイア・・・特別なセグメントや値を複数のセグメントや値の中から識別するためのもの
こんなものかな。

一応書評っぽいことを書いておくと、図や画面キャプチャがそれなりに多く入っているので、内容をイメージしやすいと思う。けれど、なんとなくこの本を一度読んだだけでは、Oracle EBSのことは分からないと思う。実際にEBSを使ってみる必要があると思う。

Oracleはぜんぜん情報公開していないので、EBSの情報を得ようと思ったら、この書籍くらいしかない。けれど、絶版で旧バージョンのものにしか対応していない。なので、EBSなどの情報を得るのに一番いい方法は、Oracleのトレーニングを受講することなんだけどね。高いらしいけど・・・。

この記事を書いている時点で、マーケットプレイスでは12,000円で売られているようだ。

読むべき人:
  • Oracle EBSの基本を知りたい人
  • Oracle EBSを導入しようと思っている人
  • コンカレント、フレックスフィールドという用語が分からない人
Amazon.co.jpで『Oracle』の他の本を見る

にほんブログ村 本ブログへ bana1 ランキングへ


January 14, 2008

パッケージから学ぶ4大分野の業務知識


パッケージから学ぶ4大分野の業務知識 (開発の現場セレクション)

キーワード:
 梅田弘之、パッケージ、ERP、業務知識、フィット・アンド・ギャップ
パッケージソフトを通して、会計、販売、生産、人事の4大分野の業務知識を習得できる本。内容は以下のようになっている。
  1. 基本編
  2. 財務会計・管理会計
  3. 債権管理・債務管理
  4. 販売管理
  5. 調達・在庫管理
  6. 生産管理
  7. 原価管理・仕掛管理
  8. 給与計算
  9. 人事管理
  10. 付録
業務知識を学ぼうと思ったら、本を読むだけでなく、実際に開発を経験することが重要だが、どうしてもプロジェクトに依存した知識しかつかない。そこで、市販されているパッケージソフトをベースに業務知識をつける方法が良いと示されている。この方法では以下のような利点があるようだ。
  • 理想的な業務をモデルとしているので、普遍的な業務知識が身につく
  • 画面や帳票の具体例があるので、業務を具体的に理解しやすい
  • デモなどを見たり、データを入力したりして確認することもできる
この本では、著者が開発に関わった、Web-ERP「GRANDIT」というパッケージが例として使われている。

各分野の解説をしてもしょうがないので、自分が線を引いた用語を列挙。
  • 勘定科目・・・取引の明細を表す項目(pp.25)
  • 総勘定元帳・・・ある勘定科目に対する相手勘定を照会するもの(pp.37)
  • 合計残高試算表・・・勘定科目別の金額残高をそのまま左右(貸借)に並べて出力したもの(pp.38)
  • 売掛金・・・貸借対照表において売り上げで発生した債権の資産科目(pp.47)
  • 買掛金・・・貸借対照表において仕入れで発生した債務の負債科目
  • 検収・・・顧客が商品やサービスを検めて「はい。これならOKです。」と合格を与えること(pp.71)
  • 請求締・・・日本で一般に使われる商習慣で、一定期間内の売上をまとめて請求するというもの(pp.86)
  • SKU・・・Stock Keeping Unit(在庫保管単位)の略で、商品在庫の識別単位を示す物流用語
こんなものか。

パッケージ導入にはフィット・アンド・ギャップ調査を行い、パッケージで使える部分と使えない部分を洗い出す必要があるようだ。また、パッケージの機能をほぼそのまま使えるのは、「会計」と「給与」などの法律や仕組みが標準化されたもののみで、他の分野は企業によってさまざまな形態になるようだ。

自分は会計分野が苦手だ。会計用語などが分からなければ、まったく画面を見ても何を実現しているか分からない。逆に、生産管理、在庫管理などは業務やデータの流れが直感的に分かる。

規模の大きなERPシステムだと、いくつものモジュールが必要になり、それらが必ず連携していることが多い。なので、それぞれを独立に習得するよりも、業務の流れに沿ってどこでどのようなデータが必要で、それらがどこに流れていくかということを意識したほうが良いのではないかと思った。この本は、そういった意味で、複数業務の知識を身につけられて良いと思った。

それぞれの分野で画面例や業務フロー、システムフローなど図が多めに載っていて分かりやすいと思う。

読むべき人:
  • ERPシステムを導入しようと思う人
  • 業務知識に自信がない人
  • 業務知識もわかるSEになりたい人
Amazon.co.jpで『梅田弘之』の他の本を見る

にほんブログ村 本ブログへ bana1 ランキングへ


January 13, 2008

ネットワークはなぜつながるのか 第2版


ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識

キーワード:
 戸根勤、ネットワーク、インフラ、入門書、探検ツアー
インターネット上でのネットワークの技術を、ブラウザにURLを入力してからホームページが表示されるまでの内部動作を時系列で示している本。以下のような内容となっている。
  1. Webブラウザがメッセージを作る―ブラウザ内部を探検
  2. TCP/IPのデータを電気信号にして送る―プロトコル・スタックとLANアダプタを探検
  3. ケーブルの先はLAN機器だった―ハブとスイッチ、ルーターを探検
  4. アクセス回線を通ってインターネットの内部へ―アクセス回線とプロバイダを探検
  5. サーバー側のLANには何がある
  6. Webサーバーに到着し、応答データがWebブラウザに戻る―わずか数秒の「長い旅」の終わり
はじめにのところに、この本の特徴が示されている。主に2つ特徴があり、一つはネットワークの内部動作を時系列に探検ツアーのように追いかけていくようにしていること。こうすることで、ネットワークシステムの全体像の把握をしやすくしているようだ。もう一つの特徴は、ネットワーク機器やソフトウェアがどのように動くかといった内部構造をしっかり示していることとある。

この2つの特長により、自分自身も確かに分かりやすいなと思った。どうしてもネットワークなどのインフラ周りに苦手意識があり、全体像が見えなかったりルーターやハブ、ゲートウェイなどの内部動作の詳細がわかりにくかったりする。しかし、この本は、ネットワークのどの段階でどういう仕組みになっているかがかなり詳しく載っていると思う。ページ数も445ページと、入門書レベルにしては重厚だ。

第1版よりも100ページ近く加筆修正があるようだ。第2版は現実の機器やソフトウェアの動きに重点を置いてあるようだ。

去年の夏から少しずつ読んできて、放置気味だったものを読了にしたくて思い出したように再読。以前に読んだところをすっかり忘れてしまっている・・・。ACKの動作やパケットの内部構造とかルーターのルーティング方法とか結構怪しい・・・。また、さすがにこれは速読しても頭に残らない可能性が高い。読み返すときはもっと速くいけそうだが。

ソフ開対策に読んでいたのだけど、この量を一度だけ読んで完全理解できる人意外は、何度も読み返す必要があると思う。また、基礎的が部分をかなり丁寧に解説されているので、何度も読み返す価値があると思う。また読み直さなければなぁ。

自分に関してはネットワークに対する苦手意識みたいなものは薄れたと思う。

読むべき人:
  • ネットワークの基礎を学びたい人
  • ネットワークに対して苦手意識がある人
  • 情報処理技術者試験を受ける人
Amazon.co.jpで『戸根勤』の他の本を見る

にほんブログ村 本ブログへ bana1 ランキングへ


December 29, 2007

アマゾる


アマゾる―オンラインショップAmazonをとことん限界まで使いこなすこと

キーワード:
 津田大介、Amazon、アマゾン、便利ワザ、アソシエイト
Amazonをとことん限界まで使いこなすために70のワザが示されている本。これは便利だ。

構成的には、2部構成で、Part1が『アマゾる!』でPart2が『Amazon.comの利用方法と「詳細サーチ」の使い方』となっている。さらにPart1は『探す』、『お得』、『アソシエイト』、『便利』と4章構成。

自分が知らなかったもの、もしくはこれは使える!!と思ったワザを以下に列挙。
  • マイストアを鍛えて自分の欲しい商品が的確に並ぶようにする
  • ウェブ技術のPHPについて書かれた本だけを検索する
  • 著者名があやふやな作者の作品を調べる
  • カスタマーレビューに投稿されたレビューを検索する
  • ネットで話題の本やCDをいち早く紹介してアソシエイト購入率を上げる
  • 発売中なのになかなかヒットしない書籍を探す
  • 在庫切れ商品の中古商品を予約購入する
  • Amazonで価格.comや楽天より安く電化製品を買う
  • 通常ディスカウントされない新作CDを低価格で購入する
  • 商品の値下げ情報を定期的に調べて一番安いときに買う
  • Amazonで今どんなキーワードが検索されて人気なのか調べる
例えば、マイストアを鍛えるというのは、おすすめ商品にある『持っています』と『興味がありません』リンクをこまめにクリックしていくことで、おすすめの適切度がかなり変わってくるようだ。結構おすすめ商品もウィッシュリストに入れるので、これは使えると思った。

『ウェブ技術のPHPに〜』というのは、Googleとの複合ワザでGoogleの検索オプションである指定ドメイン内であるキーワードを排他的に検索する方法。『site:amazon.co.jp PHP -研究所』といった具合でググるとよいらしい。これも今まで気づかなかった視点だな。いつもAmazon内で検索していたから。

さらに『著者名があやふやな〜』ではAmazon内での検索ワザが示されている。それはアスタリスクによるワイルドカード検索機能であり、検索ワードの最後に * を指定するとあやふやな部分が補完される。アスタリスク指定は検索ワードの末尾しか機能しないようだ。

『ネットで話題の本やCDをいち早く紹介して〜』はアソシエイトのワザ。ネットでみんなが買っているものが売れるという基本を押さえて、「自分のサイトの読者が興味を持てそうなジャンルの商品で、売れている(話題になっている)ものをオススメする(pp.129)」とよいらしい。これはなるほどなぁと思った。

他にも、Amazonのウェブサービスなどを使用したツールが多く紹介されていた。以下にいくつか列挙。それぞれのワザには概要、画面ショット付き説明があるので分かりやすい。また各ワザの詳細が示されているColumnが参考になる。そこは著者の意見であったり、Amazon関係者の説明であったりする。

最近Amazonクレジットカードを作ったこともあり、徹底的にAmazonを使いこなそうと思っていたので、この本はかなり役に立つ。結構知らないことが多い。

また、自分はどのくらいアマゾっているかというと、Amazonクレジットカードを作り、このブログでAmazonアソシエイトをやり、かつAmazonプライムを導入してまでAmazon経由で買っている。Amazonクレジットカードを作る前は、本はほとんど書店経由で買っていたけど、これらを複合的に使用するとかなりお得なことや便利なことが多いということに気づいた。自分なりのアマゾり方は、そのうちに別記事で示してみようと思う。

この本は初版が2005年8月15日なので、最近の新機能などが反映されていないかもしれない。けれど、各になる部分はかわらず使えると思うので、アマゾっている人は絶対オススメ。

読むべき人:
  • Amazonの使い方がいまいちわからない人
  • Amazonを使って得をしたい人
  • 書評ブロガーの人
Amazon.co.jpで『津田大介』の他の本を見る

にほんブログ村 本ブログへ bana1 ランキングへ


December 12, 2007

ダイアグラム別 UML徹底活用


ダイアグラム別 UML徹底活用 (DB Magazine SELECTION)

キーワード:
 井上樹、UML、オブジェクト志向、入門書、粒度
UMLのダイアグラム別に使い方や基本的なことが書いてある入門書。最近自分の本業に関する本をぜんぜん読んでいないので、これはまずいと・・・。あともしかしたらそろそろUMLを使用した設計を行う必要がるかもしれないので、UML本を。

この本はかなり分かりやすかった。以下のような章になっている。
  1. モデリングのメリットを考える
  2. ユースケース図の注意点と使いどころ
  3. ユースケース記述の注意点と使いどころ
  4. クラス図〜基本編
  5. クラス図〜応用編
  6. オブジェクト図
  7. 相互作用図〜シーケンス図とコラボレーション図
  8. アクティビティ図
  9. ステートチャート図
  10. コンポーネント図と配置図
  11. ダイアグラム間の整合性
  12. UMLとプロセス
  13. 付録1 ソフトウェア開発とオブジェクト指向の基礎
  14. 付録2 開発と管理の「プロセス」を考える
UML本の入門書はいくつか読んだことがあるけど、ダイアグラムの要素の説明はあるけど、どうやって書くか、また何に気をつけて書くべきか、どのフェーズでそれを使用するかということが詳しく載っていないものが多かったような気がする。この本はそれらについてしっかり解説されている。

例えば、UMLのダイアグラムで一番難しいと思われるクラス図作成時の基本的な注意点が以下のように示されている。
  • クラス図を描く目的と記述内容を合わせる
  • クラス名とその中身を合わせる
  • 責務のバランスをとる
  • 属性や操作の重複はなくす
  • クラスとインスタンスの区別を付ける
  • 関連に情報を付ける
  • 多重度を確認する
  • 汎化関係と関連を区別する
  • レイアウトに気を付ける
このように、何に気をつければよいか、まただめな例などが多く示されていて本当に分かりやすい。また、UML1.5と2.0の違いも各ダイアグラムで解説されている。

著者によれば、自分の思ったことを間違いなくスラスラとクラス図で描けるようになったら、かなりUMLをマスターしていると言ってもいいようだ。

どのダイアグラムに共通していえることは、何のために使うのか、そして最終的には何を示したいのかというようなことを最初によく考える必要があるようだ。そうしないと、出来上がった成果物が見当違いのものになってしまうらしい。また、常にダイアグラム内の粒度を合わせる必要があるようだ。

正直、UMLを使って設計をそこまでやったことがなかったので、完成しているクラス図を見るだけで眩暈がしていたwwwまだまだ、使いこなせるとは言い切れないけど、UML恐怖症は解消されたと思う。ただ、これを読んで即UMLを描くことができるかといわれればそれは無理だと思う。そればかりは著者も示しているように、経験を積むしかない。なので自分も頑張ってコツコツとUMLで設計ができるようにならなければ。

いくらこの本が分かりやすいといっても、前提として、Javaなどのオブジェクト指向言語でのプログラミング経験やオブジェクト指向の基本が分かってないと、さすがにちんぷんかんぷんだと思われる。

ケース・スタディ的な内容のもう少し突っ込んだUML本にステップアップする前に読むにはお勧めだと思う。

読むべき人:
  • UMLの基礎を学びたい人
  • どのように描くべきかがいまいち分からない人
  • UML恐怖症の人
Amazon.co.jpで『井上樹』の他の本を見る

にほんブログ村 本ブログへ bana1 ランキングへ


October 21, 2007

3週間完全マスター ソフトウェア開発技術者 2007年版


3週間完全マスター ソフトウェア開発技術者 2007年版

キーワード:
 ITアシスト、ソフ開、参考書、3週間、午前・午後対応
情報処理技術者試験、ソフトウェア開発技術者の参考書。今日がその秋季の試験日であり、これを勉強して挑んだ。ということで、この記事は書評というより、記念記事みたいなもので。内容は以下のようになっている。

第1週 コンピュータシステムの基本理論
 1日目 コンピュータ科学基礎(情報の基礎理論)
 2日目 データ構造とアルゴリズム(データ構造、探索など)
 3日目 データ構造とアルゴリズム(整列、データ操作)
 4日目 コンピュータシステム(ハードウェア)
 5日目 コンピュータシステム(基本ソフトウェア)
 6日目 コンピュータシステム(システム構成/性能評価)
 7日目 システムの信頼性/システム応用

第2週 コンピュータシステムの設計・開発・運用
 8日目 システムの開発と運用(プログラム言語、システム開発手法とプロセ
スモデル)
 9日目 システムの開発と運用(要求分析と設計技法)
 10日目 システムの開発と運用(システム設計、テスト技法)
 11日目 システムの開発と運用(システムの移行と運用、プロジェクト管理)
 12日目 オブジェクト指向分析と設計
 13日目 ネットワーク(データ伝送・OSI・TCP/IP)
 14日目 ネットワーク(LANのプロトコル・WAN)

第3週 コンピュータシステムの応用技術
 15日目 データベース(関係データベースの基礎)
 16日目 データベース(SQLとデータベース設計)
 17日目 データベース(午後/午後玉簑蠅留藹)
 18日目 セキュリティ(暗号化と電子署名)
 19日目 セキュリティ(認証、不正アクセス/ウイルス対策)
 20日目 午後橘簑蠅留藹
 21日目 午後玉簑蠅留藹

この参考書のコンセプトは、試験で必要部分のみを絞込み、効率よく学習することで、3週間でマスターしようというもの。章ごとに必要項目の用語説明などがあり、その後午前問題の過去問、解説、午後問題の過去問、解説という流れになっている。

まぁ、この参考書一本で無謀にもソフ開を受けたが、この本で取り上げられている項目はほぼ試験内容をカバーしていたように思う。午前問題などは15問近くこの本に載っている過去問が出題された。自信を持って解けなかったけど・・・・・。

なので、この参考書を最低2回は繰り返してしっかりやれば合格できそうだなと思った。しかし、自分の場合はじっくりとやるというよりも苦手な分野のみをやっていくというスタンスだったので、どう考えても勉強時間が足りず・・・。合格は無理そうだなぁ・・・。

ただ、あまりよろしくない部分は、用語解説やその章のトピックで必要な知識の説明がかなり省略されているように思われる。なんというか、参考書と過去問題集の中間的なもので、基礎知識は他のもので習得した後、確認のために一通り学習するという使い方がよいと思う。なので、基礎的な部分をじっくり学びたい人には向いていないと思われる。

また、午前問題、午後問題と章が分かれていないので、別々に学習したい人はこれじゃないほうがいいかも。さらに、純粋に過去問題集が欲しい人も。

あと、この参考書はかなりごつくて重い・・・。ページ数が600ページを超えるので。

日数が書いてあるので、学習計画を立てやすいというメリットは大きい。けれど、学習計画をストイックにコミットできる人はいいけど、自分のようにできない人には試験3週間前からやらないほうがいい。

試験結果は12月ごろ。受かっていたらいいなぁという程度。さすがに来年春には合格したいが。

読むべき人:
  • 3週間でソフ開をマスターしたい人
  • 出題範囲を一通り確認したい人
  • ガッツり勉強したい人
Amazon.co.jpで『ソフトウェア開発技術者』の他の本を見る

にほんブログ村 本ブログへ bana1 ランキングへ


September 10, 2007

よくわかる最新情報セキュリティの基本と仕組み


よくわかる最新情報セキュリティの基本と仕組み 増補改訂版―基礎から学ぶセキュリティリテラシー

キーワード:
 相戸浩志、セキュリティ、対策、暗号技術、ポリシー
情報セキュリティについてネットワークの技術から対策の取り組みまで体系的にまとめられた本。以下のような内容となっている。
  1. セキュリティの考え方
  2. 脅威
  3. 暗号技術とPKI
  4. セキュリティ対策
  5. セキュリティポリシー対策
  6. 情報セキュリティの国際標準と法規
最近ではセキュリティの考慮すべき要素として、3大要素の他に3つ加えて6大要素として考えるようだ。以下列挙。
  • 機密性(confidentiality)
  • 完全性(保全性)(integrity)
  • 可用性(availavility)
  • 責任追跡性(説明可能性)(accountability)
  • 真正性(認証性)(authenticity)
  • 信頼性(reliability)
それぞれの説明は省略。信頼性は負荷に耐えられる設計などのことらしい。

脅威の章では、パスワードクラックについて書かれている部分がある。パスワード解析の総当り攻撃をブルートフォースアタックと呼ぶようだ。アルファベット小文字と数字4文字の組み合わせは普通のPCで5分で解析できるほどの組み合わせでしかないようだ。それが、アルファベット大文字小文字と数字の組み合わせ8文字になると指数関数的に増えて、普通のPCのスペックでの解析は数週間はかかるようだ。なので、よくパスワードは長めにして英数字や記号も使いましょうということになる。

3章は暗号技術について。共通鍵暗号から公開鍵暗号、ハッシュ関数、電子署名、PKI、SSLなどの仕組みが解説されている。暗号技術は何度仕組みを勉強してもすぐに忘れて頭に残らない。特にその違いを説明しろとかなるとさっぱり。今回この本をソフ開対策で読んでいるので、この部分は何度も読み返して理解しなければ。

4章で、ファイアウォールの弱点が示されている。正常なアクセスによるDoS攻撃とかにはどうしようもないようだ。

セキュリティに関して技術的な側面でだけでなく組織的にポリシーを策定したりするというところまで理解するにはよいと思う。ただ、情報セキュリティアドミニストレーターなどの試験対策として読んだ場合は、一度だけ読んだだけでは頭に入らない。特に技術的な側面は何度も読んで理解する必要がある。そして問題を解きまくるのがよいかな。

読むべき人:
  • セキュリティについて体系的に学習したい人
  • 情報セキュアドを取得したい人
  • 暗号などが好きな人
Amazon.co.jpで『セキュリティ』の他の本を見る

にほんブログ村 本ブログへ 役に立ったらクリック☆  bana1


August 09, 2007

UMLは手段


UMLは手段

キーワード:
 荒井玲子、UML、勝ち組、アーキテクト、目的
UMLを使いこなすための条件が書かれた本。以下のような内容となっている。
  1. UMLは手段
    1. なぜUMLで四敗するのか
    2. 負け組パターンを分析する
    3. 勝ち組はここが違う
    4. コアコンピタンス経営によるUML戦略
  2. アーキテクトに未来を賭けた
    1. システムトラブルはなぜ繰り返されるのか
    2. アーキテクトに向いている人、向いていない人
    3. 間違いだらけのアーキテクト選び
    4. アーキテクトを育成する
第1部ではただはやっているからUMLで設計してみようというようなプロジェクトでは、UMLを使いこなせず、結局失敗プロジェクトに終わってしまうと示されている。よって、UMLを使うには、UMLの使用目的を明確にし、高い意識を持った人材にしっかりUMLのトレーニングをそれなりの期間受けさせるということが重要なようだ。

2部では、分散システムの分野でアプリケーションのアーキテクチャを構築できる人材が不足していると示されており、そのような仕事を担うのがアーキテクトと呼ばれる技術者と言うようだ。多くのシステムトラブルは、アプリケーション間のインタフェース、トランザクションなどの不整合によって起きるようだ。

アーキテクトに必要な能力は、ピープルスキル、テクニカルスキル、コミュニケーションスキル、変化予測力、美的センスが求めらるようだ。アーキテクトとなるべき人材は全ての能力を最初から兼ね備えている必要はなく、努力や意識付けによってそれらの能力を獲得できればよいようだ。

アーキテクトになるべき人材の選出については、開発経験が増えてきて、コーディング、設計、そしてアーキテクチャ設計と段を追ってアーキテクトになるのではなく、初めからある程度のアーキテクトの方向性を持っている人がなるべきだと示されている。要は、開発経験の長さとアーキテクトの特性は無関係だと。そしてアーキテクト候補として以下の人材が示されている。
  • ミドル開発経験がある技術者
  • 保守開発の経験がある技術者
ここは結構そうなのかなぁと思った。SEと一口に言っても、細分化されてきていて、それぞれの持つ特性を活かさなければならないのだと思った。そして自分にはアーキテクトは向いていないような気がした。

また、アーキテクトになるには地道な努力が必要なようだ。

ムックの記事が本になったものなので、主張は問題の提示とそれの簡単な解決策の提示でしかなく、あまり深掘りされていない印象を受ける。そのため、UMLの使い方を知りたいという人には得るものが少ないだろう。自分はアーキテクトの部分がそれなりに参考になった。こういう技術者のキャリアパスがあるのだなと分かってよかった。

内容がそこまで濃いわけではなく、難しくはないので気軽に読める。通勤電車などで読むとよいかもしれない。逆にこの本に多くを期待してはいけない。

読むべき人:
  • UMLをプロジェクトで使おうと思っている人
  • アーキテクトに興味がある人
  • 開発経験だけ長い技術者の人
Amazon.co.jpで『荒井玲子』の他の本を見る

にほんブログ村 本ブログへ 役に立ったらクリック☆  bana1


July 05, 2007

情報自動生成!集客アップテクニック


情報自動生成!集客アップテクニック

キーワード:
 松本光春、アクセス数アップ、質より量、マッシュアップ、錬金術
早稲田大学助教授によるWebサイトの集客アップ方法が書かれた本。従来、アフィリエイトなどを目的としたサイトの集客アップを図る場合は、ニッチな分野(隙間分野)を探し、コンテンツの量より質を重視し、SEO対策をして徐々にアクセス数の増加とともに売り上げも増やすという方法が定説だった。しかし、この本ではコンテンツの量、つまりコンテンツの質よりも情報量を大幅に増やすことでロングテールを狙い、そこからアクセス数アップと売り上げアップを図るほうが効果的であると主張されている。なるほどなと思った。内容は以下のようになっている。
  1. ウェブの情報量の威力!
  2. 投資先としての情報
  3. 80対20の法則とスケールフリーネットワーク
  4. ハブを目指す時代からロングテールを拾う時代へ
  5. 情報量を利用した具体的な成功事例とその分類
Googleなどの検索エンジンが発展してきたことにより、情報の価値が情報の質×情報量になってきており、サイト上にいかに多くの入り口を設けるかが重要になるようだ。それは昨今話題のロングテールを狙ったものに他ならず、極論すれば、情報を増やすために手作業をする必要はなく、コンテンツの自動生成を行っていけば情報量は格段に増えて、集客もアップできると示されている。

特になるほどと思ったのは、コンビニで目的の商品以外についでに他に何かを買う理論。これはそのままアフィリエイトにも適用できるようで、実際に著者自身が紹介している商品よりも自動生成した商品のほうが多く売れており、その内訳は著者のサイトでは全体の94%にもなるようだ。これは自分も結構実感することであり、自分が書評した本よりも全然関係ない本のほうが売れているので、そのとおりだと思う。

情報の自動化には、Aamazon Webサービスを使用し、プログラムで人気キーワードからXLSファイルを取得、HTML化していけば、自分で更新する手間も省け、勝手に集客が増えてお金も勝手に入ってくるというまさに錬金術のような方法が示されていた。

コンテンツの自動生成か。自分ならできないこともないな。暇ができたらやってみようかな。うまく軌道に乗れば、寝ててもお金が入ってくるな。

著者は大学の教員だけあり、論理展開はしっかりしており、グラフ、図も多くかなり分かりやすい。それにしても、なぜこのようなSEO対策本やアクセスアップ攻略本の表紙はけばけばしいのだろうか・・・。怪しさ満点で少し買うのをためらうんだけどね。

情報の量、サイト内の情報の多様性が集客アップの秘訣なようだ。文学作品などに的を絞った書評ブログにするべきか迷ったこともあるけど、幅広い分野を書評する自分のスタイルで間違っていなかったようだ。何よりも自分の知識欲が幅広いというのもあるけど。結局多く読めば読むほど、金銭的にも知識的にも豊かになれる可能性があるということだろう。

読むべき人:
  • サイトのアクセス数をアップさせたい人
  • アフィリエイトで稼ぎたい人
  • ジャンルを絞るのは好きではない人
Amazon.co.jpで『松本光春』の他の本を見る


June 17, 2007

知識ゼロから学ぶ ソフトウェアテスト


知識ゼロから学ぶ ソフトウェアテスト

キーワード:
 高橋寿一、ソフトウェテスト、基本、技法、境界値分析
著者はマイクロソフト、ソニー、SAPなどを渡り歩いてきたソフトウェアテストの専門家。テストの基本的なことが書いてある。以下のような内容となっている。
  1. テストをはじめる前に(「バグ」とは何かを考える)
  2. ソフトウェアテストの基本(ホワイトボックステスト)
  3. エンジニアが最もよく使う手法(ブラックボックステスト)
  4. ソフトウェアの性能をチェックする(システムテスト)
  5. 攻撃に耐えうるソフトウェアの構築(セキュリティテスト)
  6. その他のテスト手法(スモークテストと回帰テスト)
  7. ソフトウェアテスト運用の基本(テスト成功の方程式)
  8. ソフトウェア品質管理の基本(ソフトウェア品質のメトリックス)
  9. テストの自動化という悪魔(なぜ自動化は失敗するのか)
このように基本的なことが網羅的に書いてある。全て説明するのは冗長なので、気になった部分を絞って解説。

まず1章で、そもそもソフトウェアにはバグは絶対潜んでいるものであり、全てのバグを取り除くことは不可能であることを認識せよとある。そして先人のテストの格言のごとく、著者なりの格言が示されている。
ソフトウェアテストで重要なのは、どの部分に
バグが出やすいのか、そこにどのようなテスト手法を
適用すれば十分な品質が得られるかを知ることである。
―― by Juichi Takahashi
(pp.8)
そしてソフトウェアテスト工程はプログラミング工程ど同等に困難で創造的な仕事であるとあり、それを素人程度のスキルの低い新人にやらせることはそのソフトウェアの品質や企業の良識を疑われることになるとある。確かにそのとおりだよなと思う。単純にテスト結果をPass、Failと記録するだけなら新人でもできるが、バグを網羅的に発見できるテストケースを書くのはかなり困難だよなと最近実体験から思う。

3章では、エンジニアが最も使う手法であるブラックボックステストがあるが、これは『プログラムを一種のブラックボックスと見立て、様々な入力を行うことによってソースコードを利用せず(見ずに)にテストを行う方法です。(pp.46)』と示されている。そのブラックボックステストの基本に同値分割法と境界値分析法があるようだ。特に参考になったのは同値分割法で、どのようにテストケースを減らすべきかという部分。A,Bという変数のとりうる入力値の範囲を座標で示し、その中で重複している部分は除くことができると示されている。ただ、その省略されたテストケースでバグを発生させてはいけないとあるのでもっともだと思った。

また、分岐などの境界になる値を調べる境界値分析法では、0は常にバグになりやすい数であるので、境界であるか否かとは無関係にチェックするべきだとあり、参考になった。

5章で示されている、セキュリティテストとはハッキングなどに耐えうるシステムをテストすることであるが、その手法がまだまったく確立されていないのが現状なようだ。そもそも従来のソフトウェアテストはプログラムミスによるバグの障害を防ぐことを目的とされた方法論だったのに対し、セキュリティテストは従来のテスト手法から逸脱、もしくは著しく乖離せざるを得ないからのようだ。この章のコラムにセキュリティテストができる人材を確保するのは非常に困難であるとある。なぜなら、一般的なテストスキルのほかに、暗号化、セキュリティシステム、最低限のアセンブラの知識が必要になるからのようだ。もし社内にセキュリティに非常に関心を持ち、かつテストをすることも好きな人がいたらどんなに高収入を払っても辞めないようにするべきだとある。なるほどなぁと思った。

他にも面白かったコラムとして、『テストの才能のある人とは』というものがあった。テストの分野において才能のある人は普通の人の10倍の数のバグを見つけられるようで、そういう人をテスト担当者として雇うべきだとある。また、そのような人は見つけるのが困難で、学歴や頭の切れとは全然関係ないようだ。なるほどなぁと思った。テストの才能と言うと、あらゆる動作確認を網羅的にかつ地道にこなせるかどうかじゃないかと思う。そういうのを楽しめるかどうかが分かれ目なのではないかと思う。もしくは他人のあら捜しが好きな人とかwww。そうなったら、テスト担当者は開発者からの嫌われ役だな。

ソフトウェアテストの基本は、計画をきちんと立て、スケジュールを守り、テストケースを的確に実行するだけだとある。それによりバグのない製品ができるようだ。その基本的なことは、マイクロソフト、ソニー、SAPでもそんなに変わらないとある。そのとおりだよなと思う反面、テスト工程をしっかり重要視しているかどうかでその差が出るのではないかと思った。

テストに関する基本的なことが学べてよかった。著者はソフトウェアテストの専門家で博士号を持っているが、研究一筋ということではなく現場のプロジェクトでの知見が基に書かれているので、信頼性が高いと思われる。単純なテスト手法の解説だけではなく、テスト時の運用におけるコストに関することまで網羅されているので参考になった。

また、著者はテストマネージメントは基本が大事というよりも広範な知識が必要だと主張しており、以下の2冊をお薦め本として挙げている。この二つもチェックしようと思った。
基本から学ぶソフトウェアテスト―テストの「プロ」を目指す人のために
基本から学ぶテストプロセス管理―コンピュータシステムのテストを成功させるために

読むべき人:
  • ソフトウェアテストについて基礎から学びたい人
  • 同値分割法、境界値分析法について知りたい人
  • テストケースが思うように書けない人
Amazon.co.jpで『ソフトウェアテスト』の他の本を見る


May 24, 2007

Systems Engineer Vol.1


Systems Engineer Vol.1

キーワード:
 技評SE新書特別版、SE、キャリアパス、啓蒙書、20代
技術評論社から出ているSE新書の特別版。ムック形式。副題として『SEが20代で身につけておきたいこと』とある。SEなどを20年近くやってきた著者らによる若い人向けのSEの心構えを説いた本。以下のような内容となっている。

特集1 SEが20代で身につけておきたいこと
  1. プロフェッショナル思考
  2. 論理的な知識と現場の経験
  3. 新しい視点に基づく「構想力」
  4. 自分自身への投資
  5. 役割を意識する
特集2 SEのキャリアパス
  1. プロジェクトマネジャー
  2. アーキテクト
  3. コンサルタント
  4. スーパープログラマー
  5. インストラクター
他にコラムとして『オブジェクト指向への招待』、『Javaの基本書を読む』がある。

特に特集1が参考になった。20代は技術者として基礎固めの時期であり、この時期をどのように過ごすかで30代でバリュー発揮できるようになっているかどうかの分かれ道になるようだ。例えば、基礎を作るために以下のことをやる必要があるようだ。
  • ソースコードを書く、読む
  • ソフトウェアの拡張・修正の種類を知る
  • 自分のバイブルとなる専門書を見つける
  • 観察記録を書く
優れたソフトウェア技術者はソースコードを大量に読み書きするという経験が必要なようで。また、身につけるべき基本として以下が示されている。
  • ITの基礎知識
  • IT利用の基礎知識
  • ビジネスの基礎知識(従来型のビジネスとネットワークビジネス)
  • 英語力
  • これから伸びる分野の理解
  • 自分の向き不向きに対する理解
英語力が必須なのは、最新技術は特にアメリカが発祥なので、それを翻訳されるのを待っていたのではビジネスチャンスを逃すのでだめだと。日本語だけの範囲の仕事しかしないとなると長期的には一人前にはなれないと示されている。

また、技術者として生きる以上常に学習して行かなければならないとある。会社に能力開発を頼っていてはだめだと。特に30代、40代にもなってC言語しか使えませんというのでは致命傷だと。そのため、学習を習慣化するようにすべきとある。そして地道に勉強していく必要がるようだ。

特集2はIT技術者のキャリアについて示されている。とくにアーキテクトは今まで漠然としか把握していなかったので、参考になった。縁の下の力持ち的な存在で基盤的なアーキテクチャから業務内容についても把握しておりプロジェクトのタスク管理などもこなせる必要があるようだ。

スーパープログラマーの章では、初心者から上級者、そして匠まで7段階の技術レベルが示されている。自分は初級職人を修了しようとしているところかな。

優れたSEになるには何をどう考えていかに行動していくべきかということがよくわかって参考になった。やはりプロのIT技術者として生きる以上地道に努力していくしかないのだと分かった。それを10年、20年の長期的な視点でやらなければならないようだ。意識が高まった気がする。

著者は5人ほどだが、どのひともSE、IT技術者として誇りを持って働いているということが良く感じられたような気がする。

この出版社のSE新書はいろいろ読んだことがあり、他にも読んだことのないものがあるのでそれを読んで勉強してみようかな。あと、もっとプログラムをやろうかと・・・。

読むべき人:
  • 20代のIT技術者
  • プロの技術者として成長したい人
  • IT技術者としてキャリアパスを考えたい人
Amazon.co.jpで『SE新書』の他の本を見る


May 22, 2007

達人プログラマー―システム開発の職人から名匠への道


達人プログラマー―システム開発の職人から名匠への道

キーワード:
 アンドリュー・ハント、デビッド・トーマス、自己啓発、スキルアップ、ヒント、実践的
より効率的、生産的なよりよいプログラマーになるために必要なことが書かれた本。かなりの良書。値段は4000円近くだが、買って損はない。

原題は『The Pragmatic Programmer』であり、達人と訳されている。Pragmaticは実践的という意味。ソフトウェア開発に必要な行動指針やヒントが多く書かれている。以下のような内容となっている。
  1. 達人の哲学
  2. 達人のアプローチ
  3. 基本的なツール
  4. 妄想の達人
  5. 曲げるか壊すか
  6. コーディング段階
  7. プロジェクトを始める前に
  8. 達人のプロジェクト
まぁ、この目次だけでは内容がいまいち分かりにくいので、各章を簡単に説明してみる。

1章は普通の人と達人の違いについてで、達人になるためには眼前の問題を考えるだけでなく常にその問題をより大きな背景の中で捉え、より大きな問題について気付こうとする姿勢が必要とあり、自分のソースコードに責任を持つことや質の悪いコードを放置しておかないことや、常に技術を学習し続けよとある。

2章では開発におけるアプローチが示されている。例えば、コードやドキュメントの2重化は避けろということやコードの直交性(独立性)をつねに意識すべきといったことが示されている。

3章では、達人たるものは生産的な作業を行うためにエディタやCVSなどのツールを使いこなせないとならないということが示されている。

4章では完璧なソフトウェアを作ることは不可能であるということを前提に防衛的なプログラミングを行う必要があると示されている。デバッグの仕方や例外の使い方が示されている。

5章ではコードの柔軟性と適用性を保つためにどうすればいいかということが示されている。例えば、モジュール間の結合度を減らす、コード量を減らすといったことが示されている。

6章ではコーディング時に偶発的なプログラミングになることを避けろとある。つまり、自分が何を意図してコーディングをしているのかということをしっかり把握し、また自分のコードを再点検するためにリファクタリングを実行すべきとある。

7章では主に要求分析段階での内容で、要求分析ではユーザの話を聞くだけでは足りないので要求を掘り起こすことが重要であるとあり、さらにコーディング時や要求に対して問題が発生した場合は、枠にとらわれず違った視点で考えてみることが大切とある。

8章ではプロジェクトの成否を分けることにテストと自動化が挙げられている。テストは何をどの程度やるのかといったことが示されており、自動化に関しては、何度も繰り返して行わなければならないようなことは全てバッチやシェルスクリプトを使って人的ミスを少なくせよとある。

どの章もあるあるwwwとうなづきながら読んだ。それだけ自分が体験してきたことに対して的を射た内容となっている。全体を通して70のヒントが示されているが、以下に特に自分がそのとおりだと思ったものを抜粋。
  • ヒント1: 自らの技術に関心を持つこと
  • ヒント3: いい加減な言い訳よりも対策を用意すること
  • ヒント8: 常にあなたの知識ポートフォリオに投資すること
  • ヒント11: DRY―Don't Repeat Yourself (繰り返しを避けること)
  • ヒント18: あとでびっくりしないために、見積もりを行うこと
  • ヒント21: コマンド・シェルの力を使うこと
  • ヒント27: 仮定せずに、証明すること
  • ヒント30: あなたは完璧なソフトウェアを作ることができない
  • ヒント44: 偶発的なプログラミングを行わないこと
  • ヒント50: 理解できないウィザードのコードは使わないこと
  • ヒント61: 手作業は危険である
プロジェクトをひとつ経験したあとに読んだので、本当にそのとおりだなと思うことばかりだと思った。特に、ヒント3などは、「できない」とか「それは無理」と言わずに、ではどうやったらできるようになるかという姿勢が問われる内容だと思った。ヒント8は達人プログラマーになるためには常に知識に対して投資を行う、つまり書籍やネットなどで技術を学習し続けなければならないとあった。やはりそうでないといけないようだ。

また、ヒント27では、バグが発生したときは、バグのわけがないと思い込む危険性を指摘しており、バグになったからにはそれを客観的に証明する必要がある。これは自分もプロジェクトに参加していたときに、自分が改修したものがあとでエラーが発生したときに痛い目を見た。SQL文で取得したデータのバリデーション部分だったのだけど、自分の思い込みでこのようなデータだろうと思って修正したが、実際は違っていた。まさに思い込みはだめで、必ず証明する必要があるなと実感した。

他にも、ヒント61なども、DDL文作成時に手作業が多く、初期のころはミスしてばかりだった。そのため自動化すべきだと言われていたが結局、ヒント21にあるようなコマンド・シェル、つまりシェルスクリプトに精通していなかったために実現できなかったりと耳が痛いことが多い・・・・。

各節のはじめに偉人の格言などが引用されている。洋書の技術本はこういうのが多いなと思う。その格言が言い当て妙なので、いいなと思う。

ところどころプログラムが出てくる。C言語、Perl、Java、C++など。特にリファクタリングの部分や例外の扱い方の部分に多い。また、各章に演習問題があり、クラスを実装しろとかこのコードのリファクタリングをしろとか、ケーススタディ的な問題などもある。そのため、オブジェクト指向言語を理解していると分かりやすいと思う。

かなりの部分に線を引いた。技術書でここまで線を引くことはほとんどない。達人プログラマーになるための啓発的な内容となっており、ユーモアたっぷりなので読み物としても面白いと思う。

身にしみることばかり書いてある気がした。プロジェクトにアサインされる前、またリリース後に読み返してみるとまた勉強になるかもしれない。

買って損はない。絶対。IT技術者として生きるならこれは必読。あと、なによりもカバーが漆黒にゴールドの字体なので玄人っぽいデザインなので飾っておいてもいいと思う。もちろん、読後はかなりスキルアップした気もするけど。

読むべき人:
  • スキルアップしたいIT技術者の人
  • プロジェクトでバリューを発揮したい人
  • 格言が好きな人
Amazon.co.jpで『プログラマー』の他の本を見る


May 15, 2007

ハッカーと画家 コンピュータ時代の創造者たち


ハッカーと画家 コンピュータ時代の創造者たち

キーワード:
 ポール・グレアム、ハッカー、オタク、ベンチャー、Lisp、思想
プログラムが神がかかっている人種、ハッカーが何を考えているのかがよく分かる本。とても興味深い内容。数ヶ月かけて読んだので、内容を完全に把握していない。最初のほうを忘れてしまったけど、なるほどなるほどと面白がって読んだ部分が多かったのは確か。以下のような内容となっている。
  1. メイド・イン・USA
  2. どうしてオタクはもてないか
  3. ハッカーと画家
  4. 口にできないこと
  5. 天邪鬼の価値
  6. もうひとつの未来への道
  7. 富の創りかた
  8. 格差を考える
  9. スパムへの対策
  10. ものつくりのセンス
  11. プログラミング言語入門
  12. 百年の言語
  13. 普通のやつらの上を行け
  14. オタク野郎の復讐
  15. 夢の言語
  16. デザインとリサーチ
  17. 素晴らしきハッカー
17章構成だが、本の目次では0章から16章構成となっている。随想的な内容なのでどこの章からでも読める。

著者は大学院で計算機科学を専攻した後、美術学校で学んだようだ。そこからハッキングと絵を描くことは共通点があると主張している。ハッカーがハッキングを学ぶ方法は、画家が絵を描きながら学ぶのと同じであるとある。また、先例から学ぶことも同じであるとある。つまり画家にとって偉大な画家の作品を模写していくことで成長するように、ハッカーはオープンソースのコードを見ながら学ぶことができるとある。このような視点が面白いと思った。

ハッカーの生態をあらわす例として、ハッカーは規則に従わず、企業で何時間も会議をしてうるさい職場で働くくらいなら、静かな自分の部屋で仕事をすることを好んだり、そもそも企業には勤めず研究者として好きなプログラムを作ることを好むとある。また、真のハッカーは自分で自分のすごさは分かっておらず、ある人がハッカーであるかどうかはプロジェクトなどで一緒になって働いてみないと分からないとある。なるほどなと思った。

著者はオンラインストアをユーザ自身が作成できるようにするというベンチャー企業を立ちあげ、成功に導いた。これが『普通のやつらの上を行け』の章の内容で、Lispを使っているベンチャー企業は要注意とある。なぜならソフトウェアビジネスを行おうとしているベンチャー企業にとっては、選択する技術によって成功かそうでないかが左右されるからだ。そして著者らはLispを選択し、それにより競合他社よりも早くコーディングをすることができ、競争に勝てたようだ。なぜJavaでもなくC++でもなくPerl、Pythonではなく、Lispなのかというと、Lispこそが一番パワフルな言語だからだとある。Lispにある強靭なマクロ機能によってプログラムを生成するプログラムを実現でき、その部分が他の言語にはまねできない部分であるとある。Lispはそんなにすごいのかなと思った。実際にLispを使ったことがないから分からないけど。

最後の章でハッカーになるにはどうすればよいかが述べられている。以下のその部分を抜粋。
 良いハッカーになる鍵は、たぶん、自分がやりたいことをやることだ。私が知っている素晴らしいハッカーを考えてみると、彼らに共通することのひとつは、彼らが自分から望まないことをやらせるのは極めて難しいだろうということだ。これが原因なのか、結果なのかは定かではない。もしかすると両方かもしれない。
 何かをうまくやるためには、それを愛していないければならない。ハッキングがあなたがやりたくてたまらないことである限りは、それがうまくできるようになる可能性が高いだろう。
(pp.237)
なるほどなと思った。逆に、自分は仕事でプログラミングはするが、趣味としてまでプログラミングやハッキングをやりたいと思わないので、それが自分の限界なのではないかとも思ってしまった・・・。一応本業だけにね・・・。

ダ・ヴィンチの絵や1973年型のポルシェ911Eの写真、若いころのオタク少年の著者の写真、はてはスピード違反で捕まったときに警察で撮られたビル・ゲイツの若いころの写真まで出てくる。1ページ内の文字数は多めだが、視覚的に楽しめる。ちなみに、表紙の絵はブリューゲルの『バベルの塔』。

いろいろな視点で物事を考えられているので、勉強になる。単純にハッカーなどのコンピュータ技術にあまり興味のない人も読めば参考になると思われる。自分のようなプログラマーは読んで絶対損はない内容だと思う。

読むべき人:
  • ハッカーになりたい人
  • 気軽にコンピュータの話を読みたい人
  • Lisp使いの人
Amazon.co.jpで『Paul Graham』の他の本を見る


May 02, 2007

図解入門よくわかる最新Oracleデータベースの基本と仕組み


よくわかる最新Oracleデータベースの基本と仕組み 第3版―構造と機能から学ぶOracle11g入門 先進の高可用性とスケーラビリティ

キーワード:
 水田巴、Oracle、データベース、入門書、全体像
Oracleの全体像がわかる入門書。以下のような内容となっている。
  1. Oracleの概要
  2. データベースの基礎知識
  3. メモリ構造とプロセス
  4. ユーザーと権限
  5. データベースオブジェクト
  6. データベース構造と領域管理
  7. フラッシュバック機能の仕組み
  8. データ保護の仕組み
  9. Oracleとネットワーク
  10. SQL*PlusとiSQL*Plus
  11. データベースの運用と管理
  12. 自動管理機能の仕組み
  13. 高可用性の仕組み
  14. エンタープライズ・グリッドコンピューティングの仕組み
  15. 分散データベースアーキテクチャの仕組み
  16. データウェアハウスの仕組み
  17. コンテンツ管理の仕組み
  18. アプリケーションの管理
Oracleの全体像が満遍なく解説されている。図も多く載っている。しかし、その図が必ずしも分かりやすいとはいえない。また、用語の解説が本文に載っているが、それが分かったような分からないような微妙な説明の箇所が少なくない。そこはよく読まないと分かりにくい。

Oracleの基礎的な全容などを勉強しようと思っていろいろ書籍を探し回ってみたけど、これ以外にまともなものがないのが現状。かといってOracleのオンラインマニュアルは情報量が多すぎて読む気が失せる・・・。この本は入門書レベルだが、前提としてリレーショナルデータベースの概要が分かっていないと、さっぱり内容が分からないと思われる。

Oracleはいろんな機能があるのだなぁと思った。特にエンタープライズ向けに使われることがほとんどなので、堅牢でセキュアなものだと思った。例えばフラッシュバックという機能がある。これはある特定時点の情報を持ってきたり、その時点に戻ったりする機能で、フラッシュバック・バージョン問い合わせ、フラッシュバック・トランザクション問い合わせ、フラッシュバック・データベース、フラッシュバック・テーブルなどさまざまな用途に合わせて使い分けられる。

Oracleなどのデータベースは実際に動いているものをいじってみないと、感覚的に分からないと思われる。この本で得られるのは実際に動いているものを触る前の、予習的なものだろう。そのため、実践的なことはあまり書かれていない。

Oracleを使いこなすにはかなり熟練しなければならないなぁと思った。Oracleマスターなんてものがあるけど、やはり上のクラスほど価値があるのだと思う。

Oracleの仕組みや全体像がある程度分かってよかった。

読むべき人:
  • Oracleの全体像がわからない人
  • DBに興味がある人
  • DBはSQL文さえ分かればいいと思っている人
Amazon.co.jpで『水田巴』の他の本を見る


January 27, 2007

87のキーワードから学ぶOracleデータベース


87のキーワードから学ぶOracleデータベース

キーワード:
 山田精一、菅原剛、Oracle、リファレンス、用語、基本
Oracleデータベースの用語解説本。Oracleを扱ううえで知っておかなければならないような87の項目が解説されている。扱っている内容は以下のようになっている。
  1. 基本機能編
  2. Oracleのアーキテクチャ編
  3. ネットワーク
  4. SQLとPL/SQL
  5. 運用管理の機能
  6. 大規模DWH系の機能
  7. 大規模OLTP系の機能
  8. 分散データベース
  9. パフォーマンスチューニング
仕事でOracleを使用しているが、基本的なことがまったく分かっていなかったので、読んでみた。各項目が4ページほどなので分かりやすい。

Oracleをまともに使いこなそうと思うと、知っておかなければならないことが多いんだなと思った。単純にMySQLなどをWebアプリケーションで使う分には、基本的なDML文を知っていれば問題ないような感じだが、Oracleとなると、基盤よりの知識がないとさっぱり分からない。そういった部分にまでしっかり対応している本だと思う。

ただ、Oracleとはどのようなものかという初歩的な内容を事前に把握しておかないと、漠然と読むことになり、いまいち完全に理解しきれない。この本はOracleのマニュアルにある用語の理解の補助になることを目的として書かれているので、どちらかというと最初から最後までしっかり読むというのではなく、知りたいキーワードを拾って読んでいくほうがよいと思われる。正直自分の場合は、後半の部分はピンと来なかった。ここらへんは、もう少しOracleに精通したときに意味が分かるのかもしれない。

マニュアルを読むときの副読本としてお勧め。きっと何度も読み返す必要のある本だと思う。

読むべき人:
  • Oralceの基本を学習したい人
  • Oracleの用語が分からない人
  • 用語集が好きな人
Amazon.co.jpで『Oracle』の他の本を見る


December 18, 2006

Excel2003マスターバイブル


Excel2003マスターバイブル

キーワード:
 C&R研究所、Excel、リファレンス、網羅性、入門書、使い方本
Excelの使い方本。かなり分厚く773ページもある。対応バージョンは2003。初版は2004年3月5日。価格は2800円+税。以下のような内容となっている。
  1. Excel2003の基礎知識
  2. データ入力
  3. データの編集
  4. データの装飾
  5. 表の体裁
  6. 数式の入力・編集
  7. 関数の入力・編集
  8. グラフ作成・修正
  9. 図形・イラストの作成・修正
  10. データベース機能と集計
  11. データの分析
  12. 印刷の実行
  13. ファイルの操作
  14. マクロ機能の活用
  15. Web機能の活用
  16. その他の便利機能
基礎的なデータ入力からピボットテーブルや統計機能を使ったデータ分析まで幅広い内容となっている。この本の特徴としては、分厚い割りに軽量で開きやすい製本となっている。紙質が他のものよりも違っている。また、内容的にはカラーで画面図などが大きくて見やすい。このような技術本では、1ページに2段組になっているものがある。それは1行に表示される文章が短くて個人的には読みにくく感じるが、これはそうではなく文章の1行が長いので割りと読みやすい。

ExcelなどのOffice製品はどちらかというと、使いながら各機能を覚えていくということが多いが、それではどうしても自己流になり効率が悪いときがある。そのためこのようは本でひと通り使い方を基礎から学んでみた。結構自分の知らない機能が多かった。以下それらの機能。
  • 表の1行をフォームを使って入力する
  • ドロップダウンリストを自分で設定する
  • ジャンプコマンド(Ctrl + G)
  • 条件付書式
  • 形式を選択して貼り付けの使い方
  • 印刷時のページ設定で複数ページにまたがる表に見出しをつける方法
  • 図のリンクの貼り付け機能
などなど。Excelをある程度使いこなしているつもりだったが、そこまでではなかった。結構便利な機能が用意されているんだなと思った。

巻末にはショートカット一覧が載っているが、全ては網羅されていない。結構このショートカットが重要であったりするので、そこはちょっと残念だ。なぜならExcelのショートカットを使いこなせるようになると、かなり作業効率がアップするし、何よりもマウスを使わずキーボードだけで操作できるようになると、かなりハッカーみたいでかっこよいから。

全ての機能を網羅的に説明している分、こういうときはこうすればよいといったサンプルが少なくなる。特に関数の章では、使用頻度の高いものしか紹介されていない。また、マクロの部分もマクロの使い方がメインとなっているので、便利なマクロのサンプルが少ない。それらは他の本で補うしかない。

全てを実際に試しながらやると、かなり時間がかかると思われる。それでも、1つ1つの機能を使いこなせるようになるという喜びが結構あった。

読むべき人:
  • Excelの基本的な使い方をひと通りマスターしたい人
  • カラーの技術書が好きな人
  • 軽い本が好きな人
Amazon.co.jpで『C&R研究所』の他の本を見る


December 14, 2006

ライト、ついてますか―問題発見の人間学


ライト、ついてますか―問題発見の人間学

キーワード:
 ドナルド・C・ゴース、G.M.ワインバーグ、問題の本質、発見、挿話、視点を変える
コンピュータ技術者、コンサルタントである著者らによる、問題について考えるための本。以下のような内容となっている。
  1. 何が問題か?
  2. 問題は何なのか?
  3. 問題は本当のところ何か?
  4. それは誰の問題か?
  5. それはどこからきたか?
  6. われわれはそれをほんとうに解きたいか?
これらのことに関して、挿話を基に日常で起こるさまざまな問題の本質的なことは何かということをしめし、そこから教訓が示されている。例えば、タイトルになっている『ライト、ついてますか』は、「トンネルのかなたのあかり」という挿話が基になっている。内容はこうだ。

ある山中の観光スポットの近くにトンネルが開通した。トンネルの設計技師は、トンネル内で運転手がライトをつけて安全に走れるように、前方にトンネルがあるのでライトをつけてくださいという標識を出した。それにより、どの運転手もライトをつけるようにはなった。しかし、そのトンネル後のパーキングエリアで、ライトを消し忘れてつけっぱなしにしていた車のバッテリーがあがるという問題が発生した。そこで、どうすればこの問題を解決できるかということを設計技師が考えるという挿話。この話では、運転手、技師、警官たち、自動車連盟などと問題に関わるであろう登場人物の中で、誰の問題であるのかということを考える必要があるとある。最終的には、技師がトンネルの最後に『ライト、ついてますか?』と標識を出すだけで解決できたという話。

それぞれの話の途中や最後に、問題に関して本質的に的を射ている格言のようなものが多く出てくる。どれもなるほどと思うようなことが多い。いくつか抜粋してみる。
  • 問題とは、望まれた事柄と認識された事柄の間の相違である(pp.15)
  • 問題の正しい定義が得られたかどうかは決してわからない、問題が解けたあとでも(pp.43)
  • すべての解答は次の問題の出所(pp.53)
  • キミの問題理解をおじゃんにする原因を三つ考えられないうちは、キミはまだ問題を把握していない(pp.56)
  • 問題の出所はもっともしばしばわれわれ自身の中にある(pp.118)
どれも著者の経験則的なものから導かれているような気がする。これらはどれも自分の経験と照らし合わせてみると、そのとおりだと妙に納得してしまう。

ページ数も少なく、アメリカっぽい変な挿絵が多く入っており、エッセイのような感じで気軽に読める。しかし、訳があまりよろしくない。原文が想像できるような日本語になっている。1987年初版、56刷発行なのでかなり売れているようだ。そろそろ改訂版が出てもいいような気もする。

一応技術書の分類にしたが、これは別にコンピュータの話がよく出てくるような技術書ではない。問題を考える上でのヒントになる部分が多く含まれていて、普通のビジネスシーンでも応用できる良書だと思われる。Amazonでの評価もかなり高いようだし。この本を読んで、問題を多面的に捉えることができるようになった気がする。

読むべき人:
  • SE、プログラマーなどの技術者
  • コンサルタントのように問題解決を仕事とする人
  • 教訓的な話が好きな人
Amazon.co.jpで『G.M.ワインバーグ』の他の本を見る


November 07, 2006

JUnitと単体テスト技法―JUnit4対応


JUnitと単体テスト技法―JUnit4対応

キーワード:
 福島竜、JUnit、単体テスト、Java、テストファースト、ブラックボックステスト
JUnitの使い方本。この本で111冊目。

JUnitを簡単に説明すると、Javaのテストコードを書くためのオープンソースのフレームワーク。主に単体テスト実施時に利用される。単体テストを行うときに、メソッドが正しく動作しているかどうかをいちいち手動でやっていると時間がかかり、しかも漏れがある可能性があるので、JUnitのようなツールを使って簡単にかつ短時間にテストができますよという優れもの。

この本は以下のような構成になっている。
  1. テストファースト―見えてくる問題
  2. テストの基礎
  3. 単体テストの技法
  4. JUnitの概要
  5. JUnitの詳細
  6. EclipseとJUnitによる単体テスト
  7. テストケースを考える
  8. Webアプリケーションのテスト
はじめの章では、テスト対象のコードを書く前にテストコードを先に書くというテストファーストを体験しましょうという内容。そのため、JUnitの概要説明がないままいきなりテストコードの書き方から入る。

1章でテストファーストの重要性を理解してから、2章ではVモデルに沿ってテストの種類と目的などが解説されている。

3章で単体テストの方法について解説されている。ホワイトボックス、ブラックボックステストの違いや、同値クラステスト、境界値テスト、デシジョンテーブルテストなどの基本的なことなど。

4章でようやくJUnitの概要や基本的な使い方について説明されている。

5章でJUnitを利用するためのテストコードの書き方やAssertクラスの使い方が解説されている。

6章はEclipseのプラグインとしてJUnitの使い方が説明されている。

7章は、商品の代金を計算するプログラムを例題に挙げ、境界値を意識しながらテストケースを作成し、その後テストメソッドをコーディングするという内容。

8章は、WebアプリケーションをテストするためにCactusというフレームワークを利用するというもの。

以上のようにJUnitについて網羅的に書かれている。表紙の印象やページの構成から、なんだか教科書的な感じがする。

JUnitはテストファーストが重要なようだ。テスト対象コードよりも先にテストコードを作成するというのは難しいなと思う。実際にテスト対象コードを書いてからテストコードを書いたほうが効率がいいんじゃないかと思ってしまうが・・・。しかし、テストファーストはプログラムの仕様を明確にできることや、テストプログラムを書き忘れたりすることがないという利点があるようだ。

JUnitはテストファーストを実践するためにあるようなフレームワークなので、いかにもXP的なものだなと思っていたら、JUnitの開発にXPの提唱者のケント・ベックが関わっていたようだ。納得。

この本で特に役に立ったのは、3章、5章か。特にテストケースを考えるときに、入力値チェックの時に使用する境界値をどのように捉えるかが勉強になった。また、テストコードの書き方で、assert系メソッドの使用で気をつけなければならないことなどが示されていて参考になった。

また、付録には簡単な用語集やJUnit、Eclipseのインストール方法が載っている。丁寧な印象を受ける。

ただ、7章でテストケースがずらっと網羅されているけど、こららを全てじっくり見るには結構時間がかかると思う。そのため、眺めるだけでは頭に入ってこないと思う。テストケースの書き方は、実際に何かプログラムを基にして考えていくしか身につかない気がした。

JUnitをしっかり使いこなせるようになると、単体テストがかなり楽になると思われる。

読むべき人:
  • JUnitを使いこなしたい人
  • 単体テストを楽に行いたい人
  • XPのテストファーストをやりたい人
Amazon.co.jpで『JUnit』の関連の他の書籍を見る


November 01, 2006

標準JSP/サーブレット教科書


標準JSP/サーブレット教科書

キーワード:
 片山幸雄、JSP、サーブレット、サーバサイドプログラミング、Java、教科書
JSPとサーブレットについて書かれた技術書。以下のような内容となっている。
  1. World Wide Webのためのプログラム
  2. JavaとJSP
  3. Web関連規格への対応
  4. サーブレットとセッション管理
  5. サンプルプログラムを作る
  6. データベースを利用する
6部構成で、合計15章からなる。第一部ではよく利用されるHTMLフォームについて解説されている。

2部ではJSPの基本文法やアクションタグやJSPを使用したサンプルプログラムなどが載っている。

3部では、ヘッダ情報やクッキー、JavaBeans、グラフィックスの利用方法などが解説されている。

4部ではサーブレットの基本的な使い方、セッションの使い方、カスタムタグについて。

5部では、掲示板のサンプルプログラムと、メールライブラリを利用したWebメーラーのサンプルプログラムが紹介されている。

6部では、DBとしてMySQLを使うためにJDBCの使い方が解説されている。また、応用プログラムとして、ショッピングサイトのサンプルプログラムが紹介されている。

教科書とタイトルについているだけあって、一通りサーバサイドプログラムで必要なことが網羅されている。かといって、教科書と名乗れるほどのものかは微妙だが。

図が少なく、解説が分かりにくいところがある。また、JSPを先に説明しているので、サーブレットとの関係が少し分かりにくい。

あと、JSP内で処理内容を詰め込みすぎているのではないかと思えるようなサンプルプログラムがいくつかある。これは、JSP的にそのように書いたほうが都合がよいからだろうけど。

また、初版が2006年10月1日と最近出版されたようだ。それだけに、いくつかプログラムのミスや本文中の記述ミスと思われる部分がある。そこは、技術本としては信頼性を損なう要因だと思う。

付録に以下のソフトウェアのインストール方法が載っている。
  1. JDK5.0
  2. Tomcat
  3. JavaMail
  4. Apache James
  5. JAF(JavaBeans Activation Framework)
  6. MySQL
  7. JDBCドライバ
このような付録が載っているのは結構重要だと思う。

初めてJSPやサーブレットを本格的に学習したけど、PHPと結構違うところが多いなと思った。今までPHP、MySQL、SmartyというMVCモデルで開発したことがあった。JSPやサーブレットを利用したMVCモデルも示されているが、PHP、Smartyを利用したMVCモデルほど厳密にViewとModelとControllerが分かれていない印象を受ける。JSPに結構処理部分が多く書かれていて、HTMLタグ部分との関連がいまいち分かりにくいような気がする。Smartyというテンプレートエンジンがあれば、結構厳密にViewとその他を分けられるのだが。まぁ、あとは書き方の問題だろう。

ググってみると、Javaにもいろいろテンプレートエンジンがあるようだ。

それなりによい本だったような気もする。入門書過ぎてもダメで、かといって専門的過ぎる内容でもダメだという人にはよいかもしれない。

読むべき人:
  • Javaの基本文法は理解している人
  • Javaでサーバサイドプログラミングをしたい人
  • ショッピングサイトなどを作ってみたい人
Amazon.co.jpで『片山幸雄』の他の本を見る


October 20, 2006

Visual Basic.NET―速効!図解プログラミング


Visual Basic.NET―速効!図解プログラミング

キーワード:
 きたみあきこ、VB.NET、プログラミング、図解、カラー、評価版Visual Studio.NET
VB.NETの入門書。初版が2003年3月。Visual Studio.NET professional2002versionの60日評価版とサンプルプログラムが付録にある。以下のような章になっている。
  1. Visual Studio.NETの基本
  2. 簡単なプログラムの作成
  3. 基本的なコントロール
  4. オブジェクトと変数
  5. 条件分岐
  6. コントロールの活用1
  7. コントロールの活用2
  8. 応用的なテクニック
  9. 繰り返し処理
  10. クラスの利用
  11. 数当てゲームの作成
入門書なので、かなり見やすく作られている。カラーで、プログラム入力画面の横に解説が載っている。VBを初めて触れる人にはよいかもしれないが、本格的に勉強しようと思う人には物足りないと思われる。特に、VB.NETになってからは、完全にオブジェクト指向をサポートしているが、オブジェクトやクラスの部分の説明がかなり少ないので、分かりにくい。

どちらかというと、VB独特のフォームの編集やVBの基本的な構文を学びたいと思う人向けだと思われる。

なるべく早く概要を理解したい人にはいいかもしれないが、これ一冊ではカバーしきれないので、次の書籍に行くべきだと思う。また、対応バージョンが古いので、そこはよく確認するべきだと思われる。

最近VB.NETをはじめてやってみたけど、.NETは結構すごいんじゃないかと思った。以前は、VBはただのWindowsアプリを作るための初心者用のプログラム言語だと思っていたけど、オブジェクト指向になると結構いろいろなものが作れるのではないかと思った。まぁ、トレンド的にも結構需要がありそうだし。覚えておいて損はないかなと思った。

読むべき人:
  • VBの基本をさらっと理解したい人
  • Visual Studio.NETに触れてみたい人
  • わかりやすい図がないと技術書を読む気がしない人
Amazon.co.jpで『VB.NET』の他の本を見る


August 15, 2006

90分で学べるSEの英語力


90分で学べるSEの英語力

キーワード:
 小坂貴志、SE、英語、読解、会話、作文
日本IBMでSEをやっていた著者によるSEのための英語の学習本。以下のような内容となっている。
  1. 単語力
  2. 作文力
  3. 会話力
  4. 読解力
  5. 応用編:説得力
単語力は、SEが業務でよく使う単語を挙げている。作文力は、メールや履歴書の書き方について。会話力は交渉時やトラブルのときによく使う表現方法など。最後の読解力は、スラッシュ読みなどの英文の読み方について。

90分で学べるとあるが、実際にはもっと時間がかかるような気がする。しかし、それは自分がまだ技術力や業務背景に乏しいからかもしれない。もっと熟練したSEならば、英文を読むだけでいいかもしれない。

特に参考になったのは、単語力だろうか。最近英文を読む機会があるが、どうしても専門用語の日本語訳が分からないものがある。よく使われるもので、自分が知らなかったものなどは勉強になった。以下にその一部を列挙。
  • scope・・・事業範囲
  • design・・・設計
  • deliverables・・・成果物
  • man-month・・・工数(の単位)
  • cutoff・・・(プロジェクトの)開始
  • ROI(Return On Investment)・・・投資対効果
会話力は結構ネガティブな表現が多かった。なんだかIT業界のダメさが現れているような気がする・・・。例えば、『プロマネの苦悩〜あるシステム開発の現場より』という会話文の最初のほう。以下英語の部分のみ抜粋。
A:"I'm not 100% sure, but they appear to have zero experience as system developer."
B:"What! Is there anyone who is good at Java?"
A:"Most of them graduated from college and just started engineering job."
B:"We had better to leave it to someone who knows what they're doing."
(pp.77)
こんなこと入ったプロジェクトで言われたくないよな・・・。他にもトラブル時の会話とか・・・。そういうことが前提としてあるというのがなんともいえない・・・。

なんとなく、4つの分野にまたがっているので、それぞれの内容が薄いような気もする。それは90分で学べるとあるのでしょうがないのかもしれないけど。個人的には単語に特化した本がほしいところだが。

今の自分はプログラマーなので、そこまで網羅的に英語を使う必要性ない。そのため作文や会話の部分はあまり興味を持って読めなかった。また必要になったら繰り返し読めばよいか。

読むべき人:
  • 英語力が求めらるIT技術者
  • 軽くIT英語の勉強をしたい人
  • 将来海外進出、外資を目標にしている人
Amazon.co.jpで『IT 英語』の他の書籍を見る