現場に業務改善を求めてはいけないのか
コメントも含めこれを読んで思ったことを書いてみようと思います。
業務改善を求めてはいけないのか？
まず、業務改善は上司だけの仕事ではありません。そもそも上司といってもチームによって期待されているロールが分かれているんで一概に言えないと思います。
そして業務改善は現場の協力無しでは出来ないので、何らかの協力を仰ぐことは必須です。ただ、問題はどこまでを上司が行ってどこからを現場で行うのかという点なのかなと思いました。例えば以下のような方法です。
- 人が辞めてしまい、業務負荷があがっている
- リソース不足ではあるが、あきらかに業務効率が悪い点があった
- ○○の問題を解決したいので、それを実現するための方法は何かないだろうか？
というような話の流れであれば、返答のパターンは以下の3つくらいだと思われます。
- その方法を試したいので、○○という手法を導入したらどうか
- そこよりももっと他の部分に問題がある
- その問題提起は間違っている
1か2の回答であれば、建設的な意見ではあるため議論を前に進めることができます。3の場合でも対話を繰り返すことで、問題の根底を突き詰めることができる可能性があります。
現場の問題をどこまで上司は把握できるか
一方で現場の問題をどこまで把握する能力があるのかという課題はあります。完全に把握することはできなくてもなんとなくも勘所はあるはず。ただこれはその部署における何らかの専門性をもっている場合です。現場がもっている専門性をまったく理解できないまま、上司というポジションになった人には非常に難しい問題でもあるのかなぁと。
このあたりを把握できない人がマネージャーだったりプロダクトに強く関わる立場になると「ノーアジェンダ・どうしましょうか会議」が行われます。一旦関係者全員が無駄に呼ばれて、さぁどうしましょうかねみたいな会議。まぁこれは現場からみて腹立つのもわかります。
前提条件としての信頼関係
とはいえ、本当にこういった返しが返ってきているのだとしたらそれは信頼関係が完全に壊れてしまっているということだと思います。率直な意見といえばそれまでだが、これは意見というよりも対象を上司 or 会社にした一つの攻撃と捉えることができます。
攻撃的な関係になってしまうとあとはどうしようもないので、これ以上建設的な議論を行うのは難しいのかもなぁと思います。
人を採用すれば解決するか
採用って採用活動を開始してから、採用活動〜入社まで順調にいっても３ヶ月くらいかかります。なので最終的には採用するにしても、まず目の前の問題は内部で解決せざるを得ません。
とかいろいろ思いました。
リズムをつくる開発サイクルと会議のペース
先日発売されたこちらで取材された内容なのですが、せっかくなのでもう少し詳しく書いてみようと思います。スクラムの実践方法というよりも、円滑に回すために会議や意思決定のタイミングを工夫した内容です。
前提条件
以下が実施した条件です。
会議のリスト
イテレーションは２週間で切っていて、その中で以下の会議を実施しています。
開発者全員が参加するもの
- 朝会
- スプリント計画
- 振り返り
- プロダクトチェック会
- 仕様レビュー会
プロダクトオーナーが参加するもの
会議の実施内容とタイミング
Daily - 朝会
これは毎朝実施されます。デイリースクラムも呼び、その日のやることや問題となっていることなどを共有する場として使っています。
Day1 - スプリント計画
これは開発期間の開始日に実施します。その時点で決まっているプロダクトバックログをベースに個々のタスクに落としてアサインしていきます。
最終的にはカンバン化して物理的にホワイトボード上で管理をするようにしています。
実施するものはプロダクトバックログの単位でGithub上にisuue化しておきます。milestoneはリリース日にして、以降のその機能に関する議論はisuue上で行います。
Day1 - プロジェクト運営MTG
プロダクト開発そのものよりも、チームとしての問題やその他環境問題などについて話す場です。マネージャー陣中心になる会議でかつ頻繁に問題がでるものでもないので、終わり次第すぐに切り上げます。
Day6 - プロダクトバックログMTG
開発するものの一覧の整理と、優先順位を見直す場です。こちらもマネージャー陣のみの参加です。新しい要件などの追加もこちらで話すようにしています。
ここにはデザイナーであるプロダクトオーナーが参加をしていて、次のイテレーションで実施されるだろうもののラフなデザインを作り始めます。
Day9 - プロダクトチェック
今のイテレーションで実装された内容が動作しているかチーム全員で動作確認をします。ここででた不具合や実装のモレなどを可視化してリリースまでに修正をします。
Day9 - 仕様レビュー
次のイテレーションで実施する内容をチームに共有します。この時点でプロダクトオーナーが作ったラフなデザインが共有されます。チーム全体に共有されるため、仕様的な問題点などはここでクリアするようになっています。
問題がなければ、ここで共有された内容が機能一覧としてisuue化されて、リリース時のチェックリストとして使います。
Day11 - リリース
今のイテレーションで実装されたプロダクトの最終チェックをプロダクトオーナーが実施し、チェックリストが全てチェックされた時点でリリースとなります。
なお、iOSは申請のことをリリースと呼んでいます。審査が通り次第、Androidとタイミングを揃えてAppStoreに出すようにしています。
振り返り - Day 11
この２週間のイテレーションを振り返ります。出来る限り次のイテレーションに振り返りを活かせるように、可能なものはタスク化し個々にアサインをするようにしています。
また、この直後に Day1 のスプリント計画を実施していて直前の振り返りを活かせるようにしています。
上記を実施する上でのポイント
いろいろ試行錯誤した上でこのペースになったのですが、考える上でのポイントは以下の点でした。
- イテレーションの期間は２週間とし、できるかぎりその単位で出せるアウトプットを意識する
- 会議の日は出来る限りまとめて、分散しないようにする
- 祝日などがあって営業日が少ない時も同じペースで実施する（長期の休暇が入る場合は要調整）
最後に
この会議のペースや内容なども全て振り返りを中心にいろいろ実施していって生まれた実施ペースです。自分のチームとしてはかなりワークしているという実感はありますが、これはあくまで一つの実施方法です。
そのためにも振り返りをしっかりとやり、そこから改善につなげていくといったアクションが大事ですね。
管理画面と業務フロー
最近また管理画面に近いものをつくったりしていて感じたのですが、事業会社において管理画面がどのタイミングで実装されているかというのがすごく重要だなと感じたのでちょっと書いてみようと思います。
社内向けの管理画面の実装って割と後に回りがちで、最後に仕方なくなんとか実装するようなケースが多いと思うんですよね。そして、ある程度発生してきたオペレーションの実態に合わせて実装するみたいな流れになるのではないかなと。
それはそれで一つの実装の手法だと思うのですが個人的には逆のほうが良いのではないかなと思っています。
管理画面からオペレーションを設計する
まず、以下の理由から管理画面ありきでオペレーションを設計したほうが良いと思っています。
- 既存のオペレーションありきで管理画面の要件を出すため、イノベーションがうまれづらい
- 組織の最適化より管理画面の最適化のほうが合理的に行える
- エンジニアの合理的な思考がオペレーション設計に向いている
まず管理画面を実装するということは社内のオペレーションを定義することになります。そのため、社内向けの管理画面をある程度作り込んでおくと、それに従って社内の業務フローができあがります。その上で実態と異なる部分を調整していくくらいが良いかなと思います。
管理画面こそクリエイティビティの発揮場所
サービスの仕様から、このあたりは社内の作業で編集したりするかな、いろいろと業務フローについて考えながら実装したりするのが管理画面だったりします。
特に新しい機能だったりするとそれに関わるオペレーションの人もいないため、当然ヒアリングすらできません。だからこそエンジニアが考えるべき部分ですし、そこの工夫がサービスの成長に寄与できるんじゃないかなとも思っています。
新しいサービスのKPIを正しく理解し、それに付随するだろう社内オペレーションを想像し、それを効率よく行えるための実装をするというのが理想的な流れですね。
管理画面を通じて表現される運営方針
また、管理画面を実装する上で作られる制約がそのサービスの運営方針にも直接的につながることもありただ機能として実装されていればいいというわけでもなかったりします。
たとえばすべての情報を閲覧・編集できるのではなく、ある種の制限などをつけておくことが、サービスの運営方針につながるということもあります。
社内向けの管理画面という意味からは少しズレますが、mediumの記事投稿画面なんかはわかりやすい例かなと思います。文字色の変更や文中における不要な文字サイズの変更などは許可しておらず、あくまで情報を伝達するメディアとして読みやすい表現に制限している。
こういった理由のある制限などはまさに管理画面でこそ実装されるべきもので、これによってサービスの運営方針や本来の使い方を感じることができます。
というわけで
管理画面をオマケとして考えるんじゃなくて、前のめりに自分からガシガシつくっていってほうが良いんじゃないかななんて思います。当然つくって終わりではないので実態に合わせて進化し続ける必要はあるわけで、その都度最適なものに作り直すくらいのスタンスが良いんじゃないかなぁなんて思っています。
以前に書いた記事です。新規サービスの立ち上げのときにはこちらも。
StartupBaseのメンターをやってきた
つい先日、StartupBaseというイベントのメンターをやってきました。ビジコン的なイベントではあるのですが、ポイントは高校生以下ということ。今回参加している中で最年少は中学１年生の子もいました。
どういうことをするのか？
１チーム４名くらいで、４チームつくり２日間かけて事業を考えてプレゼンをします。実際に調査という名目で、街中に出ていろいろなアンケートをとったりヒアリングをしたりして事業の実現性やニーズなどを固めていくといった流れになります。その中でちょっとアイデアが出てきたかなーというあたりでメンターとしていろいろとアドバイスをするという感じでした。
実際にやってみて
彼ら・彼女らにとって、事業を自分らで考えて説明をするなんて当然人生で初めてだと思うんです。別に一生そんなことしなくても生きていけるし、人生の必修科目ではない。
でもやっぱりこの年齢でこういう場に飛び込むだけでもすごいと思いますし、これからとんでもない速度で成長するんでしょうね。中にはエンジニアになりたい！といっている子もいて高校生くらいの年齢でエンジニア志望の子が出て来る時代になったんだなぁなんてすごく嬉しくなりました。
やっぱりそういった子たちは全力で応援したいですし、個人的には特にエンジニア志望の子なんかは応援したくなってしまいます。実際にこの場で出会ってサービスを作っている子達も居るようで、そういった仲間が見つかるなんてのも良いですね。
またこんなイベントがあれば参加してみたいなぁなんて思っています。
※ 写真は掲載許可をもらっています
2016年で学んだこと、僕の行動指針
これは、行動指針 Advent Calendar ９日目のエントリーです。 僕なりの行動指針を書くわけですが、割と今年は仕事・プライベートともにいろいろあったのでそこから得たことなどを含めて新たな行動指針にしていきたいと思いエントリーしました。
価値観を疑え
目の前だけの選択をするだけで人生って進んでいくものですが、その選択をする価値観を見直す機会ってなかなかないなぁとおもいます。なぜその選択をしたのか、ということを定期的に振り返る必要はあるなぁと思いました。
絶対な価値観って存在しないし、それでも自分自身は信じ切っているので価値観の原点となるものを定期的に思い出すだけでも意味はあるかもですね。
メンタルとフィジカルを高い水準で保つ
これは起業してからの７年間ずっと考えていることです。メンタルとフィジカルは密接に結びついているので、高い水準で保つように日々努力しています。 3日間全力で走れる体力よりも、3年間とまらずに進み続けられることのほうが大事。そのために、細かな自分の変化に気付くために運動や瞑想、また自分の身体のデータの継続的取得などを行っています。
ただ、フィジカル・メンタルどちらもある程度弱ったら寝るしか無いです。寝るのが難しいときもありますが、無理してでも寝る努力はしたほうがいいという気づきがありました。感覚的なものですが体力ゲージが30%以上あれば割と自動的に回復します。ただ、運動や瞑想、食事療法などで戻るのは30%くらいまでかなと。そこを切ると寝るしか無いです。一定の水準を超えてからいろんな施策を打つのがベストかなーと思います。
自分らしいことをしている時が健全
自分で好きなことをやっているときが最も精神的に健全でいられるのは当たり前。労働時間なんかはわかりやすくて、好きなことだとどこまでもできるけどしんどいことって10分でもやりたくないわけで。当然、全てがコントローラブルなわけではないけれども、理解していることが大事かなぁと思います。
思考能力以外の全てが無い時どう戦うか
今持っている持ち物や立場全てがなくなったら、何を武器にできるかをよく考えるようになりました。なんだかんだで大人になると今までの人脈だったりそういったもので切り抜けたりするのですが、アタマだけで戦うとしたらどういう人間であればよいのかというのを考えるといろいろとやることはあるなぁと思います。
フィードバックを正しく解釈する
本来の正しい解釈なんてまぁそう簡単には出来ないわけですが、本質的に相手が自分に対して何を伝えようとしているのかを理解するスタンスは大事だなぁと。どうしても大人になると反射的に受け入れられないことは増えてくるので、できるかぎり自分のプラスになるためのフィードバックとして解釈をしていきたいなぁなんて思っています。
以上です。次の方どうぞー！
「寿司・カレー仮説」から考える文化の共通化は好手か
コスト的に考えて一緒にできそうだからまとめてしまう、という発想は、結構危険なことがあるな、と思っていて。
— けんすう (@kensuu) 2016年11月21日
たとえば、寿司屋のごはんと、カレー屋のごはんって同時に炊いて使うと、なんかよくなさそうじゃないですか。それぞれ適材適所のごはんありそうじゃないですか。そんな感じ。
こんなことを少し前に話してました。寿司とカレーの例えば会話のなかで出てきたもので、別にもとからあった仮説とかじゃないのでアレですが。
異なるものを作っているのに、傍からみたら同じように見えるので共通化したほうがいいよね。と感じるけど、本質的には結構違うものなのでなんでもかんでも共通にしないようがいいよ的なお話です。
異なる性質のものを同じ土壌で考えるべきか
事業を立ち上げる上で一定の正義は、やっぱりフェーズによって取るべき選択肢は変わるんじゃないかなぁというのが思っているところです。
まえにこんなことを書いたのですが、一見完全なる正義と思われる方向であってもその時点でその選択肢をとるのはさすがに悪手なんじゃないか、ということですね。それなりに成功している事業やシステムを持っている会社が異なる性質のビジネスやサービスを展開しようとする際、どうしてもその成功している部分の一部を使いたくなってしまうというのはあります。
これ自体は間違っていないですし、使えるものであれば使うべきではあるのですがそれにより本質的にやろうとしている事業が変わってきたり、必要以上に煩雑になったり、柔軟な設計ができなくなるというのは若干違うかなぁと。まぁ本当に正しく汎用的に元が設計されていれば話は違うのですが、なかなかそううまくはできていません。最初に設計されたインフラがベストだとしても、おそらくAWSのようには使うことはできないでしょうし。
文化の共通化は可能か
これも正直難しいと思っていて、売上をうんでいる事業とこれから立ち上げないといけない事業はそもそもの性質が異なってきます。異なるというか、評価軸や管理体制を別にしないとうまくいかない。最もよくないパターンが中間点というか落としどころを見つけるというやり方になりますが、これがどっちつかずでおそらく最悪。
で、どうせならどっちかに寄せましょうとなり、当然成功している事業のほうにカルチャーがよっていきます。コレ自体は間違ってなく、成功している事業に最適化されたカルチャーになっていくのでそっち側に大きな問題がうまれることはない。ただ、なかなか新しい事業だったり文化というものが生まれづらくなっていくんじゃないかなと思います。
当然、完全に別の組織にするという意味ではなく共通化する部分も一部あって良いと思います。会社としてのビジョンだったりバリューだったりってものは同じようにあったほうが良いと思いますし、なんらかの事業評価基準みたいなものがないと成果がでないときの撤退ラインも曖昧になってしまう。
似たようなカニバる子会社をたくさんもっている会社もあるけどある程度自由にさせるために子会社化しているのもあるんじゃないあかんと思います。これはイノベーション戦略の論理に書いてあった「事業をやる方向と回数」が大事だよね、的な話でもあるとは思いますが。
まぁそのあたりの線引は難しいのですが、なんでもかんでも共通にしても効率化どころか必要以上のコストをうんでしまったり、新しいものが生まれづらい環境になってしまう可能性もあるなと思いました。
シャリカレーという魔合体のことはおいておきます。
想いは時間に喰われるか
ベンチャーを立ち上げて、とにかく突き進んでいる時って人は最強になれる。こういうときって最初の「想い」だけで動いていて、どれだけ働いても戦い続けられる無敵状態になっている。
自分の想いをそのまま実現しているからこそ疲れないし、どこまでも走り続けることができる。この無敵状態ってプライベートにも反映されるもので、仕事が無敵状態の場合はプライベートも無敵でいられる事も多いと思う。
とはいえ実際に会社のビジョンやミッションって最初から決まっているような会社ってあまりなく、事業をつくっていく中で徐々に固まっていくことが多い。
そのビジョンが固まっていくなかで経営者の「想い」が成長することは本当に素晴らしいこと。いままで描いていた想いが抽象化されたり具体化されたりで、企業として成長をできるビジョンになっていく。そうできる会社や経営者は健全な思いで会社を経営できているはず。
これはあくまで従業員目線ではなく、経営者側の話。想いがピュアすぎた結果、ブラック企業化するって話はいったんおいておく。
想いはいつまで続くか
でも、何かのタイミングで想いが喰われることがある。何によって喰われるかはいろいろあると思う。単に時間によって風化しただけかもしれないし、心が折れたのかもしれないし、時代の変化かもしれないし、事業が思うように行かなかったのかもしれない。想いが強すぎて、責任感が強すぎて、それに押しつぶされちゃうなんて悲しいこともある。
そして何らかの理由で想いが喰われてしまって、当初の想いがよくわからなくなったとき、本当にやりたいことかわからなくなってしまったとき、最初に思い描いてた未来に立ち戻るしか無いんじゃないかなって思う。創業者としてピュアすぎて、最も未熟だった時の無邪気な想い。たぶん、そこをベースにまた引き直すしか自分を戻す方法は無いんじゃないかな。
過去の自分に立ち戻る
こうやって過去の自分の考えをみると過去の自分に気付かされることってある。初心忘れるべからずとはよくいったもので、最初ってただ自分の事業が前に進むだけで喜びがあったし、小さな出来事一つ一つに大喜びすることができた。でも人の幸せの水準なんて上がり続けていくもので、小さなことではだんだんと気づかなくなっていくもので。そんなことの積み重ねで、だんだんと方向を見失っちゃうことってよくあること。
新卒のときに言われた「幸せのレベルを下げよう」という言葉は今になって言葉の価値がちょっとわかった気がする。
最近の相次ぐサービスの終了と、この時期になると毎年思い出すこと、そして自分の仕事と価値について考え直す機会が重なったのでいろいろと書いてみました。さて、今日からまた頑張ろう。
