プログラマのためのビジネス・マナー講座

最近、若手のプログラマと仕事をしていると、フレームワークやライブラリの知識はあるのですが、常識が欠けているのではないか、と思う事があります。
業界経験の長い私たちから見ると、ほぼあり得ないようなことを、論理的な正しさだけを基準に決めつけてしまい、結果として営業が苦しむことになったり、クレームに発展するようなケースも見聞きします。
私たちにとって「当たり前」に判断できることを経験不足で判断できずに、同僚から疎まれたり、会社にマイナスの影響をおよぼしているのだとすれば、非常にもったいないことです。

今回は、業界歴20年におよぶ私が、若手プログラマの成長の一助になることを期待して、この業界のごく一般的なマナーをケース別に紹介、解説したいと思います。

商談編

Q.お客様が「Instagramに投稿された写真のうち当社の製品が写っているものを自動的に当社のHPに掲載したい」と仰ったので、「それは出来ません」とお答えしたところ、お客様が渋い顔で黙りこんでしまいました。

A.ご要望を聞いて、「出来ない」と言うのは失礼なことです。

お客様がアイデアを思いついたのに、ろくに検討もせずに不可能だと断言してしまったのですね。
お客様のご要望が仕様的、論理的にほぼ不可能であったとしても、それを口に出すべきではありません。
恥をかかされた、とお客様がお感じになるかもしれませんし、どのようなご要望にもお応えできます、と明言していた営業の面子も潰してしまいます。

プログラマの知恵の集大成であるBSDしぐさ*1にも「無理は持ち帰れ」という言葉があります。このような場合は、にこやかに「ぜひ前向きに検討させていただきます」とお答えしましょう。

そして、営業が帰った後の深夜のオフィスでじっくりと、常識を捨てて、お客様のご要望に向き合うのです。
この事例でいえば、publicスコープのInstagramAPI使用が許可されないケースである、と考えるのは一見合理的ですが、よくよく考えれば、出来ない理由にはならないことに気づくはずです。
例えば、偽装したボットを作ってInstgramサイトをスクレイピングしてはどうでしょう？BANされる？その度に、ボットを起動しているVM インスタンスを捨てて、IPアドレスを変えることにしてしまえばいいのです。自社製品が写り込んでいる写真かどうかの判別は、外注してAIを作ってもらうか、賃金の安い国の労働者に人力で判別させることにします。最後に残った著作権の問題については、弁護士にアウトソースすればいいでしょう。

こうして組み立てたソリューションをお見積書として提出して、出来る、出来ないをお客様に判断していただきましょう。
「出来ない」と判断するのはあくまでお客様なのです。

お客様の素敵な思いつきを、自分よがりの常識で安易に切り捨てないように心がけましょう。

仕様編

Q.仕様書がなく、このままでは実装できない為、お客様に仕様を問い合わせたところ返事がありませんでした。納期が迫っているので自分の判断で実装しましたが、アップ後、思っていたのと違う、とクレームになりました。

A.仕様がわからない時、本当にお客様のことを考えましたか？

お問い合わせをしたのに、返事がなかったとのことですが、なぜ返事がなかったのか、ちゃんと自分で考えましたか？
忙しかった？仕様を考えることができなかった？質問が理解できなかった？まさかとは思いますが、そのように考えてはいないでしょうか？一部のプログラマは簡単にそのような考えをSNSに書き込んでいると聞いたことがありますが、本当に恐ろしい事で、私の時代では考えられなかった話です。

一流大学を卒業したお客様はあなたと違ってシステムの最終的な形を完璧にイメージしています。（そうでなければ、どうして「思ったのと違う」というセリフが出てくるのでしょう？）ただ、それを言葉に出す必要はない、プログラマがちゃんとやってくれる、と私たちを信頼して、任せていただいているのです。

確かに経験のないプログラマにとって、お客様の思い描いたシステムを実装することは困難なことだと思います。しかし、真にお客様のことを思って、おもてなしの心をもってすれば、SEの書いたExcel紙芝居を元にシステムを実装することは容易です。

BSDしぐさにも「勧進帳」という話があります。突然の監査に皆が慌てふためく中、弁慶が、白紙のExcelを開いたSurface Proを手に、さも詳細仕様書が存在するがごとく、朗々と仕様を読み上げて、窮地を脱するシーンが有名です。
その後、どこからともなく飛んできた無数の矢が突き刺さって、弁慶は死んでしまうのですが、プログラマたるもの、このぐらいの覚悟を持って仕事をしたいものです。

スケジュール編

Q.受注の時点で、絶対に間に合わないスケジュールです。どうすれば良いでしょうか？

A.間に合わせましょう。

お客様が希望した納期に納品しないのはマナー違反です。
弱音を吐きたくなる気持ちはわかりますが、無理なスケジュールにも、初期に意味のない会議をしすぎたとか、仕様を決めるのに時間がかかって、結局決まらなかったけど、期末から逆算してスケジュールを決めたなど、やむを得ない理由であることがほとんどです。
工数を削減してスケジュールを短縮するという方法もあります。通常3人日かかる作業を1人日で出来ることにしてしまうのです。これなら最終的な価格も下がってお客様、営業ともにメリットがあります。難点としては、実際の作業は1人日にはならないことですが、そこはプログラマの根性の見せ所です。頑張りましょう。
また、BSDしぐさにも「一日三人日」という言葉があります。一日は24時間ですが、1人日は通常8時間の稼働を指します。よって、1日で3人日進捗することは論理的にも可能といえます。

それでも難しい場合は、最終手段として外注する、という方法もあります。動きの鈍い制作会社ではなく、フリーランスがいいでしょう。在宅ワーク可能でそこそこ高い単価を示せば、外注先はすぐに見つかります。
その際、部分的に任せるのではなく、必ず全面委託にして、丸投げをしてください。フリーランスは少し怯むかもしれませんが、総額をちらつかせて、スケジュールはできるだけぼんやりと伝えるのがポイントです。とはいえ、フリーランスはすぐ怠けたり他の案件をしようとしますので、進捗管理は細かく、とにかく急がせて、一日の全時間を案件に割かせるようにしましょう。
このような進行をしていると、プロジェクトの途中でフリーランスからの連絡が途絶えてしまい、個人携帯に電話してもまったく出なくなってしまうことがあります。この場合でも、納品遅延はあくまで逃げたフリーランスの責任になりますので、少なくとも非礼には当たらないということになります。

実装編

Q.Reactを使ったところ、先輩プログラマに注意されました。仕様上の動作条件は満たしています。何故でしょうか？

A.先輩の知らないフレームワークやツールを使うのは失礼にあたります。

かっこいいから、モダンだから、という浅はかな理由でReactを選んだのなら論外ですが、技術的優位性や保守性の向上を意図して導入した場合でも、先輩がjQueryとBackboneしか使ったことがないのであればNGです。
最近のプログラマはここで、合理的な理由を説明して、先輩や社内を説得しようとしますが、そのような行為はロジハラと見なされる場合もあります。
どうしてもgitなどのツールを導入したいのであれば、先輩が興味を持ってmasterブランチだけで開発し始めるまで待つか、先輩が辞めるなどして、現場を離れるまで待ちましょう。自分が先輩になれば、何を使っても大丈夫です。
その時になると、後輩が自分の知らない目新しい技術を勧めてくるかもしれませんが、その時は優しく無視して上下関係を叩きこみましょう。