プログラマーのための「Rubyの世界」イベントレポート(後編)
2015年9月28日、エンジニア目線の求人サイト「Forkwell Jobs」主催による、プログラマーのための「Rubyの世界」と題したイベントが開催されました。
第一部で講演した、Rubyコミッター、かつ、日本人唯一のRuby on Railsコミッター松田明氏の講演レポート(前編)はこちら
第二部では、“今どきやり方でWebサービスを作ろう”をテーマに、今回のイベントの運営元、Forkwell Jobs 運営する株式会社groovesのエンジニアでもある後藤大輔氏に講演いただきました。
講演者プロフィール
後藤大輔(@idesaku)
SI企業に10年勤めたのち、フリーランスに転身したプログラマー。
インターネット上や勉強会で「フリーランスです。Rubyで仕事をしたいです。」と言ってみたらそういう仕事をいただけることになり、SIer時代に夢見た環境で充実した日々を送っている。 Webサービス開発を生業としつつ、執筆経験も少しあり。
今回は「今どきのやり方でWebサービスを作る」というタイトルにさせていただいたんですけど、「今どき」ってなにが今どきなのか、非常に難しいんですね。
最初は安直に、今流行のあれやこれやキラキラしたツールを使えばいいんでしょと思っていましたが、じゃぁ、例えば今流行のReactを使えば今どきといえるんでしょうか?
あ、違うなぁ~と…
ツールとかフレームワークとかを自分たちの現場が使うべきかどうかというのは、単に自分たちがなにを作りたいのか、どの程度のサービスにしたいのかによって決まる問題であって、別にこういうのを使ったからって「今どき」ではないはずなんですね…
さて、“今どき”ってなにを今どきと言おうかなぁと。昔も今も変わらず、我々が必要としていて、振り回されていて、それでいて「今はこうなって良くなったよ」と言える、そうしたスイートスポットはなんだろう?と考えて、大変私はつまらない結論に到達しました。
やはり、チーム間のコミュニケーションの話をせねばならぬようだなと。
確かにこれは時代に関係なく、どうしても対策が必要とされる課題です。しかし、コミュニケーションと聞くと、背筋がぞわぞわ来るんですよ。
皆さんもすでに耳タコだと思うんですよね。
皆さんが勤めている会社の人事担当者にどんな人材がいるのかって聞いたら、「コミュニケーション能力の高い人。仕事なんて入社して覚えればいいんだよ」と…イラッときますよね、アレ(場内笑い)。
しかしですね、実際コミュニケーションは大事なので、仕方ないんです。
我々はチーム開発をするわけです。しかし、チームというのは、1人月が5人月になったから生産性は5倍って、そういう単純な話ではないんです。
チームを組むことのメリットは、異なる専門技術を持った人間が一カ所に集まって、緊密な連携を取って集合知性的な1つの生き物として動く、そこまでやってこれまで一人ではなしえなかったことをチームの力でやり遂げる…ここにメリットがあるんですね。
つまり、我々はプロの仕事を作るために、プロのチームを作らねばならず、プロのチームを作るためには、密接で適切なコミュニケーションスタイルが必要とされます。それは、一緒にお酒を飲んで仲良くやりましょうなんて、そんな子供じみたもんではないです…そんなのは大学生に任せておけばいいんです。
我々プロは、プロフェッショナルスキルとしてのコミュニケーションというのをキチンと身につけなければならない。
では、プロのコミュニケーションとはどういったものか。ここでは、こんなコミュニケーションの取り方をする奴はプロじゃねぇ、取り合えずこれをクリアしていればお前達はプロだ、俺たちはプロだっていうことができる最低限のラインを定めようと思います…なんだと思いますか?
私が思いますに、「口頭では言ったけど…」というやつだろうと。口頭でやり取りする奴はなにをやっても駄目です。
口頭でやり取りをするというのは、話した当事者にしか情報が共有されません。口頭でのやり取りはしちゃいけないというのは昔から知られていました。故にその件について先人達は我々にアドバイスをしてくれています。「メールを使え」です。
なので私は、ソフトウェア開発プロジェクトに参加する度に、まずこれがあることを確認して、無ければ作りました。メーリングリストです。
メーリングリスト、凄い便利ですよね。
これを正しく運用するだけで、問題は抜本的に解決します。これまで口頭でやり取りをしていた内容をメーリングリストにするだけで、記録として残りますし、チームメンバーにちゃんと共有される。便利なんですけど、私はどうもこいつが苦手でして、1ヶ月もするとメールを見なくなってしまうんですね…。
なんでかなと思うんですけど、私が思いますに、プロジェクトが進んでいくうちにメーリングリストの参加者が増えて、メールの本数がモリモリ増えていくと、そのメールの適切な分類と整理が難しくなっていくからなんですね。
大量のメールがある中で、このメールは自分がちゃんとみなければならない、このメールは無視しても構わないといった強弱の付け方が大変難しい。それで結果的に面倒くさくなってみなくなってしまう。中には大事なメールもあるのに、メール全体がゴミの山に見えてしまう。
しかし、現在そういった苦労はほぼ無くなりました。
私は今3~4本のソフトウェアプロジェクトに関わっているのですけど、どのプロジェクトともメーリングリストを使っていません。代わりにみんな大好きチャットツールを使っています。
現在のチャットツールは従来のものにくらべ大分機能が強化されています。メーリングリストでは難しかった情報の分類も結構簡単にできるようになっているわけです。
例えば、Slackでは、 関心事を分類することができ、どこにどのような情報が来ているかを一覧することができます。また、チャットツールではメンション(特定のユーザー名の頭に“@”を付けることにより、メッセージの送り先を明確化する)を使うことができます。小さな事ですけど、かなりコミュニケーションロスがなくなってきます。
さて、我々がプロジェクトで行うコミュニケーションというのは、テキストメッセージングだけではありません。
たとえば議事録だとか、設計書だとか、そういうドキュメントの形で残すことが効率的な場合も多々あります。当然そうしたドキュメントも、共有されなければなりません。
ドキュメントを共有するとき、皆さんどうしていますか?
私はかつて当然ファイルサーバーを立ち上げました。
ファイルサーバー、便利なんですよね。リモートにあるファイルが自分のマシンにあるように見えて、単純にドラッグアンドドロップすればそれだけでデータ共有ができるわけです…超便利です。しかし、その便利さ、簡単さもあっという間に色あせて、後はつらさしか残りません。ファイルサーバーには、共同作業における必須の機能、「変更管理」が欠けています。それをなんとか再現しようとして、ファイルの名前や置き場所への工夫を迫られ、結果として似た名前のファイルがあちこちに点在する、極めて管理しづらい環境ができあがります。
そこで、esaやQiita:Teamが役に立ちます。どちらともちゃんと変更管理機能を備えており、diffも見やすいです。さらに元に戻す機能すら備えているわけです。
さて、ドキュメントも共有できて、設計書も共有できました。皆さんはプログラミングを開始します。
プログラムを書いていると、当然皆さんはやりたくなることがありますよね…コードレビューです。
コードレビューが有効なことなんて、遠い昔からみんな知っていました。しかし、わたしはそれをちゃんとやれた試しがありません。コードレビューという営みが高コストだからです。
かつては、自分が行った変更内容をレビュワーに渡し、そのレビュー内容をまとめ、自分のプログラムを修正していく、という一連の作業を簡単に行う方法が無かったのです。そのため、ミーティングを計画して、みんなでパソコンを持ち寄って口頭で…という負担の大きなやり方になり、継続できなくなるのです。現代は変わりましたね。“Pull Request”凄いです。Pull Requestほど私の生活を変えたものはないなぁっと思っています。
最悪、今まで紹介したツールはなくても何とかなるかも知れませんが、Pull Requestなしの開発は考えられません。
Pull Requestとは、自分が書いたコードの差分をレビュワーと簡単に共有するための機能で、レビュワーは変更内容の確認と問題箇所の指摘を大変見やすいWebページ上で行うことができます。この機能は、コードレビューという作業を革命的に簡単にしました。
ここまで様々なアプリケーションやサービスを紹介してきましたが、次に問題になるのは、そいつらをどう結びつけるかという点です。それぞれのツールをバラバラに運用した場合、情報が分散して何をどこに置いたのかがわからなくなってしまいます。
今回私が紹介したツールは全てウェブツールであり、情報全てにURLがあり、リンクを張ることができます。そのため、URLへのリンクを作る、というWebらしいやり方で、簡単に連携させらせます。連携できていれば、どの情報をどこに置いたかを気にする必要が無くなります。リンクをたどっていけばいずれたどり着くからです。
特にその強みを理解しているのは、Slackでしょう。Slackには連携先の外部サービスが80個も登録されていました。そして、Slackは外部との連携を使いはじめると課金が発生するのです。
さて、こうしたオンラインベースのコミュニケーションツールの導入に成功したとします。しかしそれだけでは不十分です。これらを使う場合にはこれらに即した使い方をしなければなりません。
まずは、みんな大好き、emoji(絵文字)を使えるようにならねばなりません。
emojiは超重要です。遊び道具ではありません。
emojiを利用することで、ともすればトラブルを起こしがちな素っ気ない文章が表情豊かになるので、現在のネットワークベースのコミュニケーションでは必須になりつつあります。是非気に入ったemojiを利用するようにして下さい。
とはいっても、emoji自体は言うなれば、小手先のテクニックではあるんですよ。本当にうまくやっていくためには、我々のメンタルにも変化が必要です。
そこで、是非HRTを身につけるようにして下さい。HRT—ハート(Heart)と読みます—は優れたチームを作る上でメンバーが持つべき心構えのようなもので、謙虚(Humility)・尊敬(Respect)・信頼(Trust)の頭文字を取ったものです。チーム以前に、そもそもこれらを備えずして良い人間関係を作れるはずもありません。是非、このHRTを身につけるようにして下さい。
参考:Team Geek(http://www.amazon.co.jp/dp/4873116309)
オンラインのコミュニケーションツールが揃った今、会社に出社する必要があるかどうかを検討すべきかも知れません。
たとえば、株式会社groovesではすでに導入され、実際に機能しています。導入の度合いに差こそあるとしても、大きなところでは週1出勤で完璧に仕事が回っています。そしてその社員は片道1時間半の出勤をキャンセルできるので、その分の時間を有意義なことに当てています。それにより人生が充実し、ひいては仕事が充実します。
しかし、ここではリモートが持つ別の効能に注目したいと思います。近くに同僚がいないリモート環境に身を置くことで、「口頭」でのコミュニケーションへの誘惑を断ち切ることができるのです。
まとめますが、我々はプロの仕事を行うために「口頭」でのコミュニケーションを排除しなければなりません。それはかつては難しいことでしたが、環境の変化によってできるようになってきました。ですので、こういった効率的なプロのコミュニケーションを皆さんにもやっていただきたい。
もし、それが今の環境ではかなわないのであれば、新しい環境に飛び出してみるというのも考えていいんじゃないかなと思います。
以上、有り難うございました。
第一部、松田明氏の講演レポート(前編)はこちら