プロセスって大事です - 工程は課題を解決する単位 -

若手エンジニアKさんの作業報告

先日、若手のエンジニアの作業報告を聞いていると、

ざっくりですが、次のような話がありました。

• 上司の指導に基づいてた作業手順で行った
• 作業を進めづらい点があった
• 進めづらい点は考えるのをやめて、後工程での対応が妥当と考えた
• その工程では、できるところまで進めて完了とした

「あぁ、これだと、この後、手戻りで混乱してゆく可能性があるな」と感じました。

作業上の障害があり、別のタイミングで解決する方が論理的に正しいと判断することは、良いことだと思います。
進め方の変更が必ず駄目な訳ではありません。

でも、駄目だと言えるケースもあります。

なぜ、こんな指摘をするのか、掘り下げていってみたいと思います。

工程は、どの開発プロセスにもある

実は、このケースでやめてしまった考えることは、その工程で解決すべき課題だったのです。

まず、上に「上司の指導に基づいてた作業手順で行った」とあります。
今回の場合は、開発のエンジニアなので、開発の手順です。

開発の手順は、「開発プロセス」と呼ばれます。
プロセスは、大まかにいうと、上流から下流に向けて「工程」を実施していきます。

ざっくりと絵にすると、こんな感じですね。

「分析工程」「設計工程」．．．のように、工程が順に並んでいます。

この絵をみてパッと「ウォーターフォール開発プロセス」を思い浮かべるのではないでしょうか。

ウォーターフォールが悪いというイメージから、工程をしっかりと進めなくてもいいとの考え方もあるかと思います。
私も純粋なウォーターフォールはしませんが、
だからと言って、「アジャイルで作りながら仕様を詰めていけば良い」なんて話を聞くと、関心できません。
仕様担当者やシステムの開発を依頼する人は、開発者のそんな話を聞いて喜んでいますが、
その実、9割以上の人は、後で痛い目を見ていると思います。

アジャイル（＝俊敏）プロセスを選ぶことは良いのですが、「工程」を使わないのは、
大きな誤りだと思います。
いわゆるアジャイルのプロセスでも「工程」の繰り返しかたが違うだけで
「工程」を使うことに変わりありません。
「開発プロセスの違い」は、「工程の繰り返しかたの違い」とも言えます。

まずは、この誤解を解いて頂いたところで、次の話に行きたいと思います。

※（参考）
　ここでは、できるだけ難しい言葉を避けて、プロセスと工程という言葉で代用していますが、
　ここでいう「（一連の）工程のつながり」を「ミクロプロセス」、
　ウォーターフォールやイテレーティブやスパイラルなどを、「マクロプロセス」
　と呼ぶこともあります。

「工程」って、なぜ分かれているのか？

そもそも、工程ってなぜ分かれていると思いますか？

開発プロセスの標準化で、生産性が上がるんだとか言って、ある組織が推進しているからでしょうか？

工程は、
物事をスムーズに進めるためには、次のようなポイントを押さえてゆくと良い
という先人たちの経験から生まれたノウハウなのです。

重要なコアになっているのは、次の2点です。
・目的と手段をわきまえよう
・一度にいろいろな問題に取り組んではいけない

「目的と手段を取り違えてはいけない」は、よく聞く言葉ですね。
分けて考えるべき、分けて取り扱うべきだ、と言います。
でも、それを分けて考えて扱える人は、世の中に少ないと思います。

「ひとつずつ解決していこう！」も、よく聞く言葉ですね。
ひとつずつ終わらせてゆけば、思った以上にスムーズに事が運んだ経験がある人は少なくないでしょう。
それでも、余りに忙しいと、同時に複数のことに手を付けてしまいますよね。

ここまで、よく聞く話であっても、実際に何かに取り組むときに、
これらを実践できている人は、あまり見かけません。

でも、その分野の「仕事のできる人」にはできているようです。
その知見・ノウハウを元に、その分野の仕事を、わずかな手戻りで実施できるようまとめたのが「工程」なのです。

いろいろ分けた方がスムーズだという知見を活かした結果、作業の全体が工程に分かれているのです。

では、少し具体的に見ていきましょう。

開発の基本的な工程を見てみる

分析工程と、設計工程と、実装工程について考えてみましょう。

分析工程とは、作りたいものの姿を理解すること。つまり製品の要求仕様ですね。
設計工程とは、作りたいものを、作るためにどのような工夫をするのかを検討すること。例えば、非常に高速なシステムを構築するにはどんな工夫をすればよいのかを検討すること。これも設計ですね。
実装工程とは、作りたいものを、どのような工夫をするかで決めたとおりに、形作ること。これが実装ですね。

耳の痛い話かもしれませんが、作りたいものの姿をないがしろにしたまま、なんとなく「こんな技術が必要だろう」とか言って、そのサンプルを手に入れて、それをモディファイして、開発するシステムの外枠や実装方法を決めたりしていませんか？
その状態で、要求を取り込んでいこうとしたら、なんか難しいとか、速度が出ないとか、なっていませんか？

分析工程は、開発するシステムが実現する姿を明らかにします（＝システムそのものの目的）
設計工程は、開発するシステムが実現する姿を、実現する構造を明らかにします（手段）
実装工程は、設計工程で決めた「実現する構造」を実現する手段です（手段）。

初めから作りたいものの姿を理解して、どんな工夫が必要なのかを理解して、その適切な工夫を検討し、あとは考えたとおりに構築していったら、、、なんかあっさりと進みそうじゃないですか？

このように、大切になる「目的」側から、まず解決すべきことを解決し、それが解決したら次の段階に進み、、、、
としてゆくのが工程の連なりです。

各工程は、目的と手段、手段が決まるとその手段を（目的として）実現する手段、またその手段が決まると、、、
という連鎖的な関係になっています。

工程の連なりは、その目的と手段の階層を、上流から順に一つ一つ解決してゆく経験と知識をまとめたものが
「その分野のプロセス」として存在しているのです。

繰り返しになりますが、これを、先人たちがどのような課題から先に解決してゆけばよりスムーズに開発が進むのかを、体系化してくれたのが一連の工程なのです。

ただ単に、（１）概要設計をします、（２）詳細設計をします、（３）実装します、
とか、形だけやっているとしたら、そりゃ、先人たちの知識と経験の恩恵を受けられないわけです。

これが、
・目的と手段をわきまえよう
です。

工程の中にも細かな工程がある

このように、目的と手段を順序だてて解決してゆくプロセスの工程は、それぞれの工程に解決すべき課題を分けてくれます。

では、引き続きもう少し掘り下げてみましょう。

「工程」が一つの課題と言いましたが、実は、その「工程」の中でも、大きな一つの課題を解決するために、
小さないくつもの課題を解決していきます。
これらの小さな課題もまた、大きな工程と同様に、適切な作業の順番があります。

大きな「工程」だけを知って、その「工程」で課題を解決しようとすれば、多くの大小の課題に向き合います。

それを、どれから手を付けていいかわからないし、できるところから始めていったら、
なんだか、開発したいものに近づくことが難しくなっていく、、、なんてことになります。

上述の「分析・設計・実装」のざっくりとした工程であっても、それぞれに解決すべき課題があります。
更に一つ一つの工程の中に入ってみると、
例えば、「設計」の工程には多くの課題があるので、それを一つ一つの細かなステップに分けて扱わせます。
例えば、
・課題を抽出する
・課題を分類し、影響範囲ごとに分かる
・各々の課題への対応策を練る
・対応策を組み合わせる
など、大きな工程の中には小さな工程が入っています。

ソフトウェアの規模にも寄りますが、
・全体構造にかかわる課題の解決方法を解決する
・部分と部分をつなぐ構造にかかわる課題の解決方法を解決する
・部分の非機能要件を解決する課題の解決方法を検討する
なんていう中位の工程もあり得るでしょう。

こんなように、解決すべきことを分けて扱う知見から、細かな工程の１つ１つが作られているのです。

一度にさまざまな課題に立ち向かおうとすると、
あちらを立てればこちらが立たず、こちらを立てればあちらが立たず、
となってしまいます。

これが、
・一度にいろいろな問題に取り組んではいけない
です。

ソフトウェア開発だけでない、段階的な課題解決

では、最後に、客観的にみられるように、建築の例でも見てみましょう。

例えば、家を建てるときに、「部屋割りを明確にする工程」と「骨組みを作る工程」と「壁を作る工程」があったら、それを同時に進めたらどうなりますか？

• 骨組みを作りながら部屋割りを明確にするならば、良い部屋割りを作ることができますか？
• 壁を作りながら骨組みを作っていくならば、安定した骨組みを作ることができますか？

やはり、家を建てる時だって、
一つの工程には、一つの課題解決があり、解決すべき課題には解決すべき適切な順序があるのです。
それを体系化したものが建築の一連の工程と言えます。

課題解決を同時進行していませんか？

人の振り見て我が振り直せ

「部屋割りを明確にする工程」：使いやすい部屋割りを明らかにする
「骨組みを作る工程」：部屋割りを実現しかつ安定的な骨組みを作る
「壁を作る工程」：壁を作り、部屋を実現する

これらを、同時進行で進めれば、納期が延長され…ますか？ ...されますよね。
または、品質が低下...しますか？ ...しますよね。

プロセスは、順調に開発を進めるための過去の人たちのノウハウの塊です。
より少ない手戻りで進むには、どうしたらよいかという知見が詰まったものです。

一手一手、コツコツと進めることは、無駄な作業ではないかという風潮もあります。
各工程で解決すべき課題をきちんと解決する以上の中間成果物を作り続けるのは、無駄な作業ですが、
各工程で解決すべき課題をきちんと解決するだけの中間成果物を作ることは、スムーズに開発を進めるために当たり前に大切なことです。

最後に

いろいろな都合で、プロセスをないがしろにしてしまう気持ちになるかも知れませんが、
落ち着いて考えたら、プロセスを大事にする方が、ずっと開発をスムーズに終わらせてくれるのではないでしょうか？
ソフトウェアエンジニアのあなたは、
自分の家を建ててくれる建築会社の人が、
壁を立てながら、部屋割りを考えながら、骨組みを作っていってたら、契約解除ものですよね。

なんで、自分でソフトウェアを作るときは、課題を同時に解決することを自分自身には容認するのでしょうか？

本当は、容認すべきでないとは感じているでしょう？

※転載元の情報は上記執筆時点の情報です。
　上記執筆後に転載元の情報が修正されることがあります。

執筆者のページはこちら