はじめに
この記事は、業務デザインの発想法 ~「仕組み」と「仕掛け」で最高のオペレーションを創るの発売を記念して、5/30日に開催された「業務デザインの発想法」新刊出版記念講演 で沢渡あまねさんから頂いた講演を、エンジニア視点で聞いてどう感じたか？をつらつらと書き殴った記事です。
この講演では、組織内で業務プロセスを改善して、残念なシステムや組織を生み出さないようサービスに対してデザインをし続けることの大切さを提唱しています。
なお、記事内の見出し(第n章)は、書籍と紐づいています。
業務をデザインすることとエンジニアの仕事はどう結びつくのかを考えるヒントになればと思います。
第１章 やるやらを決める
1-1 リアルタイム処理とバッチ処理
この章では、普段の業務をリアルタイム処理とバッチ処理に分けようという内容であった。
確かに、API通信とか１日１回チェックすれば良いようなメールの確認とか毎日リアルタイムにやってたら今頃通常の業務なんて手がつけられないだろうなぁと想像しました。
エンジニアは常に効率を求める生き物なので、その場で「これは今すぐやらなければならないのか？」を考える必要がありますね。
では、何を持ってリアルタイムとバッチを分ければ良いのだろうか？
例えば、本番環境へのデプロイをするのに、他の問い合わせとか定期的なAPIの実行もやったりしてたら集中力切れてバグを生み出してしまう可能性がある。本番環境へのデプロイをしているときは他の作業をしない、他の作業のことを考えなくて良い環境を作ってあげればインシデントは回避できるのではないだろうか。
これを突き詰めていくと、エンジニアがあえて人がやらなければならないことって無くない？という考えに至ってしまいました。
そう、エンジニアはめんどくさいことは二度としたくないっていうスタンスで日々働いているので、システム化できるものは全てシステム化したい生き物なんです。
でも、営業とかデザインとかステークホルダーとのタッチポイントに関わる時は、システム化しようとしても出来ない領域なのかなぁと考えました。
今の所、エンジニアにはそういう考えは無いのかなぁ…
1-2 ユーザの行動を設計する
次にユーザとのコミュニケーションについての話が挙がりました。
この辺りはガッツリUXの話でした。これを聞くとアプリ作成のポイントとか流行ってるサービスの共通項が見えてきました。
サービスを提供するに当たって、動線を工夫したりステークホルダーに対してプッシュ通知をするタイミングを工夫する。それだけでなく、コストや手間・記憶の煩わしさを取り除いてあげると、沢渡さんは書籍で述べています。
LINE botとかGoogleカレンダーの通知ってすごく便利だなーと感じるのはここにあると思いました。
ユーザがサービスに対して様子を見にいくプル型じゃなく、プッシュ型でユーザにアプローチして行動を設計することが大事なんですね。アプリの動線とかも直感的にゴールまで達成できると良いですね。
社内のシステムも同じように作ってあげればみんなハッピーになれますよね。会社から見れば従業員もステークホルダーなのですから。
第２章 おはようからおやすみまで
自分がWebサービスに携わっているので、常に運用・保守しなきゃという状況にすごく納得できました。
でもサービスだけが保守運用の対象じゃないと沢渡さんは述べています。
- 業務/サービス
- システム
- データ
- 機器・資料・材料
- 組織/権限
権限周りとかゾッとしますね。権限持ってる人が辞めちゃって誰も編集できないとか地獄ですよねw
僕たちが毎日眺めているプロダクトのソースコードも、常にリファクタリングを意識して保守・運用をしてあげないといけませんね。gitでアノテーションをした時にそのコードのロジックを持っている人がもう居ない状況になったらオワタですね／(^o^)＼
それぞれに対して、新規→利用→変更→停止→廃止のプロセスを持って運用してあげる必要があるんですね。
第３章 コミュニケーション設計
コミュニケーションを取るには気合いと根性で人情を売れ！っていうのがよく出てきますねw
でも本当にコミュニケーションの活性化ってそれだけで出来るのだろうか。エンジニアなんてコミュニケーション苦手なのに・・・
コミュニケーションにも設計が必要で、設計80%とスキル20%で成り立っていると沢渡さんは言います。
そもそもの業務設計がなければ、「これって報告する必要あるんだろうか？」と報告しづらい状況を作ったりと、言語化する機会を逃している。その環境を取っ払うために業務デザインが必要なんですね。
では、どのように設計をすると良いのか。
沢渡さんは誰に、何を発信し、どんな機会を捉えて、どう行動してほしいのかを提唱しています。
組織の中の人間もステークホルダーとして考えてくれる上司がいると相談しやすかったり普段から雑談しやすいと感じると思います。
第５章 ナレッジマネジメント教育
システムやサービスに対して、個人が持っている知識を踏みつぶさず共有・評価しましょうということですね。
システムが大きければ大きいほど、業務で関わるスコープが狭いから他の機能に関しては正直何も知らないし正直個人戦な感じもする。(例えばWebフロントの担当の人がバックエンド側でどんなインシデントが起こっているかとかあんまり興味持てないですよね…)
自社のサービスとかシステムに愛を持つためにナレッジを共有して自社システムに詳しくなることも大事なんですね。
ナレッジマネジメントとして、KPTが例としてあげられていた。
KPTとは、毎週もしくは隔週で行われるMTGで、日々心がけること(Keep)、行き詰まったことや問題(Problem)、問題に対するアプローチ(Try)をまとめて共有します。
エンジニアのインシデントとかトライって各々が頭の中で複雑に存在しているので、付箋とかスプレッドシートとかに簡潔に書き出して言語化すると整理しやすいなと思いました。
調べても分からないエラーやよりキレイなコードのロジックを組む悩みはチーム内で共有した方が早く解決したりするケースが多いので、Google先生も知らないような組織としてのナレッジがすごく溜まりやすいと感じています。
もう一つの例として、輪読会とかLT大会も挙げられていた。エンジニアLT大会とかはconnpassとかTECH PLAYで探せばいっぱいあるのでけっこう身近に感じれるナレッジマネジメントですね。
組織として、こういう仕掛け作りをすればシステムに対する知識だけじゃなくて、外の世界も知れる良い機会になるので良いですね。
同時に、その組織のレベルを管理することでより効率的なナレッジマネジメントが実現できると提唱した。
めちゃ納得。
第６章 人と組織を継続的に成長させる
沢渡さんはここで、本に載せていない無敵な成長サイクルを提唱した。
採用 →
育成 →
ファン創出 →
インターナルブランディング →
組織に所属しているからレベルアップできる！ →
成長実感 →
ここの組織すごいぜ →
エクスターナルブランディング
特に育成の部分は重要で、育成・学習と業務改善をしつつ、エンジニアなら設計してコード書いてテストしてリリースするという本来の役割を組織の中のポジションとして与えてあげることが大事だと説明した。
確かに、組織に対して貢献しているのと同じように、組織も一人一人に対して期待に応えたあげるべきですよね。
私が以前書いた記事で、オフショア開発において外注先の海外企業と上手く仕事をこなす手法についても述べましたが、モチベーションを継続させることが一人一人においても組織にとっても大切なことなので、それを失わないように常に気を配る必要があります。
*俺はスーパーエンジニアになるんや！*というエンジニア本来の価値を殺さないように育てて、組織のファンとして取り込むことで組織の成長にも繋がるんですね。俺も早くスーパーエンジニアになりたいぜ
まとめ
組織の改善とか日々の業務の改善って、上の人がやることだし下っ端がやいのやいの言ってもあんまり拾われないと思っていました。
ですが、エンジニアやデザイナーなどの専門職は特に現場の人間しか分からないことだらけなので、それを発信しない限り組織は良くならないのです。
変えられるかどうかはさておき、思っていることを発信してみんなが業務デザイナーであるという自覚を持つだけでも組織の雰囲気って変わるのかなと感じました。
「上長に絶対改善させてやる！」って気持ちよりも、1on1とか立ち話で「ちょっと相談したいんですけど」と声をかけてみるのも面白いかも知れません。