Satoryu's Diary

Rubyが好きなプログラマーの日記。日々の生活、開発に関するメモとか考えとか。


2016年05月12日 [長年日記]

_ 情シス業で学んだ2つのこと

いわゆる情シス的な部署に異動したのが2013年2月なので、3年は経過している。 異動とこれまで作ったものを手放さなければならなくなるというのをつい先日に言い渡されてから、色々とこれまでのことを振り返っている。

やったこと

Active DirectoryとLDAPでお話して組織情報に基づいて色々素敵なことをしてくれるサービスをRubyとRailsでフルスクラッチで作ったり、ドキュメントが殆どなく現行動いているもののソースしか残ってない外注製のアプリをこれまたRailsで書きなおしたりした。 他にも突然降ってきた採用ページのコンテンツサーバーを作ったり、違うところで扱ってるサービスを巻き取るんだ!というからヒアリングしてきたり、とか。

どんな風にやったのか

スクラムでやってきた… と思う。 と思うというのは、スクラムをやろう!という流れで始まったけれど、最終的にチームで残ったのはリズムだけだったと思う。たぶん置かれている状況に合わせていたら、そうなったという感じ。 プロダクションサービスのように新しいものを決まった期限に出さなければいけない制約は少なく、どちらかというと色々なニーズや依頼をさばいていくことが多かったので、本来のスクラムみたいにスプリントゴールの達成を厳しく守ったかというとそうではなかった。

学んだこと

スクラムが何だとか、Railsでの開発がなんだとかそういうことはあんまり無い。全く無いわけではないけど、手段なので、情シスとして学んだことか、というとそうではない。 むしろそんなに最新の技術をどうこうしてどうにかなるようなものではなかったように思う。

人の話を聞く

サービスづくりで一番大切なのは、使う人、使ってる人の話を聞くこと。 プロデューサー*1の多くは、これができているようでやれていなかった。 手を抜いているとかではなく、ハマるポイントに陥っているように見える。情シスが提供するサービスは社員がユーザーなので、自分自信がユーザーにもなる。なので、「自分だったら、こうだといいな」が拡大解釈してしまっているような感じ。「きっとこれは便利」と思い始めて、要件だけが膨らんだりして、何が本当に欲しいのか分からなくなるような話は沢山来た。ユーザーは社員なので、オフィスを歩けば聞きにいける。何かわからないことがあったら、聞いてしまえば良い。聞いても怒られたりなんてしなかった。そもそも具体的に、使うと想定されるユーザーの名前が実名で出せない時、そのアイデアは意味があるか疑わしいと思う。

あとは、ユーザーからの問い合わせは大切。システムに加えた変更の大きさに比例して、問い合わせの量は増える。良くも悪くもリリースは、それまでと異なる挙動をするので、ユーザーを驚かしてしまう。驚いたら聞きに来るのは、当たり前。ユーザーからしても、こちらは同じ社員なので聞きやすいのだろう。驚かせてしまったのはこちらのせいなので、じっくり聞く必要がある、例えそれが些細なことだとしてもだ。基本的な機能がうまく操作できなくて躓いてしまったので困ってる、といったものなんてのは日常茶飯事。それを「相手のリテラシーが低い」とか言ってはならない。もしそうならばこちらから歩み寄るべきだ。使い方のマニュアルを用意したり、画面の文言を変えてみたりとかやりようはいくらでもある。反対に、相手にリテラシーの向上を求めるだけならば、その後に何も得られないだろう。信頼は無くなるだろうね。 キツいことを言われることもある。最初のリリースをした後に、偉い人から「業務で使い物になりません。部下に使わないように支持しました。」みたいなメールを貰った時は血の気が引いた。偉いからとか関係なくて、そういう人の大切な時間を奪わないようにすることが目的だったのに、相手の課題を見誤ってしまったのだ。間違った方向に進んだせいで、新しい課題を与えてしまったとも言える。この時もチームで話を聞きに行って、何に困っているのかを聞いて、直した後にも使い勝手を見てもらった。リリースの後に、その人のアクセスログを見ながら、その人の負担が下がっている、その人の部下の人たちが使っているのが確認できた時に、とても安心したのを覚えている。

自分達のサービスではないことについても聞かれることは良くあった。どこに聞けば良いかわからずに迷った末に、一縷の望みかけて聞きに来てくる。「いえ、それはこちらではありません」と言うのは簡単なのだけど、それをやるとまたユーザーは宛のない旅に追いやられてしまう。そういう時は、こちらで担当者を探して取り次ぐように心がけた。全部が全部できたわけじゃないけど。

「ありがとう」

リリースが上手く言った時より、テストが全部通った時より、何より嬉しいのは「ありがとう」という言葉を貰った時。システムのメトリクスは大事なのは知っているが、それらよりも成功の実感を一番得られるのはこの言葉を聞いた時だと思う。昨年、社内ですれ違いざまに立ち話で聞いたちょっとした機能改善の話をその翌週にリリースした。その後、その話をしてくれた先輩から「ありがとう」のメールを貰った。良い提案だったからそのまま実装しただけなのに喜んで貰えた。その時、色々と気が滅入ることが多かった時期だったので、あのタイミングで言ってもらえたのでむしろこちらが感謝している。

おわりに

眠い頭で色々と書いて、文体がおかしかったりするんだろうけど、思いつくままに書きだしてみた。情シスって言うと、人によってはあまり良い顔しないみたいで、窓際にある部署のイメージすら持たれているようだ。でも、やれることはいくらでもあるし、やりがいだってある。コストセンターという言われ方もする。なので、いかに安く済ませるかという話に行きがちに思う。でも、最初にシステムの導入コストを支払って、あとはランニングコスト。社内システムなのでユーザー規模は社員数が最大値でしかないのでシステムの規模はある程度は読めるだろう。スタートアップのサービスとかではないのでTVで取り上げられてアクセスが急増するとかは無いから、システムのランニングコストは緩やかにしか変化しないだろう。そこのコストを下げよう下げようとするのではなく*2、システムが生む価値を上げようとする活動が無ければ無意味だろう。

自分が次に何をやるかは決まっていないのだけれど、「ありがとう」を集められる、そういう環境にしたい。

*1 弊社でプロジェクト、プロダクトの両方の管理をするポジション

*2 もちろんできるのであれば下げれば良い。でも、それだけに執着してはいけないと思う。


最近の投稿

翻訳しました(ちょっとだけ)

follow us in feedly