『なぜ、コンピュータープログラミングは楽しいのか。なぜ、僕を含めプログラミングに携わる人々は、何度も辛い目に遭いながらも、この職種から遠ざかる事が出来ないのか・・・？』

　この問いに対する答えが下記のサイトに載っていました。ここには、プログラミングの本質的な楽しさが書かれています。

　» Why is programming fun? An extract from Fred Brooks' (Frederick P. Brooks Jr.) book, The Mythical Man-Month

　以下、抜粋した引用です。難解な部分もある英語ですが、可能な限り、僕のつたない超意訳も併せて載せます。

Why is programming fun?
　（なぜ、プログラミングは楽しいのか？）

The below is an extract from Fred Brooks' (Frederick P. Brooks, Jr.) book, The Mythical Man-Month. This is one of the best explanations of why programming is so interesting. It touches on all aspects of the mystique of programming.
　（下記は、フレッドブルックス（Frederick P. Brooks, Jr.）の本、題名「人月の神話」から抜粋したものです。これは、「なぜプログラミングがこんなにも面白いのか？」と言う問いに対する理由の中で、最も素晴らしい説明の1つです。それは、プログラミングの神秘的な面、全てに言及しています。）

The book was first published in 1974 and then republished in 1995. What Fred Brooks had to say then based on his experiences with the development of the OS/360 system is still relevant today.
　（この本は、1974年に初版が出版されて、それから1995年に再版されました。OS/360システムの開発に接したフレッドブルックスが、その当時彼の経験から言った事は、今日でもそのまま適応できます。）

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design.
　（第一に、プログラミングには、物を作る本当の喜びがあります。子供が泥のパイ作りに喜びを得るように、大人が、物作りを楽しむように、特別な物を、自分自身の設計で作り出す事が出来ます。）

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office."
　（第二に、プログラミングには、他の人にとって有益であるものを作り出す楽しみがあります。心の奥底で、私達は、自分達が作った物を他の人に使ってもらい、それが役に立つとわかって欲しいと思っています。この点でプログラミングシステムは、子どもが始めて作る「パパのオフィスの為」の粘土製鉛筆ホルダーと、基本的に同じです。）

Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.
　（第三に、プログラミングは、可動部分を連結し、それらが微妙なサイクルで動くのを見る事、つまり、複雑なパズルのような対象を形作る魅力があります。原則によってもたらされる結果の展開を初めから組み立てられます。プログラムされたコンピュータには、ピンボールマシンやジュークボックス機構が惹き付ける魅力の全てがあります。そして、最後までやり通せます。

Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.
　（第四に、プログラミングには、常に学ぶ喜びがあります。問題は常に新しいものです。そして、問題を解く人は常に何かを学びます、時には、実地で。時には、論理的に。そして、時々は両方から。）

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (...)
　（最後に、プログラミングには、とても扱いやすく加工しやすい媒体で動かせる楽しみがあります。クリエイティブなほとんどメディアはこれほど柔軟でありません。そして、磨き、調整するのがとても簡単で、すぐに、壮大な概念構造を形作る事が出来ます。）

Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separately from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.
　（それでも、それが動き、実際に作用するという点で、プログラム構成要素（それは、詩人の言葉とは明らかに異なる）はリアルです。そして、目に見えるアウトプットを構成された概念そのものから作り出します。それは結果を印刷したり、絵を描いたり、音を出したり、機械の手を動かします。「神話と伝説の魔法」は、我々の生きている今、この時代に実現しました。人々はキーボードで的確な呪文を入力します、そして、表示スクリーンは生き生きと反応します。そして、今まで無かった、存在することも出来なかったものを見せてくれます。）

Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.
　（プログラミングは、全ての男達が同じように持っている喜びの感情と、我々の奥深くに眠っている創造的な欲望を満足させるので、プログラミングは楽しいのです。）

　僕は、これら全ての意見に同意します。

　これを見て、プログラミングに対する、僕の中でもやもやしていた物が霧が晴れたようにすっきりしました。仕事として携わり、生きる糧として使用される泥臭いアイテムの中で、これほどまでに楽しく、人を惹きつける物は他にあるでしょうか。

　この職種のキャリアパス的には、プログラマから足を洗って、ほとんどソースを見ることの無い、プロジェクトマネージャーになったり、プログラム開発とあまり関係のないSEになったりする事が、多々あると思います。

　僕もすっかり最近は、業務でプログラミングしなくなりましたが、そんな事になったとしても、プログラミングと言う魅力ある作業に、無理やりでも触れていきたいなぁと、この文章を読んでぼんやり考えました。

　今読んでいる本。

　これまで、簡単な英文法の本と単語だけで英文を読もうと思っていたのですが、いよいよ限界を感じ始めてきたので、この本を手に取ってみました。

英語リーディングの秘密 薬袋 善郎 研究社出版 1996-10 売り上げランキング : 37724 おすすめ平均 Amazonで詳しく見る by G-Tools

　この本は英語の構文を品詞ごとに細かく分類して、理論的に英語を読み進める手伝いをしてくれる本です。普段からプログラミング言語に慣れ親しんでいる、理屈っぽい...いや、理論的思考を持った、IT業界の方々にぴったりだと思います。

　英語と言うものが、文系だけではなく、いわゆる「理系」と言われる方々にも興味を持っていただけるような、論理的に考えるコツと言うものが書いてあります。少なくとも僕は、「この発想は今まで無かった」、と面白く感じています。

　中には、構文解析の為に記号が山の様に出てきますが、これがなんともプログラミング言語的な雰囲気を感じさせます。

　で、まだ半分ほどしか読めていませんが、この本を読み進めていくうちに、英語の記述方法と、プログラミング言語の共通点がなんとなく見えてきました。

　僕が、こんな共通点を無理やりでも見つけようとする原因の一つは、「プログラミング言語と似てるなら、英語も時間さえ掛ければ理解出来るだろう」と言う考え方を持って、やる気を少しでも高めたいからです。

　今のところ、僕が「英語」と「プログラミング言語」で似ていると思う共通点を列挙してみます。

• 英語は、曖昧さが非常に少ない言語。きっちりしたルールで記述しないと文法的におかしくなったり、全く別の意味になってしまう。
• プログラミング言語の命令で使用するパラメータが、いわゆる英語の5文型に良く似ている。
• 不定詞や分詞構文が、プログラミング言語で言う、「関数のポインタ」の考え方に良く似ている。
• 文の主従関係が、プログラミング言語で言う、「ネスト」の考え方に良く似ている。
• プログラミング言語のコメントは、英語の形容詞や副詞。無くても通じるけど、無いと無機質だし、いろんな人に受け入れてもらえない。
• プログラミング言語で最も重要なのは、命令文。英語では動詞が最も重要。

　だんだんとこじつけっぽくなって来たので、この辺でやめますが、よくよく考えてみれば、プログラミング言語のそもそもの成り立ちは、英語的な考え方を持った欧米人が作成した言語なので、似通うのは当然かなと思いました。

　でも、今までプログラミング言語と戯れてきた、IT技術者の考え方として、「英語 ≒ プログラミング言語」だと思う思考法は、下記の2つの点でよいことだと思いました。

• 「英語がプログラミング言語に似ているなら、英語も頑張れば出来るんじゃないか」と言う希望を持てる。
• 「プログラミング言語が英語に似ているなら、プログラミング言語なんて英語に比べれば簡単じゃないか。」と言う楽観的な希望を持てる。

　以前、この件について書きましたが、『社運を賭けていると言われる「大作」』は、どうやら本当に発売延期となってしまったようです。

　以前書いた記事。

　» 社運を賭けていると言われる「大作」や「大規模システム開発」は大概成功しない法則

　ニュース。

　» 「ドラクエIX」発売延期の理由は　「油断していた」と和田社長 - ITmedia News

　延期した理由について、記事では下記の様に書かれています。

　実装が済み、本格的なデバッグに入った段階で「手強いバグがいくつもあることが判明した」という。バグの量は「とてもお客様に出せる状態ではない」ほど大量。「もう少しチューニングしようというレベルではなく、今出すべきでないことは明らかと判断した」

　延期に対する理由になってませんね。延期に至る要因と言うのは、必ずデバッグ中に発生します。実装中に遅れが発覚するようなケースは通常考えられません。もし実装中に何か起こった場合は、コンセプトや方針自体が変えられていくはずです。ですから、下記の発言に繋がっているわけですね。

　その上で「ドラクエやスク・エニに固有の問題が起きているわけではない」と釈明。

　しかし、「大作」とそうでないシステムでは、明らかに違う点があります。

　以前書いた僕の記事から引用しますが。

　「社運を賭けてる」と言われているシステムは、大概期限がきっちり定められています。それは、社運を賭けているがゆえ、業務計画としてある程度外向けに情報を公開しなければならないからです。それは株主に影響を及ぼすため、一度決めた計画を簡単には変更できません。

　つまりは、普通のシステム開発よりもはるかに計画変更がしづらいのです。この計画変更のしづらさにより、そもそも期間が変更されるリスクがとても高い大規模なシステム開発とは、性質が合わなくなります。

　どうも、上記の発言からして、『製品固有』の問題とは思ってない節があります。これではまた遅れるのではないでしょうか。そんな予感がしてなりません。

　実際、この発売延期によって、発売が期を跨いだため、業績予想を下降修正することになってしまいました。これにより、さらに計画変更がしづらいと言う、プレッシャーが圧し掛かってきています。

　延期された『4ヶ月』と言う期間についても、延期後の発売日が「7月11日」と言う事ですので、どうも夏休み前のタイミングにずらしただけと言う感じがします。

　社運を賭けるべき主力製品がある事は、とてもすばらしいですが、大作であるが故の難しさもあるのだなぁと感じます。必ずしも、定期的に発売する必要がない、連作物のゲームについては、前宣伝を極力せず、不定期に発売するなど、別の方向性からアプローチした方が良いのかもしれません。

　そう考えてみると、Nintendoは、狙ってるのか知りませんが、こういう事しませんね。さすがと言うべきなのか。

≫　現場のSE, PGが考えるデスマる条件とは:アルファルファモザイク

1 仕様書無しさん :2008/06/03(火) 22:07:26

当方１年目の新人です。"デスマ"と言うのを最近知りました。
勉強になると思うので箇条書きかなんかで挙げていただけないでしょうか。

答え
　現場の手が決して届かない上層の政治的な部分から来る、長期的な観点から見て、会社が存続するためにやむをえない事情がある場合に起こりやすい。その辺りがそもそもの根本原因。

　・・・だと思う。現場が思いつく条件なんてのは、所詮事前に逃げる為の参考にしかならないのだと思う。悲しいのだけど、これが現実。

　現場が思いついた条件はいくらでも出せるのだけど、いくら並べても解決にならないのがデスマの難しい所。

　たとえば・・・。

• 予算が決まっている。
• 納期が決まっている。
• 仕様書が固まらない。

　などなど、良く言われるデスマーチの条件は、その会社が存続する為にはそうする必要があるからそうなってるのだと思われます。

　もし逆に、

• 臨機応変に予算が変更できる。
• 納期がコロコロ変えられる。
• 常に仕様書がきっちり固まってから始まる。

　と言う会社だと、さっぱり仕事が取って来れず、デスマ以前に会社が存続出来ない可能性があります。そういったやむをえない事情から、必然的にデスマになりやすい風土が作られていくのだと思いますよ。

　結局デスマを生む会社の存続が更なるデスマーチを生んでるって事ですかねー。結果、そのような会社が一掃されないと無くならないって結論だと、お先真っ暗になってしまいますね。困りました。

参考になる
≫　「現場のSE, PGが考えるデスマる条件とは」 - カレーなる辛口Javaな転職日記

　もう、現場レベルではこれが全てです。

　下記のはてな匿名ダイアリーを読んで。

≫　来年出る大作が相当ヤバイことになってるらしい

　「大作」と言われるゲーム開発を始め、IT業界における大規模システム開発は、その事例自体、元々失敗するファクターを多くはらんでいると思います。大規模であればあるほど、原因は特定の人間でない事が多いです。

　現場にやる気がないのだけは真実らしくて、それは一番偉いクリエイターが気まぐれすぎて下請け会社の作業がストップしたことがあるからだと言っていた。

　これは非常に良くあるケースです。

　大作を作るための下地や準備期間があまり無く、見切り発射すると、方向性を決める権限が特定の人物に集中しがちです。決められたコンセプトだけが一人歩きして、伝達する手段がなく、それを具現化するチームも存在しないため、下請けまで砕かれた仕様が伝わらないのでしょう。

　「社運を賭けてる」と言われているシステムは、大概期限がきっちり定められています。それは、社運を賭けているがゆえ、業務計画としてある程度外向けに情報を公開しなければならないからです。それは株主に影響を及ぼすため、一度決めた計画を簡単には変更できません。

　つまりは、普通のシステム開発よりもはるかに計画変更がしづらいのです。この計画変更のしづらさにより、そもそも期間が変更されるリスクがとても高い大規模なシステム開発とは、性質が合わなくなります。

　「大作」と言われるゲームの場合、オリジナル（パート1）はそのようなプレッシャーや明確な期限が引かれていない為、比較的自由に開発を行うことが出来ます。しかし、そのゲームが当たってしまい、大作と呼ばれるようになると、上記の様な金銭が大いに絡むプレッシャーが乗っかってきて、パート1では普通に出来ていた自由度のある開発が束縛され、どんどんやりにくくなります。

　これは、銀行やガス、電気などのインフラのシステムでも同じことが言えます。絶対に止めてはいけないと言われる業種では、そもそも大規模システム開発と言う物自体、相性が良くないです。

　このような状況で開発を始めると、現場サイドと上層部の意識に必ず隔たりが生まれます。プレシャーをまともに受ける上層部と、遅れを取り戻せない現場サイドでは意識的ギャップが大きすぎて、上手く意思疎通が図れません。

　「気まぐれ」と言われてしまったクリエーターも、上層的な意識に取り込まれている為、現場サイドから見ると気まぐれに見えるのかも。

　一旦このような状況になるともう手が付けられません。根本的な原因が分からない限りは、どのような応急対策を行っても永遠に遅れを取り戻せません。大作と名が付き、続編となってしまった時点で、そのゲーム開発の性質が変わってしまったのです。

　まぁ、だからと言って、大規模システムを成功させる秘訣なんてものは僕には分からないのですが。

　少なくとも、特定の個人を非難するのはおかしいと思いますよ。

関連記事
　» 社運を賭けていた「大作」がどうやらうまく行かなかった件 - 涙目で仕事しないSE

≫　成果主義が失敗したいまだからこそ、社員が仕事に燃える理由を探す：NBonline(日経ビジネス オンライン)

　文頭から文末まで、全編に渡って同意出来る、素晴らしい記事です。全てのマネージメントに関わる人々が読むべき文章だと思います。僕は基本的に全て激同意なので、自分の意見は入れられないかも知れませんが、注釈を入れながら紹介していきます。

　ここに書かれている事が、まさに僕の身近な所で起きています。

しかし、2000年代初頭に入り、成果主義の流れは行き詰まってきた。「成果に応じて給与が上がる」と言われても魅力を感じなくなってきているのである。1990年代以前は年功序列的な処遇が定着しており不公平感があったため意味があったと考えられるが、年功序列的な処遇が多くの企業で崩壊している現在では、社員に成果主義は魅力的に映らない。

　元々、成果主義には懐疑的でした。結局、管理される側からすれば、成果主義といわれても、制度的な置き換えと言う観点でしか見ていません。「なーんだ、給与体系がちょっと変化しただけか・・・。」なんてすぐ見透かされてしまいます。そして、形だけの成果主義が未だ続いている状態です。

　成果主義が導入された当初は、「仕事してる分、せめて給料が上がらないとやってられないよ。」と言う考え方にある程度マッチしていましたが、最近そんな言葉さえも聞かなくなりました。一時的に潤うカンフル剤のようなアメでは、効果が出なくなってきたのだと思います。

　そして、下記の6つの背景。誰もが感じている事だと思います。近年における労働の6大傾向と言っても良いのではないでしょうか。

1. 上昇を求めない社員が多い（または増加した）
2. サービス業の感情労働という特性
3. 仕事の難度の高まり
4. 職員の志向の複雑化
5. 権威の喪失
6. 成果主義制度に対する慣れと諦め

　僕も全てに思い当たる節があります。全てが、仕事への動機付けはお金で解決できないと言う方向を示唆しています。全てのバックグラウンドは、職が確保されれば、いくら不況とは言え金銭面で必死になる機会がほぼなくなったと言う事じゃないかと思います。

　このような背景から、「内発的動機付け」が無ければ、社員はすすんで仕事をしないと言う事に繋がっていきます。その手法として6つの手法を提案しています。

（1）自己認知支援 （2）安心できる環境づくり （3）成長機会提供 （4）哲学形成 （5）使命感の創出 （6）コミュニケーション

　「知識労働者」と言われる職種の動機付けは、この6つの手法に則って仕組みを作ってやれば上手くいきそうな気がします。たとえばIT業界の場合、マネージメントの立場から出来るのは、下記のような事ですかね。

(1)自己認知支援
　職務的権限をまずハッキリさせる。決裁権限など金額的な線引きはきっちり行って、迷いが無いようにする。個人の出来る出来ないを切り分けやすくするため、チーム内メンバーの役割を明確化する。

（2）安心できる環境づくり
　ベースは安定した給料。また、サービス残業をなくし、残業に対する報酬は必ず支払われるようにする。休日や夜間呼び出しなどを出来る限り無くす仕組みを作る。（保守と開発の線引きを明確化する）特定の社員に負荷が集中しない体制を作る。

（3）成長機会提供
　成長を促進する為、業務時間内でチャレンジ出来る体制とその発表機会を作る。教育制度を確立させ、体系化した社員教育を行う。可能であれば、転職したときでも役に立つような知識と資格を取れるような制度にする。

（4）哲学形成
　最初は絵に描いた餅でも良いので、企業理念やビジョン、経営方針などを掲げる。その理念等が利益だけでなく、社会的価値へと繋がっている事が望ましい。

（5）使命感の創出
　企業理念に則って、実現可能なレベルの目標を設定する。それらの目標はいくつかに分けて、個々のグループでそれがクリア出来る様に仕向ける。

（6）コミュニケーション
　複数の部署に渡って横断的な作業チームを作り、全体で考えなければいけない課題を与えるか、飲み会を開くでも良いと思う。今は少なくなったけど、社員旅行とかを見直して、定期的に行うのも良いかもしれない。

　1以外は、もはや平の１社員が出来ることでは無いのですが。6はまぁ出来なくもない。たとえ部下が数人だったとしても、その中でやれることはあると思います。

　どちらにしても社員一人ひとりが「腑に落ちた」という状態まで話し合わなければ意味がないと記事では書かれています。そういう意味で、このピラミッドの最も下の層では、「直属の上司と部下の間での意思疎通」と言うのがあるのかもしれません。

　僕自身もモヤモヤしていた事が、この記事を読んでだいぶ「腑に落ち」ました。しばらくこれをテンプレートにして仕事していきたいと思います。

≫　プログラマの慢心。IT業界の現状。より

ブラックジョークらしいのだが、完全に否定できない。

どこかしらに心あたりがあるからだ。

　...と言う事ですので、より実情に沿った感じで、ソフトウェア開発にありがちな無限ループ。

１．仕様書通りにプログラマがコードを書く。仕様書は正しいと信じている。

1. プログラマがコードを書く。バグはないと信じている。

２．製品テストが行われ、10のバグと10の仕様漏れ、10の新たな要望が発生する。

2. 製品テストが行われて30個のバグが発見される。

３．プログラマは10のバグを直し、10の仕様漏れは調整が必要と放置。10の新要望は全くやる必要が無いとやっぱり放置。

3. プログラマは20個のバグを修正し、残り10個はバグではないとテストチームに説明する。

４．再び製品テストが行われ、バグ修正の結果、15の新たなバグが発見される。さらに10の仕様漏れと10の要望が実現されないとリリース出来る水準にならないと言う話になる。結局、プロジェクトリーダーが折れて追加案件が20増える。

4. 再び製品テストが行われ、バグ修正の結果5つの機能が正しく作動しなくなっていることが発見される。さらに15個の新たなバグが発見される。

５．上記の工程3、4を数回繰り返す。

5. 上記の工程3、4を数回繰り返す。

６．途中から追加機能が増えたにも関わらず、当初のボリュームに基づいて作られたスケジュールは変えられず、中途半端なままリリース、出荷が行われる。

6. マーケティング部が楽観的な開発計画に基づいた製品発表を行ったことや、営業部からの圧力により、製品が時期尚早に出荷される。

７．ユーザにより100のバグと、数多くの「使えねぇ」と言う声、そして、肝心の売り上げ自体芳しくないと言う状態になる。

7. ユーザにより100個のバグが発見される。

８．嗅覚が鋭いプログラマやSEは、この焦げ臭いプロジェクトから逃げ始めるか、出来なければ転職する。

8. プログラマが他社に転職する。

９．残念ながら逃げられなかった現プロジェクトメンバーに加え、新たなメンバーを加えた急ごしらえのチームが編成されるが、新旧メンバー間のコミュニケーション不足と、新メンバーの理解度のなさ、そして無茶なスケジュール等々の原因から、新たに500のバグが生まれる。

9. 緊急で新たに開発チームが組織され、ほぼすべてのバグを修正する。その過程で新たに500個のバグが生まれる。

１０．プロジェクト全体の歪みから、リーダー格のメンバーが次々と過労やうつ病により休職する。

10. テストチームのエンジニアが過労やうつ病により休職する。

１１．構造的な問題を解決するために、全体的に手を入れ、ソフトを作り直すべき、と言う結論に達し、現状やその業種自体に詳しくない、新たなメンバーが採用される。

11. 構造的な問題を解決するために一から開発し直すべきだという結論に達し、新たなプログラマが採用される。

１２．現状や業種に詳しくない新たなメンバーが仕様漏れを起こしつつ仕様書を作成する。

１．仕様書通りにプログラマがコードを書く。仕様書は正しいと信じている。

　以後、無限ループ。

　下記の記事を読んで。

≫　プロジェクトの遅れを取り戻す方法10選

　遅れてしまったプロジェクトの遅れを取り戻す方法として下記の方法が書かれています。

＃1：残業する
＃2：リソースの再割り当てを行う
＃3：すべての依存関係を入念に確認する
＃4：一定の時間を必要とする作業を把握しておく
＃5：リソースを入れ替える
＃6：スケジュールを圧縮する
＃7：ピッチを上げる
＃8：スコープの変更を阻止する
＃9：プロセスを改善する
＃10：作業のスコープを縮小する

　確かにもっともと思える記事ですし、内容は分かるんですけど、どうも絵に描いた餅みたいで僕には、ピンと来ないです。

　多少分かりやすい言葉で、逆に「プロジェクトの遅れを取り戻せない方法10選」を考えてみました。

1. とにかく残業で取り戻そうとする
2. 闇雲に追加人員を投入する
3. 初期のメンバーに対し、追加された人員へのレクチャーを迫る
4. このプロジェクトは特別な物で、デスマーチはやむを得ないと説得する
5. 『頑張って』もしくは『努力して』遅れを取り戻すと口にする
6. 遅れてるにも関わらず、初めの計画通り仕上げようと固執する
7. 朝一に何も考えないで、とにかく行動を起こす
8. 日々のゴールを設定せず、先の見えないゴールを目指して走る
9. 費用対効果を考えない計画の継続、または変更
10. 自分にできない事を出来ると思い込む

　これらを実行しなければ、より快適な社会人ライフ、SEライフが過ごせると思います。

　一応、目指してはいるのですが、なかなか難しいです。

関連記事
≫　プロジェクトの遅れを取り戻す方法10選 - finalventの日記

　そうそう。本当は、こういうのを書こうとしてたんだ。

Original update by tateru
この頃はコンピュータへの純粋な夢があった...

　今日から海外旅行へ出かけます。

　行き先はヨーロッパで、明日から28日までの日程です。いまや、どこのホテルでもインターネットの接続環境があるので、モバイルノートを持っていって接続しようかと思いましたが、せっかくの海外旅行ですので、この機会に断ネットして色々な事を吸収してこようと思います。

　この間、コメント等出来ませんのでご了承願います。

　本題はIT業界についてです。今までこのブログでもこの件について色々書いてきました。今回は、今までの記事を纏めつつ、IT業界への思いや、なんやかんやを書いてみようと思います。

IT業界には夢が無くなった？

　結構古い本ですが、村上龍著「13歳のハローワーク」に興味深い記述があります。

Q：ITに関連する仕事について、13歳の子どもたちに、どう説明すればいいでしょうか？

たとえば、今、インターネット用電話回線をほとんど独占している電話会社は、ただの土管屋さんになるかもしれない。今、NTTが持っているもので重要なのは、実は、電信柱と土管だけなんです。だから10年後には、NTTは電信柱と土管の会社になっている、とかね。SEは、たとえば道路に立っている標識とか看板を描く人、みたいになっていくかもしれません。標識でも、看板でも、今はどんどん自動化されて、実際に標識を作ったり看板を書いたりする仕事はあまり必要なくなっているでしょう？

　これは現在、僕がひしひしと感じている事です。コンピュータが十分過ぎる程普及し、身近となった今、それと同期するようにして「有るのが当然」と言う考えが生まれてきます。その為、新しく物を創出するよりも、インフラを維持していく方向性に流れが偏っていきます。

　今後も創出する人は一定の割合で居ると思いますが、インフラ維持の人員がどんどん増えていくため、上記の例のように「IT」と言うイメージ全体が将来的には道路工事屋や土管屋のイメージへ傾いていきます。

　僕は、この流れを避けることは出来ないと思います。なぜなら今までの歴史を見ると新しいテクノロジーは有る程度時間を経ると、ことごとく泥臭いイメージへ変わっているからです。電話しかり、電力しかり。これらも登場当時はかなり持てはやされたのだと思います。

　どのテクノロジーにも、夢の総量が減ってしまう問題は存在します。どんな最先端技術でも一般化して、最後には普及する時代がやってきてしまいます。それは、とあるテクノロジーが十分普及し、皆が等しく便利になった事への裏返しです。

　これからの子供（実際問題として僕の娘や息子）に、数年後のIT業界全体を説明する機会があったら、下記の様な事を言おうと考えています。

　『未来のIT業界全体に夢は少ないよ』と。

　純粋に技術的なテクノロジーに夢を見出す時期は終わりを告げ、今後は、ITを使って一体何をやらせたいのかと言う段階へと入って行きます。ITでやりたいことを作り出す人々は、IT業界の人である必要がありません。

　こういった事から、純粋なIT業界に対する夢と言うのはあまり存在しなくなりました。

システムエンジニアと言う職業

　そもそも、職業自体の価値、夢に関しては、『システムエンジニア』と言う職業、役割自体に顕著に現れています。

　主に要件定義や仕様書を書き、プログラミングを行わないのがシステムエンジニアの定義だとすれば、自ら新しいものを生み出さないと言う意味で、システムエンジニアは子ども達に夢を与えない最たるものかもしれません。すでに「インフラ維持組」の仲間入りです。

　もちろん、システムエンジニアの中にも新しい技術を生み出す人はいるでしょう。しかし、全体数からの割合で、単純作業を生業とするインフラ維持のSEが増えてくれば、比率的にみて、システムエンジニア自体は、「道路工事の現場監督」と言うイメージに落ち着くはずです。

　実際、新卒者から見たシステムエンジニアのイメージはそちら側に傾いているのではないでしょうか。

　これが新卒者がIT業界を目指さない原因の一つだと思います。

　IT業界に携わる人々が、誰かが作った道を手直ししている今の現状では、近いうち労働コスト面でオフショアに負けてしまいます。これでは、後はぺんぺん草も生えないような悲惨な状態が待っています。

IT業界の労働環境問題

　子供への説明はひとまずおいといて、新卒者が敬遠する要因の一つとして、今まで書いてきたことに輪を掛け、「デジタル土方」と揶揄される労働環境悪化の問題があります。

　これは、いつか記事にしようと思っていた記事ですが、ここで出します。

≫　IT業界不人気の理由は？ 現役学生が語るそのネガティブイメージ － ＠IT

「トヨタ自動車やソニーのようなユーザー企業と違い、IT（の導入）しか行っていないNTTデータのような会社が一番謎」といった疑問が出た。イメージを聞かれても、そのイメージ自体が何もないという皮肉な答えだ。別の学生からは「（情報を発信するテクノロジなのに）IT業界が何をしているのか分からないのは問題」といった、そもそも論も聞かれた。

　おそらく、この問いに対するはっきりした答えは出せないと思います。なぜなら、前の節で述べたように、ITは世に十分普及していて、もはや『インフラ維持』の段階に入っています。そこへ来て、「何を作り出しているの？」と聞かれても、本音は「現状を維持している」と答えるしかない訳です。

　いくつか挙げられたIT業界のイメージは実にネガティブな内容だった。いわく「きつい、帰れない、給料が安いの3K」に加えて、「規則が厳しい、休暇がとれない、化粧がのらない、結婚できない」の"7K"というイメージだ。学生は、ほかの業界と比べて「IT業界は特に帰れない」というネガティブな印象を強く持っているようだ。

　IT業界がインフラ維持段階に入っている事を認識せず、危機感が無いまま現状に甘んじていると、このようなネガティブイメージは絶対に払拭出来ません。

　この中でも根強い、「帰れない」と言うネガティブイメージは、おそらく帰れないのが嫌なわけではなく、IT自体の成果物がはっきりイメージ出来ず、時間を費やした分の対価が見出せないと言う事ではないでしょうか。問題は、モチベーションだと思います。ITへ携わる事に対して価値が与えられる必要があります。

　下記の発言はむかむかしますね。

　ネガティブイメージを突きつけられた浜口氏は、「必ずしも全員が3Kではない」と反論。岡本氏も「3Kの"帰れない"は、帰りたくない人が帰れないだけ。スケジュール管理の問題だ。

　これは、思考停止の最たるものです。IT業界を牽引する重鎮としての役目は、業界に対して常に深い関心を持つことだと思います。この様な席で、自分の意見を言ってる場合じゃない。

　この業界では「デスマーチ」と言う現象が時たま発生します。これはプロジェクトに携わるメンバーの思考を停止させ、時にはメンバー達を再起不能に追い込む恐ろしい現象ですが、重鎮達だって過去、一度はそのような思いをしてきたはずです。

　質問した学生達だって、そのような現象は時たまが起こりうると、十分調べた上で質問を投げかけています。この場合、自らの過去の経験と照らし合わせて素直に、帰れない現状がある、と言うべきです。現実を認める事から今の労働環境の改善は始まります。無関心は一番の悪です。

じゃあ、子供たちにはなんていえば良いのさ

　IT業界に興味を持ってもらった子供に対し、将来のIT業界について伝えるべき事は少なくなっています。職業として就く場合、目指す方向を指南するとしたら、下記の2つしかないと思います。

• プログラマとして、可能な限りクリエイティブな職場に就く。
• ITを使って何かを創り出す？と言う、ITの枠を超えた方面に就く。

　プログラミングと言う事自体に興味を持つなら、前者へ。ITを含めつつ、色んなことに価値を見出したい場合は後者へ。この中間にはあまり夢がありません。

　はっきり書くと、「システムエンジニアにはなるなよ」、です。悲しいけど、これ現実なのよね。

　もしくはあえて職業にせず、趣味的に関わるという方法もあります。それが一番幸せなのかも。

そういう世界に居る僕らは何をすべきなのか

　今どっぷり浸かってしまっている僕らは一体何をすべきなのか。

　まず大切な事は、ある程度無駄な時間、または投資だと感じても、新しいことに対し関心を持ち続ける事だと思います。

　たとえプログラミングを専門としないシステムエンジニアだとしても、普段PCを使っているので、アプリケーションは試せます。新しいアプリやwebサービスの噂を聞きつけたら、ベータ版の内にすぐ飛びつく様な姿勢が大事だと思っていますし、僕も可能な限りそうありたいと心がけています。

　また、クリエイティブな事を作り出すにしても、メタ開発的手法を作り出すにしても、いまやITの技術だけではダメで、むしろITの枠を超えた範囲に対しても関心を持つことが必要です。

　僕自身は、どんな駄文でも「ブログを書き続ける」行為がそういった事に繋がっていくと感じています。ブログで文章を書く行為は、意外に色々なスキルが試されます。

　単純な文書作成能力だったり、アイデアを考え出す能力だったり、トレンドを掴んで良いタイミングで記事を発信することだったり、アドセンス広告をいかにクリックしてもらうかと言うテクニックだったり、ブログのデザイン能力だったり・・・。

　ブログは単なる一例です。おそらく今の現状に甘んじている人々は、いわゆる「インフラ維持系IT要員」となり、どんどん単純作業化される今後の流れに落とし込まれていきます。そこには誰しも夢見ていたはずのクリエイティブなIT業界はありません。

　あなたは自分に対して、どんな事をしますか？

　最終的に、今ブログ書きに浪費してる時間を正当化させる為の壮大な言い訳でした。（笑）

　最後まで読んでいただいてありがとうございました。

　では、旅立ちます。

参考になる関連記事をつらつらと
≫　ニッポンIT業界絶望論:江島健太郎 / Kenn's Clairvoyance - CNET Japan
≫　どうせ理系出身者なんていらねえんだよ。
≫　IT業界がいいのは、つねに勉強せざるをえないこと
≫　10年泥が嫌ならITお勧めだよ - 雑種路線でいこう
≫　衰退していくIT業界に向けて、30半ばシステムエンジニアが昔の思い出を語るよ 0001
≫　cpainvestor.com | 超長時間労働を厭わない組織風土をいかにして変えていくべきか

下流から見たIT業界: SEとPG、どっちが頭がいい？（1）
下流から見たIT業界: SEとPG、どっちが頭がいい？（2）

　タイトルは釣りっぽいですが、上記の記事で、2回に渡ってシステムエンジニアとプログラマについての関係が書かれています。

　そもそもアメリカなど欧米諸国では、『システムエンジニア』と言う職種自体、存在しないんですね。これは知りませんでした。"SE"が、"OL"と同じレベルの和製英語だったとは。ここのブログのタイトルも「涙目で仕事しないPG」に変えようかしら。

　システムエンジニアの定義について、wikipediaでは、以下のように書かれています。

1. 顧客の要求に対する聞き取りをして要求定義を行い、構築する情報システムの内容を明確化する。
2. 定義された要求を実現するために構築するソフトウェアとハードウェアの設計を行う。
3. ソフトウェアの構築とハードウェアの調達を行う。
4. 構築するシステムのテストを実施する。
5. テストにより発見されたバグの修正を行う。
6. テストに合格したシステムを構成管理して稼動開始させる。
7. 稼動したシステムの運用管理を行う。
8. 運用管理の成果に基づき、顧客にシステムの改善を提案する。
9. 以上の全域に渡り、システム構築のプロジェクトマネジメントを行う。

　職種の役割的な観点から言って、システムエンジニアと言う職種上、意地でもプログラミングはしないと言う事ですね。ここにプログラミング作業さえ入れば、システムエンジニアとプログラマはほぼ同化します。同化出来ると言う事は、「プログラマ＋上流工程＝システムエンジニア」と言う理論になり、上とか下とか、頭が悪いとか言う話が出て来るんだと思われます。

　また、職務権限的な観点だと、上記の記事では以下のように書かれています。

日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だ

　SEとPGの出来始めは、おそらくそうだったのでしょう。人を出すときのユーザー説明への妥協点として、製造者と管理者的な区分が必要だったのかもしれません。しかし、今ではこの区別も業界全体が複雑化して、適応できないものになりつつあります。基本2つしかないのは荒っぽすぎる。僕なんかどっちかなんて切り分けられないし。

　だったら、SEって職種いらなくね？

　細かく分けるなら分ける、無くすなら無くす、どっちかにするべきだと思います。

　職務権限（課長とか主任とか）と、開発時の役割（プログラマとシステムエンジニア）が企業の中で混在してるためこのような問題が起きるのでしょう。

　最近は新たな妥協点として、『主任SE』とか、『上級SE』とか更に良く分からない職種（職務権限？）が登場しています。普通の主任とか、普通の課長との違いが僕にはよく分かりません。やってる事は同じっぽいし。もう、どうでも良いです。

　僕なりの結論としては、『SEとPGは単なる役割であって、上も下もない。職務権限とごっちゃにするから話がおかしくなる。しかも職種権限でさえも、上とか下とかもないし。権限も役割の一つ。』と言う事で。

　元記事に戻りますが、（２）の記事では、IT業界の空洞化について非常に鋭いところを突いています。

現在のIT業界で「SEとPGのどちらが頭がいいか」と問われたら、「どちらも頭は空っぽだ」と答えざるを得ません。これは技術者個人個人の責任ではありません。明らかに企業のアウトソーシング戦略の結果です。単に頭が空っぽなだけならまだしも、このような技術者が多数派になってしまったおかげで、技術に対する浅薄な侮りと無知が蔓延（まんえん）するようになってしまいました。

　まさにこの通りですね。全てを外注して、自社としては、一体何を残すつもりなのでしょうか。究極的には、アウトソーシング技術だけが高まっていくトンネル会社のようになってしまいます。会社に流されているといつの間にか空っぽ人間になってしまうかも。自発的なスキルアップは必至です。

　・・・と、IT業界の片隅でぽつりと愚痴ってみても状況は悪くなるばかり。これが時代の流れなのかもしれませんねぇ。

　最後に、村上龍著「13歳のハローワーク」を最近借りてきたのですが、こんな記述があります。

たとえばSEという職業ですが、新しい技術が次々と生まれて、ソフトも変化していくなかで、わずかな例外を除いて、システムエンジニアは最終的に不要になるかもしれません。

　と書かれています。異論を唱えたかったのですが、上手く答えられない。僕自身もそう感じるときがあるからです。

　これは13歳が大人になるとき何になりたいかを導く本ですので、今の情勢的にこの書き方は正しいと思います。

　今の子供が、本当にIT関連の職種に就きたいのであれば、システムエンジニアよりむしろプログラマを目指すべきです。今後予想される、技術抜きされて平均化されたSEと言う職種は、子供が目指すべき職業ではなくなります。

　楽しくなければ目指す価値も無いのですから。そういう点で、13歳の選択は意外にシビアです。

13歳のハローワーク - 村上龍（著）