若者の体力と時間を浪費する伝統()

もういろいろテンションMAXなので書く。だいぶ前から言いたかったことだ。


とある日本のIT企業の話。
そこでは毎年入社3年目の若手社員に、これまでの業務で得た経験や成果を重役の前でプレゼンさせるというイベントがある。
それだけならまだ良いのだが、このイベント、

・深夜残業、徹夜、休日出勤してパワポの準備して当たり前
・プレゼンは「業務」ではないので残業代つかない

という謎な伝統()があるそうだ。
もっとも最近は残業代も支払われるようになり幾分ましになったとのことだが。
しかもこれ、上長や先輩社員まで残業して指導につきあうとのことで、もうなんのこっちゃである。

■疑問1
なぜ、たかが社内向けのパワポ作成に徹夜までしなければならないのか?

若手社員は会社の指示でパワポ準備させられてるのだろう。
であれば通常業務時間内に作業するのが筋だ。それができないから徹夜までしてるのだとすれば、管理職が作業管理できてないからと考えられる。
管理職も「このイベントだし、パワポだし、これがフツー」と捉え、若手の負担を減らす気がないのが見え見えである。

■疑問2
なぜ若手だけでなく他の社員も残業してまでつきあうのか?

推測の域を出ないが、
パワポの出来が部署の評価につながるから(ボーナスとか)
・自分も先輩に同じように指導されたから
こんなところじゃないだろうか。

部署ごとの対抗意識に巻き込まれる若手はたまったもんじゃない。
同じように指導されたからだとすると、自分の後輩には同じ思いをさせたくないと考えはしないのだろうか?
自分だったら、パワポなんてテキトーにやっとけ、徹夜すんなって言うけどなぁ。


■疑問3
そもそもこのイベントいるの?

このイベントの意義は何なのか。
単に若手の成長を確認したいのなら、各上長に「若手の作ったプログラム見せてよ」「受注した案件教えてよ」と問い合わせるだけじゃ駄目なのか。
成果物だけでなく、その背景まで知りたいのなら、ワードのレポートを提出させれば十分じゃないのか。
わざわざ多大なりソースをかけてパワポ作らせてプレゼンさせてって、そこまで下駄を履かせないと立派に見えないような成果しか上げてませんよ、そんな仕事しかさせてませんよ、と認めてるようで気持ち悪い。

ほんとうにイイ仕事してるなら、内容を簡単に説明させるだけで伝わるんじゃないか。



この会社に限らず、似たような行事があるところは割と多いらしい。
何の利益も生み出さないパワポ合戦に若手の貴重なリソースを費やすくらいなら、その時間で最新開発技法の研修受けさせたり、テレアポやらせたりするほうが1024倍効果的だと思うのだが、経営者の皆さんには是非ともご一考をお願いしたいところでございます。

『はじめての現代数学』瀬山士郎 早川書房(2009)

230ページの文庫本を読みきるのに何日かかったのか……数学本は面白いけど時間泥棒ですね!

あたくし文系出身とは言いながら高校時代に一番得意だった科目は数学だったりします……。なんで文系に進学したのか自分でもわからない。それはさておきこの本、数学科出身の友人から送ってもらったのですが、古代ギリシャの世界からはじめてゲーデル不完全性定理ポアンカレ予想まで、現代数学の有名トピックをきっちりはっきりわかりやすく、正直わかんないところもあったけど、や、わかりやすく解説してくれる良書でした。


代数学とは、「モノ」から「コト」への転換であった。つまり、「5次方程式の一般解の公式は存在するか?」という問が「方程式の一般解の公式が存在するとはどういうことか?」という問に変わったとき、現代数学の入口が現れたわけですね。


何度Wikipediaを読んでもわからなかったゲーデル不完全性定理の言いたいこともだいぶ納得できた。無限の大小の話も面白かった。自然数の数と偶数の数は等しい。ほえー。ホモトピーホモロジーの違いはよくわかんないのでそのうち再読します。そのうち……


紙と鉛筆と頭脳で世界の真理に挑戦する学問、数学。心底カッコイイって思っちゃいます。先ごろABC理論の証明のニュースも世界を駆け巡りましたが、いずれあれの解説本も出るんでしょうなぁ。読みたいなあぁ。

1 「モノ」から「コト」へ

1-1 現代数学のイメージ

1-2 代数方程式の解法についての構造主義的方法

1-3 非ユークリッド幾何学の発見と別世界への旅

1-4 解析学における無限取り扱いマニュアル



2 無限の算術・集合論

2-1 再び「モノ」的無限へ


2-2 果てしない無限の彼方

2-3 集合論内の矛盾の発見と数学の危機



3 柔らかい空間・トポロジー

3-1 近さの発見から位相空間

3-2 位置とつながり方の幾何学(1) グラフ理論

3-3 位置とつながり方の幾何学(2) ホモロジー理論

3-4 位置とつながり方の幾何学(3) ホモトピー理論



4 形式の限界・論理学とゲーデル

4-1 納得、説得と論理

4-2 論理の記号化

4-3 正しいことと証明できることの違い

4-4 模型としての論理の無矛盾性と完全性

4-5 形式の限界・ゲーデル不完全性定理



5 現代数学の冒険

5-1 あいまいさの数学・ファジイ理論

5-2 複雑さの数学・フラクタル理論

5-3 不連続現象の解析・カタストロフィ理論

5-4 コンピュータと現代数学四色問題をめぐって

5-5 現代数学・その意味と形式

睡眠時間への挑戦

昨年あたりからベストな睡眠について考えている。

自分にとってのベストな睡眠時間は8時間であり、22時就寝6時起床という生活リズムが作れれば完璧、だと思っていた。

ところがどうもそうではないらしいことがわかってきた。まず22時に寝ても26時(2時)に寝たとしても起きる時間があまり変わらない。7時くらいに目が覚め、暗い寒いと言いながら二度寝し、結局8時過ぎに起きて慌てて身支度をする。アイマスクをしたり目覚ましをかけたりと色々な方法を試したがこのリズムが変わらない。

それならいっそ毎日遅くまで起きてやれ、ということで今年は2時3時まで平気で起きて本読んだりプログラミングしたり、時には事務所でフツーに仕事してたりします。まだ日中目を開けるのが辛いときもありますがそのうち慣れるでしょう。

今まで寝ていた22時から2時3時までの時間を毎日使えるのなら年間1500〜1800時間のアドバンテージ。なんかわくわくしますね。体壊さない程度に自分の睡眠時間に挑戦していく所存でございます。

技術のわからないSE()にはなりたくない

こちらの小説を読んでみて色々と思うところあり。

Press Enter ITエンジニアは定時退社の夢を見るか?
人形つかい
http://el.jibun.atmarkit.co.jp/pressenter/2011/05/1-17a8.html

フィクションとはいえ読んでいて思わず寒気がしました。

主人公はITベンチャーに勤めるプログラマーの細川マモル。SI業界大手のエースシステムから受注した案件に携わることになります。

このエースシステムにいるいわゆる上流SE()が本当にクソ。

設計担当の橋本は単純なSQLも書けないほどプログラムの知識がないが、プログラムの経験がないことを恥とも思っていない。むしろプログラミングなど誰でもできる下等な作業だと思っている。
プロマネ的立場の上級SE()・高杉は顧客から/社内からの自分に対する評価を下げないことにしか興味がなく、プロジェクトがデスマに陥っても作業者をほったらかしにしてクリスマス休暇を取るほどの鉄の心臓の持ち主。当然プログラマのことは人とも思っていない。

まぁフィクションですし、ここまで魂の腐ったSE()はいまどきいないと思いますが(いないよね?)。

しかしながら、「プログラムなんて下等な作業」と考えている自称SE()は意外といるようです。5年前、就活中に業界最大手と呼ばれるSIerを何社か訪問しましたが、
システム開発の技術に興味があります!プログラミングとか!」と話した途端
「うちはSEの会社だよ。プログラミングなんかやらないよ」と社員の方に冷たく突き放された経験があります。
「うちとはアンマッチだよ」という助言ではなく、SEを名乗りながら明らかに技術に興味がなく、むしろ技術者を見下すような物の言い方でした。あまりに腹がたったのでそこの面接はキャンセルしてやりましたが(笑)。

システム開発に携わっていながらプログラミングの経験を積んでいないことは、わたしにとって大きなコンプレックスです。日々プログラムを組み上げていく技術者の方々は尊敬の対象です。

技術を馬鹿にする自称SE()とは死んでも仕事したくない。技術のわからないプロマネにはなりたくない。
去年はPMBOKやEVMなどマネジメントの技術・理論にシフトして勉強していましたが、今年はプログラミングの勉強にも力いれてこうと思います。

『社畜のススメ』藤本篤志 新潮社 (2011)

基本働きたくない人間なもので、脱社畜ブログこちらのブログなど愛読しております。それだけで何も考えていないと「残業悪!休出悪!9時5時万歳!」的な考えに精神を蝕まれて没落リーマンまっしぐらですので、たまにこういう本を読んでバランス取る必要があるわけで。

社畜のススメ (新潮新書)

社畜のススメ (新潮新書)

第1章「自分らしさ」の罪

第2章「個性」が「孤性」になる悲劇

第3章 会社の「歯車」となれ

第4章 ビジネス書は「まえがき」だけ読め

第5章 この「ウソ」がサラリーマンをダメにする

第6章 「クレバーな社畜」がベストの選択

終章 運、縁、恩

この本から一言キーワードを抜き出すなら守破離です。
守破離」は世阿弥が説いたとされる成長プロセスに関する教えで、14世紀〜15世紀の人物であることを考えればその不変性は言わずもがな。

そのメッセージは第3章に凝縮されています。

「守」の段階では、師に決められた通りの動き、形を忠実に守る。「破」の段階では、「守」で身につけた基本に自分なりの応用を加える。そして「離」の段階では、これまでの形に囚われず、自由な境地に至る。(p.59)

つまり、サラリーマンとして成功したいならば必ず「守」の段階を経なければならない、つまり「会社の歯車」=「社畜」として働くプロセスが重要である、というのが著者の主張です。
世にはびこる個性重視なビジネス本の著者の皆さんも、その多くが「守」のプロセスを経てきている。*1
もちろん、体や精神を壊すほどのあまりに理不尽な指示にまで耐える必要は無いと付け加えています。


わたしの場合入社3年目くらいまではかなり上司の言うこと聞いて一生懸命働いていたら見事にメンタルぶっ壊した経験があるので、ここ数年は上からの指示に素直になりきれなかったところがあります。
ただ、今の自分がふらっと会社から飛び出して、どこかで独り立ちしてやってけるの?と言われると、そんなことは無いわけでして。


自分なりの方法論を唱えるにも、上司の批判をするにも、まずは「守」のプロセスを経なければダメですね。


明日は仕事はじめ。リフレッシュした頭とキモチでまた働きます。

*1:例外は本当の天才だけ。孫正義さんなど

『ずっと受けたかったソフトウェア開発管理の集中研修』翔泳社(2010)

2013年、あけましておめでとうございます。
新年一発目のエントリはこの本から。

ずっと受けたかったソフトウェア開発管理の集中研修

ずっと受けたかったソフトウェア開発管理の集中研修

目次

オリエンテーション


第I部 基礎技術
第1章 ソフトウェア開発管理の基礎知識
1.1 ソフトウェア開発プロセス
1.2 ソフトウェア開発の問題と開発管理
1.3 ソフトウェア開発管理とは

第2章 品質保証と品質管理
2.1 品質保証とは
2.2 品質の作り込み
2.3 品質管理

第3章 見積りと工数管理
3.1 見積りとは
3.2 代表的な見積手法
3.3 工数管理

第4章 リスク予測と進捗管理
4.1 リスク予測とは
4.2 リスクの種類
4.3 リスクの評価とリスク対応計画
4.4 リスクを意識した進捗管理


第II部 演習
第5章 演習の進め方
5.1 演習の進め方

第6章 品質の作り込みと管理
6.1 要件定義工程
6.2 設計工程
6.3 製造工程
6.4 テスト工程
6.5 品質保証の勘所

第7章 見積りと見積精度の管理
7.1 積み上げ法による見積り
7.2 FP法による見積り
7.3 見積りの見直し
7.4 見積りの勘所

第8章 リスク予測とリスクの管理
8.1 上流工程のリスク
8.2 下流工程のリスク
8.3 リスク予測の勘所

前半部分がソフトウェア開発管理(プロジェクトマネジメントではない)の概論、
後半が実際の開発事例を用いた演習という構成になっている。
ソフトウェア開発管理で「管理」すべき重要な要素はQCD(Quality Cost Delivery)であり、
第2章〜第4章のそれぞれがQ C D に対応しているという構成*1
単純明快でわかりやすいけれど意外とこういう構成の本は無かったような気がする。
見積りのセクションではEVMにも少しだが触れており、
FP法からUMLによる業務分析につなげてもいるし
そろそろ管理者としてのキャリアを考えないとという年次の人にとって、
各専門書への入口となる内容として良書だと思います。
あぁオブジェクト指向分析勉強したいいぃ。


テスト目標件数と摘出バグ件数からエリア分析を実施して品質チェックを行う手法は
初期開発時だけでなく保守時にも応用できるようにしときたいなぁと思った。
そのためにはちゃんとクラス設計しとかないとだめなんですよねぇきっと……。


後半の演習はさすが実際の開発をベースにしているだけに
リアリティがあってのめりこんでしまいました。
要件定義書のレビューから業務分析、
各フェーズにおけるリスク分析、云々。
これ教科書にして勉強会やるとなかなか楽しいんじゃないですかね。
中堅〜ベテラン層の方のご意見がぜひ聞きたいところです。


常日頃ぷろまねぷろまねと唱えているわたくしですが
「プロジェクトマネージャー」を目指す前にまずは
「ソフトウェア開発管理者」として一人前にならなきゃいけないな、
と再考した一日でございました。
PMBOKは抽象度が高いのであればっかりやってると評論家になっちゃいそうでコワイ。


本年もよろしくお願いいたします。
次はオブジェクト指向分析の本読もう。

*1:見積り、リスク分析はCおよびDに重複する

『デザインのためのデザイン』ブルックス ピアソン桐原(2010)

『人月の神話』でおなじみブルックスさんの本。

デザインのためのデザイン

デザインのためのデザイン

人月の神話

人月の神話

合理的モデルは非現実的

デザインの最も困難な部分は、なにをデザインするかを決めることである。(p.22)

合理的モデル≒ウォーターフォールモデルと言い換えて良いでしょう。
目指すべきゴールがはじめから決まっており、それに向かって一直線に突き進むようなモデルは成り立たない。なぜなら顧客は本当に欲しいものが何かわかっていないから。
それでもなお多くの現場でウォーターフォールモデルは盲信され、使用されている。実際にはうまいこと動いちゃいないのに。

素晴らしいデザイナを雇う、育てる、守る

・すべての専門的な技能は「実習とその批評」を通して習得される。必ずしも基礎科学を修める必要はない。コンピュータサイエンスにおいても早期にデザイン実習と批評を始めることが重要だが、そのようなカリキュラムを設けているところは少ない。(p.238-239)
・すぐれたデザイナを雇うには面接ではなく直接成果物を見ること。(p.240)
・管理者ではなく「技術リーダー」を育てるには、時間をかけて、多彩な実務と正規の教育(大学の集中講義など)を受けさせることが大事。(p.240-242)*1

「素晴らしいデザインは素晴らしいデザイナから生まれる - 素晴らしいデザインプロセスからではない」

http://blog.livedoor.jp/dankogai/archives/51563028.html


ソフトウェアディベロッパーたるもの、顧客に対して「要件コロコロ変えるなよ」なんて愚痴るなんてもってのほか。要件をどんどん引き出してフィックスさせるのが僕らの仕事。

あと社内教育の重要性。日本のIT企業*2って教育の仕組みがあるとは言っても概論ちょろっと教えておしまいとか、外部講師を呼んできておしまいとか、そんなのが多い気がする。ITが高度な専門知識と経験を必要とする業界だってことをもっと認識しないといけないんじゃないですかね。

そして教育された内容をしっかり実践できる職場を用意することですね。
レガシーシステムのおもりを若手にやらせてるようなところは猛省しないといかんじゃないでしょうか。

*1:なんだか泣けてきたぜこの野郎

*2:ITゼネコンとも言う。