はてなキーワード: コンパイラとは
1. コードはプログラマーと宇宙の秘密のやり取り。でも、宇宙は時々 "42" って言っちゃったりすることもある。
2. プログラミングはエラーを見つけ出す冒険。ただし、その冒険にはときどきドラゴンも混ざっていることがある。
3. 真のプログラマーは "Hello, World!" を書くことで宇宙の秘密を解き明かすことができます。それから "Goodbye, World!" と言ってサヨナラします。
4. プログラムは人生のコントロールセンター。ただし、"Ctrl+Z"(元に戻す)は人生には効かないことがあります。
5. コードは時には詩よりもラグビーの試合のよう。問題に突進し、バグをタックルしまくります。
6. プログラミングはあなたが言うことではなく、コンパイラが理解することです。コンパイラが言うことを聞く賢明さが必要です。
7. コードは魔法のスペルブック。しかし、時々 "Abracadabra" を打っても期待通りのことが起こらないことがあります。
8. デバッグは魔法の水晶玉のよう。時には見通しがよくなく、ぼんやりしていますが、それでも未来を予測しようとします。
9. コードは時間のカプセル。将来の自分に向けてメッセージを残すことができます。ただし、時々 "TODO: 未来の自分、これを修正してください" というメモしかありません。
セキュリティソフトウェアの研究開発、という仕事を自分の経験をもとに紹介します。主な想定読者は、情報セキュリティ関連を仕事にしたいと考えている学生や若手、特に、いわゆる「低レイヤー技術」に惹かれている人です。
低レイヤ技術を間接的に仕事で生かしてきた経験の共有。元Linuxカーネル開発技術者の場合 - 覚書を読んで思い出したのですが、セキュリティキャンプなどで、セキュリティに興味のある学生とやり取りをしていて、ソフトウェアエンジニアリングの分野でセキュリティ関連のキャリアが議論されることが少ないと感じました。自分はセキュリティソフトウェアの研究開発に10年以上携わっていることもあり、この職業は低レイヤー技術をセキュリティに活かせる面白い選択肢だと思っているので、紹介してみることにしました。
セキュリティソフトウェアの研究開発では、アンチウイルスやEDRなど、文字通りセキュリティ機能を提供するソフトウェアを研究、開発します。
「研究、開発」と書いたように、この職業には研究と開発の両面があります。
研究は、実現可能性や価値が定かでないアイディアを調査、試験実装する、という仕事がその一部です。例えば、ファイルをディスクに書き込まないマルウェアを検知したいが、どのような技術的選択肢と課題があるかを評価する。実現可能な場合は、開発チームと協働して実装、出荷にこぎつける。あるいは、製品として実装された機能がバイパスされないか調査したり、バイパスされてしまった場合にはその原因を究明したりして、製品を改善するために開発チームと協働する、という場合もあります。
開発は、研究との対比という意味においては、できると判っているアイディアを保守性の高い状態で実現する作業だといえます。保守性の重視は研究との大きな違いで、例えば、研究では、コメントもテストものない書き殴りのコードで十分であっても、開発の工程では、5年後でも改修が必要になるため許容できなかったりします。製品という大きなコードの中での開発であるため、別のチームや利害関係者との連携も、研究の場合よりずっと重要です。例えば、リードのポジションであれば、研究工程で実現可能と分かったアイディアが、既存の機能に統合する形で実装されるべきか否かアーキテクトと議論したり、テスト計画を品質保証のチームと練ったり、プロジェクトのスケジュールを調整したりします。
研究は、既定の手法がなく、闇の中を手探りで進める面があり、最終的に製品レベルにこぎつけずに終わる場合も多いです。判りやすい成果が出ない場合があるので、好き嫌いが別れやすいです。自分は、職業としては研究3,開発7くらいのバランスが好きで、趣味では逆に研究8,開発2くらいになってます。趣味では成果が出ようが出まいが過程が楽しければ満足、という個人的な考え方がこの違いとして出ているようです。
この職業のおいて、低レイヤー技術に明るいことは、ほかの多くのエンジニアができないことができるという付加価値、だと自分は考えています。例えば、特定分野の詳細を知っていることでその分野の研究、開発が効率よくできたり、新しいアイディアが生まれたりします。具体例をいくつか挙げると、OSの仮想メモリー管理に親しみがあれば、プロセスのメモリーを走査してメモリー上のみに存在するマルウェアを検出する機能をより効果的に設計、実装できる。プロセッサーの機能の詳細を知っていれば、CETという新しいプロセッサーにしかないセキュリティ機能を、他のプロセッサー機能を使って疑似的に実現するというアイディアを思いつく。などです。脆弱性の知識や探す技術も、とても価値があります。脆弱性を知らない人と、知っている人では、どちらが脆弱性の少ない設計や実装をできるでしょう。自社の製品の脆弱性を、開発中に発見するのと、テスト・出荷後に発見、改修を加えるのではどちらのコストが少なくて済むでしょう。コンパイラーの知識は検出ロジックを書くための独自言語の開発に、エミュレーターの実装経験はマルウェア解析エンジンの開発に役立ちます。
ただ、低レイヤー技術は付加価値であることに注意してほしいです。
まず前提として、ほかの平均的なエンジニアができることに加えて低レイヤー技術があるべきです。セキュリティソフトウェア開発者の多くは、実はセキュリティや低レイヤーのエキスパートではありません。優秀な開発者であることに加えてこれらを必要条件にしてしまうと、人が雇えなくなってしまうためです。そのため、一般的なエンジニアリングの能力に加えて低レイヤー技術やセキュリティという強みがあると、大多数の開発者ができない(したがらない)ことを任せられる人、と差別化してもらえる可能性が高いです。一方、エンジニアリングに対する素養や意欲なしでは、セキュリティソフトウェアの研究開発職は難しいです。その場合、研究者のほうがあっています。(ちなみに自分は、脆弱性解析とマルウェア解析を専門とする研究職にも各2年ほど就いていました。)
ここからは一般論になりますが、OSに詳しくても、プロセッサーに詳しくても、バグハントが得意でも、それを会社が求める結果を出すために使えなくては意味がありません。会社は、あなたがやりたい仕事をくれません。会社は、会社が必要としている仕事をもってくるだけです。
ではどうやって「会社が必要とする仕事」と「あなたがやりたい仕事」の重複を最大化するか。
まずは、上司にどういう仕事をしたいかを明示的に、繰り返し話しておきます。さらに、能動的に、自分からプロジェクトのアイディアを提案して意欲を示すことも心がけます。あなたの仕事を最終的に選ぶのは上司である以上、上司からの理解は必須です。良い上司(そして良い上司であることを可能する、良い上司の上司)は、必ず、あなたの能力に対する信頼度に応じて、あなたの意向を考慮してくれます。言い換えると、まずはやりたい仕事を主張する前に、与えられた仕事をこなして信頼を得る必要があります。個人的な経験では、これは1年あれば十分で、1年たっても状況に変化がない場合、あなたの仕事ぶりが上司の信頼を得るのに不十分か、あなたがやりたい仕事をうまく伝えられていないか、上司やその上司あるいは会社に問題があるか、あるいはこれらの組み合わせの可能性が高いです。
上記がうまくいかない場合、チームや会社を変えることを検討しましょう。チーム異動はリスクの少ない選択肢です。これも、実現するか否かは、上司からの信頼の程度に大きく依存します。会社を変えるのはリスクが大きいですが、上司やその上司を変えるよりも現実的です。新しい会社でもうまくいかなかったら、また新しい会社を探せばOKです。最終的にあった会社に行きつくか、自分の能力やコミュニケーションに問題があることに気づくと思います。
最後に、「会社が必要とする仕事」と「あなたがやりたい仕事」の重複を追求しないことも視野にいれておきましょう。仕事はあくまでお金のためであって、やりたい仕事のほうが楽しいが必要要件ではない。……という視点を持っておくと、些細なミスマッチで不満をためて、そこそこ良い環境から性急に転職してしまう、という状況を防ぎやすいです。隣の芝生は青い、ということを忘れないように。
セキュリティソフトウェアの研究開発は、セキュリティに深く関わりつつ低レイヤー技術を付加価値として自分を差別化できる面白い職業です。
ところで自分は7年務めた研究開発職を退職しました。おめでとう、ありがとう。これからは、また違う低レイヤー技術+セキュリティの研究開発をしていきます。
素人で調べたところだと、
こんな感じで普通の人が知るのは難しそうだ。
お絵描きやプログラミングなど、創作系の趣味において、自分が欲しいものがなかったり、あっても不満だったりすると、「自分で作ってしまおう」というのは一番ありがちな動機
自分で作ろうと思った時に選択するツールがアナログ画材なのか、液タブなのか、AIなのかの違いなんてその時点での目的の達成しやすさの違いでしか無いじゃん?
曲作りたいなら打ち込みかもしれないけれど、モテたいが目的なら自分でギターを弾くじゃん?
手作業の温かみなんて求めてハンドアセンブルで手動最適化なんてせず、コンパイラの自動最適化のほうがよっぽど高度に最適化してくれるじゃん?