技術本（コンピュータ関連）

May 14, 2017

その「エンジニア採用」が不幸を生む

その「エンジニア採用」が不幸を生む ~良い人材を見つけ、活躍してもらうには何が必要か?
その「エンジニア採用」が不幸を生む ~良い人材を見つけ、活躍してもらうには何が必要か? [単行本（ソフトカバー）]
キーワード：
　正道寺雅信、エンジニア、採用、評価、組織づくり
IT系エンジニアを効果的に採用するための仕組みが示されている本。概要と目次内容は以下の出版社の紹介ページを参照。去年の3月に転職し、Webサービス的な業務をやっているのだけど、十数人の部署内でITエンジニアは実質自分1人しかいない状況であったりする。当然一人でできることなどたかが知れているので、エンジニアを追加採用する必要がある。そこで、転職後の早い段階から部署内でどういうエンジニアが必要かを考えて、一次面接にも出て採用活動をしている。

しかし、この1年でそれなりに面接をしたが、結局誰も採用できておらず、依然として1人システムチームの状況である。はて、なぜ採れないのだろうか?もちろん、そもそもイケてるWebサービス的な企業ではないし、ITエンジニアが活躍できそうな業界でもないという部分はあるし、中小企業という企業規模でそこまで知名度があるわけでもない。なので、応募自体も少なく、まぁ、そんなに簡単に採れないだろうということは予想できていたし、実際その通りだった。

ごくまれによさそうな人材が転職エージェント経由で応募してくれるが、2次面接に行く前に他社に内定が決まって結局選考はスルーであったり、最近では上層部がもっともらしい理由をつけて本当にこの人は絶対必要だ!!という候補者を見送ったりということもあった（愚痴）。もはやすがるように、どうやったら理想的なエンジニアを採用できるのか!?を知りたくて読んで見た。

ある程度は予想できた内容だけど、改めて論理的に示されていると、なるほどなぁ、と思うと同時に、自分自身と自社の部署そのものあり方について、反省するところが多かったなと思った。そして、あまりにも納得できるところが多すぎて線を引きまくった。

本書の概要を恣意的にものすごく大雑把にまとめると、ものすごくできるA級クラスのエンジニアは、A級同士で働ける環境に魅力を感じ、そもそも転職エージェント経由で転職をすることはなく、SNSや勉強会、カンファレンスなどの自分自身の人脈を活かして人づてで転職先が決まる傾向がある。また、うまくそれなりによいエンジニアを採用できたとしても、その部署なり会社なりがITをコストとしてみなすのではなく、それなりの高給で待遇を保証し、エンジニアの志向性や生態?に対する理解があり、評価尺度、働く環境についてエンジニアを適切に受け入れる体制が必要だ、という内容である。

現状の採用方針を継続していけば、何年たってもエンジニアは採用できない可能性が高いし、採用できたとしてもあまり技術力が高くなく、それこそその採用自体がコストになってしまうな、と思った。プライベートでは絶賛婚活中だけど、採用活動はある意味婚活と同じだなと思った。一部の人気のある人以外は待ってても相手から来るが、そうではないので狩りに行かなくては!!と思った。

まず、個人的にやるべきことは、自分自身がA級クラスのエンジニアになること（そもそも何をもってA級といえるのか?はいろいろあると思うけど）。そのためには仕事でちゃんと実績を作り、技術ブログで情報発信し、カンファレンスや勉強会などに参加して人脈を築いておき、自分自身と一緒に働きたいと思えるような存在になること。そして、よさそうな人がいたら、転職エージェントに頼るのではなく、自分でスカウトしていくことだなと。

今年から技術ブログを始めたのだけど、更新停止している・・・。最近は毎朝5時台に起床してLaravelの技術勉強や技術書読み込みをやっているけど、もう少しアウトプットをしていかなければなと。一応自分の技術ブログは以下と。また、社内、部署内の組織もエンジニアを迎える体制を整えていかなければならないなと。自分自身だけではなく、部署、組織の上層部にもエンジニアの評価体制を提案していく必要があるし、ITそのものに対する理解を深める啓発もしていかなければならないなと。システム開発がどれだけ工数がかかり、すんなりうまくいかないということを理解してもらうのに本当に苦労する。

エンジニアに対する扱い方、考え方は以下の本と大体本質は同じだなと思って読んでいた。こっちは小説だけど、年功序列ではなく技術力があるエンジニアが高給を得るべきだし、ITが分からないものにエンジニアを正しく評価できるわけがないというようなことが書いてある。まさしくその通りなのだけど、それをどう実現していくかが課題である。

ITエンジニアの採用は難しい。もちろんほかの業種もいろんなことがネックになって難しいのだろうけど、ITエンジニアはそれなりに特殊な傾向があるのかもしれない。また、これから転職しようと考えている人も読めば参考になるところが多い。

本書を読んで、効果的なエンジニア採用ができればいいなと思う。まずは、本書を上司にも読んでもらおうと思う。


その「エンジニア採用」が不幸を生む ~良い人材を見つけ、活躍してもらうには何が必要か?
その「エンジニア採用」が不幸を生む ~良い人材を見つけ、活躍してもらうには何が必要か? [単行本（ソフトカバー）]
正道寺 雅信
技術評論社
2016-12-07

読むべき人：
  • エンジニアを切実に採用したい人
  • 転職しようと思っているエンジニアの人
  • できるエンジニアの生態を知りたい人
Amazon.co.jpで『正道寺 雅信』の他の本を見る

bana1 エンジニア採用クリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 15:35│コメント(4) 


April 16, 2017

レッドビーシュリンプの憂鬱

レッドビーシュリンプの憂鬱 (ツギクルブックス)
レッドビーシュリンプの憂鬱 (ツギクルブックス) [単行本]
キーワード：
　リーベルG、IT小説、エンジニア、評価、改革
IT小説。以下のようなあらすじとなっている。
業績不振のWebシステム開発部に突然コンサルの男――ソフトウェア・エンジニア労働環境向上推進協会、通称「イニシアティブ」の代表を名乗る五十嵐――が現れる。五十嵐が実行する思い切った改革に、若手エンジニアは賛同し成果を出す一方、ベテランエンジニアたちは反発し、五十嵐と対立していく。チームリーダーに抜擢された女性エンジニア箕輪レイコは、板挟みの立場になりながらも問題を解決しようと奮闘するが……。

エンジニアを通してビジネスパーソンとしての働き方や組織の在り方について問題提起する、異色のIT小説。
(Amazonの内容紹介から抜粋)
この本はいろいろと現状のIT業界、エンジニアの処遇に対する問題を提起しているのが主なテーマとなる。それは、エンジニアの技術力がないのに年功序列で評価され、実装技術よりも要件定義や仕様調整、プロマネ的なものばかりが評価されるプログラマーの上位職としてSEが存在することを是正し、年齢に関係なくプログラミング、実装技術を持つものが正当に評価されてそれに見合った報酬を得るべきだ、というものである。

中堅SI企業を舞台に、イニシアティブという外部コンサルタントがやってきてからいろいろと変化が起き始める。良い点は若手エンジニアが新技術、新プロジェクト、Web系サービスに対して意欲をもって働き始めたこと。よくない点は、これまで技術に対する研鑽を怠っていた古株メンバーがリストラ候補に挙がってしまって軋轢を生んだこと。一見エンジニアが正当に評価される制度を取り入れていけば、何もかもがうまくいくようには思えるが、古株メンバーは家庭もあり、新技術のキャッチアップする体力も意欲もなくなっていくので、まぁ、そうかもしれないなと思うのだけどね。

小説としてはそこまで面白いものではないけど、IT業界、特にSI業界ではあるある!!という部分がいろいろとちりばめられていて、線を引きつつ共感しながら読んでいた。たしかにイニシアティブのコンサル、五十嵐のIT業界を変えたいという理念は納得だな、と思う。その反面、自分自身がそのような技術力だけで評価されるところで、生き残れるだろうか?と自問自答せざるを得ない。僕はどっちのエンジニアだろうか?と。もちろん、技術力を高めてそれで評価されたいと思う。それを少なからず望んでSI的なところから転職したのだし。

一点だけITエンジニアを正当に評価すべきという主張に対して本書で抜けている視点、あまり言及されていないものがあって、それは『人月』に対する考え。現状のIT業界の工数見積もり、エンジニアの単価は役職ベースの人月稼働時間で算出されており、それが結局システムの値段、エンジニアの評価となっている。その人月ビジネスを根本から変えないと正当な技術力評価はできないのではないかと思う。

しかし、人月は発注側にも受注側にも便利な尺度であり、人月意外に代替でき納得のいく評価尺度がいまだにないのだから、どうにもならないのかもしれない。ソフトウェアそのものが不可視であり、バグがなく完全なものを作ることはほぼ不可能だし、エンジニアの技術力によって生産性が10倍くらい違ったりするから。

本書はITエンジニアが読めば共感するところはたくさんあるので読んだほうが良い。やはりSI的な評価尺度、正しく自分の技術力で評価されていないのは納得がいかないと思う人は、本書を読んで思い切って転職をするのもいい。また本当はこれはエンジニアを評価する上長的な立場の人もぜひ読んでおくべきだ。正当な評価ができないと、本当にできるエンジニアはその組織で長く働き続けることはないだろうし。

IT小説といっても難しい技術的な話はそこまで出てこない。もちろんIT用語、技術用語がところどこに出てくるが、注釈が載っている。重要なのは些末な技術用語よりも、本書で提起されている問題の本質を把握することだ。

読めばいろいろと考えさせられるIT小説だった。読了後の後味は若干苦いけど、良書の部類。


レッドビーシュリンプの憂鬱 (ツギクルブックス)
レッドビーシュリンプの憂鬱 (ツギクルブックス) [単行本]
リーベルG
SBクリエイティブ
2017-02-16

読むべき人：
  • ITエンジニアの人
  • ITエンジニアを評価する立場の人
  • 正当な技術力で評価されたい人
Amazon.co.jpで『リーベルG』の他の作品を見る

bana1 イニシアティブクリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 07:25│コメント(0)│トラックバック(0) 


January 29, 2017

Laravel リファレンス[Ver.5.1 LTS 対応]

Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク
Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク [単行本（ソフトカバー）]
キーワード：
　新原雅司、Laravel、PHP、フレームワーク、リファレンス
PHPのフレームワークのLarvelについての本。本の目次等は出版社のページ参照。仕事でLaravelを使ったWebアプリケーションを作ることになって、読んで見た。あまりほかに日本語書籍がないので、これが一番ボリュームがあってよくまとまってはいると思う。

しかし、とてもわかりにくい書籍だと思った。そもそも自分がそこまで現状バージョンのPHPと他のフレームワークに精通しているわけではなかったので、基本的なところが理解できていないと読み通すのがしんどい感じがする。できれば本書の対象読者、前提知識がどういうものが必要かは示しておいてほしいと思った。

あとはリファレンスという形式でもあるので、わかりやすく説明しようという意図はほとんどない。何よりも図解がないので、Laravelの全体像がよくわからない。特に最初はComposerとLaravelの関係が地味にわかりにくいし、Laravelでインストール時に作成されるディレクトリ群とそれらがどのような動きをするのかが分かりにくい。さらにもっといえば、サンプルコードが書籍内に載っており、GitHubからcloneしてサンプルを実際に見ることができるが、書籍内でそのコードのパスが示されていないところがあって、うーん、となった。

あとは日本語説明がそっけなさ過ぎるし、ところどころ間違いがあるし（正誤表もあるが、それも完全ではなさそう）とにかく全部読み進めるのがかなり大変な技術書であった。本当にわかりやすい技術書は適度に図解があって、さくさくと読み進められるが。リファレンスなので、随時該当箇所を調べながら使うのが良いか。といっても、この本の初版は2015年で、PHPのバージョンも56までしかカバーしていないし、Laravelも5.2までしか対応していないので、若干内容が古くなっているところがある。

特に自分のような初心者にとってこの本から学習をするのはおすすめしないかな。以下で学習するのがいいかもしれない。ある程度学習が進んでから本書を読むと割とすんなり理解できるかもしれない。

なんとか1月中に初回更新ができてよかった。今年も冊数はあまりこなせない可能性が高い。ちなみに27日誕生日で33歳になって、そこで技術ブログをはてなで始めることにした。こっちもよろしく!!


Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク
Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク [単行本（ソフトカバー）]
新原 雅司
インプレス
2015-12-04

読むべき人：
  • Laravelについて調べたい人
  • PHPをある程度理解している人
  • Laravelのまとまったサンプルコードを見たい人
bana1 Laravelクリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 08:57│コメント(0)│トラックバック(0) 


September 11, 2016

Amazon Web Servicesではじめる新米プログラマのためのクラウド超入門

Amazon Web Servicesではじめる新米プログラマのためのクラウド超入門 (CodeZine BOOKS)
Amazon Web Servicesではじめる新米プログラマのためのクラウド超入門 (CodeZine BOOKS) [単行本（ソフトカバー）]
キーワード：
　WINGSプロジェクト/阿佐 志保、AWS、クラウド、基本、入門
AWSの基本的なことが解説されている本。目次は長いので翔泳社のページを参照と。仕事で自社のデータンセンターで運用しているWebサービスをクラウドに移行しようということになって、クラウドってなんぞ?というところから始まって、まずは以下の本を読んだ。この本はどちらかというと移行前に考えることを詳細に示された本だった。AWSの全体像と概要を理解したので、次は実際の使い方とWebサービスの構築方法が知りたいと思って、書店のAWSコーナーを見ると、これが一番初心者向けで分かりやすいと思って買って読んだ。

『新米プログラマのための』とタイトルにあるが、別に新米プログラマが対象でなくても読むべき内容で、とても分かりやすくAWSの基本的なことが示されている。各サービスの概要、そもそものインターネットやネットワーク、IPアドレスの仕組みなども示されている。また、各サービスの構築手順がキャプチャつきで示されているので、この本を読みながら一通り試しながら学習できる。

WebサービスはEC2インスタンスがAmazon Linuxで、そこにApacth Tomcatを設定し、RDSにMySQLを組み合わせてJavaで作るものを想定されている。Javaを使う人にはそのまま参考になると思われる。また、仮想化環境でアプリを管理、実行するためのオープンソースのプラットフォームのDockerについて、インストール方法から示されている。

自社のWebサービスはWindows Serverを使っているので、MS系の技術は本書には書いてなく、そこはあまり参考になるところがなかった。例えば、RDSにSQL Serverはあるが、EC2のWindows ServerインスタンスにもSQL Serverが標準搭載になっているものがあるので、初心者にはどっちを使うべきなのかとか、そもそも両方の選択肢があることなどは分からなかったりする。

AWSでWindows系のシステム構成になっている本があまりないので、そういうのが個人的にほしいなと思った。まぁ、そもそもAWSじゃなくて、Azure使えばいいじゃないかという気もするのだけどね。

とはいっても、AWSの基礎的なことが分かって重宝した。他のAWS本はぶ厚すぎたりある程度基礎が分かっている人向けだったりするので。本書を読めば最低限のAWSのシステム構築方法が分かるはず。あとは、地道にAWSのWeb上のドキュメントを読んで、お試し環境で試行錯誤していくのが理解の早道と思われる。


Amazon Web Servicesではじめる新米プログラマのためのクラウド超入門 (CodeZine BOOKS)
Amazon Web Servicesではじめる新米プログラマのためのクラウド超入門 (CodeZine BOOKS) [単行本（ソフトカバー）]
WINGSプロジェクト 阿佐 志保
翔泳社
2016-06-17

読むべき人：
  • AWSの基礎が知りたい人
  • JavaでAWSを使う必要がある人
  • Dockerも考慮したい人
Amazon.co.jpで『AWS』の他の本を見る

bana1 AWSクリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 16:32│コメント(0)│トラックバック(0) 


July 03, 2016

Amazon Web Services企業導入ガイドブック

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-
Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで- [単行本（ソフトカバー）]
キーワード：
　荒木靖宏、クラウド、AWS、移行、計画
AWSの導入時のポイントが網羅されている本。以下のような目次となっている。
  1. #1 [概要編] クラウドコンピューティングとAWS
  2. #2 [概要編] AWSのさまざまな利用シーン
  3. #3 [概要編] AWSのサービス
  4. #4 [概要編] AWSのセキュリティ概要
  5. #5 [戦略・分析編] クラウド導入のプロセス
  6. #6 [戦略・分析編] 現状分析の進め方
  7. #7 [戦略・分析編] クラウド標準化
  8. #8 [戦略・分析編] PoCによる事前検証
  9. #9 [概要編] クラウドにおけるTCOと費用見積り
  10. #10 [設計・移行編] クラウド利用時の開発プロセス
  11. #11 [設計・移行編] クラウドにおけるシステム設計
  12. #12 [設計・移行編] クラウドにおけるサイジングと性能測定
  13. #13 [設計・移行編] クラウドへの移行
  14. #14 [運用・改善編] AWSにおける運用監視
  15. #15 [運用・改善編] クラウド活用の最適化
(目次から抜粋)
自社のシステムがデータセンターで運用をしていて、月々の運用コストがかかっているのでコストダウンを図りたいよね、そしてその後のシステムの拡張性などを考慮するとクラウドに移行がいいよね、いろいろ調べたらAzureよりもAWSかな?、ということで移行よろしく!!という仕事が発生しとき、そもそもクラウドって何?AWSで何ができるの?、そんでいくらコストかかるの!?教えてエ〇い人!!みたいな状況だった。

普通はAWSについて調べようと思と、本家のサイトを見ればよいのだけど、S3、EBS、RDS、VPCなど独自の略語やタカナ語が多すぎるし、あまり構造化されてないのでどっから見ればよいのかわかりにくいし、サービス紹介動画を見ても激しく眠くなるしw、ブラウザ上で何時間も慣れない文章を読むのは疲れる。そんなとき、先月中旬に発売した本書がたまたま目に留まり、速攻で買って読んでみたわけだ。

本書はAWSのサービスの概要、AWSを導入時に検討すべきポイント、サービスのサイジング、クラウド移行の計画の立て方、移行してからの運用監視についてなどが網羅されている。

出回っているAWS本はすでに導入した後の使用時の設定について書かれていることが多いが、AWSを導入するときに何を考慮しなくてはいけないのか?、移行計画とか何を考えればいいんよ?とか導入以前のことがほとんど書いてなかったりする。しかし、本書は僕のような状況時に移行前に知りたいことがほぼ網羅されている印象で大変役に立った。

特に勉強になったのは、クラウド移行の目的を先に明確化すべきというところかな。いくつか示されているが、コスト削減、伸縮自在性や柔軟性の向上、インフラ調達効率の向上などがあり、その中でも優先順位付けをすべきとあった。そして、サービスレベル要件、性能要件、セキュリティ要件などクラウドで達成すべき要件を洗い出すと費用やスケジュールが明確になるようだ。

そして、移行が決定したらどの順番でどのように移行するか、どれくらいコストがかかるのかを判断するための現状分析が必要になるが、その流れが以下のように示されている。
  1. 移行対象の選定
  2. アーキテクチャ検討
  3. ロードマップ策定
  4. コスト試算
プラットフォームの全面移行などの仕事をしたことがある人にとっては、当たり前のことなのだけど、そういう経験がないと、どっから手を付けてよいのかわからないので、このように示されているのは本当にわかりやすくて、そのまま仕事に使える。

あとはAWSは使った分だけ課金するモデル（オンデマンドインスタンスの場合）なので、利用を変動させられるのが特徴である。そのため、固定作業と可変作業のコストを最適化できるので、サービスの直接コスト、間接コストを見積り、比較するための財務指標になるTCO（総所有コスト）をある程度の期間想定して評価することが重要らしい。まぁ、要はいろんなAWSサービスの構成を組み合わせた時にいくらかかって、ROI的にどうなるのか?をしっかり考えるべきと。お金は大事だしね。

実際の見積りには本書では以下のようなツールが示されている。あとは本書には載ってないけど、金額見積りをExcelベースで算出できる割と便利なものが以下にある。全部使ったわけではないけど、とりあえずExcelが楽かな。

本書はAWSの中の人が書いているので、内容としては間違いはないだろうし、何よりもユーザ企業がAWSを導入するときに何を検討すべきなのかがよく分かっているというか、そのような導入時に検討すべきことがナレッジとしてそれなりに蓄積されているのだろうと思われる内容だった。もうすでにAWSを利用して運用している人には、デジャブ感いっぱいの内容かもしれないが。しかし、AWSの移行前に何をすればよいかわからない!!、というときはまずはこれを読むのがよいだろう。

技術本は今抱えている仕事の解決策になるのか、ヒントを得られるのかどうか?を目的として読むので、使える、使えないが割とはっきり評価しやすいが、本書はかなり使える!!と思った。


Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-
Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで- [単行本（ソフトカバー）]
荒木 靖宏
マイナビ出版
2016-06-10

読むべき人：
  • AWSの概要について知りたい人
  • IT戦略などの意思決定をしなくてはいけない人
  • クラウド移行を検討している人
Amazon.co.jpで『AWS』の他の本を見る

bana1 AWSクリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 07:25│コメント(0)│トラックバック(0) 


June 19, 2016

新米IT担当者のための Webサイト しくみ・構築・運営がしっかりわかる本

新米IT担当者のための Webサイト しくみ・構築・運営がしっかりわかる本 (ばっちりわかる)
新米IT担当者のための Webサイト しくみ・構築・運営がしっかりわかる本 (ばっちりわかる) [単行本（ソフトカバー）]
キーワード：
　池谷義紀、Web、開発、担当者、入門書
Webサイトの構築・運営の基本的なことがまとまっている本。以下のような目次となっている。
  1. 序章 Web担当者の仕事を知ろう
  2. Chapter1 Webサイトの仕組みを知ろう
  3. Chapter2 Webサイトの構築準備をしよう
  4. Chapter3 Webサイトを構築しよう
  5. Chapter4 Webサイトを運営しよう
(目次から抜粋)
転職してから、SI的なSEから自社のWebサービスの開発・運用の担当に仕事が変わったので、Web全般の基本的なことを知る必要があると思った。そもそも一般的な業務システムの作り方とWeb系は同じシステム開発といっても似ているところもあれば、全然違ったりするので、今までの知識体系だけでは足りないだろうというのもあったし。そこで、書店で何かないか探してみて、本書が目に留まった。

タイトルに『新米IT担当者のための』とあるとおり、入門書的な内容となっており、そもそもインターネットとはどういう仕組みか?といったところから、Webサイトの企画から構築までに必要なこと、制作会社の選び方、Web特有のUI/UXの基礎やSEOやアクセス解析、Webマーケティング、セキュリティ、個人情報、著作権など法律的な部分に関連するところまで幅広く基礎的な内容が網羅されている。

ある程度基礎的なことは分かっているけど、やはりWeb特有の概念、特にWebマーケティング的な部分、UI/UXなどデザイン的な観点はあまり詳しくないなと分かった。特にWeb系特有の略語、例えばEFO、CVR、SEM、LPOなどWebサービスを開発したり運営している人にとってはなじみのあるものだと思われるが、仕事でもこれらがときどきよく出てきて何のことかわからなかったりした。そういうものの概念や基礎がわかって勉強になった。

Web系の技術は昔に比べていろいろと発展してきて、選択肢も増えて誰でも作れるような環境にはなってきているけど、収益を出す、アクセス数を稼ぐ、使ってもらえるWebシステムを作るには、単純な実装技術だけが分かってもダメなんだなと最近仕事をしつつ実感している。

そもそものWebサービスなどのアイディアが重要だったり、デザイン的なものも重要だったり、サイト更新のスピード感なども重要だったり、Googleの検索エンジンの仕様の更新に大きく左右されたりするのでそれらも考慮しなくてはだし。また、ネット上に公開されるWebシステムは業務システムのように誰が使うかが確定していないのが一番の違いでもあるし。

Web系の特有の技術や用語、流行り廃りを常にウォッチしていく必要があるなと思った。学ぶことがいろいろとあって、もっと勉強しなくては!!と思いつつ、最近はなんだかあまり技術勉強ができていないので、何とかやっていきたい。

本書はWeb担当者として自社なりのサービスの構築・運営に初めて携わる人には重宝する内容と思われる。大型書店でいろいろと見て回ったが、あまりこういう入門的な本は、ありそうで類書がなかったりするし、あっても内容が古すぎたりするので。Web系の仕事に初めて就くような新入社員、もしくはSI系から転職したなどの人が読むとよいと思われる。


新米IT担当者のための Webサイト しくみ・構築・運営がしっかりわかる本 (ばっちりわかる)
新米IT担当者のための Webサイト しくみ・構築・運営がしっかりわかる本 (ばっちりわかる) [単行本（ソフトカバー）]
池谷 義紀
技術評論社
2011-04-22

読むべき人：
  • Web担当者の人
  • Web系の会社の新入社員の人
  • Webで儲けたいと思っている人
Amazon.co.jpで『Webサイト』の他の本を見る

bana1 Webクリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 18:34│コメント(0)│トラックバック(0) 


April 03, 2016

はじめよう! 要件定義

はじめよう! 要件定義 ~ビギナーからベテランまで
はじめよう! 要件定義 ~ビギナーからベテランまで [単行本（ソフトカバー）]
キーワード：
　羽生章洋、要件定義、開発、画面遷移図、システム
システム開発における要件定義のやり方がわかりやすく示されている本。以下のような目次となっている。
  1. 第1部 要件定義って何だろう?
    1. 要件定義=要件を定義すること
    2. 要件定義の基本的な流れ
    3. 定義すべき要件の内訳
    4. 3つの要素の定め方
  2. 第2部 要件定義の詳細
    1. 要件定義、その前に
    2. 企画を確認する
    3. 全体像を描こう
    4. 大まかに区分けしよう
    5. 実装技術を決めよう
    6. 実現したいことを整理整頓しよう
    7. 利用者の行動シナリオを書こう
    8. 概念データモデルを作る
    9. UIを考えよう
    10. 機能について考えよう
    11. データについて考えよう
    12. 要件定義の仕上げ
    13. 要件定義、その後に
(目次から抜粋)
要件定義をやろう!!と思い立った時に、今まで下流工程メインでしかやってこなかったので、要件定義のような上流工程は未経験で、はて、何をどうやればいいんだろう?と思ったので、買って読んでみた。

要件定義ってそもそも何?というところから始まって、要件定義の基本的な流れ、定義すべきことなどがイラスト付きで170ページほどでコンパクトにわかりやすくまとまっている。

そもそもシステム開発での要件として必要なことが以下のように示されている。
プログラマがソフトウェアを完成させるために必要な情報
(pp.18)
そして、これの元ネタがUI、機能、データとなり、それらを決めることが要件定義でのやることと示されている。なので、完成させるシステムのゴールから逆算して以下の順番でそれぞれの内容を決める必要がある。
  1. UIを決める
  2. 機能を決める
  3. データを決める
しかし、要件定義の準備段階が重要になってくる。何をやるべきかは省略して、それらを実施していれば、その成果物と以下が手元に揃っている状態であると。
  • 企画書
  • 全体像（オーバービュー）
  • 利用する実装技術
  • 実現したいこと一覧（要求一覧）
  • 行動シナリオ
  • 概念データモデル
3月に転職してから受注側から開発ベンダーに依頼する発注側の立場となった。僕の事業室の内部IT要員は実質自分1人だけなので、内部の要件とベンダーの橋渡しをうまくやらなければいけないという状況。要件定義が重要なのは身に染みているので、なんとなくこんな感じでよろしく!!と言ってベンダーに丸投げしてまともなシステムができるわけがないことは言うまでもない。

なので、自分である程度要件定義に近いことを内部でやっておく必要がある。まずはこの準備段階をきっちり決めることだな。案外ないものがある。企画書とか全体像とか要求一覧とか行動シナリオとか概念データモデルとか、というかほぼ全部ない!!wこのあたりをしっかり分析して用意しておいて、そこからようやく外部ベンダーにこんな感じで、と依頼できるかな。

発注側も要件定義の内容としてのUI、機能もある程度洗い出し、完璧とはいかないまでも考えるネタとして資料化、そんで外部ベンダーに引き渡して、外部ベンダーにブラッシュアップしてもらうことで要件漏れや手戻りもある程度防げるのではないかと思う。まぁ、ビジネススピード優先でかつ内部のIT要員が自分１人の状態というのもあったりでどこまでできるかはわからないけど、ここまでは意識としてやっておきたい。

理想は発注元もデータを決める、つまりDB設計までやればよいが、ここまでになるとUI、機能を決めるよりもより複雑になってくるので、外部ベンダーに投げてもいいのかなと思ったり。理想は完全内製化でDevOpsで行きたいところなのだけど、実際そんなことができないから外注するしかないのだけどね。

また、以下のDainさんの記事がとても勉強になるので、一度読んでおくとよい。本書は著者の携わった案件から、最近はやりのアプリやゲーム開発も考慮された内容となっている。要件定義の漠然としていた内容がすっきり整理されて、明日からの自分のタスクが明確になった。受注側の特に上流工程をやる人は読んでおくべきだし、発注側のベンダーとのやり取りをする人も絶対読んでおいた方がいい。すべては糞システムにしないために。


はじめよう! 要件定義 ~ビギナーからベテランまで
はじめよう! 要件定義 ~ビギナーからベテランまで [単行本（ソフトカバー）]
羽生 章洋
技術評論社
2015-02-28

読むべき人：
  • 受注側の上流工程要員の人
  • 要件定義についてわかりやすく知りたい人
  • 発注側でベンダーとやり取りする人
Amazon.co.jpで『要件定義』の他の本を見る。

bana1 要件定義クリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 20:50│コメント(0)│トラックバック(0) 


March 27, 2016

ストーリーで考える「見積り」の勘所

ストーリーで考える「見積り」の勘所 (開発の現場セレクション)
ストーリーで考える「見積り」の勘所 (開発の現場セレクション) [単行本（ソフトカバー）]
キーワード：
　中村秀剛、見積り、工数、コスト、勘所
システム開発時の見積りについて解説されている本。以下のような目次となっている。
  1. イントロダクション システム開発における「見積り」とは?
  2. 第1章 引き合いからヒアリングの準備まで
  3. 第2章 ヒアリングから提案方針の検討まで
  4. 第3章 提案方法のディスカッション
  5. 第4章 工数の算出
  6. 第5章 見積り金額の策定
  7. 第6章 全体を振り返って
  8. 第7章 より良い「見積り」のために
  9. 第8章 よくある落とし穴の紹介
(目次から抜粋)
本書は仮想のシステム開発案件をストーリー仕立てにし、システム開発をするときに必要な期間やコストを求める「見積り」方法が分かりやすく示されている。そして、見積りの流れとして以下のステップが示されている。
  1. 引き合い
  2. 資料の事前調査
  3. 客先訪問、ヒアリング
  4. 要件分析
  5. 実現方式検討
  6. 工数算出
  7. スケジュール検討
  8. 開発実費算出
  9. 見積り金額の合意
  10. 見積り提示
それぞれのステップで架空の登場人物たちのやり取りとサンプル成果物が示されていて、参考になる。

本書の主な想定読者は受注側のSI系企業の上流工程担当者である。なので顧客からの要望（RFP）に対してどのように提案していくか?、そしてそのときのシステム開発の見積りをどうやるか?を考えるときに参考になる。

見積り、といっても決定的な手法が確立されているわけでもなく、実際にプロジェクトを進めていくと要件が変わったり、使用する技術の不備などで開発工数が予想外に多くなったりで、スケジュールがずれてきて、結局当初の見積りからもずれることが多い。それでも経験を積んでいくしかないのだけどね。

そもそも本書を読んだのは、顧客側（発注側）の立場として開発ベンダーに開発要件を伝えた後に提示された見積りが妥当かどうか確認したいという理由からだった。要は、提示された金額は妥当かどうかを知りたかった。

しかし、『開発実費算出』の章で、「残念ながら金額の決定方法については、具体的な手順を説明することはできません。」と示されていて、肝心のところが載ってない!!と思った。そこは企業秘密的な部分であるし、会社によって人月単価は異なるから一般化できないところだろうから仕方のないところだけど、発注側としてはそこはサンプル的な数字でよいので示してほしかったかなと。

受注側が提示してくる見積り金額の妥当性をどうやってチェックするか?を考えてみると、適切な工数から算出されているか?を確認するしかないかなと。要は新規開発なり改修であったりするときの改修対象が網羅されているか、その対象の機能一覧がそれぞれどれだけの工数（人員とスケジュール、つまり人日、人月等）がかかるかを発注側もある程度計算するしかないかなと。そこで受注側の提示工数と乖離があるかどうかで判断する。競争入札の場合は、提案企業ごとに比較できるので、安い高いが判断しやすいが、1社単独の場合は、比較しようがないので、計算するしかない。

また、著者や著者の周りで何度か提案活動を進めていくなかで、「最低限これだけは必要ではないか」という見積り工数を算出するための元ネタになるドキュメントが以下のように示されている。
  • 作業内容一覧
  • WBS
  • スケジュール
  • 機能一覧
  • テーブル一覧、データモデル図
  • システム論理構成図
  • システム物理構成図
一部は設計工程で詳細に作るものなので、提案段階で詳細化はしないだろうが、それでも大雑把に作っておくことで見積りがわかりやすくなると示されている。受注側はこれらから見積りを実施すればよいし、発注側は見積りの根拠は何か?を問う時に受注側からこれらが提示されているかどうかで見積りの妥当性を確認できるのではないかと思う。

タイトルに『勘所』とあり、著者もイントロダクションで示すように、本書を読めば誰でもすぐに見積りが作成できるわけでもない。どうしても経験の積み重ねが重要になってくるが、何もわからない状態で経験を積み重ねるよりも、本書に示されている著者のこれまでの経験値としての『勘所』を基礎にして経験を積むほうがよいし、それぞれの章で示されるその『勘所』のコラムがとても勉強になる。

220ページほどで、内容もストーリー仕立てで会話調なので、すらすらと読めるし、分かりやすい。何とか1日で読了できた（実質4時間くらい）。僕のように発注側の人が読んでも勉強になるし、役立つ内容である。


ストーリーで考える「見積り」の勘所 (開発の現場セレクション)
ストーリーで考える「見積り」の勘所 (開発の現場セレクション) [単行本（ソフトカバー）]
中村 秀剛
翔泳社
2008-03-12

読むべき人：
  • 上流工程を担当することになった人
  • 見積りの妥当性をチェックしたい発注側の人
  • ビジネス側の視点も強化したいSEの人
Amazon.co.jpで『見積り』の他の本を見る

bana1 見積りクリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 19:54│コメント(0)│トラックバック(0) 


March 21, 2016

Webエンジニアの教科書

Webエンジニアの教科書
Webエンジニアの教科書 [単行本（ソフトカバー）]
キーワード：
　佐々木達也、Web系、概要、フルスタック、基礎
Webエンジニアが取得すべき技術の概要が網羅されている本。以下のような目次となっている。
  1. CHAPTER-01 Webエンジニアについて
  2. CHAPTER-02 Ruby on Railsでの開発
  3. CHAPTER-03 PHPでの開発
  4. CHAPTER-04 NoSQLデータベース
  5. CHAPTER-05 フロントエンドの実装
  6. CHAPTER-06 ログについて
  7. CHAPTER-07 データの可視化について
  8. CHAPTER-08 環境構築の自動化
  9. CHAPTER-09 便利な外部サービス
(目次から抜粋)
WebサービスやWebアプリケーションを開発するエンジニアが扱う技術領域は幅広くなってきており、各自の専門領域だけに目が行きがちで、他の領域も最低限知っておかなくてはいけないという意識があっても、なかなかキャッチアップができなかったりする。本書はWebエンジニアが知っておいた方がよい技術領域の概要が網羅されており、他領域のキャッチアップのきっかけになる。

内容について補足すると、2，3章はRuby on Rails、PHPの導入についての手順やフレームワークなどが紹介されている。4章のNoSQLではKey-Value型のRedis、ドキュメント指向データベースのMongoDBが紹介されている。5章のフロントエンドについては、CoffeScript、TypeScript、Angular JSなどが示されている。8章の環境構築の自動化については、Vagrant、Ansible、Serverspec、Dockerなど仮想化、プロビジョニングソフトが示されている。

どの章も概要とそれぞれのインストール方法、簡単な使い方が示されている。概要レベルを網羅しているだけなので、あまり深い説明などは載っていない。そこはそれぞれの専門書なりWeb上のドキュメントを見て詳細を把握していくしかないが、よくはてブなどで日々上ってくる、見たことあるけどあまり知らない技術やソフトの概要を知ることができたのでよかった。

3月から転職して、結果的にWeb系のエンジニアになって、しかも自分の所属部署でエンジニアが実質自分一人という状態である。さらに今後も新規開発をやりたいということで、なんでもある程度できるようにならなくてはいけないポジションにある。かっこよくいえばフルスタックエンジニア、ということなのだけど、Web系の技術に関しては大学時代にPHP+MySQL+SmartyでWebアプリケーション開発をやったことがあるくらいで、最近の技術はさっぱりついて行けておらず、さて何から勉強すべきか?を考えた時に、まずは全体像を知る必要があると思った。本書はその目的を十分に果たしてくれたと思う。

それぞれ何が流行っているのかをまず把握し、そこからどこを重点的に補強して勉強していくか?の優先順位付けをする必要があるなと思った。いくらフルスタックといっても全領域の技術を深く習得して使いこなせるようになることはないので、得意不得意、仕事での重要度を鑑みて決定していけばいいのかなと思う。とはいえ、どの領域もそんなに詳しくないので、せめて概要くらいは把握しておきたい。

また、本書が書かれたのは2015年4月なので、賞味期限は今年いっぱいという感じかな。

Web系のエンジニアとしては駆け出し状態だけど、IT知識や開発経験が0からスタートするわけでもなく、それなりに下地があるから速習できるはずでしょ!?と楽観的にかつWebサービス開発を楽しんでいけたらと思う。


Webエンジニアの教科書
Webエンジニアの教科書 [単行本（ソフトカバー）]
佐々木 達也
シーアンドアール研究所
2015-03-26

読むべき人：
  • 2，3年目のエンジニアの人
  • 最新技術を目にするけど試せていないエンジニアの人
  • フルスタックエンジニアになりたい人
Amazon.co.jpで『Webエンジニア』の他の本を見る

bana1 フルスタッククリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 21:16│コメント(0)│トラックバック(0) 


February 17, 2016

リーダブルコード

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) [単行本（ソフトカバー）]
キーワード：
　Dustin Boswell／Trevor Foucher、コード、可読性、品質
読みやすいコードを書くための実践的な内容がわかりやすく示されている本。目次はオライリーのページに詳細が載っているのでそちらを参照と。職業プログラマであるなら、なぜ読みやすいコードを書く必要があるかは説明するまでもなく分かるでしょう。それなりの規模の開発になれば、自分一人だけがプログラムするわけでもなく、かならずチームで仕事をすることになる。そのときは人に自分のコードを理解して機能なりを拡張して、プログラムしてもらうことになる。

そんなときに変数名がhogeとか何が入っているかわからず、if文やwhile文が何重にも入れ子になっており、グローバル変数が使われていたり、1クラス、関数の行数が1万行を超えていたり、コメントにはコードの内容をそのまま翻訳しただけの無意味なものが設定されているようなソースコードを読んだりいじったりすることは、どれほど時間がかかり、そして品質に影響を与えるかは、似たようなソースを見たことがある人には腑に落ちるはず。本書はそれらのダメなポイントを列挙し、改善点が示されている。

大学生の時にC言語によってプログラミングを学び始めた時からなるべく本書のような文章読本的なものはそれなりに読んでいた。それなりにできているはずだ、と思って一昔前から話題になっていた本書を改めて読んでみたが、意外にできていない部分もあるなと思った。もちろん、グローバル変数は使わないとかコメントは意味のあるものを設定しようというような基本的な部分は大丈夫なのだけど、一番怪しいのは変数名の設定の仕方のところか。

変数名の設定について言及されている2章のまとめを抜粋しておこう。
  • 明確な単語を選ぶ。
  • tmpやretvalなどの汎用的な名前を避ける。
  • 具体的な名前を使って、物事を詳細に説明する。
  • 変数名に大切な情報を追加する。
  • スコープの大きな変数には長い名前をつける。
  • 文字列やアンダースコアなどに意味を含める。
特にやりがちなのは一時的な値を保持するだけのtmpという変数名を使うこと。それが何が入っているかわかりやすくべきとある。例えばファイル名ならtmp_fileがよいと。tmpを使うには、生存期間が短くて、一時的な保管が最も大切な変数にだけ使用しようとある。ついつい生存期間が長いものにまで使っていたので注意しよう。

変数名に具体的な名前を使用しようとあり、また最善の名前は誤解されない名前を使うべきとある。そのため複数の変数名を検討することが推奨されている。変数名は一般的に英単語を組み合わせると思うので、明確な単語を設定する必要があるなと。しかし、あまり時間がない時や追われていて余裕がない時は安直な名前にしてしまいがちだね。さらに適当な英単語を英辞郎などで調べようと思っても、ネットが遮断されているような客先常駐環境だとどうにもならなくなる。なので、普段から英単語を勉強しておくのがいいと思う。以下とお勧め。だいぶ前の過去最高スコアが610だった。今やったら450前後ですっかり忘れているなぁ・・・。

本書はそのタイトルの通り、読みやすく分かりやすいし、230ページほどで実践的な要点がまとまっているのでお勧め。また、あわせて読みたい本としていくつか類書が列挙されていた。その中で読了済みなのは以下。リーダブルコードも内容としてはよいが、もっと深く学んでおくべき内容なので、個人的にはCODE COMPLETEを強くお勧めする。値が張って読了にもかなり時間を要するが、それだけの先行投資の価値は十分にある。

あまり職場以外で人のコードを読む機会がなかったので、今年はもっといろいろと読んで勉強していこうかなと思う。あとはコードも晒すということもやろうかなと。ブログで駄文をさらしているのに慣れているのでソースコードくらいどうということはないはず。自分のコードはそれなりに美しく読みやすく心がけているので。また持論だけど、美しいコードを書くには普段から美術館で絵を見たり、旅行で美しい風景を見たほうがいいと思っている。

ともかく、何よりも読みやすく美しいコードがとても重要だね。職業プログラマでまだ本書を読んでない人はまず買って読もう。2週間もあれば読めるよ。


リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) [単行本（ソフトカバー）]
Dustin Boswell
オライリージャパン
2012-06-23

読むべき人：
  • プログラマの人
  • 1行でまとめて書くのがイケてると思っている人
  • 美しいコードを書きたい人
Amazon.co.jpで『ソースコード』の他の本を見る

bana1 リーダブルクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 10:08│コメント(0)│トラックバック(0) 


December 28, 2015

ゲーマーはもっと経営者を目指すべき！

ゲーマーはもっと経営者を目指すべき!
ゲーマーはもっと経営者を目指すべき! [単行本]
キーワード：
　4Gamer.net編集部 / 川上 量生、ゲーム、経営、廃人
4Gamer.netで連載されていた記事が書籍になったもの。本書の内容は以下で読める。簡単に概要を示すと、ドワンゴの川上氏が自分のゲーマー人生の自慢をしたいだけで始まったゲーム関係者などと対談、鼎談している内容となる。

連載の建前上のテーマはゲーマーの戦略性や一定のルール化で思考（試行）しながら最適解を導いてプレイする能力が実社会、例えば会社経営にも通じるところがあるのではないか?というものが設定されているのだけど、連載初期で早くも川上氏によって完全否定されていたりする(笑)。連載途中でも全然テーマとは関係ない話題にもなって、そもそもテーマってなんだっけ?みたいなことになるのだけど、全連載を通関して読んでみると、そのテーマの設定がすごくよかったと思う。

個人的な感想を最初に示しておくと、今年読んだ本の中で一番面白くて、共感できて、そんでかなりマニアックで、そして勉強にもなるスゴ本!!今年の優勝本!!

この連載をリアルタイムでウォッチしていた人にとっては何をいまさら感があるかもしれないけれど、僕は本書の存在を最近まで知らなかった。そんで年末恒例となっている西新宿のブックファーストの書店員が勧める今年の本というようなフェアで本書が置いてあって、買って読んでみたらガチャで超激レアカードを引いたような、そんな感覚w西新宿のブックファーストの店員さんマジ神!!!!

内容がかなり多岐にわたってかつマニアックな内容なので、どこを個別に取り上げるかはすごく迷う本。上に示したリンク先でどういう人が川上氏と対談しているかわかる通り、ドワンゴの身内の人やはてなの伊藤直也氏とか今ではフリージャーナリストとしてテレビコメンテータにもなっている津田大介氏や将棋棋士・谷川浩司氏、SF作家・藤井太洋氏などいろいろな人がゲームプレイ遍歴やビジネスや会社組織やその人の興味関心のあるテーマについて語っている。

連載初期の方はみんなゲーム廃人みたいな人ばかり出てきて、マニアックすぎると思うと同時に、あるあるwwと共感しつつも読める。「Ultima Online（ウルティマオンライン - Wikipedia）」や「Diablo（ディアブロ (ゲーム) - Wikipedia）」にハマってリアルでの生活に支障をきたすくらいとか。川上氏は3日連続で寝ないでぶっ続けでやってやばいと思ってなんとかアンインストールしたらしい。

僕はオンラインゲームをやったことがないけど（絶対ここに出てくるような人のように廃人になるのが目に見えてたからなんとか自重したw）、そういうゲームのはまり方はよくわかる。特に中高時代はダビスタで最強馬生産に明け暮れてたなぁとか（そのために視力と成績がガタ落ちになった!!w）読みながら自分のゲーム遍歴をオーバーラップさせてた。他にもファミコンを買ってもらえなかった人はよりコアでマニアックなPCゲームにはまっていき、ゲームを卒業できずに大人になってダメ人間になるとかなんとかw

ファミコンの懐かしいソフトやオンラインゲーム、ほかにもボードゲーム（そこに将棋も含むからプロ棋士の谷川浩司氏の対談もあり、将棋ソフトと絡めた話も面白い）、カードゲーム、最近のソシャゲについて多岐にわたり、そのゲームリストが最後に載っているのもよい。

僕は1984年生まれで、一応ファミコン世代であるので、リアルタイムでファミコンをやっていた最後当たりの世代になり（おそらく僕の2，3歳下の世代からはスーファミからの世代）、本書に出てくる人たちよりも15歳以上若いので、ファミコンを含めたコンピュータゲームの興隆をリアルタイムで体感してはいないが、その空気は十分に感じることができた。40歳以上のゲームにはまったおっさん世代は絶対懐かしくも興味深く読めるはず。そんで俺にもなんかゲームについてちょっと語らせろ!!みたいな気持ちになれると思うw

また、ドワンゴの経営方針というか、内情が川上氏の視点から語られて、ニコニコ動画とかニコニコ超会議の裏話的な話もとても面白い。ドワンゴ大丈夫か?みたいな感じだけど、何となく結果的にうまくいっていて、それが川上氏の手腕なのか魅力なのか確かなところはわからないが、変だけどスゴイ会社だなと思った。

さらに、川上氏の考え方や持論もとても興味深い。特に激しく同意!!と思った部分は連載初回のテーマのあとからコラム１の最後の部分（ちなみにあとからコラムはWeb連載上にはなく、書籍版のみ収録）。
　ちなみに。連載のこの回のタイトルは「世の中で一番面白いゲームは『現実』」とありますが、本音を言うと現実はクソゲーだと思います。だって「現実のゲーム」は自分ではコントロールできない変数が多すぎて、ほとんど「運ゲー」ですからね。ゲームバランスもなにもあったもんじゃありません。
(pp.28)
ほんこれ!!と日ごろから考えたいたことが同じように明言されていて、一人でうなづいていたのだったwまぁ、クソゲーでどうにもならなくて詰んだら死ぬじゃん、みたいなところはあるし、まだ積んでる状況でもないし、バグってても何とかプレイできるし、先が見えないゲームだから楽しむ余地もたくさんあるじゃないか!?と前向きに考えて生きていきたいと思う。

ゲーマーが経営者となるべき、を体現しているのが、連載の最終回の任天堂の岩田 聡氏の回。ちょうど去年の年末の今頃に公開されており、確か読んだ記憶がある。しかし、岩田氏の書籍化を望まれていないという意向もあってこの回は本書には収録されていない。そしてさらに残念なことに、岩田氏は本書が出版された後の今年7月に若くしてお亡くなりになられてしまった。この回はWeb上でしか読むことはできないので、この回だけでも読んでおく価値はあると思う。経営論としても本書の連載のテーマに一番沿った内容でもあるし。

なんというか、本書の面白さはいろんな要素が含まれまくっていてうまく伝えきれないので、もうゲーマーというかゲーム好きな人はさっさと連載記事を読めばいいんだよ!!みたいな感じ。ゲームにかかわらずWebサービスやコンテンツビジネスをしている人も面白くかつ勉強になることも多い。でもビジネス書のように読むと、内容がマニアックすぎてなんじゃこりゃ!?と面食らうかもしれないwでも経営論というか組織論とかもところどころで論じられていて、そこも勉強になる。

個人的な話をすると、今年はいろいろあって、休職することになり、その間は暇なので久しぶりにゲームの封印を解いて（ゲームよりリアルをプレイしなくちゃと思って自重してたわけだ）PS4を買ってプレイしてみたらやはりゲームは面白いなと思った。あとは東京ゲームショーにも行ってみて、ひと昔前はゲーム業界はもう落ち目だと思っていたけど、全然そんなことはないなと実感した。

自分の今後のキャリアについて考えて、好きなことをやるべきかなと思っていたときに本書を読んで、来年は思いっきりゲーム漬けになろう!!と腹をくくれたわけだ。そんでなんとかゲーム業界に逝こう!!、そしてゲーム廃人になろう!!を来年のテーマとしていきたいと思うww

(ﾟДﾟ)

ちなみに本書の単行本は560ページと分厚く、値段も2000円ほどする。タダで読みたい人はWeb上の記事を読めばいいし、もっと便利にかつあとからコラムも読みたい人はKindle版がよいと思う。Kindle版は1000円以内で買えるし。

とにかく、ゲーム好きな人は絶対読め!!な1冊で、読んでいるだけでニヤニヤできるし、なんというか、昔感じたゲームのときめきみたいなものを思い出せたとても良い本だった。

（追記）
この記事を更新してからちょうど翌日、任天堂の岩田氏の追悼特別記事がアップされてた。本当にスゴイ人だったんだなと思わされる超良記事。そして合掌。


ゲーマーはもっと経営者を目指すべき!
ゲーマーはもっと経営者を目指すべき! [単行本]
4Gamer.net編集部
KADOKAWA
2015-04-24

読むべき人：
  • ゲーマー（廃人）の人
  • 経営者の人
  • ゲームを作りたい人
Amazon.co.jpで『川上量生』の他の本を見る

bana1 ゲーマークリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 18:45│コメント(0)│トラックバック(0) 


December 27, 2014

独習Javaサーバサイド編 第2版

独習Javaサーバサイド編 第2版
独習Javaサーバサイド編 第2版 [大型本]
キーワード：
　山田祥寛、Java、JSP、MVC、JSTL
JSP、サーブレットの独習本。以下のような目次となっている。
  1. 第1章 イントロダクション
  2. 第2章 JSP(JavaServer Pages)の基本
  3. 第3章 リクエスト情報
  4. 第4章 データベース連携
  5. 第5章 JSTL(JSP Standard Tag Library)
  6. 第6章 サーブレット&JavaBeans
  7. 第7章 デプロイメントディスクリプタ(基本編)
  8. 第8章 デプロイメントディスクリプタ(応用編)
  9. 第9章 JSP&サーブレットで利用可能なライブラリ
  10. 第10章 セキュリティ対策
(目次から抜粋)
本書で技術本カテゴリのちょうど100冊目!!

今年こそJavaを習得して、仕事でもJavaの開発プロジェクトにアサインされたいと思っていた。なぜなら、Java案件の需要がかなりあるし、C#はたまたま自社ではもう取り扱って行かない言語になっていくことが決まっていったので。今までVBA、.NET、C#とやって来ていたので、そろそろJavaを本格的に学習しようと思って本書を手に取ってみた。

最初のイントロダクションの章ではTomcat、MySQLのインストール方法などもキャプチャ付きで示されている。また、JSPの基本、リクエスト情報の章ではPOST、GETの違いなど初歩的な部分から説明されていてわかりやすい。

自分がJSP、サーブレットを最初に学習したのは2006年の入社後の研修時で、そのときに学んだきりで使用することもなかったので、ほとんど忘れてしまっていた。またその時から時間も経っているのでJSPのバージョンも変わり、Javaコーディングに精通していないデザイナ的な人もJSPページを作成しやすいアクションタグのJSTLなども追加されているので、これは知らなかった。各章図説入りでかなり分かりやすい説明だと思う。ダメな技術本は日本語の説明がおかしかったりするが、これはすんなり頭に入ってきた。また、各章の途中に随時練習問題があったり、章末に理解度チェック問題がある。それらをやっていくことで理解が深まるはず。

書店でJSP、サーブレットの本をいくつか見比べてみたけど、本書が一番最新バージョンかつ網羅性があり、入門的な内容だった。実際に読んでみると、分かりやすく、特に躓くようなところもなかったかな。実際にサンプルを打ち込んではなく、読んだだけなのだけど。Javaの基本を習得しており、JSP、サーブレットなどWeb系の基礎を習得したい場合は本書が最適と思われるのでおお勧め。

Kindle版もあるようなので、通勤電車で読みたい人はそっちを購入するのがよいと思われる。僕は大型の紙の本を買って学習したのだけど。

来年こそJava案件をやりたい。


独習Javaサーバサイド編 第2版
独習Javaサーバサイド編 第2版 [大型本]
山田 祥寛
翔泳社
2013-01-29

読むべき人：
  • JSP、サーブレットを学習したい人
  • アクションタグについて知りたい人
  • JavaのWebアプリケーションの仕組みを勉強したい人
Amazon.co.jpで『JSP/サーブレット』の他の本を見る

bana1 JSPクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 21:07│コメント(0)│トラックバック(0) 


July 26, 2014

システム設計の謎を解く

システム設計の謎を解く 強いSEになるための、機能設計/入出力設計の極意
システム設計の謎を解く 強いSEになるための、機能設計/入出力設計の極意 [単行本]
キーワード：
　高安厚思、システム、設計、アーキテクチャ、指南書
システム設計の指南書。以下のような目次となっている。
  1. 序章 本書の構成と概要
  2. 第1章 設計の謎
  3. 第2章 設計へのインプット~要件定義行程の概要~
  4. 第3章 設計する前にやるべきこと~共通設計~
  5. 第4章 アプリケーション設計としてやるべき作業
  6. 第5章 アーキテクチャ設計としてやるべきこと
  7. 第6章 本書の知識を現場で活用するために
(目次から抜粋)
本書の概要がまえがきに示されているので、そこから抜粋。
　本書は、著者の豊富な現場経験と幅広いソフトウェア工学の知識に基づき、「設計」というシステム構築の要諦を体系的かつ実践的に習得させることを目的に記された指南書である。
(pp.iii)
あまり経験がない場合、システム開発における「設計」というと、いったい何をどうすれば設計したことになるのか?というのが感覚的にわからなかったりする。画面設計、DB設計、IF設計、帳票設計などなど、その中身もいろいろとある。本書は「Webシステムを利用した基幹業務系システム」を例に各種設計の具体的なサンプルが示されている。

書店に行ってもシステム設計の具体的なサンプルが示されていたり、何をどうやって設計すればよいのかを示した良書があまり見当たらなかったりする。そもそも「設計」にフォーカスした書籍もそんなに多くない。まったく、設計の本がないわけではないが、あってもあまり使えないものだったり、サンプルの例が古すぎたりする。しかし、これはかなり実践的にそのまま使える本。

例えば、画面項目設計では、ID、項目名称、ラベル、部品種類、型、桁、フォーマットなどなど定義すべき項目の一覧が示されている。さらにその項目の一覧から設計サンプルが示されている。これを元に設計書にそのまま利用できるくらい。もちろん、これから自分の仕事の対象のシステムにそのまま利用できない部分もあるが、各設計で気をつけなくてはいけないことなども示されている。

さすがにそれなりに設計経験があるので、何をどう設計すべきかは感覚的にわかっている。それでも、改めて一通り示されている内容を読んでみると、やったことない部分などもあるし、復習にもなったと思う。

ただ、『決済』と『決裁』の漢字の誤記の部分が全体的に何か所かあり、それは業務系SEにとっては間違えてはいけない漢字なのだけどなと。校正があまいなと思う。よく間違えがちな漢字だけど、どっちがどっちの意味かはちゃんと覚えておきましょう。

初めて設計する場合は、このようなサンプル的な本がとても役に立つと思われる。2，3年目くらいのときに読みたかったなぁと思う。また、以下の本と合わせて読んでおけばより設計の知見が深まるはず。本書は2，3年目くらいに読みたかったなぁと思った。もちろん、必要に応じて読み返して読むに値する本。暗記するくらい読んでもいいかもしれない。


システム設計の謎を解く 強いSEになるための、機能設計/入出力設計の極意
システム設計の謎を解く 強いSEになるための、機能設計/入出力設計の極意 [単行本]
高安 厚思
ソフトバンククリエイティブ
2013-05-24

読むべき人：
  • はじめて設計をする人
  • Webシステムの開発者の人
  • 強いSEになりたい人
Amazon.co.jpで『設計』の他の本を見る

bana1 設計クリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 20:51│コメント(0)│トラックバック(0) 


July 23, 2014

Head First Java 第2版

Head First Java 第2版 ―頭とからだで覚えるJavaの基本
Head First Java 第2版 ―頭とからだで覚えるJavaの基本 [大型本]
キーワード：
　Kathy Sierra, Bert Bates、Head First、図解、Java
オライリーのHead FirstシリーズのJava学習本。内容の概要、目次、サンプルなどがちゃんとオライリーのページにあるので、そちらを参照。商品説明が他の出版社よりも多くてわかりやすいのでとてもよいのだけど、正誤表が完全ではないので注意。ここに示されている正誤表は全体の間違いの3割くらいしかカバーされていないような印象。完全版の正誤表は出なさそうなので、第3版が出版されるの待ちか。

オライリーのHead Firstシリーズは脳が効率よく学習できるようにイラストや図解、写真が豊富に示されている。どうでもいいガチョウとか赤ん坊とか犬とかエイリアンなどなど。それらによって認知能力が高まるらしいという研究結果に基づいて作られているようだ。そのため、680ページ近くあるが、他の技術本に比べてかなり楽しんで学習できる。

今年の目標はJavaだ!!と思って本書をなんとか最後までやり遂げた。本書を買ったのはちょうど入社したての頃の8年前で、ずっと積読状態だったww4割くらいまでやって結局仕事でJavaを使うようなPJTに行かなかったので、読まずじまいだったのだけど、割と時間のあるタイミングだったので学習できた。保留事項を一つ完了にできた気分。

本書の初版が2006年で、扱われているJavaのバージョンが5.0で、まだSunの時代。今ではOracle傘下になっており、バージョンもだいぶ先まで行っているので若干注意が必要かも。それでも基礎的なことは十分学べる印象。ただ、ServletやJSPなどのサーバサイド部分はほとんど触れてないので、それらは別で学習するしかない。

手書きで本書に書き込んだりちゃんと自分で考えようというコンセプトなので、割と忠実にそれにしたがってやった。章の最後のエクササイズなども自分でやってみた。また、プログラミング言語学習は読むだけでは学習効率が悪いので、ちゃんとサンプルプログラムをほぼEclipseで打ち込んで実行してみた。時間はかかるけど、しっかり習得しようと思うなら、読むだけではなく写経のように一応自分でタイプするのがいいかな。

本書の大きな欠点は、間違い、誤記が頻出していること。自分で正誤表を作ろうかと思ったけど多くて面倒になってやめた。むしろ間違い探しのエクササイズだと思ってやるのがいいかも。誤記でその解説内容が全く意味不明という部分はなかったけどね。

本書は基本的な部分だけの解説がメインで、Javaのすべては網羅されていないので（バージョンも古いし）、本書の対象範囲外は他の本で補完する必要がある。Javaの本はいろいろあるのだけど、これが最初の1冊としては最適かもしれない。もちろん、分厚いし自分で考えて手を動かす必要があるので、しっかりやろうと思うと2,3か月はかかるかな。それでも、微妙な他の本をたくさん買って分からないままよりはいいと思う。

Javaの基礎を習得したので次のPJTはJavaかな!?と若干期待していたのだけど、次もC#案件だった件wwまぁ、前回からの延長ということでいいのだけど、今後C#（.NET）案件にはアサインされなさそうなので、いずれJavaをしっかりできるようになる必要がある。あと、一応Javaの基礎を習得したので、今年の目標はほぼ達成したことにしよう!!（これだけじゃ足りません）ww


Head First Java 第2版 ―頭とからだで覚えるJavaの基本
Head First Java 第2版 ―頭とからだで覚えるJavaの基本 [大型本]
Kathy Sierra
オライリージャパン
2006-03-01

読むべき人：
  • プログラミングをしてみたいと思ったことがある人
  • Javaを学びたい人
  • 楽しく勉強したい人
Amazon.co.jpで『Head First』の他の本を見る

bana1 Head First Javaクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 20:49│コメント(0)│トラックバック(0) 


July 09, 2014

ソフトウエア開発55の真実と10のウソ

ソフトウエア開発 55の真実と10のウソ
ソフトウエア開発 55の真実と10のウソ [単行本]
キーワード：
　ロバート・L・グラス、ソフトウェア、研究、真実、ウソ、銀の弾丸
ソフトウェア開発における真実が55、ウソが10個示されている本。本書の内容が大まかにわかる目次が出版社のページにあったので、そちらを参照。著者は企業に所属する技術者、または大学での研究者としてソフトウェア工学の世界に45年以上（本書出版は2002年なので、現在では60年近く!?）携わってきており、書籍を25冊、論文を75本書いているようだ。そんな著者によって、ソフトウェア開発における一般的に知られている真実、またはまったく知られていない真実、そしてウソを各種文献、論文をもとに列挙している本となる。

各種の真実、ウソの構成として、最初に概要を述べ、次にその反論を示している。最後に真実の情報源が論文や各種文献として示されている。

本書は以下の本で、『初級』レベルより上に進むために開発者が読むべき本として取り上げられていたので、読んでみた。CODE COMPLETEにもつながる内容が多く示されていたなと思う。

さて、前述のリンク先の目次をざっと眺めてみると、聞いたことがある、経験則的にわかっているというものも多いと思う。例えば、『真実3：遅れているプロジェクトに人を追加すると、もっと遅れる。』は、ソフトウェア工学をちゃんと勉強した人なら当然知っている、ブルックスの法則だね。本書に示されているように、この真実を根本から否定する人はほとんどいないとある。まぁ、そうだよねと。人員投下で何とかなったためしがない。表面上スケジュールに間に合ったとしても、コスト面では赤字になったりとかね・・・・。

そして次は『真実8：プロジェクトが大失敗する原因には二つある。一つは見積もりミスだ』を見てみよう。本書によれば、見積もりの大部分は非現実的で単なる希望に過ぎず、21世紀になっても、適切な見積もり手段がないと示さされている。これはもう自分のタスクでも正確に見積もるのが難しいと実感するのに、大規模見積もりとなると、不正確にならざるを得ない。あとは、競争入札で勝つために無謀な見積もりになっていたり・・・。さらには、見積もり手法としてファンクションポイント法や他の開発プロジェクトを参考にするというのがまったく有効でないということもいろいろと示されていて、そうだよねとうなずくばかり。

さらに『真実10：見積もりは、上層部かマーケティングが実施する場合がほとんどだ。実際にプログラムを開発したり、開発プロジェクトの直接のマネジャが見積もることはない。結局、適切な人が見積もっていないのだ。』はみんな実感しているだろう。やっぱりプログラミングや開発経験のない人が提案して全体の開発スケジュールを決めるのはダメだよね。そんでいざPJTが開始になって、デスマーチ確実で下っ端は死ぬ!!!!wwということになりかねない。

保守のカテゴリでは『真実41：保守には、ソフトウエアのコストの40〜80％(平均60％)がかかる。従って、ソフトウエア・ライフサイクルの最重要フェーズである』とある。これは、ソフトウェア技術者がよく忘れる真実の代表として挙げられている。なので、ソフトウェアサイクルで最も重要なフェーズとして示されている。

そして、『真実45：優れたソフトウエア・エンジニアリングに沿ってプログラムを開発すると、保守は減らず、かえって増える』は、最大級の意外性で、これはどういうことだってばよ!?wとなった。その部分の理由を以下に引用。
新技法で開発したシステムは、何度も変更を繰り返すため、保守期間が長くなる。このシステムは、構造がきれいなのでエンハンスが容易であり、それゆえ、何度も変更を繰り返すのだ。
(pp.199)
保守というのは、『問題』として扱うのではなく、すでに出来上がったソフトウェアの改善に導く『解法』であるという考えにつながるようだ（真実43 保守は解法であり、問題ではない。）。

また、真実21に関して、著者が本書でこれだけは覚えておいてほしいという部分があるので、そこを引用しておこう。
この本を読んで、すべて忘れてもよいが、次のことだけは、覚えていてほしい。「対象となる問題の複雑度が25%増加するたびに、ソフトウェアによる解法の複雑度は100%上昇する」。また、この問題を一挙に解決する「銀の弾丸」はないことも、記憶してほしい。ソフトウェアが複雑なのは、ソフトウェアの性格なのである。
(pp.98-99)
そして、さらに、真実31（ソフトウエア開発のライフサイクルで、不良除去に最も時間がかかる。）に関して、以下の部分も引用しておこう。
この真実は、本書で繰り返し述べている「圧倒的な真実」、すなわち、「ソフトウェアを開発することは、きわめて難しく、エラーが入り込みやすい」ということの一部である。希望や革新的技術や銀の弾丸では、この真実を変えられない。
(pp.147)
本書を読めば読むほど（そして自分の過去の経験からも）、『どんなに頑張ってもあなたはバグのない完璧なソフトウェアを作り上げることはできない』という絶望にまみれた真実を突きつけられるのであった!!（なんかもう転職して職業を根本から変えたくなってくるね!!w('A`)）

2，3ページで1つのトピックなので割と読みやすい。自分の経験則と照らし合わせて、あるある!!と共感する部分も多いし、はて、それは本当に正しいと言えるのだろうか!?と思うものもある。本書の知識を実際の現場で有効活用できればいいのだけどね。

本書はすでに絶版になっているようだ。もしかしたら大型書店で売れ残っているかもしれない。ソフトウェア開発、システム開発の仕事をしている人、ソフトウェア工学を学ぶ学生、そして研究者の人も中古でもいいから買って読んでおいて損はない。


ソフトウエア開発 55の真実と10のウソ
ソフトウエア開発 55の真実と10のウソ [単行本]
ロバート・L・グラス
日経BP出版センター
2004-04-08

読むべき人：
  • ソフトウェア開発者の人
  • ソフトウェア工学を研究している人
  • 完璧主義者の開発者の人
Amazon.co.jpで『ロバート・L・グラス』の他の本を見る

bana1 ソフトウェア開発クリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 12:33│コメント(0)│トラックバック(0) 


February 27, 2014

情熱プログラマー

情熱プログラマー ソフトウェア開発者の幸せな生き方
情熱プログラマー ソフトウェア開発者の幸せな生き方 [単行本（ソフトカバー）]
キーワード：
　Chad Fowler、プログラマー、情熱、キャリア、生き方
プログラマー向けのキャリア論。目次はちゃんと出版社のページに全部載っていたので、リンク先を参照と（オーム社は目次の重要性をちゃんとわかっていて、いいね！）。本書の概要が「イントロダクション」に示されていたので、そこを引用しておく。
　この本は自分のキャリアにおいて充足感と幸福感を得るためのものである。充足感と幸福感は偶然に得られるわけではない。間違いを犯したときに進路を変えるためには、思索、意思、行動、そしてやる気が必要だ。この本はソフトウェア開発におけるキャリアで（したがって人生で）根本的に成功を収めるための戦略を提示する。
(pp.xiii)
著者の経歴はちょっと変わっていて、当初は音楽大学でサックスを学んでおり、ジャズプレイヤーであるミュージシャンであった。あるとき、ゲームをやりたくてプログラミングを独学し、本格的にソフトウェア工学、プログラミングを学んでいる友人からいろいろと教えてもらいながらソフトウェア開発会社に就職する。そしてアメリカ以外にもインドのバンガロールなどでも働き、プログラマーだけではなくプロマネ的な立場にもなっている。そんな著者によって、情熱的に働くことの重要性がわかりやすく、かつ具体的な内容で示されている。

率直な感想を言えば、もっと早く読みたかったぞ!!というような内容だった。ある程度仕事をしていると行き当たる壁というか、陥りがちな考え方とそのアンチパターンのようなものが示されている。読んでいるとなんというか、耳が痛いことが多く書いてあって、線をひきまくった。

その線を引いた部分をちょっと多めに引用しておきたい。
  • ビジネスの分野における経験は、自分のレパートリーのなかでも重要な部分だと考えるべきだ。（「3 コーディングはもう武器にはならない」pp.9 ）
  • 機会を与えられるだって！そんなの僕だってなかったよ！僕は学ぶ機会を自分でつかまえたんだ。（「5 自分の知性に投資しよう」pp.17 ）
  • 君の目標が解雇やオフショアの嵐の中で最後まで生き残ることなら、自分自身の汎用性を高めておいたほうがいい。（プラットフォームの垣根を越えたスキルを身に付けろ）（「7 万能選手になろう」pp.24-25 ）
  • 自分の仕事で秀でた存在になりたければ、自分の仕事に情熱を注がないとだめだ。（「10 愛せよ、さもなくば捨てよ」pp.32 ）
  • まずは仕事で使うツールについて勉強しよう。（教えてくれるのを待つな。自分から訊け！）（「11 魚の釣り方を学ぶ」pp.40 ）
  • ビジネスの仕組みを知りもしないで、ビジネスが利益を上げるために想像力を働かせて協力できるだろうか?（「12 ビジネスの仕組みを学ぶ」pp.43 ）
  • これからも品質という基準で戦うつもりなら、実務で練習するという考え方は捨てなければいけない。自分の技術に対して時間を投資しなければ。（「15 一に練習、二に練習」pp.50）
  • 顧客の要求以上の対応をしたり要求する前に対応を済ませたりすれば、顧客は満足どころか大喜びだろう。（「20 読唇術」pp.70 ）
  • 自分の功績を認めてもらいたいなら、まずマネージャから評価されないといけない。（「22 誰のために働いているのか思い出す」pp.75 ）
  • 彼は並の働きしかしないし、態度もよくない。たとえ高い可能性を秘めていても、それが何だっていうんだ？現時点でそれを発揮していないじゃないか。（「23 今の職務を全力で」pp.76 ）
  • ヒーローはあわてない（「31 あわてるな」pp. 99）
  • 君は他人の評価を気にすべきだ。認識されたものこそ現実なんだ。このことを受け入れよう。（業績の客観的な評価なんてありえない）（「33 弱点が違えば認識も異なる」pp.112 ）
  • 顧客はビジネスのニーズを主張し、君は報酬をもらってニーズを満たすんだ。このことを忘れちゃいけない（「34 アドベンチャーツアーガイド」pp.115 ）
  • 君の短期的なキャリア目標がレベル23のプログラマからレベル24のプログラマアナリストになることだとしても、プログラマとして次の昇進や現在の職場といった枠を超えて考えることも必要だ。（「39 業界で名前を売ろう」pp.126 ）
  • 自分はプログラマ（あるいは設計者、テスター）だっていうアイデンティティにこだわるな。（「45 君は既に職を失っている」pp.145）
  • 君のキャリアにとって本当に重要なのは昇進でも昇給でもない。重要なのは、そういう成果を得るために努力した時間だ。もっと重要なのは、そういう成果と関係ないところで努力した時間だ。（「46 終わりのない道」pp.147 ）
  • 大きな目標を立てたら、それを常に見直すようにしよう。経験から学び、進みながら目標を変更していこう。（「51 ウォーターフォール式のキャリア計画はやめよう」pp.161 ）
仕事でうまくいってなかったりして、評価が微妙だったりすることもある。そういうときは、なんで評価されないんだ?とかプロマネがダメなやつなんだよとか、技術領域がそもそも自分の得意分野ではなかったとか、対象業務分野が自分の経験のあるものではないしなとか、自分の技術レベルではこのままではジリ貧になるなとか、そもそもこの仕事はまったく面白くないし、しんどいだけだから転職しようかなとか考えたことのある人は（もちろん全部考えたことあるぞ!!w）、ぜひ読んでみたほうがよい。

それらの考えは誰もが陥りがちな罠みたいなもので、それらに対するヒントが示されている。こういうのは、誰かに指摘されるまで気づかなかったりする。たとえ指摘されても、そんなわけあるかと直視（客観視）できなかったりするしね。そういうときに、自分で気づけるかが重要で、本書は嫌でも気づかされる。そして、自分のこれまでを反省せざるを得ない。

もちろん、反省しっぱなしで終わらずに、熱い気持ちにさせてくれるのが本書のよいところ。若干自己啓発的な感じではあるけど、ソフトウェ開発者のために具体的に示されているので、書店の自己啓発本コーナーに並んでいる微妙な自己啓発本よりも断然によい。ある程度プログラマーなどの技術職を経験したことがある人は、あるあると、経験則的に納得したりできる部分は多いと思う。

結局、今までの自分に圧倒的に足りなかったものは、技術力ではなく、『情熱』なんだということがよくわかった。そして、まだこの仕事で勝負してみたいと思ったから、格ゲーで負けた時に出てくる10カウント中にコンティニューボタンを押すように、再チャレンジしていきたいと思った。そんなこんなで、最近はずっと放置していたJavaの強化トレーニング中だ。

炭火のように静かに熱く火をつけてくれるような本だった。何度も定期的に繰り返して読みたい1冊。


情熱プログラマー ソフトウェア開発者の幸せな生き方
情熱プログラマー ソフトウェア開発者の幸せな生き方 [単行本（ソフトカバー）]
Chad Fowler
オーム社
2010-02-26

読むべき人：
  • 自分のキャリアについて考えたい人
  • プログラマー、SEを辞めようかと思った人
  • 情熱的に生きたい人
Amazon.co.jpで『Chad Fowler』の他の本を見る

bana1 情熱プログラマークリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 22:02│コメント(0)│トラックバック(0) 


February 16, 2014

なれる!SE 2週間でわかる?SE入門

なれる！SE 2週間でわかる？SE入門 (電撃文庫)
なれる！SE 2週間でわかる？SE入門 (電撃文庫) [Kindle版]
キーワード：
　夏海公司、SE、ネットワーク、ツンデレ、仕事
SEの実態が描かれたラノベ。以下のようなあらすじとなっている。
平凡な社会人一年生、桜坂工兵は厳しい就職活動を経て、とあるシステム開発会社に就職した。そんな彼の教育係についた室見立華は、どう見ても十代にしか見えないスーパーワーカホリック娘で!?多忙かつまったく優しくない彼女のもと、時に厳しく指導され、時に放置プレイされながら奮闘する工兵。さらには、現場を無視して受注してくる社長のおかげで、いきなり実際の仕事を担当させられることになり―。システムエンジニアの過酷な実態をコミカルに描くスラップスティック・ストーリー、登場。
(Amazonの商品の説明から抜粋)
2年前くらいにネットで話題になっていて、存在は知っていて気にはなっていた。最近以下の著者インタビュー記事を読んでから、より関心がわいて、ためしに1巻をKindleで買って読んでみた。著者はバリバリのSE経歴があり、物語の半分は実体験が元になっているらしい。へーと思った。大変だねとも思ったw

シリーズ化されていて、この記事投稿時点で11巻まで刊行されているようだ。第1巻目は、主人公工兵が就職活動を経てシステム開発会社になんとか就職するも、そこは従業員が少なく、しかも社員が会社で寝泊まりしているようなブラック企業!?だった!!文系卒で何もシステム、コンピュータのことがわかっていない状態で、中学生のような容貌のツンデレ女性上司、室見から無茶ぶりでCiscoルーターのコンフィグ設定のタスクを投げられる。設定内容がさっぱりわからない状態で、締め切りは今日中という無茶ぶり!!そして2週間の試用期間の評価が悪ければクビに!!どうする、工兵!?というお話。

表面上はラノベの体裁で、文章は短く、改行も多く、主人、工兵の一人称で物語は進むのでかなり読みやすい。登場人物も平凡な新卒文系社員の工兵（もう名前からしてソルジャー社員じゃないか!?ww）、その上司である年齢不詳の中学生のような容貌の室見（ツナ好き、仕事人間、嫌いな人には無関心、怒るとドライバーが飛ぶ!!wでもツンデレ）と派遣社員のカモメ（Excelのショートカット使いまくりで目にも止まらない速さで事務処理をこなす!!、裏設定で麻雀ゲームが最強レベルで電気系にも地味に強い）などなどラノベっぽい設定とお決まりなドキドキな展開!?が繰り広げられて楽しめる。

しかし、この物語の本質は単純なラノベではなかった。なんとうか、これはSE入門書というか、本質は仕事論の物語であるなと。

SEというとよくネット記事で残業地獄で心身ともに壊れたりしたり、2次受け、3次受けの独特の受注階層構造になっていたりし、低賃金だったりプロジェクトは火を噴きまくりでIT土方、奴隷など揶揄されている。僕も職業はSEなので、まぁ、そういう部分もあるなと実感する。すべてではないけど。あと、ちょうど最近以下のスレがあったので参考に。それでもSEとしての面白さ、醍醐味が工兵の成長を通して描かれている。たとえば、SEのやりがいとして、本作では『「何かを自分の手で作り上げる快感」』というものが示されている。あぁ、そうだよねと思った。他社ベンダーから引き継いだクソな設計、しかもドキュメントなし、コードもイケてないものを保守しなくてはならないときはそういったものをあまり感じられないけど、自分で設計、プログラミング、テストまでこなし、そしてカットーバーを迎えると得も言われぬ達成感があるのは間違いない。僕は過去にそんなにたくさんそれを経験したことがあるわけでもないけど、そういう経験があったなぁと思い出した。

あとは工兵が仕事を始めたばかりで、母親との電話での会話部分から。
「ねぇ、働くって大変だね」
（中略）
『あたりまえじゃない、何言ってるの。みんなその大変なことをやって暮らしているのよ』
(58%部分)
まぁ、そうだよね。実際に自分の母親も働いていて、そんなことを言っていたような気がした。

一応エンタメ作品であるから、工兵のようにすぐに1年目でやりがいとか面白さを感じられるかは人によるとしか言いようがないかな。そもそも向き不向きというのが少なからずあるからね。それでも3年目まで必死でやって、こういうやりがいとか面白さを感じられればいいね。必死でやってもしんどいだけで得るものもやりがいもないと思ったら、さっさと見切るのもよしかな。

工兵と室見のラノベ的なやり取りで(・∀・)ﾆﾔﾆﾔしたり、ドキドキしたりしつつも、上司が鬼軍曹みたいなのだったり、顧客に無茶ぶりされたり、納期がやたらと短かったり、納入機器のバグがあって危機的状況に陥るという部分もあるある!!wと突っ込みつつも、自分の仕事に当てはめて想像して逆の意味でドキドキ（胸の動悸w）がして、よくも悪くも精神的に揺さぶられてくる。そして、読み物としても面白いんだな。

表紙はラノベ丸わかりなので、本として電車で読む場合はカバーを付けたほうがいいかもね。僕は主にスマフォのKindleアプリで読んだ。これだと表紙とか分からないし。あと、読了してみて、スマフォのKindleとラノベは相性が良いなと思った。文章がもともと短いし、改行が多いので、スマフォの1ページ当たりがちょうどい文章量になる気がする。また、電車待ちなどの隙間時間に数ページずつ読んで区切っても、難しい描写もないし、シーンも数行で変わったりするので、途中から読んでもすぐに内容に没頭できるし。なので、紙より安いので、Kindle版がオヌヌメ!!

続編もいろんな展開になり、純粋に勉強になる部分が多い感じなので、全部買って読もうと思った。あと、本書は技術者向けなので、この本のブログのカテゴリは『文学作品』ではなく、『技術本（コンピュータ関連）』に設定した。

これから就職活動をする人は、これがすべてではないけど、SEの仕事としては割とリアルな内容なので参考になるし、実際にSEとして働いている人は萌えながらも勉強になったり、きっと自分の仕事を頑張ろうと思えるはずだ!!


なれる！SE 2週間でわかる？SE入門 (電撃文庫)
なれる！SE 2週間でわかる？SE入門 (電撃文庫) [Kindle版]
夏海 公司
KADOKAWA / アスキー・メディアワークス
2012-10-04

読むべき人：
  • 就職活動中でSE志望の学生の人
  • 現役SEとして働いている人
  • 自分の仕事について考えてみたい人
Amazon.co.jpで『夏海公司』の他の本を見る

bana1 なれるSEクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 17:12│コメント(1) 


February 11, 2014

CODE COMPLETE 第2版

CODE COMPLETE 第2版 上CODE COMPLETE 第2版 下
CODE COMPLETE 第2版 上 [単行本]
CODE COMPLETE 第2版 下 [単行本]
キーワード：
　スティーブ・マコネル、コード、コンストラクション、可読性、奥義書
米ソフトウェア界の第一人者による、プログラミングの指南書。目次はかなり多いので、以下のリンク先を参照。最初に結論を示しておこう。

プロプログラマーならこれを読まずにプログラミングをすることなかれ!!なぜなら、これはプログラマーにとっての圧倒的な奥義書だからだ!!

初版は1994年に出版されており、2005年に改訂版として本書が出版されている。上下巻構成で合計1,272ページ、重量約2kg(体重計で測った!!w)の圧倒的なボリュームであるが、プログラミングのお作法的な本として、テーマの網羅性、内容量、分かりやすさ、使える度に関して、これ以上の本は読んだことがない!!もしこの本以上のプログラミングお作法本があるなら、教えてくれ!!っていうような内容。

本書のテーマとして、「ソフトウェアコンストラクション」という言葉が示されている。これはソフトウェア開発におけるプロセスのことで、本書では特にコーディングとデバッグがメインで、その他に詳細設計、コンストラクション計画、単体スト、統合、統合テストといった部分が示されている。

そして、このソフトウェアコンストラクションはなぜ重要かというと、以下の理由が示されている。
  1. コンストラクションはソフトウェア開発の大部分を占める
  2. コンストラクションはソフトウェア開発の中心的なアクティビティである
  3. コンストラクションに専念することで、個々のプログラマの生産性は驚くほど向上する
  4. コンストラクションの成果物であるソースコードは、多くの場合、ソフトウェアを正確に書き表した唯一のドキュメントである
  5. コンストラクションは必ず実行される唯一のアクティビティである
なので、特にコーディングに関しては以下の2点が最重要なテーマとなる。
  • ソフトウェアに不可欠な技術的な要素として、設計、コードの複雑さに適切に対処すること
  • コードの読みやすさ
これらをテーマとして、目次に示されている内容がかなり分かりやすく、網羅的に示されている。

もう少し補足すると、複雑さに対処するということはどういうことかというと、設計やコードをなるべく分かりやすくすべきということになる。複雑な部分は他の人が理解するのに余計な労力を強いることになり、そしてそういった部分にバグが混入しやすい。結果的にソフトウェア品質が落ちてしまう。

よって、変数名は分かりやすく意味のあるものを付ける、クラスを適切に分割する、カプセル化でメンバデータを保護する、クラスの継承をしすぎない、多重ループを避ける、if分のネストも制限する、ポインタを使用しなくても実現できるなら使用しない、ルーチンの引数を増やしすぎない、などなどといったプログラミングの基本的なお作法が必要になる。

また、ソフトウェア開発におけるプログラミングというのは、本書によれば、実際にコードを書いているよりも他の人が書いたコードを読んでいることのほうが時間的に多いので、適切なコメントを設定し、読みやすくするべきとある。たとえ自分しか読まないコードだったとしても、それを1ヵ月後などに手を入れる時などに、読みにくいコードを書いていた場合は、なんだこれは!!と思うことは確実なので（あるあるw）、ちゃんと読みやすくしましょうと示されている。

詳細な内容については、もう読んでくれ!!としか言いようがない。もちろん、著者もまえがきで示している通り、すべてに納得がいくわけではないとある。それはその通りであるが、納得がいかない部分に関しても、自分なりのコードのスタイルを確立するための一つの参考になり、結果的に勉強になる。

上巻は主にコードの書き方そのものに関して示されており、下巻はすでにあるコードの改良やプロプログラマーとしての心構えなどが示されている。上巻だけでよい、ということはなく、下巻も合わせて読むべき。個人的にはむしろ下巻のほうが割と心に残った気がする。

ボリュームは相当多いのだけど、他の翻訳本にありがちな分かりにくさはほとんどない。まず日本語訳がすばらしい。意味の通らない文、原文が想像できるような変な日本語はなかった。また、本書のページ構成もちゃんと構造化されていて、分かりやすい。そもそもコードを読みやすくしましょうと説いている本が読みにくい構成だったら説得力がないし。つまり、翻訳技術本としてはかなり読みやすいと実感した。

これがなぜ奥義書かというと、分かりやすさとテーマの網羅性もあるのだけど、決定的なのは先人の英知の結晶であるから。つまり、本を書いたのは著者一人なのだけど、初版から第2版まで相当の専門家のレビューを受けているし、何よりも圧倒的な参考文献の量が品質を担保していると言える。

参考文献だけで30ページも詳細に示されており、研究論文から定番本の『人月の神話【新装版】』など様々な文献が示されている。なので、これ1冊読むだけでプログラミングのお作法的な内容はほぼ網羅されていると思われる。また、本書からそれらの参考文献に知識を広げていくのもよい。

また、以前取り上げた似たテーマの以下の本も推薦図書として示されている。こちらも合わせて読んでおいたほうがいいね。

上下巻合わせて約1,200ページもあるので、買って読むのはかなり躊躇するだろう。値段も合計12,200円+税とかなり高額になるし、残念ながらKindle版もまだ出ていない。実際僕も買って2年ほど積読して放置していた。しかし、最近また自分の技術力の底上げをしようと思い立って、読み始めてみたら、案外分かりやすく、お作法的な本は別に大丈夫だろうと思っていたけど、それでもかなり勉強になった。今まで読んでいなかったことを反省しているというくらいに。

さすがに量が多いので最後まで読むのはしんどいかもしれない。そのため、記録を付けていくのがいいと思う。僕は大体20日間（間に有給休暇を挟む）で約50時間近く（ネットしたり集中していない時間も含む）かかって読了した。1日大体2時間ペースかな。そんなに時間が取れない人は、1日30分からでもぜひ読んでみてほしい。はやりのソーシャルゲーム株に数万円投資して損失を被るよりも(('A`))、本書の上下巻12,200円+税と約50時間の工数の投資のほうが確実なリターンとなるのは間違いない!!

また、同じようなテーマの本として『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)』があるが、こちらは2012年発売で、本記事の投稿時点で26件のレビューが示されている。しかし、コードコンプリートは2005年発売で、上巻で16件、下巻でわずか5件となっている。評価もほぼ5つ星でにもかかわらず。このことから推測できることは何か?

これだけの圧倒的な奥義書にもかかわらず、下巻の最後まで読了した人は少ないということ。つまり、下巻まで読了するだけで並みのその他大勢のプロプログラマーから頭一つは抜け出せるっていうことだ!!

そもそも本を読んでいる人は少数派であり、さらに本書の存在を知っているプログラマーも実はそんなにいないかもしれない。たとえ知っていても、価格とボリュームの障壁で、最後まで読んでいる人はさらに少ない。ということで、チャンスだし消費税がアップする前に速攻で買って読むんだ!!

まだ読む気になれない!?では、本書に寄せられている著名人たちの賛辞で激しく同意!!と思ったものをいくつか引用しておこう。
  • 「プログラミングスタイルとソフトウェアコンストラクションのための優れた手引書」―Martin Fowler『Refactoring』
  • 「これまでに読んだソフトウェアコンストラクションの書籍の中で最高の1冊である。どの開発者も同書を1冊手に入れ、毎年最初から最後まで読むべきだ。私は9年間これを続けているが、それでもまだこの本から学ぶことがある」―John Robbins 『Debugging Applications for Microsoft .NET and Microsoft Windows』
  • 「プログラミング技術の向上を真剣に考えているならば、Steve McConnellの『Code Complete』を手に入れるべきである」―Jean J. Labrosse 『Embedded Systems Building Blocks: Complete and Ready-To-Use Module in C』
  • 「プロのプログラマを目指しているなら、この35ドルという投資は、これまでで最も賢明な投資かもしれない。この書評を読み終えるまで待つ必要はない。今すぐ書店へ駆け込み、この本を購入しよう。McConnellが述べているように、同書の目的は、業界の第一人者と一般的な商用ソフトウェアの習慣との格差を縮めることである...驚くべきことに、彼はそれに成功している」―Richard Mateosian 『IEEE Micro』
  • 「『Code Complete』は、ソフトウェア開発に携わる...すべての人の必読書である」―Tommy Usher 『C Users Journal』
内容をちら見したい人は、以下の章が（その他の一部の章も）公開されているので、それを読んでみるのがお勧め。最後に特に本書で琴線に触れた部分を引用しておこう。下巻の第33章『個人の資質』の「専門能力を養うことを誓う」という節の最後の部分。
　初級者レベルや中級者レベルであることは罪ではない。指導者レベルではなく、上級者レベルであることも罪ではない。罪であるのは、自分の能力を向上させるために必要なことをすべて知った後も、初級者レベルや中級者レベルに甘んじることである。
(下巻 pp.437)
もう経験年数もそれなりになってきているのだし、同一クラス（職位）に停滞したままではダメだなと思っていた。だから本書を読んで技術力の底上げを図ろうとした。その目的は確実に達成された。あとは本書を何度も繰り返して読みながら、自分のコードを練っていくだけだ。

本当にプロプログラマーにとっての奥義書なので、絶対買って読め


CODE COMPLETE 第2版 上
CODE COMPLETE 第2版 上 [単行本]
スティーブ マコネル
日経BP社
2005-03-26

CODE COMPLETE 第2版 下
CODE COMPLETE 第2版 下 [単行本]
スティーブ マコネル
日経BP社
2005-03-26

読むべき人：
  • プロプログラマーの人
  • プログラミングはやらない管理職の人
  • 奥義書を読んで修行したい人
Amazon.co.jpで『スティーブ・マコネル』の他の本を見る

bana1 プログラミング奥義書クリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 11:41│コメント(7) 


January 24, 2014

実践ソフトウェアエンジニアリング

実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識-
実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識- [単行本]
キーワード：
　ロジャーS.プレスマン、ソフトウェア工学、教科書、SE、必読書
ソフトウェアエンジニアリングの世界的権威による、ソフトウェアエンジニアリングについて網羅的に示されている教科書。

目次は内容が多くて、ググっても出版社のページにも詳細なものが全然出てこない・・・。技術書の目次は特に重要な部分なので、仕方なく部、章、節のレベルまでをすべて自分で2時間近くもかかって打ち込んだ・・・（Amazonなどネット書店はともかく、せめて出版社は詳細な目次をすべて示すべきだ。それで買うかどうかの大きな判断基準になるのに、目次が示されていないのは大きな機会損失になっているはず）。目次をみると分かるように全5部構成の32章となる。かなりソフトソフトウェアエンジニアリングの内容について網羅的にカバーされているのが分かると思う。ページ数は649ページと分厚く、値段も税込で7,980円と技術本でもかなり高額の部類。それでも、すべてのソフトウェアエンジニアリングに関わる人は絶対買って読むべき!!な1冊。

著者はソフトウェアエンジニアリング分野のコンサルティングと教育の企業の社長もやっているが、本業は大学教授である。初版が30年ほど前に出版され、時代の技術トレンドなどを反映して改定を重ね、本書の第6版が2005年に出版されている。

本書はソフトウェアエンジニアリングを学ぶ学部3〜4年生、もしくは大学院1年生のための総合的な入門書であることを意図している。また、学生だけではなく、実際にソフトウェア開発に関わる現役の技術者にも使えるような内容となっている。

僕は一応大学ではソフトウェア工学を学部4年だけだけど、割としっかり学んだほうで、そのままSEになった。大学で学んだことがすごく役に立っているなと実感する一方、実際に仕事でシステムの品質、プロジェクトベースでの仕事の進め方、設計、テスト方法などは大学で学んだことだけではどうしても足りないなと思った。要は大学で学ぶことは座学がどうしてもメインになりがちで、最低限知っているけど、自分がそれを使いこなすまでの知識の深さと網羅性が足りないと思った。

そのギャップを埋める助けになるのが本書。確かに一見教科書的な内容と体裁なのだけど、かなり仕事などでソフトウェアの作成、システム開発のプロジェクトで必要、意識しなくてはいけない、気を付けるべきことなどが実践的に示されている。例えば『プラクティス―一般的な考え方』の「5.3プラクティス」で以下のように示されている。
  • 原則1:プロジェクトのスコープを理解する．
  • 原則2:計画活動に顧客を参加させる．
  • 原則3:計画は反復的であることを認識する．
  • 原則4:わかっていることから見積もる．
  • 原則5:計画するにあたってリスクを考慮する．
  • 原則6:現実的であれ．
  • 原則7:計画するにあたって粒度を調整する．
  • 原則8:どのように品質を保証するかを決める．
  • 原則9:どのように変更に対応するかを決める．
  • 原則10:頻繁に計画を追跡し、必要に応じて調整する．
    (pp.80-81)
こんなのはまず大学の講義では学ばないし、たとえ産学連携のプロジェクトをやっていたとしても、こういうのはまず教えてはくれないだろう。実際に仕事をするうえでも、ヒントになる部分、勉強になる部分がかなりある。

本書は32章、650ページもあり、大型本でもあるので読み進めるのが割と大変。僕は2011年にこれを技術力の根本からの強化を目指して、アマぞったのだけど、実際に読み始めたのは2012年で、仕事が忙しかったり他の本を読んでいたりして結局その年には読み終われず、2013年は全く読まず、最近有給で時間ができたので残りのページを読了した。

理想は1日1章のペースで読み進めるのがよいのだけど、さすがに日々の仕事などでそれも難しいかもしれない。なので現実的には3ヵ月から半年の期間で読了することを推奨。逆にそれ以上時間をかけすぎると、内容がすっかり忘れてしまって学習効率が落ちる。しかし、別に全部通読しなくては理解できない構成とはなっていない。全部読むことを推奨するが、日々の業務で特に必要そうな部分を重点的に読んでいくというのもよい。

また、一つプロジェクトが終わって、自分が関わったフェースの反省として該当箇所を読み込むのもよいし、次に始まるプロジェクトで必要そうな技術を予習しておく使い方もよい。

対象読者は学部3年生からとなっているけど、これを学部生で読んでも実践経験が少ないのでちょっとピンとこない部分があるかもしれない。それでも余裕があれ読んでおこう。また、新人SE、特に文系卒だったり理系だけどソフトウェア工学全般を学んできていない人は、遅くとも3年目以内にこれを読了することを推奨する。他にもソフトウェア開発の流れに沿った入門書などが出ており、それをきっかけにソフトウェアエンジニアリングを学び始めるのもよいが、それらだけではどう考えても足りない。いろいろその分野の本をそれなりに読んできたが、網羅性と内容に関してはこれが断然よい。

また、システムエンジニア、プログラマーのどの職位の人でも必ず役に立つ内容と思われる。新人のテスターの場合は、何を意識してテストをすればよいか分かるし、プログラマーであれば、コーディング時に気をつけなくてはいけないことが役に立つし、基本設計から詳細設計をする人も、より上流のプロマネ的な立場にある人も必ず役に立つ内容が示されている。

さらに、SIer的な立場にある人だけではなく、Web系の人にも役立つ内容が示されている。特に第3部がまるまるWebエンジニアリングの内容となっており、アジャイル的な内容も示されているので、そこだけでも読む価値あり。

網羅的な内容となっている反面、それぞれのトピックに対する深さはどうしても足りない。そんなときは各章ごとに論文、有益な本などが示されているので、より詳細に学びたい場合はそちらをあたるのがよい。

ソフトウェア工学、ソフトウェアエンジニアリングを理解せずにシステム開発、ソフトウェア開発を実践することほど不毛なことはない。一見それらを体系的に学ばなくてもうまくいっているようには見える。しかし、顧客の要求がよく分からず、スケジュールは遅れ気味になり、それをカバーするためにデスマ的な働き方をせざるを得ず、実際に出来上がったと思われるシステムはバグだらけで品質に問題があり、しかも顧客の求めていた内容とは違っていた!!なんてことは割とよくある話である。

ソフトウェア、システム開発プロジェクトで生産性が常に高く、スケジュールも遅れなく、バグが全くないような特効薬、つまり『銀の弾丸』は存在しないとしても、それらの仕事に関わる一人ひとりがソフトウェアエンジニアリングをしっかり身につけ、少しでもよりよいものを作れるようになるべきだと強く思う。

最後に第1章に示されているソフトウェアエンジニアリングを学ぶ意義が示されているところを引用しておこう。
　ソフトウェアが重要になるにつれて，素早く，安く，高品質なプログラムを簡単に作成・保守できるような技術も次から次へと生み出されている．Webアプリケーション開発やオブジェクト指向開発，アスペクト指向プログラミング(aspect-oriented programming)のような特定の領域の技術もあれば，Linuxのように多くの領域で活用される技術までさまざまである．われわれソフトウェア開発者は，実現までの時間がかかるかもしれないが，最高の技術を生み出すべく努力を続けなくてはならない．人々は今のところ，仕事を，最適さを，安全を，息抜きを，意思決定を，いやまさに生活そのものをソフトウェアに委ねるという賭けを行っているにすぎないのだ．分の悪い賭けではないことを祈ろう．
　本書は，ソフトウェアを開発する際に駆使すべき技術―ソフトウェアエンジニアリング―の概要について解説している．技術論だけでなく，仕事の進め方（プロセス）も扱う．人々が賭けに勝つために，われわれソフトウェア開発者はソフトウェアエンジニアリングをきちんと修得しなければならないのだ．
(pp.1)
すべてのソフトウェア開発に関わる人はぜひこれを買って読もう。投資した分だけ、必ず勉強になるし、将来的に大きなリターンとなるはず。

少なくともプログラマー、SEとして第一線で活躍していきたいなら、これは絶対買って読め!!!!


実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識-
実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識- [単行本]
ロジャーS.プレスマン
日科技連出版社
2005-02-08

読むべき人：
  • ソフトウェア工学を学んでいる学生
  • ソフトウェアエンジニアリングを学んだことがない人
  • ソフトウェア開発に関わるすべての人
Amazon.co.jpで『ソフトウェアエンジニアリング』の他の本を見る

bana1 ソフトウェアエンジニアリングクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 18:59│コメント(0)│トラックバック(0) 


January 20, 2013

プログラマーのジレンマ 夢と現実の狭間

プログラマーのジレンマ 夢と現実の狭間
プログラマーのジレンマ 夢と現実の狭間

キーワード：
　スコット・ローゼンバーグ、ソフトウェア、工学、プロジェクト、失敗
ソフトウェア開発プロジェクトの失敗記録が示されている本。以下のような目次となっている。
  1. 第0章 ソフトウエア時間
  2. 第1章 絶望
  3. 第2章 アジェンダの魂
  4. 第3章 プロトタイプとパイソン
  5. 第4章 レゴの国
  6. 第5章 犬とギークの扱い方
  7. 第6章 デザインへのこだわり
  8. 第7章 プログラマーとデザイナー
  9. 第8章 ホワイトボードと付箋]
  10. 第9章 開発手法をめぐる旅
  11. 第10章 エンジニアとアーティスト
  12. 第11章 ドッグフードへの道
  13. エピローグ 未来への掛け
(目次から抜粋)
本書は、チャンドラーというクロスプラットフォームで、オープンソースで、ピアツーピアの個人情報管理ツールで電子メールとカレンダー機能に重点を置いたソフトウェア開発記録を第3者の視点からまとめられた本となる。

チャンドラーはOASF（オープンアプリケーション財団）創立者にして元ロータスデベロップメント創立者でもある、ミッチ・ケイバーによるプロジェクトで、その開発メンバーには元マイクロソフトや初期MacOS開発者、ネットスケープ創業者のメンバーなどなど、ソフトウェア開発のエキスパートたちが集まったドリームチームという構成である。しかし、このプロジェクトは結局には失敗に終わっている。その失敗の軌跡がオンラインマガジン『サロン』の共同創設者によってウォッチされて、まとめられたものが本書となる。

ちなみに、Chandlerは以下からダウンロードできる。以下本書のまえがきから、概要が分かる部分を抜粋。
　つまり、この作品はプログラマーにも楽しんでもらいたいが、それと同じくらいに、あるいはそれ以上に、一般の人向けに書いたものである。本書は疑問を提示し、物語をかたる。なぜ良いソフトウェアを作ることがこれほど難しいのか。コンピュータ時代に入ってから五〇年たった二十一世紀初頭の現在でも、この問いに完璧に答えられる人はいないだろう、そこで、あるソフトウェアの開発物語を、実地調査にもとづいて書いてみることにした。これは、新旧さまざまな障害に行く手を阻まれ、役に立つもの、豊かなもの、永く続くものを作ろうともがきながら、ともにコードの巨石を動かし山の頂点をめざそうと挑んだ人びとの物語である。
(pp.3)
ミッチ・ケイバー自身はすでにある程度の金持ちであり、しかも資金調達などによってプロジェクトの資金は豊富にあった。メンバーもみなエキスパートばかり。作りたいものもある程度ははっきりわかっている。B to Bのシステム開発ではないので、デッドラインのように厳密な納期もない。しかし、思ったほど開発が進まなかったりする。ボトルネックになっている機能を実現できる人材がいなかったり、見積もりがあまかったり、プロジェクトの進め方が悪かったり、エンジニアリングの組織を作るのが予想以上に難しかったりとさまざまな要因により、プロジェクトは泥沼にはまっていく。

そうこうしているうちに、2005年ごろからAjaxを筆頭としたすべてWebのあちら側で何でも実現できるようなものが台頭してくる。PCのこちら側にダウンロードしてインストールするソフトであるチャンドラーの存在意義も危ぶまれてきてしまうという始末。

いわゆるSIなどの開発は競争入札によって受注できれば、開発したものがそのままお金になる。しかし、B to Cのようなある程度自由な感じのソフトウェア開発は、受注開発ではないので、リリースを急がなくては競合で似たようなものが出てきて商機を失ってしまうのだなぁということもよく分かった。

作っている物の違いはあれど、あるあるwと思う部分もたくさんあった。それと同時に、どんなにコンピューターシステムが発達しても、やはり人が作るものであるので、そこのマネジメントなどの部分がボトルネックになるのだなぁと思った。そして、そのどれらも終わってから対応策は練ることができるかもしれないが、現在進行形でそれらを回避する銀の弾丸は存在しない。なぜなら「典型的なソフトウェアプロジェクトなどない。プロジェクトは一つひとつ違う」のだから。

ソフトウェア工学的な内容も、過去の業界の偉人やエピソード、例えばブルックスの法則とかムーアの法則とかアラン・ケイによるオブジェクト指向の話とか、Texの開発者であるドナルド・クヌースの『ソフトウェアは難しい』と言った話も豊富で、ソフトウェアの話全般が割と分かりやすく示されていると思う。ただ、どうしてもマイSQLとかJavaスクリプトとかパール、パイソン、マックOSといった訳し方はいかがなものかと思う。いくら訳者がソフトウェア業界にそんなに詳しくないとしても、出版社がちゃんと技術者によるレビューをしてないことが丸わかりだなぁと。

これから何かスタートアップで開発をする人などはとても勉強になることが多いと思われる。そうでなくても、ソフトウェア開発がなぜこんなにも失敗ばかりであるのか?という参考事例として読んでみるのもよいかもしれない。
　現在のソフトウェアの壮大な構造物を引き裂き、新しいまったく違ったものに置き換えようと夢見る人がいる。人間の希望や行動の流れに柔軟に対応するプログラムや、言われたことだけをやって余計な邪魔をしないソフトウェアや、信頼できるコードにあこがれる人もいる。
　われわれはそんなものを夢見て、作ろうとする。そして混沌の闇に落ちる。
(pp.21)
やっぱり作るのは難しいね。


プログラマーのジレンマ 夢と現実の狭間
プログラマーのジレンマ 夢と現実の狭間
著者：スコット・ローゼンバーグ
販売元：日経BP社
(2009-05-21)
販売元：Amazon.co.jp

読むべき人：
  • ソフトウェア開発者の人
  • ソフトウェア開発がなぜ失敗するか考えたい人
  • スタートアッププロジェクトにいる人
Amazon.co.jpで『ソフトウェア』の他の本を見る

bana1 ソフトウェアクリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 15:35│コメント(3)│トラックバック(0) 


January 07, 2013

ピープルウエア 第2版

ピープルウエア 第2版 − ヤル気こそプロジェクト成功の鍵
ピープルウエア 第2版 − ヤル気こそプロジェクト成功の鍵

キーワード：
　トム・デマルコ/ティモシー・リスター、人間系、プロジェクト、管理、やる気
プロジェクトの管理面に焦点を当てたエッセイ本。以下のような目次となっている。
  1. 第1部 人材を活用する
  2. 第2部 オフィス環境と生産性
  3. 第3章 人材を揃える
  4. 第4部 生産性の高いチームを育てる
  5. 第5部 きっとそこは楽しいところ
  6. 第6部 ピープルウエアの小さな続編
(目次から抜粋)
いわゆるデマルコ本で、システム開発のプロジェクト管理者が陥りやすい脇道などがユーモアと共に示されている。そして、本書のテーマは以下のように示されている。
　人が絡む問題を、政治学と呼ぼうと、社会学と呼ぼうと、次のプロジェクトでは、人に関する問題が、設計、製造、開発技法のような技術的な問題よりもトラブルの原因になることは間違いない。だからこそ、人に関する問題をこの本を貫くテーマとしたのである。
(pp.3)
そこで、プロジェクトに関わるメンバー、管理者など人間系に焦点があてられているので、ピープルウェアとタイトルがついているようだ。システム開発、ソフトウェア開発のプロジェクトにおける人に関する問題の本質は、以下のように集約される。
ソフトウェアは、多数のチームやプロジェクト、固く結束した作業グループで開発するので、ハイテクビジネスではなく人間関係ビジネスに携わっているといえる。プロジェクトの成功は関係者の緊密な対人関係によって生まれ、失敗は疎遠な対人関係の結果である。
(pp.5)
本書の第1版が発売されたのは今から20年ほど前のことであるが、これは時代や国が変わってもあまり変わらないことだなぁと。システム開発プロジェクトの成功確率は他の業界、例えば建築などに比べてあまりにも低い。その要因の大部分は、要求されるIT技術の複雑さなどによるものではなく、プロジェクトに関わる様々なメンバーのコミュニケーションが問題であるということが、本書を読めばよく分かる。

分かりやすいのが2部の『オフィス環境と生産性』では、オフィス環境の違いによってプログラミングの生産性に違いがあるかどうか調べるプログラミングコンテストが開催され、その結果、上位のグループは静かで、個人の空間、プライバシーが保護され、電話などの無駄な割り込みがないほうが、生産性が高い傾向があるとなった。

他にも「電話についての意識改革」という節では、プログラマーには静かで割り込みが発生しない環境が不可欠なので、電話を無視してもよいような現実的で効果的な方法を考えるべきだとあった。これは実体験からもう電話出るのいやだ!!と思っていたから、あるあるwwと思って読めた。

特にカットオーバー後の障害対応要員として、自分の担当タスクをこなしつつ、電話番という状況だと、電話に出てちょっと別の対応をして、さて自分の元のタスク再開だけど、どこまでやってたんだっけ?そうそうここだ、ここからだ、と思った矢先にまた電話対応をやっていると、仕事進まないじゃないか!!となったりしたなぁ。

システム開発などは、結局人が作って、使うのもまた人であるのだから、どんなにコード自動生成が発達しても、人間同士の問題が完全に解決されるわけでもなく、そしてそれがプロジェクト成功のボトルネックになるのだなとよく分かった。なので、一部の天才プログラマーが数人でWebサービスを開発するような例外的なものを除くと、多くの人が参画するようなプロジェクトは、やはり人に対する思いやりというか、理解が必要なんだと思う。各メンバーが技術スキルを保持していることも重要だけど、やはり最後は人間を理解することがとても大切だね。

特に管理者の立場であるプロジェクトマネジャーは必読書かもしれない。プロジェクトメンバーの作業進捗を監視するようなことがマネジャーの仕事だと思っている人は特に。最後に特になるほどと思った部分を引用。
つまり、管理者の役割は、人を働かせることにあるのではなくて、人を働く気にさせることである。
(pp.41)
これはどの階級の人も心にとどめておいた方がいいね。

各エッセイはユーモアを交えて示さされていて、割と面白く読める。ある程度の経験年数のある人が読めば、必ずこれは自分もあるあるwwと実体験から納得できる内容が多い。そして、1章ごとに読むとよいかも。あまり速く読むようべきような本でもないし。ゆっくりと1日1章ぐらいのペースで読むのがいいかもね。

プロジェクトに関わる全ての人にお勧めの一冊。


ピープルウエア 第2版 − ヤル気こそプロジェクト成功の鍵
ピープルウエア 第2版 − ヤル気こそプロジェクト成功の鍵
著者：トム・デマルコ
販売元：日経BP社
(2001-11-26)
販売元：Amazon.co.jp

読むべき人：
  • マネジャーになったばかりの人
  • 環境が悪くて生産性が微妙な人
  • プロジェクトの失敗要因について考えたい人
Amazon.co.jpで『トム・デマルコ』の他の本を見る

bana1 ピープルウェアクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 22:13│コメント(2)│トラックバック(0) 


December 16, 2012

初めてのC# 第2版

初めてのC# 第2版
初めてのC# 第2版

キーワード：
　Jesse Liberty / Brian MacDonald、C#、.NET、入門書
オライリーのC#入門書。表紙の動物は金魚。目次はオライリーのホームページを参照と。この第2版が2006年発売のようで、最新の4.0などの内容は反映されていないようだ。まず、C#とはどんな言語かはWikipedia参照と。一応本書の定義では、以下のように説明されている。
C#は、C++とJavaという2大プログラミング言語をベースに作られた近代的な言語のひとつで、構造化され、コンポーネントベースのオブジェクト指向プログラミングに対するすべてのサポートを含みます。
（中略）
　C#の目標は、単純で安全な、オブジェクト指向でインターネット中心の、パフォーマンスの高い言語を、.NET開発に提供することです。C#はキーワードが比較的少ないので、単純です。そのため、学ぶことが容易で、特定の要求に適合させることが容易です。
(pp.3)
C++はやったことないし、Javaは基礎的な部分までしかやったことがないので、それらの言語のいいとこどりをしているのがC#と言っていいものかは分からない。しかし、最近仕事でC#、ASP.NETでスクラッチ開発を経験した限りで言うと、かなり使い勝手のよい言語ではないかなという印象を受けた。

C#の経験はまったくなかったが、今までの主なプログラミング言語経験は、C、PHP、VBA、VB.NET、PL/SQLがあるので、すんなり習得できた印象がある。とはいっても、本格的にオブジェクト指向言語を使ったことがないので、まだ抽象クラスとかインタフェースなどの使いどころが分かってなかったりする。それでもかなり生産性が高いのではないかなと思った。同じこと実現するために、他の言語に比べて余計なコードを書かなくてもいいような感じだし。

本書の内容に関して言及しておくと、この本から学習するべきということはないかなと思う。少なくともまったくプログラミング経験がない人がC#から始めるときに、これが適切かというと、あんまりそうとは思わない。まず、翻訳ものだから仕方がない部分もあるけど、説明が分かりにくいところがあったりする。そして、図解があまりない。何よりも、初心者がいきなり抽象クラス、インタフェース、デリゲートまですんなり理解できるとは思えなかったり。

そういう意味では、本書は他のプログラミング言語の経験があり、初めてC#を学ぶ必要があるが、あまり時間がない人向けの本かもしれない。そういう人は、すべて最初から読む必要もなく、特に知らない部分、曖昧な部分だけを読んでいけばいいと思う。時間的に余裕のある人は、最初から読みつつ、サンプルコードを全て写経するように一度実行してみるとよいかも。僕もすべてはやってないけど、一部はやってみたりした。

また、Amazonの評価を見ると、同著者の『プログラミングC# 第6版』とかなり同じ内容らしい。こっちはまだぜんぜん買ってもないので、詳細は分からないけど、時間的に余裕がある人でもっとじっくり網羅して学びたい人はこちらがよいかも。2011年発行なので、4.0の内容も網羅されているようだし。

本書は17章立てで352ページあるのだけど、読了までに半年ほどかかってしまった。もう少し集中して1ヵ月くらいで読了したかったのだけど、どうしても日々のお仕事が忙しくて読む気力がなかったり、説明が頭に入ってこないこともあったり、小説を読んだりして時間がかかり過ぎた。理想は1日1章ペースで20日以内がよいのだけど、できれば写経してサンプルプログラムも自分の手を動かしてやったほうがいいかな。そしたらもうちょっと時間がかかるかもしれない。

C#をやりたい人は、無料のVisual C# 2010 Expressをインストールすればよい。ユーザー登録しないと、30日間しか使えないけど。でも基礎的な部分を写経したりするには重宝した。あとついでにショートカット集も参考に。一応自分の専門がMS系技術領域なので、C#は必須技術かなと。今年ようやく新言語であるC#を習得し始めた。まだまだ使いこなせているとは言えないけど、使ってみるとすごくしっくりくきて、自分に合っている気がした。なので、地道にC#に限らず.NET系技術を勉強しようと思う。


初めてのC# 第2版
初めてのC# 第2版
著者：Jesse Liberty
販売元：オライリージャパン
(2006-08-01)
販売元：Amazon.co.jp

読むべき人：
  • C#を習得する必要がある人
  • .NET系の技術が好きな人
  • 金魚が好きな人
Amazon.co.jpで『C#』の他の本を見る

bana1 C#プログラミングクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 14:17│コメント(0)│トラックバック(0) 


July 22, 2012

グラス片手にデータベース設計〜販売管理システム編

グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)
グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)

キーワード：
　梅田弘之、DB、業務モデリング、販売管理システム、カクテル
販売管理システムの業務ノウハウと設計技術が解説されている本。以下のような目次となっている。
  1. Part1 業務システムの概要とマスタの設計
    1. 第1章 販売管理システムの全体像
    2. 第2章 基幹業務システム構築のポイント
    3. 第3章 部門／社員／商品マスタの設計
    4. 第4章 取引先（顧客／仕入先）マスタの設計
  2. Part2 販売システムのDB設計
    1. 第5章 受注業務のDB設計
    2. 第6章 出荷／売上業務のDB設計
    3. 第7章 請求業務のDB設計
    4. 第8章 回収業務のDB設計
  3. Part3 仕入／在庫システムのDB設計
    1. 第9章 発注／仕入業務のDB設計
    2. 第10章 入庫／倉庫移動業務のDB設計
    3. 第11章 在庫管理業務のDB設計
    4. 第12章 仕入／支払業務のDB設計
    5. 第13章 業務全般に関連する処理のDB設計
(目次から抜粋)
本書は、販売管理をテーマに業務処理ノウハウとDBシステム設計が解説されている。ここで言う、「販売管理」は、販売管理システム、在庫管理システム、調達管理システム、会計システムの枠内に入る債権管理、債務管理までを含め、単なる販売だけではなく、そのための商品の調達、在庫する仕組みや請求／支払処理までを分かりやすく解説されている。

そして本書の特徴として、教科書通りの業務知識を語るのではなく、実践的な生きた業務ノウハウを具体的なデータベース設計まで落とし込んでいる点、と示されている。

今の仕事は、別に販売管理システムが対象ではないのだけど、自分のタスクとしてデータベース設計がありえたので、予習と設計ノウハウで参考にできる部分がないかと思って読んでみた。本書はすごく分かりやすかった!!これは似たようなシステムを運用していた1，2年目のときに読みたかったなぁと思った。

本書で示されていて一番なるほどと思ったのが、『業務ノウハウ不滅の法則』というもの。これは、業務アプリケーション開発に必要な技術としてはOracleやSQL ServerなどDBの知識だったり、C#, Javaなどのプログラミング言語、その他モデリング手法、プロジェクト管理などもたくさんある。しかし、業務知識や業務システム設計についてはあまり技術として触れられていなかったことから、著者の今までの経験から業務システムのノウハウを体系的にまとめたのが本書となり、『業務ノウハウ不滅の法則』は以下のように示されている。
　次々に新技術が誕生しては消えていくIT業界ですが、プラットフォームがどんなに変わろうとも、業務ノウハウは変わりません。業務ノウハウは一度身に付けたら、ずっとあなたの財産になります。まさに、「業務ノウハウ不滅の法則」なのです。
(pp.25)
これはすごく納得がいった。

企業のエンタープライズシステムを構築したり業務システム構築を対象範囲としているSEが、この先生き残っていくために必須の知識、技術がこの業務知識や業務システムの設計のノウハウなのではないかなと。昨今話題のクラウドなどの新技術の台頭、人月単価の安いオフショアなどによって、今後フルスクラッチ新規開発案件が減少していく傾向にある。そのときに、単純な機械系の技術力だけでは勝負できなくなって仕事がなくなっていくのだろうなと。もちろんハイパーな人は機械系の技術力だけでも行けるかもだけど、それはかなり少数派だろうね。

ではどこで差別化を図るかというと、著者も示しているようにやはりお客様の業務知識をしっかり分かっているという部分だね。業務知識が分からずに何となくこんな感じだろうと設計していくと、お客様の業務に支障が出たり、システムに業務運用ルールを合わせなくてはならなかったりと使いにくいものになってしまう。そうなっては次から受注は見込めないよねと。もちろん、ある程度高度な機械系の業務知識を持ち、技術力があることが前提ではあるが。

よって、特定の業務領域、例えば、生産管理だったり物流管理だったり、金融系、会計系だったりいろいろな業務に特化していくのが一つの生き残り戦略なのかなと。どれだけ技術革新が起こっても、お客様の業務の流れや基礎的な知識、商習慣だけはそんなに変わらないのだから、そこのかゆいところに手が届かせられるシステム設計ができる技術者が生き残っていくのだろう。

業務知識の話はこれくらいにして、本書に話を戻すと、一ヶ所とても参考になった部分があったので、そこを引用。
　業務系のテーブル設計で最も大切なことは、テーブルの正規化技術やRDBMSの知識だけではありません。まず、いろいろな業務形態があることを理解し、次にそれを自分なりにきちんと整理して、「今回のユーザーの場合はどうすれば一番良いか」を柔軟に考える力です。ここで書いた設計モデルはあくまでも一例なので、どうか自分の頭で考えて良い設計をしてあげてください。
(pp.160)
これは肝に銘じておこう。

本書は本当に分かりやすい本だった。そもそもあまり会計や販売管理の業務についてまとめられた本が少なく、あっても分かりにくかったり文章が微妙で全然頭に入ってこないということがある。しかし、これはとても読みやすく、すんなり理解できる。もちろん今までの自分の経験値があるという部分も考慮しなくてはならないが、それを差し引いても読みやすかった。

DB設計をやる人だけが読むのにはあまりにももったいない本で、実際にDB設計をやらなくても、販売管理の一般的な業務知識を勉強する場合にもとても重宝する。その場合は、業務知識を理解しつつ、データの流れと格納方法がなんとなくこうなっているのだなぁという理解でもよいと思う。実際に販売管理システムでDB設計をするときにまた読み返して理解すればよいので。

また、販売管理、会計的な業務用語集もちゃんと巻末に載っているのがよい。あと同著者の本として以下がある。こちらも分かりやすい。

タイトルに『グラス片手』にとあるように各章の最後に著者が飲んだカクテルのレシピが載っているのが個人的にポイントが高い。自分もBar巡りが好きなので。ちなみに、各章で示されているカクテルは以下のもの。
  1. Kiss in the dark
  2. Daiquiri
  3. FROZEN GIN & LIME
  4. MIMOZA
  5. Nikolaschka
  6. Gibson
  7. Long Island Iced Tea
  8. Pina Colada
  9. Campari & Soda
  10. Bacardi
  11. DITA TONIC
  12. White Lady
  13. Kiss of Fire
この中で飲んだことあるのは、2, 7, 9, 12くらいかな。ということで、ついでだから本書片手にKiss of Fireを飲んでみたw

DSC_1478

この前行ったときに常連になろうと思ったBarのメニューにちゃんとKiss of FireとWhite Ladyが載っていた。ソルトではなくグラニュー糖でスノースタイルになっているカクテルは初めて飲んだ。最後のほうはその名の通り熱く燃えるような感覚だったね。そしておいしかった。本書は本当におすすめの業務知識系の本。ただ唯一の欠点は、毎朝の通勤時間に読んでいると、朝から無性にBarに行って飲みたくなることだ(笑)。


グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)
グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)
著者：梅田 弘之
販売元：翔泳社
(2003-11-19)
販売元：Amazon.co.jp

読むべき人：
  • 販売管理の業務知識を勉強したい人
  • DB設計のパターンを増やしたい人
  • カクテルが好きな人
Amazon.co.jpで『データベース設計』の他の本を見る

bana1 かんぱいクリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 12:37│コメント(0)│トラックバック(0) 


July 08, 2012

はじめての設計をやり抜くための本

はじめての設計をやり抜くための本 概念モデリングからアプリケーション、データベース、アーキテクチャの設計まで (エンジニア道場)
はじめての設計をやり抜くための本 概念モデリングからアプリケーション、データベース、アーキテクチャの設計まで (エンジニア道場)

キーワード：
　吉原庄三郎、設計、品質、アーキテクト、コミュニケーション
IT業界に何らかのかたちでかかわり、はじめて設計をする人のための本。以下のような目次となっている。
  1. 第1章　はじめての設計をやり抜くために
  2. 第2章　設計の目的
  3. 第3章　外部設計の手法
  4. 第4章　内部設計の手法
  5. 第5章　アーキテクチャの目的
  6. 第6章　アーキテクチャ設計のアプローチ
  7. 第7章　本当に設計は必要か
(目次から抜粋)
5月から新しいプロジェクトに参画しており、そこでの自分のロールは基本設計からテストまでということになった。さて、設計をきっちりやったことがない、どうしようと思って本書を本屋で探し当てた。探し当てたというか、数年前からタイトルからいつか読もうと思っていたので、このタイミングで買って読んだ。

対象読者は、SI企業に所属しながらシステム開発業に関わる人で、プログラミングはやってきたけど、設計は未経験だったり、見よう見まねでやってきたけど基礎からもう1回勉強し直したい人に向けで、設計の基本的な手法を知りたい人のための本と書かれている。まさに今の自分にぴったり。

本書によれば、設計をやり抜くために最低限必要なことは以下の3つらしい。
  1. 設計の目的を正確に把握すること
  2. 設計を行うために最低限必要なテクニックを知ること
  3. 周りにいる人と正常なコミュニケーションをとること
設計スキルを上達させるには、誰かのために設計するという視点を持つことらしい。自分が作成した設計書を誰かが読んで正しくプログラミングできるようにする必要があるので、曖昧な表現ではダメで、そのため、設計という作業はコミュニケーションと示されている。

また、本書では設計を行うために必要な知識として次の4つを重点的に取り上げられている。
  • ユースケース
  • 概念モデル
  • データベース設計
  • アーキテクチャ設計
そして、本書によると設計の目的は以下のように示されている。
  1. 要件定義の内容をシステムでどのように実現するかを検討する
  2. 要件定義で明確になっていない外部仕様を検討する
  3. 開発の関係者間で情報を共有する
  4. システムの品質を高める
  5. メンテナンスのために設計情報を残す
    (pp.056)
ここが一番重要なところだね。

本書全体の構成に関して言及しておくと、割と設計工程に関して網羅的に示されている分、要素要素に深さがどうしても足りないと感じる部分がある。それはそれで本書のコンセプト上、しょうがない部分なので、例えばDB設計に関してもっと詳しく知りたい人は他の専門書を読むとよい。

全体の網羅性をある程度の抽象度を保って説明されている分、もう少し具体的な設計成果物のサンプルがあれば分かりやすかったかなと思った。例えば、Web上の購買システムをサンプルとして画面設計、DB設計、IF設計、画面プログラム設計、ビジネスプログラム設計などの一貫性を保った具体的な成果物を示してもらった方がよかったかもしれない。

しかし、設計のポイントの網羅性を示している本はあんまり本屋にもないので、本書が重宝すると思う。いろいろと参考文献も示されているし、アジャイル開発の設計に関することもコラムで言及されているので、読み物としても参考になる部分が多い。

ページ数が327ページと割とボリュームが多いので、少しずつ読んで読了まで2週間という工数かな。既知の部分や技術要素のところで自分の業務に関連が薄い部分は読み飛ばすなどすればもう少し速く読めるかもしれない。大切なのは設計の全体像をさくっと把握することなので、詳細は実際の仕事の現場で習得する、もしくはさらに専門書を読んだりする必要がある。

最近基本設計からの仕事をやっているけど、これはこれでいろいろと仕様や要件を考慮しなくてはいけない部分が多くて、なかなかすんなり仕様が固まらなかったりする。それでも単純なプログラミング工程とはちょっと違った面白さがあるなぁと思う。もちろん、プログラミングそのものも設計の1工程と捉える考えもあるけど、純粋なウォーターフォールモデルでは別物と考えるとね。

設計をやっていると自分がシステムを作っているんだという気になってくる。自分の設計のよしあしがそのままシステム品質につながると思うと、微妙な設計ではダメだなと。特に技術者の都合、例えば、その機能を盛り込むとテストが激しく面倒といったことで仕様を決めてしまいがちになったりするけど、大切なのは限られた工数や予算の中でちゃんとお客様の要件を満たすものを考慮するということだね。そういう部分で最適解を導き出すために試行錯誤するのが設計工程の面白みでもあるのかなと思った。

設計と言っても技術的なことを知らなくてはまともにできないし、プログラミングだってある程度できないとまともなものはできないなぁと思う。だからプログラミングをやったことがない人がいきなり設計をやるのは無謀というか、欠陥があったり品質が低いシステムになる可能性が高い。なので、ちゃんと技術の勉強もしつつ設計能力を磨かないとなぁと思った。

そういうことをいろいろと考えていると、熟練したエンジニアになるには最低でも10年オーダーの修行が必要なのかなと思ったり。先は長い。精進あるのみ。


はじめての設計をやり抜くための本 概念モデリングからアプリケーション、データベース、アーキテクチャの設計まで (エンジニア道場)
はじめての設計をやり抜くための本 概念モデリングからアプリケーション、データベース、アーキテクチャの設計まで (エンジニア道場)
著者：吉原 庄三郎
販売元：翔泳社
(2008-12-11)
販売元：Amazon.co.jp

読むべき人：
  • はじめて設計をする人
  • 設計書の成果物がイメージできない人
  • アーキテクトになりたい人
Amazon.co.jpで『設計』の他の本を見る

bana1 デザインクリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 11:07│コメント(0)│トラックバック(0) 


June 03, 2012

ASP.NET の絵本

ASP.NET の絵本
ASP.NET の絵本

キーワード：
　株（アンク）、ASP.NET、VB、C#、入門書
技術書の絵本シリーズの一つ、ASP.NETの概要が分かる本。以下のような目次となっている。
  1. ASP.NETをはじめる前に
    第1章　 ASP.NET
    第2章　 Webアプリを作る
    第3章　 Webアプリの性質
    第4章　 サーバーコントロール
    第5章　 Webアプリを詳しく学ぶ
    第6章　 Webアプリを配置する
    第7章　 データベースの利用
    第8章　 データベースへのアクセス
(目次から抜粋)
最近になって5つ目のプロジェクトにアサインされて、使用する開発環境がASP.NETで、まったく触れたことのない技術なので本書を読んでみた。選定のポイントは、大型書店の技術書コーナーで、ASP.NETが置いてあるところに行き、なるべくページ数が少なくかつイラストが豊富で分かりやすいものだった。本書はその要件を満たしてくれた。

もともとASP.NETの技術本があまりない感じだったので、ページ数が少なめのもので他の購入候補として考えたのは、10日でおぼえるシリーズ。こちらもよさそうだったのだけど、1週間くらいで読める分量がよかったので、絵本のほうを選択。

なぜページ数が少ないものを選ぶ必要があったかというと、スケジュールにあまり余裕がなく、すぐにパフォーマンスを発揮する必要があり、数ヶ月かけて悠長に勉強していられない状況にあったから。そのため、まずは全体像をさくっと把握する必要があり、細かいところは実際に仕事中に調べながらやるか、概要把握後に詳細な解説が載っているより専門的なものを読めばいい。

しかし、基本中の基本が分かっていないと、詳しい本もなかなかすんなり読み進められなかったり、仕事中でも必要以上にこれはなんだ?と調べたり考えたり人に聞いて工数がかかったりする。そういう無駄な工数を極力減らすために、分かりやすくてすぐに全体像を把握できるものを読んでおいたほうがいい。時間があるときはいきなりもっと分厚いのから読めばいいのだけどね。

さて、ASP.NETについて簡単に説明すると、Microsoft社が提供しているWebアプリケーションフレームワーク、サーバーサイド技術で統合開発環境Visual Studioで開発する。使用できる言語は主にVB.NET、C#となる。あと、もっと突っ込んだ概要が知りたい人は以下を参照。というか、未読なので自分自身のためのメモリンクかな。来週中くらいまでに全部一通り目を通しておこう。

本書の内容について言及すると、概要が分かる入門書なので、そんなにWebアプリケーションが詳しくない人でもイラストがあったり、1ページ当たりの文字数が少ないので分かりやすい内容となっている。サンプルコードは基本的にVB.NETで示されているが、同じ機能をC#で示されているものもいくつかある。仕事ではC#を使うので、これは結構よかった。

Web系の技術領域は、大学生の時にPHP+MySQLのWebアプリケーションをちょっと作っていたので、最低限は分かる。なので、MS系技術特有の本当に自分の知らない部分のみを読めばいいのだけど、一応基礎からやり直すことを目的としてちゃんと全文目を通した。ページ数は189ページと他の本よりも少ないが、全文理解しながら読むと5時間くらいはかかるかな。本当に知らない部分のみ読めばもっと短時間で概要を把握できると思う。

仕事とは関係なく、個人的に独習してWebアプリを作ろう!と思っていきなりC#とかASP.NETを選択する人はあんまりいないかな。たいていは導入しやすいPHPとかRubyとかだろうけど。個人的にはMSの.NET系はエンタープライズ系の仕事をやる人しか関わらないような印象。大学の情報系の講義などでもまず取り上げられないだろうし。なので、仕事で必要になったら本書のような本から読めばよいと思う。ネット上でもあんまりまとまった記事がなさそうだし。

あと、レンタルサーバでASP.NET対応のところってちゃんとあるんだね。技術力がついたら何かここで作るというのもアリかな。まだ作りたいものが特にないけど。

絵本シリーズは読んだことがなかったけど、これからはやったことのない技術を学習し始める場合、最初に読むことにしよう。


ASP.NET の絵本
ASP.NET の絵本
著者：アンク
販売元：翔泳社
(2010-02-27)
販売元：Amazon.co.jp

読むべき人：
  • ASP.NETの概要を知りたい人
  • MS系のWeb技術の基本を学習したい人
  • 技術系絵本が好きな人
Amazon.co.jpで『ASP.NET』の他の本を見る

bana1 ASP.NETクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 19:43│コメント(0)│トラックバック(0) 


February 19, 2012

44のアンチパターンに学ぶDBシステム

44のアンチパターンに学ぶDBシステム (DB Magazine SELECTION)
44のアンチパターンに学ぶDBシステム (DB Magazine SELECTION)

キーワード：
　小田圭二、DB、アンチパターン、Oracle、大罪
Oracleの中の人によって、DBのアンチパターン集が示されている本。記事末尾に44のアンチパターンを全て列挙するので、今回は目次を割愛。

本書はDBマガジンで連載されていた記事が本になったもので、プロジェクトの現場で苦労している部分、症状は似たものであることから、その失敗事例、落とし穴の例をキリスト教の7つの大罪（拙速、無関心、狭量、無精、強欲、無知、傲慢）になぞらえてDBでのアンチパターンとして44個まとめられたものとなる。「アンチパターン」の説明はWikipediaによると『ある問題に対する、不適切な解決策を分類したものである』とある。そこから、本書ではユニークなパターンタイトルが付けられ、各アンチパターンに以下のような構造で内容の説明が示されている。
  • 説明
  • 挿話証拠
  • 頻出スケール（どこで見られるか）
  • 再構想解
  • 背景
  • 一般形式
  • 症状と結果
  • 典型的な原因
  • 例外的なケース
  • 再構想による解決
  • トラブルから学ぶアーキテクチャ
現在データベーススペシャリスト試験の勉強をしていたり、実際の仕事でAccessを利用したDBシステムのリファクタリングなどをやっていて、あまりよろしくないDBをどう改善するか?のヒントにならないかと思って読んでみた。大きめの書店のDBコーナーに行っても、分厚すぎず分かりやすくDBの改善についての全体像が把握できる本がほとんどない中、この本は結構役に立った。

著者はOracleのエンジニアであることから、DBシステムが使われたさまざまなプロジェクトを経験されてきている。その経験的なものなどが一般化されていてとても分かりやすかった。

例えば、アンチパターン2『大河ドラマ「SQL」』では、パズルのような長すぎるSQL文が使われていて、性能が悪すぎたり、SQL文の解析処理に時間がかかるということがあったりする。そういう場合は、きちんとひも解いてSQLを書き直し、テストすることが得策と示されている。まぁ、理想はそうだよね、でも時間も工数も人員もないよねって思ったりもww

他には大規模DBシステムの典型的なものとしては、アンチパターン5『OLTPなのにSQLが重い』っていうのとか。OLTPはオンライントランザクション処理のことで、予約システムや物販システムに利用されているもの。顧客との契約にレスポンス5秒以内ね!!ってところに10秒待っても画面が固まったままなのだけど・・・っていう場合にはこれに当てはまる。その原因と解決策も簡単に示されている。

機械系だけではなくマネジメント的な人間系のアンチパターンもあって、かなり網羅されている印象。DBシステムのメンテナンス、運用要員になった場合、DBシステムの肝、気をつけなくてはいけないところ、パフォーマンスのボトルネックになっている部分ってなんだろう?というようなことを一通り把握するにはかなり優れている。さらに、Oracleをベースとしてアーキテクチャの説明もあってよい。

ただ、どうしても網羅性に主眼が置かれている作りのため、実際のパフォーマンスチューニングは具体的にどうやるんだ?といった部分などについては若干物足りなさもある。そこらへんは別の書籍をあたるか、現場のデキるDBスペシャリストな人に教わるしかないかなと。

ITシステムにおいて、データベースが使われていないものはほとんどと言ってないほどなので、データベースに詳しくなっておきたいと思っていた。そのため、本書で「開発者側DBAにお勧めのスキル」というものが載っていたので、参考になった。一言でDBと言っても、データモデリングなど上流部分から、パフォーマンチューニング、SQLコーディングと行った運用、下流部分までとさまざまなだなぁと思った。

最後に、本書で示されている44のアンチパターンのタイトルを以下にすべて示しておく。
  1. ねずみ算
  2. 大河ドラマ「大作SQL」
  3. バケツ RDBMS
  4. 太っちょ（多くの列を持つ表）
  5. OLTPなのにSQLが重い
  6. DATE型の意識統一不足（時分秒など）
  7. データの保持期間を決めていない
  8. 不適切なリトライの仕組み
  9. バッチにおいて適切に処理を分割していない
  10. バッチがリラン（再実行）できない
  11. 再利用しない（コネクションなど）
  12. バインド変数を使っていないSQL
  13. 組み合わせ爆発
  14. 臭い物に蓋をすると、もっと臭くなる
  15. データの量の暴力
  16. 過ぎたるはなお及ばざるがごとし
  17. データの分身の術……どれが本物？
  18. DB連携地獄
  19. サーバー移行やバージョンアップでSQLのテスト軽視
  20. トランザクションスコープが不適切
  21. なんでもかんでもリアルタイム集計
  22. 詰まると接続が増えるアーキテクチャ
  23. 引きずられるアーキテクチャ
  24. 無関心（エラーが起こるまで異常に気がつかない）
  25. タイタニックシンドローム（絶対に沈まないと思って緊急時の備えを怠る）
  26. 自分で自分を診察する（自分を冷静に判断することはできない）
  27. 不法占拠
  28. 掃除しない部屋
  29. 振り返れば相手はいない
  30. 足元おろそか
  31. リソースのバランスが悪い
  32. 気がついたらテストの時間がない（もしくはテストをしない）
  33. 目標なきチューニング
  34. 完璧な初期DBサイズ見積もりと実際のデータ量の差が生む悲劇
  35. 性能に関するアプローチがない
  36. DBに格納されているテストデータ量が少ない／種類が少ない
  37. 見て見ぬふり
  38. 重すぎる高価な鎧（よろい）
  39. 度を越した楽観
  40. 心配屋
  41. 自社に合ったDBAのあるべき姿が分からない／DB担当の要員アサインが悪い
  42. DBAが育たない
  43. セキュリティ権限設定とDB運用のミスマッチ
  44. DBチームのリーダー／担当者の権限が弱い
DBシステムのプロジェクトに関わったことのある人は、必ずどれか一つはあるあるwwwってなること確実!!

今年は更新頻度を上げると宣言していたはいいけど、2月はあまり更新できておらず。読んでいる本が分厚すぎたり、仕事が若干忙しくなってきたこともあったり、DBスペシャリスト試験の勉強を最優先にしていることもあって、4月半ばまでは更新頻度がかなり下がるかも。なので、気長にお待ちを〜。


44のアンチパターンに学ぶDBシステム (DB Magazine SELECTION)
44のアンチパターンに学ぶDBシステム (DB Magazine SELECTION)
著者：小田 圭二
販売元：翔泳社
(2009-11-28)
販売元：Amazon.co.jp

読むべき人：
  • DBシステムのプロジェクト要員の人
  • DBシステムのリファクタが必要な人
  • DBを極めたい人
Amazon.co.jpで『データベース』の他の本を見る

bana1 DBアンチパターンクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 14:17│コメント(0)│トラックバック(0) 


December 18, 2011

Being Geek

Being Geek ―ギークであり続けるためのキャリア戦略
Being Geek ―ギークであり続けるためのキャリア戦略

キーワード：
　Michael Lopp、ギーク、キャリア論、マネジメント、ナード
シリコンバレーで働くエンジニア兼マネージャによるギークのキャリア論。目次はちょっとすべて紹介しきれないので、本家オライリーのページを参考に。ついでに本書の概要も上記リンク先で見れるので、気になる人は目を通しておいたらよいと思う。こういうところがしっかりしているのがオライリーのHPのよいところで。

全体的に網羅して示せないので、例によって自分の気になった部分、考えさせられた部分を恣意的に取り上げておく。

本書を読み進めながら、常に以下のことを問い続けるとよいと示されている。
  • 自分は今、何をしているか?
  • 自分はこれから何をしていくべきか?
  • 自分にとって何が重要か?　最も考えるべきことは何か?
(pp.7)

これがギークのみならずマネージャになるような人にも考えておくべきこととなる。

ということで、いきなり35章の『就職先の選択』の『決断』から以下抜粋。
　将来について、確実に1つ言えるのは、「どういうことがいつ起きるかは、まったく予測ができない」ということである。チャンスというのは、得てして最悪のタイミングで訪れるものだ。そして、チャンスが訪れた時には、自分にその準備がある否かに関係なく、ともかく即座に何かしらの決断を下さなくてはならない。「この誘いを受けて転職するべきか」といったことを決断しなくてはならないのだ。
　自分が一体、何を望んでいるか、それをよく知っていれば、良い決断ができるに違いない。
　自分の将来について戦略を立てる際には、次に示す3つのことを自分に問いかけるべきだろう。どれも、就職、転職に関わる問いである。この問いの答えを考えることで、自分はどこへ行きたいのか、何が作りたいのか、また、それをどうやって作りたいのかが明確になるだろう。
(pp.290)
著者なりの考えが示されているのだけど、3つの問いを自分なりに考えてみたので、示しておく。

問1：ベンチャー企業か大企業か
このテーマについて論述された記事ははてブのホットエントリに入りがちで、いろいろと読んだことや考えたことがある人は多いと思う。ベンチャーだと成長しやすいとか、いろんな経験ができるとか一般的に言われているが、実際はそうじゃないという記事も見かけた。

現状では自分は大企業に属するほうで、かつ新卒でそこに入ってから一度も転職していないし、まわりにベンチャーで働いている人が身近にいるわけではないので、ベンチャーの可能性についてはあまり示しようがない。でもどっちがよいのかはケースバイケースなのだと結論付けておく。

それぞれのメリット、デメリットがある中、結局エンジニアとして一番よいのが、待遇とか将来性はあまり考慮せずに楽しく自分のやりたいことができるかどうか?に尽きるのではないかと思う。大企業もベンチャーも現在の経済状況では先が読めなくなってきていると思うので将来性は未知数だね。経験できることと言っても、一概にベンチャー、大企業というくくりでは何とも言えないし、組織のカルチャーによるとしか言いようがない。思った通りのキャリアを描けるわけではないし、半分は運みたいなものにも左右されるなというのが現在6年目の感覚的な理解。

将来は今の組織でキャリアを積み上げていくというのもありだと思うし、ベンチャーに行くというのもいいなと思う。それぞれに条件を付けるならば、今の組織で行くのなら、自分のやりたいことは必ずしもできなくても、エンジニアとしてだけではなく、ビジネスマンとしての可能性の成長も得られるかどうかかな。逆に、ベンチャーで行くなら、誰かが起こしたものの下っ端として行くよりも、自分が共同経営者、もしくは創業者としてやったほうが確実に面白いだろうし、得られるものも多いだろうね。それが条件というか、求めることかなと。

過去自分が今の組織の面接時に志望動機として語ったことと、現状の指向性としても、グローバルな環境であるというのが今の組織に残り続ける理由となる。まぁ、どっちにしても結局自分が何を求めているかをもっとはっきりさせないと、この問いには自信を持って答えらないね。

問2：どの分野で働くか　会社のブランドは重要か
これは結構ベンチャーか大企業かよりも重要な問いのような気もする。現状では会社のブランドはある程度確立されているから不満はない。著者は会社のブランドが転職の可否に影響することは大いにあり得ると示している。また、インスパイア創業者である成毛眞氏も今後は学歴よりも最初に就職した会社が一つの判断基準になるというようなことを示していた。自分もそういうものを期待して今の組織に入ったというのがある。転職して次のステップアップを順調に進めるためにね。

今の組織に帰属意識があまりなく、次を見越しているのであればブランドは大事かなと思う。あと下世話な話としては合コンのときにちょっとはいいことあるかもしれないしねww(今年も何も成果ないけどね・・・('A`))

問題はブランドそのものよりも、どの分野で働くか?のほうだと思う。ここで言う分野は、著者はDB、ブラウザ、Webアプリケーション、eコマース、OSという技術領域で示している。著者はそれらを時代の最前線ととらえて、それらに関する仕事や組織を転々と渡り歩いてきたようだ。今までの自分に何ができるか?を鑑みてみると、ここが弱い。つまり、どの分野で働くか?は自分が何を作りたいか?に言い換えることができ、ここが弱いというのはまだ何が作りたいかを確定できていないということになる。

ここだけは早く決定する必要がある。今年いろいろと考えて、やはり自分のITの技術領域で仕事を続けてプロフェッショナルになろう!!と決定した。しかし、どのドメインで勝負するか?も同時に決める必要がある。ここは来年、いろいろと技術勉強をやってみて見出していきたいところ。自分の作りたいものが先にないとね、というお話。

問3：マネージャになるつもりがあるか
これは他2つよりもそこまで重要ではない問いかな。ここで言うマネージャは、プログラミングから離れてプロジェクトや人を管理、調整するような責任ある立場になるということになる。現状の組織でステップアップすれば、結果的にこの役職に就くことになる。同等のクラスとして技術特化型のポジションもあるのだが、自分はどっちを選ぶのか?ということかな。

まぁ、自分はマネジメントにはあまり向いておらず、そういうのに対する指向性は低い。どちらかというと技術領域を深めて役に立ちたいほうだなと。かといってマネジメント的なことに対して全く興味がないわけでもなく。マネージャと言えば、軍隊で言えば隊を率いるような隊長とか将校クラスだと思うので、そういう部隊を統率してプロジェクトを回してみるというのも一つの面白みではないかと思う。

これらの問いはもうちょっと深堀しておく必要がありそうだ。

あと、36章の『エンジニアとマネージャ』の『作ったもので評価されるエンジニア』という節からキャリア初期に重要なこととして、以下のものが示されている。
  • 良いものを作る。ともかく良い製品を作ること。
  • 速く作る。限られた時間の中で、できるだけ多くのものを作るようにする。
  • 誠実に話す。上の人間に、ごまかしやウソは決して言わず、真実を話す。話を信用してもらえるようになれば、結果的に、自分の作った製品を守ることにつながる。
  • 期日を守る。「できる」と言った日に確実に製品を作り上げるようにする。
  • ただし、間に合わせるために質の悪いものを作ってはならない。必ず良いものだけを作る。
    (pp.301)
これは今でも意識するし、決してキャリアの初期だけで重要なわけでもなく、何かを作るエンジニアとしてずっと成長していきたいのなら、これは常に意識しておかなければいけないことだろうね。

特に4つ目は上司にも結構言われたな。あと社長も、何でもかんでも「できる」と言ってできていないのが一番最悪で、かといって何もできませんではダメで、Can Doの精神で現状ではできないかもしれないけど、なんとかできるようにするにはどうすべきか?を考えることが重要と言っていたなぁと。これらは常に忘れないようにしておこう。

本書は344ページでかつ1ページ当たりの文章量が多めなので、そんなに速く読めず、読み始めてから3ヵ月ほどかかったかな。毎日読んでいたわけではないけど。いろんな具体的なシチュエーションが示されているので、それらについて自分なりに考えながら読むことが重要で、速く読むことが重要なわけではないタイプの本だな。

ギークと言っても突然ソースコードが出てきたりはせず、どちらかというと組織やマネジメント的な部分にも多く言及されている感じで、ITエンジニアとして働くなら一度は考えたことがあるようなことが結構示されている。かといって、すべてじっくり考える必要のあるものではないので、気になるところを読んでいけばよいと思う。

あと、翻訳が素晴らしいので、割と読みやすい。ダメな翻訳本は、原文の英文の構造がそのまま想像できるような訳だったりするが、本書はそんなことはなかった。さらには、表紙のビジネスシューズとスニーカーのコントラストが印象的で、スーツとギークの対比を暗喩しているね。現状の自分はどちらかというと、『エイリアンVSプレデター』に出てくるハイブリッドタイプのプレデリアンのごとく、スーツとギークの中間的な存在かなとww

エンジニアが自分のキャリアについて考えてみるにはよい本だね。特に今のような年末年始シーズンなどにはね。


Being Geek ―ギークであり続けるためのキャリア戦略
Being Geek ―ギークであり続けるためのキャリア戦略
著者：Michael Lopp
販売元：オライリージャパン
(2011-06-25)
販売元：Amazon.co.jp

読むべき人：
  • ギークになりたい人
  • 転職しようかと思っている人
  • ITエンジニアとして成長していきたい人
Amazon.co.jpで『オライリージャパン』の他の本を見る

bana1 ギークキャリアクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 20:16│コメント(0)│トラックバック(0) 


September 25, 2011

プログラミング作法

プログラミング作法
プログラミング作法

キーワード：
　Brian Kernighan / Rob Pike、C言語、プログラミング、型、レッスン
プログラムに対する効果的な取り組み方を提示し、質の高いコードを作成／維持するという目標を支援する目的で書かれた本。以下のような目次となっている。
  1. 第1章　スタイル
  2. 第2章　アルゴリズムとデータ構造
  3. 第3章　設計と実装
  4. 第4章　インターフェイス
  5. 第5章　デバッグ
  6. 第6章　テスト
  7. 第7章　性能
  8. 第8章　移植性
  9. 第9章　記法
(目次から抜粋)
著者の一人は、C言語の生みの親のBrian Kernighanである。プログラミング界の神みたいな人で、この人のあらゆる開発経験が元になっているのが本書である。もう一人のRob Pikeは、ベル研究所でUNIXの開発に携わっており、現在Googleに勤務しているようだ。プログラミング時に間違ったアルゴリズムでコーディングしてしまってやたらと時間を無駄にしてしまったとか、使用するデータ構造が死ぬほど複雑になったとか、5分あれば見つかるはずのバグを一日がかりで探し回ってしまったという経験は、プログラミングを始めてから仕事で使うまで誰もが経験する道かもしれない。本書ではそうならないためにかつプログラマの生産を高めるために、簡潔性、明瞭性、一般の基本原則にそって、その具体的な方法がC言語、C++、Javaなどのサンプルコードとともに示されている。

ちょっと長いけど「はじめに」からの部分を引用しておいたほうが、本書の意図がよりよくわかるので、そこを示しておこう。
　本書のアプローチはこうした基本的で互いに関連し合う原則に基づいており、これらの原則はあらゆるレベルのコンピュータ使用形態に通用する。まず簡潔性(simplicity)。これはプログラムを短く扱いやすい状態にしておくということだ。明瞭性(clarity)はプログラムを人間にもマシンにもわかりやすく書くことを表す。一般性(generality)は幅広い状況できちんと機能し、新たな状況にもうまく対応できるという意味で、自動化(automation)は自分の代わりにマシンに仕事をさせて、つまらない佐合から自分を解放することだ。本書では、アルゴリズムやデータ構造から設計、デバッグ、テスト、性能改善の話題にいたるまで、さまざまな言語を使ってコンピュータプログラミングについて解説する。これによって、個別の言語やオペレーティングシステムやプログラミングパラダイムにとらわれない、ソフトウェア工学の普遍概念を明らかにできるはずだ。

　本書は我々の経験から生まれたものだ。我々は長年にわたって数多くのソフトウェアの開発とメンテナンスに従事し、プログラミング講座で講師を務め、さまざまなタイプのプログラマと共同作業をしてきた。本書を通して、現実の問題から学んだ教訓や我々の経験から得た考えを伝えたいと思うし、技術レベルの如何を問わず、すべてプログラマが自らの能力と生産性を向上させるのに役立つ手段を提示できればと思う。
(pp.11-12)
そして、読者に唯一必要な条件として、できればCかC++かJavaでの多少のプログラミング経験とある。まぁ、一応C言語を作った人が書いているからね。サンプルプログラムはC言語がメインで、たまに正規表現の例としてPerl、AWKまで出てくる。C言語ではポインタ表記が多いので、できればポインタのポインタまで理解しているとわかりやすいかもしれない。

どの言語もやったことのない人は、本書を読む前に一度バイブル本としての『プログラミング言語C 第2版 ANSI規格準拠』を読んでおくとよいかもしれない。まったくプログラミングやったことない人は他の言語でもいいからそれなりに習得してからがよいかもしれない。

さて、肝心の内容についてであるが、これはとても勉強になった。特に一番すぐに使えるのは、第1章の「スタイル」でしょう。変数の名前の付け方、インデントはちゃんとしましょうといった基礎的なことが示されている。プログラミングを始めたころは、どうしても自分独自の癖が出てきたりして、その癖があまりよろしくない場合は、チームで開発するときにボトルネックになる。つまり、コードの保守性が低かったり、意味不明な記述になっていたり、移植性が悪かったり、典型的なのはバグだらけだったりする。

第1章を読むだけでそういうよろしくない部分を改善し、定番的な型を身に着けられる。ゴルフで言ったら、変なフォームを身に着けてしまってなかなかボールがちゃんと飛ばないけど、ちゃんとレッスンプロに教わったら変な癖が改善され、よく飛ぶというような感覚に似ている。かといって、プログラミング初心者がいきなり全てを読みこなせるような内容ではないけど。

本書の巻末に「Appendix：ルール集」として各章のルールが示されている。自分自身の勉強のためにも、1章の「スタイル」のルールを全て以下に列挙しておこう。
  • グローバルにはわかりやすい名前を、ローカルには短い名前を
  • 統一しよう
  • 関数には能動的な名前を
  • 名前は的確に
  • 構造がわかるようにインデントしよう
  • 自然な形の式を使おう
  • かっこを使ってあいまいさを解消しよう
  • 複雑な式は分割しよう
  • 明快に書こう
  • 副作用に注意
  • インデントとブレースのスタイルを統一しよう
  • 慣用句によって一貫性を確保しよう
  • 多分岐の判定にはelse-ifを使おう
  • 関数マクロはなるべく使うな
  • マクロの本体と引数はかっこに入れよう
  • マジックナンバーには名前をつけよう
  • 数値はマクロではなく定数として定義しよう
  • 整数ではなく文字定数を使おう
  • オブジェクトサイズは言語に計算させよう
  • 当たり前のことはいちいち書くな
  • 関数とグローバルデータにコメントを
  • 悪いコードにコメントをつけるな、書き直せ
  • コードと矛盾させるな
  • あくまでも明快に、混乱を招くな
(pp.335-336)

これらのルールは文脈の中で示されており、これだけを読んでも微妙なので、ぜひ本書で内容を確認してほしい。また、マクロとかC言語特有の記述もあり、すべてのプログラミング言語に該当するルールではないので、そこは読み替える必要がある。

特に自分がよくやりがちなのはコメントを多く書きすぎるということかな。学生の時からの癖で、ついつい明らかにコードを読めばわかるような部分にもコメントを書いてしまう。まぁ、基本的に今はExcel VBAで自分しかツールのメンテナンスをしていないからよいのだけど、そうはいってもどこで自分の作ったプログラムが移植されたりするかわからないので、やはり書きすぎはよろしくないので気を付けたい。

今は新人君のプログラミングレッスンをやっているので、特にこのスタイルの部分が改めて勉強になった。マジックナンバーはなるべく定数化しましょうねとか、基本中の基本であるインデントをそろえるとか最近指摘した。そういうのは、プログラミングをやり始めた時にはあまり気づかない部分かもしれないし、なまじプログラミング経験があまりないときにそういう基礎的な部分をきっちり身に着けておいたほうがよいかもしれないし。

なので、プログラミング経験にまだ乏しい人は1章だけはなんとか習得しておいたほうがよいと思う。初級レベルを脱却するなら第2章の「アルゴリズムとデータ構造」まで理解しておきたいところ。ここはソートや二分探索木などの典型的なアルゴリズムが示されている。応用情報技術者試験にもよく出てきたね。

3章以降からちょっと難易度が上がって、チームや仕事でのプログラミング経験がないとちょっと理解するのに苦労するかもしれない。実体験がないと感覚的に理解できずにふーんって感じで終わってしまうかもしれないし。自分は5，6，7章のデバッグ、テスト、性能の部分が特に勉強になった。

本書はC言語で連結リストなどを学習していた大学2年生のとき、正確な日時は2003年の6月28日（土）に大学の図書館で読んだことがあった（なんでそんなに正確にわかるかというと、ノートに読書記録をつけていたから）。その記録によると読了時間が20分となっており、当時速読訓練も兼ねていたからその読書時間となる。もちろん20分で読める程度の理解で、さっぱり記憶に残っておらず、たぶんこんなことが書いてあったとしか言えなかったと思う。

そして3年前の2008年の夏にアマぞった本書をようやく最近になって読了した。3章まで読んで積読状態になっていたのを続きからなんとか読み始めた。大体1章30〜40ページあたり平均90分ほど時間がかかった。全350ページ読了まで大体10時間ほどかな。もちろん完全に理解しているわけでもないし、ところどころ問題としてなんとかせよっていう部分はあまり考えずに飛ばしていたけど、大分理解できたと思う。昔に比べて各段に理解度が上がっている。

なんだか本書をある程度読みこなせて、まだまだプログラマとしてなんとかやっていけるのではないかという自信みたいなのがついた。最近いろいろともっとページ数が多くて辞書みたいなのをたくさん買ったので、どんどん読みこなせていけそうだなと。でもさすがに週1冊ペースで読みこなしていくのは無理かも・・・。

本書はプロプログラマとして生きていきたい人はぜひ読んだほうがよい。どんなプログラミング言語を使用していたとしても。


プログラミング作法
プログラミング作法
著者：ブライアン カーニハン
販売元：アスキー
(2000-11)
販売元：Amazon.co.jp

読むべき人：
  • プロプログラマになりたい人
  • プログラミングの書き方がいまいち微妙な人
  • プログラミング教育担当者の人
Amazon.co.jpで『プログラミング』に関する他の本を見る

bana1 プロプログラミングクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 21:13│コメント(0)│トラックバック(0) 


September 19, 2011

実践的データモデリング入門

実践的データモデリング入門 (DB magazine selection)
実践的データモデリング入門 (DB magazine selection)

キーワード：
　真野正、DB、モデリング、分析、設計
データベース設計の前工程に必要なデータモデリングの具体的な方法が基礎から示されている本。技術本は目次が重要なので、今回は省略せずにすべて示す。
  1. 第1部　基礎編
    1. 第1章　なぜモデリングを行うのか―モデリングの種類と手順―
    2. 第2章　モデリングの基本作法―モデリングの記法と読み方―
    3. 第3章　データモデルを補完するモデル―プロセスモデルとUML―
  2. 第2部　実践編
    1. 第4章　エンティティの切り出し方―トップダウンモデリング―
    2. 第5章　トップダウンでの主キーと主要属性の定義
    3. 第6章　ネーミング標準とドメイン
    4. 第7章　ボトムアップ分析（その1）
    5. 第8章　ボトムアップ分析（その2）―CRUD分析―
    6. 第9章　トップダウンモデルとボトムアップモデルの融合
    7. 第10章　RDB論理とビジネスルール
    8. 第11章　モデルパターンの活用
    9. 第12章　ツールの活用法―できること、できないこと―
    10. 第13章　モデルレビューの観点
    11. 第14章　論理モデルから物理モデルへの変換
    12. 第15章　物理実装のポイント
    13. 第16章　ビジネス環境の変換に伴うモデルへの影響
    14. 第17章　モデルの変更管理―維持管理の必要性―
(目次から抜粋)
第1部の基礎編の重要な部分を簡単にまとめておく。

まず、データモデリングとは何かというと、『利用者とシステム構築者に実業務の姿をモデル化してみせるもの』となる。そして、テーブル、インデックスなどの格納構造の設計となるデータベース設計の前工程で利用されるものとなる。

データモデルの種類として以下の3つがある。
  • 概念モデル・・・システム構築の最初に作成するモデルで、こんなシステムが作りたいといった要件を盛り込んだもの
  • 論理モデル・・・概念モデルを引き継ぎ、システムで必要とするデータ項目をすべて付加したもの
  • 物理モデル・・・リレーショナルデータベース（RDB）のテーブル1対1に対応し、CREATE TABLEなどを用いてスキーマ定義の生成が可能なもの
ここら辺は基本情報とか応用情報技術者試験のDBの分野でもよく出るね。そんでモデリングの手順が以下のように示されている。
  1. 情報戦略に基づいた概念コーポレートデータモデル（概念CDM）の作成
  2. 業務機能と概念CDMのエンティティのCRUD分析を行い、プロジェクトごとに概念プロジェクトデータモデル（概念PDM）を作成
  3. 新システムの要件を加味して、主要属性を追加し、論理プロジェクトデータモデル（論理PDM）を初期作成
  4. 論理PDMに属性（データ項目）を追加し、関係付ける
  5. テーブル、カラム名、インデックスなどのDBMS固有情報を付加して物理プロジェクトデータモデル（物理PDM）を作成
  6. 物理PDMからDBMS上に実装
さらにトップダウン分析とボトムアップ分析を両方組み合わせていくとよいらしい。

第1部の内容の残りはエンティティや属性、リレーションシップなどのモデリング記法の読み方などが示されている。

第2部からはネット書店を具体例にしてデータモデリングの方法が具体的にかつ網羅的に示されている。これが結構ボリュームがあり、他の本にはあまりないような網羅性と思われる。

微妙なデータモデリング本は、分かりにくかったり、扱う対象が微妙だったり、もう少し深く突っ込んで欲しいというものが多いが、これはかなりよかった。Amazonで評価が高かっただけはあった。まぁ、Amazonの自分の購入記録によると、買ったのは2007年で、約4年間も積読状態にしていたわけだけど（笑）。

モデリング時のポイントの例として、何でもかんでもエンティティを分割しまくるのではなく、業務や利便性を考えてエンティティを統合したままにしておくべきといったことが結構勉強になった。こういうのは具体例、本書の場合はネットショップの顧客、店舗情報、注文内容といったエンティティを見ながらでないとまったく分からないので。

著者によると、良いモデルとは以下のようなものらしい。
  • モデルを見て概略業務が分かる
  • 一度説明してもらえば業務内容を把握できる
(pp.236)

モデリングをするときは、モデリング記法を書けるだけではなく、お客さんの業務が理解できていないとダメだしね。これが会計システムであったり、物流システムであったり、販売管理システムであったりと多岐にわたる。高度にモデリングできる人は、お客さんの業務に精通していることに他ならない。

データモデリングがうまくなるには、年数をかけて習得しなければいけない部分があるのかなと思った。少なくとも仕事でモデリングしてみるという経験が必要だしね。本だけ読んでも限界がある。そして、本書はその補助になる。

結構本書に誤記があった。版が進んでいるものは修正されているようだが、読み始める前に誤記の部分を先に以下のページで確認しておくと良いかも。また、モデリング本は以下もお勧めかな。「アナリシスパターン」は本書の参考文献にも示されていた。それにしても、意外にモデリング本を読み込んでいたんだねぇ。まぁ、Oracle EBSのプロジェクトに関わっていたときだね。

自分は分析タイプなのでモデリングとかデータベース設計に向いていると思う。なので、データベースを主軸の技術領域として、今後専門性を深めていこうかなとか思ったり。ということで、来年の春にデータベーススペシャリスト試験を受験予定。応用情報技術者試験合格による午前I問題の免除の期間が合格から2年までらしいというのもあるし。

ちなみに、本書は約7日間で10時間近くかかって読了した。300ページちょいの技術本を読み込むにはこれくらい時間がかかるようだね。完全に理解していないし、基礎から網羅的に示されているので、また実際にモデリングするときくらいに再読み込みしよう。


実践的データモデリング入門 (DB magazine selection)
実践的データモデリング入門 (DB magazine selection)
著者：真野 正
販売元：翔泳社
(2003-03)
販売元：Amazon.co.jp

読むべき人：
  • 上流工程に関わっている人
  • データモデリングについて基礎から知りたい人
  • データベースを極めたい人
Amazon.co.jpで『データモデリング』の関連書籍を見る

bana1 データモデリングクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 10:02│コメント(0)│トラックバック(0) 


September 11, 2011

業務によく効くAccess 開発現場ワザ

業務によく効くAccess 開発現場ワザ (DB Magazine SELECTION)
業務によく効くAccess 開発現場ワザ (DB Magazine SELECTION)

キーワード：
　星野努、Access、フォーム、連携、設計
MSのOffice製品であるデータベース管理ソフト、Accessを業務で実用的に実装する方法が示されている。はじめにと目次は著者の以下のページを参照したほうがよい。対象読者はどちらかというと、VBAの基礎的な文法が理解できており、さらにはAccessに限らずデータベースの基本的な概念が理解できている人向けとなる。今仕事でAccessを使うことがあるので、読んでみた。

自分はDBの基礎は大学生のときに講義で受講したし、MySQLとかOracle、SQLServerなどを経て実際に触れてみて理解している。VBAに関してもExcel VBAでツールを30個近く、数万行近くはコーディングしているので問題ない。しかし、AccessのDB、もしくはAccess VBAとなるちょっと不安な部分があったので、この本が結構役に立った。

Excel VBAの場合はあまりフォームを使ったものを作ったりしないのだけど、Accessはどちらかというとフォームを使ってデータ操作することがメインで使われやすいので、そのデータの取得方法、見せ方について知っておく必要がある。本書ではフォーム、サブフォーム、さらにはフォーム上に乗せるコントロールなどにかなりページを割いて示している。

図解でキャプチャ画面もあったり、コードのサンプルも載っているのでかなり分かりやすいと思う。初心者向けすぎて冗長な説明もないのが自分には合っていてよかった。脚注にも補足説明がたくさんあるし。

業務でそのまま使えるサンプルが多く示されている。以下簡単にそれらの一部を列挙しておく。
  • 指定ユーザーのみにフォームを開かせる
  • ラベルに今日の日付を表示する
  • ボタンにロールオーバーの機能を持たせる
  • カレント行全体の背景色を変える
  • オブジェクトをメールに添付する
  • CSVファイルへの加工データのエクスポート
AccessとExcelの連携、エクスポート処理についても示されていてよかった。ここが結構知りたかった部分なので。また、Access内でVBAでExcelを直接操作する方法が示されていて参考になった。参照設定を使用するパターンとCreateObject("Excel.Application")で操作する2パターンあるようだ。これはあんまり知らなかったの勉強になった。

Excelと連携してデータエクスポートをしたり、エクスポートしたExcelファイルの書式を設定したりして整形するときに、どこまで連携して自動化するか、そしてExcel, Accessのどちら側をメインにVBAコードを書いていくかが重要かなと思った。そこが設計者の腕の見せ所だね。パフォーマンスなどを考慮して。

以下、このブログで取り上げたAccess本は以下となる。そうえいば、2年前にVBAエキスパートのAccess 2002 VBA スタンダードを取得したのだった。受験料が1万円以上もするくせにあんまり役に立たない資格だねぇww

本書は朝90分、出社前に読み、大体6日間で280ページを8時間20分ほどで読了できた。大体平日5日に90分、日曜日に120分という計算となる。なるべく今後技術本を1週間に1冊のペースで読み込んで行きたい。

あと技術本はボリュームも多いし、網羅的な内容を示せないので、結構恣意的な記事になると思う。いつものことかもしれないけど（笑）。


業務によく効くAccess 開発現場ワザ (DB Magazine SELECTION)
業務によく効くAccess 開発現場ワザ (DB Magazine SELECTION)
著者：星野 努
販売元：翔泳社
(2009-07-31)
販売元：Amazon.co.jp

読むべき人：
  • Accessを使いこなしたい人
  • AccessとExcelの連携について知りたい人
  • 仕事でAccessシステムを設計する必要がある人
Amazon.co.jpで『Access』の他の本を見る

bana1 Access VBAクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 14:49│コメント(0)│トラックバック(0) 


September 04, 2011

SEのための「どこでもやれる力」のつけ方

SEのための「どこでもやれる力」のつけ方
SEのための「どこでもやれる力」のつけ方

キーワード：
　野口和裕、SE、成長、独立、自由
自由なSEになるためにはどうするべきかが示されている本。目次よりも前書きに分かりやすい内容が示されている部分があるので、そこから一部引用。
　本書のコンセプトは、エンジニアが独立して「フリーエンジニア」としてやっていくには何が必要で、どういった心構えが大切かを解説するものです。
（中略）
　この時代を乗り切るために、私たちシステムエンジニアも力を蓄えておく必要があります。しかし、一夜にして一気に実力を上げることはできません。どうすれば、その力を身につけられるのか。何を準備する必要があるのか。―それを解説するのが本書の役目です。
(pp.3-4)
著者が示しているフリーなエンジニアというのは、必ずしも会社を辞めてフリーランスになることのみを示しているわけではない。ここでは、「自由」という意味で自由なSE、つまり自分の進む道を自分で選択するSEのなり方が全編に渡って、著者の13年の会社員時代と独立経験から示されている。

本書の構成は、新人SE時代（目安経験は2年目まで）、中堅SE時代（2年目から10年目）、ベテランSE時代（10年以上）の3部構成で示されている。そして、それぞれの期間に身につけるべきものが、4原則、3スキル、3基準として示されている。以下簡単に示しておく。

新人SE時代の目標は「社内でできるやつ」と思われるようになるで、その代表的な悩みは「仕事が面白くない!」となる。その解決策として以下の4原則が示されている。
  1. 自分のために仕事する
  2. 顧客の悩みを考える
  3. 武器を持つ
  4. 与えられたことに全力で取り組む
自分は6年目に突入しているので、さすがにもう新人ではないのだけど、改めてこの部分は参考になった。特にまだ自分の武器がないなぁという点かな。著者は右手にハードウェア、データベース、ネットワークなどの基礎的な技術を身につけろと示している。ここは大学時代からそれぞれの基礎は身につけているのだけど、いざ実践で武器となるほど深められているかというと微妙なので、もっと勉強しなければなと思う。まずは直近の仕事に関係のありそうなDB回りかな。特にテーブル設計など。

左手の武器としては新しい技術がよいとあった。例としては検索技術と示されていた。他には自分が不満に感じているもので、それを解決できる技術が次の有望な技術になると示されている。なんかあるかな?ちょっと考えてみるけど、なかなか思いつかないなぁ。

あともう1つの武器として脳を鍛えるというものがあった。ジャンルにこだわらずに多様な本を読むことが脳を鍛え、感性を磨くことに役に立つと示されている。これはある程度は十分かなと思うけど、今後も継続しよう。

感覚的な自論だが、設計能力やプログラミング時の抽象化能力は、自分の想像力の限界を超えるようなSF小説とか海外の古典文学作品を読むことによって鍛えられるのではないかと思っている。あとは、技術書とのインプットバランスが重要だね。他の本を読みすぎて、技術の勉強がおろそかになってはいけないので。

2部の中堅SE時代では、社外でもウワサになるということが目標で、そのときの悩みとして「自分の力を試す仕事がしたい!」とある。まさに自分は今ここだね。そして、解決策として以下の3つのスキルを身につけるべきと示されている。
  1. コミュニケーション力
  2. チームワーク力
  3. 育てる力
これはどれも今鍛えなければいけないものかなと思う。まさに今新入社員の教育係をやっているので、どう育て上げるか?を割りと毎日真剣に考えている状況だね。なぜなら社会人1年目の成長性でその人のキャリアが大体決まってしまうから。責任重大。

3部のベテランSE時代では、目標が独立して成功するとあり、悩みとして「自分の好きな仕事がしたい!」とある。やるべきこととして、以下の基準を考えろとある。
  1. やりたいこと
  2. できること
  3. やるべきこと
まぁ、ベテランじゃなくても常時考えたほうがいいことだね。独立するしないに関係なく。よくやりたいこと、できること、世の中で求められることの3つの円がベン図で示されるね。これがすべて一致していれば完璧なのだけど、なかなかそうは行かない。今の自分はやっとできることと会社で求められていることの積集合部分(できること(A) ∩ 求められること(B))が多くなってきたところかな。やりたいことはまだ重なっていないけど、まぁ、そこはそのうち重なるだろうと楽観的に考えている。

特に本書を読んでいてなるほどと思った部分を以下に抜粋。2部の中堅SE時代として身につけるべきスキルの育てる力に関して。以前著者は部下を育てることの意義が見出せなかったが、今では以下のように考えているとある。
　自分の育てた部下が転職し、いろいろな会社で活躍する―それは、いわば影響力が社内にとどまらず、広がっていくことを意味します。短期的には無駄のように思えたことが、長期的には各方面からの評判を呼び、あなたが社外でウワサになることにもつながるかもしれません。
　人を育てると影響力が大きくなって、自分も成長し、さらには感謝もされる―大変ですが、そこには大きな喜びがあります。
(pp.178)
プロジェクトベースの仕事の醍醐味は、自分が上司や周りの人に育てられ、そしてそれを部下に継承していき、それが連鎖していって組織、業界が成長していくことなんじゃないか?って最近思い始めた。まずは自分自身が成長しなければいけないけど、それと同時に、もう自分だけのことを考えていれば良い年次ではなくなってきたので、いかに人材育成するか?というのも考えなければいけない。

自分は人を教育するとか、ポテンシャルを発揮できるようになるにはどうするかを考えるのが好きだったりする。誰かのためになりたいという部分が少なからずあるから、こんな読書ブログをやっているくらいだしね。いつかは自分の下についたメンバーが他に行っても能力発揮しまくりで、「あのMasterの下にいたのか!!どうりで抜群にできるわけだ!!」というよいウワサ!?が社内で轟くようになりたいねぇwww

本書全体はかなり読みやすい。著者の実体験からこれからのSEはどうあるべきかが真摯に示されている。技術的な部分は少なめだけど、これからがんばろうという気にさせてくれる。また、この「SEのための」シリーズは以下もお勧め。まだ読んでないものもあるので、地道に読んでいこう。

9月から実質6年目突入になり、そろそろアグレッシブに本業で修行しなければいけない時期にさしかかっているため、しばらくはIT技術本メインで更新予定。


SEのための「どこでもやれる力」のつけ方
SEのための「どこでもやれる力」のつけ方
著者：野口 和裕
販売元：技術評論社
(2008-01-26)
販売元：Amazon.co.jp

読むべき人：
  • SEで独立したい人
  • 仕事ができるSEになりたい人
  • 自由なSEになりたい人
Amazon.co.jpで『SEのための』で他の本を見る

bana1 フリーダムSEクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 17:50│コメント(0)│トラックバック(0) 


August 27, 2011

プログラマが知るべき97のこと

プログラマが知るべき97のこと
プログラマが知るべき97のこと

キーワード：
　Kevlin Henney編、プログラマ、格言、達人、とびら
技術本を書いているような世界中で活躍するプログラマ97人＋日本人プログラマ10人によるプログラミングに関するエッセイが示されている本。いわゆるオライリー本。なんだかんだ言ってこのブログではじめてのオライリー本だね。技術者としてその出現率の低さはどうかというのもあるけど・・・。

目次を見れば、とてもワクワクする内容を予期させるものではあるが、ちょっと多いので泣く泣く省略。本家のページを参照あれ。この目次を見て読みたさをそそられないプログラマはいないと思う。また、仕事でプログラミングをしたことがある人ならば、この本を読んでまったく参考にならない、勉強にならないとか共感する部分がないということはないのではないかと思う。もしそうなら、もう達人の領域をはるかに超えているか、プログラマとして終わっているとしか言いようがない。それほどたくさん線を引いたし、共感する部分も多かったし、勉強になった。これは間違いなくいい本だね。

本当は線を引いた部分を一つ一つ示しておきたいのだけど、あまりにも多いので本当に厳選したものを示す。それらのピックアップの観点は、今後自分がプログラマとして成長していくために、現状で欠けていると思われる部分となる。

まずはソフトウェアデベロッパ、コンサルタント、メンターの肩書きを持つクリント・シャンク氏の『学び続ける姿勢』から。ソフトウェア開発業で市場競争力を維持するには学び続けるしかないとある。学び続けなければ恐竜のように滅びていくと。以下最後の部分を抜粋。
　映画『マトリックス』のネオのように、必要な情報があれば即時に脳にダウンロードするような能力が私たちにあればいいのですが、あいにくそんな能力はありません。時間をかけ、努力して学ぶしかないのです。とはいえ、起きている時間のすべてを学ぶことに向けることは不可能だし、そんな必要はありません。そのほんの一部でも、たとえば週に1回1時間でも、何もしないよりはずっと良いでしょう。人間には日々の業務とは関係ないことをする時があってもいいし、むしろそうあるべきでしょう。
　技術はすごい速さで変化していきます。学ばなければ置いていかれるのは確実です。
(pp.37)
仕事をし始めてからを振り返ってみると、あまりにも技術習得に関しては不勉強だったなぁと反省した。まぁ、いろいろと迷い、悩みながら来てしまったので仕事どころじゃなくてこんな読書ブログを始めてしまったというのもあるけど。他の分野の本ばかり読んできたけど、それがまったく役に立たないわけではないしね。読解力とかプログラミングにとても重要だしね。今後はもうちょっと技術習得に注力していく必要がある。

また、次はC#、アジャイルソフトウェア開発の専門家でもあるジョン・ジャガー氏の『1万時間の訓練』から抜粋。
　専門的な技術や知識は、ゆっくりと徐々に身につくものです。1万時間が経過した途端、急に身につく、というわけではありません。それでも、ともかく1間時間やる、ということが大切なのです。ただ1万時間と言ってもそれは膨大な時間です。週に20時間なら10年かかることになります。「1万時間努力したはいいけれど、結果、自分にはエキスパートになる素養がないとわかるだけかもしれない」そう心配する人はいるでしょう。そんな心配はいりません。エキスパートには必ずなれます。何かに秀でた人間になるかどうかは、ほぼ、自分がなろうとするかどうかだけで決まるのです。すべてはあなたの意思次第なのです。
(pp.44-45)
1万時間トレーニングをして習熟する、というのは以下の本に詳しく示されている。仕事の総稼働時間だけならもう1万時間に達しているくらいだけど、純粋にプログラミングとなると大体大学生のころからやって、多く見積もってもせいぜい4,000時間くらいなんだよね。

プログラマとして自分は向いていないのではないかと思い悩むときは大学生のときから常にあったけど、まずは1万時間積み上げろ!!ということなのだと思う。継続は力なり、は真で、続けているうちにそれが自分の才能となって武器となるんだよ、と思い込みながらまだまだこれからもがんばろうと思う。まずはもっと技術勉強とかプログラミングをやらなければだけど。あと6,000時間修行だ!!

また、生命維持システム、国際プロジェクト、フレームワークなどの多種多様な経験を持つ、クラウス・マルカルド氏の『いろいろな言葉を学ぶ』から以下抜粋。
　プログラマにとって、抽象度の異なる複数の言語を学ぶことは重要です。1種類の言語だけでは、中には非常に表現することが困難な概念があります。優秀なプログラマなら、日々の業務をこなす以外に、自分の時間を割いて別の言語を学ぶ努力をするでしょう。業務で使うものとは目的が異なり、違った概念の表現に適した言語を学ぶのです。この努力は、いつか必ず報われるはずです。
(pp.96)
今の自分にはこれが足りないなぁと思う。仕事で使う以外の言語をプライベートで学ぶことはあまりなかった。ちょっと入門書を読んで終わりというのばかりだった。まぁ、プログラミング言語の枠以外を含めていいのなら、ここ1年半くらいは必死で英語を習得していたのだけど。あとは、日々読書して日本語による読解能力を高めていたのだと言い訳してみる（笑）。でも、読書量が多い人、読解力が高い人は新言語習得が速いと思うよ。たぶんね。

ちなみに今まで触れてきた言語に関して示すと、最初のプログラミング言語は大学1年の講義のときにScheme、その後Cをがっつり、そんでPHP+MySQLでWeb系、社会人の研修でJavaちょっと、仕事でPL/SQL、T-SQL、VB.NETちょっと、そんで今は3年ほどどっぷりVBAという変遷。オブジェクト指向系のものをプライベートでしっかり学んでいこうかと思う。とりあえず自分の本業にも関係してきそうなC#あたりを習得しようと思う。

最後にプログラミングの講師でもあり、メンターでもあるピート・グットリフ氏の「よいプログラマになるには」からなるほどと思った部分。
　ここに書いてあることに興味を持ち、最後まで読んだ人はおそらく、プログラミングが好きで、良いプログラマになりたいという熱意を持った人でしょう。是非これからもプログラミングを楽しんで欲しいと思います。難しい問題を見事解決できるプログラム、自ら誇りに思えるプログラムを書きましょう。
(pp.183)
この本を読む前は、オライリー本ということもあり、気後れしていたけど、実際に読んで見ると難しくなかったし、割と読みやすかった。そして毎朝の通勤時間に少しずつ読み進めて、最後まで読めた。読みながらだんだんワクワクしている自分がいたのに気付いた。今まで本業としてIT技術者を続けていこうか迷っていたけど、なんだかまだまだやれる気がした。まだプログラミングを楽しめる、もっと挑戦し続けられると再認識できた。それくらい自分のキャリアを変えるかもしれない良書になるものかもしれない。

この本の中では他の本にも言及されている。一番言及されていると思われるのは以下だね。これもプログラマ必読書だね。

本書を読んで、今後やるべきことを簡単に以下に示す。
  • 技術本をもっと読み、週1回くらいブログに更新できるようにする
  • C#プログラミングをプライベートでも実践する
  • 問答無用で1万時間プログラミングの修行をする!!
ということで、年次が変わる9月から本気出す!!www


プログラマが知るべき97のこと
プログラマが知るべき97のこと
販売元：オライリージャパン
(2010-12-18)
販売元：Amazon.co.jp

読むべき人：
  • プロプログラマになりたい人
  • プログラマとして向いていないと思っている人
  • プログラミングで修行したい人
Amazon.co.jpで『オライリー』の他の本を見る

bana1 プロプログラマクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 12:07│コメント(0)│トラックバック(0) 


July 17, 2011

エンジニアとしての生き方

エンジニアとしての生き方　　IT技術者たちよ、世界へ出よう！ (インプレス選書)
エンジニアとしての生き方　　IT技術者たちよ、世界へ出よう！ (インプレス選書)

キーワード：
　中島聡、エンジニア、IT、キャリア論、指南書
グローバルに活躍をしているITエンジニアである著者による、若いITエンジニアへの指南書。以下のような目次となっている。
  1. はじめに
  2. プロローグ
  3. 第1章　“世界を舞台に働いてみないか？”
  4. 第2章　日本のエンジニアは大丈夫か？
  5. 第3章　勝てば官軍、負ければガラパゴス
  6. 第4章　自分を変えて自由になろう
  7. 第5章　エンジニアとして世界で成功する
  8. おわりに
(目次から抜粋)
著者は高校生のときからプログラマとして活躍しており、大学院卒業後はNTT研究所に入る。その後すぐに転職してマイクロソフト日本法人、米国本社へ渡り、Windows95,98,IE3,0などの開発に携われている。そして今も現役エンジニアとして、コードを書いておられる。

本書は著者のブログの記事を編纂したものとなり、閉塞状況が漂う日本のIT業界を憂い、そこで働いていて、行き先を見失っている若い人に向けたメッセージとなるような本となる。著者のブログは以下。自分もRSSリーダーに登録して、ある程度内容を追っていた。とはいえ、本書は2006年の記事も含まれていたりするので、そこまで昔の記事内容を知らない身としては、本書のようにまとまっているのはとても良かった。

最近自分が考えているのは、30歳まであと数年というときに、ITエンジニアとしてやっていけるのかどうか、もしくはやっていく上でどうキャリアを積み上げるか?を考える必要がある時期かなと思っていた。そんなときに本屋で本書を見かけて買って読んでみた。前から存在は知っていたのだけどね。

本エントリでは、本書の内容を網羅的に示すというのではなく、著者の考えをもとに、自分自身のITエンジニアとしての今後をどうすべきか?を考えてみたいと思う。

いきなり4章あたりから。「まずは第一に考えるべきは自分のキャリアパス」から一部引用。
　では、現時点でIT業界で苦しむSEやプログラマーの人たちは何をしたら良いのだろうか。

　とても難しい問題ではあるが、まず第一に考えるべきは自分のキャリアパスだ。五年後、一〇年後に自分がどんな仕事をしていたいか、どこで勝負をしたいか、どのくらいの価値のある人間になりたいのか、どんなスキルや知識をみつけていたいか、などなどである。

　それが見えてきたら、自分の日々の仕事と、自分の立てたキャリアパスを出来るだけシンクロさせるように努力すべきだ。
(pp.119)
大学生のときは何となく海外志向だった。だからなんとか外資系企業に運よく入った。しかし、理想と現実のギャップにひどく苦しめられて今後どうすべきか本当に悩んだ。それからいろいろとあり、なんとかいろいろと収束させることができて、今後改めてどうすべきかを考える必要がある。

まだまだ自分の能力とかスキルレベルはこれといったものが何もない。何となく日々が過ぎてしまってきた感じがする。なので、目標設定をちゃんとすべきかなと。まずは5年後くらいか。32歳前後。マネジャークラスにはなっていたいのだけど、自分の現状の昇進スピードではちょっと厳しい。

その前にマネジメント系で行くのか、バリバリコーディングするタイプのほうで行くのかという選択肢も考える必要がある。まぁ、もっと技術スキルをきっちり勉強するべきなのは目に見えている。問題は何を?という部分になる。それにはやはりなりたいイメージ像から選択する必要がある。

漠然とではあるが、10年後は海外をまたに駆けて働いてみたいと思う。著者も海外に目を向けるべきだと終始主張しており、そのためには英語が絶対必要だとも示している。一応海外志向でもあるので、英語は何とかTOEICトレーニングを通して基礎的なレベルまでは身につけられた。あとは実戦で使いこなすだけではあるが。幸い外資系という環境を活かして海外プロジェクトにアサインされるとかも考えて行きたい。

まぁ、そもそも10年後くらいはITエンジニアをやっていないということも可能性としてありえる。でもせっかく大学4年間IT教育をみっちり受けて、しかも適職診断ではほぼ必ずプログラマとかIT技術者が一番に出るから、特性はあるはずなので、どこまで自分がITエンジニアとして通用するかを試してみたいというのもある。そのためには激しく修行する必要があるのだけど。

また、「自分の適正を見つめ直す」から。
　以上のようなことを考えた上で、自分がこの業界に対してどんな価値を提供できるのか、自分は何が得意で、理想的には何がしたいのかを問い直してみる。

　自分が得意なのは、ユーザーインターフェイスの設計なのか、スケーラブルなウェブサービスの設計なのか、業務系のアプリケーションを作ることに情熱を燃やせるタイプなのか、ゲーム作りが大好きなのか?ハードウェアに近いところでソフトウェアを作りたいのか、ハードとはできるだけ離れた上位レイヤーでのアジャイルな開発が好きなのか?
(pp.141)
何となく設計よりも純粋にプログラミングで作り上げるほうが好きだと思う。ここ3年間、ExcelVBAツールでひたすらコーディングしてきた経験から、そこまでプログラミングが出来ないわけではないし、案外自分の思い通りの脳内設計でエレガントにコーディングできて一人で（・∀・）ﾆﾔﾆﾔしている部分もかなりある（笑）。大学生のときは課題をこなすためのプログラミングとかで、あまり楽しさを感じていなかったので、これは大きな発見かもしれない。

ではずっとVBAレベルのスタンドアロン系のものを作っていて満足かと言うと、それはないなぁと思う。Web系の言語で何かサービスを独自に作ってみたいなぁとか思うけど、最近流行の言語とか技術トレンドに疎いので、ここをもうちょい網羅的に勉強する必要がある。たぶん何かを作り上げるのが好きで、修練を重ねて自分のコーディングレベルがどこまで通用するかも試してみたいというのがある。これはTOEIC900点突破トレーニングの成功体験によるものだと思う。

あと「キャリアパスを考える」から以下のようにある。
　目標を設定する際に大切なことは、「そんなことは自分には無理」と最初からあきらめずに、高めの目標を設定すること。「少し高望みかな?」と思えるぐらいがちょうど良い。イメージは具体的であればなるほど良い。実際のこの業界で活躍している誰かを自分のロール・モデルとして目標設定するのも悪くない。
(pp.143)
これはよく自己啓発本に書いてあることかな。そして自分もやはりそうすべきかなと思う。何度もTOEICの例を挙げてばかりだけど、900点取るという目標は、設定当初内心無理じゃないかと思っていたけど、何とか達成できた。この体験が自分の精神的な壁を一つ壊せたのだと思う。つまり、選択と集中で日々修練を継続していけば、必ず到達できるのでないかと。だから、目標設定するときもちょっとというか、かなり高めの目標を設定して、日々修行するほうがよいし、そのほうが日々精神的に充足感を得られるタイプだし。

そこで、自分のIT技術者としての目標、野望とは何かを改めて考える必要がある。今何となく思い浮かぶのは、以下かな。
  • プログラミング言語を3つ極める
  • 独自のWebサービスを作り上げて、どこかに買収される
  • 英語を使って仕事し、自分の専門分野の技術書を書く
とかかな。まぁ、どう考えても少し高望みというレベルではなく、現状では困難だろうけど、目標に向かって修行するのが好きだから別に結果などについてはこの際気にしない。あえてこのような場でオープンに宣言することが重要かなと。自分自身の志向性を把握するためにも。

最後に一箇所だけ抜粋。「好きだからがんばれる、だから成功できる」から。
　長々と書いてしまったが、まとめると、せっかく職に就くのであれば、給料とか社会的地位とかを基準にするのではなくて、自分が好きなことをやりたいこととマッチした職を選ぼう、というのが私の人生論である。若いうちにいろいろなものに触れておき、自分が本当に何がしたいのか、何になら夢中になれるのかをできるだけ早いうちに見つけ出すことはその後の人生にとって人生にとって大きなプラスとなる。そんな「天職」を得るための努力なら惜しむことはないし、けっして無駄にはならない。そうやって「好きなことをして生きていく」ための努力を続けている限り、（ほかの人にとっては）つらいことも苦痛ではなくなるし、楽しい人生がおくれる。一度しかない人生、思いっきり楽しもうぜ。
(pp.169)
IT業界で今後もやっていくべきかどうかを考えなくてはならないのは、どうしても日本でITといった場合、土方とかデスマとか過労死するとか出会いがないとか（笑）負の側面ばかりに目を向けがちだからね。そうではなくて、もっと正の部分にも目を向けつつ負の側面を回避するようにしていけばいいのだと思った。

また、ITに限らず、他の職に就いたとしても好きかどうか、楽しめるかどうかという部分がポイントなのだと思う。ここだけは自分をごまかさず、自分の内面に正直に従いたい。

自分と同じようにIT技術者で、キャリアとか今後の方向性について考えてみたい人、悩んでいる人はぜひ読んだほうが良い。

さて、あとはもっと目標設定をきっちりやって、日々修行に励むだけだね。


エンジニアとしての生き方　　IT技術者たちよ、世界へ出よう！ (インプレス選書)
エンジニアとしての生き方　　IT技術者たちよ、世界へ出よう！ (インプレス選書)
著者：中島 聡
販売元：インプレスジャパン
(2011-03-11)
販売元：Amazon.co.jp

読むべき人：
  • IT技術者でキャリアを考えたい人
  • グローバルなITエンジニアになりたい人
  • IT技術者を辞めようとかな思っている人
Amazon.co.jpで『中島聡』の他の本を見る

bana1 ITエンジニア指南書クリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 16:06│コメント(0)│トラックバック(0) 


April 13, 2011

facebook完全活用マニュアル

facebook完全活用マニュアル
facebook完全活用マニュアル

キーワード：
　オブスキュアインク、facebook、マニュアル、入門書、いいね！
facebookの使い方が示された本。以下のような目次となっている。
  1. Part01　introduction―Facebookって何?
  2. Part02　Let’s begin―Facebookを始めよう
  3. Part03　privacy&account―プライバシーとマイアカウントの設定
  4. Part04　connection―友達とつながろう
  5. Part05　share―話題を共有しよう
  6. Part06　communication―コミュニケーションを深めよう
  7. Part07　page&group―つながりを広げよう
  8. Part08　application―アプリケーションを楽しもう
  9. Part09　mobile―モバイル環境で楽しもう
  10. Part10　business―ビジネスで活用しよう
  11. Appendix　 おすすめFacebookページガイド
(目次から抜粋)
初版発行年月が、2011年4月1日と割と最近出版されたもので、書店で売っているfacebookの使い方本としては、これが一番分かりやすい内容だと思われる。

マニュアルと示されている通り、facebookの概要からアカウント登録、アプリの使い方、facebookページ、グループの作成までといったことが画面キャプチャつきで示されている。

まず、全ページカラーであるのがよい。他のfacebook本もたいていはカラーであるが、たまにモノクロのものがある。モノクロに比べてカラーであるのはかなりぱっと見の印象がよくなる。

また、操作方法については、キャプチャ内を枠線などで図示しながら1ステップごとに分かりやすく示されている。facebookそのものは、どうも日本人の使い慣れているWebのインタフェースとは違うので、直感的にどこに何が配置されているのかが分かりづらかったりする。そのため、一度こういう本でfacebook独特のインタフェースを把握しておいたほうがよいかもしれない。

あと、本書で示されている内容で、特に参考になった部分を以下に列挙する。
  • 実社会でリアルにるながりのある相手に絞って友達になる、という使い方が基本
  • Twitterの感覚で無闇にリクエストを出すのは避けたほうが無難
  • facebookでは自分と関係する「誰」が「どんな発信をするか」、またその相手に「自分が何を伝えたいか」、という双方向の情報共有と人間関係の構築が大切
  • facebokのプロフィールは詳細な履歴書にもなり、自分を世界の人々や企業へアピールする有効なツールになり得る
  • 「いいね!」はそのコンテンツの人気度や注目度を表す
  • また「いいね!」された側も情報発信に対するリアクションをダイレクトに感じられ、モチベーションにもつながっている
  • facebook内でもそのリンクがまた別のユーザーに「いいね!」されれば、それだけ自分のサイトへの「入り口」が増えるので、ブログのアクセス増加につながる
まぁ、こんなところかな。最近になってやっと「いいね!」の効力というか、ポテンシャルを理解した。なるべく他の人のコメントや写真、ネット上の他の記事に「いいね!」することにしている。

そして、やっとこのブログにも「いいね!」ボタンを配置した。ブログのサイドバー左上と各記事に「いいね!」ボタンが押せるようになっている。また、ついでに、Twitterとはてなブックマークのボタンも設定しておいた。

RSSリーダーで見ている場合は、各種ボタンは表示されないけど、自分のブログに訪れると、「いいね!」ボタンが押せるので、facebookやっている人はぜひ押しておいてください（笑）。

自分のfacebookの利用目的は、どちらかというと既存の人間関係を濃密にするというよりも、海外展開を視野に入れて、外国人の友達を作るということにしている。そのため、一応今のところ何とか英語で書いている。まだまだ1文ごとにしか書けないけど。

他にもライフログをつけるという目的もあり、街中の写真をスマフォで撮って、そのままfacebookにアップしている。これは使ってみてかなり便利だと思った。以前は日記ブログに写真をアップするとき、デジカメのメモリをPCに読んで画像サイズを縮小して一括アップし、さらにそこから記事作成という流れだった。

スマフォとfacebookだと、画像サイズなどをあまり気にせずに撮ったらすぐにコメントをつけてアップできるのがよい。なので、今は投稿の半分がスマフォ経由からの写真アップとなっている。

ちなみに、自分のアカウントは以下。まだまだ始めたばかりなので、もっといろいろと使っていきたい。イベントを作成して読書会をしたりとか、ゴルフに行くとか。

あ、ちなみに最近ゴルフ始めることした☆
まったくやったことないけどww
まぁ、自分の私生活を覗き見たいと言う人は、ぜひ友達申請を〜。ちゃんと承認しますよ

また本書の内容から脱線したが、まとめとしては、本書はカラーページ250ページもあるのに、1200円程度とお買い得で、現時点でfacebookの基本的な使い方本としてはこれが一番分かりやすいと思う。Facebookを始めるときに、最初にこれ1冊だけ読めば、少なくとも使い方や機能で分からないという部分はないと思う。その後友達が増える保証はまったくないけどね・・・。


facebook完全活用マニュアル
facebook完全活用マニュアル
著者：オブスキュアインク
販売元：ソシム
(2011-03)
販売元：Amazon.co.jp

読むべき人：
  • facebookを始める人
  • グループとfacebookページの違いがわからない人
  • facebookで海外展開したい人
Amazon.co.jpで『facebook』の他の本を見る

bana1 いいね!ボタンもついでにクリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 22:52│コメント(0)│トラックバック(0) 


March 28, 2011

日本人のためのフェイスブック入門

日本人のためのフェイスブック入門 (Forest2545Shinsyo 29)
日本人のためのフェイスブック入門 (Forest2545Shinsyo 29)

キーワード：
　松宮義仁、facebook、入門書、いいね!、影響力
facebookの入門書。以下のような目次となっている。
  1. プロローグ　新しいメディア「フェイスブック」とは?
  2. 第1章　アメリカ人とは違う日本人にとってのフェイスブック
  3. 第2章　人生を変える!友達を1000人つくる方法
  4. 第3章　フェイスブックを使ってビジネスで儲ける具体的な方法
  5. 第4章　フェイスブックライフを快適にすごすための「マナー」&「プライバシー保護」
  6. 特別付録1　フェイスブックを100倍楽しく便利化するTips
  7. 特別付録2　可能性を感じるファンページ
(目次から抜粋)
タイトルにある『日本人のための』というのは、日本人が特に気にする実名登録やプライバシーに関してより他の本よりも詳しく示してあるという意図らしい。全体的には、facebookの基本的な機能の説明が示されている。

とくになるほどと思った部分を列挙しておく。
  • 「いいね!」ボタンをワンクリックするだけで、自分のページへのリンクを獲得できるしくみがある
  • 「ファンページを専門分野ごとにつくって、情報を発信していけばいいじゃん!」
  • 「友達申請は名刺交換」のようなもの
  • 「いいね!」というのは、リンクだけでなく、口コミ発生のボタンも兼ねている
  • 「『いいね!』を押してもらいたかったら、先に『いいね!』を押す」
  • 「最新情報」は、友達になっている人の中で、最新の発言順に並んでいるニュースフィード
  • 「ハイライト」とは、フェイスブック側のアルゴリズムで、普段からよく関係している人を優先して表示するニュースフィード
  • 「人間性」の部分を個人アカウントでおぎなって、「専門性」をファンページでアピールしていく
  • 「ウォールがツイッター、ノートがブログ」
  • フェイスブックは、ビジネスの場面では、今後は「名刺」や「履歴書」代わりに使われていくことも予想される
発売が今年の1月なので、この時点では「ファンページ」と言われていたが、最近では「facebookページ」と呼ばれているので、その部分を読み替える必要がある。

まだfacebookを始めて1週間ちょっとしか経ってない状況なので、この本に示されている基本的なことが結構分かりやすかった。特にfacebookにおける「いいね!」の概念がよくわかっていなかったので、そういうことだったのか!!と思った。著者曰く、「いいね!」は自分自身のfacebook内での影響力を発揮するための肝になるらしい。

逆にfacebookをある程度使いこなしている人にとってはあまり新しく得るものが少ないかもしれない。どちらかというと著者はビジネスに利用することを目的としており、いかに集客をして自分の影響力を大きくするかに主眼が置かれている。そういうビジネスくささに違和感を覚える人には合わないかもしれない。

とりあえず1週間使ってみての所感としては、Twitterよりも静的であるが、ブログよりも動的なイメージで、Twitterとブログのいいとこどりなソーシャルネットワークサービスがfacebookなのではないかと思った。

Twitterだと書き込んだつぶやきはTLに流れていって、あまり蓄積感がなく、即物的なイメージがある。その分瞬発力というか、即効性、情報の伝達度は早いかもしれない。たまたまTL上に流れてくるものをキャッチすればだけど。そのため、自分は人のつぶやきをリストやRSSに登録して常にウォッチするという使い方はしていない。

ブログはどちらかというと、日付とカテゴリで記事を蓄積していくイメージ。どちらかというと思考のとりまとめや一定のテーマで長文を書き続けていく感じで、コミュニケーションツールとしてはあまり向いていない気がする。ブログにコメントを残すのと、Twitter、facebookでメッセージ、コメントをやり取りするのとはかなり意識が違う。ブログはどちらかというと相手の家の敷居をまたぐイメージ。

facebookはTwitterとブログの両方の特性を併せ持っている感じで、流れていってよい部分はウォールに書き込み、そうじゃない部分はノートに書き込める。それでいてコメント、メッセージをやり取りできるのは基本的に友達承認したユーザーだけなので、Twitterほど自由すぎない。

ここ1週間の利用で、facebookは本当に人間関係を構築するために作られたシステムだと実感した。自分自身はたぶん、Twitterはただの日常生活のちょっとした思索、気付いたこと、思ったことを気軽に情報発信するツールとして使い、ブログは読書による日々の思索の積み重ねを書き、facebookはより人とのつながりや、自分自身はどういう人間であるかを示すために使うことになるのだと思った。

まぁ、そんなこんなで、完全に英語だけで日々更新しているので、もしよかったら友達申請どうぞ。全員例外なく受け入れ予定です。まぁ、英語だけで更新しているからなかなか自分から友達申請するのは気がひけるし、友達申請してくれる人も少ないだろうね（笑）。それでも初めて1週間でなんとか18人友達がいる。メールアドレスから一括友達申請したり自分からもっと申請すれば余裕で3桁は行くはずだけど・・・。

あとはこのブログに「いいね!」ボタンを設置するようにしないとね。それはなるべく早めに対応予定。


日本人のためのフェイスブック入門 (Forest2545Shinsyo 29)
日本人のためのフェイスブック入門 (Forest2545Shinsyo 29)
著者：松宮義仁
販売元：フォレスト出版
(2011-01-07)
販売元：Amazon.co.jp

読むべき人：
  • facebookを始めたばかりの人
  • 「いいね!」の概念がよく分からない人
  • ビジネスでfacebookを使いたい人
Amazon.co.jpで『facebook』の他の本を見る

bana1 いいね!クリック☆ 　にほんブログ村 本ブログへ


type5w4_lion at 21:24│コメント(0)│トラックバック(0) 


March 21, 2011

facebookを100倍活用する本

facebookを100倍活用する本 (アスペクトムック)
facebookを100倍活用する本 (アスペクトムック)

キーワード：
　アスペクト、facebook、ムック、入門書、始めました
最近発売されたfacebook入門のムック本。以下のような目次となっている。
  1. Chapter1　世界最大のSNS「Facebook」とは？
  2. Chapter2　Facebookを始めよう！
  3. Chapter3　Facebookの楽しみ方
  4. Chapter4　さらにネットワークを広げよう！
  5. Chapter5　モバイルでFacebookにアクセス！
  6. Chapter6　Facebookアプリを活用する
  7. Chapter7　Facebook上級テクニック
(目次から抜粋)
今日からfacebook始めました。

時代はfacebook!!、映画「ソーシャルネットワーク」も見たし、自分の回りでもやっている人が多いし、TOEIC終わったらアカウント登録してみると半年前から宣言していたので、そろそろやるにはよいタイミングということで、始めてみた。

始めるに当たって参考にしたのはこのムック本。980円で安く、フルカラーの100ページでアカウント作成といったわりと基本的なところから示されているので本屋で買ってみた。西新宿のブックファーストで買ったが、理工系本の売れ筋で1位か2位だった。

まぁ、この本の内容を書評するというよりも、facebookを始める時に何をしたかといったことや、どういう風に使っていくかを示しておきたいと思う。

以下始めるまで、そして始めた直後にやったことのリスト。
  • 実際にfacebookをやっている人の感覚的な話を聞いてどんなものか知る
  • 本屋に行ってfacebook本を3冊ほど購入（このムック1冊、他新書2冊）
  • ムック本を参照しながらアカウントを実名で作成
  • 所属組織も含めてプロフィールを英語で設定
  • プライバシーの設定
  • 83年会のページで「いいね!」を押してみる(83年会)
  • 「Smart Tweets」というアプリをインストールしてTwitterの投稿を反映できるように設定
  • Androidスマートフォンにfacebook公式アプリをインストールしてスマフォでも使えるように設定
  • firefoxにfacebook toolbarをインストール(Firefox アドオン - Facebook Toolbar | Mozilla Japan)
  • 適当に極少数の友達を申請（笑）
一応facebook以外にも日記ブログとかこのブログとかTwitterもやっているので、4刀流ということになる（笑）。なので、今回始めたfacebookをどう使っていくかを考える必要がある。現時点で考えているのは以下の目的、ポリシーとしている。
  • 実名登録で、所属組織まで含めて完全にオープンでやる
  • 友達申請は基本的に全員受け付ける
  • 英語のライティングスキルのトレーニングを兼ねて英語で日記をつけていく
  • 海外進出に向けてなるべく外人の友達を意識的に増やして交流する
  • 単純にリアルでの知り合いのつながりを増やす
まぁ、こんなところか。基本的にこの読書ブログは本のレビュー、感想を示し、Twitterはブログに書くまでもないことをつぶやいたり、日記ブログは映画レビューとか雑感を書いておき、facebookはイベント管理やつながり、そしてグローバル展開用の道具として使おうと思う。

TOEICで900点超えた後、そこで英語の勉強を終わりにするのではなく、ここがある意味英語を真に使いこなすためのスタートラインでもあるので、このまま勉強を続ける動機付けになればいいかなと思う。自分が必要な、もしくはほしい英語能力は最終的にはスピーキングよりもライティングであるので、日記程度から英文を書いていこうと思う。

まぁ、Twitterの投稿は日本語で、それがfacebookにも反映されているからバイリンガル設定にはなっているけど。あ、あとなぜかfacebookの言語設定でJavaとかSQLとかVBAといったプログラミング言語まで選択できるからついでに選択しておいた（笑）

あとは実名登録じゃないとアカウント削除されるというのもあるし、基本実名で。別に匿名である必要性はもうないかなと思うし、そろそろ実名でいろいろと活動していったほうがいいころかなというのもあって、実名にしてある。ネットとリアルのギャップを少しずつ埋めて、徐々にリンクさせていこうかなと。

また、実名にすることで、匿名とどう違うのか、どういう影響があるのかを確認しておきたいというのもある。よほど変なことを書かなければ炎上したりはしないだろうし。その分発言や書き込みには気をつけないとだけど。

これからfacebookライフを楽しむ予定〜☆

Just started facebook!!
Don' t hesitate to follow my facebook account!!Thank you for your attention.


facebookを100倍活用する本 (アスペクトムック)
facebookを100倍活用する本 (アスペクトムック)
著者：アスペクト
販売元：アスペクト
(2011-02-21)
販売元：Amazon.co.jp

読むべき人：
  • facebookをはじめようと思う人
  • facebook本がたくさんあって迷う人
  • Masterと友達になりたい人（笑）
bana1 facebookライフスタートクリック☆ 　にほんブログ村 本ブログへ

Amazon.co.jpで『facebook』の他の本を見る


type5w4_lion at 22:54│コメント(0)│トラックバック(0) 


July 31, 2010

応用情報技術者試験勉強法〜社会人のための2ヵ月半で確実に7割獲得する方法〜【ネタ記事】

今日で7月も終わりです。
皆様、暑い日々をいかがお過ごしでしょうか?

自分は若干夏バテ気味です('A`)・・・。

さて、今回のネタ記事は、応用情報技術者試験の勉強法についてです。

来る情報処理技術者試験の秋期に備えて、明日から勉強して確実に7割以上を獲得できるような勉強法（勉強スケジュール）を示したいと思います。

以下のような人におススメの記事となります。

  • 現役IT技術者（SE,プログラマー）だが、そろそろワンランク上の資格を取得したい
  • 過去に応用情報技術者試験に数回落ちたことがある('A`)
  • いつも資格試験などの勉強は一夜漬けで乗り切ってきたが、社会人になってそろそろ限界を感じている
  • 応用情報技術者試験に初めて挑戦してみようと思うけど、何をどこまでやればよいか分からない（´・ω・`）ｼｮﾎﾞｰﾝ
では、以下から本題です。

1. 応用情報技術者試験はなめてかかると合格できない!!

自分は今年の春期に受験し、何とか合格しました。以下は証拠キャプチャと点数内訳です。

応用情報技術者合格

午後問題で選択した分野は以下になります。
  1. プログラミング
  2. システムアーキテクチャ
  3. ネットワーク
  4. データベース
  5. 情報システム開発
  6. 情報セキュリティ
今年の春期で3度目の挑戦でようやく合格しました。ちなみに、1回目はソフトウェア開発技術者試験時に1回（平成19年度秋期、午前問題570点で撃沈（´・ω・`））、応用情報技術者試験になって1回(平成20年度春期、午前問題56.25点で撃沈('A`))だったので、今年の春こそ確実に合格したいと思って、過去2回の2倍ほどの勉強時間を費やして、何とか合格しました。

過去2回の受験では、応用を甘く見ていたので、最低限の勉強しかしなかったため、ギリギリ足きりラインにすら到達しないという状況でした・・・。

一応情報系の学部出身で、学部4年間を通して最低限基本情報レベルのカリキュラムは網羅されているような内容の勉強をしていたし、現役のSEという自負もありましたが、ある程度しっかり勉強しなければ確実に合格できないということを思い知らされました。

ちなみに、基本情報は受けたことすらないです。いつもいきなり応用狙いでした

よく周りの人とかネット界隈を見ると、

『応用?あんな楽勝な資格試験、2週間（or 1週間）勉強すれば余裕でしょ』とか、『あんなの落ちるなんてダメだろwww』

とか見聞するかもしれませんが、それらは人によるとしか言いようがありません（笑）もともと地頭がよい人だったり、日ごろからバリバリIT技術系の勉強をしていたり、たまたま受験した回の難易度が高くなかったりして合格できただけかもしれませんが・・・。

少なくとも自分のように試験勉強が得意じゃなくて、日ごろからIT技術系の勉強をみっちりしていない人（社会人）が、同じようにまねして2週間前後の勉強量で臨むと落ちる可能盛大です。

ヽ(；´Д｀)ノ

また、社会人ともなると、日々の業務の労働時間の長さなどから、短期でみっちり（1日8時間とか）といった勉強が難しくなります。

そして、一体何をどれだけやればどの程度得点が獲得できるのか?が分からないために、勉強時間の量が少なすぎたりして不合格になってしまったりします。

そこで、この記事では、2ヵ月半という無理のない勉強スケジュールで、応用情報技術者試験を確実に7割以上（そもそも75%ほどしか点数を獲得してないため）獲得して合格する方法を示したいと思います

2. 勉強する参考書選びは超重要!!

資格試験などは、勉強する参考書選びが合否を決めるといっても過言ではありません!!なぜなら、解説が分かりにくかったり、読みにくいといったダメな本で勉強していては勉強時のストレスになるし、工数の無駄遣いになるからです。

逆に良質な問題集、参考書であれば、効率よく少ない時間で合格まで到達する可能性が高くなります。

以下は、自分が書店で数時間立ち読みし（（笑））、さまざまな参考書を比較し（もちろんAmazonのレビューもチェック済み!!）、実際にそれらを使って勉強してみての実感からおススメするものです。

参考書はこれ!!

平成22年度[春期][秋期] 応用情報技術者 合格教本平成22年度[春期][秋期] 応用情報技術者 合格教本
著者：大滝 みや子
販売元：技術評論社
発売日：2009-12-09
おすすめ度：5.0


1冊参考書を選ぶとなると、これが一番よいと思います。ページの構成が分かりやすく、読みやすいものとなっており、脚注に用語の解説もあります。

午後問題対策に特化したページもあり、各分野1題ずつの掲載となっております。さらに午前、午後問題の1回分の過去問が載っております。

またCD-ROMつきで、17年度春期から21年度春期までの午前問題、午後問題がPDFファイルとして収録されているのでお得です。

ページ数が710ページとかなり分厚いので、地道に読み込まないとなかなか終わりませんが・・・。

午前対策問題集ならダントツでこれだ!!

平成22-23年度 応用情報技術者 試験によくでる午前問題集平成22-23年度 応用情報技術者 試験によくでる午前問題集
著者：大滝 みや子
販売元：技術評論社
発売日：2010-03-19


午前対策ならこれ1冊で十分という内容です。まず、他の問題集に比べて格段にぱっと見のページ構成が見やすいです。そして解説もとても丁寧で、同著者の合格教本をやらなくてもよいくらいです。

また、22年度春期の試験で、この問題集に収録されているまったく同じ問題（問題文に出てくる数値も選択肢も同じ）が10問近く出題されました。この問題集の収録問題数は433問なので、10/433（2.3%）でしかないじゃなんと思うなかれ午前問題数80問中10問(12.5%)も楽勝で点数を稼げるのだから

この本のおかげで合格したも同然でした

午後対策はこれだ!!

応用情報技術者 午後問題の重点対策〈2010〉 (情報処理技術者試験対策書)応用情報技術者 午後問題の重点対策〈2010〉 (情報処理技術者試験対策書)
著者：小口 達夫
販売元：アイテック
発売日：2009-12
おすすめ度：5.0

午後問題集というくくりであまり問題集が多く売っていない中、書店とAmazonの評価を比べてみてこれを買ってやってみました。

ぱっと見、文字がぎっしり詰まっている印象ですが、それは解説がかなり丁寧に示されているからでもあります。各分野4〜8回分の問題数が収録されております。

午後問題は事前に受ける問題を決めておけば、全部網羅してやる必要はないです。

アルゴリズム問題が苦手な人は、全部やって確認しておきましょう。また、他の分野は苦手な分野を優先的にやるようにしておけば問題ないでしょう。

午後問題は基本的に午前問題の延長ですが、案外時間配分がネックになります。午後問題の問題文に読みなれていないと、意外に時間配分でミスって分かる問題も焦って解けなくなるという可能性があります。

さらに、25文字以内で回答しろといった字数制限問題も何問か出題されます。過去問で解答の表現力を確認しておくというのも重要となります。

この本で時間配分と字数制限回答問題に慣れておきましょう。

以下はオプションです。

ポケットスタディ 応用情報技術者 (情報処理技術者試験)ポケットスタディ 応用情報技術者 (情報処理技術者試験)
著者：村山 直紀
販売元：秀和システム
発売日：2009-01
おすすめ度：2.5

この本単体で評価する場合、これ1冊ではまったく体系的な理解が深まらないという感じです。これは完全に復習用の本で、合格教本で概要を理解し、午前問題集で対策し、その合間を埋める暗記用の本です。

コンパクトで持ち運びがしやすいので、電車通勤時間などに読み込んでいくのがよいと思います。ただし、いきなりこれから始めると意味不明で挫折する可能性があるので、他の対策本で理解が進んでからがよいです。

他の対策本で理解が進んでから読むと、説明が極端に省略されているという部分が利点になってきます。

また、そもそも基本情報レベルでもちょっと怪しいかもしれない、と思う人は以下のものがおススメです。一旦基本に立ち戻るというのもありです。

追記（2011.4.23）
上記に示した参考書は、この記事投稿時点で自分が使用した参考書の年度のままとなっております。最新版は以下よりご確認ください。

Amazon.co.jpで『応用情報技術者試験』の他の本を見る

3. プロIT技術者を自認するならデスマ的な勉強スケジュールは避けよう!!

先ほど合格に必要な参考書を示しましたが、一体何をどれだけどのペースで勉強すればいいのかよくわからん（´・ω・`）ｼｮﾎﾞｰﾝ、ということがあります（以前の自分はそうでした・・・）。

そういうときに必要なのが、おおよその勉強スケジュールをしっかり立てて、制約条件のある中で地道に勉強を継続し、期限までにアウトプットする（試験日までに合格できる知識をつけて本試験に臨む）ことが重要になります。

スケジュールを立てるときに重要なのが、睡眠時間を削ったりといった無理をするようなスケジュールを立てないということです。そのためには、事前に見積もりをしっかり実施し、余裕を持って勉強をし続けることです。

確かに1，2週間という短期で瞬発力を発揮して成果を出せることも時には重要ですが、それで合格しても仕事で活かせるほど知識が体系化されない可能性があります。

資格試験など取ったところで転職に有利といったことや仕事ができることの証明にはほとんどなりませんが、どうせ資格試験を受けるなら、資格試験を通して得られる知識体系を自分の日々の業務に活かすことを考えたいものです。

また、プロIT技術者として生きていくのであれば、無謀なスケジュール、デスマ的な勉強方法をするのではなく、無理のないスケジュールで質の高いアウトプットができるようになっておきたいものです。

そのためには、資格試験のためだけの付け焼刃的な知識のつめこみではなく、時間をかけて考えながら勉強する必要があります。

そこで、無理のないスケジュールで明日、8月1日から試験日である10月17日までおよそ2ヵ月半の余裕を持った勉強スケジュールが重要になります!!

4. 2ヵ月半で何をどの程度やればよいのか?

自分の場合は、2月半ばから4月半ばの受験まで、約2ヶ月間費やして75%獲得できました。

で、具体的にどの程度やればよいのか?が一番気になるところだと思います。

基本的に先ほど示した以下の3つの対策本だけをきっちりやればよいです。
  1. 合格教本
    目標は第1部のみを2回転読み込みです。
    1回転目は1日90分で15ページペースの進捗で大体1ヶ月ほどかかります。
    2回転目は90分で20ページペースで読み込みましょう。
    10月ごろに入ったら第2部の午後問題部分に着手です。

  2. 試験によく出る午前問題集
    合格教本の1回点目読了が完了した9月に入ったころから、この問題集に着手しましょう。90分15ページで26日前後で完了できるでしょう。
    2回転目は10月に入ってから2週間で終わらせれば、午前対策としては十分です。

  3. 午後問題の重点対策
    この本は午前問題の知識がついてから実施するとよいので、10月に入ってからでよいでしょう。本試験はアルゴリズム問題を解くとして、収録されている全6問を1日1問ペースで実施しましょう。
    また、その他の分野も各3問ほど取り組んでおけば十分でしょう。解答確認も含めて、1分野1問40分が目安となります。
このようなペースでやればよいですが、なんとなくわかったようなわからないようなペース配分だなぁ、と思ったそこのあなた!!そんなあなたのために、試験日までの綿密なスケジュールを策定しましたよ以下のリンク先からExcelファイルをダウンロードできます上記のファイルは改変、2次配布は自由です。自分の使いやすいようにカスタマイズしてください

内容をチラ見したい人は、以下のキャプチャを参考にしてください。

schedule_sample

この勉強スケジュールExcelファイルには以下の特徴があります。
  • 先ほど示した参考書の各章ごとのペース配分が日付ごとに示されている
  • 春期に合格したときに2ヶ月間勉強記録をつけていたペース配分から、無理なく理想的なスケジュールを策定
  • 日々の勉強記録をつけやすい内容となっており、勉強に対するモチベーション維持ができる
  • 日々の勉強時間の成果を視覚化する累積度数グラフを設定済み
スケジュールの開始日は明日、8月1日からなのでぜひこれを参考に勉強して欲しいと思います

追記（2011.4.23）
設定日付が古いままですが、Excelの関数で1セルを変更すると他の日付も変わるようになっているので、それぞれのスケジュール間にあわせて日付設定をしていただければと思います。

実際にこの通りにできるかどうかは別ですが、一つの勉強スケジュールの目安としてご使用ください。

ただし、この通りに実践すれば難易度にもよりますが、確実に7割以上は取れるはずですm9（・∀・）ﾋﾞｼｯ!!

さて、応用情報技術者試験のインターネット申し込みは以下からできます以下は今回の記事の簡単なまとめです。
  • 応用情報技術者試験は、合格率が20%前後なので、それなりに対策しないと合格は難しいでしょう
  • 参考書選びが重要なので、自分に合った参考書を選択しましょう
  • 資格試験だけの勉強に留まらず、資格試験を通して得られる知識体系を自分の本業に活かそう
  • 勉強のスケジュールは余裕を持って、事前に適切な工数を見積もり、デスマ的な勉強はやめよう
  • たかが資格試験ではあるが、資格試験の勉強スケジュールから工数管理を身につけよう
以上、応用情報技術者試験勉強法〜社会人のための2ヵ月半で確実に7割獲得する方法〜【ネタ記事】でした〜。

ちなみに、自分の次の資格試験はTOEIC900点突破です。日々Twitterで英語トレーニングなどについてつぶやいておりますので、気になる人はサイドバーのTwitterガジェットからフォローお願いします☆

追記（2011.4.23）
おかげさまで2011年1月30日の公開試験でTOEICで955点取得できましたでは、皆様の健闘をお祈りいたします（・∀・）!!

bana1 役に立ったらクリックをお願いします☆ 　にほんブログ村 本ブログへ


type5w4_lion at 17:43│コメント(137) 


April 19, 2010

平成22年度 イメージ&クレバー方式でよくわかる 栢木先生の基本情報技術者教室

平成22年度 イメージ&クレバー方式でよくわかる 栢木先生の基本情報技術者教室
平成22年度 イメージ&クレバー方式でよくわかる 栢木先生の基本情報技術者教室

キーワード：
　栢木厚、基本情報技術者、参考書、イメージ、猫
基本情報技術者試験の参考書。以下のような目次となっている。
  1. 第1章　情報の基礎理論
  2. 第2章　データ構造とアルゴリズム
  3. 第3章　ハードウェア
  4. 第4章　基本ソフトウェア
  5. 第5章　システムの構成と方式
  6. 第6章　システムの開発技術と監査
  7. 第7章　ネットワーク技術
  8. 第8章　データベース技術
  9. 第9章　セキュリティと標準化
  10. 第10章　情報化と経営
(目次から抜粋)
基本情報技術者試験の参考書で、この本は以下のようなコンセプトからなるようだ。
「難しい知識を難しく教えても意味がない。
難しい知識をわかりやすく教えることが重要である。」
(pp.3)
コンセプトの通り、かなり分かりやすいなぁと思った。

タイトルにイメージとあるが、これは、各節の初めにその節の内容についてのイラストが載っていることを示す。大抵は表紙の猫が描かれている。『情報量の単位』という節では、2進数の0,1をイメージして、ONのとき猫が電球のスイッチを入れていて、OFFのときは寝ているというイラスト。そういうのがあると、これから学ぶ内容がイメージしやすくてよい。

また、クレバーとタイトルにあるのは、『nビットで表現できる情報量 とくれば 2のn乗通り』と暗記項目のくればの部分のことらしい。各節のその部分だけをチェックするだけで、要点がつかめる。

昨日は情報処理技術者試験の日で、自分は応用情報技術者試験を受験した。基本情報技術者試験用のこの本を読んだのは、基本情報レベルのものも理解できているかどうか確認したかったのと、Amazonでこの本のレビューを見たら、応用情報にも出てくる部分の基本が理解できてよいとあったので、読んでみた。

確かに応用情報と重複する部分が多くあり、他の応用情報の参考書を読みつつ、こっちの本で復習になったのでよかった。また、応用では省略されているような基本的な事項、例えばキロ、メガ、ギガ、ミリ、マイクロ、ナノといった整数乗倍の単位などが載っていたのはよかった。計算問題で単位を合わせるとき、どれがどれだか結構すぐに忘れてしまうので。

他にも2進数から10進数、2進数から16進数の基数変換などがイラスト付で理解しやすかった。

ただ、参考書なので、問題数は少なめだと思われる。この参考書を何度か繰り返し読み込み、同時に過去問題集で多く過去問を解くのが良いと思われる。

ページ数は400ページを越えるので、通勤電車の合間に少しずつ（1日大体15分くらいのペースで）読むと大体1ヶ月はかかる。繰り返して読む場合は、もっと1日あたりに読む時間を多く取るべきだが。

昨日の試験の自己採点サービスなんてものがあるらしい。自分は、面倒だからやらないけど。

約1ヶ月ぶりの更新となった。まぁ、昨日の応用情報技術者試験対策のため、みっちり勉強する必要があったので、ブログ更新はできなかった。なんせ3度目の受験だったので・・・。さすがに3度目も落ちるのはありえないと思い、今回は割りと必死でいつもより勉強する必要があった。さすがに余裕で合格だろうという手ごたえがあったので、合格しているはず

合格発表は6月25日（金）らしい。合格していることを確認したら、応用の参考書、また勉強法について記事を書くと思う。

また、応用の勉強が終わったので、次からはTOEIC900点突破対策を再開する。そのため、しばらくは洋書が多く更新されるかもしれない。そのうち今のTOEICの点数状況のネタ記事を更新予定。


平成22年度 イメージ&クレバー方式でよくわかる 栢木先生の基本情報技術者教室
平成22年度 イメージ&クレバー方式でよくわかる 栢木先生の基本情報技術者教室
著者：栢木 厚
販売元：技術評論社
発売日：2009-12-11
おすすめ度：4.0

読むべき人：
  • 基本情報技術者試験を受けようかと思う人
  • 応用を受けようかと思うけど、基本が怪しい人
  • 猫が好きな人
Amazon.co.jpで『基本情報技術者』関連の本を見る

bana1 ブログ更新再開クリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 21:42│コメント(0)│トラックバック(0) 


March 17, 2010

情報はなぜビットなのか

情報はなぜビットなのか 知っておきたいコンピュータと情報処理の基礎知識
情報はなぜビットなのか 知っておきたいコンピュータと情報処理の基礎知識

キーワード：
　矢沢久雄、情報理論、入門書、コンピュータ史、偉人伝
日経BP社のなぜシリーズの、情報理論の入門書。以下のような目次となっている。
  1. 音声をデジタル化する
  2. 一筆書きの可否を判定する
  3. 最も儲かるようにお菓子を詰める
  4. 身の回りのデータを解析する
  5. コンピュータ とじゃんけんする
  6. どっちの手順がよいか判定する
  7. プログラムでパズルを解く
  8. 機械に言葉を解釈させる
  9. スイッチで計算を行う
  10. 情 報を表形式で整理する
  11. 情報伝達の仕組みを階層的に整理する
  12. コンピュータで社会貢献した人たち
(目次から抜粋)
本書のサブタイトルにあるとおり、情報処理の基礎知識が学習できる本で、『はじめに』で以下のような目的が示されている。
情報の表現方法と処理手順をはっきりさせるためには、どうすればよいのかをお教えするのが、本書の目的です。
（中略）
　本書を書く際に最も注意したのは、多くの知識を押し付けるのではなく、皆さんに「なるほど！」と思っていただけるポイントに的を絞ってお話しすることです。皆さんに身に付けてほしいのは、情報処理に関する「知識」ではなく「センス」です。センスとは、「わかっちゃったなぁ」「見えてきたよ」「スッキリしたぜ」といった感覚です。
(pp.2)
センスの説明がちょっと微妙な気もするが、本書は、コンピュータの情報処理全般を分かりやすく説明している内容となっている。

タイトルにある『情報はなぜビットなのか』の答えを簡単に説明すると、情報の最小単位が0，1のビット（bit）で表現されるから、となる。タイトルに合致する内容は1章部分だけで、正直タイトルが誇張的な気がしないでもない。

2章以降はグラフ理論とか待ち行列とか統計分析、E-R図、アルゴリズム計算量の話、チューリングマシン、論理回路、DBの正規化、OSI基本参照モデルなどなど、基本情報処理技術者試験レベルの内容が具体例とともに示されている。

この本の特筆すべきところは、コンピュータ史によく出てくる天才、偉人、例えばフォン・ノイマン、チューリング、ダイクストラ、アラン・ケイ、グレース・ホッパー、ケン・トンプソン、デニス・リッチーといった人たちの顔写真が載っているところだ。こういう偉人たちの名前はいろんな本でもよく見かけるが、実際に顔を見たことがなかったので、親近感が沸く。

情報理論全般についての網羅性はあるが、深さはあまりなく、基本情報を受けようかなと思っているけど、そこまでコンピュータ全般の基礎知識があまりないんだよねっていう人が読むとちょうどよいレベルで、かつそれなりに興味を持って読めると思う。しかし、自分の場合は、最低限の復習にしかならなかった。

『はじめに』に示されているようなセンスは本書を読んだだけで身に付くのか？と考えてみると、微妙かなと思った。深さがないので、ふーん、そうなんだぁ〜といった感覚で終わってしまう可能性が高い。もちろん最低限の考え方に触れることは重要だけど、探索アルゴリズムを実装してみるとか、DBならテーブル設計で正規化をやってみるなど自分の手と頭を使ったほうが確実にセンスは身に付くと思う。まぁ、本書はその入門に位置づけられるのだろうけど。

ちゃんと情報理論全般を学びたいなら、基本情報の良質な参考書を読んだほうがよいかなぁと思う。この本はむしろコンピュータ史、偉人伝として読むとよいのではないかと思った。どうせなら12章の『コンピュータで社会貢献した人たち』の内容を膨らませて1冊にすればよかったんじゃないかと思う。内容的には分かりやすくてよいと思うし。

そういえば、偉人伝の本として、『IT業界の開拓者たち』なんてものがあったけどどうやら絶版らしい。

IT業界の開拓者たちIT業界の開拓者たち
著者：脇 英世
販売元：ソフトバンククリエイティブ
発売日：2002-09
おすすめ度：3.0

いろいろとググってみたら、@ITで全内容が公開されていたので、偉人伝とか好きな人は暇つぶしに読んでみたらいいかも。

情報はなぜビットなのか 知っておきたいコンピュータと情報処理の基礎知識
情報はなぜビットなのか 知っておきたいコンピュータと情報処理の基礎知識
著者：矢沢 久雄
販売元：日経BP社
発売日：2006-09-07
おすすめ度：3.5

読むべき人：
  • 情報について考えてみたい人
  • 基本情報を受けようかと思っている人
  • IT業界の偉人の顔写真を拝みたい人
Amazon.co.jpで『なぜシリーズ』の他の本を見る

bana1 情報ビットクリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 22:13│コメント(2)│トラックバック(0) 


February 27, 2010

クラウドの衝撃

クラウドの衝撃――IT史上最大の創造的破壊が始まった
クラウドの衝撃――IT史上最大の創造的破壊が始まった

キーワード：
　城田真琴、クラウド、サービス、脅威、創造的破壊
野村総合研究所に所属する著者によって、クラウド・コンピューティングが分かりやすく解説されている本。以下のような目次となっている。
  1. 第1章 姿を見せ始めた次世代コンピューティング・モデル
  2. 第2章 雲の中身はどうなっているのか
  3. 第3章 ネット企業がリードするクラウド・コンピューティング
  4. 第4章 ICT業界の巨人たちはネット企業に追いつけるか
  5. 第5章 クラウド・コンピューティング時代の企業IT戦略
  6. 第6章 クラウド・コンピューティングで何が変わるのか
  7. 第7章 クラウド・コンピューティング時代へ向けて超えるべきキャズム
(目次から抜粋)
数年前からIT業界だけでなく世間をにぎわせている『クラウド』という言葉（バズワード）、なんとなく概要を知っているが、その特徴などの詳細についてはあまり知らなかった。IT業界でシステム開発業をやっている自分としては、さすがにその知識レベルではなんだかまずい気がする、ということで、クラウド・コンピューティングについて示されている本書を読んでみた。

結論から言うと、今後SI業のビジネスモデルそのものが大きく変わってしまうんじゃないかと思った。

まずは、そもそもクラウドって何？それってFF7の主人公となんか関係あるの？wwwっていうところから示しておこう。本書での著者なりの定義は以下のように示されている。
　「クラウド・コンピューティング」とは、拡張性に優れ、抽象化された巨大なITリソースを、インターネットを通じてサービスを提供（利用）するというコンピュータの形態である。

　このように書いてしまうと難しく感じるかもしれないが、簡単にいえば、インターネット上に雲のように浮かぶ巨大なコンピュータ群を必要に応じて利用できるコンピュータの形態が、クラウド・コンピューティングとなる。
(pp.15)
もうちょっと簡単にイメージするなら、雲のあちら側にサーバやサービスがあり、ブラウザを通して、利用者はその雲からサービスを自社内のシステムを利用する感覚で使用できるという感じかな。ポイントは、全部自前でシステムを作ったりする必要はなく、雲の向こうのサービスの利用分だけ使用料を払えばよいという形態である。

もうちょっと詳しい説明はWikipediaを参照するとよいかもしれない。まぁ、FF7の主人公とクラウド・コンピューティングには『雲』という単語の意味しか共通点はないwwwちなみに、スコール、ティーダも天気系の名前。どうでもいいことだが。

そして、このクラウド・コンピューティングは、以下の2つの特徴があるようだ。
  1. 高度なスケーラビリティ（拡張性）を持つ
  2. 抽象化されたコンピュータ・リソースである
1は、アクセス数の増加に伴い、コンピュータ・リソースを追加したいとき、利用者は契約先にリソースの追加注文をするだけでよいということになる。

2については、コンピュータ・リソースがどこのデータセンターにあり、どのようなマシンでどのような処理をしているかということが抽象化されており、ユーザーは気にする必要がないということらしい。

そして、クラウドの利用形態は一般的にXaaS（X as a Service）として以下の3つに分類されるようだ。
  • HaaS(Hardware as a Service：ハードウェア・アズ・ア・サービス)
    サーバのCPU能力やストレージなどのハードウェアをインターネット経由で提供するサービス(例：アマゾンの仮想サーバのレンタルサービス「アマゾンEC2(Amazon Elastic Compute Cloud)」や同じくアマゾンのストレージのレンタルサービス「アマゾンS3（Amazon Simple Storage Service）」など)
  • PaaS(Platform as a Service：プラットフォーム・アズ・ア・サービス)
    アプリケーションを稼動させるプラットフォーム機能をインターネット上で提供するサービス（例：グーグルの「グーグル・アップエンジン(Google App Engine)」、セールスフォース・ドットコムの「フォース・ドットコム(Force.com)など」）
  • SaaS(Software as a Service：ソフトウェア・アズ・ア・サービス)
    アプリケーション・ソフトウェアの機能をインターネット上で提供するサービス（例：セールスフォース・ドットコムのCRM/SFA、グーグルのGmailなど）
    (pp.29-30)
ここら辺はググッたらいろいろと出てくるので、もうちょい詳しく、と思う人は先ほどのWikipediaの記事とか見たらよいと思う。

全体像はこの辺にしておいて、以下、SI企業でSEをやっている視点から気になった部分を抜粋しておく。まずは『ネットベンチャー、個人の開発者には理想的な時代の到来』から。
　一方、ネット系のベンチャー企業や個人の開発者は、HaaS、PasSの利用に目を向けるべきだ。
（中略）
　ベンチャー企業や個人の開発者は、HaaSやPaaSを利用すれば、サーバやネットワークなどのインフラ部分の構築や運用に頭を悩ませることなく、これまでより圧倒的に少ないリソースで起業が可能となる。優れたアイディアがあり、プログラミングさえできれば、一攫千金も夢ではない時代がやってくるのだ。第2、第3のミクシィがクラウド・コンピューティング・サービスを利用する企業から生まれても何の不思議もない。
　グーグルやアマゾンのインフラをうまく使えば、日本だけでなく、海外でも活躍できるチャンスが広がる。
（中略）
　ネットベンチャー、個人の開発者にとっては、起業の障壁が従来に比べ、格段に下がる。まさに理想的な時代の到来といえるだろう。
(pp.179-180)
これは、もしかしたら自分にもチャンスがあるのではないか!?とまじめに思った。将来自分が独立するとしたら、何かサービスを作ってそれを基に起業するというイメージが漠然とあった。また、自分自身、こういうサービスがあれば便利なのにと思うものがいくつかあるし。

そして、人並み以上にプログラミングと英語ができるのだから、本気で一攫千金を狙ってみようかと思ったりもする。まぁ、この辺は要調査だね。まだAmazon EC2とかGoogle App Engineとかまったく分からないし。それでも挑戦してみる価値はあると思う。

さきほどの話は開発者個人の視点だったけど、次は、所属組織全体の話。『システム・インテグレータ、レンタルサーバ事業者のビジネスが変わる』から。
　最適なIT基盤の構築を売りにしてきたシステム・インテグレータにとって、PaaSは大きな脅威となる。セールスフォース・ドットコムやグーグルが提供するPaaSを顧客が使い始めると、自分たちのコアであったIT基盤の構築というビジネスが奪われてしまうだけではなく、システム稼動後の運用・保守といううまみのあるビジネスまで消滅してしまうからだ。
（中略）
　結果的に、これまでパッケージ・アプリケーションの導入をシステム・インテグレータに任せていたケースも含めて考えると、システム・インテグレータの出番は確実に減少する。
　とくにPaaSの利用シーンが増えると「最適なIT基盤の構築」というシステム・インテグレータの腕の見せ所が少なくなるということは避けられない。大手システム・インテグレータとしては、こうした状況に陥る前に、積極的に自社のノウハウが詰まった「IT基盤」をPaaSとしてサービス展開するという思い切った戦略も必要だ。
(pp.195-196)
ここの部分が一番『衝撃』だった。これはSI業のビジネスモデルが大きく変わるじゃないか!?そして、クラウドが主流になっていった場合、この波に乗れないSI企業は淘汰されるんじゃないか・・・。クラウド・コンピューティングの一番の脅威って、あるクラウドサービスがある業界の標準になったら、それが業界全体に使われることになり、それはつまりサービスの独占が可能になるということだと思う。

逆に言えば、いち早く業界標準をクラウドで作ってしまえば、そのサービス利用料で儲けられるチャンスがあるということだろう。

また、すべてがクラウドに置き換わるわけではないので、ミッションクリティカルでセキュアなものは依然としてフルスクラッチ開発になると思うが、その案件自体はまず少なくなるので、競争が激しくなり、そうなるとますますSIerの開発力、技術力が求められることになるなぁ。

さらに、今後単なる人月いくらという開発費で受注するビジネスモデルでもう儲けられなくなるんじゃないかなぁ。

ということで、以下湧き上がってきた疑問、課題を整理しておこう。
  • クラウド開発が主流になってきたら、開発者一人当たりの人月単価は下がるのか?
  • クラウドサービスの開発、もしくは導入支援に必要な技術、知識はカスタム開発のようなものと大きく違ってくるのか?
  • SE個人としてクラウド時代に身につけるべき知識、技術は何か?
ここら辺がまだ全然分かってないので、今後もっと勉強していきたい。

IT系雑誌、ネット、社内でもクラウド、クラウドと言っているので、さすがに自分もクラウドについて知る必要に迫られてきたので、この本を読んでみた。クラウド本はたくさんあるようだが、この本自体は、アマゾンでの評価が一番高かったので買って読んでみた。内容は、図解も多く、かなり網羅的に示されていて、評価の通りだと思った。

IT業界の人なら読み進めるのが難しいと感じることはあんまりないと思うが、普通の人ならどうだろうか。まったく無理ということはないだろうけど、ちょっとカタカナ語が多くて苦手という人にはしんどいかもしれない。

SIerの人やユーザー企業の情報システム部門の人は絶対この本を読んでおいたほうがいい。少なくとも、クラウドっていう単語が話題に上がったときに、FF7の主人公しか思いつかないということはなくなるから（笑）


クラウドの衝撃――IT史上最大の創造的破壊が始まった
クラウドの衝撃――IT史上最大の創造的破壊が始まった
著者：野村総合研究所 城田 真琴
販売元：東洋経済新報社
発売日：2009-02-06
おすすめ度：4.5

読むべき人：
  • クラウドの波に乗っていきたい技術者の人
  • ワンランク上の情報システム部門の人になりたい人
  • 『クラウド』からFF7の主人公しか思いつかない人（笑）
Amazon.co.jpで『クラウド』の他の本を見る

bana1 クラウド・ストライフ!?クリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 22:02│コメント(6)│トラックバック(0) 


February 20, 2010

Windowsはなぜ動くのか

Windowsはなぜ動くのか
Windowsはなぜ動くのか

キーワード：
　天野司、Windows、OS論、教科書、アーキテクチャ
日系BP社から出版されているなぜシリーズのWindows解説書。以下のような目次となっている。
  1. 第1章 Windowsが使われるワケ
  2. 第2章 オペレーティング・システムとは
  3. 第3章 Windowsとは
  4. 第4章 マルチタスクのふしぎ
  5. 第5章 マルチウィンドウのふしぎ
  6. 第6章 ハードウェア・サポートのふしぎ
  7. 第7章 プログラム連携のふしぎ
  8. 第8章 ネットワークのふしぎ
(目次から抜粋)
この本は、Windowsが内部でどのように動作しているかをイメージしやすいように解説されている。DOSから始まったMicrosoftのOSがWindowsへとどのように進化してきたのかがよく分かる内容となっている。

1章、2章は読み物的な内容だが、4章あたりからメモリ内部の動作などが解説されており、入門書的な位置づけとはいえ、かなり難しめの内容だと思う。タイムシェアリングシステムとか、割り込み処理とかDDLなどが解説されている。まったくOSの基礎知識がない人がこれを読むと、4章で挫折する可能性が高い。自分もちょっと怪しかった（笑）

以下、教科書の用語解説的に自分の気になったものを列挙しておく。
  • システム・コール・・・OSの上で動作するアプリケーション・ソフトや、あるいはOS自体、その内部から呼び出し可能になっているOSの機能のこと
  • ライブラリ・・・アプリケーションの中に組み込まれて、アプリケーション自身がそれを実行するもの
  • リロケート・・・プログラムやデータが置かれるアドレスが変化すること
  • ディスパッチ・・・OSが各アプリケーションの処理を振り分けつつ少しずつ実行させるような機能のこと
  • ウィンドウ・システム・・・ウインドウ表示だけを専用で行うプログラムのこと
  • Windowsオペレーティング・システム・・・OSのシステム・コールの一部としてウィンドウ・システム関連の機能を取り込んだものの一括した総称
  • イベントドリブン（イベント駆動型）なプログラム・・・ユーザーがキーボードを操作するとか、マウスを操作するといった操作（イベント）の後に続く形で動作するプログラムのこと
  • マルチスレッド・・・一つのプロセスの中に複数の実行単位を配置する方式で、一つのプロセスの複数箇所が並列に実行されるもの
この本は、Windowsアーキテクチャの解説が主な内容だが、他のOS、例えばUnix系のOSの解説にも当てはまるようなことが結構ある。逆にWindows特有の解説がされているのは、4章のDDLの解説、6章のプラグ&プレイ、７章のクリップボードの仕組みなどが該当する。

8章のネットワークは、別にWindowsに限った話ではなく、ネットワーク通信の基礎的な内容となっている。

特に勉強になったのは、16ビットWindowsと32ビットWindowsの違いの解説について。以下その部分を抜粋。
　16ビットCPUや32ビットCPUはCPUの性能を表す言葉としてよく使われていますが、この言葉が意味するのは、CPUが処理を行う最小単位である「レジスタ」のサイズが16ビットであるか、32ビットであるかのところからきています。たとえば、16ビットCPUであれば、一度に扱える数は2の16乗である65536までであり、32ビットCPUであれば2の32乗、すなわち約42億までの数値を一度に扱うことができます。
　ただ16ビットCPUと32ビットCPUの違いは、この「扱えるビット数」の違いに留まりません。というのは、扱えるデータサイズや量が増えれば、それに見合うだけ機能も高度化してきますし、一度に大量のデータを処理できるようになることから、処理速度も高速化されます。つまり16ビットCPUと32ビットCPUとでは、扱えるデータ量の違いはもちろんのこと、処理速度も段違いですし、また利用できる機能も高度化されているのです。
(pp.51)
16ビットCPUのWindowsは、Windows1.0から3.1までらしい。32ビットはXPまでと示されている。

この本は2002年初版発行なので、XP以降のVista、7についてはまったく示されていない。よって、64ビットOSなどについての解説もないが、16ビットと32ビット対応OSの比較の説明と同じになる。

Windows 7が発売されて、32ビットOS、64ビットOSの両方のバージョンがあり、何が違うんだろうか？と思っていたけど、この本を読んでその違いが何によるものかよく分かった。間違っても64ビットOSのほうが32ビットOSより2倍の性能があるということではない（最初見たときは、へー処理速度が2倍なんだなぁ〜とか思っていた（笑））。一度に扱える数値が2の32乗か2の64乗かの違いで、1,844京6,744兆737億955万 1,615　÷　43億　倍あるということになる。

350ページ近くあるので、結構簡単に読み進められない。一応OSの基礎知識はあったけど、1日1章というペースで読み込むのもちょっときつかった。まだまだ技術本に読みなれていないからだろうけど・・・。

Windows7が発売されている昨今だから、DOSからのOSの仕組みを理解してみるのもよいかと思う。自分の場合は、Windows系技術のエキスパートになるために、今回読んでみた。結構知らない部分が多いということが分かった。

また、この日系BP社のなぜシリーズで、過去に取り上げたのは以下になる。まだなぜシリーズをすべて読んでいないので、徐々に読んでいきたい。


編集後記っぽいもの

たまには編集後記を。最近はTOEIC対策付けだったので、更新が滞りがちだった。今年に入って1月31日、2月13日と受験した。結果はまだ明らかになっていない。次回受験は3月14日になる。

また、4月18日に応用情報技術者試験を受ける。そのため、技術本が多めに更新されると思う。あれ、去年も受験していなかったっけ?と思った方、そんなあなたはこの読書ブログのコア読者（笑）。まぁ、去年の春に受けてみたら、午前問題が3点足りなくて足きりをくらって落ちた・・・。

どうも合格最低点の6割狙いでいくと、凡ミスで合格点に届かないということが分かったので、今度は最低8割狙いでいく(`･ω･´) ｼｬｷｰﾝ


Windowsはなぜ動くのか
Windowsはなぜ動くのか
著者：天野 司
販売元：日経BP社
発売日：2002-10-28
おすすめ度：4.5

読むべき人：
  • Windowsアーキテクチャに関心がある人
  • Microsoft系技術のエキスパートになりたい人
  • 64ビットOSって何？と思う人
Amazon.co.jpで『なぜシリーズ』の他の本を見る

bana1 Windows OSクリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 22:39│コメント(0)│トラックバック(0) 


January 28, 2010

The Twitter Book

The Twitter Book
The Twitter Book

キーワード：
　Tim O'Reilly / Sarah Milstein、Twitter、入門書、ビジネス利用
Twitterの基本的な使い方から企業利用まで示されている本。オライリーの洋書で、以下のような目次となっている。
  1. Get Started
  2. Listen In
  3. Hold Great Conversations
  4. Share Information and Ideas
  5. Reveal Yourself
  6. Twitter for Business: Special Considerations and Ideas
(目次から抜粋)
この本は2009年6月出版らしい。まだ日本語訳は出版されていないようだ。たまたま、Amazonでこの本を発見し、その後リアル書店のオライリー洋書コーナーに立ち寄ったらこの本があったので、中身を見てみたらまったく読めないこともないと思ったのでがんばって読んでみた。

最近いろいろとTwitter本が出版されているが、この本は洋書、かつ技術者ならみんな読んでるオライリー本なので、まだ書評はどこにも取り上げられていないようだ。

まずは著者の紹介から。著者は、以下のお2人。オライリー社CEOのO'Reilly氏自ら書いているようだ。もう一人のSarah氏は、以前オライリーに勤めていたライターらしい。この2人によって、Twitterの登録方法など初歩的なところから、投稿方法、RTの方法、便利なTwitter関連のサイト紹介、さらにはユーザー同士のコミュニケーションを円滑にする方法、Twitterの企業利用するときに気をつけたほうがよいことなどが示されている。

特になるほどと思った部分について紹介することにする。

まずは、なぜ140字制限であるのかという部分に関して、以下のように示されている。
By the way, posts on Twitter are capped at 140 characters for a reason: text messages on your phone are limited to just 160 characters. Twitter takes base and reserves 20 characters for usernames, leaving you with a tidy 140.
(pp.33)
これは確かTwitterの公式ページにも載っていると思うが、携帯電話が160文字制限で、ユーザー名の確保のために20字使用するので、残り140文字しか使用できないことによるらしい。そして、英文の140文字ぴったりの文章として、以下のようなものが示されていた。
This unusually helpful sentence, including all of the spaces and all of the punctuation, is precisely one hundred and forty characters long.
(pp.32)
これを訳すと、『すべてのスペースと句読点を含めて、この一風変わった役立つ文は、ぴったり140字の長さになる。』となり、文字数は46文字となる。英語と日本語では、同じ意味を表すだけでここまで文字数差が出るようだ。

英文の140文字相当は、日本語だと50文字くらいらしいので、改めて日本語のつぶやきはかなり冗長だなと思った。

また、3章の『 Get great followers 』というトピックでは、よりよいフォロワーを形成するために以下の3つのポイントが示されていた。
  1. Be interesting. The best way to become popular on Twitter is to post messages that other people want to read, retweet and respond to.
  2. Be conversational. Engage with people, whether they're already following you or not. People like it. Plus, when prospective followers hit your Twitter account page, they'll see you're a friendly, thoughtful person.
  3. Follow relevant people. If you follow somebody, there's a good chance she'll follow you back. Use the tips in Chapter 2 to find people who are interested in the same sort of topic you are and follow them. It's the first step in building a relationship.
    (pp.43)
それぞれを簡単に訳すと以下のようになる。
  1. 興味深い存在となりましょう。Twitterで人気者になる一番よい方法は、他の人が読みたくなったり、リツイートしたり返信したくなるようなメッセージを投稿することです。
  2. 対話的な存在となりましょう。他のユーザーがあなたをフォローしていようとなかろうと、その人たちと話がかみ合うようにしましょう。人々はそのような状態を好みます。さらに、フォロワーになりそうな人があなたのTwitterアカウントページにたどり着いたとき、あなたのことを友好的で思慮深い人だと判断するでしょう。
  3. 関連するユーザーをフォローしましょう。もし、誰かをフォローした場合、そのフォローした人がフォロー返しをしてくれるかもしれないチャンスとなります。チャプター2のTipsを使って、あなたと同じような話題に関心がある人を見つけて、彼らをフォローしましょう。それが関係を築く最初のステップとなります。
まぁ、自分もTwitterをやってきた経験上、特に1,2が重要かなと思う。あまりにも独り言になりすぎていると、誰もフォローしてくれない可能性がある。

とはいえ、つぶやくことすべてが誰かにとって価値のあるものであったり、面白いものでなければいけないということはないと思う。そうなると、気軽につぶやくことができなくなると思う。気軽さがTwitterの大きな特徴なんだからね。まぁ、バランスが重要なんだと思う。また、そもそも何を目的としてTwitterをやるかにもよると思う。

また、RT、つまりRetweetに関して、RTよりもviaを使ったほうがよいときがあると示されていた。RTはクライアントソフトなどを使えば簡単にできてしまうため、あまりにもRTをしすぎるとタイムラインをノイズに変えてしまう可能性がある。

そのため、単純に他の人のつぶやきをRTするよりも、なぜそのつぶやきを広めるに値するか？などの自分なりのコメントを元発言者のクレジットを示しつつviaを使って付与したほうがよいとあった。以下のような感じで。
  • "Yadda Yadda Yadda http://someURL (via @OriginalPosterName)."
これはなるほどと思った。まぁ、この本で示されているviaの使い方がQTに相当するんだと思う。ちなみに、上記の本で示されている『Yadda Yadda Yadda』はググったら、『なんとかなんとかなんとか』って意味らしい。初めて知った。

この本が出版されたのが去年の6月なので、出版当時は公式RTの機能はまだなかった。現在は公式RTも使用できるようになり、よりRTがやりやすくなっているので、これは特に重要かなと思った。

いまいち、RTについてイメージしづらいという人は、以下の記事がとても参考になる。特にTwitterをやり始めたばかりの人は、一度は見ておいたほうがよい。

他にも5章では、プロフィール欄を充実させておけば、どんな人かわかりやすいし、また、アイコンは、なるべく顔写真がよいといったことや、背景画像もカスタムスして自分自身を演出しましょうということが示されていた。

6章は、企業がビジネス目的でTwitterを使うために気をつけたほうがよいことが示されていた。簡単に重要部分をまとめると、以下のようになる。
  • 企業情報を一方的に投稿するのではなく、@を使ってユーザーと対話的な内容を投稿すること
  • 顧客となるユーザーと親密な関係を築くためにも企業組織といった単位ではなく、投稿者が誰か分かるように担当の名前や顔をプロフィールや背景画像に設定したほうがよい
  • 自分の企業情報のことばかりを投稿するのではなく、人々が興味を引くほかのサイトのリンクなどを含めた内容を投稿するとよい
  • 属人的な部分を示して、顧客と良好な関係を築くためにも、時には投稿者の個人的なこと（例えば、家族のことだったり日常的なことなど）を投稿するとよい
  • フォローされたアカウントに対してフォローを返すと、対話的な態度を示すことになるのでよい。また、それによってDMが可能になり、カスタマーサポートとして利用できるようになる
こんなところかな。自分も企業アカウントをいくつかフォローしているけど、ボットのように投稿していると思われるものよりも、投稿している人のパーソナリティが見えるアカウントのほうが興味を持ってフォローできる。例えば、ぐるなびとか。まだまだ企業もTwitterの可能性を模索している段階だと思うので、企業担当者はぜひこの6章を読んだほうが良いと思う。

入門書的な内容かと思ったら、結構コアなことやTips、ユーザーの検索に便利なサイト、最近話題になっているものを調査するときに役立つサイト、企業利用の方法などまで示されていて、参考になる部分が多かった。

最近発売されている新書のTwitter本は全然未チェックだけど、きっと違った内容が示されているんじゃないかと思う。ただ、去年の6月出版なので、リスト機能や公式RTについては示されていない。

去年の8月ごろからちょっとづつ読み進めて、やっと読み終わった。ページ数は200ページで、左のページはTwitterの画面ページで、右のページがその内容の解説という構成となっている。なので、実質100ページちょっとの内容となっている。1ページ大体5分くらいかかるとして、まぁ、500分、8時間くらいで読めるんじゃないかと思う。

オライリーのページを見ても、この本が翻訳される様子はまだなさそうなので、英語が得意な人は読んでみるとよいかも。どうでもいいことだが、初めてオライリー本を最初から最後まで読み通した。コアな技術者ならもっとごつい本をたくさん読んでいるようなものだけどね・・・。

自分がTwitterを始めたのは去年の8月からで、この投稿時点でTwitter歴は179日目になるようだ。まだまだ使い方を模索しているような段階かな。個人的にはこの読書ブログとTwitterをもっと連携させられたら面白いかなぁと思う。

例えば、ブログに投稿するまでもないおススメ本をお知らせしたり、対話的にフォロワーからおススメ本で何かないかといった質問に答えたりとか。

あと、自分のTwitterアカウントは以下になります。お気軽に、follow(or unfollow)どうぞ

ところで、昨日、めでたく26歳となりましたTwitterをやっていてよかったなぁと思ったのは、リアルでお会いしたことのある人、そうでない人からも祝福の言葉をたくさん頂いたことです。Twitterをやってなかったらこんなことはありえませんでした。

この場を借りてお礼申し上げます。ありがとうございました


The Twitter Book
The Twitter Book
著者：Tim O'Reilly
販売元：Oreilly & Associates Inc
発売日：2009-05-26

読むべき人：
  • Twitterの概要を知りたい人
  • 企業のTwitter担当者の人
  • 洋書×オライリーのTwitter本に挑戦したい人
Amazon.co.jpで『Twitter』の関連の本を見る

bana1 The Twitter Book Follow Click☆ 　にほんブログ村 本ブログへ

type5w4_lion at 22:56│コメント(4)│トラックバック(1) 


October 31, 2009

The Road Ahead

"The Road Ahead": Level 3 (Penguin Readers Simplified Texts)
"The Road Ahead": Level 3 (Penguin Readers Simplified Texts)

キーワード：
　Bill Gates、コンピュータ史、Microsoft、自伝、インターネット
いわずと知れた、Microsoft創始者、ビル・ゲイツの本。以下のような内容となっている。
Bill Gates, the richest man in the world, started Microsoft in 1975 with a friend when he was only nineteen years old. Twenty years later he wrote this book about the future of computers and the Internet. Read the ideas and dreams of a man who has changed the world.
(カバーの裏から抜粋)
また、目次は以下のようになっている。
  1. Introduction
  2. Special Words You Will Meet in This Book
  3. Chapter 1　The First Part of the Road
  4. Chapter 2　Beginnings
  5. Chapter 3　Some Things Computers Can Do forUs
  6. Chapter 4　Changes in Information Systems
  7. Chapter 5　The World of Business
  8. Chapter 6　Markets and Money
  9. Chapter 7　Education in the Future
  10. Chapter 8　A Home for the Future
  11. Chapter 9　The Internet "Gold Rush"
  12. Chapter 10　Moving into the Information Age
  13. Activites
(目次から抜粋)
この本は、1995年、Windows95が発売された年に発表されたものを、ペンギンリーダー用に平易な文章に再編纂されたものとなる。Level3で主要語は1200。ちょうど、本屋で何かおもしろそうなものがないかと思って探していたら、ゲイツの本があったので、買って読んでみた。

内容的には、1995年当時、ビル・ゲイツが考えていた"Information Highway"について示されている。そこにはコンピュータ、システム、さらにはインターネットの可能性によってビジネスや教育、生活が大きく変わっていくだろうということが示されている。

この本を読むにあたって、出版からおよそ15年経ち、Windows7が発売されているような現在において、ビル・ゲイツの構想がどこまで実現しているのか？と考えるとおもしろいと思った。
　When we talk about this new system, we call it the Internet. This book will try to answer questions about the future of the Internet – what it will be like, and how we will use it. Sometimes when we talk about the future of the Internet, we call it the "Information Highway."
(pp.1)
Chapter4では、ビル・ゲイツは子供のころ、百科事典を読むのが好きだったというようなことが示されていた。そこで、ゲイツは紙の重要性はなくならないが、紙に変わる電子媒体で情報が多くやり取りされると示している。

そして、この当時MicrosoftはEncalta(エンカルタ - Wikipedia)を発売していたようだ。しかし、現在では百科事典といえば、Wikipediaが広く使われていると思う。実際にエンカルタをWikipediaで見ると、今年の3月31日にサービスを終了するみたいだ。これは、ネット上の百科事典がスタンドアロンPCに入っている電子百科事典に取って代わったということだろう。現在は、ゲイツの構想よりさらに進んでいるだと思われる。

他にもインターネットでアイディアを共有できると示しており、その例として、electronic bulletin board、つまり電子掲示板を挙げている。電子掲示板に投稿すれば、たくさんの人にメッセージを送れると示している。これも現在では、2chなどはまだ健在だが、掲示板よりもさらに進んだ（!?）twitterが出現している。

95年ごろにゲイツが予想した未来よりも、現在はだいぶ進んでいるんだなぁと思った。いわゆるドッグイヤー的な発展を遂げているみたいだ。

一つへーと思ったのは、Microsoftの社名の由来について。それが示されていた。
　It took us five weeks of hard work, but in the end we did it. We had a program for the Altair and we had something more. We had the world's first company that wrote programs for microcomputers. In time we named it "Microsoft."
(pp.3)
マイクロコンピュータに世界ではじめてプログラムを書いた会社だから『Microsoft』となったらしい。ビル・ゲイツが19歳のときで、その後忙しくなってハーバード大学を中退したようだ。なるほどなぁと思った。社名の由来は、案外知っているようで知らなかった。ちなみにAltairは世界最初の個人向けのPCらしい。世界ではじめてのプログラミングって、ワクワクするんだろうなぁと思った。また、Microsoftは今や帝国と言われるほどの巨大企業だけど、最初はベンチャーから始まったんだよなぁと思った。

ちょっと一般的ではない技術用語は、『Special Words You Will Meet in This Book』の章に説明がある。BINARY SYSTEMとかCONTROL CONSOLEとかHACKERとかLAPTOPとかSOFTWAREとか。

割と簡単な英文で、35ページしかないのでさくっと読める。通勤電車の中で読んだので、数日はかかったけど。あんまりMicrosoftやWindowsのことは書いてないので、読む気が失せるということはないと思う（笑）

この本を読んでいて、どこかで読んだことのある内容だなと思って調べてみると、大学時代に図書館で読んだ本だった。それは、『ビル・ゲイツ未来を語る』という本だった。こちらは500ページ越えの本で、18歳のときに読んで、世界一の金持ち（当時）っていろいろと考えているんだなぁと感心した記憶がある。

ビル・ゲイツ未来を語るビル・ゲイツ未来を語る
著者：ビル・ゲイツ
販売元：アスキー
発売日：1995-12
おすすめ度：5.0

IT技術者の人なら興味を持って読めるのでお薦め。Windows7も発売されたことだし。


"The Road Ahead": Level 3 (Penguin Readers Simplified Texts)
"The Road Ahead": Level 3 (Penguin Readers Simplified Texts)
著者：Bill Gates
販売元：Penguin
発売日：2008-02-21
おすすめ度：5.0

読むべき人：
  • 技術英語を読む訓練をしたい人
  • ビル・ゲイツに興味、関心がある人
  • プログラマーなどのIT技術者の人
Amazon.co.jpで『ビル・ゲイツ』の他の本を見る

bana1 William H.Gates IIIクリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 11:13│コメント(0)│トラックバック(0) 


September 25, 2009

SEのための「構造化」文書作成の技術

SEのための「構造化」文書作成の技術
SEのための「構造化」文書作成の技術

キーワード：
　佐藤健、SE、ライティング、ドキュメント、構造設計
現役のエンジニアによって、構造を考えて書く方法が示されている本。技術本は目次が超重要箇所なので、多めに抜粋。
  1. 第1章 書くということ
    1. 1.1 技術文書の問題点
    2. 1.2 技術文書の種類
    3. 1.3 テクニカルライティングとは
    4. 1.4 読解力から「書く力」へ
    5. 1.5 書くことで頭を整理する
    6. 1.6 「 書く力」をビジネスの武器に
  2. 第2章 文書のプランニング
    1. 2.1 文書作成のステップ
    2. 2.2 プランニング工程の作業
    3. 2.3 メッセージを明確にする
    4. 2.4 アブストラクトの書き方
    5. 2.5 文書タイトルの付け方
  3. 第3章 材料の収集
    1. 3.1 材料収集工程の作業
    2. 3.2 日常生活での心構え
    3. 3.3 Webの活用
  4. 第4章 文書の構造設計
    1. 4.1 構造設計工程の作業
    2. 4.2 文書の構造化
    3. 4.3 演繹法と帰納法の活用
    4. 4.4 文書の構造を決める
    5. 4.5 目次の作り方
    6. 4.6 パラグラフを意識する
  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 執筆ルールの作成
  6. 第6章 文書の推敲
    1. 6.1 推敲工程の作業
    2. 6.2 推敲のチェック項目
    3. 6.3 推敲の事例
    4. 6.4 ビジュアル表現の工夫
  7. 7章 文書作成技術の応用
    1. 7.1 要求仕様書の書き方
    2. 7.2 システム提案書の書き方
    3. 7.3 マニュアルの書き方
    4. 7.4 調査レポートの書き方
    5. 7.5 小論文の書き方
    6. 7.6 論文の書き方
    7. 7.7 論文試験問題の書き方
  8. 付録
    1. 付録1 英文マニュアル作成から学ぶ
    2. 付録2 電子メールの書き方
    3. 付録3 演習問題
    4. 付録4 演習問題解答例
(目次から抜粋)
目次を見ると、大体どんなことが書いてあるか想像できると思う。一応、この本の概要を簡単に紹介しておく。

この本の目的は、IT技術者に書く力を身につけてもらい、よりすばらしい成果を出していただくこととある。文書作成の肝は、いきなり闇雲に書き始めるのではなく、事前にプランニングし、書きたいことを構造化してから書くべし、とある。

この本はかなり勉強になることが多く示されており、どこを紹介するべきか迷ってしまう。

まず、この本で示されているテクニカルライティングとは何かを紹介しておく。

テクニカルライティングとは、技術的な内容をわかりやすく、かつ正確に書くための技術であり、以下のポイントがあるようだ。
  • テクニカルライティングは、技術文書を書くための手法である
  • テクニカルライティングは、ビジネス文書にも応用できる
ビジネス文書にも応用できるというのがポイントとなる。

また、文書を「書く力」は、読解力を身につけることで身につき、同時に書くために思考する過程で思考力が身につき、それが読解力にもなると示されていた。この関係は、このような読書ブログを3年以上やってきた経験から、納得できるものである。

「書く力」について、なるほどと思った部分があるので、以下に引用。
　「書く力」は、その基になる読解力や考える力が付かないとうまくいきません。コンピュータにたとえれば、読解力は入力装置であり、考える力は処理装置であり、「書く力」は出力装置です。これらの装置がうまく連携することにより、より良いアウトプットが生まれることになります。
　物事をうまくまとめ、うまい文章をまとめることができるということは、1つの大きな能力です。優れた能力を身に付けることは、人生における1つの「武器」になりえます。ものを書くのが苦手な人が多いので、これは大変貴重な力です。
(pp.32)
普段何気なくこの読書ブログを更新していたり、仕事で設計書などを作成しているが、これはあまり意識したことはなかった。また、以下もなるほど思った。
　仕事の成果は、表現されたもので測られます。日常のビジネスの場では、報告書、記録、議事録、メモ、メールなど、書いた結果で、相手はその成果を推し測ります。書く力には、書くべき内容を作り出す力が必要です。さらに、その書いたものを相手に伝えるコミュニケーション能力も必要です。「書く力」を持っているということは、ビジネスにおいて、最強のツールを持っていることだといえるでしょう。したがって、この能力をビジネスの「武器」といってもよいと思います。
(pp.38)
自分はかなり「書く力」を意識的に身に付ける努力をしてきた。それがビジネスにおいて、最強のツール、「武器」になりえるというのは、自分のやってきたことが間違いではなかったということになる。
　
ウェブやブログ、メールが発達した現在では、昔よりも書く量が格段に多くなっていると思う。しかし、書くことの気軽さに反して、実際に読むに耐えうる文章が示されているものはそんなに多くはない。誰でもなんとなく文章を書いているような状況ではあるが、本当に価値ある成果物としての文章は、真に「書く力」に裏打ちされたものによって作成される。そういう「書く力」は、このような本を読んで意識的に磨かないと、なんとなく書いているだけでは絶対に身に付かないと思う。

また、『SEと文書作成』では、以下のように示されていた。
　ビジネスで「書く力」を最も必要としているのは、SEといってもよいでしょう。SEには単に文章を書くだけでなく、それにより、ユーザに説明を行い、納得させて、仕事を請け、それを完成させるという業務があります。システム提案書、アプリケーションシステムの仕様書、報告書、議事録、成果発表資料など、作業のあるところには必ず文書作成が伴います。ユーザに理解してもらい、行動をとってもらうためには、納得できる、理解しやすい文章が必要です。若いSEにこそ、「書く力」をビジネスの武器にしてほしいと思います。
(pp.40)
SEとなると、プログラムを書くよりも設計書やマニュアル、提案書などを書くことが多くなってくると思う。これはかなり実感するところで。なので、上司や偉い人には、日本語作成能力、つまりテクニカルライティング能力がかなり重要になるからしっかり磨いておけと言われたりする。そのため、文書作成能力がそのままSEの能力を反映するといっても過言ではないと思う。

自分の職業がSEということもあり、ライティング能力の獲得は必須ということになる。そういうこともあり、この読書ブログではキャッチフレーズの羅列ではなく、ちゃんとした文章を書くようにしている。その訓練を入社直後から3年半近く行ってきたので、ライティングにはそれなりに自信がある。実際プロジェクト先ごとに、自分の書いた成果物がかなりほめられたりする。

この本では、文書作成のステップは、プログラム開発のステップと考え方が似ていると示されている。
  1. プランニング
  2. 材料収集
  3. 構造設計
  4. 執筆
  5. 推敲（見直し）
上記の5ステップが、プログラム開発工程の各ステップ、1.プランニング（基本設計）、2.機能設計、3.詳細設計、4.コーディング（製造）、5.検査に対応するようだ。これはなるほどなぁと思った。特に重要なのは、主題を選定する、文書の目的を明確にする、誰が読むのかを明確にするといった、最初の工程のプランニングらしい。また、各工程の詳細は、実際に読んで確かめてほしいと思う。

執筆時に気をつけなければいけない具体的なことも多く示されている。文章は短くするとか、できるだけ能動態で書くとか、読点をなるべく多めに使用するべきとか。それらを読むと、自分ができている部分とできていない部分がはっきりわかる。文章を短くするとか、あまりできていない・・・。ついつい長くなりがちだ。

さすがにわかりやすい文書の作成指南本であるので、かなりわかりやすい内容だと思う。技術系の本は、翻訳本ではないのに1回読んだだけでは頭に入らないものがたまにあるけど、この本はそんなことはまったくない。ダメな例を改善したり、図解も多く示されているので、よい内容だと思う。

「書く力」は、大きな武器になるということがわかってよかった。また、もともと書くのが好きだというのもあったり、将来は本を書こうと思っているので、自分の「書く力」をもっと磨いていきたい。

IT技術者の人は、買って読んで損はないと思う。案外普段書いている文章は、自分ではわかりやすいと思っていても、そうではない場合が多いので。

他にもライティングに関する本は、以下のものがお薦め。どれもわかりやすいし、すぐに役立つ内容である。


SEのための「構造化」文書作成の技術
SEのための「構造化」文書作成の技術
著者：佐藤 健
販売元：技術評論社
発売日：2008-10-18
おすすめ度：4.0

読むべき人：
  • SEなどの技術者の人
  • 文章を書くのが苦手な人
  • ビジネスで最強の能力を身につけたい人
Amazon.co.jpで『文書作成』関連の他の本を見る

bana1 最強の武器獲得クリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 22:39│コメント(1)│トラックバック(0) 


August 28, 2009

エンジニアのためのWord再入門講座

エンジニアのためのWord再入門講座 美しくメンテナンス性の高い開発ドキュメントの作り方
エンジニアのためのWord再入門講座 美しくメンテナンス性の高い開発ドキュメントの作り方

キーワード：
　佐藤竜一、Word、ドキュメント、エンジニア、スタイル
Wordを使用し、読みやすくてメンテナンス性が高いドキュメントの作成方法が示されている本。以下のような目次となっている。
  1. 第1章　 ドキュメント作成の意味とは
  2. 第2章　 これだけはやっておきたいWordの初期設定
  3. 第3章　 スタイルを理解することから始めよう
  4. 第4章　 DRYで行こう!
  5. 第5章　 テンプレートを設計する
  6. 第6章　 図と表の取り扱い
  7. 第7章　 チームでの作業を効率化する
(目次から抜粋)
システムエンジニアが仕事で設計書などのドキュメントを作成するときに、なぜかWordではなく、Excelを使用したりする。そのときは、Excelのセルを正方形にし、方眼紙のように使うことがある。しかし、本書ではそんなドキュメントは見た目が悪いし、改行処理などのメンテナンス性が著しく低下するので、まともなドキュメントではない、と示されている。

そして、この本の著者の主張を一言で強烈に!?示すと、以下のようになる。

EclipseやEmacsを自分専用にバリバリカスタマイズするくせに、Wordは初期設定のまま使用し、しかもスタイルの機能もうまく使いこなしていない品質の低いドキュメントを作成していて、プロのエンジニアとして恥ずかしくないのか!!

ということだと思った。いやー、この本を読んで、いかに自分がWordを使用したドキュメント作成ができていないかがよくわかった・・・。自分の今までのドキュメント作成方法は、ぜんぜんダメじゃないか!!と思った。

この本で示されている内容は、『読みやすく、体裁が整っていて、メンテナンス性も高いドキュメントを、より短い時間で作成するための技術と考え方 (pp.iii)』とある。そして、本書では、ドキュメント作成にWordを使用することを薦めている。なぜWordかは、以下のように示されている。
　その理由は簡単です。現在のシステム開発の現場で、おそらくWordはもっとも広く使われているワープロだからです。少なくとも、大多数の開発者が使うPCには、Wordの何らかのバージョンがインストールされていることが期待できます。
　本書の説明は、その大部分がWordに特化したものです。Wordの機能の説明に終始してしまっている章もいくつかあります。しかし本書で最もお話したいことはWordの使い方ではなく、Wordを使ううえで、そしてよいドキュメントを作成するうえでの背後にある考え方です。すべてではありませんが、それらの考え方のいくつかは、他のソフトウェアにも応用できるはずです。
(pp.025)
Wordで設計書などのドキュメントを作成する理由は、それらお客様への納品成果物をWordで、と指定されることが多いからという側面もある。また、複数SI企業が参画する大規模プロジェクトでは、各社が独自のソフトを使うと他社にドキュメントを展開するときに困るので、やはりWordが使われる。このような側面からも、Wordでメンテナンス性の高いドキュメントを作成できなければならないということだろう。

本書では、よいドキュメントとは、ドキュメントにまつわるコストを最小化できるものと示している。そして、よいドキュメントは、以下の3つの条件を満たすものだとある。
  • 読みやすい
  • 体裁が整っている
  • メンテナンス性が高い
まずは、内容よりも見た目が重要、ということらしい。見た目が悪いと、読む気が起こらないからということになる。これはブログの文章でも同じだと思う。だらだらと長文で空白や改行がまったくないものだと、開いた瞬間に読まれることなくスルーされる。

また、メンテナンス性が求められるのは、完成したシステムにメンテナンスが必要なように、ドキュメントも同じようにメンテナンスが求められるからとある。つまり、変更されたシステムの内容を、ドキュメントにも同じように反映するために繰り返し改訂・追記がされるので、ドキュメントのメンテナンス性が低いと、いずれ陳腐化して役に立たないものになってしまうからとある。これはもっともだなぁと思った。

Wordなどのワープロでやってはいけない例が以下のように示されている。
  • 「段落」という考え方を理解しない
  • 改行を「行の区切り」だと認識する
  • 段落の先頭に1文字の全角空白を入れる
  • スペースでドキュメントの整形を行う
  • 箇条書きを実現するために手で「・」を打つ
  • 手で連番を打つ
どれもやったことありすぎで、自分のWordの使いこなし度がよくわかってしまう・・・。これらは、すべてメンテナンス性を損なう方法なので、Wordの機能として用意されている『スタイル』を使用してドキュメントを作成するべきとあった。

スタイルを使うことの最大のメリットは、ドキュメントの各構造の外観を、常に同一に保つことができるとあった。そのため、「選択した領域のフォントを手で変更する」とか「ルーラーで個別にインデントを付けを行う」といったことはする必要がなくなるし、著者によれば、高機能ワープロがあるのにそれらのことを行うのは、職務怠慢に等しい行為とあり、かなり耳が痛い・・・。

この本を読むと、自分がいかにダメなドキュメント作成者であるかを思い知らされた・・・。ついつい簡単なドキュメントはExcelで作ったりするし、Wordを使うと、ルーラーで行位置をいじったり、空白を多用しすぎたりと、反省することばかり・・・。

WordはWYSIWYGなワープロソフトなので、あんまりWordの機能を深く知らなくても表面的に使いこなしているようには見える。しかし、ドキュメントのメンテナンス性を考慮するには、スタイルやフィールド、テンプレート、図表の取り扱いをしっかり理解しなければならないようだ。

案外自分はWordの機能を深く理解していないなということがわかった。特にスタイルとかまったくいじったことがなかった。他にもフィールドの機能とか。以下のように表中にフィールドを設定すると、Excelのように簡単な計算ができるたりする。

フィールドのサンプル

平均列と合計行の設定をフィールドで実現している。Excelの関数とは違い、Wordのフィールド独自の関数が用意されているようだ。そして、フィールドの計算結果を反映させると以下のようになる。

フィールドのサンプルの計算結果

Wordにこんな機能があるとは知らなかった。フィールドは一般的に、文章中に他の部分を引用するときに使うらしいが、このように表に設定すると、簡単な計算ができる。

Excelやパワポはそれなりに使いこなしているが、Wordはどうも苦手だった。これからは、メンテナンス性の高いドキュメントを作成できるようにならなければプロ失格だねぇ。

この本は、エンジニア向けなので、Wordの機能説明は結構簡略化されている。そのため、あまりWordの機能を知らなさ過ぎる人が読むと、ちょっとちんぷんかんぷんかもしれない。自分はもっとWordの基本機能を学習してからこの本を読むべきだったと思う。どうも機能説明を読んでいても、頭にすんなり入ってこなかったので。

プロのエンジニアの人は、ぜひ読んだほうがよいと思う。案外Wordを使いこなしていないということに気づくから。


エンジニアのためのWord再入門講座 美しくメンテナンス性の高い開発ドキュメントの作り方
エンジニアのためのWord再入門講座 美しくメンテナンス性の高い開発ドキュメントの作り方

読むべき人：
  • プロのシステムエンジニアの人
  • Excelを方眼紙として設計書を作成している人
  • Wordを使いこなしていると自負している人
Amazon.co.jpで『Word』関連の他の本を見る

bana1 プロWordユーザークリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 22:28│コメント(2)│トラックバック(0) 


August 03, 2009

Excel VBA スキルアップコレクション

Excel VBA スキルアップコレクション
Excel VBA スキルアップコレクション

キーワード：
　坪崎誠司、Excel、VBA、Tips、技
Excel VBAの高度で実践的な技が示されている本。項目が多いが、技術書は目次が超重要箇所なので、以下にすべて列挙。
  1. 共通セル範囲を表すRange オブジェクトの取得
  2. セル範囲の集合を表すRange オブジェクトの取得
  3. 連想配列を作成
  4. 動的配列を利用
  5. シート上へ高速にデータを書出す
  6. シート上のデータを高速に配列に取込む
  7. VBA でExcel 関数を使用した方が高速処理できる場合がある
  8. 時間の差分を計算
  9. 時間の差分をミリ秒単位で計算
  10. クリップボードの文字列を操作
  11. ユーザフォームでカレンダーを使う
  12. 右クリックメニューに自作マクロを追加
  13. メニューバーに自作マクロを追加
  14. ツールバーに自作マクロを登録
  15. ツールバーを利用してFaceId の一覧を作成
  16. 右クリックメニューにサブメニューを作成
  17. メニューバーにサブメニューを作成
  18. ファイル選択ダイアログを利用
  19. フォルダ参照ダイアログを利用
  20. CSV 形式の文字列を分解して配列に格納
  21. 文字列配列のデータをCSV 形式の文字列にする
  22. フォルダ内に存在するファイルの一覧を作成
  23. フォルダ内に存在するサブフォルダの一覧を作成
  24. テキストファイルを作成
  25. テキストファイルの内容を読み込む
  26. フォルダを作成
  27. ファイル、フォルダを削除
  28. ファイル、フォルダをコピー
  29. ファイル、フォルダの存在を調べる
  30. ファイル操作をWin32 API を利用して高度に実現
  31. ファイルパスを分解
  32. ファイルの行数を簡単に調べる
  33. ファイルを読み取り専用で開き保存せずに閉じる
  34. ファイルを開くと同時に起動するイベントプロシジャを機能させない
  35. ファイルを開く際に自動リンク更新を無視
  36. XLSTART フォルダを利用
  37. 他のExcel ブックのマクロを実行
  38. 構造体を定義して利用
  39. 画面のスクロールをVBA から行う
  40. VBA 実行中に数秒間処理を止める
  41. VBA から非同期処理を実行
  42. VBA から実行した非同期処理の終了を監視
  43. エクスプローラでフォルダを開く
  44. エラーを無視
  45. エラー発生時に処理を分岐
  46. メッセージボックスをとことん活用
  47. インプットボックスをとことん活用
  48. 円周率を取得
  49. 乱数を使う
  50. 条件分岐を一行で実現
  51. 配列を作成せずにリストを使った処理を実現
  52. 2つの文字列を比較
  53. グループを利用した折りたたみ機能をVBA から制御
  54. Excel ファイルに存在するリンクを調べる
  55. キーボード操作をVBA で実現
  56. 複数のファイルに存在する個人情報を一度に削除
  57. VBE をショートカットキーで起動
  58. 定義されている場所へジャンプ
  59. 変数や関数の型を調べる
  60. プログラムの行をショートカットキーで削除/ 追加
  61. ブック内の全モジュールを対象にした文字列検索
  62. コードウィンドウをショートカットキーで切り替え
  63. モジュール内のプロシジャを前後へ行ったり来たり
(目次から抜粋)
まぁ、この目次を見れば、Excel VBAを使う人には何が示されていて、どういう傾向の本であるかがわかるだろう。逆に、VBAはおろかExcel自体普段使用しない人にとっては、何のことかわからないと思われる。

この本は、セルの数式を操作する程度のExcel VBAの入門書的なものではなく、VBAの基本はある程度わかる人向けの実践的な内容となっている。これは結構知らないことが多く載っていて、本当に秘伝書みたいな内容だった。

まず、Excel VBAで連想配列が使えるとは思わなかった。これは知らなかったので、なるほどと思った。以下のように定義するようだ。
　'連想配列を作成する。
　Dim HS As Object
　Set HS As CreateObject("Scripting.Dictionary")
　
　'連想配列にデータを格納する。
　HS.Add "犬", "Dog"
　HS.Add "猫", "Cat"
　HS.Add "熊", "Bear"

(中略)

　　Debug.Print HS.Item("犬")
(pp.017)
連想配列は、Scripting.Dictionaryというオブジェクトを作成するのがポイントらしい。さらに、連想配列の場合は、配列インデックスが任意の型でよいらしい。これも便利だ。

あと、結構衝撃的だったが、『 Tips05 シート上へ高速にデータを書き出す』というもの。VBA処理では、数千件というデータをシートの各セルに書き出す、というものをよく実装すると思われるが、その実装方法しだいでパフォーマンスがだいぶ改善するというもの。たいていの人は、画面の自動再描画をオフにする、Application.ScreenUpdatingをFalseにしてパフォーマンス改善まですると思われるが、さらにその一歩先があることはあまり知られていないと思う。自分も知らなかった。それが以下の方法。
Public Sub test3()
　　Application.ScreenUpdating = False '画面更新の抑止

　　Dim lpl As Long, lp2 As Long
　　Dim dataArr(1000 - 1, 100 - 1) As Variant

　　' 行数分ループする
　　For lpl = 1 To 1000
　　　　' 行数分ループする
　　　　For lp2 = 1 To 100
　　　　　　'"行数+行数"の値を二次元配列に格納する。
　　　　　　dataArr(lpl - 1, lp2 - 1) = lp1 + lp2
　　　　Next
　　Next

　　'作成した2次元配列をシートに一括書出しする。
　　Range("A1:CV1000") = dataArr

　　Application.ScreenUpdating = True '画面更新の再開
End Sub
(pp.028-029)
11行目のコメントに『二次元配列』とあるのに、16行目のコメントには『2次元配列』と示されていたので、そのまま抜粋。

上記の関数は、A1からCV1000の範囲のセルに"行数+列数"の値を書き出す単純な処理である。実際に上記を実行してみたら、驚くほど速かった。本書によれば、普通に入れ子ループの中でセルの値を設定するものよりも、50倍高速であると示されている。2次元配列の値をRangeオブジェクトにセットするのがポイントとなるようだ。

これは単純にすごいなぁと思った。データ件数が万単位のものを入れ子ループ処理をすると、メモリ、CPUが貧弱なPCだと画面がフリーズしそうになる。この方法は知らなかったので、ものすごくへー、そんな方法があるのか!!と感嘆した。また、こういう書き方はネット上にはあまり載っていないと思う。

他にもいろいろと示したいが、それはさすがにネタばれしすぎなので、自重。

Tipsの合間に著者の意見が示されているコラムが載っている。そこもとても勉強になる。以下、『コードの良し悪し』というものから一部抜粋。
　”良いプログラム”とは、非常に定義しづらいものです。私もこれまでいくつものプログラムを見る・書くしてきましたが、「可読性」を意識し過ぎて単純なプログラム構文ばかり利用したら「高速性」を失ってしまったとか、プログラムの「高速性」を追及したら「拡張性」がないものになってしまったなど、いくつもの事例を目の当たりにしてきました。”良いプログラム”は必ずしも評価基準をオールAでクリアするものではなく、ケースに応じた”評価バランス”がそこに存在していると思います。
（中略）
　現実的には「生産性」という最大の課題もあり、オールA判定されるプログラムの作成は難しいでしょう。せめてD判定のものが一つもない状態のプログラムを目指しましょう。実際の開発現場においては、D判定のものが一つもない状態のプログラムを”良いプログラム”と呼んで良いのだと思います。
(pp.052-053)
D判定がどの程度のものか？にもよるのかなと思った。まぁ、やはり一番の課題は生産性だよね。納期がきついときに、すぐに思いついたコードは、最低限の仕様を満たせるが、可読性や拡張性、保守性が低くなりやすいものであったりする。かといって、可読性、拡張性、保守性までを考慮して自分なりに納得しつつイケているコードを書く時間がないと、どうしようかとジレンマに陥って、結局自分では納得いかない微妙なコードを書くことになる。そして、後でリファクタしようと思っていたら、結局やらなくてその部分でバグったりする（笑）また、生産性を語るときに、見積もりとプログラマーの能力値の関係は切り離せない。

この本は、Excel VBA本を探していたときに書店で発見した。妙に表紙がかっこいいと思い、中を見てみると、モノクロで玄人っぽいページ構成で、自分の知らない技が多く載っていたので速攻で買った。正直これをものにすれば、2,200円は安いと思う。

自分自身は、Excel VBAを本格的に使うようになったのは、ちょうど1年ほど前だったので、もう1年のキャリアになる。VBAの基本構文はネットでも十分習得できるが、ファイルの入出力などのな定石的な技、アルゴリズムは、あまりまとまって載っているページが少ない。そのため、この本はかなり重宝すると思う。

昔はExcelはただの表計算ソフトだと思っていたけど、関数を多く覚え、そしてマクロを覚え、さらにはVBAまで習得すると、Excel VBAで何でもできそうな感じがしてくる（笑）少なくとも、Excel上で手動でできることはほぼ全部自動化できると思う。そう思うと、Excelはすごく奥が深く、神がかったソフトなんだよなぁと思う。ちなみにExcelを作った神は以下の人。自分もこんなの作れたらなぁ・・・と妄想してもしょうがない。

Excel VBAはプログラミングそのものを考慮すると、玄人プログラマーからしてみたらVBA（笑）って感じかもしれないけど、プログラミング初心者がアルゴリズムの考えを習得するにはよいのではないかなと思う。特に行列位置を指定してセルを操作するというのが結構わかりやすいのではないかと思う。

実践的な技が示されてるスキルアップコレクションシリーズは、他にもいろいろと出版されているようなので、チェックしておきたい。


Excel VBA スキルアップコレクション
Excel VBA スキルアップコレクション

読むべき人：
  • Excel VBAツールのパフォーマンスを改善したい人
  • 体系的に実践的な技を習得したい人
  • Excel VBAで何でも仕様を実現できると思っている人
Amazon.co.jpで『スキルアップコレクション』関連の他の本を見る

bana1 VBAエキスパートクリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 22:42│コメント(2)│トラックバック(0) 


March 15, 2009

VBAエキスパート教科書 AccessVBAスタンダード

VBAエキスパート教科書AccessVBAスタンダード (VBAエキスパート教科書)
VBAエキスパート教科書AccessVBAスタンダード (VBAエキスパート教科書)

キーワード：
　プロジェクトA株式会社、VBAエキスパート、Access、スタンダード、教科書
VBAエキスパートのAccessスタンダードの教科書。以下のような目次となっている。
  1. Lesson1　Access2002 VBAプログラミングの基礎
  2. Lesson2　Access2002 VBAの基本文法
  3. Lesson3　変数、定数、配列
  4. Lesson4　VBA関数と演算子
  5. Lesson5　制御構造
  6. Lesson6　サブルーチン
  7. Lesson7　イベントプロシージャ
  8. Lesson8　フォーム/レポートの制御
  9. Lesson9　SQLステートメント
  10. Lesson10　SQLステートメントとデータベース管理
  11. Lesson11　ADO
  12. Lesson12　Access2002の新機能
(目次から抜粋)
このエントリは、この本の内容を取り上げるというよりも、VBAエキスパートというベンダー資格の受験結果の報告というような感じになる。貴重な500冊までのラスト10冊の、491冊目がこれでいいのかという疑問もあるが・・・。

そもそもVBAエキスパートは何かというと、ExcelとAccessで利用できるVBA（Visual Basic for Applications - Wikipedia）のスキルを評価する資格制度で、2003年に設立されたようだ。そして、Excel,Accessともにベーシック、スタンダード、プロフェッショナルというランクがあり、今日というか、昨日Accessのスタンダードを受験してきた。

VBAエキスパートの詳細については、以下の公式サイトを参考に。そもそもなぜこの資格を取得しようかと思ったかというと、仕事でAccessを使用しているし、Accessを本格的に学習したことがなかったので、ググって見たらこんな資格があることを知り、どうせなら受験しようと思った。また、仕事での目標設定で、AccessとExcelのスタンダードを取得すると決めてしまったので、取らないわけにもいかず・・・。

そして、この本を参考に受験して、一応合格した。受験料が1万5千円で、この高額受験料ゆえに、今月のセミナー参加を泣く泣く見送った・・・。しかも口座残高が依然として厳しい状況で、この程度の資格試験で落ちたら笑えないと思って、事前に必死になって勉強した甲斐があった。

少しだけこの教科書について触れておこう。

Accessの基本的な文法から関数、ADOやSQL、Formなど、ふだんは仕事で使わないようなものまでしっかり示されていた。その点は純粋に勉強になった。ただよろしくない点が二つある。
  • 記述の間違いが多すぎて、正誤表を最初にチェックしなければならないこと
  • 付属CD-ROMのプログラムをインストールしても、WindowsUpdateが原因で起動しなくなること
こういう技術書で間違いが多すぎると、信頼性が落ちるのでよろしくない。また、模擬試験ができるソフトが使用できないのは致命的。それぞれこの本の出版元サイトで正誤表がアップされており、また更新プログラムがダウンロードできるので、それを最初に入手しなければならない。また、2009年3月、つまり今月末からVBAエキスパートの試験が全体的に更新されるようだ。自分は旧バージョンを受けたが、旧バージョンは完全に選択問題のみだが、新バージョンは選択問題と空欄穴埋め問題があるようだ。そのため、勘で回答するということができなくなる。そして、それに伴って、この教科書シリーズも新バージョンになって発売されるようだ。なので、この旧バージョンの教科書はもう存在価値がなくなってしまう。

旧バージョンは選択問題なので、大体2週間かけて勉強したら合格できた。大体1日30〜45分を費やしてこの本を読み、試験3日前までに2回繰り返して読んだ。そして前日、当日を含めて3回目を読んで、何とか合格できた。大体8割正解だとほぼ合格なので、この程度の試験に完全を求めて勉強しすぎるのも、時間がもったいない。かといって、なめすぎて楽勝でしょ!!とかいってあまりにも勉強しなさ過ぎだと、引っ掛け問題や普段は使わないような領域の問題が出てきて撃沈の可能性もあり・・・。まぁ、普通に何回か繰り返して教科書を読んでおけばそんなに難しくはないけど。さすがにAccessに触れたことがないという人は、ベーシックから順を追って受験すればいいと思うけど。

この程度の資格そのものにはほとんど価値はないけど、資格取得までのモチベーション、時間管理がすごく勉強になったと思った。1万5千円を払って、社会人になってからの勉強リズムを体得したと思っておこう。

一応Excelスタンダードも取得しておこう。そしたら、Accessスタンダードと合わせて、VBA Expert Standard Crownが取得できる、と思って公式サイトを見ると以下の記述が・・・。
Excel VBAとAccess VBAそれぞれのスタンダードレベルを両科目とも取得した方にはスタンダードクラウンの認定証を発行します。新しい試験と従来の試験を混在した組み合わせは対象外となります。

スタンダードクラウンの認定対象
  • Excel VBA スタンダード + Access VBA スタンダード
  • Excel 2002 VBA スタンダード + Access 2002 VBA スタンダード
今回自分が取得したのは、Access 2002 VBA スタンダードだから、同じく2002のExcelスタンダードを取得しなければいけない。しかし、もう今月、来月は受験している余裕がない・・・。金銭的に・・・。かといってExcel VBA スタンダードを取得して、再度Access VBA スタンダードを受験するのも受験料がもったいない・・・。まぁ、クラウンはどうでもいいか。履歴書とかにもあまり書きたくはないし。どうせならVBA Professional Office 2003を取得しよう。


おまけ

VBA Expert受験結果

受験終了後にもらえる試験結果レポート。何とか正解率が80%だった。まぁ、楽勝ですよ(落ちたら1万5千円が水の泡になるから、事前にかなり必死で勉強したので・・・)

正式な認定証は1ヵ月後くらいに配送らしい。また、TOEIC以外に初めて資格を取得したので、ちょっとだけ嬉しい。大した資格ではないけど。

この資格の難易度は以下を参照。2chのこういうランクは結構信用できる。学歴、企業ランクはネタとして見なければいけないけどね・・・。

来月は応用情報技術者試験（旧ソフ開）受験だぜ


VBAエキスパート教科書AccessVBAスタンダード (VBAエキスパート教科書)
VBAエキスパート教科書AccessVBAスタンダード (VBAエキスパート教科書)

読むべき人：
  • Accessの基本的な文法などを勉強したい人
Amazon.co.jpで『VBAエキスパート』の関連書籍を見る

bana1 資格ゲッツクリック☆ 　にほんブログ村 本ブログへ

type5w4_lion at 01:21│コメント(2)│トラックバック(0) 


February 28, 2009

システムはなぜダウンするのか

システムはなぜダウンするのか 知っておきたいシステム障害、信頼性の基礎知識
システムはなぜダウンするのか 知っておきたいシステム障害、信頼性の基礎知識

キーワード：
　大和田尚孝、障害対応、システム、ダウン、運用
コンピュータシステムのダウンの原因が技術的な観点から示されている本。以下のような目次となっている。
  1. 第1章　システムが止まった…――「ダウン」とは何か
  2. 第2章　きちんとテストしたはずなのに…――アプリケーション・ソフトの不具合
  3. 第3章　アプリケーションだけではない…――OS、ミドルウエアの不具合
  4. 第4章　アクセス殺到に耐え切れず…――性能・容量不足
  5. 第5章　気づかなかったは許されない…――環境設定・変更ミス
  6. 第6章　その「うっかり」が致命傷…――運用・操作ミス
  7. 第7章　まさか、こんなことが起こるとは…――ハード故障、不慮の事故
  8. 第8章　障害対応は時間との闘い…――ダウンに学ぶ
(目次から抜粋)
著者は、以前SEでシステム運用に従事した後、日経BP社に転じ、『日経コンピュータ』の記者として、システムダウンの事例を数多く取材されてきたようだ。そして、システムの信頼性向上につなげるには、システムダウンの経験を多く得るのが一番という結論に至ったようだ。しかし、一人の技術者が多くのシステムダウンに遭遇することはないので、この本が書かれたようだ。以下その部分を抜粋。
そこで本書では、過去数年間にわたって、実際に発生したダウンの事例のなかから、日経コンピュータ誌をはじめ、雑誌や新聞などで原因が詳しく報じられたケースを取り上げ、どのような原因がきっかけでどんな事象が起きたのかを技術的な観点で体系的にまとめました。
(pp.2)
取り上げられている事例は、企業名などは伏せられているけど、数年にニュースを騒がせた株の誤発注のものやあまり大きな事例でないものまで幅広く示されている。それらのシステムダウンの事例が、システム内部の挙動、ハードウェアなどの解説を含めて技術的に示されている。これらは、とても勉強になる。

システムがダウンする原因は、以下のように大体4つに分類できるようだ。（クリックで拡大）
ダウンの原因の分類

このように、システムが動かなくなる原因が各章で詳細に示されている。

この本を読む前は、システムがダウンする原因は、作ったシステムのバグとか不正データとかそういうのが主な原因だろうと思っていたけど、それ以外にもハードウェアが原因だったり、OSとハードウェアの不整合だったり、DBのデッドロックだったり、ネットワークの輻輳だったり、はてはねずみがケーブルをかじっていたのが原因といったものまで示されており、システムが落ちる理由は多岐にわたるなぁと分かった。それら全てに対応するのはかなり難しいのではないかと思った。

そして、本書では、ダウンを100%防ぐというのは無理という現実を受け止めて、ではどうするかということが以下のように示されている。
　ダウンを100%なくすのではなく、ダウンしてもすぐに復旧させる、ダウンした際の影響範囲を小さくする、同様のダウンが起きないように対策を講じる、といったアプローチが求められます。
(pp.21)
そして、最終章では、原因究明よりもまずシステムを復旧させることが最優先であると示されていた。なるほどと思った。

他にも、障害対応技術者について、以下のように示されている。
技術者にとっての腕の見せ所は、いかに原因を迅速に突きとめられるかです。それにはまず、システム全体のハード構成やネットワーク構成、使用するOSやミドルウェアの知識、アプリケーションの仕様、開発言語の知識などをすべて理解している必要があります。
（中略）
優秀な技術者ほど、ダウンの発生状況や影響範囲などから根本原因を突きとめる嗅覚があると言われるのは、こうした幅広い知識を身につけているからです。
（中略）
これからの技術者には、ダウンが起きた際に原因を素早く突き止めるスキルと、ダウンから再発防止策を学ぶ力の両方が今まで以上に求められています。
(pp.23)
システムを知り尽くしていないと、障害対応はできないということだろう。そうなるには、どれだけ時間がかかることやら・・・。

この本は、システムダウンの事例が豊富に載っており、いかにシステムを運用させるかといった観点から書かれている本はあまりないので、貴重だと思った。これを読んでおけば、いつでも運用、障害対応要員として借り出されても大丈夫だと思う。少なくとも基礎的なことは網羅されていると思うので、システムダウンの原因の特定などが早くなるのではないかなと思った。

ただ、システムダウンの原因の事例は多く示されているが、障害が発生ないようにするにはどうするか、そして発生した場合はどうするかといったことについては、あまり詳しく示されていない。

入社して最初の仕事が運用だったので、これはもっと早くに読みたかったと思った。そうすれば、JP1（JP1 - Wikipedia）でバッチが異常終了していて赤くなっているのを見て、無駄に不安がらなくてもすんだのに・・・。また、もっと運用に早く価値を見出せたかもしれない。

システムは、作って終わりではなく、いかに安定稼働させるかが重要だということがよくわかった。昨今のシステム開発は、要求が複雑化し、求められる技術も高くなり、大規模化していき、難しくなってきている。そして作った後も安定稼働させるのが難しいという状況になりつつあるのかなと思った。そういう状況になったとき、システム構築業界、SI業界、IT業界は、再度ソフトウェア危機(ソフトウェア危機 - Wikipedia)に直面しているのではないかと思った。やはりシステム構築業は難しい世界なんだなぁと思った。

運用担当、障害対応要員は絶対読んでおいて損はない1冊。ゆっくり読むと大体5時間くらいかかるが。

このなぜシリーズで書評したのは以下。どれも分かりやすくていい。


システムはなぜダウンするのか 知っておきたいシステム障害、信頼性の基礎知識
システムはなぜダウンするのか 知っておきたいシステム障害、信頼性の基礎知識

読むべき人：
  • システム運用要員の人
  • 運用などSE業ではないと思っている人
  • システムは作って終わりだと思っている人
Amazon.co.jpで『日経コンピュータ』の関連書籍を見る

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

type5w4_lion at 16:33│コメント(0)│トラックバック(2) 


February 27, 2009

Microsoft Visual Basic 2005実践講座―ステップバイステップで学ぶプログラミング!〈Vol.1〉基礎編

Microsoft Visual Basic 2005実践講座―ステップバイステップで学ぶプログラミング!〈Vol.1〉基礎編 (マイクロソフト公式解説書)
Microsoft Visual Basic 2005実践講座―ステップバイステップで学ぶプログラミング!〈Vol.1〉基礎編 (マイクロソフト公式解説書)

キーワード：
　マイケル・ハーバーソン、VB.NET、Visual Studio、基礎、公式解説書
統合開発環境Visual Studio 2005の使い方とVisual Basic 2005の入門的な内容が示されている本。以下のような目次となっている。
  1. パート1　Visual Basic 2005の基礎
    1. レッスン1　Visual Studio 2005の起動と開発環境
    2. レッスン2　初めてのプログラミング
    3. レッスン3　コントロールの基本的な使い方
    4. レッスン4　メニュー、ツールバー、およびダイアログボックス
  2. パート2　言語仕様の基礎
    1. レッスン5　変数と式、.NET Framework
    2. レッスン6　条件判断構造
    3. レッスン7　ループとTimerコンポーネント
    4. レッスン8　プログラムのデバッグ
    5. レッスン9　構造化エラー処理
    6. レッスン10　モジュールとプロシージャ
    7. レッスン11　数値と文字列を扱うための配列
    8. レッスン12　コレクションとSystem.Collections名前空間
    9. レッスン13　テキストファイルと文字列の操作
(目次から抜粋)
この本の概要が示されている部分が『はじめに』にあるので、その部分を抜粋。
本書は、さまざまなレベルのプログラミング技術を持つ読者を対象に、実用的な体験型チュートリアルの形式をとっています。プログラミングの初心者は、役に立つ実践的なアプリケーションの作成を通じてソフトウェア開発の基本を学習することができます。また、Visual Basicプログラミングの経験者は、VB2005で変更された主要ツールとプログラミング技術を短期間でマスターすることができます。
(pp.11)
このように、プログラミングをまったくやったことのない人でも、チュートリアルに沿ってサンプルプログラムに触れながら学習できる。学習者の目的に応じて、参考にすべき章が示されている。例えば、VB2002/2003からアップグレードする場合は、レッスン1,4,5,7,8,13を参照するとよいらしい。自分の場合は、他のプログラミングを触れたことがあり、VB.NETもある程度分かるが、基礎的な部分からもう一度確認したいと思ったので、ほぼ内容を飛ばさずに最初から読んだ。さすがに付録のCD-ROMについているサンプルプログラムは実行しなかったけど。

VB2005で特に勉強になった部分、これはよく忘れそうだと思う部分を以下に恣意的に列挙。
  • VS2005の便利な新機能の1つに、環境開発内にシンプルなWebブラウザを開く機能がある
  • 特定のオブジェクトやイベントに関連付けられたプロシージャを、「イベントハンドラ」または「イベントプロシージャ」と言う
  • Visual Studioのコードエディタは、1行に65,000文字以上表示することができるが、1行を80文字以内にした方が、見やすくかつ編集しやすい
  • 名前空間とは、固有の名前で系統立てられたクラスの階層ライブラリのこと
  • コンパイルエラーは、プロパティやキーワードの入力ミスなど、VBの規則に違反した場合に発生するプログラミングの誤り
  • ランタイムエラーは、実行中のプロセスが予期せず停止する原因となる誤りで、「実行時エラー」とも呼ばれる
  • 論理エラーは、間違った実行結果を出してしまうような人為的なミス
  • パブリック変数の宣言は、 Public RunningTotal As IntegerとDimの変わりにPublicを指定するだけ
  • ブレークポイントはプロジェクトと一緒に保存されるため、プロジェクトをいったん閉じて再度開いた場合もプログラム内に設定されたまま
この本は、マイクロソフトの公式解説書という位置づけらしい。そのため、間違ったことは書いてないと思うので、信頼性が高いと思う。しかし、初心者がぱっとこの装丁を見たときに、とっつきやすいかどうかは微妙だと思う。他の入門書は、『簡単』とか『入門』とか『わかりやすい』といったキーワードが示されているが、これはそうではない。中身を見てみると、2色刷りで、文字量もそれなりにあるので、他の入門書よりもとっつきにくいと思う。しかし、しっかり読み込んでいくと、内容的にはそこまで難しくはないので、問題ないと思う。

ページ数が400を超えるので、まじめに精読すると1ヶ月はかかると思う。大体2日で1レッスンを進めるという進捗でも、やはり1ヶ月はかかる。自分の場合は、精読しすぎたが、マイクロソフトの公式解説書なので、細かいところまで仕様が示されていると思ったが、そうでもなかった。

オブジェクト指向などもう少し高度なことは、『Vol.2 活用編』に示されているようだ。VBはバージョンが2008までリリースされているので、この2005版の続編を読むかは微妙だが。

著者はマイクロソフトでVBの開発に携わっていた人らしい。今は、大学で助教授として歴史を教えているようだ。変わっているなぁと思った。また、プログラミングができて歴史を教えているというのは何だかいいなぁと思った。


Microsoft Visual Basic 2005実践講座―ステップバイステップで学ぶプログラミング!〈Vol.1〉基礎編 (マイクロソフト公式解説書)
Microsoft Visual Basic 2005実践講座―ステップバイステップで学ぶプログラミング!〈Vol.1〉基礎編 (マイクロソフト公式解説書)

読むべき人：
  • VB2005の基本を学習したい人
  • VB.NETの例外処理を学習したい人
  • プログラミングと歴史が好きな人
Amazon.co.jpで『Visual Basic2005』の関連書籍を見る

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

type5w4_lion at 07:24│コメント(2)│トラックバック(0) 


February 17, 2009

ifとelseの思考術 プログラマ脳育成講座

ifとelseの思考術 プログラマ脳育成講座
ifとelseの思考術 プログラマ脳育成講座

キーワード：
　矢沢久雄、入門書、プログラマ脳、教育担当、ベンチマーク
プログラミング時の思考法について示されている入門書。以下のような目次となっている。
  1. 第1章　プログラマとはこんな人
  2. 第2章　コンピュータとプログラムに対するイメージをつかむ
  3. 第3章　プログラミング教材で学習する方法
  4. 第4章　プログラミング入門講座で指導する方法
  5. 第5章　サンプルプログラムを真似るときのポイント
  6. 第6章　覚えておくべき基本的なアルゴリズム
  7. 第7章　プログラマなら一度は夢中になるテクニック
  8. 第8章　ここまでできれば一人前のプログラマ
(目次から抜粋)
プログラミング初心者にとっては、プログラミング時の考え方というものがよくわからなかったりする。この本では、プログラミングする際の思考方法をプログラマ脳と捉え、そのプログラマ脳を身に付けるための方法が示されている。

この本は、プログラミング初心者が読めばなるほどと思うことが多いだろう。しかし、ある程度プログラミングを経験しており、それなりにコーディングをガリガリ書ける人にとっては、この本はつっ込みどころが多いのではないかと思う。細かいつっ込みやこの本の網羅性は、以下の方のブログの書評が参考になる。自分もそれなりにそれはどうかなぁとか、微妙だなぁと思うところがあった。しかし、基本的に自分の書評スタイルはなるべく内容をポジティブに受け取るというものなので、共感できた部分、なるほどと思った部分を以下に恣意的に示しておく。
  • プログラミングは、指と目で覚える
  • 自分が作ったプログラムが、社会の役に立った達成感が、これまでに経験したことのない喜び
  • はじめてプログラミングを本格的に学ぶ人にはC言語の方がよい
  • 「どうしたらプログラムが作れるようになるのか」という疑問に対する回答は、多くのサンプルプログラムを経験して真似ること
  • 統一性がることを美しいと感じることも、プログラマ脳を持つ人ならではの感覚の1つ
  • 自分の中にプログラマ脳を芽生えさせるためには、一緒にプログラミングする仲間をつくるとよい
こんなものか。自分もプログラミング言を習得するとき、C言語が本格的に学んだ最初の言語だった（正確にはSchemeを最初に触れたが括弧が多すぎて意味不明すぎて挫折・・・）。だから、C言語でポインタまで理解してメモリ空間の使い方を把握し、さらにアルゴリズムとデータ構造まで習得しておくと、大体他のプログラミング言語もすんなり習得できると思う。これは経験的に自信を持って言える。

次に、どうしてもこれはつっ込んでおきたいという部分がある。それはフローチャートについての部分。
　新人研修の講師をしていると「どうにかプログラムは作れますが、フローチャートを描くことが苦手です」と言う新人さんをよく見かけます。このような新人さんは、考えがまとまらないうちにプログラムを打ち込み始め、その実行結果（正しくない実行結果）を見てからプログラムを修正するという作り方をしています。趣味でプログラミングするなら、このスタイルでもかまいませんが、プロを目指すならいけません。フローチャートを描いて考えをきちんと整理しないと、品質の高いプログラムを作れないからです。
(pp.52)
プログラミングを学び始めるときに、プログラミング前に分岐やループ処理を整理するためにフローチャートに一度落とし込む、というのは有効だとは思う。しかし、『フローチャートを描いて考えをきちんと整理しないと、品質の高いプログラムを作れないからです。』は本当だろうか？と少し疑問に思った。まず、オブジェクト指向とかWeb系の言語ではフローチャートで表現できないような処理が出てくる。そのときに、フローチャートはまず使えない。

そして、ここでいう『品質の高いプログラム』が何を指しているのかにもよるが、それはならずしもフローチャートよる効用ではないと思う。高品質であるとは、バグが出ないものであるとか、メモリを無駄に使用しておらず処理速度が速いとか、メンテナンス性に優れているとか定義できるが、フローチャートが担保できそうなものは、バグが出ないもの（論理エラーがないとか）ということのみだろう。確かにフローチャート的に思考して論理エラーを回避するというのは、プログラミング前に脳内でイメージする。けれど毎回フローチャートを描く必要があるかと言うと、それはいらないと思った。少なくとも、フローチャートが有用なのはケースバイケースで、必ずしも必要なものではないというのが自分の考え。

フローチャート不要論、有用論はググッたらいろいろ出てくるので、興味がある人は自分で調べたらいいと思う。

あともう一箇所つっ込んでおきたいのは、プログラミング書籍の購入方法について。以下その部分を抜粋。
プログラミング教材には、以下に示したような種類があります。書店に並んだ本がどれに該当するかは、書名と表紙のデザインから判断してください。もちろん、手にとって内容も確認してください。
  1. プログラミングを楽しむ入門書
  2. 言語構文の概要を網羅した入門書
  3. 言語構文を詳細に網羅した解説書
  4. アルゴリズムのサンプル集
  5. プログラミングのTips集
  6. データベースプログラミングの解説書
  7. インターネットプログラミングの解説書
  8. その他
(pp.63-64)
このように示されているが、この本は『プログラミングを楽しむ入門書』だろう。しかし、『書名と表紙のデザインから判断しろ』と示している割に、この本の書名と表紙は全然入門書っぽくない。そして自分は書店で思わず本書をジャケ買いし、実際に読んでみると内容が入門書で、微妙に騙された気がした・・・。書名とデザインから、もっとコアな内容かと思っていたら、完全にプログラミング初心者向けの内容で、プログラミング歴が10年近くの人やIT教育をみっちりやった人にとっては、復習にしかならない内容。まぁ、よい復習にはなったよ。この教訓から、技術本はジャケ買いせずに、Amazonのレビューを一度見て、さらに絶対内容を確認してから買え!!と言える。技術本は2000円以上のものが普通で、しかも読了までかなり時間がかかるから投資工数が普通の本より大きい。それではずれ本を買ってしまったときの失望感といったら・・・。しかも口座残高が残り少なくて危ないというときに買ったものであればなおさら・・・。

この本は、本当にプログラミングをこれから1から学ぼうと思っている人向けの本で、ある程度のレベルのプログラマが読んでも得られるものがあまりないと思う。もちろんよい復習にはなる。けれど、それ以上の能力開発にはならないと思う。また、新人教育担当の人が読めばいいのではないかと思う。

ある程度のレベルのプログラマであるかどうかを確認するためにこの本を読む、というのもひとつの手だと思う。これを1時間以内で読了して、それなりにつっ込みを入れられる人は、間違いなく初級プログラマの域をはるかに超えているだろう。そういう人は、こういう入門書は早く卒業したほうがいい。

ということで、自分も入門書レベルの技術書を読んで勉強した気になるのはもう止めようと思った。もっとコアな技術書を読まなければね。


ifとelseの思考術 プログラマ脳育成講座
ifとelseの思考術 プログラマ脳育成講座

読むべき人：
  • プログラミング初心者の人
  • 基本情報処理技術者を受験する人
  • 自分が初級プログラマかどうかを確認したい人
Amazon.co.jpで『矢沢久雄』の他の本を見る

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

type5w4_lion at 21:46│コメント(0)│トラックバック(1) 


   次のページへ