エンジニアからみるマネジメント基礎 - 第3回 改善と問題解決
では前回に引き続き、以下の全7回のうちの第3回目になります。
- 管理の基礎
- 仕事の管理
- 改善と問題解決 ← 今回はここ
- 人間行動の理解
- 部下の育成
- よい職場つくり
- 管理者の自己啓発
第3回 改善と問題解決
改善と競争は、人間社会の基本的原理であり発展の原動力である。職場の仕事の改善は、まず管理者自らが問題意識をもち、絶えず改善への探求を続けることが大切である。
3.1 改善における管理者の役割
3.1.1 管理者は改善の原動力
管理者は日常の管理活動の中で自ら改善にあたるとともに、部下が改善に関心をもって積極的に取り組むように働きかけることにより、職場を活性化して改善意欲の高い風土をつくることである。そのために管理者は
- 部下に問題を投げかけ、問題意識を高める
- 部下からの提案に耳を傾け、よい案を取り入れる
- 改善のねらいや方向を明確にし、部下に理解させる
- 部下と一緒になって考える
- 障害を取り除く
といった行動をすることが大切である。
管理者は改善の原動力として
- 問題を論理的に組み立てる
- 衆知を結集する
- 関係者を巻き込んで実現にもっていく
といった問題解決能力を身につける必要がある。
エンジニアマネージャーとして
エンジニアリングよって解決できる問題（システム上の問題）と、エンジニアリングによって解決出来ない問題（開発PCのスペックが低い）がある。エンジニアマネージャーとしては、エンジニアリングによって解決出来ない問題にも取り組む必要があります。
3.1.2 改善にあたっての基本姿勢
部下に改善意欲をもたせ、自主的に改善を進めさせることは大切であるが、問題によっては管理者自らが考え、改善する必要もある。基本的には自分の管理する組織の改善、風土、手続き、人事などに関しては管理者が行うべき改善である。部下に任せる改善は業務（仕事）そのものの改善である。
- 管理者が行う改善・・・組織の改善
- 部下に任せる改善・・・仕事の改善
エンジニアマネージャーとして
自分が担当するシステムの改善は部下に意欲的にやってもらいましょう。エンジニアマネージャーは、彼らが意欲的に働くことを阻害する要因を排除するように改善を行いましょう。無駄な会議、劣悪な開発環境、少ない予算、足りない人員、周囲からのノイズ、偏った評価制度など。
3.2 問題と問題意識
3.2.1 問題とは
- 問題とは
あるべき姿と現状の差（ギャップ）であり、解決を必要とする事柄
- 問題解決とは
あるべき姿と現状の差（ギャップ）をなくすこと
エンジニアマネージャーとして
何がギャップかをはっきりさせるために、あるべき姿と現状をはっきりさせる必要があります。バグ修正などはとてもわかりやすい事例でしょう。
3.2.2 問題をとらえる立場
問題はとらえる立場、おかれた立場によって異なる。問題を解決する立場からしてみれば、問題となるものならないものは以下のようになる。
1. 問題となるもの
ギャップを認識し、自らこれを解決しようとする意思をもっている事柄
2. 問題とならないもの
ギャップを認識しているが、自らは解決する意思をもっていない事柄
ギャップがあったとしても、対策の立てようもないものや答えの出せない事柄
エンジニアマネージャーとして
立場によってどこまでを自身が解決できる問題と置くかは変わります。新人エンジニアが組織の問題を問題として捉えられないのも当然です。マネージャーとしては、彼らが問題として捉えられない高次元の問題を解決することに時間を割くべきです。
3.2.3 問題の種類
- 発生型の問題（未達型の問題）
あるべき姿に向かって進めてきたが、予定通り運ばないために、現時点でギャップが生じている問題
例）1ヶ月後にリリースしなければならないが、現時点でまだ結合テストが終わっていない
- 発生型の問題（逸脱型の問題）
あるべき姿で進んでいたのに、そこから外れて対策を必要とするギャップになってしまった問題
例）SSL証明書の有効期限が切れた。
- 設定型の問題
あるねらいをもってあるべき姿の水準を引き上げ、ギャップを作り出すという問題
例）リリースサイクルの自動化を導入して、高頻度で安全なリリースを実現する
エンジニアマネージャーとして
特段この分類を気にする必要があるとは思いませんが、この視点での問題分類は面白いと思います。発生型の問題というのはどうしても解決しないといけない問題ですので、対策に周りの理解を得やすいでしょう。一方で設定型の問題は、「現状うまく周っているのだから、そこに今あえて切り込む必要はない」という意見に封殺されてしまいがちです。しかし自ら問題を設定しそれを解決するというのは、（今考えれば）採用時に応募者に求めるスキルの1つによく上がりますよね。マネージャーとしては、メンバーが設定型の問題を持ってきた場合には決して封殺せずに、積極的にやらせて上げるべきです。また非常に自身の成長に繋がりやすく、満足度も上がりやすい課題です。
3.2.4 問題把握のタイミング
タイミングは以下の３つに分類される
- 予知する問題（潜在している問題）
例）スパゲッティコード、テストのないコード
- 感知する問題（早期に発見する問題）
例）パスワードの平文で保存されている。まだお客様は気づいていないけど、バレたらやばい。
- 飛び込む問題（火消し問題）
例）OOMでTomcatが死んだ
エンジニアマネージャーとして
問題は早く把握し手を打つことが大切である。バグは発見が遅れるほど、修正にコストがかかるのと同様です。
3.2.5 問題意識
管理者が改善を進めるためには常に職場の仕事の状況を正確につかみ、鋭い問題意識をもって問題を見つけ、解決しようという強い意欲をもって部下を指導していくことが必要である。
エンジニアマネージャーとして
マネージャーが問題を改善していく気概がなければ、問題意識のある部下はついていかないでしょう。助言しても無駄、改善を実施させてもくれないとなったら、優秀なエンジニアから辞めていきます。
3.3 問題解決の手順
3.3.1 問題解決のステップ（科学的接近）
科学的接近による問題解決は、事実を基にして一連のステップを順序を追って一つひとつ進め解決に到達しようとするものである。
- 問題発見と形成
- 問題を明らかにする
- 問題の証拠を上げる
- 原因分析
- 原因を探る
- 核心的原因をつきとめる
- 意思決定
- 対策の目的を明らかにする
- いくつかの代替案を考える
- 対策を決める
- 実行
- 対策を実施する
- あとを確かめる
3.3.2 問題発見と形成（問題のつかみ方）
ギャップを明確にするために、まず「あるべき姿」をはっきりさせておかなければならない。そして、あるべき姿と現状を比較してそのギャップをつかみ、問題のアウトラインを文章によって具体的に表現する。そしてそれが問題であることを証拠を集める。
例）弊社通販サイトのフロントの描画速度は3000ms以内が理想であるとリリース当初は定めている。だが、リリースして一年がたち、最近描画速度が遅くなってきているようで、このままいくと顧客が離脱し売上が減る恐れがある。フロントにログを仕込んで描画速度を保存するようにして、過去一週間の描画速度を集計した。また同時に描画速度とコンバージョンについての研究記事を説得材料として集める。
3.3.3 原因分析（原因のつきとめ方）
証拠からスタートして原因と思われる事実を集めます。できる限りデータに基づくことが大事です。そして「これがなければこの問題は起きなかったという原因」である核心的原因を突き止めます。
例）フロントの描画ログは過去一週間平均で約3000msであった。しかし実際の体感としてはもっとかかっているように感じる。nginxログを集計してみたら初回アクセス時に2000msかかっていることがわかった。どうやらフロントエンド・バックエンド双方に問題があるようである。まずはフロントエンドの詳細な分析をするためにChrome Developer Toolを利用して、どのjs処理にどの程度時間がかかっているのか計測してみたところ、サーバーへのajaxアクセスでリコメンド商品リストを取得しているが、同期処理になっており後続のjs処理をブロックしている。またこの取得処理にも1000msかかっている。JVMの分析を行ってみたところ、DBアクセスに80%の時間を費やしておりソースを見たら商品リストをループさせ、その中で商品詳細情報などを取得するためにSQLを発行していることがわかった。
3.3.4 意思決定（対策の決め方）
原因から対策を決めます。その際には対策の目的にはどうしても達成しなければならない絶対目的と、できればやったほうがよい希望目的とを区別しておくことも有効です。ですが、緊急を要する場合には代替案から対策を始めることも有効となります。対策を決めたら実行に移す前に次の処置を考えておきましょう。
また、実行の障害となることが起きる可能性を予測して、これを予防する処置を予め講じておき、障害が発生したときにその被害を最小限に抑える処置も考えて置く必要があります。
例）フロントエンドはPromise処理を導入して、非同期処理を実現して描画速度の改善を試みます。バックエンドはループ内でのSQL発行を止めて、複雑なSQLになりますがjoinして取りに行くことにしました。出来たら、Viewテーブルを作成しておいてそこにアクセスすれば簡素なSQLでアクセスできるので好ましいのだが、まだViewを利用したことがなく検証に時間がかかるので、今後の対応としておく。開発環境でテストしてみたところ、50%の速度改善がはかれたので本番環境でも効果が期待できると思う。この修正方針でいくことをレビューし、許可をマネージャーからもらう。
3.4 改善を実施する際の留意点
3.4.1 実施のタイミング
安全強化月間に安全対策を行ったり作業基準を改善すれば円滑に実施されるが、顧客とトラブルが起こっているときに実施しようとしても誰も身を入れて実施してくれないだろう。
例）残念ながら無停止適用できるほどうちのサイトは良く出来ていない。適用には停止時間が必要になる。運営サイドと話し合い、次回定期メンテナンスより前の売上が少ない時間帯を見計らって、適用することに決定した。
3.4.2 合理化と3S
標準化（Standardization） --- 品質安定・向上のために作業方法等を統一し、誰が操作しても一定の質の仕事をできるようにすること
単純化（Simplification）--- 部品や作業方法などをできる限り簡素化し単純化すること
専門化（Specialization）--- 部品や作業方法を専門化・特殊化しておくことで、作業方法を分業化し、一つのことに集中すること
エンジニアマネージャーとして
ソフトウェア品質ということに関していえば、標準化とはソースコードの静的解析、自動テスト、レビュープロセスなどが該当します。単純化はオブジェクト指向などで1つクラスに複数の仕事をさせない工夫、専門化とはフロントエンド開発者、バックエンド開発者のように分業を行っていくことになるであろう。ですが、この３Sをあらためて意識して導入していく意味はまだ筆者は見い出せていないです。
3.4.3 改善に対する抵抗
関係者が多くなればなるほど、改善に対抗してくる人も出てくるでしょう。正論であっても、しかしという気持ちが出るのが人間である。合理性だけではなく職場の空気や関係者の気持ちにも十分に配慮しなければならない。
エンジニアマネージャーとして
「今弊社のサイトはプロモーションをどんどん行っており、売上は右肩上がりである。サイトを停止するなどしたくない。多少サイトが遅かろうが問題ない。」という意見もあるかもしれません。エンジニアマネージャーとしては、他組織との交渉を引き受けながら、一方で自分たちのシステムの変更が他に依存しないようなシステム構成にするよう開発を続けていく必要があります。エンジニアリングで解決できることはエンジニアリングで解決し、抵抗者との依存を減らしていくことに意識を向けるべきです。
3.4.4 問題を共有化する
改善に対する抵抗を乗り越えるには改善の必要性を合理的に道筋を立てて説明するとともに、強い熱意をもって相手の感情に訴えかけて共感を得ることが大事である。
- なぜ、この改善を行わなければいけないのか
- 改善することによって関係者の仕事の分担や方法にどんな影響が出るのか
- 改善したときの効果はどうか
- 改善しないとどうなるのか
以上を関係者の協力を求める姿勢で十分説明するようにし、決まった対策を一方的に押し付けることがないように注意する必要がある。
そのためには、対策が導き出されたプロセスを関係者に体験してもらうことが一番で、できるだけ企画段階からさせるとよい。
エンジニアマネージャーとして
システムを良くしようとしていく思いに反対する人はいないはずです。常に、開発が行っていること、今後行いたいこと、をきちんと開発部門外にも分かるようにアピールし続け、常に理解者を増やす努力をし続ける必要があるでしょう。これは会社が大きくなればなるほどに起こる問題です。この手の仕事が苦手なエンジニアが多いと思いますが、マネージャーは頑張りましょう。
以上、第3回 改善と問題解決でした。
