プログラムを書くということ
（@tets01）
仲宗根徹也と申します。
2009年12月15日付けで、後述の技術理事に就任しました。
理事という肩書きは付いていますが、普段は楽天市場のアプリケーション開発を担当する現場のエンジニアです。
ここ数年は思うようにプログラムを書く時間が取れていません。それでも常日頃から、いかに少ない量のソースコードを書いて、最大限の仕事量を発揮させるか？ そのようなプログラムの書き方というのを追及したい、などと考えながら仕事をさせていただいております。
先日、別の会社のエンジニアの方とお話した時のことです。
その方は、「自分は上流だけやっていきたい。コーディングは単純作業だ」ということをおっしゃられていました。僕はその言葉を聞いた途端、不快感を覚えたわけですが……。
今時「上流＝偉い」と考えている方はほとんどいらっしゃらないと思うので、そこはよしとしましょう。単なる前工程、後工程の違いでしかないはずです。コーディングよりも、設計や管理のほうが向いている、という方もたくさんいらっしゃいます。
ですが、その方が「コーディングは単純作業である」という考えに至った背景が理解できませんでした。
それに反論する意見はあちらこちらで見かけますし、この記事を読んでらっしゃる多くの方も、「んなわけない」とお考えでしょうが、あえて僕もその辺の事を書いてみたくなりました。
■コーディングは単純作業か？
プログラムをまったく書いたことのない人の中には、
- プログラマは設計書の指示に従って、コーディングのみを行うのが仕事
- プログラミング言語を覚えて、それを組み合わせて使うだけ
だから「単純作業」である、と考える人がいます。
当たり前のことを書いてしまいますが、
- ソースコードと1対1で結びつくようなレベルの設計書が作られることはまずない
- 必ずプログラマの頭の中の変換を通って書き出される(ツールによる生成は除く)
- 変換の際、プログラマ個人の経験や美的感覚やコダワリによって、書き出されるものにバラツキが発生する
隣に習えで単純に書けるケースもありますが、誰が書いても同じプログラムが出てくる、ということはほとんどありません。チームや組織内にしっかりした規約や、よくできた設計ポリシーがあれば、ある程度バラツキを抑えることは可能かもしれません。
プログラマの能力に依存した変換をさけるために、一通りの書き方しかやりようがないくらいまで詳細な設計書を書くということも、通常行われません。そのような人がいるとしたら、設計書を書くのをやめさせて最初からプログラムを書いてもらったほうが早いですし。
「ソースコードがどう書かれているか？」という点が、そのアプリケーションの効率、今後のバグの埋め込まれやすさ、拡張性などに大きく影響してきますので、大変重要だと僕は考えています。
実際にソースコードとして表現してみて、初めて気付く仕様の漏れ、試行錯誤で解決しなけれならない部分はたくさんあり、そのようなことは実際の現場でもたくさん起こっていることと思います。
僕にはこのエンジニアによる変換や試行錯誤による解決が、単純な作業とは思えません。
ちなみに、ソースコードはCPUやVMなどのランタイム環境で動かすための設計書であり、プログラミングをするということは設計そのものである、という考え方には賛成派です。
■アプリケーションが動けばいいのか？
最終的に仕様通りに動くものが作られているならば、中身はどうなっていようと関係ない、とおっしゃる方もいます。
しかし、ソースコードがどう書かれているか（保守性の高さ）は、開発スピードや生産性に直結しますので、どうでもいいことではないと僕は思っています。
楽天のように自社でサービスを開発し、短期間で機能追加や改善を頻繁に行っていかなければならない会社にとっては、なおさら重要なです。
楽天だけじゃなく、世の中のほとんどのシステムでにとっても本来重要なことだと思うのですが、その重要性を認識しているのは、現場でコーディングを行っているエンジニアだけのような気がしています。
重要なはずの「どう書かれているか」に対する評価は、エンジニア同士が認め合うことで済まされていて、組織的に行われているという話を聞いたことがありません。
どうやってそれを評価すべきか、大変難しい問題です。
高いレベルでコーディングできる人でなければ、そのソースコードの品質を評価できないからです。この状況を何とかする方法は無いのでしょうか？現場のエンジニア同士で理解しあえればよいのでしょうか？
エンジニアレベルの底上げとソースコード品質の向上をさせるためにはどうすべきか、ということも技術理事として考えていければと思っていますが、その評価方法についてはどれも決定打になるものが思い当たりません。
評価、評価、うるせーなー、と思われるかもしれませんが、大きな価値を生み出している重要な要因のひとつである以上、やはり正当に評価されるべきことかと思っています（この問題に限らず、影の努力に支えられている物事が、世の中多すぎませんか？）。
何か良い事例、ご意見などをいただけるとありがたいです。
■単純作業と言い切った人の状況を考えてみる
話がそれてしまいましたがｗ、その「単純作業」と言い切った方は、コーディングの経験もお持ちであります。
なぜ「単純作業だ」という発言をしたのか、詳細に突っ込んで聞かなかったため、僕の推測でしかありませんが、
- 1つの案件が終了したら別の案件に移り、一度作った物を保守する機会がほとんどなかった(動くものを納めれば終わり)
- 設計書を見て、どう書くべきか一発で答えが出てしまうくらい、とても優秀な方だった
- いわゆる「上流」は「下流」より偉いと擦り込まれて仕事をしてきた
の中のどれかくらいしか思いつきません。
今後はそういうことをいう人と出会ったら、なぜそう思うのか、きちんと教えていただくようにしたいと思います。
■技術理事について
先日、楽天が技術理事という役職を新設した、との事がニュースサイトに出てまして、記事には以下のようなことが書かれています。
ネット業界で名が知られるなど先進的な技術力をもつ「技術理事」。
技術理事のひとりは、
@hyoshiokという名で知られているものです。比較的知名度が高く、さまざまな方との交流も深いのですが、もう1人の僕は特に有名人でもないため、大変恐縮しておりますｗ。
まぁそのことは置いといて、現場のエンジニアと経営が一体となってシステムを考えていけるようになったことは、大きなチャンスです。本気でがんばりたいと思います。
■世界一を目指す
楽天グループが掲げる目標の1つに「世界一のインターネットサービス企業」を目指す、というのがあります。このコラムのシリーズのタイトルにも、「世界一」という言葉が入っています。
世界一のインターネットサービス企業になるためには、本気になって世界一を目指そうと考えているエンジニア達がシステムを作っていかなければ、実現はできないと思っています。
無限にスケールする基盤、エンジニアの技術力、など、まだまだ楽天に足りない物があるのは重々承知しておりますが、本気で考えているエンジニア達と共に価値あるサービスを創りだし、本気で世界一のインターネットサービス企業を目指していきたい、と考えています。