日々鍛錬

ソフトウェア開発エンジニアが鍛錬を続ける

根本原因の考え方 〜開発プロセスを「工場」に例えて考える〜

「工場」をイメージして根本原因を探る

開発プロセスを工場のラインとして捉えると、本当の原因にアプローチしやすくなる。例えばペットボトル飲料の製造工場として捉えてみよう。本物の工場の工程を知っている訳ではないが、勝手に想像した工場のラインをイメージ化するとこうなる。


各種原料を元にして、材料を撹拌し、ペットボトルに封入し、出来上がったボトルをラベリングし…といった工程を踏んでいく。各工程間は検査員がチェックをしており、品質の問題が無いかチェックを行っている。

 ペットボトルに異物が混入!?

あなたはこの工場のライン管理者。生産から出荷に至るまで最終的な責任を負っている。

各製造工程を経て、順調に大量のペットボトル飲料が生産されていく。あとは来週の初出荷の時を待つのみ…。と思っていた矢先、品質管理担当から「最終生産品の飲料内に、一定の割合で異物が混入しいてる」という報告を受けてしまった。

工場のライン管理者であるあなたは、この問題に対応して製品を出荷しなくてはならない。

ラインは動かし続ける必要があるが、既に生産してしまった異物の混入した製品は、回収して適切な対応を行わなくてはならない。

さてあなたは原因をどう分析して対策するか?

異物が混入してしまう工程や原因を突き止める

賢明なあなたであれば、問題の原因は封入以前の工程や原料に由来している可能性が高いと考えるだろう。そして各工程でどのような製造プロセスが回っているか調査し、異物が混入するプロセスを特定しにいくだろう。

なぜなら、原因となるプロセスや問題を根本から断ち切らないと、いつまで経っても問題は収束しないからだ。

それに加え、生産してしまった製品のうち、どの製品を回収すべきか当たりをつけるためにも役に立つ。一例として、複数台ある機械のうち特定の機械だけ故障している、などが考えられる。 

「最終工程が甘い」? 的外れに見える原因分析

さて、これまでの分析によって異物混入プロセスが大体判明した。これでようやく問題も収束しそうだ・・・。と思っていたころ、あなたのチームの誰かが「最終工程後の検査員のチェックが甘いのが原因なのでは?」と突然言い始めた。

そして彼は対策として「最終工程後の検査を強化し、かつ出来上がった飲料をしらみつぶしにチェックしていくべきだ!」と声高に主張している。賢明なあなたであれば、この対策が適切だとは思えないはずだ。それはなぜか。 

仮に最終工程だけ強化されたとしても、根本的な原因が取り除かれないため、異物が混入された製品は生産されて続ける。それを最終工程で常にチェックするなんて、極めて非効率であり、少しでもチェックに漏れがあれば異物が混入した製品を出荷してしまうことになる。

だからこそ、対策として適切ではないのだ。

開発プロセスに置き換えてみる

ここで、上記の工場の生産プロセスをシステムの開発プロセスに置き換えて考えてみよう。

この図に記載したドキュメントだけでシステム開発を十分に行えると仮定して見て欲しい。

システム開発の場合は「設計→製造→テスト」という工程を経て、最終成果物であるソフトウェアが作られ、出荷されていく。それに合わせてペットボトル工場の工程名や原料名をシステム開発の用語へ置き換えた。 

よくある品質懸念を例に考える

ペットボトル工場の異物混入問題と同じように、システム開発で発生する問題を考えてみたい。

良くある例として…単体テスト工程が終わった後、その後のテスト工程で単体テスト工程で取り除くべき障害が多数見つかり、品質懸念が発生した、という例を取り上げてみたい。

結合テストで検出した障害が単体テストレベルの障害であり「特定のデータパターンで処理分岐が考慮できておらず、エラーが発生する」というものだったとする。

これが結合テストの工程で「大量に」発見された、という状況だ。この時、どうやって原因を分析するだろうか?

 陥りがちな誤り

「データパターンの処理ができていない」と聞いたときに真っ先に思い浮かべるのはテスト工程。「パターンが網羅できていないんじゃないか」という疑念が浮かぶ。

その思いに駆られ、安易な分析をしてしまうと「テスト工程に問題がある。テストの際に十分なデータパターンをテストできていなかったから、問題が流出した。

同じような障害が埋まっている可能性が高いので、テストのデータパターンを洗いなおす」といった対策を打とうとしてしまう。 

はたして、これは有効な対策だろうか?ペットボトル飲料の工場の例で書いた「最終工程の検査を強化する」という対策と、似ている部分がないか考えてみてほしい。

無差別に「データパターンを洗い直す」ということは、最終的に生産されたペットボトルをチェックしようとしているのと似ているのでは…?(完全に一致しているわけではないが)

このような対策をしても、結局効果が薄く、根本的な問題の解決には至らない。

開発プロセスの「封入工程」を探せ

ペットボトル工場では「封入工程」に根本原因がありそうだった。それではシステム開発の「封入工程」はどこだろうか?

 

ペットボトルの「封入工程」は、各原材料を利用し製品自体を製造するメインの工程であるが、システム開発でいうところの「要件」を元にして「設計」や「製造」を行い成果物を作っていく工程と似ている。

また「データパターンを考慮して処理分岐を考える」のは、開発者が「設計」しているタイミングだ。とすると「設計」が「封入工程」と似てはいないだろうか? 

「封入工程」で何が起こっていたか?

今回の結合試験では「データパターンを意識できていない」障害が「少数ではなく大量」に見つかっている。当初想定していなかった問題が一つではなく多数見つかるという事はプロセス上の不備である可能性が高い。要するに「設計」のプロセスに何らか問題がある可能性が高い。要するに設計者が「設計のタイミングでデータパターンを意識できない状態になっていた」ということだ。

例えば特定の設計者が「データパターンは要件定義書に全て記載されている。それ以上の設計は不要だ」という前提がインプットされ、設計してい可能性などが考えられる。

まさにこれがペットボトル工場でいう「機械の故障」だ。システム開発では「機械」ではなく「人」が開発を行う。しかし、その作業前提となる「プロセス」が誤っていれば成果物にエラーが埋め込まれてしまう。

ここまで特定できれば、あとは問題のあるプロセスを通して生産したもの(ペットボトル工場でいうところの特定の機械を通して生産された飲料)だけを選り分けて、必要なデータパターンを洗い出し集中的に対応すれば良い。

それ以外の成果物は同様の問題をもつリスクが低いため、対応の優先度が低くなり、強弱をつけて対策を行うことができる。

事象を単純化し「過ぎる」ことなかれ

上記はあくまで一例だが、上記の悪例のような障害分析を行ってしまっているケースは非常に多い。実際に起こった障害を分析するときに「データパターンが漏れた=テスト工程が悪い」といった具合に、発生した複雑な事象を理解しないまま、特定の側面だけ捉えて対策を打ってしまうケースだ。

システム開発は工場のように機械で製品を大量生産している訳ではないため、一連のプロセスを経てシステムが作られているということを認識し辛い。しかし実際は、工場のラインと同じように事前に設計されたプロセスを通して成果物を生産している。

そのため、本章で紹介したように開発プロセスを工場のように構造化しプロセスの因果関係を考えてみると、真の問題にアプローチしやすくなる。

表層的な課題対応に終始せず、プロセス全体を通して考えるクセをつけていきたい。

 

ただし、システム開発は「機械」で行うものではない

やや逆説的にはなるものの、システム開発のプロセスは「機械」で行っているわけではなく「人」で行っている。

そのため、工場とは趣の異なる不確実な要素が含まれており、工場とは違ったポイントを考慮することも必要となる(例えば「モチベーション」「チームの風通しの良さ」も大きな要因となる)。

 

こういった不確実要素を含め「いかに目的の品質にアジャストして生産するか」ということを考え抜き自分なりの答えを出していくのが、システム開発マネジメントの醍醐味の一つだと思っている。

システム開発と情報の非対称性

実は身の回りで起こっている「情報搾取」

うちの会社では「要求を出すチーム」「要求を精緻化するチーム」「開発実行するチーム」といった具合でチームが分かれていることが多い。「要求を精緻化するチーム」は社員が多く「開発を実行するチーム」は準委任契約の常駐パートナーが多い。ただ幸いにも、「要求を精緻化するチーム」は、他の企業のように「情報システム部門」や「情報システム子会社」になったりする訳ではなくて、同じ会社の開発にチームとなって動いていることが多い。そのため、情報の流通速度は割と早いほうだとは思う。特に「同じ会社だからフラットに情報を流通すべきだ」と自覚している社員が多いチームほど、流通速度は上がる。当たり前の話だが。

 

しかしながら、情報システム部門や情報システム子会社、SIerから中途入社で来たようなメンバーが「要求を精緻化するチーム」に入ってしまった場合は少し違う。

仕事を始めてから今まで、育ってきた環境の違いから「自分たちが正しく情報を理解し、正しく下流工程へ伝えなければならない」という想いが強いようで、頑張って開発チーム向けのインプット資料を作り、要求を出すチームや自チーム内で何度もレビューを繰り返して、最終的に出来上がった情報を下流工程に渡そうとする。

 

この行動は一見良いように見えるものの、実はこの過程において大量の情報が失われている。レビューを繰り返した時の議論や課題は全て隠蔽され、最終的な結論しか残らない。どのような議論が尽くされたのか全く見えない。さらに酷い場合は、大元の要求すら隠蔽されている。これを私は「情報搾取」と呼んでいる。

システム開発と「情報」

ここで、システム開発と情報について考えてみたい。工業ロボットの製造工場をメタファーとして考える。

工業ロボットの製造工場において最終的に製品を作り上げるためには、複数の部品が必要となる。

製品に合った部品をベルトコンベアで流し、部品からパーツを作り上げ、そのパーツを最終工程で組み上げて製品を作る。

工業ロボットでいうと、最初から全てを新規で作り上げることはなく、コアとなる基盤は今までの製品を流用し、それに合わせた形で新たなパーツを作りあげていくだろう。

仮に部品の規格がパーツに合っていなかったり、パーツが既存のコア基盤の仕様を無視して作られていたりすると、前工程へ戻される。当たり前だが、品質に問題があるからだ。そして最終的には全ての要求・仕様が噛み合い、製品が完成する。

 

さて、製造スピードスピードを高めるためにはどうすればいいだろうか?

TPSの考え方でいうと、部品が必要なときに、必要なだけ、迅速に供給される必要がある。品質に問題がある場合は迅速に検知して新たな部品を流さなくてはならない。

 

さて、システム開発における「部品」は何だろうか?

自分は「情報」だと思っている。システム開発においては、要求や仕様などの情報が後続の作業者に渡っていかなければ製品=コードは作ることができない。ちょっとでも情報インプットされれば開発できるような機能なんていくらでもあるが、情報が落ちて来なければ開発することは不可能だ。なので、下流工程にとって必要な情報をいかに早く流通させるか、ということがシステムを早く届けることにつながるのである。

情報の非対称性とその捻れ

上記に記載した通り、部品である「情報」はできるだけ早く下流に流した方が、全体のリードタイムは短くなるはずだ。しかし、これを「日本の商習慣」「組織構造」が情報を流す事を阻んでしまう。例えば一番最初に書いたように「正しく決まった事を流そうとする」ということは、ある程度の情報がまとまった後に後続へ流す事を意味する。情報のバッチサイズを大きくしてから流そうとするのだ。これは「社員対パートナー」「ユーザ企業対SIer」などの構造の中で特に発生しやすい。いわゆる情報の非対称性が発生してしまい、本来進むはずのものが進まなくなってしまう。

また、システム開発における情報は上流と下流双方での非対称的になっていることが多く、プロジェクトの上流に関する情報は下流は知らず、既存システムの現仕様に関する情報は下流は知っているが上流は知らない、という状態になりがちだ。上流では既存システムの制約を考慮せずに要求・仕様を定めてしまう一方で、情報のバッチサイズが大きいため、下流へその情報を流した時に一気に手戻りを起こしてしまう。工業ロボットの製造ラインへ例えると、上流から規格外の部品を一括で製造してしまった後、一気に最終工程へ送り込むようなものだ。一つの部品だけ最初に後工程に送っておけば気づけたはずが、全て組み上げるタイミングでようやく問題が発覚する。要するに品質の低い部品を大量に後工程へ送っていることに他ならないのである。

 

f:id:heica:20181229130553p:plainf:id:heica:20181229130641p:plain工場を止める「情報搾取」

さらにそれを助長するのが、要求元と開発者の間に立つ「要求を精緻化するチーム」である。我が社では「ディレクション」と呼ばれるポジションだ。本来このチームは要求元と開発者の良き通訳・翻訳者でなければならない。そのため、自分たちだけが持つ情報をできるだけ少なくし、要求元と開発者が直接会話できるような事項はそのまま会話をさせ、首を突っ込んではならない。首を突っ込めば突っ込むほど情報をスタックさせ、劣化させ、後工程へ質の悪い情報を送って手戻らせる。

しかしながら先に書いた通り、日本の組織ではこれを「あるべき姿である」と誤認し、どうしても正しい情報を選別し、まとめて後工程へ送ろうとしてしまうのだ。

 

一部の人たちは「不正確な情報を与えると、混乱させてしまう」という事を言う人がいる。正直、これには呆れてしまう。

どのような場面であれ、まだ決まっていない情報をもらったことで、あたたが不利益を被ったことがあるだろうか?あるとすれば、最終的な結論が曖昧なまま物事が進んでしまって、間違った仕事をしてしまった、ぐらいだろう。単純に結論が決まっていればいいのだ。

そうすれば、後工程で情報を受け取った人は、どのような経緯で問題が解決されていったのか把握することができ、逆に議論が尽くされていることに想いを馳せる必要がなくなるのだ。それよか、議論が尽くされていないであろう他の事項に想いを馳せ、疑問を持つことができるため、品質は向上するはずである。なぜなら、情報の非対称性が緩和されているからだ。

いかに情報を歩留まりさせないか

これまで述べたように、システム開発に置いて情報の透明性や流通は極めて重要だ。これを実現するためには、コミュニケーション上の仕掛けが重要である。

ディレクション組織を介するコミュニケーションにはしない

上記に記載した通り、ディレクション組織など情報を歩留まりさせてしまうチームを間に挟むようなことはしないことだ。場のファシリテーション、重要な課題事項の推進、全体のコントロールを担わせるべきであり、決して開発の各論に対して首を突っ込ませてはならない。

コミュニケーションツールを使用し、可能な限り情報を公開する

古くはメールングリスト、最近はSlack等のコミュニケーションツールがあるが、利用方法を誤ると一気に情報が歩留まりしてしまう。まず、プロジェクトに関わる内容について1 to 1コミュニケーションを絶対にやめさせることだ。情報が錯綜し、決定までに長い時間をかけることになる。

更には、プライベートな情報のグループ化もやめさせた方がいい。例えば「要件チーム」「開発チーム」でグループを分けながら、グループ内しか内容を知ることができないメーリングリストやチャットグループを作ってしまいがちだ。しかしこれはやめさせなくてはならない。このようなグループを分けてしまうと、情報がバッチでしか流れなくなる。これこそ上記に書いた情報の非対称性を産んでしまう。

前工程からシステム知見者に同席してもらう

先に書いた通り、システム開発においては情報の非対称性だけでなく、それが捻れている。これを開発の序盤から解消させるためにも、システムについて熟知している人は上流の検討から入るべきだ。なんとなく経験的に「システムの知見を持っている人が最初から検討に入るべき」と思っている方々も多いとは思うが、このような情報の非対称性が理由であると考えればスッキリする。

情報を密閉しようとする力を阻止せよ

上記に記載した通り、システム開発に置いていかに「情報の透明性を担保するか」ということが重要か説いてきた。しかしこれは、システム開発に限ったことではない。これは私の肌感でしかないが、日本の企業は得てして「情報を隠すこと」によって個別最適が計られ、情報を持っている人が得をするような構造に慣れきってしまっているように思う。日本全体の生産性が悪いと言われているのも、このようなことが本質的な原因なのではないかと思ってしまう。

恐らく今後仕事を進める中で、情報を密閉し流通させることを拒む輩が必ず現れる。

「この情報はこの場にいる人だけで共有することにしたい」「他の組織には伝えないように」などなど。そんな場面に出くわす度に「なぜこの情報を公開してはならないのか?」と問いかけて欲しい。

システムのライフサイクルと「社員」の変遷

「社員だから〜をしなければならない」

最近、他の開発組織のマネージャーSさんと会話する機会があり、全般的な開発プロセスについて会話した。

この中でSさんが頻繁に使っていた言葉は「パートナーの方に〜してもらうために」という言葉だった。

この言葉に非常に違和感を感じたため、詳細を議論した。

 

この話の詳細を話そう。彼の開発組織はパートナーを含めると30〜40名ほどの開発組織だ。組織としては一体となっている。しかし実態としは「社員相当のメンバー(一部パートナーを含むためこういった表現にしている)」「パートナーのメンバー」という大きな区分を設けて運営している。組織の中で複数のチームを分け、そのチームのリーダーとして社員相当のメンバーを置き、その下にパートナーメンバーを置いている。

開発案件を実行するときは、かならず社員相当のメンバーが上流の要件を検討し、それを要件定義書相当のドキュメントに纏め上げ、パートナーメンバーへインプットし、開発を始める。

 

こういったやり口は「社員相当のメンバーは要求をまとめて開発者へインプットしなければならない」という一種の先入観とシステムのライフサイクルが絡み合って形成されていく。

システムの初期構築から保守・運用・拡張開発に移行して起こること

システムの初期構築には大量のメンバーが携わる。一方で初期構築以降の保守・運用などは、初期構築のメンバーの一部メンバーを限定して実行されることが殆どだ。まずここで問題の種が埋め込まれる。

初期構築から携わるメンバーの知識レベルは非常に高く、いわゆるシステム有識者としてシステムの維持保守に必要なスキルを持っている。こういったメンバーは組織の中でも主要なメンバーであることが多く、システムに対する新たな要求・要望を的確に捌くことが可能だ。また社員、パートナー双方にこういったキーメンバーが残り、それぞれが有機的に阿吽の呼吸で連携しながらシステムが維持されていく。

 

この初期構築から数年が経過したときに何が発生するか。システムは維持しなければならないが、主力のメンバーをこのシステムに固定しておくのではなく、新たな現場で成長をさせたいという周囲の期待がかかってくる。それを実現するためにも、若手のメンバーを社員・パートナー双方に投入することになる。これまでシステム全体を見通せていた社員・パートナー双方のスキルセットが徐々に変わり始め、社員の若手メンバーは上流には詳しくなるが、下流のシステム仕様は理解できない。逆もまた然りだ。

最終的に社員・パートナー双方からシステムのキーメンバーが別の現場に移った後、上流を担当する社員相当のメンバーはシステム仕様を知らないまま要求を作り続け、下流を担当するパートナーのメンバーは要求の背景を知らないまま、無理難題や無駄を含んだ要求を元にして開発しなくてはならなくなる。世間でよくある「情報システム部門」と「開発ベンダー」の構造になっていく。

社員、パートナーでできることは違うのか?

自分の開発組織は、基本的に「社員だから」「開発パートナーだから」という区別をしないことにしている。

より下流のシステム仕様は開発を担当しているメンバーの方が詳しくなるに決まっているし、新人で入ってきたメンバーが1週間システムを眺めただけで理解できるような代物ではない。

システムに対する要求を現実的なラインに落とし込むためには、現在のシステム仕様を知った上で、その制約事項を具体的に思い浮かべつつ、できること、できないことを切り分けなければならない。上流の業務や要求を熟知したところでカバーできるものではないのだ。

ということは、システムを維持・運用していくためには、社員であろうとパートナーであろうと、システムの仕様を知るための行動をしなければならない。また、システムの仕様をよく知るパートナーは上流の要求を噛み砕いて要件に落とし込む行動をしたほうが、全体最適につながる。

要するに「社員だから」「パートナーだから」という理由で、どの工程を担当するか、何の役割を担うか、ということを決めてしまうと、極めて非効率な個別最適しか生まれないのだ。

究極的に言えば、社員など開発組織にいてもいなくても変わらないのだ。

「社員」とは何なのか?

となると「社員」は何をすべきなのか疑問になってくる。ちょっと考えてみて欲しい。社員とパートナーは一体何が違うのか。

 

大前提として社員とパートナーは所属している会社が違っており、それぞれ個別の目標を追って業務を遂行している。要するに負っている責任が違うのだ。ただここで勘違いしてはいけないのは「責任を持てる」ということであって「責任がある」ということではない。

例えばプロジェクトでリスクのある判断をしたい場合がある。この時に、責任を持てるのは社員であり、パートナーは責任を持とうとしても持ちきれない。そういった「リスクがあるが責任を持つ人が判断しなくてはならない」という局面で「社員」しか持てない力を発揮することができるのだ。

 

これは言い換えると、リスクがある場面など判断が迫られる場面以外で「社員」という存在が特別な力を発揮することはできないのである。ちなみにその力を発揮するためには、的確にリスクを判断する力が必要となる。入って数ヶ月の若手が、簡単に判別することはできないのである。そういった能力をつけるためにも社員、パートナーを問わずにシステムの全貌を知り、またお互いに歯に衣着せぬ物言いができる関係性を作らなくてはならない。

 

「上流は社員、下流はパートナー」といった旧来の情報システム部門が採用してきた、日本ならではのどうでもいい関係性は今すぐ捨て去るべきだと自分は思っている。

開発プロジェクトはアートではないか、とよく思う

失敗するプロジェクトのPLはどう振る舞うか?

色々な開発プロジェクトに携わり、いちチームやプロジェクト全体をドライブする役割を何度か経験させてもらった。今の会社に入社してから、そういった機会を与えてもらうことも多く、色々な玄人達のプロジェクトのドライブ方法を学ばせてもらう中で、自分なりの美学が出来上がってきた。わかる人にはわかると思うのだけれども、プロジェクトは「単純」「明確」「完結」なものの方がより良く、逆に「複雑」「曖昧」「冗長」なものは失敗すると思う。

どんなプロジェクトでも最初は「複雑」「曖昧」「冗長」な場合が多いのだが、それをいかに「単純」「明確」「簡潔」な構造へ持っていくか、というところが勝負ポイントではないか。

失敗するプロジェクトのPLはその構造を理解せず、本来シンプル・単純化できるものを複雑なものとして捉えてしまって場当たり的に対応してしまい、終わりのない無限ループに入ってしまうように思う。

 

今日目撃した事例を紹介しよう。

 

「要件定義がなぜかうまくいかない。課題を潰しても潰しても、モグラ叩き状態で考慮しなくてはいけないことが出てくる」

「人によっては手が空いてしまって、うまく作業を割り当てられない」

「場当たり的に作業を割り当ててしまって、最終的に何を作れば要件定義が終わるのかわからない」

こういった状態に遭遇したときプロジェクトのアート性を理解していない人は、丁寧に一つずつ事象へ対応しようとする。例えば課題管理や進捗管理を厚くし、ひたすらタスクをディスパッチし始める。しかしそれは当にモグラ叩きであり、根本的な対応にはならず、プロジェクトは遅延していく。

 

何を理解してどう振る舞えばいいのか?

今日この話を聞いた時に瞬時に思ったのは「あぁ、プロジェクトの全体構造を理解していない弱者がまた現れてしまったか」ということ。世間一般的なプロジェクト管理手法が世の中には溢れており、それを盲目的に信じて実践してしまう人がいる。

できないコンサルはフレームワークを多用するが、そのフレームになぜ帰着したのか深慮して利用するのではなく「世の中で一般的に正しいとされているから」という”思考の逃げ”の結果でしかない。これと全く同じだ。

 

理解すべきはプロジェクトで働く力学であり、その力の流れに逆らわずに如何にシンプルに終わらせていくか徹底的に考えなくてはならない。その力学とは、人間が集団で働いた時に発現する習性であり、個人の感情であり、その結果として発生する問題までも含む。これら発生する構造的な力の流れを具体的に意識し理解する事で、初めて各種プロジェクト管理の方法論が「よくできている」と思えるようになる。

 

WBSは何のために引くのか?ゴールとスコープを決めずにWBSを作る意味があるのか?まして先にスケジュールを作ってしまうことに問題はないのか?

 

プロジェクトはアートである

プロジェクト計画を立てて各種プロセスやルールを一人で打ち立てた時に感じるのは、一種の達成感である。プロジェクトのゴールとスコープに従って、一度自分の中で組み上げた完璧なアーキテクチャだからだ。デザインし、それ通りに物事を動かしていく。もちろんそれだけではうまくいかないため、幾度もプロセスを補正をしていき、最終的に均衡が取れる。

この目に「見えないが感じられる形式美」こそ、私がプロジェクトをアートであると言う理由なのである。毎回同じものは二度とつくることができないアートなのだ。

 

ぜひプロジェクトに流れる力学を理解した上で、適切でシンプルなデザインを行い、プロジェクトを成功に導いてほしい。