読者です 読者をやめる 読者になる 読者になる

現場の反対はまた別の現場 #DevLOVE

この記事はDevLOVE Advent Calendar 2013「現場」 の11日目の記事になります。 昨日はうえじゅんさんの「僕らは進化する、そして現場も進化する」でした。

タイトルについて

「正義の反対はまた別の正義」のパロディです。*1

詳しくはぐぐってください。

自己紹介

すえなみと申します。漢字で書くと末並です。「末波」とよく間違われますが「末並」です。

とても希少な名字なので勉強会等で「すえなみ」と名乗ってる人間がいたら間違いなく僕のことだと思ってください。

オンラインでは a_suenami とか a.suenami とかで活動してます。

所属は渋谷にあるファクトリアルという会社で、受託開発のお仕事をしています。RubyPHPあたりがメインの開発言語です。

よろしくお願いします。

現場とは

さて今回のテーマである「現場」について。 「現場」とは一体何でしょうか。

僕が「○○とは何か?」と考えるときは必ずその反対は何かを考えるようにしています。対象の反対が何かを考えると自分が対象に対してどういう印象を持っているかを分析することになりますし、思考を整理するためにうってつけなのです。

では「現場」の反対はなんでしょうか? 「経営」でしょうか?「マネジメント」でしょうか?それとも「現場」イコール「開発現場」だとすると反対は「基礎研究」でしょうか?

どれも間違いではないのでしょうが何だかしっくりきませんね。

DevLove Advent Calendarの3日目の記事である「現場と現場をつなぐ現場」でoppyさんも述べていますが、経営者にも経営者の「現場」があり、マネージャにもマネージャの「現場」があるはずです。もちろん研究者には研究者の「現場」が。

そういった思考の中で僕がたどり着いた結果がこの記事のタイトルで「現場の反対はまた別の現場」です。

「また別の現場」を知ること、ただし依存しないこと

「現場」にはその現場のルールや文化があります。 そして「また別の現場」にもその現場のルールや文化があります。 これらはしばしば「プラクティス」や「パターン」として形式知化されて共有されますが、それをそのまま取り入れてすぐにうまくいくことなんて稀でしょう。

僕は学生時代にとあるビジネス系の学生団体に所属していたのですが、その関係で周囲にスタートアップのベンチャー企業をやっている人が多く、そういった人たちから開発やサービス設計やチーム作りに関する相談を受けることがあります。ただ、そのときに本当に心から思うのは、それぞれのチームで抱えてる課題もチームを包んでる雰囲気もまったく違うということです。 当たり前ですが、僕がファクトリアルという「現場」で実践していることをそういったスタートアップ企業の「現場」に持ち込んでもうまくいきません。ビジネスのフェーズも違えば、開発しているものもそこに集まっているチームメンバーも組織としての文化も違うからです。

「また別の現場」がどういうやり方で日々の仕事をしているがを知ることは大事です。その点でDevLoveをはじめ多くのコミュニティ活動や勉強会が果たしている役割は非常に大きく、僕もそういったコミュニティや勉強会のスタッフの方々には常々感謝しております。

ただそれに依存するのは「現場」としてあるべき姿ではありません。 「別の現場ではxxxxをやっているらしいからうちでもそうしよう」と安易に考えるのは思考停止以外の何者でもありません。*2

あくまで「現場」はそこにいる人たちがつくるものなのです。

考えることをやめないこと

考えることをやめないこと。 これが僕が「現場」に求める唯一のことです。

何がうまくいくかわかりません。何が正しいかわかりません。いえ、むしろ正しいことなど存在しないのかもしれません。 だからとにかく考える。考えることだけはやめない。そういう現場が僕は好きです。

わかりやすい目標や役割分担はときには必要だと思います。 コストやスケジュールと照らし合わせると「思考」の時間をできる限り短くして、「作業」の時間を多くすることを余儀なくされることもあるでしょう。 しかしそれは現場の人たちを簡単に思考停止に陥らせる劇薬です。ほどほどの使用にしないと現場は疲弊し、プロダクトの品質は下がる一方でしょう。

そこで世の中で広く受け入れられているプラクティスやパターンを活用しましょう。これらは「考え続けること」を後押しする強力なツールです。

  • アジャイル開発は「振り返り」の機会を提供します。
  • リーンスタートアップは「ピボット」することを容認します。そして「ピボット」するかどうか考える機会を提供します。
  • カンバンやデイリースタンドアップは日々の業務を可視化し、うまくいっていないことはないかどうか考えることを支援します。
  • テスト駆動開発(TDD)はコードが健全な設計になっているかどうか考えるきっかけとなります。

世の中には多くのプラクティスがあり、それらがプロダクトやサービス、そしてその先にあるビジネスの成功に対してどのように寄与するのかについても多くの報告があります。 しかしそれは、あくまで現場が「考えることをやめなかった」結果であり、プラクティスそのものがビジネス価値を生み出したというよりは、現場が考え続けることをプラクティスがサポートすることによって間接的にビジネスに寄与したということだと捉えています。

これを読んでいる人は基本的には「考え続けている」人が多いと思いますが、さらなる高みを目指すための一助になればこの記事を書いた甲斐もあったかと思います。

バトンタッチ

明日はつつひさんです。 どのような現場のお話が聞けるか楽しみです。 よろしくお願いします。

*1:漫画「クレヨンしんちゃん」に登場するしのすけの父・野原ひろしの言葉だという説があるみたいですが、どうやらガセネタの模様です。

*2:もちろん十分に考えた結果なのであれば問題はありません。