ワークスタイルの最近のブログ記事

人数の少ないベンチャーや小さな会社では、仕事の「かけもち」はよく発生します。SonicGardenでも同様です。SonicGardenでプログラマは、お客様との要求開発からデータベースや画面の設計、プログラミングからクラウドでの運用、サポートなどもします。それだけでなく、会社の経営上の必要なことであれば、割となんでもしますし、案件の掛け持ちも普通にあります。

(c) 伊藤サトシ｜ストック写真 PIXTA

一般的には、掛け持ちや兼務は効率を落とすため悪いことだと思われていますが、私は組織にとって逆に良いことではないか、と思うようになりました。確かに、効率だけを考えたら一つの仕事だけに専任することの方が良さそうに思えます。実際に、それなりの組織になると総務や経理といった部門に分けますし、もっと大きな会社になれば人事部門、企画部門などより専門性をもった細かな部署に分かれるようになります。

しかし、そうした専門部署が会社を悪くする原因の一つではないか、と思うのです。

専門部署が無駄を生む

役割分担のしっかりした組織では、忙しそうに見えて実は暇な社員が沢山いるんです。細分化された役割と目標の中で、もし早く仕事が終わってしまったとしたらどうするか？その役割を超えて別の何かをする訳ではなく、その役割の中で品質を高めようと努力してしまうんです。世の中の仕事の大半は、80%程度の品質で済んでしまうはずですが、それ以上の品質向上を目指すのはかけるコストに対して見合う成果としては非常に小さいです。

もしExcelの見栄えを直したり、印刷物をキレイに出そうとしてる人がいたら、それは暇な人です。

実は、ソフトウェア開発でよくある「人月」の契約でも、それが起きがちなんじゃないかと思っています。発注側の意識というよりも、受注側は人数分のコストを受け取ってしまったら、他にすることもないので、それだけに専念しすぎてしまって、無駄に綺麗な仕様書とかに拘ってしまうのです。

かけもちせずに一つの役割だけでお金をもらってしまうと、それに依存せざるを得ないため、本末転倒することがおきてしまうことがあります。政治家が掛け持ちできずに選挙に当選することが仕事だと思ってしまう政治屋になるという話もよく聞きます。大企業だと、品質管理部やセキュリティ監査部といった部署がありますが、その部署の人たちにとって「取り締まること」が仕事になると、会社のパフォーマンスを落としかねなくなります。

この問題は、専門部署の人たちが真面目であればあるほど、その役割を全うしようとし過ぎて起きてしまうのです。

掛け持ちが助け合いをうむ

人がいないために、やむなく仕事のかけもちをやったりしますが、そうすると自分の役割を超えた視点を持つようになります。もちろん本業があってのことですが、組織全体のゴールは何かを常に考えていなければいけないので、お互いに助け合うようになります。それぞれの人にとって好き嫌いや得意不得意があるので、適材適所に人を配置することは大事ですが、一つだけの役割で業務分掌を決めずに、なんでもするというスタンスが助け合いの文化をつくります。

掛け持ちすると、とても忙しくなります。そこで100%の品質や成果を求めるのではなく、組織のゴールが明確に共有されてさえいれば、しなくて良いことも沢山みえてくるんです。掛け持ちしてると無駄なことをしてる余裕がなくなるんです。キレイなExcelとか用意してる暇なんて無い。大事なポイントは、すべてを100%にしないという割り切りを全員に浸透させることです。

100%を超えた掛け持ちは、ただのブラック企業の過労働になってしまいます。

また、一人に一つの役割だけしか持たないとなると、個人の目標も一つになってしまって、それに賭けるしか無いということが起きます。それが本人の頑張りだけで何とかなるのであれば良いのですが、世の中そうはいきません。掛け持ちしてれば、一つ駄目だったとしても、もう一つの方で頑張れば良いんだという気持ちも起きたりするので、精神的にも良いんじゃないかと思います。

トータルフットボールが出来るチームへ

私は、サッカーでいう「トータルフットボール」という戦術が好きで、チームとして理想的だと考えています。「全員攻撃・全員守備」の意識で、ポジションはあるにしても、ゴールのためにはお互いに遠慮しあわない。トータルフットボールは「選手一人一人が同じくらい高い技術と戦術眼を併せ持ち、なおかつかなりのスタミナが必要」ということですが、むしろ、社員にはそんな風に育ってほしいと思うし、そういうチームを目指したいと思うのです。

これまでコンサルタントの方と一緒に仕事をする機会もあり、横で話を聞いていて、相手に伝えるのがとても上手だなぁと感心をすることがあったんですが、何度か経験をするうちに優秀な方のプレゼンテーションには共通のフレームワークがありそうだと気付きました。ここでのプレゼンテーションは、勉強会などのLTや発表というよりも、顧客にプロダクトを説明するケースです。

(c) Haruru｜ストック写真 PIXTA

技術者のプレゼンテーションは、中身に詳しいが故に、どうしても「正確に伝えよう」「全て伝えよう」としてしまいがちです。もし技術者を相手にした「セミナー」であれば、それでも良いかもしれません。それも、聴く人たちが詳しく知りたいという動機をもって参加している場合です。

しかし、プレゼンテーションをする相手が、その技術やプロダクトについて詳しくなく、そのプレゼンテーションを聴いたあとに、興味をもってもらって、問い合わせなどのコンバージョンに繋げたいということであれば、正確性や網羅性の優先度は低いと考えた方が良いです。上手な人のプレゼンテーションだと「よくわからないけど凄かった」という感想が出ます。問い合わせに繋げたければ、それで十分なんです。

よくある技術者がするプレゼンテーションだと、○○とは？といった定義から始まり、全体の構造と特徴を示して、あとは一つ一つの部品と特徴について詳しく説明する資料が何枚か続き、最後にまとめ、というスタイル。これでは、興味を持ってもらえなかった場合、中だるみしてしまいます。ではどうすれば良いのか。出来る人のフレームワークに従えば良いのです。

上手なコンサルタントの方々のプレゼンテーションには共通の流れがあり、それに従って作れば、誰でもそれなりのプレゼンテーションを作ることが出来るのではないか、と考えました。その流れは以下のようなものです。

1. 問題に至る背景の共有と共感
2. 対象とする問題の提示
3. 解決につながる仮説(プロダクト)
4. それが正しい解決であるというプルーフ

まず最初に、プレゼンテーションをする相手の人々に共通する背景を説明します。これは、共感を得てもらうことが目的です。まず、相手と同じ視点を持っているということや、プレゼンテーションをする自分はどういった文脈で話すのか、ということを伝えた上で「同じ問題意識を持っているのかも」という共感を得てもらいます。これによって、聴く側は話を聞く心の準備ができますし、なによりも同じ問題意識を持っていると思ってもらうことで、対立ではなく同じ方向を向いていると思ってもらえます。

上級テクニックになると、この背景の話の中で、さりげなく数字を含んだグラフや表を入れ込みます。そうすることで、より一層、リアリティが増すので、そこで話されている背景が本当のことだと理解してもらえます。

背景を共有し、それに共感してもらえたら、次はその背景の中で起きている問題を示します。実際には、その背景からは様々な問題が出てくるとしても、それを網羅する必要はなく、ここで提示する問題は、次の自分たちで解決出来ることにフォーカスした問題だけを提示するだけで構いません。むしろ網羅するよりも、フォーカスをあてた方が良いです。聞いている人たちも考えながら聞いてくれるので、その背景から沢山の問題があることは承知の上なので、あえて自分の主張に繋がる問題だけを伝えます。

そして、その問題が的外れではなく、プレゼンテーションの相手も問題だと感じてもらえたら、それに対する、自分たちのソリューションを提示します。それは、特定の技術かもしれないですし、プロダクトかもしれません。このプレゼンテーションで興味を持ってもらいたい対象です。問題を解決するものだと提示をしますが、そうすると聞いている方にしてみると、本当かな？と思ってもらえる筈です。実はそのように疑問を持ってもらうことが大事です。疑問を持つということは興味があるということです。

そうして、ようやく準備が整いました。ここまでくれば相手は疑問をもっているので、詳しく聞こうという姿勢になってくれています。そうしたら、あとは好きなように技術やプロダクトの説明をしましょう。ここでは多少、難しい用語を使ったりしても大丈夫です。そのソリューションであるという仮説が正しいものであるという証明をするのです。機能や特徴の説明も、なぜこの問題の解決に繋がるのか？という視点から説明すると良いでしょう。

実際は、相手との関係性や、お互いの背景、プレゼンテーションの目的などによって、変えていくしかないと思いますが、こういったフレームワークも知っておいて損はないと思います。

先週末から、SonicGardenのプログラマである @maedana が、住居をアイルランドのダブリンに引っ越しました。一方で、SonicGardenの仕事は続けてもらうことになっています。少し面白いワークスタイルなので紹介します。

View Larger Map

彼は特にアイルランドに縁もゆかりもあるわけではないですが、英語を身につけたいというモチベーションがあり、英語圏で彼の年齢で長期滞在が出来るところは限られており、結果としてアイルランドに決めたようです。（ただダブリンはRubyにゆかりのある松江市と姉妹都市らしいというのを後から知りました。縁ですね。）

当社（SonicGarden）では、以前からどこでも仕事が出来るためのノマドなワークスタイルを目指していました。その為に、仕事は当然ノートPCですし、システムはすべてクラウドに置き、厳密な勤怠管理をするのではなく自主性を重んじるなど、環境と制度を整えてきました。

その結果として、3.11の大震災の際も、震災後に無理をして出社するということはしないで、各自が在宅か地元に帰って、そこから通常業務をするようにしましたが、まったく業務に支障がないことが判明しました。（請求書発行などの事務仕事は難しいと思いますが）

当社では、自社サービスの開発運用と、納品しない受託（サービス型受託）の開発運用、この２つを事業部で分けるのではなく、それぞれの個人の時間の中でシェアするという業務の仕方をしています。当社のプログラマは自社サービスのディレクターも兼ねる場合がありますが、彼の場合は純粋なプログラマです。

私たちの言う「プログラマ」は、ただ言われた仕様を実装するのではなく、プロダクトオーナーとディスカッションして要件を確認し、画面やDBの設計をし、ソースコードで表現をし、テストを行い、ステージング環境や本番環境へのデプロイから、日々の運用まで、ソフトウェアの開発と運用に関する全てを行う職業のことです。

当社でのプログラマの仕事の仕方は、Pivotal Trackerというインターネット上で動いているタスク管理のツールを使って、そこでインプットされた要件を順番にこなしていくのが基本です。内容がわかりにくいものは、SkypeやyouRoomを使って納得がいくまでディスカッションします。プロダクトオーナーはそれに応えられるようにしています。

このスタイルは自社サービスだろうが受託サービスだろうが同じようにやっています。彼自身は移動することなく、日本にいるプロダクトオーナーと連携しながら仕事を進めることができるようになっています。ノートPCとネット回線さえあれば、世界中のどこにいても仕事ができるのです。

なので在宅勤務でも良いのですが、彼の場合は独身ということもあり、家にずっといたいという動機は薄く、会社には出勤という概念より、ワーキングスペースを使う意味で来ていました。そこで彼は閃いたんです。そもそも在宅勤務でも良いということは、家を別の国に移して、在宅勤務しても良いということに。

私としては、将来的には世界中のプログラマと仕事をしたいと思っていますし、プログラマが場所に縛られずに仕事ができれば、今までよりも精神的にも物理的にもより豊かな生活を送ることができると思うので、彼のアイデアには大賛成で、応援することにしました。むしろ、そんなチャレンジをしてくれることに感謝しています。

これは、将来のビジョン実現に向けた壮大な実験の一つです。おそらく時差の関係など、想像もつかない課題は出てくる可能性はありますが、ひとつひとつクリアしていき、このプログラマのノマドワークスタイルについての経験と知見を貯めていければ良いなと思っています。

ダブリンに旅行などで行かれて興味ある方は @maedana にコンタクトとってみてください。そして、こんな働き方に共感してくれた方は、ぜひSonicGardenのFacebookページのLikeもお願いします！

あわせて読みたい：

• 仕事をするのにオフィスはいるのか？


• ソフトウェアをサービスで提供するビジネスにおけるタスク管理とは〜RedmineからPivotal Trackerへ