- 開発で発生問題の対処方法を間違えているかどうか不安
- 問題の解決方法がいつも的外れといわれる
- クネビンフレームワークで意思決定を行う
将来エンジニアになりたい、開発者になりたいという人は多いです。ただ巷に出ているのは、情報教材をやればエンジニアになれるというものが多いですが、実際は仕事をするときに困ることになるでしょう。
実際に開発現場に入ってやることは問題解決です。問題を解決しつづけ何ができるのか？を周りに認知してもらうことになるでしょう。
実際の開発現場ではどのような問題が起こるのか具体的な例を交えて解説していこうと思います。
私はメーカーで１５年ほど開発をやっているエンジニアですので、現場のことをかなり知っていますし、今もまだ現場で開発をやっています。
- お客様からのクレーム
- 他社が新機能を搭載したことによる新しい問題
開発現場では日々お客様の課題を解決するために、様々な仕事を実施しています。
その中でもお客様のクレームや他社の新機能発表によって自社が新しい問題を解決しなければいけないこともあります。
現場では日々様々な問題解決をして過ごす場としてとらえてみると面白いのかもしれません。
そんな開発現場では日々問題に対して、意思決定をして何をやるかやらないかを決めて進める必要があります。この方法を間違えると解決に時間がかかったりします。
そこで、問題を分けるフレームワークとしてCynefin Frameworkというものがあります。このフレームワークで分けて考えるとよいです。
- 単純（Simple）
- 煩雑（Complicated）
- 複雑（Complex）
- 混乱（Chaotic
クネビンフレームワークは、デイブ・スノーデン（Dave Snowden）が開発した「問題解決へのアプローチを考える」フレームワークです。
ハーバードビジネスレビューで紹介されたことをきっかけに広まりました
このフレームワークでは、発生した問題や状況を４つのドメインに分類して考えます
1.Simple：単純
⇒問題の因果関係・構造が明確
2.Complicated：煩雑
⇒少し分析すれば、因果関係・構造が明確
3.Complex；複雑
⇒因果関係が複雑、調査・探索が必要
4.Chaotic：混乱
⇒因果関係が不明確で、状況や問題を理解することも難しい
その他.Disorder(ディスオーダー)：無秩序
⇒直面する問題に適切な解決策がない
の４つです。メーカーのモノ作りの中でどのような問題に直面するのでしょうか各事例を紹介していきます。
- 単純なバグ修正：（例）UIに表示されるメッセージが間違っていた
- 仕様書の誤記：仕様書に決まった仕様が書かれていない
先ほど説明しましたが、単純と分類される問題の特徴は、問題の因果関係・構造が明確ということです。実際の開発現場では毎日単純な問題は発生します。
UIの実装でメッセージ間違えていた、if文を逆に実装していた。などが該当します。
私は実装というより品質チェックをする立場にいるので、単純な問題というと、問題対応しているのに、直した後のエビデンスが何も提出されていないということでしょうか。何を直したのかわからなくなるので、毎回確認するようにしています。あとから追うのも面倒なのですし、それが原因で市場からクレームが出るということもあるからです。
単純な問題は数は多いですが、自分のやれる範囲でできる仕事なので、計画的にこなすことができるので私は好きです。ただ成長の観点からみると、できるようになったら派遣・委託などにやってもらうのがよいでしょう。自身の成長にはならなくなる問題です。
- 少し専門知識の必要なバグ修正：10Gネットワーク前提で作っていたが、テストは10Mのネットワークでやっておりタイムアウトエラー頻発する
- 仕様書の誤記：画像処理の手法が間違って記載されていた
煩雑な問題とは、少々問題の分析が必要ですが、知識があれば因果関係の判別が可能な問題です。専門知識があれば一発で回答可能なものととらえるとよいのかもしれません。例としては、Network関連トラブル、画像処理関連トラブルなど専門知識があれば即解決というものを指しています。
なぜ専門知識が必要かということですが、現場によって異なります。
私がいる現場は、一つの知識では開発できません。複雑なシステムを複数の技術領域を使い実現しているため、問題が１つの知識で解決できることは稀です。
解決方法となると、チームに相談したり専門家を社内から見つけて相談するといった行動をとる必要があります。ここで必要なのはコミュニケーション力となります。
よくありがちな間違えた行動は、自分なりにWebで調べて実装して解決としてしまうことです。レビュー等で軌道修正されればよいですが、そのようなメンバーがいないチームの場合はそのまま市場へいくことになります。
- 複雑なバグ修正：複雑なシステムに対する変更
- 仕様書の誤記：複雑なシステムのある部品変更などその影響箇所のドキュメント変更
複雑な問題とは、ドメインは不確実性が高く、予測可能性が低いものとされています。そのため「複雑」の対処には、問題の分析から更に踏み込んだ調査が必要です。
複雑なシステムの例を出すと、組み込み機器・Linux・WindowsやCloudサーバなどと連携するシステムの場合、どこに問題があるか問題の現象でわからないです。
このような問題は大きめの問題としてあげられます。１か月、２か月の調査を行い仮説を立てながら進める必要があります。このレベルの問題を解決できるかどうかが良いエンジニアや現場で使えるといわれるレベルのエンジニアです。
メーカーに勤めるエンジニアはこのレベルの問題解決に集中し取り組むほうが組織やチームにとってはよいです。環境によって、できる派遣メンバーが対応したり、一部のメンバーが解決している場合もよく見る光景です。ここで手を挙げてやれるようになると成長もするしスキルも上がることでしょう。
- 混乱なバグ修正：物理現象から追う必要のある変更
「混乱」は問題の原因も結果も不明な状態で、とにかく早急な対応・行動が要求されます。
先に問題に対して手を打ち、手を打った結果問題の原因に気づくのが「混乱」の対処行動の特徴であり、原因追及型と大きく異なる点です。
この手の問題は、あまり起きませんが、発生した場合はビジネスが止まったり、生産できなくなるため、早急に解決が必要になります。こういったリーダーに指名され実際に解決するエンジニアがどんどん出世していきます。ただプレッシャーも大きいですし、判断をミスすると、猛烈な工数を使い人が倒れることもあります。
このレベルの問題は会議も多くなるので、説明する機会が増え作業ができなくなる特徴があります。1度やったらもう関わりたくない案件と私は呼んでますね。
- クネビンフレームワークをベースに問題解説をしてみた
問題をクネビンフレームワークにあてはめて、自分の解決すべき問題を分類することから始めましょう。
自分の成長のためには、複雑な問題や煩雑な問題をこなす量をある程度確保した状態で仕事をすることがよいです。
そういった問題が与えられない組織にいる場合は、変化するという選択肢もよいです。組織やチームは問題を成長してほしいと思う人に振るので、いつも良い問題があるとは限りません。
私は環境を変えてから様々な高度な問題に対応することが増え成長の実感を感じています。異動にはざまざまな障害がありますので、体験談をまとめています。
