Line 1: Error: Invalid Blog('by Esehara' )

または私は如何にして心配するのを止めてバグを愛するようになったか

>> Zanmemo

あと何かあれは 「esehara あっと じーめーる」 か @esehara まで

スタートアップで働くプログラマとして、非プログラマに対して気を付けなきゃいけないと感じていること

はじめに

 前回、非プログラマに対してプログラマに理解してほしいことというのを書いたら、なんかあとから伸びてきて、みんな思っていたことだったんだなーと思う反面、逆に一方通行に、プログラマだけが理解しろ!というのではなく、自分がプログラマとして働く上において、ちょっとだけ意識していることをあげておいたら、お互いにWin-Winかもね、と思う。そもそも、何かを要求するのに何も与えないというのも都合のいい話だろう。

 もちろん、プログラマというのは一括りにできないし、前回の如く、当たり前にやっていることかもしれない。また「気を付けている」ということなので、気を付けている程度で本当はできていないかもしれない。

 ただ、自分としては、非プログラマに対してこういうコミュニケーションが出来たら理想だなと思っている。そして、これはスタートアップの話である。すべての組織に適応できればベターだけど、そう簡単ではないことも理解している。

読み始める前に

正直、下の本以上のことは書いていないと思う。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

挨拶をする

 皆は挨拶を意識しなくても出来るタイプの人間だと思うのだけれども、しかし俺は意識しないと出来なかったりする。もともと勉強会の懇談会にいっても話しかけられない人間であって、社交性があるとはいいがたい。ただ、職場のときは、どんなに嫌いな人でも、無視されても、挨拶するようにしている(実際、ピザ屋でアルバイトしていたときは無視されていたこともある)。

 よくわからないが、自分は挨拶に対しては、変な価値観を持っていて、それは「挨拶というのは、自分の存在を知らせ、相手の存在を認める」という儀式であると思っている部分があるからだ。だからどんなにお互いに嫌だったとしても、挨拶をして、ちゃんと俺はプロトコルが開いているよ、というのを示しておくのは重要なことかなと思う。

プログラム以外の話で雑談してみる、話を聞いてみる

 優秀なプログラマであれば、「この実装はどうあるべきか」とか、あるいは「新しく出たあの技術についてどう思う?」みたいな議論を熱くかわす筈だ。同様に、経営もマーケティングも一緒で、熱のあるスタートアップならば、どういう風にやっていくべきか、真剣に考えている筈だ。

 そこで、昼ご飯に行ったり、あるいは業務がひと段落したりしたときに、相手の仕事の話を振ってみるといいと思う。具体的には「KPIってどうやって算出しているんですか?」とか、「ターゲット層として絞る場合に、どこを基準とするんですか?」とか。もちろん、忙しすぎるときは厳しいと思うけれども、たいていだったら快く教えてくれるはずだ。

 「俺は経営とか興味ないね」という人もいるだろう。自分の場合は本当に興味を持っている場合が多いのだけれども、それでもとりあえず「興味がありますよ」というのを示すのは有効だ。少なくとも「こいつは話がわかるやつだ」と思ってもらうことは、単純に働きやすさとしても、また綺麗な話でいうならば、チームの信頼性が前に向かう。よく「雑談力を身につけましょう」なんていうのがあったりするけど、雑談というのは、相手の領域で熱心にやっていることを振れば問題ない。

 こういう点でいうと、自分は基本的に挨拶をするように心掛けている。過去にピザ屋で働いていた時に、苦手な人がいて、いつも嫌な顔をされて無視されるのだけれども、それでもしつこく挨拶をしていた。挨拶をしておけば、何らかのかたちで「嫌な奴」から「好きな奴」になったときに、相手にコネクションできるからだ。もし、挨拶をしなくなると、一生「嫌な奴」で終わってしまうし、それは良くないことだと思う。それに、挨拶するということは「あなたがいるということをちゃんと認めてますよ」という合図になる。

 とはいえ、多くの人々が雑談を難しいと感じるのは、「こんな話をして余計な時間を奪ってしまうのではないだろうか」という不安であったり、あるいは「こんなバカなことを聞くと恥ずかしくないだろうか」とか「これに意味があるのではないか」とか考えてしまうからだと思う。とはいえ、信頼を構築するというのは、プロダクトを良くするという意味で重要なものだと感じる。だからそういう意味では「余計な時間ではない」し、「恥ずかしくもない」し、「意味がない」というものでもない、と俺は思う(ただし雑談ばっかりしている奴は殴ってもいい。俺を殴るな!)。

たまに周りを見渡してみて、相談しやすい雰囲気を出してみる

 実は、今お手伝いしているスタートアップの人に言われてはっとしたことがあった。それはプログラマが画面に集中しているときって「怖い」のだ。

 僕もそうだけれど、コードと向かい合っているとき、うまくいっているときは鼻歌まじりで笑顔だったりするのだけれども、だいたいうまく行かなかったり、クソコードになっていたりすると段々と顔が歪んできてしまう。それは集中して目の前の問題に取り組んでいるからなのは事実だし、そういうときこそ、一番楽しかったりする(こういう集中状態のことをゾーンといったりするらしい)。

 ただ、重要なのは、非プログラマにとって、いわゆるテクニカルな部分に関してはわからないため、とりあえず相談していたいことはあったりする。ただ、そういう風な「ゾーン状態」でいつまでもいると、話しかけづらい。そうすると、何らかの機能に対して、無理な想定がされたまま突っ込まれるか、あるいは機能が決められずに日を過ごしてしまうだけだ。

 プログラマというのは、ある意味において、何らかの機能を実装するにあたって、その機能を技術的な観点からレビューすることができる能力を持っているはずだと思う。少なくともプログラムをやったことない人間よりは、できるはずだ。もちろん望むかどうかは別だけど、望むなら、定期的に暇な時間をもうけたりして、「いま話しかけても大丈夫ですよ」という時間をアピールするといいかもしれない。

なにか応答するときは「今来た三行」を意識してみる

 当たり前だけれど、プログラマとそれ以外の人にとっては、論点が違う場合が多い、誠実なプログラマの場合、何か聞かれたときに詳細まで解説したりしていて、それは信頼できたりするんだろうけれども、しかし話として重すぎることが多い。自分もこんな長文を書いてしまうので、ついつい詳細について話してしまう。

 自分を顧みるに「誤解がないように」という形にしたいと思うんだけど、しかしついつい知らなくてもいいようなことを喋ってしまう。そうすると、「知りたいのはそこではなくて」みたいな行き違いになってしまう(たまにある)。

 そういう正確さはプログラマにとって必要なことだと思う一方で、自分が話そうとしている要点を意識することは、「何を実装しようとしているのか」という大筋がわかっているということでもあると思う。なので、出来るだけ要点を出して、相手が細かいところを聞いてきたら、それを追って説明するくらいがちょうどいいのかなという気はしている。

あんまり使いたい技術を無理に採用しないようにする

 僕もプログラマの一人だし、例えばHaskellでAPIサーバーを書き直すとか(実は自分のところではそういう話が出る。もちろん、現状やらないけどね)すごく夢がある。そして、それができることがモチベーションの根源だったりする。自分の使いたいものを仕事で使うという機会というのは、案外あるようでない。だから、モチベーションがあがるという意味で、使いたい技術を入れちゃいけないとは思わないし、そういうチャレンジの部分があったほうが、開発として楽しくなると思う。しかし、だからといって安直に使いたい技術を利用してしまうと、それが足かせになってしまうこともある(最近では、それがmongodbだったりするみたいな話はたまに聞く)。

 だから、「これを使いたいなー」と思ったとき、「いやこれ使っちゃうとあとあと苦労するかもよ」と思えるかどうかは重要だと思う。苦労して使うものを減らした自分としては、以下のような基準になるのかなとにらんでいる。

  • 採用したい技術について、何かしらの機能を使うために必要なものなのか
  • 採用したい技術について、それが稼働している間、その技術について継続的に詳しくなるモチベーションが保てるか
  • 採用したい技術について、メンテナンスするコストよりも、それによって受け取るコストのほうが大きくなりそうか
  • 採用したい技術を使うプロダクトは捨てることができるものか、あるいは捨てるまではいかなくとも書き直しに関して現実的な日数で収まるか
  • 採用したい技術について、プライベートで使ってみて納得したか
  • 採用したい技術を使うことで、チームの士気が上がるか
  • 採用したい技術を使うことについて、自分が信頼しているプログラマが納得しているか
  • 採用したい技術は今使うものなのか(将来に備えて、ではなく)

 たぶん、これのどれにも当てはまらないものに関しては、あまり採用してはいけないとは思う。問題は「何かあったらちゃんと面倒見切れる?」という話だと思う。最初に採用した技術について、本当にじわじわとジャブのように叩かれていくので、出来るだけ最小限の構成にしていくのは必要だと思う。しかし、これらについて当てはまるものがいくつかあるのならば、それは実際に使ってみるべきものだと思う。

他のひとがやっている業務を楽にできないか考えてみる

 プログラマという仕事は端的に言ってしまうなら、コードを書くことによって、なんらかの問題を解決することだ、と言えると思う。場合によっては問題とはいわないけど、ユーザーを笑顔にすることというのもある。たぶんどっちかだと思うのだけれども、他の人が効率的にできないことでも、コードの力があれば解決できるものはあると思う。事実、今見ている業務についても、「このあたりはああやれば改善できそうだな」ということが幾つかある。

 そして、それが社内で使われるのなら、とりあえずの「やっつけプロトタイプもどき」みたいなコードを書いてあげるといいと思う。それで楽になった場合、すごくいいと思う。

動いてない綺麗なコードよりは動いているけどクソコードのほうによせる

 自分なんかもそうだけど、コードの良さみたいなものにこだわり過ぎてしまうことが多い。ただ、注意しなければいけないのは、プログラマ以外からしたら、コードの内部がどうなっているかよりも、ちゃんと動くかどうかのほうが重要だ。当然、コードの質は開発速度に関わってくると思うのだけれども、しかしそこにこだわり過ぎると意味がない。

風呂にはいる

すいません

まとめ

 正直、プログラマというよりも、プログラムが好きなのは、知的な遊びであると同時に、単純にコードでできることなんてたくさんあるというところだと思う。そしてコードを書くと喜ばれる。コードのことを教えると喜ばれる。で、そういう能力と知識を持っている以上、その能力を分け与えたり、あるいはそのことについて教えられるようになったほうが、チームとしてもよくなるし、まわりまわって自分のためになるのかなーと考える。