プログラマの三大美徳。それは無精、短気、傲慢。
Perl の生みの親である Larry Wallによる、Perl 解説本「プログラミング Perl」の「はじめに」で現れる有名なこの言葉。
同著の用語集に解説があります。
無精：
エネルギーの総支出を減らすために、多大な努力をするように、あなたをかりたてる性質。こうして労力を省くために書いたプログラムは他人も使うようになり、そのプログラムに関する質問にいちいち答えずに済ますためにドキュメントを書くようになる。それゆえ、プログラマにとって最も重要な素質である。またそれゆえ、この本が存在するのである。
短気：
コンピュータがサボっているときに感じる怒り。あなたの指令に反応するだけでなく、実際に指令を予測する−あるいは、少なくともそのようなふりをする−プログラムを書く原動力になる。それゆえに、プログラマにとって２番目に重要な素質である。
傲慢：
ゼウスの怒りにふれるほど、プライドが高いこと。また、他人にケチを付けられないようなプログラムを書く（そして維持する）ための原動力になるもの。それゆえ、プログラマにとって３番目に重要な素質である。
こういうイタズラゴコロ、大好きです。
この Larry Wall というおっさん、「プログラミング Perl」では、言語解説書なのになぜか親しめてしまう文体で Perl を紹介し、講演では複雑なものから本質をすくいとってシンプルに表現してしまう。
憧れと尊敬を隠せない、愛すべきおっさんです。
三大美徳はhttp://www.lanl.gov/Document/で原文が参照できます。参考までに。
2005年02月28日
2005年02月27日
プロの心得：外を見つめる。まっすぐに。
プロとして提供すべき価値は、常に組織の外に向けられたものです。
組織の中にはコストしかないし、プロならば社内調整や権限獲得に奔走すべきではないです。
えー、以上、建前論というか「こうありたい」論です。
自分の中ではこの、組織の外を見つめて自分がいかに貢献できるかを追求するか、それとも組織の中で得られる権限を追求するかがプロとサラリーマンとの分かれ目だと思っています。
できる限り社内調整や組織内の利害整理なんてしたくないです。
そんな事をしている間に、お客様に割ける貴重な時間が費やされてしまうのが耐え難いです。
でも、じゃぁ貢献するためにはプロジェクトチームがなければならず、２人以上の人間がいるならそこには必ず政治が生まれてしまい…
前の会社、今の会社、社外の同業、ネット上。
仕事上の愚痴のほとんどが…下手したらすべてが、社内の話。
ゲンバの現実問題として避けては通れないんですよね。
でもせめて、これらの問題への対処が「自分が果たすべき貢献」ではなく「貢献を妨げる制約条件の除去に過ぎない、付加価値は生んでいない」ことは忘れないようにしたいところです。
一個下のエントリの件も含め、プロフェッショナルと組織。深いです。
組織の中にはコストしかないし、プロならば社内調整や権限獲得に奔走すべきではないです。
えー、以上、建前論というか「こうありたい」論です。
自分の中ではこの、組織の外を見つめて自分がいかに貢献できるかを追求するか、それとも組織の中で得られる権限を追求するかがプロとサラリーマンとの分かれ目だと思っています。
できる限り社内調整や組織内の利害整理なんてしたくないです。
そんな事をしている間に、お客様に割ける貴重な時間が費やされてしまうのが耐え難いです。
でも、じゃぁ貢献するためにはプロジェクトチームがなければならず、２人以上の人間がいるならそこには必ず政治が生まれてしまい…
前の会社、今の会社、社外の同業、ネット上。
仕事上の愚痴のほとんどが…下手したらすべてが、社内の話。
ゲンバの現実問題として避けては通れないんですよね。
でもせめて、これらの問題への対処が「自分が果たすべき貢献」ではなく「貢献を妨げる制約条件の除去に過ぎない、付加価値は生んでいない」ことは忘れないようにしたいところです。
一個下のエントリの件も含め、プロフェッショナルと組織。深いです。
2005年02月26日
SE は組織を超越する
SE は組織を超越した存在です。ボランティアが NPO を超越した存在であるように。
高度のスキルはそれ自体が生産手段であり、組織が集約的に持つ資本や物的資源から独立して価値を創出しうるからです。
SE に話題を限れば、組織にとっていかに働いてもらうかは、もはや労働の問題ではなく人的資源の問題です。
大きなコトを言っていますが、ドラッカーの受け売りです。
（もちろん、ドラッカーが論じていたのは SE だけでなく Knowledge worker 全般でしたけど）
ご存知の方はひと目見てわかったと思います。良いですよね、ドラッカー。
さて、「未来のいつか」より「人材のプール」のトラックバックです。
続きを読む
高度のスキルはそれ自体が生産手段であり、組織が集約的に持つ資本や物的資源から独立して価値を創出しうるからです。
SE に話題を限れば、組織にとっていかに働いてもらうかは、もはや労働の問題ではなく人的資源の問題です。
大きなコトを言っていますが、ドラッカーの受け売りです。
（もちろん、ドラッカーが論じていたのは SE だけでなく Knowledge worker 全般でしたけど）
ご存知の方はひと目見てわかったと思います。良いですよね、ドラッカー。
さて、「未来のいつか」より「人材のプール」のトラックバックです。
続きを読む
2005年02月25日
ゲンバで使ったSQL：縦並びデータを範囲集計して横並びに変換する
前回のバリエーション。
というように続くテーブル（月ごと）を
というように続く部署ごとの四半期推移にするなら、
縦並び状態で sum() をかけた一時テーブルを作る手もあるかも知れないけれど、まぁ状況により使い分けるってことで。
サンプルは不自然だけど、あくまでSQLのロジックを伝えるのが目的なんで勘弁して下さい。
| 月 | 部署 | 経費 |
|---|---|---|
| 3 | 営業 | 48 |
| 12 | 研究開発 | 260 |
| 5 | 営業 | 30 |
| 3 | 岩手工場 | 12 |
| 10 | 広報 | 125 |
というように続くテーブル（月ごと）を
| 部署 | 第１四半期 | 第２四半期 | 第３四半期 | 第４四半期 |
|---|---|---|---|---|
| 営業 | 715 | 528 | 628 | 476 |
| 研究開発 | 1279 | 1368 | 1572 | 983 |
というように続く部署ごとの四半期推移にするなら、
insert into 変換後
select 部署
sum( decode( 月,
least( greatest( 月, 1 ), 3 ),
経費, 0
) ) as 第１四半期,
sum( decode( 月,
least( greatest( 月, 4 ), 6 ),
経費, 0
) ) as 第２四半期,
sum( decode( 月,
least( greatest( 月, 7 ), 9 ),
経費, 0
) ) as 第３四半期,
sum( decode( 月,
least( greatest( 月,10 ),12 ),
経費, 0
) ) as 第４四半期,
from 変換前
group by 部署縦並び状態で sum() をかけた一時テーブルを作る手もあるかも知れないけれど、まぁ状況により使い分けるってことで。
サンプルは不自然だけど、あくまでSQLのロジックを伝えるのが目的なんで勘弁して下さい。
2005年02月24日
やりがいを感じる瞬間
SE がやりがいを感じる瞬間は大体
1) システムの稼動時
2) お客様が喜ばれた時（感謝された時）
という意見が多いですね。
多少、表現のブレがあるにしても前者は物を作り上げた喜びで、後者はそれを「誰かに喜んでもらう」喜び。
エンジニアとしてはモノヅクリが嬉しいのは当たり前だし、それに人として産まれた以上、人を喜ばせる以上の喜びはないでしょう。
でも第３のパターンとして、私の先輩のケースが強く印象に残っています。
曰く、「本稼動から１年後、お客様の財務諸表を PDF でダウンロードして経費が XX 億減ったのを見たとき」。
自分が作った物が、ビジネス上の価値を生んだことに感じる喜び。
ん〜、プロですね、プロ。
少なくとも情報システムはお客様が楽しみたくて発注するわけではなくて、ビジネス上の目的があって「投資」しているわけです。
投資は回収されなければ意味がない。
仮にシステム導入で業務改善ができても、現場の人が「仕事がスムーズになりました、ありがとう」と言ってくれたとしても、トップが「よく頑張ってくれた」とねぎらってくれたとしても、ビジネス上の価値を生まなければ意味がない。
ビジネス上の価値が生まれなければ、利用はされても「動かないコンピュータ」に等しい。
まぁ、人は人間なので（トートロジー）喜びを感じるツボはそれぞれですが、自分の仕事の定義を再認識させられた一言でした。
あ、私ですか？
私は日々の業務をきちっと終わらせて帰る瞬間ですね(笑)。
凡人なので平凡な幸せの積み重ねがいいんです。
「SWITCH BACK」より「やりがい」のトラックバックでした。
1) システムの稼動時
2) お客様が喜ばれた時（感謝された時）
という意見が多いですね。
多少、表現のブレがあるにしても前者は物を作り上げた喜びで、後者はそれを「誰かに喜んでもらう」喜び。
エンジニアとしてはモノヅクリが嬉しいのは当たり前だし、それに人として産まれた以上、人を喜ばせる以上の喜びはないでしょう。
でも第３のパターンとして、私の先輩のケースが強く印象に残っています。
曰く、「本稼動から１年後、お客様の財務諸表を PDF でダウンロードして経費が XX 億減ったのを見たとき」。
自分が作った物が、ビジネス上の価値を生んだことに感じる喜び。
ん〜、プロですね、プロ。
少なくとも情報システムはお客様が楽しみたくて発注するわけではなくて、ビジネス上の目的があって「投資」しているわけです。
投資は回収されなければ意味がない。
仮にシステム導入で業務改善ができても、現場の人が「仕事がスムーズになりました、ありがとう」と言ってくれたとしても、トップが「よく頑張ってくれた」とねぎらってくれたとしても、ビジネス上の価値を生まなければ意味がない。
ビジネス上の価値が生まれなければ、利用はされても「動かないコンピュータ」に等しい。
まぁ、人は人間なので（トートロジー）喜びを感じるツボはそれぞれですが、自分の仕事の定義を再認識させられた一言でした。
あ、私ですか？
私は日々の業務をきちっと終わらせて帰る瞬間ですね(笑)。
凡人なので平凡な幸せの積み重ねがいいんです。
「SWITCH BACK」より「やりがい」のトラックバックでした。
2005年02月23日
SE として訓練しておくべき隠れたスキル
タイトルは大仰ですが(笑)、成果に対して厳しい、私が勤めている会社で密かに重要となるスキルがあります。
それは Excel です。
まぁ、ウチに限らずどこの SI でも、もしかしたら一般企業でも事情は同じかも知れません。
普段意識していなくても、言われれば支持してくれる方も多いんじゃないでしょうか。
SE の仕事のかなりの部分をドキュメント作成 / メンテが占め、そのためのソフトは大抵 Excel です。
Excel に向かっている時間が長いので Excel での生産性が全体の生産性に大きく影響する。
だから Excel スキルは重要。
非常にシンプルな話です。
仮にも情報システムを扱う立場でアビバやユーキャンで Excel を覚えようなんて人はいないでしょうけど、ショートカットや効率的な作業手順、関数、印刷回りの設定など「ちょっとした細かなワザ」まで勉強していない、という人がほとんどだと思います。
と、いうよりも勉強せずとも使えているし勉強するまでもない、といったところでしょうか。
私の前の会社もそうでした。
でも転職後の今の会社は違います。
「それで日々の作業効率が数パーセントでも上がるなら勉強するよ」
「むしろ日常使いつづけるんだから、勉強した分は確実に投資回収できるじゃん」
と、当たり前のように言い、皆一度は Excel の機能辞書や関数集を通読しています。
おぉ、こいつらプロだ。
こういう環境こそ、転職で得られた最大の収穫だったかも知れません。
それは Excel です。
まぁ、ウチに限らずどこの SI でも、もしかしたら一般企業でも事情は同じかも知れません。
普段意識していなくても、言われれば支持してくれる方も多いんじゃないでしょうか。
SE の仕事のかなりの部分をドキュメント作成 / メンテが占め、そのためのソフトは大抵 Excel です。
Excel に向かっている時間が長いので Excel での生産性が全体の生産性に大きく影響する。
だから Excel スキルは重要。
非常にシンプルな話です。
仮にも情報システムを扱う立場でアビバやユーキャンで Excel を覚えようなんて人はいないでしょうけど、ショートカットや効率的な作業手順、関数、印刷回りの設定など「ちょっとした細かなワザ」まで勉強していない、という人がほとんどだと思います。
と、いうよりも勉強せずとも使えているし勉強するまでもない、といったところでしょうか。
私の前の会社もそうでした。
でも転職後の今の会社は違います。
「それで日々の作業効率が数パーセントでも上がるなら勉強するよ」
「むしろ日常使いつづけるんだから、勉強した分は確実に投資回収できるじゃん」
と、当たり前のように言い、皆一度は Excel の機能辞書や関数集を通読しています。
おぉ、こいつらプロだ。
こういう環境こそ、転職で得られた最大の収穫だったかも知れません。
2005年02月22日
情報処理技術者試験：キャッシュメモリの実効速度計算
基本情報処理技術者試験で頻出のパターンです。
これを覚えて下さい：
実効速度＝（キャッシュメモリの速度×ヒット率）＋（主記憶の速度×（１−ヒット率））
さて、キャッシュメモリとは、メモリ（主記憶装置）へのアクセスを高速化する技術です。続きの解説と出題一覧を読む
これを覚えて下さい：
実効速度＝（キャッシュメモリの速度×ヒット率）＋（主記憶の速度×（１−ヒット率））
さて、キャッシュメモリとは、メモリ（主記憶装置）へのアクセスを高速化する技術です。続きの解説と出題一覧を読む
2005年02月20日
グローバル変数：説明方法を変えてみようか
プログラマなら誰もが聞いたことのある「グローバル変数は使うな」という言葉。
「読みにくくなるから」との説明が多いけれど、「変化への対応が難しくなるから」というのはどうでしょうか。
結局は同じことを言っているけれども、プログラマやコーダーの視点での問題点よりも、プロジェクトやシステムの視点での問題点、悪影響を挙げた方が新人が「育つ」気がします。
顧客のビジネスモデル自体が変化への対応力を問われており、それを具現化したシステム、ひいてはプログラムにも変化への対応が求められます。それにアジャイル宣言の背後にある原則の２点目にも「変化の対応により顧客の競争優位に寄与する」との文言があり、若手プログラマ的にアツいトピックにつながりますし。
新たなバズワードの提案かも知れませんが、「読みやすさ」とか「保守性」よりも「変化への対応」の方が響く感じがするんですよね。
「悪態のプログラマ」より「グローバル変数が嫌われる理由」のトラックバックでした。
「読みにくくなるから」との説明が多いけれど、「変化への対応が難しくなるから」というのはどうでしょうか。
結局は同じことを言っているけれども、プログラマやコーダーの視点での問題点よりも、プロジェクトやシステムの視点での問題点、悪影響を挙げた方が新人が「育つ」気がします。
顧客のビジネスモデル自体が変化への対応力を問われており、それを具現化したシステム、ひいてはプログラムにも変化への対応が求められます。それにアジャイル宣言の背後にある原則の２点目にも「変化の対応により顧客の競争優位に寄与する」との文言があり、若手プログラマ的にアツいトピックにつながりますし。
新たなバズワードの提案かも知れませんが、「読みやすさ」とか「保守性」よりも「変化への対応」の方が響く感じがするんですよね。
「悪態のプログラマ」より「グローバル変数が嫌われる理由」のトラックバックでした。
クリティカルシンキングを支えるハート(心臓)
本屋を覗くとクリティカルシンキングが流行しているようです。
演繹と帰納といった基礎からMECEにロジックツリー、SWOTや4Pというツールに自省的思考が主だったテーマのようです。
そういったいわばビジネスで戦う上での筋トレ本の中にあって、筋肉に血液を供給する強い心臓を作ってくれたのがこの本。
他人に対する優しさの醸成と、自覚症状を感じてからの自分のメンテナンス
考えるを考える
思い当たるふしが、、
自分の思考のクセを知れ！
思考系の本100冊分
インパクトのある表紙ですが(笑)、中身はハードです。
この本で言う思考の生活習慣病とは以下の４点です。
これらに対処するための方策として７つの思考習慣、思考のシフトチェンジ、思考の基本動作が紹介されています。
私にもかなり思い当たるフシがありますね〜。特に最初の２個、放棄と依存。
考えよう、となればもちろんある程度以上の水準で考える自信はありますが、知らず知らずのうちに放棄や依存で思考回路にスイッチが入らないことがあります。
気づかぬうちにいつの間にか、というのがまさに生活習慣病。
いくら思考のテクニックを身につけても、頭が回り始めなければ意味がないですよね。
その怖さに気づかせてくれた良書です。
思考の生活習慣病に対処する方策もよく整理されていて「使え」ます。
演繹と帰納といった基礎からMECEにロジックツリー、SWOTや4Pというツールに自省的思考が主だったテーマのようです。
そういったいわばビジネスで戦う上での筋トレ本の中にあって、筋肉に血液を供給する強い心臓を作ってくれたのがこの本。
考えるプロが明かす「思考の生活習慣病」克服法
posted with amazlet at 08.05.10
船川 淳志
講談社
売り上げランキング: 134999
講談社
売り上げランキング: 134999
おすすめ度の平均: 
他人に対する優しさの醸成と、自覚症状を感じてからの自分のメンテナンス 考えるを考える 思い当たるふしが、、 自分の思考のクセを知れ！ 思考系の本100冊分インパクトのある表紙ですが(笑)、中身はハードです。
この本で言う思考の生活習慣病とは以下の４点です。
- 思考の放棄。例えば…
- これだけの情報では判断できないですよ
- だって私はプログラミングしかやってきてないですから
- そんな事考えたって意味ないよ
- やったことないからわかりませんよ
- 思考の依存。例えば…
- 経済誌にそう書いてあったからです
- だって皆もやってるじゃない
- やはりこれからはアスペクト指向だな！
- 先輩もそうやってきたし変える必要はないです
- 思考の歪み。例えば…
- 日本は島国なので閉鎖的だ
- アメリカは犯罪が多く危険だ
- 値段を下げろ、消費者は安価な物を求めている
- プログラマは喋るのが嫌いだよね
- 思考の偏り。例えば…
- 知識が不足する分野の議論で声の大きい人に納得してしまう
- 同じロジックなのに自分の立場を俎上に乗せると結論が変わってしまう
- Windows と Linux を技術的な観点から評価しているはずが開発モデル論になってしまう
- 設計の美しさと同様のこだわりが運用への配慮に表れない
これらに対処するための方策として７つの思考習慣、思考のシフトチェンジ、思考の基本動作が紹介されています。
私にもかなり思い当たるフシがありますね〜。特に最初の２個、放棄と依存。
考えよう、となればもちろんある程度以上の水準で考える自信はありますが、知らず知らずのうちに放棄や依存で思考回路にスイッチが入らないことがあります。
気づかぬうちにいつの間にか、というのがまさに生活習慣病。
いくら思考のテクニックを身につけても、頭が回り始めなければ意味がないですよね。
その怖さに気づかせてくれた良書です。
思考の生活習慣病に対処する方策もよく整理されていて「使え」ます。
ゲンバで使ったSQL：レコードの存在だけ確認
ゲンバでプログラミングをしていて、開発途上だとテーブルが空になっていないか、あるいはある条件に当てはまるデータがあるか知りたい時があります。
単純に Select すればいいんですが、もし存在していたらとんでもない件数返ってくるかも知れない…なんて時は rownum を使って返ってくる行数を指定します。
こうすると２未満、すなわち１行だけ返ってきます。
単純に Select すればいいんですが、もし存在していたらとんでもない件数返ってくるかも知れない…なんて時は rownum を使って返ってくる行数を指定します。
select 従業員番号
from 従業員表
where 部署 = つくば工場
and rownum < 2
こうすると２未満、すなわち１行だけ返ってきます。
2005年02月19日
図表のタイトルには内容の説明よりもメッセージを
プレゼンテーションや報告書で使う図表のタイトルには、内容の説明よりもメッセージを使うべき。
これ、社会人になってから教わって目から鱗が落ちました。
同じ図表やチャートでもタイトルは「過去10年間の製品別売上の推移」よりも「重要製品は化粧品から健康食品に移っている」の方が優れている、というわけです。
そもそもドキュメント全体の目的が意見の主張や意思決定者の説得やならば、その論拠をデータで示した図表だって、何がしかのメッセージを読み手に対して発しているはずです。というよりも、書き手は発したくてその図表を載せたはずです。
純粋な統計資料ならば、図表自身が示す「事実」をタイトルにすればよいけれど、
プレゼンならば図表を使って自分が伝えたい「メッセージ」をタイトルにすべき。
なるほど。
最近はメディアリテラシーとか総合科目とかあるらしいから違うかも知れないけれど、私が小学校の時なんかでは図表のタイトルは図表が伝える「事実」を採用しなさい、って教わった気がする。
これ、社会人になってから教わって目から鱗が落ちました。
同じ図表やチャートでもタイトルは「過去10年間の製品別売上の推移」よりも「重要製品は化粧品から健康食品に移っている」の方が優れている、というわけです。
そもそもドキュメント全体の目的が意見の主張や意思決定者の説得やならば、その論拠をデータで示した図表だって、何がしかのメッセージを読み手に対して発しているはずです。というよりも、書き手は発したくてその図表を載せたはずです。
純粋な統計資料ならば、図表自身が示す「事実」をタイトルにすればよいけれど、
プレゼンならば図表を使って自分が伝えたい「メッセージ」をタイトルにすべき。
なるほど。
最近はメディアリテラシーとか総合科目とかあるらしいから違うかも知れないけれど、私が小学校の時なんかでは図表のタイトルは図表が伝える「事実」を採用しなさい、って教わった気がする。
2005年02月18日
お金以外の仕事の報酬、５品目
仕事の報酬は普通、お金ですよね。
でも金銭以外の報酬もあると思います。
もちろん、受け取る金額の大小はキャリアを測る一つの指標ですし、それを大きくしたいという欲求もあります。
でもキャリアを構築しようと考えた時、いわゆる「現物支給」である金銭よりも重視すべき報酬もあるんじゃないでしょうか。
私はそれに以下の５点を挙げたいです。
ん〜、言葉選び自体は色々迷いました。明日には別の言葉を選んでいるかも知れません。
（得に「評判」を間に挟むべきか）
でも「よりよい仕事をするために働く」というのは一つの答えだと思います。
でも金銭以外の報酬もあると思います。
もちろん、受け取る金額の大小はキャリアを測る一つの指標ですし、それを大きくしたいという欲求もあります。
でもキャリアを構築しようと考えた時、いわゆる「現物支給」である金銭よりも重視すべき報酬もあるんじゃないでしょうか。
私はそれに以下の５点を挙げたいです。
- 知識。本からは得られない、ゲンバの暗黙知が得られるのは仕事を通じてのみ。また形式知も実践的。成長に繋がる。
- 人脈。仕事を通じ、具体的なスキルとそれが生む価値を互いに熟知し、熟知してもらった仲間。適切な情報をもたらしてくれるし、人生の刺激にもなる。
- 成長。蓄積された知識とスキルを具体的な価値創出につなげる能力は、仕事を通じなければ得られない。
スポーツにおける試合勘のように、ゲンバにいなければ身につかない何かを得、養うこと。 - 評判。名声欲を満たす。人脈を媒体に成長した姿を知られること。
- 仕事。より高い評判がよりよい仕事を連れて来る。
よりよい仕事って何か？
それはより知識が得られ、人脈が拡がり、成長できて評判も上がるような仕事。
ん〜、言葉選び自体は色々迷いました。明日には別の言葉を選んでいるかも知れません。
（得に「評判」を間に挟むべきか）
でも「よりよい仕事をするために働く」というのは一つの答えだと思います。
2005年02月13日
ゲンバで使ったSQL:縦並びデータを横並びに変換する
つまりこういう事。
を
にするには、
システム間連携なんか、こんな感じでレイアウト変換することもあるんじゃないかな。
| 氏名 | 科目 | 点数 |
|---|---|---|
| 佐藤 | 英語 | 60 |
| 鈴木 | 数学 | 70 |
| 鈴木 | 英語 | 40 |
| 佐藤 | 国語 | 90 |
| 佐藤 | 数学 | 70 |
を
| 氏名 | 英語 | 数学 | 国語 |
|---|---|---|---|
| 佐藤 | 60 | 70 | 90 |
| 鈴木 | 40 | 70 |
にするには、
insert into 変換後
select 氏名 as 氏名,
sum(decode( 科目, 英語, 点数, 0)) as 英語,
sum(decode( 科目, 数学, 点数, 0)) as 数学,
sum(decode( 科目, 国語, 点数, 0)) as 国語
from 変換前
group by 氏名システム間連携なんか、こんな感じでレイアウト変換することもあるんじゃないかな。
英語はキャリアアップの武器にはならない
私は一応、外資系企業に勤めていて社内公用語は英語なんですけど、英語は苦手です。
具体的に言うと TOEIC で 550 に微妙に届かないくらい、技術書もなんとか辞書を引きながら理解できるかな、って程度です。
外資系に転職して英語できるようになった？なんて聞かれますが、実際には英語アレルギーが無くなった、ってくらいです。
この Blog の「使えるリンク」にも英語のサイトを入れていますけど、普段英語で情報収集しているわけではなくて、それができるようにならないとね、と自分に言い聞かせるために貼っています。
でも最近つくづく思うのは、「ある程度以上を目指すなら英語ができることで有利にはならない。英語ができないことで不利になることはあるけれど」ということ。
「現代の読み書きそろばんはパソコンと英語」と言うけれど、そういうリテラシーって決して武器にはならないですよね。
パソコン、例えば Excel が得意でもそれが「キャリア」を意識するようなレベルでは意味がないのと同じで。
はぁ、書いてて憂鬱になってきた。
具体的に言うと TOEIC で 550 に微妙に届かないくらい、技術書もなんとか辞書を引きながら理解できるかな、って程度です。
外資系に転職して英語できるようになった？なんて聞かれますが、実際には英語アレルギーが無くなった、ってくらいです。
この Blog の「使えるリンク」にも英語のサイトを入れていますけど、普段英語で情報収集しているわけではなくて、それができるようにならないとね、と自分に言い聞かせるために貼っています。
でも最近つくづく思うのは、「ある程度以上を目指すなら英語ができることで有利にはならない。英語ができないことで不利になることはあるけれど」ということ。
「現代の読み書きそろばんはパソコンと英語」と言うけれど、そういうリテラシーって決して武器にはならないですよね。
パソコン、例えば Excel が得意でもそれが「キャリア」を意識するようなレベルでは意味がないのと同じで。
はぁ、書いてて憂鬱になってきた。
情報処理技術者試験：ベンチマークも過去問で
前回は過去問が得点力を伸ばす一番の方法だ、という話をしましたが、過去問でもう一点、外せない話題がありました。
過去問で自分のベンチマークを取ろう
という話です。
具体的には、できるだけ早い段階で過去問か過去模試を本番と同じ時間でやって自分の得点源、失点源を知ろう。そして失点源を重点的に勉強しよう、ということです。
当然ですが、出題範囲とされている全分野から同じ配分で出題されるわけではありません。また、人によって得意不得意もあるはずです。
にも関わらず、勉強となると全分野に同じ配分で取り組んでしまうという非効率的な方法に陥りがちです。
資格のための勉強の目標は合格点に達することですから、唯一の進捗管理指標は本番での得点力のはずで、今日は問題集が何ページ進んだか、では学習の進捗を測ることはできません。
仮に過去問をやってみてネットワークは合格水準、データベースはイマイチ、となったとします。
ならばネットワークは試験直前までメンテナンス程度の勉強にとどめてその分の時間をデータベースに当てた方が効率的なのは明らかです。
また法律関連は出題比率が小さいので、思い切って一切勉強しないという選択肢もありえます。それは極論にしても、出題比率の大きい分野の勉強が一段落して自信がついた後まで手をつける必要はないでしょう。
こういった判断を下すための基礎情報として、本番形式での過去問演習は非常に使えます。
限られた学習時間、効率的に使って無理なく無駄無く合格に近づきましょう。
過去問で自分のベンチマークを取ろう
という話です。
具体的には、できるだけ早い段階で過去問か過去模試を本番と同じ時間でやって自分の得点源、失点源を知ろう。そして失点源を重点的に勉強しよう、ということです。
当然ですが、出題範囲とされている全分野から同じ配分で出題されるわけではありません。また、人によって得意不得意もあるはずです。
にも関わらず、勉強となると全分野に同じ配分で取り組んでしまうという非効率的な方法に陥りがちです。
資格のための勉強の目標は合格点に達することですから、唯一の進捗管理指標は本番での得点力のはずで、今日は問題集が何ページ進んだか、では学習の進捗を測ることはできません。
仮に過去問をやってみてネットワークは合格水準、データベースはイマイチ、となったとします。
ならばネットワークは試験直前までメンテナンス程度の勉強にとどめてその分の時間をデータベースに当てた方が効率的なのは明らかです。
また法律関連は出題比率が小さいので、思い切って一切勉強しないという選択肢もありえます。それは極論にしても、出題比率の大きい分野の勉強が一段落して自信がついた後まで手をつける必要はないでしょう。
こういった判断を下すための基礎情報として、本番形式での過去問演習は非常に使えます。
限られた学習時間、効率的に使って無理なく無駄無く合格に近づきましょう。
情報処理技術者試験対策：過去問がすべて！
私はまだソフトウェア開発技術者までしか持っていませんが（この春にDBを受験予定）、情報処理技術者試験に限らず、資格試験対策に最も効果的なのは過去問から学ぶことです。
得点力を伸ばすという意味では、過去問を解き、学ぶ以上の効率的な学習方法は無いです。これは言い切っても良いと思います。
というのも、資格試験というのは過去に出された問題が繰り返し使いまわされる傾向にあるからです。
出題する側から見れば、
という制限の中で、毎年（基本情報処理技術者試験なんかは年２回）試験があり、新しい問題アイディアを出し続けるのは困難だからです。
その中で「この資格を持つ者がこれを外しちゃいけないだろ」→「出題しないわけにはいかないだろ」というポイントはさらに限られていきます。
結果、毎年似たような問題が繰り返し出されるわけです。事実、私が基本情報処理技術者試験やソフトウェア開発技術者試験を受けた時も、会場で「あ、この問題知ってる」というのがかなりありました。「これわかる」ではなくて「これ知ってる」です。過去問こそ最も的中精度の高い予想問題です。
また、「どう聞かれるか」を知ることも強力な武器になります。これは資格を通じた学習という意味では邪道ですが、最短で合格を目指すためには王道です。
例えば今私が勉強中の DB 試験では、正規化は必須知識です。これ、基礎的な概念であるために様々な覚え方がありますし、10人のエンジニアに聞いたら10通りの説明が帰ってきそうです。
ところが DB 試験では「この表は第何正規形か。それはなぜか」という問い方が頻出です。そして回答例も各社「（推移的）関数従属なので〜」となっています。様々な覚え方があっても、試験対策上はこのキーワードを解答欄に書けるかどうかがポイントです。
試される知識を、試される形で身につけることができる過去問こそ、最高の教材です。
さて、この Blog では今後、情報処理技術者試験対策カテゴリで主に午前問題の過去問、それも頻出問題に絞って出題例と回答をメモっていこうと思います。
得点力を伸ばすという意味では、過去問を解き、学ぶ以上の効率的な学習方法は無いです。これは言い切っても良いと思います。
というのも、資格試験というのは過去に出された問題が繰り返し使いまわされる傾向にあるからです。
出題する側から見れば、
- 出題範囲が決まっている。初心者には広く感じても、有限であることは間違いない。
- 年度ごとの難易度のバラツキは許されない。大量の受験者を、例年と同じレベルで合格／不合格に振り分けねばならない。
という制限の中で、毎年（基本情報処理技術者試験なんかは年２回）試験があり、新しい問題アイディアを出し続けるのは困難だからです。
その中で「この資格を持つ者がこれを外しちゃいけないだろ」→「出題しないわけにはいかないだろ」というポイントはさらに限られていきます。
結果、毎年似たような問題が繰り返し出されるわけです。事実、私が基本情報処理技術者試験やソフトウェア開発技術者試験を受けた時も、会場で「あ、この問題知ってる」というのがかなりありました。「これわかる」ではなくて「これ知ってる」です。過去問こそ最も的中精度の高い予想問題です。
また、「どう聞かれるか」を知ることも強力な武器になります。これは資格を通じた学習という意味では邪道ですが、最短で合格を目指すためには王道です。
例えば今私が勉強中の DB 試験では、正規化は必須知識です。これ、基礎的な概念であるために様々な覚え方がありますし、10人のエンジニアに聞いたら10通りの説明が帰ってきそうです。
ところが DB 試験では「この表は第何正規形か。それはなぜか」という問い方が頻出です。そして回答例も各社「（推移的）関数従属なので〜」となっています。様々な覚え方があっても、試験対策上はこのキーワードを解答欄に書けるかどうかがポイントです。
試される知識を、試される形で身につけることができる過去問こそ、最高の教材です。
さて、この Blog では今後、情報処理技術者試験対策カテゴリで主に午前問題の過去問、それも頻出問題に絞って出題例と回答をメモっていこうと思います。
コンピュータが理解できるコードなら誰でも書ける。優れたプログラマは人間が理解できるコードを書く。
Martin Fowler, Refactoring, 1999 より。
オリジナルは 'Any fool can write code that a computer can understand. Good programmers write code that humans can understand.' 日本語訳はピアソンエデュケーションから「リファクタリング プログラミングの体質改善テクニック」というタイトルで出版されています。
良いプログラムの指針として覚えておきたい格言ですね〜。
よく「コメントの多いコードが人間にとって理解しやすいコードだ」という人もいるけれど、本当の意味での理解しやすさは、コード自身が「自分は何をするか」を雄弁に語っているものだと思います。
そういったコードは大抵、設計が素直でネーミングがうまいんですよね。この Refactoring の中でも、ネーミングは訓練すべきスキルだとされています。関数内のある処理に名前をつけたいがために、そこを別関数に切り出すことまでしています。
そう、ネーミングって意識して伸ばしていくべきスキルなんですよね。やってないけど。(^^;
英語は苦手だしな…
オリジナルは 'Any fool can write code that a computer can understand. Good programmers write code that humans can understand.' 日本語訳はピアソンエデュケーションから「リファクタリング プログラミングの体質改善テクニック」というタイトルで出版されています。
良いプログラムの指針として覚えておきたい格言ですね〜。
よく「コメントの多いコードが人間にとって理解しやすいコードだ」という人もいるけれど、本当の意味での理解しやすさは、コード自身が「自分は何をするか」を雄弁に語っているものだと思います。
そういったコードは大抵、設計が素直でネーミングがうまいんですよね。この Refactoring の中でも、ネーミングは訓練すべきスキルだとされています。関数内のある処理に名前をつけたいがために、そこを別関数に切り出すことまでしています。
そう、ネーミングって意識して伸ばしていくべきスキルなんですよね。やってないけど。(^^;
英語は苦手だしな…
