国民宿舎はらぺこ 大浴場

• 趣味プログラマが業界で生きて行くには (Note さま)
• 趣味プログラマ歓迎じゃないの？ (みかログ さま)

上記に触発されておいらもちょろっと書いてみる。

1. コミュニケーションを大切にしよう。

   共に仕事をする人間との意思疎通が行えることは、必要かつ重要な能力です。コミュニケーションという言葉を誤解する人は多いのですが、必ずしも仲良くなる必要はありません。個々人と友達になろうと尽力するのではなく、例え相手が苦手なタイプであったり、生理的に受け入れられないようなタイプの人間であったりしても、必要な会話をこなし、意思疎通を図ることができる、ということが重要です。

   なお、コミュニケーションとは、何も口答での会話に限ったものではありません。メールなどでのやり取りはもちろん、例えば成果物としての各種文書等においても、読み手に内容が伝わることに配慮することも、必要なコミュニケーションスキルの一つです。その為に、文章の論理性、効果的な表現手法の選択 (箇条書き、図、表など)、読み手の技術スキルを想定した上での言葉の選択、などといったことにも、都度、考慮する必要があります。

2. 分からないことは素直に分からないと表明しよう。

   知ったかぶりは、業務に支障をきたします。絶対にやめましょう。また、分かっているつもりのことでも、実際には知識があやふやであるという事は、職歴の長いベテランでもよくあることです。他者との会話などを通じて、自己の知識のどういった部分があやふやであるのかを自ずから検証し、あるいは他者からの指摘があれば、時としてそれに耳を傾けることも必要です。

3. 自分の意見を言おう。提案すべきことは提案しよう。

   グループ内の合意事項であっても、それが必ずしも常に正しいとは限りません。もっと適切な方法があることをあなたが知っているのであれば、その知識は提案として明かされるべきです。それらのすべてが必ずしも受け容れられるとは限りませんが、少なくともあなたの責任を和らげる効果と、将来グループの面々に反省を促す可能性は期待できるかもしれません。

   逆に、あなたが信じる方法を提案した結果、元々グループ内で採用されている方法の方が優れていることが判明するならば、それは恥ずかしいことかもしれませんが、あなたの知識を向上させるという結果をもたらすことになります。どちらにせよ、無駄になるということは、あまりありません。

4. 顧客などの取引先や、その他の外部に影響するような身勝手は慎もう。

   例えば技術的な検証が十分では無い再現情報を、むやみに顧客に公開すべきではありません。発言には責任を伴うことを忘れないでください。それも、あなた個人の責任ではなく、会社の責任になるということを。顧客がその再現情報を信用した結果、関連する副次的な現象が発生した為に損害を被った場合、あなたは責任を取れますか? 機密情報と公開情報の切り分けは、社内またはグループ内で十分に合意が形成されている必要があります。

   また、業務外の場で仕事に関する話をするのは、基本的にはご法度です。もちろん、感情的なわだかまりが、このような話題を生み出してしまう点について、個人的には同情的立場を取りたいと思っています。しかし、それであっても、重大な機密情報を漏らすような行為や、仕事仲間のプライベートを侵害するような行為に至らないことを、十分に配慮する必要があります。自信が無いなら、仕事の話は業務外では避けるべきです。

5. 頼まれるどんな仕事にも好奇心を抱こう。

   あなたが関わっているプロジェクトに関わるほかの人々の仕事内容を、すべて知っておく必要がある、とは言いません。しかし、概ねどのような作業が存在するのかを知り、それらに関心を抱くことは、とても良いことです。

   もしもあなたが、上司に頼まれた仕事内容が、あなたがやりたいと思っていたものではなかったとしても、その作業に関心を以って従事すべきです。たとえばよりよい仕様書の書き方を知っているプログラマは、仕様書の書き手に的確な文句を言うことができます。テスト作成や不具合管理を通じて QA に精通したプログラマは、バグの混入しにくいプログラムを書く方法について研究することができるようになります。そして顧客とのやり取りを通じて要件定義を行った経験者は、その後の開発を通じて、潜在的な要求事項を洗い出すことの重要性に気付かされることになるでしょう。

6. 誰でも読めるコードを書こう。

   あなたは趣味のプログラミングを通じて、より効率的で、パズルのように難解なロジックを書くことに、快感を覚えてきたかもしれません。そうでなくても、コーディングにおけるあなたならではの癖やこだわりがある可能性は十分にありますね。

   趣味であれなんであれ、まともなソフトウェア開発会社や事業部であれば、プログラミングの経験者を優遇するはずです。ただし、オタクは嫌われます。この点については、覚悟しておいた方が良いかもしれません。それまであなたが信条としてきた観念が、その職場では受け容れられない可能性は、大いにあります。

   コードの可読性は、その代表例の一つに過ぎません。動作効率としてどんなに優れたロジックを書いても、そのコードが何をするものなのかが理解できないようなものは、恐らく受け容れられません。なぜなら、そのコードをメンテナンスするのは、あなた一人ではないからです。もしもそのロジックにバグがあったら、誰がそれをどうやって直すのか? 機能拡張の要求に応じる必要が生じた場合は?

   基本的には、あなたがそのロジックに対する説明責任を果たしているならば、それほど大きな問題にはならないかもしれません。ソースのコメントに、処理の概要だけではなく、ロジックの詳細についても記述しましょう。必要ならば内部設計文書も残しましょう。数学的ロジックとしてパブリックドメインに公開されているものであるならば、その情報の提供元となる URI または書籍名を書いておくのも手かもしれません (公開されているロジックだからといって、あなたの職場にその知識が浸透している保証はありません)。これらの解決策が取れないのであれば、そのようなロジックの使用は避けるべきです。

7. 自分の書いたコードが誰にでも読めるものであると過信しないようにしよう。

   6番にも通ずることですが、自分で書いたコードに関しては、説明責任が果たされるべきです。表面的にはコメントや設計文書が充実していることも大事ですが、なによりコードのすべてのステップに対して、あなた自身が言葉で説明できることが重要です。

   ソースコードレビューを実施しているような職場であれば、このようなクセは自然と身についてゆくものですから安心ですが、そうで無いならば、余裕があれば、自分自身で一行一行読み直し、なぜその名前や書き方を選んだのかが分かりにくい箇所を洗い出す、という作業を行ってみると良いかもしれません。

8. 既にあるものを利用しよう。

   あなたが独自に作り出そうとするアルゴリズムやデータ構造は、多くの場合、恐らく既にライブラリとして提供されています。作ろうとする前に、まずはライブラリ内を探して見ましょう。C/C++ なら標準 C ライブラリや STL に、Java ならクラスライブラリに、Perl なら標準添付のライブラリに、すでに同じことができる信頼性の高い実装が用意されてはいませんか?

   ここで重要なのは、必ずしも工数の削減だけではありません。開発効率も確かに重要ではありますが、最も重要なのは信頼性の担保です。標準規格に則って作られているライブラリや、言語パッケージに標準搭載されたライブラリであれば、信頼性は高いといえます。十分に知られた会社が独自に作成し配布するライブラリは、次いで信頼性が高いといえます。どちらも責任の所在が明確かつ不動であるため、動作に関する疑問点があっても、適切なプロセスを経て解決することが可能です。

9. ネット上で流れている情報を利用する場合は、信頼性を確認するか、または上司に相談しよう。

   8番に関連しますが、例えば零細企業や個人が作成し配布しているライブラリを組み込むような行為は、あなただけの判断で勝手に行うべきではありません。上司や関係する取引先と十分に相談しあって、使用するかどうかを決断すべきです。このようなライブラリは信頼性は決して高いとは言えず、責任の所在も不明確かもしくは流動的であるため、問題が発生した場合に、解決に向けた適切なプロセスを踏むことができなくなる場合があるかもしれません。

   ライセンスの問題もあります。GPL であれば、それを組み込むプログラムのソースコードも公開せねばならなくなります。プロプライエタリの開発に従事しているのであれば、そのような事態は避けなければなりません。

   業務時間中に、業務とは直接関係の無いオープンソースソフトウェアの機能改善を行ってフィードバック、といった作業を行うと、履行契約違反だということになって怒られたり処罰されたりする可能性があるので注意しましょう。絶対にばれない自信があるならおいらは何も言いませんが。

   それから、ライブラリではなくて、例えば参考情報のようなものであっても、その情報源が信頼のおけるもので無いならば、注意が必要です。特に、調査報告書を記述する際に、参考情報源として、個人のブログ記事や、2ちゃんねるのスレッドなどを挙げるのは避けるべきです。信頼性のボーダーラインは職場ごとに異なると思いますので、その辺は上司と相談することも必要ですが、例えば特定のツールやライブラリに関する情報であれば、そのツールやライブラリの開発元による公式文書であれば、十分に信頼に足ると言えるでしょう。

10. 効率の悪い作業を自動化する自由は、認められるべき権利だ。

    これは職場の民度によって、推奨されたりされなかったりすることですが、もしも推奨されない場合であっても、作業を自動化するツールを作成した方がより効率的であると判断できる場面であるならば、積極的に自動化を図るべきです。

    この点については、基本的には上司に相談する必要もありません。やっちゃったもん勝ちです。で、やっちゃった後で、実はこういうツールを作った、似たような作業をすることがあれば自由に使っちゃってください、といって職場内で共有するのもアリです。もっとも、共有する場合には、それがどういうツールで、どうやって使うものなのか、ぐらいの説明責任は果たされるべきですが (共有するつもりがなくても、引継ぎの際に困らないような準備をしておくことが望ましいとは思いますが)。

他にも何かあればどんどん追加してあげちゃってください。

ちなみに、個人的には、趣味グラマとしての経験の有無が、職業プログラマとしての能力の高さに大きく関係しているとは、あまり思っていません。学生時代までにプログラミングの経験がほとんど無い人であっても頭角を示すケースは実際にありましたし、教養としてプログラミングはやってたけど実はあんまり好きじゃないしポテンシャルも低い、って人もいないわけではありません。性格に由来するセンスの有無というのも結構大きいです。

「作業量を省略して楽をしよう」と考えることのできない人や、協調性が極端に低い人、論理的な考え方の苦手な人、固定観念に凝り固まる人、利用価値を吟味できずに新しいものであればなんでもかんでも習得しようとする人は、プログラマとしてはあまり幸せになれないかもしれません。

それでは、健闘をお祈りいたします。。。