UNIX的なアレ

UNIX的なこととかいろいろ

「ノーアジェンダ・どうしましょうか会議」の傾向と対策

wadap.hatenablog.com

先日、こんなエントリーを書きました。割とエンジニアやデザイナーの方は経験したことがある会議ではないでしょうか。このワードに反応されていたので、少し掘り下げてみたいと思います。

「ノーアジェンダ・どうしましょうか会議」とは

もうこの名前に全てが詰まってはいるので、経験したことがある人はすぐにわかるとおもうのですが、以下の点が揃っているとまさにその会議かと思います。

  • アジェンダが用意されていない
  • とりあえず関係がありそうな人を呼ぶ
  • 会議が始まり次第「どうしましょうか」的な空気が流れる
  • ダラダラ長い
  • 丸投げ感満載

というところでしょうか。会議そのものに主催者側の専門性があるものでは起きづらいのですが、自身が理解できない or 経験の無い領域の話になるとわりとこういう会議になりがちなのかなと思います。

会議の傾向

そしてこの会議が始まり「どうしましょうか」的な気まずい空気が流れます。呼ばれた側も事前にあまり話を聞いておらず、割とどうしようもありません。

そして会議をまともに仕切る人がいないため、気になった点の議論だけが行われプロジェクト自体が前に進みません。わかり易い例としては、作るプロダクトの詳細も決まっていないのに言語選定とか自分が現時点で理解できる範囲の話になりがちです。

そしてよくわからないまま会議が定例化されダラダラとしたプロジェクト運営が進みます。

対策 - 出席者

この出席者側の対策としては以下の点に注意することです。

  • プロジェクトのマイルストーンを明確にする
  • 点の議論にならないように意識する
  • 主催者側 vs 出席者という構図を作らない

これは本来は主催者側の仕事といえばそのとおりではあるのですが、そのままじっと座っていても自分が参加しているプロジェクトが辛くなっていくだけです。そのため、いかにプロジェクトをストレスなくすすめることができるかという点に注力すべきです。

たしかにこういう会議が開かれると戸惑いを超えて腹立たしいこともあるのですが、呼ばれた以上関わる可能性があるのでその瞬間から主催者側に協力的になったほうがトータルのコストでみると得です。

対策 - 主催者側

プロジェクトにおける業務の詳細を把握できない人がやりがちな会議ではあるのですが、以下の点をクリアにすれば少しはスムーズに運営できるのではないでしょうか。

  1. 会議の前に強く関わりそうな人に個別に相談する
  2. 会議に出席するメンバーは最小限にする
  3. 会議そのもののゴールを明確にする

この3点を踏まえた上でアジェンダを作成し、事前に話すテーマがわかっているだけで会議の雰囲気は全く変わってきます。

会議のタイトル問題

そして、わりと軽視されがちなのが会議のタイトルです。会議自体は GoogleCalendar などで設定されることが多いと思いますが、そこに表記されるタイトルです。会議のタイトル適当な会議は本当にロクな会議がない。

アジェンダといえど全員が読むとは限りません。でも会議のタイトルくらいは嫌でも目に入ってきます。そのため、タイトルがら伝わる会議名が入っていると参加者は助かります。

ありがちなのが「ご相談」や「新規プロジェクトについて」のようなざっくりしたタイトル。このままだとその会議で何を行うのかが、イマイチ見えてきません。

主催者側はタイトルを気にすべきですし、参加する側もイマイチわからないタイトルがあったら事前に主催者側に確認をしておくのが良いです。

協力関係が大事

おそらくこんな会議を経験した人が多数いるんじゃないかなと思ってかいてみました。

本来は適当な会議を主催する側が気にすれば発生しない問題ではあるのですが、どうしてもこういった会議は行われてしまうもの。そのため、参加する側も協力することで少しでもこういった会議を減らしたいものです。

現場に業務改善を求めてはいけないのか

anond.hatelabo.jp

コメントも含めこれを読んで思ったことを書いてみようと思います。

業務改善を求めてはいけないのか?

まず、業務改善は上司だけの仕事ではありません。そもそも上司といってもチームによって期待されているロールが分かれているんで一概に言えないと思います。

そして業務改善は現場の協力無しでは出来ないので、何らかの協力を仰ぐことは必須です。ただ、問題はどこまでを上司が行ってどこからを現場で行うのかという点なのかなと思いました。例えば以下のような方法です。

  • 人が辞めてしまい、業務負荷があがっている
  • リソース不足ではあるが、あきらかに業務効率が悪い点があった
  • ○○の問題を解決したいので、それを実現するための方法は何かないだろうか?

というような話の流れであれば、返答のパターンは以下の3つくらいだと思われます。

  1. その方法を試したいので、○○という手法を導入したらどうか
  2. そこよりももっと他の部分に問題がある
  3. その問題提起は間違っている

1か2の回答であれば、建設的な意見ではあるため議論を前に進めることができます。3の場合でも対話を繰り返すことで、問題の根底を突き詰めることができる可能性があります。

現場の問題をどこまで上司は把握できるか

一方で現場の問題をどこまで把握する能力があるのかという課題はあります。完全に把握することはできなくてもなんとなくも勘所はあるはず。ただこれはその部署における何らかの専門性をもっている場合です。現場がもっている専門性をまったく理解できないまま、上司というポジションになった人には非常に難しい問題でもあるのかなぁと。

このあたりを把握できない人がマネージャーだったりプロダクトに強く関わる立場になると「ノーアジェンダ・どうしましょうか会議」が行われます。一旦関係者全員が無駄に呼ばれて、さぁどうしましょうかねみたいな会議。まぁこれは現場からみて腹立つのもわかります。

前提条件としての信頼関係

とはいえ、本当にこういった返しが返ってきているのだとしたらそれは信頼関係が完全に壊れてしまっているということだと思います。率直な意見といえばそれまでだが、これは意見というよりも対象を上司 or 会社にした一つの攻撃と捉えることができます。

攻撃的な関係になってしまうとあとはどうしようもないので、これ以上建設的な議論を行うのは難しいのかもなぁと思います。

人を採用すれば解決するか

採用って採用活動を開始してから、採用活動〜入社まで順調にいっても3ヶ月くらいかかります。なので最終的には採用するにしても、まず目の前の問題は内部で解決せざるを得ません。

とかいろいろ思いました。

リズムをつくる開発サイクルと会議のペース

gihyo.jp

先日発売されたこちらで取材された内容なのですが、せっかくなのでもう少し詳しく書いてみようと思います。スクラムの実践方法というよりも、円滑に回すために会議や意思決定のタイミングを工夫した内容です。

前提条件

以下が実施した条件です。

  • iOS/Androidのアプリ開発
  • アプリはリリース済みで、機能追加やアップデート対応
  • iOS2名、Android2名、サーバサイド2名、デザイナー2名

会議のリスト

イテレーションは2週間で切っていて、その中で以下の会議を実施しています。

開発者全員が参加するもの

  • 朝会
  • スプリント計画
  • 振り返り
  • プロダクトチェック会
  • 仕様レビュー会

プロダクトオーナーが参加するもの

会議の実施内容とタイミング

Daily - 朝会

これは毎朝実施されます。デイリースクラムも呼び、その日のやることや問題となっていることなどを共有する場として使っています。

Day1 - スプリント計画

これは開発期間の開始日に実施します。その時点で決まっているプロダクトバックログをベースに個々のタスクに落としてアサインしていきます。

最終的にはカンバン化して物理的にホワイトボード上で管理をするようにしています。

実施するものはプロダクトバックログの単位でGithub上にisuue化しておきます。milestoneはリリース日にして、以降のその機能に関する議論はisuue上で行います。

Day1 - プロジェクト運営MTG

プロダクト開発そのものよりも、チームとしての問題やその他環境問題などについて話す場です。マネージャー陣中心になる会議でかつ頻繁に問題がでるものでもないので、終わり次第すぐに切り上げます。

Day6 - プロダクトバックログMTG

開発するものの一覧の整理と、優先順位を見直す場です。こちらもマネージャー陣のみの参加です。新しい要件などの追加もこちらで話すようにしています。

ここにはデザイナーであるプロダクトオーナーが参加をしていて、次のイテレーションで実施されるだろうもののラフなデザインを作り始めます。

Day9 - プロダクトチェック

今のイテレーションで実装された内容が動作しているかチーム全員で動作確認をします。ここででた不具合や実装のモレなどを可視化してリリースまでに修正をします。

Day9 - 仕様レビュー

次のイテレーションで実施する内容をチームに共有します。この時点でプロダクトオーナーが作ったラフなデザインが共有されます。チーム全体に共有されるため、仕様的な問題点などはここでクリアするようになっています。

問題がなければ、ここで共有された内容が機能一覧としてisuue化されて、リリース時のチェックリストとして使います。

Day11 - リリース

今のイテレーションで実装されたプロダクトの最終チェックをプロダクトオーナーが実施し、チェックリストが全てチェックされた時点でリリースとなります。

なお、iOSは申請のことをリリースと呼んでいます。審査が通り次第、Androidとタイミングを揃えてAppStoreに出すようにしています。

振り返り - Day 11

この2週間のイテレーションを振り返ります。出来る限り次のイテレーションに振り返りを活かせるように、可能なものはタスク化し個々にアサインをするようにしています。

また、この直後に Day1 のスプリント計画を実施していて直前の振り返りを活かせるようにしています。

上記を実施する上でのポイント

いろいろ試行錯誤した上でこのペースになったのですが、考える上でのポイントは以下の点でした。

  • イテレーションの期間は2週間とし、できるかぎりその単位で出せるアウトプットを意識する
  • 会議の日は出来る限りまとめて、分散しないようにする
  • 祝日などがあって営業日が少ない時も同じペースで実施する(長期の休暇が入る場合は要調整)

最後に

この会議のペースや内容なども全て振り返りを中心にいろいろ実施していって生まれた実施ペースです。自分のチームとしてはかなりワークしているという実感はありますが、これはあくまで一つの実施方法です。

そのためにも振り返りをしっかりとやり、そこから改善につなげていくといったアクションが大事ですね。

WEB+DB PRESS Vol.98

WEB+DB PRESS Vol.98

管理画面と業務フロー

最近また管理画面に近いものをつくったりしていて感じたのですが、事業会社において管理画面がどのタイミングで実装されているかというのがすごく重要だなと感じたのでちょっと書いてみようと思います。

社内向けの管理画面の実装って割と後に回りがちで、最後に仕方なくなんとか実装するようなケースが多いと思うんですよね。そして、ある程度発生してきたオペレーションの実態に合わせて実装するみたいな流れになるのではないかなと。

それはそれで一つの実装の手法だと思うのですが個人的には逆のほうが良いのではないかなと思っています。

管理画面からオペレーションを設計する

まず、以下の理由から管理画面ありきでオペレーションを設計したほうが良いと思っています。

  • 既存のオペレーションありきで管理画面の要件を出すため、イノベーションがうまれづらい
  • 組織の最適化より管理画面の最適化のほうが合理的に行える
  • エンジニアの合理的な思考がオペレーション設計に向いている

まず管理画面を実装するということは社内のオペレーションを定義することになります。そのため、社内向けの管理画面をある程度作り込んでおくと、それに従って社内の業務フローができあがります。その上で実態と異なる部分を調整していくくらいが良いかなと思います。

管理画面こそクリエイティビティの発揮場所

サービスの仕様から、このあたりは社内の作業で編集したりするかな、いろいろと業務フローについて考えながら実装したりするのが管理画面だったりします。

特に新しい機能だったりするとそれに関わるオペレーションの人もいないため、当然ヒアリングすらできません。だからこそエンジニアが考えるべき部分ですし、そこの工夫がサービスの成長に寄与できるんじゃないかなとも思っています。

新しいサービスのKPIを正しく理解し、それに付随するだろう社内オペレーションを想像し、それを効率よく行えるための実装をするというのが理想的な流れですね。

管理画面を通じて表現される運営方針

また、管理画面を実装する上で作られる制約がそのサービスの運営方針にも直接的につながることもありただ機能として実装されていればいいというわけでもなかったりします。

たとえばすべての情報を閲覧・編集できるのではなく、ある種の制限などをつけておくことが、サービスの運営方針につながるということもあります。

社内向けの管理画面という意味からは少しズレますが、mediumの記事投稿画面なんかはわかりやすい例かなと思います。文字色の変更や文中における不要な文字サイズの変更などは許可しておらず、あくまで情報を伝達するメディアとして読みやすい表現に制限している。

こういった理由のある制限などはまさに管理画面でこそ実装されるべきもので、これによってサービスの運営方針や本来の使い方を感じることができます。

というわけで

管理画面をオマケとして考えるんじゃなくて、前のめりに自分からガシガシつくっていってほうが良いんじゃないかななんて思います。当然つくって終わりではないので実態に合わせて進化し続ける必要はあるわけで、その都度最適なものに作り直すくらいのスタンスが良いんじゃないかなぁなんて思っています。

以前に書いた記事です。新規サービスの立ち上げのときにはこちらも。

wadap.hatenablog.com

StartupBaseのメンターをやってきた

f:id:wadap:20170328095627j:plain

つい先日、StartupBaseというイベントのメンターをやってきました。ビジコン的なイベントではあるのですが、ポイントは高校生以下ということ。今回参加している中で最年少は中学1年生の子もいました。

startupbase-u18.com

どういうことをするのか?

f:id:wadap:20170328102904j:plain

1チーム4名くらいで、4チームつくり2日間かけて事業を考えてプレゼンをします。実際に調査という名目で、街中に出ていろいろなアンケートをとったりヒアリングをしたりして事業の実現性やニーズなどを固めていくといった流れになります。その中でちょっとアイデアが出てきたかなーというあたりでメンターとしていろいろとアドバイスをするという感じでした。

実際にやってみて

f:id:wadap:20170328101855j:plain

彼ら・彼女らにとって、事業を自分らで考えて説明をするなんて当然人生で初めてだと思うんです。別に一生そんなことしなくても生きていけるし、人生の必修科目ではない。

でもやっぱりこの年齢でこういう場に飛び込むだけでもすごいと思いますし、これからとんでもない速度で成長するんでしょうね。中にはエンジニアになりたい!といっている子もいて高校生くらいの年齢でエンジニア志望の子が出て来る時代になったんだなぁなんてすごく嬉しくなりました。

やっぱりそういった子たちは全力で応援したいですし、個人的には特にエンジニア志望の子なんかは応援したくなってしまいます。実際にこの場で出会ってサービスを作っている子達も居るようで、そういった仲間が見つかるなんてのも良いですね。

またこんなイベントがあれば参加してみたいなぁなんて思っています。

※ 写真は掲載許可をもらっています

2016年で学んだこと、僕の行動指針

これは、行動指針 Advent Calendar 9日目のエントリーです。 僕なりの行動指針を書くわけですが、割と今年は仕事・プライベートともにいろいろあったのでそこから得たことなどを含めて新たな行動指針にしていきたいと思いエントリーしました。

価値観を疑え

目の前だけの選択をするだけで人生って進んでいくものですが、その選択をする価値観を見直す機会ってなかなかないなぁとおもいます。なぜその選択をしたのか、ということを定期的に振り返る必要はあるなぁと思いました。

絶対な価値観って存在しないし、それでも自分自身は信じ切っているので価値観の原点となるものを定期的に思い出すだけでも意味はあるかもですね。

メンタルとフィジカルを高い水準で保つ

これは起業してからの7年間ずっと考えていることです。メンタルとフィジカルは密接に結びついているので、高い水準で保つように日々努力しています。 3日間全力で走れる体力よりも、3年間とまらずに進み続けられることのほうが大事。そのために、細かな自分の変化に気付くために運動や瞑想、また自分の身体のデータの継続的取得などを行っています。

ただ、フィジカル・メンタルどちらもある程度弱ったら寝るしか無いです。寝るのが難しいときもありますが、無理してでも寝る努力はしたほうがいいという気づきがありました。感覚的なものですが体力ゲージが30%以上あれば割と自動的に回復します。ただ、運動や瞑想、食事療法などで戻るのは30%くらいまでかなと。そこを切ると寝るしか無いです。一定の水準を超えてからいろんな施策を打つのがベストかなーと思います。

自分らしいことをしている時が健全

自分で好きなことをやっているときが最も精神的に健全でいられるのは当たり前。労働時間なんかはわかりやすくて、好きなことだとどこまでもできるけどしんどいことって10分でもやりたくないわけで。当然、全てがコントローラブルなわけではないけれども、理解していることが大事かなぁと思います。

思考能力以外の全てが無い時どう戦うか

今持っている持ち物や立場全てがなくなったら、何を武器にできるかをよく考えるようになりました。なんだかんだで大人になると今までの人脈だったりそういったもので切り抜けたりするのですが、アタマだけで戦うとしたらどういう人間であればよいのかというのを考えるといろいろとやることはあるなぁと思います。

フィードバックを正しく解釈する

本来の正しい解釈なんてまぁそう簡単には出来ないわけですが、本質的に相手が自分に対して何を伝えようとしているのかを理解するスタンスは大事だなぁと。どうしても大人になると反射的に受け入れられないことは増えてくるので、できるかぎり自分のプラスになるためのフィードバックとして解釈をしていきたいなぁなんて思っています。

以上です。次の方どうぞー!

www.adventar.org

「寿司・カレー仮説」から考える文化の共通化は好手か

こんなことを少し前に話してました。寿司とカレーの例えば会話のなかで出てきたもので、別にもとからあった仮説とかじゃないのでアレですが。

異なるものを作っているのに、傍からみたら同じように見えるので共通化したほうがいいよね。と感じるけど、本質的には結構違うものなのでなんでもかんでも共通にしないようがいいよ的なお話です。

異なる性質のものを同じ土壌で考えるべきか

事業を立ち上げる上で一定の正義は、やっぱりフェーズによって取るべき選択肢は変わるんじゃないかなぁというのが思っているところです。

wadap.hatenablog.com

まえにこんなことを書いたのですが、一見完全なる正義と思われる方向であってもその時点でその選択肢をとるのはさすがに悪手なんじゃないか、ということですね。それなりに成功している事業やシステムを持っている会社が異なる性質のビジネスやサービスを展開しようとする際、どうしてもその成功している部分の一部を使いたくなってしまうというのはあります。

これ自体は間違っていないですし、使えるものであれば使うべきではあるのですがそれにより本質的にやろうとしている事業が変わってきたり、必要以上に煩雑になったり、柔軟な設計ができなくなるというのは若干違うかなぁと。まぁ本当に正しく汎用的に元が設計されていれば話は違うのですが、なかなかそううまくはできていません。最初に設計されたインフラがベストだとしても、おそらくAWSのようには使うことはできないでしょうし。

文化の共通化は可能か

これも正直難しいと思っていて、売上をうんでいる事業とこれから立ち上げないといけない事業はそもそもの性質が異なってきます。異なるというか、評価軸や管理体制を別にしないとうまくいかない。最もよくないパターンが中間点というか落としどころを見つけるというやり方になりますが、これがどっちつかずでおそらく最悪。

で、どうせならどっちかに寄せましょうとなり、当然成功している事業のほうにカルチャーがよっていきます。コレ自体は間違ってなく、成功している事業に最適化されたカルチャーになっていくのでそっち側に大きな問題がうまれることはない。ただ、なかなか新しい事業だったり文化というものが生まれづらくなっていくんじゃないかなと思います。

当然、完全に別の組織にするという意味ではなく共通化する部分も一部あって良いと思います。会社としてのビジョンだったりバリューだったりってものは同じようにあったほうが良いと思いますし、なんらかの事業評価基準みたいなものがないと成果がでないときの撤退ラインも曖昧になってしまう。

似たようなカニバる子会社をたくさんもっている会社もあるけどある程度自由にさせるために子会社化しているのもあるんじゃないあかんと思います。これはイノベーション戦略の論理に書いてあった「事業をやる方向と回数」が大事だよね、的な話でもあるとは思いますが。

まぁそのあたりの線引は難しいのですが、なんでもかんでも共通にしても効率化どころか必要以上のコストをうんでしまったり、新しいものが生まれづらい環境になってしまう可能性もあるなと思いました。

シャリカレーという魔合体のことはおいておきます。

すしやのシャリカレー|くら寿司 ホームページ