はじめに

　自分の基本はプログラマとして、サーバーサイドのサービスをゴリゴリ書くのが仕事だ。しかし、仕事をするとなると、いろいろな人が絡んでくる。もちろんマーケティング担当や戦略担当の人もいる。そして、僕はそういう人たちが実際にやっていることはわからないけれど、それはたぶんそういう人たちが「プログラマってどういう仕事なのか？」ということがわからないのは一緒なのだろうと思う。もちろん、お互いに相手の仕事を理解して、それに合わせてどういう風なことを共有して作ってもらうか、というのを話し合う機会は重要だ。

　たぶん、自分たちがどのように仕事をしていて、どのように情報を共有してもらえれば、仕事がスムーズにいくのか、ということを説明しないことには、たぶん「プログラマが理解されない」ということを嘆いても仕方ないと思う。なので、まず自分が「プログラマとしての自分」が考えていることを共有する必要があるなあということを考えていた。そこで今回の話はそれにあたる。

　例によって、これは少人数でやるスタートアップの話なので、これより大きな規模になるとまた若干違う話が出てくる可能性が高い。

最低限のヒアリングをしてみよう

　「JavaとJavaScriptがどう違うの?」というネタが定期的に出てくるけれども、非エンジニアにとっては、そもそも「PHPとRubyとPythonの違い」みたいなのはわからないものだったりする。最近だと、「iOSとAndroidの違い」みたいなものの開発においてネックになる部分はかなり違う。自分たちのところだと、結構ハードの部分をひっくるめて考えないといけないことが多いのだけれども、そのときに、単純に「ハードの多さ」だけを考えてしまうこともある。それはそれでわかるのだが、実際のところは、例えば日本なら各種キャリアが特殊なカタマイズをしている場合もあったりして「ふざけんな」となることがあると聞く。

　もちろん、僕はAndroidの開発者ではないから、詳しい内容はわからないし、突っ込みどころがあるかもしれない。問題は、「非エンジニアにとっては同じように見えること」であっても、それを深くやっているエンジニアからすると、全く別物であるということで、さらに「良心的なエンジニア」であるならば、自分以外の領域については「目星はだいたいつく」けれども「細かい話はわからない」ということを正直に伝え、そのうえでちゃんとどういう風な問題点があるかを聞くようにアドバイスするものだ、と思っている。

　実際にAndroid開発者に対して「iOSの通りに作ってください」という注文は多いようなんだけど、そもそもiOSとAndroidの考え方は違うわけで、一緒にすることで無理が発生するかもしれないとうことは考えるべきだし、そういう意味では、その専門ではないのならば、ちゃんとヒアリングして考えるべきことだと思う。

見積もりを出してもらおう

　「非プログラマ」というのは、たぶん機能に対して「複雑だから難しそう」みたいな話であったり、あるいは「画面一枚だから簡単でしょ?」みたいなことを考えたりするかもしれないけど、どのテクニカルな判断というのは、実は見た目の複雑さとは関係がなかったりする。例えば、Twitterのようなタイムラインの実装に関してもそうで、あれはいろいろとテクニカルな問題が必要になる（例えば、フォロワーに対して投稿を結びつける処理は、当然のことながらフォロワーが増えれば増えるほど負荷がかかるものなので、そのあたりのアルゴリズムをきっちりと負荷と感じさせない形で作る必要が出てくるだろう）。

　あるいは、僕はデザイナーじゃないので、実際の現場はわからないけど、しかしデザイナーの人が「ここのところを少し変えておいて」と言われたことによって、全体の構成自体がそもそも崩れてしまって考え直しになるという話はたびたび聞くし、またいわゆるHTMLの話にしても、最近はやりのウィンドウサイズごとにパーツの表示を変える（レスポンシブとかいうやつ）にしても、HTML構造自体によっては大胆な書き直しが必要になるし、そもそもレスポンシブ後の表示デザインも考えないといけない。

　そのように考えると、実は非プログラマが考えるその機能を実装するにあたってかかる工数自体というものが、そもそもエンジニアが考える工数とのズレがあることは確かなので、そこを確認しなければならない。「これ難しそうだよね」と思ってひっこめていたタスクが、実はエンジニアからすれば「いや、それ一日で実装できるんですよ」ということもあるだろうし、逆にエンジニアから見て「他のサービスでもやっているし、簡単でしょ?」ということが、実はテクニカルに難しいことだったりする。

　だから、「この機能が重そうだからあまり振らないほうがいいんじゃないか」とひっこめてしまい、「これは簡単だからやってもらおう」みたいな感じになると、実はテクニカルなことでは難しいことに偏ってしまう危険性が存在する。そして、自分たちの作業というか重さ自体がだいたいどんな感じになりそうなのか、みたいな情報を提供することも、プログラマとして手を動かしていて、さらにいうなら経営や運用と近い位置とするなら、そういう相談にも乗るのは業務の一つということは可能だと思う。

その機能が必要である文脈（ストーリー）を伝えてみよう

　当然のことではあるが、仕様通りに作るというのは当たり前ではあるんだけれども、しかしそもそもその「仕様」ってどういう意図で決定されたものかという文脈が落ちて伝えられることが多い。しかし、何らかの機能というのは、そもそも「ユーザーに何をさせたいのか」であったり、あるいは、「サービスを伸ばしていく上に置いて、この機能を先手として実装する必要があったりする場合がある。

　そもそも仕様策定と言わなくても、何らかの機能を作るということは、なんらかの文脈があってその機能を実装させたいと思っている筈だ。そして、その文脈をちゃんと知らないと、その文脈からずれた仕様を作ってしまう可能性が高まってしまうし、またその文脈が共有されているならば、テクニカルに難しい機能を言われたとして、もう少し簡単でかつ効率的にその文脈を埋めるような機能の再提案を、エンジニア側からのフィードバックとしてすることが可能になる。

一つ新規機能を作るたびに、コードを見直したりする機会を入れてみよう

　自分も十分承知なのだが、そもそもユーザーに何かをアピールしようとするさいに、やはり新機能という部分のほうがアピールしやすいという問題がある。もちろん、以前からクラッシュしやすいといったり、レスポンスが遅すぎてイライラするという問題もあって、それらはユーザー目線からすれば「当たり前に」出来ていて当然のものだ。しかしこれについては、ユーザーに対してストレスを感じさせないという意味では、やはり必要なことである。そうすると、どうしても今開発しているコードを改善するということは疎かになる。コードをあっちに移動したり、こっちに移動している時間があったら、パフォーマンスを改善したり、あるいは新規機能を追加したいと思うのが、人の常だと思うからだ。

　しかし、そこでプログラマとしての俺から見るに、そもそもコードは腐る。たぶん、非プログラマの人たちにはピンとこないかもしれないけれど。現に目の前で動いているのに、コードが腐るとはどういうことなのか、と疑問に思うかもしれない。

　まず一つに、規模によって、どういうアプローチでその機能を実装するかという開発戦略の段階はかなり違う。そもそも、ユーザー数がそんなにいない段階から、100万人にも耐えうる構築を考えても仕方がない。なぜなら、そもそもそのサイトは1万人のユーザーがいればそれで十分かもしれないからだ。しかし、実際に1万人程度でいいだろうと思ったものが、100万人になった場合にどうするのかという問題がある。そういう風に、最初予定されていなかったものが、だんだんとスケールするにしたがって、新しい局面を迎える。そこでちゃんとコードを書き直さないといけない。

　これはパフォーマンス改善という問題として、一つ言えることではあるので、一応説得はできるたぐいのものだ。

　むしろ非プログラマの人に説得しにくいのは、「コードがぐちゃぐちゃになっていて新規機能が開発できません」といった問題だと思う。

　少なくとも、ある程度良心的なプログラマならば、「今後、何かの機能を追加するなら、現状のこのコードを放置しておくといろいろ足かせになる」という部分と、「目の前で機能追加の期限がせまっている」という部分で天秤にかけることが多い。そして、その天秤にかけたところとして、後者を選ぶという形になると思う。しかし、このように「現状のこのコードを放置しておくと……」の部分は、未来において、新しい機能を追加するときに、工数を爆発させてしまう爆弾として埋め込まれている。なので、ちゃんとこのコードの体質を改善しないとどうしようもなくなってしまう。

　一時期、「クソコードが云々」というのがタイムラインで流れてきていたが、非プログラマに伝えなければいけないものとして、「クソコード」というのは、上記のように、もしWebサービスという枠組みで何かビジネスをやろうとした場合に、工数爆発による動きの鈍りとして、将来的なリスクになる可能性が非常に高いのだ。最初に舞台に踊り出たスタートアップが、段々と動きが鈍ってしまうのは、この辺りの問題が多少なりとも絡んでいるということは、非プログラマの人が考えておくリスクとして、おぼえておくと、プログラマの人と話すときにスムーズになると思う。

贅沢な環境を提供できるようにしよう

　例えば、1回だけ1万円支払えば、一ヵ月後に2万円返ってくることが保証されているならば、誰だって喜んで1万円支払うと思う。しかし、「朝三暮四」ということわざがあるように、一万円を支払うのを渋って、二万円を失うことが多々ある。

　直近でいうと、自分たちのところでは、外部ディスプレイというのが、つい最近までなかった。もちろん、パソコンの解像度によっては、そのようなディスプレイが存在しなくてもなんとかやっていけるのだが、しかし古いラップトップパソコンを使っていると、解像度の問題があったりして、どうしてもドキュメントやチケット管理ツールやコンソール画面などを一つの画面にまとめようとすると、非常に大変なことになってしまう場合がある。なので、その場合において高解像度なディスプレイが存在しているという環境は、そもそものコーディングの時間を圧縮することが可能となる。どうせ余裕があるなら、目の前のラップトップを買い替えてしまってもいい。

　自分は、よくジャンクのラップトップを買ってきたが、一年くらいで使えなくなって買い替えることを繰り返していた。結果として安物買いの銭失いという結果になり、全体としてちゃんと継続して使えるラップトップを購入したほうがコストパフォーマンスがいいということもある。少なくともそういう環境の部分で渋っていると、生産性に寄与しなくなることは考えたほうがいいだろう。

まとめ

　というわけで、ちょっと自分の中でどういう風なことをお願いしたいのかを書いてみた。もちろん、これらの問題は、俺が考えていることだから、ほかのプログラマの人たちに同意できるかどうかは怪しい。ただ、ポイントとして、「プログラマがどういうことをされるとありがたいのか」、あるいは「プログラミングするという行為が何に依存している作業なのか」ということを理解し、それをくみ上げて反映できる人が一人いるかいないかで、そのスタートアップでの働きやすさはだいぶ変わるし、さらにいうならば生産性もかわる。

　自分が少しだけ言っていることとして、ユーザーに価値を届けるという志は立派だけれども、しかし同じチームとして働いている人にどういう価値が届けられるのか。そういうことを考えるだけで、ユーザーに価値を届けるための距離がだいぶ縮まるのではないかと思う。