毎日がもふもふ

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

イライラする会議を建設的なものに変えるために避けたい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

リモートワークだとサボる?導入してみて分かったメリット・デメリット

f:id:redhornet96:20200220153508j:plain

こんにちは、エンジニア兼社長のはらぱんこと原田敦です。

最近の趣味はInstagramにコンビニスイーツをアップすることです。Instagramマーケティングを学びためにやっているという大義名分あるため、合法的にスイーツを買うことが出来てホクホクしてます。

(2020/02/19 更新)

コロナウィルスが流行の兆しをみせていますね。感染対策のため弊社でも昨日から3週間の出社禁止(リモートワーク)の措置をとりました。そんなこともあり、今回はトレンドのリモートワークについて書きたいと思います。

note.com

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

リモートワーク導入はメリットもたくさんあるけれど、課題やデメリットもたくさんある。ある程度の期間やってみた結果、今はフルリモートはやめて週1リモートワーク、それ以外は出社という勤務形態をとっています。

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

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

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

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

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

リモートワークのスタイルの変化

2015年後半くらいの話、当時オフィスを他社とシェアしていたのですが、そちら会社の人数が増えてきてしまい物理的にオフィスの席が足りなくなったので、一度mofmof inc.側は全員フルリモートにしてみることにしました。

リモートワークであるがゆえのトラブルとかもなく、まあ問題なくいっていたのですが、日常的にモブプログラミングしているチームがあって、オフラインでコミュニケーションしたいというニーズがあったためそのチームは普通に出社していました。ぼくも外部のミーティングが多かったのでほぼ毎日出社していました。

結局、当時はまだ人数が少なかったので、8割くらいのメンバーが狭いオフィスに出社して仕事している状況になり、あんまりリモートワークをしていた実感がなかったというのが正直なところです。

リモートワークだとメンバー間のコミュニケーションが希薄化することが予め分かっていたので、このあたりのタイミングで、毎日朝会を取り入れることにしました。生活リズムが乱れやすいので、朝イチでコミュニケーションする機会を作ると生活リズムが安定しやすいです。

最近(2020/02/18)の朝会の様子。zoomのバーチャル背景で遊んでます。なんか透明人間がいますね。

f:id:redhornet96:20200220125304p:plain

リモートワークのメリットとデメリット

実際にメンバーにインタビューした結果も含め、リモートワーク導入したメリットとデメリットを紹介します。

  • リモートワークのメリット
    • 満員電車に乗る必要がない
    • 移動時間が節約できるので睡眠時間増える
    • オレ(自分)の考えた最強の開発環境で仕事出来る
    • 地方のカンファレンスに参加出来る(RubyKaigiとか)
    • 里帰り出産に立会える
  • リモートワークのデメリット
    • 自宅だと集中力の維持が難しい
    • 寂しい・孤独、独身の一人暮らしとかだと寂しいっぽい。
    • 自宅に作業場所がない(小さい子供とかいる家庭)

リモートワークの課題の対策

リモートワークの課題に対して、こうやって工夫している!とかこうしたらいいんじゃない?と上がったものや実施しているものをあげます。

  • 自宅だと集中力の維持が難しい
    • 疑似出社・疑似退社
    • コワーキングスペース・レンタルオフィス借りる
    • カフェで仕事する
    • 家の中でも靴を履く
    • もはやオフィス行く
    • ポモドーロ・テクニック
    • 眠くなるので昼飯食べない
  • 寂しい・孤独
    • 常時接続ツールを使う
    • 猫飼う
    • リモートペアプロを意識的にやる
    • 結婚する
    • オンラインでボードゲーム
  • 自宅に作業場所がない
    • 引越す
    • 嫁と交渉する

リモートワークだとサボる?

リモートワークに関する議論を見ていると、「リモートワークだとサボる」「サボるやつはどの道サボる」というやりとりが非常に多いです。しかし、リモートワークだとサボる人がよりサボりやすい環境におかれるため、相対的にサボりが助長される可能性は否めませんが、実のところ問題の本質はそこではないと思います。

ちゃんとサボらずに仕事して成果を出したいのに、リモートワークだと集中力の維持が難しくて思うようにアウトプット出来ない、という問題の方が深刻です。

リモートワークやったことない人は、満員電車に乗らなくていいとか、自宅から出なくていいので楽とか、一側面だけのユートピアのようなイメージを持っている人もいるのですが、集中力を維持する努力や工夫をしなくいい分、出社して仕事する方が圧倒的に楽にアウトプット出せます(個人差あると思うけど)。

疑似出社・疑似退社

f:id:redhornet96:20171006182020j:plain

そんな集中力維持の問題にとても有効な対策が「疑似出社・疑似退社」です。朝から晩までずっと自宅にいると、なんだかいまいちスイッチが入らない、みたいな感覚は経験ある方多いんじゃないでしょうか?

人間の体内リズムは太陽の光を浴びることでリセットされるとかいう説があるように、外へ出て気分を変えることは一定の合理性がありますし、人の目や外界の音など、程よいストレスとなって意識をクリアにさせてくれます。

オフィスに出社する場合、当然家の外に出ることが強制されますが、リモートワークの場合は1日中家にいるため、いつまでたってもスイッチがオンにならないということがおこりがちです。

そこで、就業前・就業後に散歩しにいく習慣を取り入れます。10分程度でも十分に効果があります。めちゃくちゃ重要なポイントが2つあって 1つ目は雨だろうと強風だろうと極寒だろうと灼熱だろうと隕石が落ちようと、例外なく散歩に行くことです。そして2つ目は必ず外出用の服に着替えること。この2つを徹底して守る必要があります。

散歩にいくことにテンションが上がらない人は、近所の自販機までジュースを買いに行くとか、コンビニまでお昼ごはんを調達しにいくとか、理由付けすると比較的習慣化させやすいです。

もはやオフィスへ行く

こうかはばつぐんだ。

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

家の中で靴を履く

ぼくはやったことないんですが、これは非常に良さそう。リモートワークをしていると人目がないので、いつでもベッドにゴロンと出来る状況におかれます。昨日夜遅くまで飲んでてちょっと眠いんだよね、みたいなとき、つい5分くらい横になるかーって気分になります。

結果どうなるかは簡単に予想できますよね?

そうです。寝ちゃいます。目が冷めたら3時間くらい経過してたりします。仕事するつもりだったのにショックで落ち込みます。やる気が低下してさらに生産性が下がります。

家の中で靴を履いていれば、履いたままでベッドに転がることが出来ません。結果、気軽にゴロンとすることができなくなるので一定の抑止効果が期待できます。

ポモドーロ・テクニックを活用する

f:id:redhornet96:20200220152641j:plain

ポモドーロ・テクニックとは、簡単に言うと25分間(1ポモドーロ)作業に集中して取り組んで、5分間休憩するというサイクルを繰り返す手法です。

  1. 25分を1ポモドーロとし、やるべきタスクを1ポモドーロ刻み(25分毎)に分ける。
  2. 25分間は、他の事は一切やらず、タスクに集中する
  3. 25分経てば、5分間の休憩を入れる
  4. 4ポモドーロ毎(2時間毎)に30分程の長い休憩をとる
  5. 後は上記を繰り返す

引用:ポモドーロテクニックとは サイエンスの人気・最新記事を集めました - はてな

ぼくは、もうかれこれ5年以上ポモドーロ・テクニックで仕事しているのですが、非常に良いです。ポモドーロ・テクニックがどう良いのかはまた別の機会に書きたいですが、リモートワークとの相性が良く、集中力維持に寄与します。

ポモドーロ・テクニックが出来るツールはたくさん存在しているのですが、おすすめはg4というサービスで、ポモドーロするたびに自分のキャラクターが成長していきます。自分が集中して仕事した結果、成長していくというユーザー体験が得られるので、単にタイマーで無機質にやるより楽しみながら仕事が出来ます。

www.g-g-g-g.games

ポモドーロタイマー画面

f:id:redhornet96:20200220152822p:plain

ステータス画面

f:id:redhornet96:20200220152832p:plain

常時接続ツールを使う

リモートワークの寂しい・孤独問題に有効な策として、常時接続ツールがあります。Google HangoutやZoomなどのビデオ会議ツールを使っている事例もあるのですが、リアルタイムだとデータ転送量が多いのでちょっとPCが重くなります。なので、この手のツールでは自動的に数秒おきでFaceカメラで写真を撮ってアップするものが多い印象です。

なかなか物理的に同じ空間で作業しているとまで体感することは出来ませんが、少なくとも同じタイミングで仕事をしている人の存在を実感出来るので、孤独感が少し薄れる気がします。

国産サービスだとRemottyが有名。

www.remotty.net

軽量のサービスでtPresentというものもあります。

tpresent.pythonanywhere.com

使ったことはないですが、sneekやPukkaTeamというサービスもあるようです。

sneek.io

https://pukkateam.com/

オンラインでボードゲーム

mofmof inc.ではよく昼休みにボードゲームをして遊んでいます。このように気軽に遊べるのは、オフラインで集まっているからこそ出来るもので、仕事の実務とは直接関係ないけれでも、メンバー間での交流が盛んになって間接的に業務をスムーズにすることに寄与していると思います。

しばらくリモートワークが続くことになったとき、何かオンラインで出来るボードゲームないかなと探してみたらおあつらえ向きのがありました。

boardgamearena.com

一体いくつのゲームがあるのか数えられていませんが、数十以上のボードゲームが無料で遊べます。中でもおすすめが「お邪魔者」というゲームで、1プレイあたり20,30分程度で終わるので昼休みにちょうどよいです。

f:id:redhornet96:20200220152308p:plain

週1リモートワークという形

リモートワーク導入のメリットはたくさんあるけれど、課題やデメリットもたくさんあります。昨今では「リモートワーク最高!!」な雰囲気もあるけど、手放しで良いことばかりとは言えないので惑わされないように。

リモートワークでちゃんと安定して成果を出し続けようと努めた場合、オフィスワークするよりも強い自律が求められます。実際のところ、その点だけ取り上げて言えば、リモートワークより出社して仕事した方が圧倒的に楽です。本当に。

その一方で、物理的に出社する必要がないというのは大きなアドバンテージで、時間的にも労力的にも非常にメリットが大きいのは事実。これらのメリット・デメリットを鑑みて、現在の落とし所としては、台風や大雪、子供の病気、家庭の事情など、出社が困難なときは各自判断でリモートワークOKという運用にしています。

日頃から定期的にリモートワークしておくことで、いつリモートワークになっても成果が上げられるように、週1日をリモートワークという形に落ち着いています。

一緒に働くエンジニアを募集しています

週1リモートワークを取り入れているmofmof inc.で一緒に働いてみたいと思った方はぜひお気軽に声かけてください。

www.mof-mof.co.jp

システム開発の目的は、成果物を実現することではなく価値を実現すること

f:id:redhornet96:20170908120216p:plain

開発「仕様通りに出来上がりました!検収お願いします。」

顧客「うーん。こうじゃないんだよなー。ここって直せませんか?」

開発「そういう仕様なので追加費用をいただかないと無理です。」

顧客「いや、でもそれじゃ困るんですよ。。。」

開発「いやいや、だってこうだって言ったじゃないですか」

システム開発の業界に従事している方ならあるあるーって話なんじゃないかと思います。

こんな経験がある方はぜひ今一度自分達が提供したものが本当に「価値」を実現していたかどうか、細い目で悠久の時に思いを馳せながら、ゆったりとリラックスした姿勢で続きを読み進めてください。

ところで価値とはなんでしょう?

ソフトウェアにおける価値とは非常に重要な概念であるにも関わらず、その抽象性の高さから、あまり議論の中心には上がることがなく、なんとなく暗黙的ままでプロジェクトが進行していることが多い。

今回は、普段システム開発に従事しているプログラマや、プロジェクトマネージャー、ひいてはプロダクトオーナーなど、システム開発に直接携わる人向けに「価値とは何か?」という話を書きます。

ソフトウェアにおける価値とは何か

改めてもう一度。価値とはなんだろう?

普通の人はそんなこと聞かれても「は?」とか「なんか意識高いキモいヤツが現れたぞ!逃げろ!」としか思いませんよね?

話を掘り下げるために対象物を用意しましょう。弊社の一事業である、AIチャットBotサービス「My-ope office」の価値がなんなのか考えてみよう。

www.my-ope.net

My-ope officeで想定している1つ目の価値は、従業員が業務に関して何か不明点が発生したときに、情報を探したり、誰かに質問することを躊躇したりという時間を減らし、組織として業務の効率をアップすること。

2つ目の価値は、総務部や情シス部など、質問を受ける側が、度々同じような質問を受け、その度に同じような回答を繰り返す、というオペレーションのムダを削減することです。これにより、担当者は自身の業務を進める時間をもっと確保出来るようになること。

どんな課題を解決出来たら、ユーザーが心から喜ぶのか?それを突き詰めて表現した言葉が「価値」を表します。

大きく分けると価値にはプロフィットセンターかコストセンターかで二種類に切り分けることが出来て、前者は利益を増やすもの。後者はコストを減らすものです。従ってMy-ope officeは後者にあたる。

利益かコストか、そのいずれかを大きく変動させるポイントが何か?それが価値に直結する。ちなみにコストには金銭的なコストだけでなく「心理的コスト」というものも含まれたりする。

煩わしいと思っていることをいかに減らすか?という点も価値につながるので、数値的なものだけでなく人の心理にも着目するとなお良い。

どうやって価値を理解するのか?

価値を理解するには自分がユーザーのつもりになって想像し、感じる必要があります。ぼく自身も作り手なので分かるのですが、作り手はこれが苦手なことが多いです。「機能を実装する」という手段にフォーカスし過ぎて目的を想像することが得意じゃない。

せっかくなので、それっぽいこと言っておくと、価値とは「点」なんですよ。「面」ではなく「点」。

「My-ope officeを導入すると業務が改善してコストが減るんですよ」という言葉は面でしか語っていないから、この言葉だけではユーザーがどういう風に心から喜ぶかが想像できない。

価値を「点」で表現するには、アジャイル開発におけるドキュメントの一つ「インセプションデッキ」の「エレベーターピッチ」というのがオススメ。詳しい説明は省きますが、どんな目的でどんなゴールを達成したいかを表現するものです。

ポイントとしては、顧客に作っておいてもらうだけでなく、開発サイドでも作ってみるのが非常に良いです。自分が立てた価値の仮説と顧客が考えている価値にどれだけズレがあるか分かるので大変面白い。

f:id:redhornet96:20170908120709p:plain

あとは普段から「価値」を理解しようという習慣を身につけるべし。価値を理解出来るようになるためにやると良いのはこんな感じ。

  1. まず一番最初に、自分は「価値」を理解しているという思い込みを一旦全て捨てる
  2. 作って欲しいものの相談を受けたら、一番最初にどの点が「価値」なのか仮説を思考する
  3. 思考した仮説を相手にぶつけてみる。「そうそうそう!それなんですよ!」というちょっと大げさな反応が出たら当たり(反応が小さくてもハズレとは限らない。個人差がある)
  4. 上記のことを開発相談されるごとに繰り返し、3の当たり精度を上げていく

これをやっていくと確実に価値を見極める仮説思考が鍛えられていくのでぜひチャレンジしてみてね。

計測したわけではないけど、こういう話が出来る人は実は少ないので、作り手サイドの人は受注率が上がるかも知れない。少なくともぼくは何か外注する時、こういうことをちゃんと考えられる人にお願いしたいと感じる。

成果物の実現ではなく、価値の実現を目指せ

everyday.mof-mof.co.jp

以前にイケてるエンジニアの振る舞いについて書きましたが、イケてる人はこの「価値」を確実におさえて、そこへ向かって仕事をしてる。そうでない人と決定的な程に差がある。

「言われた仕様の通りに作ったのに、顧客からこんなんじゃないって怒られた」みたいなトラブルは、この業界あるある話だけど、そもそも「価値」を実現しようとしないで「成果物」だけを実現しようとしてるからそうなるんじゃないかと思ってます。

作り手側の人で、あ、こういう経験あったな、と思った人は今一度自分は顧客が求める価値を理解して、価値を実現するためにものを作っていたかどうか自問してみてもらえたらいいな。

と若き日の自分に言いたい。

こんな話を書いていたらインセプションデッキを作り方を学ぶ勉強会を企画したくなってきた。もし「聞きたい!」という方もしいたら個別にメッセージがWEBサイトから問い合わせいただければ、開催時に招待するかもしれない。

www.mof-mof.co.jp

https://www.facebook.com/harada.at.sea4

ベンチャー企業の経営者は死ぬほど働いてはいけない

f:id:redhornet96:20170825175216j:plain

こんにちは、はらぱんことmofmof inc.代表の原田です。

今回はベンチャー企業の経営者やその役員など、普段忙しすぎてめまぐるしい日々を送っていてロクに寝ていない方向けに「ちゃんと寝るべし!」と主張したい。

1日3時間しか寝てないんすよーとか、お前はナポレオンなのか。偉人か何かなのか。すげえな。

「私は偉人です」という方は続きを読まなくていいです。偉人ならば仕方ない。ロシアあたりに遠征行ってろ!

かくいう、ぼくはエンジニア出身の凡人経営者なんですが、最近組織として10名を超えるあたりに来て、「組織を作る」とか「組織を動かす」とかいうことの重要性についに気づいてしまった。

やっぱりアレですね、エンジニアとしての仕事と経営者としての仕事はかなりギャップがあって、日々新しいことに気づいたり学んだりすることがいっぱいです。人生学ぶことは尽きませんな。

経営者は仕事は組織のパフォーマンスを最大にすること

ぼくは、経営者がやるべき最も重要な仕事は「会社全体のパフォーマンスを最大にすること」だと思ってます。偉そうに言い切っていますが、ぼくはこの考えに至るまで2年以上かかったりした。

ちょうど数ヶ月前、とある新規事業の開発業務とビジネス側の業務を一人でやっていたのですが、お客様と約束した機能を翌日までに実装しなければならないにも関わらず、ミーティングやら他業務に忙殺されて、いつになっても開発に取り掛かれそうにない状況に陥り、にっちもさっちも行かなくなって大変困ってしまったことがありました。

実は「俺最強だし本気出せば人の3倍くらい仕事出来ますしおすし」とか思ってたフシもあるのですが、そのときはじめて、いかに自分が気合を入れて猛烈に働いたところで、せいぜい人1.5人分くらいの成果しか出せず、目標に向かって成果を上げるにはチームで手分けしないと行き詰まることを身をもって知りました。

チームで成果をあげるためには、チームを導く人間が必要です。開発の仕事に集中してしまっていては、チームを見ている余裕がありません。ぼくがやるべきはチームとしての成果を最大にすべく、個々をチューニングし改善していくことだと気づきました。その方が自分で開発を続けることより長期的には成果を大きく出来るはず、そう考えました。

疲れていては人を思いやれない

f:id:redhornet96:20170825175417j:plain

チームとしての成果を最大にするために、経営者にとって最も必要なことは何か?と問われれば「経営者自身が常に元気でいること」だと思っています。

以前は「俺最強だし、1日18時間労働とか余裕ですしおすし」とか思って長時間労働が常態化し体力がカラカラに枯渇している日々を送っておりました。

そんなとき、自分に若手をつけてプログラミングを教えることになったのですが、言ったことちゃんとやってくれなかったり、いまいち気が利かないことだったり、些細なことにイライラし、ぶっきらぼうな態度をとりがちになってしまいました。

結果的に、見どころがあったその若手は、ぼくの態度に理不尽さを感じて1年たたずに退職するに至りました。このときの経験は、今の考えに至る大きなきっかけになっています。

組織を成長させて、成果を最大にするためには自分以外の人がパフォーマンスを上げてくれるように工夫しなければなりません。そうなったときに、仕事の成果はスキルや能力といったものより個々の「気持ち」と切っては切れない関係になります。

例えば以下のようなことが経営者の重要な仕事だと思っています。

  • メンバーが困っていることはないかを知り、それを取り除くこと
  • メンバーの良くない振る舞いにフィードバックを出し、良い方向へ改善していくこと
  • 会社としてどこへ向かっているかを表現し伝え続けること
  • 自らの意志で自発的な仕事が出来るように動機づけすること

ともすると、具体的なアクションは全て「コミュニケーション」になります。コミュニケーションにはテクニックのようなものもありますが、やはり基本は、おもいやりや誠意というような気持ちのベースの上に円滑に成り立つと思ってます。

人は疲れているとイライラしやすくなります。イライラをぶつけられた人間は理不尽を感じ、やる気を失ってしまいます。だから、常に誠意を込めて、相手を思いやったコミュニケーション出来るようにするために経営者自身が元気でなければならないと思うのですよ。

会社経営を短距離走と見るか、長距離走と見るか

よく「経営者は死ぬほど働け」と主張する方もいます。短期的にはそれでも良いかもしれませんが、実際それは精神論でしかなくて、「経営者はちゃんと休め。常に元気でいろ」って言ったほうが長期的には組織として良い成果が出せるはずだと思ってます。

ぼくは会社経営を長距離走だと思っています。自分の呼吸と体力の限界を超えたペースで走っていては、ゴールどころか途中リタイアもありえます。だったら少しずつだったとしても一定のペースをコントロールして前へ進み続けることの方が有益だなーと思っているわけです。

世の中の経営者はそんなにタフなんですかね。ぼくは1日でも徹夜したらダメです。翌日まるで使い物になりません。もうボロクズです。

でも世の中には実際猛烈に働いているのに関わらずいつも快活な人っているよね。ああいう人は死ぬほど働いていても大丈夫なのかな。不思議だ。

もしやナポレオンなのか?偉人なのか?

イケてるエンジニアor開発会社に外注したいときの3つの見極めポイント

f:id:redhornet96:20170710190325j:plain

mofmofのエンジニア兼代表取締役の原田ことはらぱんが書いてます。2017年8月、皆さんごきげんよう。アツはナツいですね。

例えばエンジニアのいない企業が、システム開発を誰かにお願いしたいなーと思ったとき、知り合いのエンジニアだったり開発会社に相談すると思うのですが、どういうポイントを見れば失敗する確率を最小限に出来るか考えてみた。

エンジニア採用の話ではないので誤解なきように。

そんなに頻繁ではないのですが、ぼく自身も専門外の仕事を誰かにお願いしたり、外注したりっていうこともあります。

とりあえず相談して話は聞いてみたりはするけど、どういう点を見ればいいかって意外と難しいし、正直発注した結果後悔してしまったことも少なくなかったです。

中でも複雑で曖昧なものを扱うシステム開発は、非常に難しい部類だと思っていて、ここでうまくやるか失敗するかでプロジェクト全体の運命を決めるといっても過言ではないです。

ぼくが過去会った人や一緒に仕事をしたことのある優秀な人達の振る舞いを思い出してみます。

良いエンジニア・開発会社を見極める3つのポイント

  • 具体的に何を作るかよりも先に、何を実現したくて作ろうとしているかを掘り下げてくれる
  • 仕様変更が発生することを想定した計画を立てることが出来る
  • 予算・期間・期待価値の3点を考慮し、最善の着地点を提案してくれる

これはエンジニアの仕事じゃねえぞって言う人もいそうですが、仮にエンジニアの仕事じゃなかったとしても、チームの中で誰かがこういうことを気にかけてないとコケる。

ちなみに焼きそばを焼くのはエンジニアの仕事なのかという件については、ぼくは焼きそば焼きたいタイプです。

何を実現したくて作ろうとしているかを掘り下げてくれる

f:id:redhornet96:20170710190654j:plain

良い作り手は、成果物を作って納品することではなく、作ったもので価値を実現することをゴールだと考えてます。なのでまず最初にその事業(プロダクト)のコアバリューが何なのかを理解しようとしてくれます。

例えば、転職希望者と企業をWEBでマッチングする新規事業を作ろう、という場面だったときに、もしかしたらTinderライクに右左にスワイプする気持ちいいマッチングUIで勝負したいのかも知れないし、実は在日フィリピン人特化のニッチなマッチングなのかも知れない。例は適当、他意はない。

それが分かれば、何を達成すればその成果物が価値を生むのか理解出来るので、あとはそれに実現するための計画を立てれば良い。極端な話、それさえ実現出来ればあとの機能とかは全てオプションなわけで、実はなくても構わなかったりもする。

一般的にシステム開発界隈では21世紀になってもなお「仕様変更だ!」「バグだ!」みたいな争いが未だに絶えないんですが、実はこの「ゴール」の認識がズレてるからそうなるんじゃないかと思ってる。ちゃんとゴールに到達していればこんな泥仕合にはならんと思うですよ。

なので、プロダクトや事業の概略を伝えた際などに「どのポイントが他サービスとは違うのか?」「どうやって利益を上げるのか?」みたいな作るものに関する直接的な仕様以外の話に興味を持ってくれる人は非常に頼りがいがあるし、実際うまくやってくれた。

仕様変更が発生することを想定した計画を立てることが出来る

ウォーターフォールとかアジャイルとかの手法に限らず、仕様変更は必ず発生するですよ。要件定義を完全無欠にして完璧なものを作り、仕様変更をゼロにする!とかいう幻想は捨てるべし。そんなん全然現実的じゃない。初登場時のクリリン一人で魔神ブウを倒すってくらい無理ゲー。クッキーにされて食べられちゃうよ。

なので、どういうやり方を取るにせよ仕様変更に対応出来るような計画を立てられることが重要。

スケジュール作成を含めてお願いしているケースであれば、設計・製造・検証やらのいくつかのフェーズで分かれていると思うので、検収フェーズ後に修正対応出来る期間が含まれているとちょっと安心出来る人。

ちなみにmofmofからどなたかに発注するときは、最初から仕様が変わることを想定して、月額制か時給制で契約していることが多いので普段はあんまり意識していることはないかも知れない。

予算・期間・期待価値の3点を考慮し、最善の着地点を提案してくれる

しばしばシステム開発と製造業は同じように取られることも多いけども、実際のところ「完成」という着地点が可変である点で違う。

一般的には、「不変」に出来ることを前提として、要件を固めるために、要件定義書とか設計書のExcel方眼紙が血でにじむくらい努力しているわけなんですが、上で書いたとおりそれはちょっと難しい。

予算・期間・期待価値を伝えたとき、予算と期間を固定した場合におおよそ実現出来そうな着地点と、期待価値を固定した場合の予算と期間を、回答してくれた人が過去にいて「こやつめデキる…!!」と感じましたし、実際相当手練なおじさんでした。

ちなみにポイントとしては、予算内で「実装できそうな機能」ではなく「実現出来そうな価値」ということを念頭おいて提案してくれたように思えます。言葉で表現すると難しいんだけど、実現したいことを実現するためのミニマムな投資がどれくらい必要なのかを伝えてくれる感じ。

他には一通りやりたいことを伝えた後に、後日機能を一覧化してそれぞれに重みをつけて「この中からどの部分を仕様から落とすことが出来ますか?」っていう風に話を進めてくれた例もあって割りと良いと思った。

価値を提供するのか、単なる成果物を提供するのかの違い

ぼくの過去の経験から良いなーと思ったケースを上げました。主観なので「ソースは俺」くらいの話かも知れないけど、つまりは「価値を提供しようとしている人か、単なる成果物を提供しようとしている人か」という違いだと思う。

前者の方が素敵なのは言うまでもない。

弊社mofmof inc.では月額制の受託開発「開発チームレンタル」をやっております。もし身近に良いエンジニアや良い開発会社なくて困っているーなんて方がいらっしゃいましたら、いつでも下記WEBサイトなどからお気軽にご相談いただければ嬉しいです。

www.mof-mof.co.jp

生産性が通常の3倍になる「タイムボックス」のススメ

f:id:redhornet96:20170726143741j:plain

生産性上げたいよね生産性。わかるわー。

最近ニュースで見ましたが、経済財政白書によると「労働時間短いほど生産性上がる」という画期的な事実が明らかになったようで、ついに時代がぼくの思考に追いついてきたな、とほっこりした気持ちになっています。

news.careerconnection.jp

ある人は生産性を上げて早く帰りたいのかも知れないし、またある人はもっと仕事の成果を上げたいのかも知れません。

それぞれ違った目的があるとは思いますが、生産性は高くて困ることはないので、まあ労使ともに一般的には生産性は上げるのは良いことだと考えていいかなと思います。

生産性とは?

そもそも生産性とは何だろう。なんとなく感覚的に使っている言葉ですが、どう捉えると良いか。

我らがWikipedia大先生にはこう書いてある。

生産性=アウトプット/インプット

つまり、少ないインプット(作業量)で多くのアウトプット(成果)を出せることを生産性が高いと言うことです。

ところでソフトウェア開発においては「成果の尺度」って難しいですよね。作った量を成果としてしまうのはLOC見積もりとかに例示されるように、本質的な価値とは比例しないし、かといって売上とか利益を成果をすると、ソフトウェア開発という営み単独では評価が出来ないという問題もあったり。

すみません、ただの余談でした。

まあこれを掘り下げてしまうと400字詰め原稿用紙が256枚くらい必要になりそうなので、あえて掘り下げないでおこう。

長時間労働は生産性を下げる

アウトプット割ることのインプットが生産性であるとした場合、長時間の労働はインプット過多だから、当然生産性が下がる。

簡単な算数の話ですね。最近のサルはgitも分かるらしいから、これくらいはサルでも分かるんじゃなかろうか。

従って、生産性下がるから長時間労働はやめて早く帰ろうぜー。おしまい。

と思いきや、そうも問屋が卸さない的な話でして、我らが日本国にはですね、苦難に耐えることを美徳とする厄介な文化があるとかで、結果とは無関係に「一生懸命頑張った」で評価されたりとかする傾向があるみたいです。

正直日本にしか住んでたことがないので、ホントのところ外国ではどうなのかは知らんけど。

ただ観測の範囲で言えることは、長時間労働することにより、確実に思考は鈍る。ぼくも経験があるけど、疲労は長期的に蓄積するものなので、解消するときにも長い時間がかかる。その間は明晰な仕事が出来なくなる。

鈍い頭でダラダラ仕事をすること(させること)は誰の得にもなっていないということです。

生産性を上げるにはタイムボックスを短くする

ぼくは生産性を最大限に引き上げるには「タイムボックス」を持つことが効果的だと思ってます。

タイムボックスというのはアジャイル開発の中の概念らしいのですが(今さっき初めて知った)、計画における固定された期間のことです。

例えばリリースのタイムボックスだとしたら、◯月◯日がリリース日です、と言った場合に今日からその日までの期間がタイムボックスになります。これは原則変更しちゃダメで固定するものとします。その固定されている箱の中で現実的にやれることを計画しようってことです。

このタイムボックスは小さいサイズで考えれば、作業の一つ一つにタイムボックスを設けることもできます。例えば、今度のプレゼンの資料を作るというタスクに対して、2時間というタイムボックスを設けるというやり方が出来ます。

この考え方をすることのメリットは、かの有名な悪魔の法則「パーキンソンの法則」の対策になります。パーキンソンの法則というのは「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」というアレです。これを読んでいる出来るビジネスパーソンの皆さんは既に知っているとは思いますけどね!

完璧・完全を目指せば目指す程、仕事の生産性は下がっていきます。必要最小限である仕事を高速にこなす方が結果的に良い仕事になるのです。だからタイムボックスを設けることは生産性に大きく寄与する。

f:id:redhornet96:20170726143529p:plain

ちなみにタイムボックスはある程度短い方が良いと思います。人間が直感的に理解できるのは直近のものごとだけで、期間が長いと人間はそのタイムボックスの大きさを直感的には把握できません。ほら夏休みの宿題とか、終了間際で気合でどうにかしてたでしょ?

仕事はそれを達成するためのミニマムのタイムボックスを設定すること。それが生産性を上げる秘訣だと思ってます。

ぼくは会社の定時というのをこのタイムボックスとして考えていて、残業をするという行為はタイムボックスの制限を変えてしまうということなので、例外的な場合以外はやらないほうが仕事の成果は高くなると思ってます。

結論とポモドーロについて

  • タスクに着手する前に費やして良い時間を決めて、必ずその範囲で終わらせること
  • なるべく定時になったら帰ろう(定時がない人は1日の仕事時間を予め決めておき、その時間を越えて仕事しない)

「何かを調査する」とか「プレゼン用のスライドを作る」とかそういうタスクって明確に終わりが存在しないから、やろうと思えば何時間でもかけることが出来てしまいますが、そういうタスクをやるときにタイムボックスをキープするには「ポモドーロテクニック」がお勧め。生産性3倍は赤い人もビックリですが、1.2倍くらいならイケそう。

詳細に書くとアレなので書きませんが、簡単に言うと25分仕事して5分休むっていうサイクルを繰り返す仕事法です。

245cloudというWEBサービスでみんなでポモドーロ出来るのでオススメです。

245cloud.com

f:id:redhornet96:20170801132226p:plain

さあこれであなたもプロダクティブな毎日を!