インテル8080伝説を読んだ
いしかわさんの投稿を見て「これは買わねばなるまい」と思い、購入しました :)
- 作者: 鈴木哲哉
- 出版社/メーカー: ラトルズ
- 発売日: 2017/02/20
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
初版のみCD-ROMが付くということだが、出版社の購入ページから直接買えばCD-ROMがもらえるみたい。
さて
その内容ですが、70-80年代のマイコン世代であれば当時の空気を感じられることは間違いない。のですが、本書の肝は8080マイコンを作る！というところにあるので、ハードウェアの知識がないとちょっとツライかも。かく言う私は電子工作のところはイマイチ分からなかったです。
とはいえ、なるべく当時のノリで作ってみようという著者の心意気は十分に伝わります。そうそう、当時のマイコンは命令サイクル数からクロックが計算できたんだよな。EPROMに焼く時はインテルHEXフォーマットを使うんだっけ。そんな当時のことを思い出すことが出来ました。
最初に触れたコンピュータが、こういった素直な設計のハードウェアだったことに今更ながら感謝です。コンピュータの学習に大きな苦はなかったものね。これが今のマイコンクラスだったら、イヤになって投げ出してしまってたかもしれない。
プログラマに必要なスキル
私も自分なりに、プログラマとして必要なスキルをまとめてみる。
エンジニアにとって最も大切なことは、お腹が出ていないこと。
エンジニアに必要なスキルは - まなめはうす
と、１５年前に私の見ていたサイト界隈で決着がついたのですが、エンジニアである私が必要だなと思うスキルって自分の中では時折変わっているので並べてみます。
要約すると
ソフトウェア開発という仕事は「問題を調査し、原因に対する最適な解決策を考え、それを実現するコードを書いて問題を解決する」のループであると思う。これはバグ修正に限らず、ソフトウェア開発の全ての工程において言える。
といった観点から
私の考える「プログラマに必要なスキル」をまとめてみる。他にもいろいろあるけど、それは他の機会にでも :)
ソフトウェアを作るために必要な情報を探し出すスキル
プログラマであれば「こんなのをxx/xxまでに作って」と言われたことは経験にあるだろう。いや、大体そうか(汗)
それはググればすぐ分かることかもしれない。けど、大抵それは周りに詳しい人もいないようなことで、どこから手を付けたらいいか分からない。そんな時、大量の情報から必要な情報をピンポイントで見つけ出し、ソフトウェアをデザインする能力は重要だ。
そのためには色々なことに興味を持ち、情報収集を怠らない努力が必要だと思う。とはいえ、人間は全知全能ではないので、その分野に得意な人とコネクションを作っておくことも必要かもしれない。
動作するコードを素早く仕上げるスキル
これは id:maname さんの意見に賛成。testableなコードをいかに素早く実装できるかはプログラマにとって重要なスキルだ。
ここで重要なのは、単にコーディングの速度が早いというだけではなく、設計段階でどこまで実装を意識した仕様に落とし込めているかということだと思う。「ん？このケースはどうやって実装すればいいんだっけ？」というのを、いかに減らしておくかの方が重要なように思う。いくらタイピングが速くても、仕様変更ばかりではかえって時間がかかってしまうよね :)
何が問題なのかを突き止めるスキル
ソフトウェア開発に限らず、コンピュータを使っていると、様々な問題に遭遇する。それが自分が作ったモジュールであればいいが、実際にはどこに問題があるかも分からないことが多い。もっと言えば、ソフトウェアの問題だけとは限らない。
そんな時、当たりをつけて問題を絞り込み、原因を素早く発見する能力は重要だ。これについては経験を積む以外、いい方法が思いつかない。一緒に問題を調べてくれる、職場の同僚やその分野のエキスパートとのコネクションが、実は一番重要なのかも。
問題に対して最適な解決方法を提示できるスキル
問題の原因は見つけた。さて、どうやって解決しよう。単純なコード修正で終わることも多いが、複数のソリューションがある場合も少なくない。いや、そもそも思い込みから他のソリューションがあることに気がつかないこともあるだろう。
パフォーマンス、コードサイズ、データ量、プラットフォームにおけるバランス、互換性への配慮、などなど様々な条件から複数のソリューションを考え、その中からベストを提案できることは重要なスキルだと思う。とはいえ、全てを一人で決めることがベストではなく、複数の識者の知見をふまえて解決方法を提案できる人の方が優秀かもしれないと、最近は感じている。
とか書いてきたけど
出来てたら、こんなに苦労してないわ！あー、こんなプログラマに私はなりたい(笑)
アメリカで働くことは大賛成だけど、ちょっと考えて欲しいこと
類さんがシリコンバレーでソフトウェアエンジニア職に就くことに関してのエントリーを書いて、それが反響を得ているようなので、その雑感。
海外でエンジニア職に就くことの雑感 – Yoshifumi YAMAGUCHI – Medium
私も短い期間ではあったけどアメリカで働いていたことがあったので、所感など書いてみようかな :)
なお、何十年も前の話なのと、私の観測範囲においてなので、まあ参考程度に読んでいただければ幸いです。
ソフトウェアエンジニアならアメリカに行った方がいいか
という問いに対しては間違いなく行ったほうがいいと答えます。ぼくが言うまでもなく、コンピュータに関する技術は今も昔も多くはアメリカが発祥であり中心で、動きも早いです。日本とは全く違う文化に触れるだけでも、行く価値があると思います。また、アメリカのIT企業の多くはソフトウェア技術者の価値を知っているので、優秀であればとても快適な開発環境が体験できます。最先端でエキサイティングなチャレンジが出来る機会も多いですよ。
もちろん全てがバラ色とは言いません。でもそういったチャレンジが出来るチャンスは人生の中でそれほど多くありません。やりたいという気持ちがあればぜひチャレンジして欲しいな。
ただ、アメリカで長く働くということであれば
ちょっと考えてみて欲しいことがあります。
自分の成果を積極的にアピールしていくバイタリティが必須
アメリカは基本に成果主義であり、自分がしたことの成果は自身でアピールする必要があります。上司が自動的に評価したりはしません。「能ある鷹は爪を隠す」という言葉は忘れましょう。そうしないと「特に成果ないの？じゃあ君はうちとしては要らないね」って話になってしまいます。
あと成果として重要なのは結果です。会社/プロジェクトに対して自分がどんなふうに貢献できたのか、という形でアピールすることが大事。長時間がんばってました！みたいなのはあまり評価されないので注意しましょう。
転職は普通
日本と違ってアメリカでは普通にレイオフされます。長く一つの企業に勤めるより、次々と職場を変わっていく人の方が多いです。逆に言うと、転職については日本よりオープンであり、頻繁に転職したからといって、それがネガティブなイメージになることはありません。
異国の雰囲気に馴染めるか
そしてこれが一番重要なことだと思うのですが、長く暮らしていくにあたり、アメリカの雰囲気に馴染めるかどうか。
ぼくの場合、アメリカに住んでみて、あらためて日本って、なんて住みやすい国なんだろうって思いました。だんだん慣れて来るとは言え、やはり異国の地で暮らすというのはなかなか大変です。東洋人だと露骨にイヤな顔をする人とかもいます。表面的な付き合いをするお友達は多くできるでしょうが、親友を作ることはなかなか難しいです。強烈なホームシックになることもあると思います。
とはいえ、普通に暮らす分にはほとんど問題はありません。「どうしても日本じゃなきゃイヤだ！」って人でない限り、大丈夫でしょう :)
最初に書かれたコードが最も影響力が大きい
最初に書かれたコードって、すごく影響力大きいよね。
もはやファイルのタイムスタンプを確認するまでもないだろう、と私は思った。おそらくは、このシステムは構築の初期、ある程度はまともに作られていたのだ。しかし、そのまともに作ることのできるプログラマは「消えて」しまった。
あとを引き継いだ彼女は「消えた」プログラマほどの技量はなかった。彼女は「消えた」プログラマが残したフレームワークを理解することもできず、ただ、ソースコードを模倣した。
消えたプログラマの残したものは - megamouthの葬列
興味深いですね。
個人的には
プログラミング経験に関係なく、最初に書かれたコードというのは非常に影響力が大きいものであると感じてます。それはそのソフトウェアの設計思想を決定づけるものであり、脈々と受け継がれていくものだからです。優秀なプログラマであるないに関わらず、多くのプログラマは元の設計思想を尊重し、それに合わせたプログラムを書くもの。それがリライトした方が遥かにいい、ヒドいデザインのものでない限りはね :)
そしてプログラムがヒドいものになっていく原因の多くはこの「最初の設計思想」にあることが多いのです。いわゆる要求事項。このプログラムは誰が何のために使うのか。優先すべき性能はどこにあるのか。そして相反する要求があった時、何を基準に機能を決定するのか。もっと言えば、そもそもそのプログラムは必要なのか！？(笑)
そういった設計思想はコードに反映され、伝承されていきます。設計思想が曖昧なプログラムはその後場当たり的な対応がなされ、そのうち使えなくなって最後は捨てられます。書いてて頭痛くなってきた ^^;
そうならないよう精進しますです、はい。
そういえば
カーゴ・カルトという言葉を初めて知りました。盲目的なコピペコード、うんうん、あるよね、そういうの。反面教師にします :)
残業を減らそうだけじゃ、単なる思考停止じゃない！？
もう30年以上前の話。まだ社会人になって数ヶ月あまり、定時で帰ろうとした私を「ちょっとちょっと」と課長が呼び止めた。何かなと思って行くと「仕事というのは定時になったら帰っていいものではない」と説教された。「？」と思ったが、まだ新人だった私は素直にその日は意味もなく残業。それを見ていた先輩社員も「オレも昔はよく怒られたなあ」と言っていたから「そんなものなのかな」と思ったけど、今そんなことしたらパワハラものですな :)
IT業界に限らず、残業が減らない原因の根幹はこれだと思う
表面的には「早く帰れ」「効率的に」などと言っていたとしても、本音の部分では違っていたりしますから、そのニュアンスは社員にも伝わり、どんな施策をとったとしても、その徹底度は薄れてしまうでしょう。
「何でもいいから4時に帰れ。できないなら辞めろ」…この命令は正しかった | ダ・ヴィンチニュース
結局のところ、いくら会社が「早く帰れ」と言っても、上司や同僚がいつまでも帰らなかったりすると、早く帰ることに後ろめたさを感じたりするわけです。上司や上の人が「ほらほら、早く帰って」とか言わないと、部下は「自分の評価が下げられたりしないだろうか」と不安になるもの。
根底にあるのは、数十年前の日本企業によくあった残業する人は頑張ってる人っていう価値観が今も企業の上の人に根強くあるということだと思う。残業をすれば企業の支出が増えるので、利益が減ることになる。長時間残業が続くと社員は疲弊し、作業効率が落ちる。結果、納期も伸びて、会社の支出は更に増える。はずなのだが、実際には残業してると怒られるどころか「頑張ってるね」と褒められたりする。
まずは会社の上の人に対する意識改革が必要だと思う。
あと
もう一つは日本企業によくある「みんなで一緒に頑張ろう」の弊害。作業が早く終わった/時間に余裕がある人は他の人の作業を手伝いましょう、ってやつ。
するとどうなるか。効率よく仕事を手早く終わらせる優秀な人に、終わらない人の仕事がまわってくる。いっぱい仕事がまわってくるのに感謝もされず*1、それにより評価は多少良くなったとしても収入アップにつながることは少ない。「こんなに頑張ってるのに、給料が変わらないなんて、どういうこと！？」という不満が募り、会社からは優秀な人からいなくなることになる。
そもそも
なぜ長時間残業が常態化しているのか。理由はそれこそ千差万別なはず。まずは原因を突き止め、それに対して有効な対策は何かを考えることが必要なはず。
たぶん本当の理由は言いにくいことなのだ。「今日は定時間日です。早く帰りましょう」なんて、見たくない事実から目を背けるための言い訳なのだ。
残業を削減するのは手段の一つであって、目的じゃないはず。
最終的には
不満の多くはお金なのです。「自分はこれだけ頑張ってるんだから、それに見合った見返りが欲しい」ってことかと。そこをうまくバランスするしかないんじゃないかな。
*1:必ずしもそうではないが、当然という扱いをされることが多い
世の中の半分ぐらいの人はプログラマになれるそうです
逆に言えば40%もの人にプログラミングの素質があるということで、それはけっこうスゴイことなんじゃないの！？専門性を必要とするソフトウェア以外のエンジニアや芸術家・音楽家なんかはそんなに高くないでしょ！？こりゃもうみんなプログラマになっとけ、って感じなのでは :)
ふたこぶラクダという名前で知られている有名な論文がある。この論文では、60%の人間にプログラミングの素質がないと推定している。
本の虫: 60%の人間はプログラミングの素質がない
ちなみにうちの息子(小学校高学年)にscratch教えたら、他の人のプログラムとかチュートリアルとか見て、あっという間にプログラム作れるようになってました。いいなー。その柔軟な脳みそ欲しい^^;
息子やいろんな人を見てると
プログラムが出来る出来ないの差って興味があるかないかっていうのが出発点になっているような気がしました。ここが最初の分岐点。
で、次のステップは、プログラマにとって重要な「教えなくても勝手に自分で調べたり試したりしてモノにしていける」かどうかで、それはコンピュータを使って自分のやりたいことが明確になっているかどうかなのだと思います。「これを実現したい」->「じゃあどうすればいいか」->「なるほどこうすればいいのか」->「じゃあこれを実現するには」というループが自然にできている人は覚えるのが早いです。
あとは何か分からないことがあった時にアドバイスをくれる人も重要かな。それも答えを教えるんじゃなくてヒントをくれる人がいい。そうすれば理解した喜びを味わえて、学習のモチベーションが上がり、どんどん学んでいけます。
「好きこそ物の上手なれ」とは、昔の人はよく言ったものです。
コンピュータさえあれば
自分の望むものを作ることができて、結果がすぐに分かる。作り直すのに部品屋さんに行く必要もない。何かを作るという点において、コンピュータソフトウェアほどお手軽なものはないと思います。慣れるとパズルゲームのようで、とても楽しい。パズル好きの人はきっと気に入ると思う。
世の中の半分ぐらいの人は素質があるわけですから、あなたもぜひプログラミングを初めてみては！？ :)
あなたはなぜプログラマをしているのですか？
子供向けプログラミング講座が大人気らしいですね。私も妻によく「息子にプログラミング教えてよ」と言われます。
でも、こうも言われます。「息子は絶対プログラマにはしない」と。なぜかと聞くと「遅くまで仕事させられるわりには給料が低い。業界自体がブラックだから」だそうです…
「スタートアップならハードワークは当然」「この業界では定時帰宅なんてムリ」…
ワタミの失敗〜「善意の会社」はなぜブラック企業の代名詞になったか（新田 龍） | 現代ビジネス | 講談社（1/2）
妻の認識は大体世間一般の認識と一致しています。IT業界は大方ブラックというのが通説になってますね。ネットで検索すれば多くの「IT業界の悲惨な現状」を目にすることができます。さらに「そんなのはウチに比べれば全然大したことはない」と、不幸自慢大会が始まります(笑)パロディ漫画のネタも枚挙にいとまがありません。
確かにそういった側面があるということは否定しません。下請けであるが故に無茶な仕様変更に対応せざるを得ないケース。大企業であっても見込みの甘さからデスマーチに突入するケース。残念ながらそういったことは少なくありません。
でも
IT企業の全てがそのような状況というわけではありません。バブル経済の時代、私も基本給より残業代の方が多いということもありましたが、現在は長引く不況により、多くの企業は残業代を削減する方向へ向かっています。会社にもよるが、昔のようなムチャな残業は全体としては減っている印象ですね。
加えて近年はフレックスタイム制など、作業時間を比較的自由にできるようになってきました。まだまだこれからではありますが、だんだんとプログラマの価値を企業が認識してくれるようになってきてはいます。
あなたはなぜプログラマをしていますか？
人によって理由は違うと思うけど、多くの人はプログラムを作ることに喜びを感じているから、プログラマをしているのではないですか！？
初めて作ったプログラムが動いた時の喜び。ずっと分からなかった問題の原因が分かった時の爽快感。苦労して作ったソフトウェアがリリースされた時の達成感。そういう気持ちがあるから、プログラマを続けているのではないですか！？
別にウソを言えとは言いません
でも不幸な現状を嘆くだけではなく、できれば前向きな提案もして欲しいのです。プログラミングに興味を持つ若い人たちに、希望を感じさせるようになって欲しいのです。
そして、嬉しいことがあった時は、ぜひその気持ちをシェアして欲しいのです。プログラミングって、こんなに楽しいんだよって :)
