毎日がもふもふ

新規事業に特化した渋谷の開発会社mofmof inc.を経営するエンジニア兼代表・原田敦のブログ

コミュ力とは何なのか?適当にコミュ力チェックシートにしてみた

f:id:redhornet96:20180808185611j:plain

コミュ力。

とは、一体何なんだろうか。最近くそマジメにそんなことを考えている。ぼくはコミュ力の権化と呼ばれる程には、コミュ力に自信はあるのだけど(もちろん苦手なシーンもある)、いつ権化になったのかとんと検討もつかん。

巷に出回っている有象無象の求人広告にも「コミュニケーション能力」という言葉は度々目にする。にも関わらず、コミュニケーション能力というものが一旦どんなものなのか?どうやって身につけることが出来るのか?未だ明らかになっていない現代の七不思議の一つなのではないかと思うのです、ぼくは。

コミュ力の細分化

まず手始めにコミュ力を細分化してみるのはどうだ?コミュ力の定義を以下の2つに分けて、さらに細分化してみる。

  1. 素早く適切に他者と意思疎通し合意する能力である
  2. 会話や振る舞いによって他者に好感を与える能力である

8個くらいYESがあればコミュ力強者なんじゃないすかね?←適当か

素早く適切に他者と意思疎通し合意する能力

  • 少ない説明と会話で、タスクの目的とゴールを把握することが出来る
    • 不完全な情報がどの部分にあるのかを察知し、明らかにする能力も含まれる
  • その場での情報をかき集めて、コンテキストを素早く理解し、 妥当な意見を言うことができる
    • 全ての情報が頭にあるという状況は普通はありえない。限られた情報でコンテキストを類推し、的を射た意見を言えるとカッコいい
  • 質問と回答が噛み合っていること
    • 意図せず論点をずらしてしまう人は実はけっこういる
  • 言いにくい話を、感情的なやりとりにならないように伝えることが出来る
  • コンテキストが異なる相手と建設的な議論が出来る
    • 職業が違う、性格が違うなど、自身の常識感が通用しない相手と意思疎通が出来ること
  • 話の中で重要なこととそうでないことの区別がつけることが出来る
  • 相手の言葉選びや態度から感情を推測することが出来る
    • これは両者に属する能力

会話や振る舞いによって他者に好感を与える能力である

  • フリに対してノリが一致している
    • 例えば、誰かがボケたときはツッコミを入れるのが正しく、マジレスするのは正しくない
  • 話やノリで場を盛り上げることができる
    • 合コンとかある程度複数人がいるシーンで、場を盛り上げる能力
  • 初めて話す人でも気さくに話すことが出来る、人見知りしない
  • 相手の言葉選びや態度から感情を推測することが出来る

コミュ力の伸ばし方は正直知らん

f:id:redhornet96:20180808185630j:plain

ブログを書くからには役に立つことを書かなければならないというプレッシャーがあって最近書けていなかったのだけど、もはや役に立たなくても良いだろう。書きたいのだぼくは。全世界に向けて思っていることを発言したいのだ。

コミュ力をどうやって伸ばしたらいいかだって?

そんなん知らん。お前の頭で考えるんだ。考えるのを辞めたらお前はただの芦だぜ?

今やある程度のコミュ力に自信はあるオレだが、当然生まれつきコミュ力を持ってして生まれたわけではない。世の中には、生まれた瞬間に歩きだして「天上天下唯我独尊」とか言い出した天才児もいるくらいだから、生まれつきコミュ力があってもおかしくはないが、ともかくぼくは普通の赤ちゃんとして生まれたはずだ。

長い話になるから簡潔に書いて完結させないけど、ぼくがコミュニケーションに課題を感じ始めたのは小学校4年生くらいのときだったと思う。

あの時を振り返ると、クラスの中で強いやつ、普通のやつ、しょぼいやつってスクールカーストを暗黙的に感じるようになった。出来るだけ強いやつの近く、でなくても普通のやつの中には、って空気が当時あった気がする。

コミュ力が明確な課題になったのは今でもはっきりとおぼえている、16歳のときアルバイトの面接に落ちたことだ。友達の紹介で面接を受けたから、落ちた理由を聞くことが出来たんだけど、その理由は「話しているときに目を見て話さない」ってところだった。そんなこと一度も指摘されたことなかったからけっこうショックだった。

そこからどのようにぼく原田がコミュ力を身に付けていったのかは後に明かにされるのである…

(長くなったのでまた別で書くかも知れない)

ブログが書けない

f:id:redhornet96:20180731163518j:plain

最近どうもブログが書けない。元来ぼくの得意技の一つだったからちょいちょい時間とって書いてみるチャレンジはしてるんだけど、ばーっと下書き書いてみて、んーなんか違う。ってお蔵入りパターンが多い。ムダにEvernoteを肥やしている感じだ。

なぜブログが書けないか仮説を出してみよう。

  • ブログを書くリターンを狙い過ぎて打算的な内容に寄りがち。テンションが下がるわ
  • 一企業の代表者として文章を書くからには恥ずかしくない内容でなければならないという謎のプレッシャー
  • 誰かの役に立つ記事を書かねば!という使命感

こんなところだろうか。

正直どれもあるなーと思う。大体ブログ書き始めるときは、こんな手順だ。

  1. Evernoteにメモってあるブログテーマリストから書けそうなのをピックアップ
  2. 先に見出しを書く
  3. 本文を適当にざーっと書く
  4. この辺でテンションが下がるのを感じる
  5. 全文をブラッシュアップ・肉付け・整理する
  6. 更にテンションが下がるのを感じる
  7. 少し文章にヘンテコな面白みを付け加える
  8. ヘンテコ文章がうまくいくとテンション上がる。逆にうまくいかないとまたテンション下がる
  9. アイキャッチ画像とか入れる
  10. SNSでシェアする

テンションが下がるポイントがちょいちょいある。ブログを書き始めた頃は、今よりも書きたいことを書きたいときに書いてた気がする。今よりもいい加減にやってた気がする。

本来人間は自分の思いとか頭の中にあるものっていうのは誰かに聞いて欲しいもんだ。その欲求にもう少し素直になることが、ブログ復活のためのポイントかも知れん。

とりあえずこの記事はロクに推敲もせずにネットの広大な海へぶん投げることにする。

エレベーターピッチの作り方 - シンプルな言葉でプロダクトを表現する方法

f:id:redhornet96:20180221142427j:plain

どんな開発プロジェクトでも何かものを作る限りは、そのプロダクトで何を目指しているか、明文化されているいないに関わらずあるはずです。

それを明文化するためのドキュメントとしてインセプションデッキというものがあります。これはアジャイル開発における要件定義書のような位置付けで、10個ページのスライドを埋めていくシンプルなもの。

mofmof inc.は開発会社という立場でプロジェクトに参画することが多いわけなのですが、一般的な受託開発会社とは違って、決められた通りにものを作ればOKという考え方ではなく、そのプロダクトのゴールを実現することを目指した作り方をしています。

ゴールの実現を目指すには、ゴールがどこにあるのか強く関心を持たなければなりません。そのためにインセプションデッキ・エレベーターピッチは大変役に立っています。

この記事では、その中の1つであるエレベーターピッチの作り方ついて解説しますね。

エレベーターピッチとは何か?

f:id:redhornet96:20180221142650p:plain

エレベーターピッチというのは、忙しい投資家に対して、エレベータに乗っている30秒間という短時間で起業家がプレゼンするというシーンを指しています。

30秒間という短時間にエッセンスを詰め込むからこそ、プロダクトの本質を表現した文章になるので、プロダクトのイメージを強く形付けることが出来ます。

インセプションデッキではそれを応用して、ドキュメントにまとめちゃおうという発想ですね。

エレベーターピッチは、テンプレに穴埋めしていく形でやっていくのですが、以下の7個の穴埋めがあります。

  • ニーズ
  • 顧客
  • プロダクト名
  • カテゴリ
  • 価値
  • 競合
  • 競合との差別化

エレベーターピッチの作り方

ぼくが趣味で作っているアイデアストックというアプリの例にして、実際に書いていきますね。

アイデアストック

アイデアストック

  • Atsushi Harada
  • Productivity
  • Free

ニーズ

潜在的なニーズを満たしたり、潜在的な課題を解決したりの部分。

どんなニーズがあるかの仮説を入れていきます。

企画職の人や、個人アプリ開発者、起業家などをイメージすると、一人でアイデアを出して一人で立ち上げていく姿が見えたので、アイデア出しが煮詰まってしまったときに、アイデアを増やしたい、というニーズがあるのではないかと考えました。というか自分にそのニーズがありました。

もっとアイデアを増やしたいと入れます。

ちなみにエレベーターピッチ全体に言えることですが、基本的には全て仮説で入れていっても問題ないです。事実かどうかは検証してみないと分からないので、アレコレ悩んで時間を費やすより、現時点の仮説を入れてしまって、反証されたらそのタイミングで修正すれば良いです。

顧客

対象顧客の部分。

誰をターゲットとするかを記入します。「全ての人々」みたいな抽象的な範囲ではなく、なるべく具体的な粒度で書きましょう。

ここで書かなかったからといって未来永劫ターゲットからはずすというわけではないので、一番最初に売り込みたい顧客をイメージして絞ると良いです。

アイデアを出す職種の人として新製品企画者としました。最初は起業家としていたのですが、起業家だけをターゲットにするとアプリの方向性が偏りそうな気がしたので、少しターゲットを広めにした。

プロダクト名

プロダクト名の部分。

言わずもがな。好きなプロダクト名を入れればいいじゃない!

カテゴリ

プロダクトのカテゴリーの部分。

簡単そうに見えてちょっとだけ奥が深いカテゴリ。なぜかというと、そのプロダクトをどのジャンルに位置付けるかによって戦うベき相手が変わるからです。

アイデアストックの例で言えば、「ノートアプリ」にすると競合はEvernote辺りになるけど、「アイデア発想アプリ」にすると競合はマインドマップアプリ辺りになる。

つまり、どこを戦場に選ぶか?ということですね。

アイデアストックでは、アイデア探しツールとしました。

価値

重要な利点、対価に見合う説得力のある理由の部分。

ユーザーがなぜそのプロダクトを使うのか?を記入する部分。プロダクトのコアな部分です。

アイデアストックは、ノートアプリではなく、煮詰まっちゃったときにアイデアを増やすためのアプリなので、既存アイデアから他のアイデアを派生させて増やすこととしました。

競合

代替手段の部分。

ここには競合アプリ名(サービス名)を入れると非常にわかりやすい。競合サービスが存在しない場合は、ユーザーが現在課題をどうやって解決しているかを記入すると良い。

マインドマップやアイデアメモアプリとしました。どちらも一人でアイデアを発散したり増やしたり出来るものです。

競合との差別化

差別化の決定的な特徴の部分。

「価値」の部分と重複しやすいので注意が必要。価値は競合サービスと同じでもOKだけど、この部分は競合にはないものを書くと良い。

アイデアストックでは自分のアイデアから連想される新しいアイデアが自動的に増える機能とした。

エレベーターピッチ完成

f:id:redhornet96:20180221142845p:plain

これで完成!簡単ですね!

良くない例

エレベーターピッチを作るときに注意する必要があるのは2点。

1点は、なんでも盛り込んでしまい全部盛りになってしまうケース。

f:id:redhornet96:20180221142923p:plain

例えば価値の部分に、「アイデアを高速にストック・タグ付けが出来て整理がしやすく、更に検索機能があって大量にアイデアを貯めておくことが出来る」みたいな機能列挙をしちゃダメ。

ウリをたくさん書きたい気持ちは分かるけど、たくさん書けば書くほどユーザーに響かないし、プロジェクトのチームメンバーにも伝わりづらくなってしまう。

2点目は、それぞれの項目が重複しまくるケース。

f:id:redhornet96:20180221142939p:plain

特にニーズ価値の部分と競合との差別化の部分が重複しやすいけど、重複はプロダクトを説明する言葉としては全く役に立たない情報なので、可能な限り過不足重複なく書くことに気をつけると、より人に伝わりやすい強い文章になります。

何かを生み出すときはエレベーターピッチを書こう

開発プロジェクトに限らず、新商品企画や、事業立ち上げなど、何か新しいものを生み出そうとしているシーンで、エレベーターピッチは非常に高速かつ的確にイメージを形付けられるので、やってみるのをオススメします。

例え個人開発アプリだったとしても、自分が定めたプロダクトの軸をいつでも思い出せるように書いておくのが良いです。マーケティングするフェーズや、ピボットが必要なときに、冷静に分析するのに役に立ちます。

関連記事

everyday.mof-mof.co.jp

www.mof-mof.co.jp

会議やイベントに!初対面でも打ち解けるアイスブレイクネタ3選、自己紹介編

f:id:redhornet96:20180220180551j:plain

新しいプロジェクトのキックオフや、勉強会などのイベント。初めましての人が集まると決まってやるのが自己紹介。

ぼくは比較的良くイベントを主催するので、参加者の方の緊張を適度にほぐして参加者同士も交流しやすくなるように自己紹介のやり方に工夫しています。

この記事ではぼくが実際にやってみたことのある自己紹介のやり方を紹介しますね。

自己紹介でアイスブレイクしよう

アイスブレイクとはなんぞやか?

平昌オリンピックで盛り上がっているアイスダンスでもアイススケートでもなくアイスブレイクです。アイスブレイク。

何かのファシリテーターをやったことある人にとってはおなじみの「アイスブレイク」。初対面の人が集まった時に、緊張をときほぐしコミュニケーションを取りやすくするための小技のことで、自己紹介に限らずいろんな手法があったりします。

そんなに難しいものではないので、イベント主催とかする方はぜひチャレンジしてみると、イベントの満足度が上がって良いですよ。

今回は自己紹介でアイスブレイクする3つのやり方を紹介します。

  • カタルタ自己紹介
  • 名前リレー自己紹介
  • 読むだけ自己紹介

カタルタ自己紹介

f:id:redhornet96:20180221102713j:plain

最近全オレの中でブーム到来しているカタルタ自己紹介。

カタルタとは、鹿児島在住のメドラボ 代表 福元和人さんという方が考案したらしい、カード54枚の発想支援ツールです。作った人のことはよく知らんけど、54枚のカードそれぞれに文を接続する言葉が書いてあります。

ぼくが愛用しているのはロジカル版で、例えば「おそらく」「むしろ」「さもなければ」「対照的に」などの言葉が書かれてます。

自己紹介での使い方は簡単で、一人が普通の自己紹介をし終わった後に1枚めくって、話を一つ付け加えるだけ。

例)

普通の自己紹介 => 渋谷のIT企業を経営しているエンジニア兼代表取締役の原田です。趣味は海外ドラマを観ることです。

カタルタ => 「むしろ」

むしろ、Netflixが趣味と言った方が正確です。休日は海外ドラマに限らず、Netflixで映画やアニメなどを観尽くしています。Netflixサイコー

みたいな感じ。

それだけなんですが、「歴史的には」とか「本質的に」とか絶妙なやつを引いた時に、「ええええっっ!?」となってちょっと雰囲気が和みます。どうにかこじつけて話をまとめるのも頭を一捻りするけど、意外とこじつけは難しくないので誰でも出来て、アイスブレイクに最適。

カタルタは公式のショップで購入出来るみたい。

ちなみにNetflixは公式サイトから契約できます。俺的満足度は超高いので契約待ったなし。

名前リレー自己紹介

f:id:redhornet96:20180221102846j:plain

順番に普通に自己紹介をしていくのですが、自分より前に自己紹介した人の名前を言ってから自己紹介スタートするというシンプルなルールです。

1人目「田中さんです。ほげほげ〜」

2人目「田中さんの隣の山田です。もげもげ〜」

3人目「田中さんの隣の山田さんの隣の鈴木です。ぽげぽげ〜」

という風に進めていきます。

ぼくが実際にやったときは確か6人くらいだったのでそれほど難しくはなかったけど、後半の人になるに連れて「どうなるどうなる?」みたいな緊迫感混じりのワクワク感みたいのが刺激されていい感じに盛り上がります。

席の配置がものをいうアイスブレイク。 6人くらいなら余裕だけど、人数多いときは、そういうのが苦手そうな人がいたら一番最初に指名したり、利害関係が強くちょっとセンシティブな関係の参加者がいたら、なるべく前半に来るように指名したりしても良い。

名前を覚えるのが苦手と自覚がある人は、自分が最後に来るようにしてやると、確実に名前覚えられるのでオススメ。ただし名前以外の内容はあまり入ってこない。

読むだけ自己紹介

f:id:redhornet96:20180221103009j:plain

アイスブレイクではないのですが、人数が多い時にオススメの「読むだけ自己紹介」自己紹介のテンプレートを準備しておいて、それに従って自己紹介してもらいます。

テンプレがあると自己紹介する側も楽だし、主催側として知りたいことを意図的に入れておくことが出来し、ある程度自己紹介の長さを制御出来るので、色々と合理的。例えば20人の自己紹介を20分で終わらせたいときなどに使えるテクニック。

ぼくが主催しているアジャイルひよこクラブでよく行われているやり方で、ぼくも幹事メンバーに教えてもらった。

色んなアイスブレイクの引き出しを持とう

ぼくはファシリテーターを目指してきたわけではないけど、何かを仕掛けようとイベントをやってみたりするとき、自己紹介アイスブレイクは、参加者にとってイベントを楽しいものにする一要素になっていたと思う。

例えば、新規事業のブレストをするとき、いろんな立場の人や外部の人を交えてアイデアソンをするとき。初対面の人を交えてワイワイやることはビジネスのシーンでも多くあったりします。そんなときにアイスブレイクの引き出しはきっと役に立つので、一度挑戦してみるといいよ!

イライラする会議を建設的なものに変えるために避けたい3つの言葉

f:id:redhornet96:20180130153500j:plain

ところでみなさん、会議は嫌いですか?

嫌い?時間のムダ?

ただの報告ならメールで流せばいいじゃん?

その気持ち分かる。なんでしょうね、自分と対して関係ないと感じる話が延々と繰り広げられている様を見ているとまあ大変ダルいっすよねー。分かる。

ぼくはエンジニアなので、以前は会議の時間はほとんどムダでもっと手を動かすべき、って考えが強かったのですが、エンジニアリング的な仕事から社長業的な仕事に移っていく過程で、会議についての認識も変化していったりした。

そんな中で、会議のときに自分を含めチームのやる気が一気にそがれる言葉がいくつかあることに気がついたものを書いていく。

なぜ議論が必要なのか

そもそもなんで会議が必要なのか。当然自分一人で仕事しているのであれば情報はほとんど自分の中に蓄積し意思決定も一人で行うから会議をする必要はない。

だけどほとんど仕事はチームでこなすことが多いわけで、情報を共有したり、プロジェクトに関する何かの意思決定をしたり、チームでの合意形成したりするために必要だったりする。

結論を出すための会議だったら、最終的にどんな目的でどんなアクションをするのかを意思決定するのがゴールなので、全員がより建設的にゴールへ向かうための発言すべきなのは言うまでもない。

なので、ゴールに向かうことを邪魔する以下のような言葉は避けたほうが良い。

  • 分かりません
  • 〜すればいいだけでしょ?
  • それやる意味なくない?

f:id:redhornet96:20180130153522j:plain

「分かりません」

分からないものはしょうがないのだけど、誰かが答えを知っているようなことはそもそも議論に上がってくることもないわけで、チームとしての課題に対して、前進させるための話をしているのに、ただ「分かりません」だと議論に参加している意味がなくなってしまう。

答えが分からない課題には、仮説で対応するしかないので、考えうる仮説からベターだと思うものを主張する必要がある。正しいかどうかは誰も知らないので、間違っていても良いから自分目線での主張をするようにしたい。

また「意図が分からない」という意味を含んでいる場合もあるけど、「オレに分かるようにちゃんと説明して」という態度をとると、相手を馬鹿にしているような態度に映るので気をつけたい。

会話というのは双方向のコミュニケーションであるわけだし、自分と相手のバックグラウンドが大きく異なることは多々あるので、相手をリスペクトしながら意図を正しく一つずつ引き出して、相互の理解を積み重ねながら議論を深めるのが良い仕事の仕方だと思う。

「〜すればいいだけでしょ?」

これはぼくもうっかり言っちゃうときがあるのだけど、相手の立場が見えてないからこそ出てきてしまう言葉。実際には本当に〜するだけで済んでしまうようなこともあるけど、往々にして議題に上がっている時点で、〜すればいいだけではない事態だったりする。あるいは〜することが出来ない事情があったりもする。

〜するだけでは解決できない理由を深掘りして、本質的な課題を導き出せるような質問をするように心がけよう。

エンジニアだったら経験あるんじゃないですかね?「この画面に、この項目ちゃちゃっと追加しといてよ、画面に表示するだけでしょ?」みたいに言われたら「いやそれはそうなんだけど…」と思いつつイラッとするでしょ?

「それやる意味なくない?」

何か課題に対してアクションを起こそうという場において、基本的にやる意味がないものなんてないわけで、効果の見込みが高いか低いかしかない。ようするにコスパの話なので、やる意味がないと主張するのなら、よりベターで実行可能な対案を出さないとフェアじゃない。

この言葉はちょっと強い言葉なので、一般的な常識感のある人ならそんなに頻繁に言うような言葉ではないと思う。従って、やるかやらないかという点よりもむしろ別のところに課題があることが多い気がする。主義主張が折り合わない人同士でやりとりをしているときに発言されることが多いかも。

建設的な会議をするために

上記のような言葉は極力使わないように気をつけること。そして、参加者全員が会議のゴールを認識して、ゴールに近づけるように貢献すること。

そういう会議になっていればけっこう楽しいです。そういう会議はぼくは好きです。

どういう意味で品質って言ってるの?システム開発の現場で品質おじさんと建設的に向かい合う方法

f:id:redhornet96:20171101113444j:plain

「わしはシステムの品質を妥協せんぞ!」って偉い人から議題があがるって経験したことありますか?

この「品質」って言葉が少々やっかいなヤツでして、それだけ言われても何のことを指しているか分からなくなくなくないですか?

じゃあこの偉い人にどういうことが詳しく聞けばいいじゃんって話なんですが、「品質ってなんスか?」とか聞いたら、「キサマ!『品質』って言葉も知らんのか?国語辞典で読んで小学生からやりなおせぃ!」ってブチ切れられて、焼き土下座とか強制地下労働とかさせられるのが関の山。そんなリスクを考えると、なかなか言い出しづらいですよね。

そんなあなたのために具体的にこの「品質」という言葉をどう扱うべきか考えて行きましょう。

品質という言葉は何を示しているのか?

ところで、アジャイル開発にはプロジェクトの目的やゴールを明確にするための「インセプションデッキ」というドキュメントが存在します。

その中の一つとして「トレードオフスライダー」というものがあり、スコープ・予算・時間・品質の4つから優先度をつけるというものです。

システム開発プロジェクトにおいて、それぞれ4項目はトレードオフの関係があって、何かを優先とした場合に、他の何かの優先度を犠牲にしなければならない、ということを示すことが出来る。

f:id:redhornet96:20171101113500p:plain

さてでは、「品質」とはどんな意味を持っているんだろうか。システムにおける「品質」とは例えばこのようなものがあるかと。

  • バグが少ないシステム
  • 画面デザインがキレイなシステム
  • 保守性が高いソースコードで実装されたシステム

どれも品質に当てはまる言葉だと思う反面、それぞれ向上させるためには力のかけ方が異なるため、別軸で考えるべきものであって、一緒くたに「品質」と呼ぶのは良くないんじゃないかと思う。

従って「品質」について議論したいときは、一体どの品質を指しているかを明らかにしてから議論する必要があると。

品質を無意味に追いかけてしまう病気

f:id:redhornet96:20171101113527j:plain

ぼくはこの「品質」という言葉をなるべく使用しないようにしていて、トレードオフスライダーからも削除していることが多いです。なぜかというと、上記のような問題を解決しないまま「品質」を重要視する方向にプロジェクトの舵を取ると、間違ったことに努力してしまいがちだからです。

例えば、「キサマら!もっと品質を高めるのじゃーーーー!」というオーダーがあった場合、 「そうか品質か、より完璧に近いものを作ればいいのだな?」と解釈して実行に移しちゃったりする。こういうのイクナイ。大変イクナイ。

偉い人は単に見た目がキレイなシステムをイメージしているだけかも知れないのに、デザインがモダンで超かっこいい、バグが一切なく、ソースコードも超絶美しいものを目指したらどうなるか。

延々と重要でもないことを頑張り続けてプロジェクトのリソースが圧迫していき、結果的にプロジェクトが破綻、あなたは責任をとらなければならず、偉い人の前で10秒間の手と足と額を地に付けた焼き土下座を披露することになり兼ねません。

本来システムとは、人の手間を減らして楽にするためのものであり、人を喜ばせることが目的のはず。最も重要視すべきは、その目的が満たせるかどうかであり、システムがとにもかくにも完璧であることを目指すのは妥当ではない。

品質という言葉を使うのをやめよう

まずはですね、システム開発のプロジェクトで「品質」という表現を使うのはやめよう。話はそれからだ。

品質について何か語りたい場合は、具体的な言い方をしよう。

  • バグの少ないシステムにしたい
  • 見た目の良いシステムにしたい
  • メンテナンス性が高く機能追加の工数が少ないシステムにしたい

もし偉い人が「品質じゃ!品質!!キエーーーー!!」と言って今にも襲い掛かってきそうなときは、「ちょ、ちょっと待ってください!!その品質という言葉は一体全体上のどの意味を指しているのでしょうか!」とぜひ問いかけてみてください。

もし「ばっかもーん!全部じゃ全部じゃ!!」と言われた場合「で、ではどれから取り組むか優先順位をつけましょう!」と言ってみると良いです。

なんでもかんでも容易に「品質」という言葉にひっくるめ、完璧にこなそうとしてしまうと、結果的に現実とのギャップを埋められずに苦しむことになります。

我々システム開発を生業とするものにとっては、限られた予算や人的資源の中で、人を助け、喜ばせることが出来るシステムを実現することが使命。

だから「品質」を求められたならどんな具体的にどんなポイントに力を入れるべきなのか、あるいは、今最重視すべきものが本当に「品質」であるのか。本質を問う必要があると、ぼくは思います。

おまけ

mofmof inc.では、新規事業におけるWEBサービス開発を得意分野としております。短いスパンで早くよりよいサービスをリリースすることを良しとしているのですが、かといって汚いソースコードでも良いとはしておりません。

mofmof inc.では各自がメンテナブルで良いコードを高速に書けるように成長する仕組みとして、コードレビュー文化を推進しております。

参考:コードレビューは技術力を伸ばし続けるための仕組み

www.mof-mof.co.jp

2年半リモートワークをやってみて分かった、5つの良いところと3つの課題

f:id:redhornet96:20171006181747j:plain

こんにちは、エンジニア兼社長のはらぱんです。最近の趣味はInstagramにコンビニスイーツをアップすることです。

Instagramマーケティングを学びためにやっているという大義名分あるため、合法的にスイーツを買うことが出来てホクホクしてます。

さて今回は、最近トレンドのリモートワークについて。リモートワーク素敵ですよねリモートワーク。場所に制約されないから、地方在住の優秀な人とか、海外にいる人とか、地球の裏側にいる人とか、火星にいる人とか、はたまた異世界からリモートワークとか、考えるだけで思わず胸が踊りますよね!

結論から先に言うと、リモートワークは良いところもたくさんあるけれど、課題もたくさんある。完全リモートではなく週1リモートワークくらいがちょうどいい感じと思ってます。

mofmof inc.では、法人の立ち上げ当初からリモートワークを実施していて、子持ちの主婦エンジニアや、地方在住のエンジニアなどなどと一緒に仕事をしてきました。経験値もぼちぼちあるので、結論に至った経緯を書きます。

ちなみに、ぼく自身フリーランスエンジニアとして一人で仕事をしていたとき、在宅リモートワークを半年ほどやっていたことがあり、その際の自身の感覚も交えてます。

どういう風にリモートワークをやっているか

まずmofmof inc.ではどういう風にリモートワークをやっているか(やってきたか)について。

起業当初のリモートワーク

特に制限などなく、リモートワークを希望する人は全員OKにしてました。この時点ではリモートワークの経験値がなかったので、エンジニアという仕事をする上では働く場所と成果はあまり関係ないだろうという仮説のもとやっていました。

実際のところ、2,3名程フルリモートワーカーがいましたが、特にパフォーマンスが低いと感じることもなく、まあ問題なくやっていたかと思います。この時リモートワークでやっていた方は上で書いた子持ち主婦エンジニアと、京都在住のエンジニアでした。

振り返って考えてみると、mofmof inc.では月額制開発チームレンタルという受託開発サービスを主たる事業としてまして、その際開発チームが1〜3名くらいの小規模な形になります。なので、それぞれのチーム内だけでコミュニケーションできていれば、業務上は特に差し支えることがなかったという点が前提としてあったと思います。

2015年後半くらいのリモートワーク

確かこのときはRuby on RailsのプログラミングスクールであるDive into Codeさんとオフィスをシェアしておりまして、そちらの人数が増えてきてしまったため、mofmof inc.側のメンバーはこれを機に全員でリモートワークやってみよう!ってなってました。

diveintocode.jp

やってみた結果、一部のチームはオフラインでのコミュニケーションをしながら仕事をしたいということになり、普通に出社してました。ぼくもミーティングが多いのでほぼ毎日出社してたと思います。

当時はまだ人数が少なかったので、8割型みんな出社している状況になり、あんまりリモートワークをしていた実感がなかったというのが正直なところです。

もちろんこの間も特にリモートワークであるがゆえのトラブルとかもなく、まあ問題なくいっていた感じです。工夫していた点としては、毎日朝会を取り入れることにしました。リモートワークは生活リズムが乱れやすいので、各自リズムを壊さないようにという目的と、コミュニケーションが疎になりがちなので、コミュニケーションの機会を作るという目的がありました。

朝会の様子

f:id:redhornet96:20171006181943p:plain

最近のリモートワーク

最近は、普通にオフィスワークメインに戻したのですが、火曜日だけはリモートワークの日として残しておいてます。

理由は、いつでもリモートワーク出来る状態を維持しておけば、悪天候やら天変地異やらがあった場合に出社しないでも仕事することが出来るようになるからです。

あるいは、急に子供が熱を出したとか、ちょっとRuby Kaigi行ってくる!とかでも柔軟にリモートワークに切り替えることが出来るようになるからです。

週1回程度のリモートワークなら普段の生活リズムが壊れにくく、緊張感を保ったままリモートワーク出来るいい塩梅だと感じています。

リモートワークの良かった点

実際にメンバーにインタビューした結果も含め良かった点。

  • 満員電車に乗る必要がない
    • ぼく自身は毎日座れる電車で来るので元々あんまりストレスなかったけど、そうでない人にとってはやはりこれは楽だと思う。
  • 移動時間が節約できるので睡眠時間増える
    • ぼくは会社・自宅間で往復で2時間くらいかかるので、めちゃくちゃ時間の節約が出来る。日頃から睡眠時間をいかに確保すべきか悩んでいるので非常に良い。控えめに言って最高に素晴らしいエクセレントである。
  • オレの考えた最強の開発環境で仕事出来る
    • 人によっては自宅の作業環境をトリプルモニタとかアーロンチェアとかセパレートキーボードとか、がっつりオレオレカスタマイズしている人もいるので、それを最大限に活かせるのは良い。
  • RubyKaigi行ける
    • 目からウロコだったけど遠方のカンファレンスに気軽にいけるのは非常に良い。リモートワーク出来るので行ったついでに週末観光もしてこれる。
  • 里帰り出産に立会える
    • メンバーが偶然そのタイミングがあったのですが、里帰り出産に立ち会うために1週間ほど地元で仕事しますとかも出来た。こういうときリモートワークに素晴らしさを感じる。

課題

  • 自宅だと集中しづらい
    • 自宅だとテレビもあるし、食べ物もあるしおやつもあるし、気を抜くとダレてしまいやすい。これは人間のサガでロマンシングサガだから、いかにやり方を工夫するかというところ。
  • 寂しい・孤独
    • 独身の一人暮らしとかだと寂しいっぽい。
  • 自宅に作業場所がない
    • 子持ち家庭だとたまにパパの作業用の部屋がなくリビングで仕事をしているということもあったりする。出来ればある程度静かな環境で仕事出来る方がよいけれど仕方ない。ぼくが給料をたくさん払えるように努力するしかない。がんばるぞ。

対策

課題に対して、こうやって工夫している!とかこうしたらいいんじゃない?と上がったものを羅列しておく。

  • 自宅だと集中しづらい
    • レンタルオフィス借りる
    • カフェで仕事する
    • もはやオフィス行く
    • 疑似出社・疑似退社(始業前後に15分ほど散歩に行く)
    • 家の中でも靴を履く
    • 245cloud使ってポモドーロ
    • 眠くなるので昼飯食べない
  • 寂しい・孤独
    • tPresent使おう
    • 245cloud使おう
    • 音声のみビデオチャット常時接続とかいいかもね(事故に注意)
    • 猫飼う
    • リモートペアプロを意識的にやる
    • 結婚する
  • 自宅に作業場所がない
    • 引越しを検討する
    • 嫁と交渉する

疑似出社・疑似退社する

f:id:redhornet96:20171006182020j:plain

朝から晩までずっと自宅にいると、なんだかいまいちスイッチが入らない、みたいな感覚は経験ある方多いんじゃないでしょうか?

人間の体内リズムは太陽の光を浴びることでリセットされるとかいう説があるように、外へ出て気分を変えることは一定の合理性があります。

オフィスに出社する場合、当然家の外に出ることが強制されますが、リモートワークの場合はそうではないので、意図的に外出するという行動を作るため、仕事前の散歩、仕事の散歩で、疑似出社・疑似退社するという工夫をしてました。

これは個人的にはめちゃくちゃ効果あった。リモートワーカーのあなたにオススメ。

もはやオフィスへ行く

自宅だと集中できないのなら、オフィスでリモートワークすればいいじゃない。

リモートワークとは一体なんだったのか。

家の中で靴を履く

これはめっちゃおもろいですよね。ぼくはやったことないんですが、確かに靴を履くというのはスイッチONになりそうな感じがする。

あと、自宅だと気軽にベッドにゴロンと出来ちゃうけど、靴を履いておけば、靴を脱がなければならないという面倒があるので、抑止効果が期待できそう。

現在のリモートワークの最適な落とし所

リモートワークは良いところもたくさんあるけれど、課題もたくさんある。昨今では「リモートワーク最高うえーい!」な空気もあるとかないとかだけど、手放しで良いことばかりとは言えないと思う。

リモートワークでは、ちゃんと成果を上げようと努めた場合、オフィスワークするよりも強い自律が求められる。実際のところ、その観点だけ取り上げて言えば、リモートワークよりオフィスワークの方が楽。ホントに。

反面、物理的に出社する必要がないというのは大きなアドバンテージで、時間的にも労力的にも非常にメリットが大きいのは事実。

これらのメリット・デメリットを鑑みて、現在の落とし所としては、出社が困難なときは出社しなくて良いというくらいが今のところベターかなと思ってます。そのためには日頃からリモートワークでも価値を出せるように、週1日をリモートワークとしてやっていくのは理にかなっていると思ってます。