2019年07月31日

計画的に進める為には多くの領域に手を付ける必要がある


このブログは基本的には「どうすれば計画通りに行くのか」について述べています。しかし話としては純然たる計画に関するものだけではなく色々な領域に及んでいます。今回はなぜそのように色々な領域の事を考える必要があるのかを説明します。

各領域の説明


ソフトウェア開発には以下の様な領域が考えられます。
このブログの記事の分類も基本的にはこの領域の分類に従っています。計画的に進める為に取り組むべき視点で選び出した領域ですが、実際はほぼ全ての範囲に及んでいるのではないかと思います。

全体の構造

各領域の位置づけは以下の様な構造になっています。
全般
  内容
   外
    企画
    開発
     計画
   中
    仕様
    設計
    製造
   品質
  作業
   人
   機械
  環境
 文書知
  規程
  資料

意味としては開発「環境」の上で人と機械(ツール等)が開発「作業」をして「内容」を作り上げるという事を意味しています。「内容」は何をどのように作るかという「外」側と実際に作るソフトウェア自身の技術的な「中」身に分かれます。そしてそれらの活動は全て「文書」に蓄えられたノウハウ(「知」)に従って行われます。(文書知の詳細は以下で説明します)
次に各領域の説明をします。

全般

全体にわたる事や基本的な考え方等です。

企画

開発より前の工程全てです。つまり「何を作るか」を決める事です。従って個別の製品企画だけではなく事業企画のようなものも含まれます。

計画

一般に言うプロジェクト計画、プロジェクト管理などの計画の立案や推進だけではなく、時間に関するもの全てです。

仕様、設計、製造

一般的な意味合いの仕様、設計、製造です。

品質

品質に関するもの全てでテスト等について以外に品質保証活動等についても含みます。
この場合、品質というのは、仕様や設計などの直接的なソフトウェアの構成要素ではなく、それらをいかに問題なく作るかという視点だと言えます。全ての領域において問題を作り込ませない、作り込んでしまったものは確実に発見して退治する事を目指すものです。


物では無く人に関するもの全てです。
人を物と同じように考える事はできません。心理的な要素が多いです。リーダーシップやコミュニケーション等を含みます。全ての事は人間が行う事ですから全ての事に影響があります。

文書知

文書知というのは造語です。どうにもうまい言い回しが見つからなくて仕方なく作りました。
これは何を指しているかと言うと、結局ノウハウというものは人に蓄積させるか人の外(文書)に蓄積させるかのどちらかしかありません。その文書側を指した言葉です。この言葉を使うと開発の全てのノウハウは「人知+文書知」だという事になります。集団においては文書知は重要な要素です。
具体的にはいわゆる「標準」と呼ばれるマニュアル等のルールを定めた規程と、過去の開発時に作成された様々な資料になるかと思います。規程は従わなければならないものであり、資料は参考にしなければならないものです。
属人的になっているノウハウをいかに文書に吐き出して共有するか、つまり「人知から文書知へ」が組織の重要な課題と言えます。

計画的な意味合い


各領域について計画的な視点ではどのような意味を持っているのかを説明して行きます。

全般

基本的な考え方は個々の具体的な事柄を考える際のよりどころとなり重要です。計画について考える時も同様です。

企画

何を作るかを決める事ですから、開発は直接的に大きな影響を受けます。「UIについて-概要」で少し触れましたが、企画が曖昧だとそれを受けた開発ではポリシーが定まらずにヨロヨロしてしまいます。その度に議論が起こり、見直しが発生して、歩みが止まってしまいます。また、「要件は誰が固めるべきなのか」で述べた様に企画と称して仕様を押し付けられたりすれば、そもそも動くものが出来ない可能性もあります。企画担当にとっては「売れる売れない」という視点が重要だと思いますが、開発にとっては「上手く開発できるのか」という視点で重要です。ここで首を突っ込まないと大変な目に遭うのは自分達になります。

計画

言うまでもなく計画的に進める為のメインの内容になります。プロジェクトというのは暴れ川のようなものなので、周囲を計画と言う堤防で固めないととてもコントロールする事はできません。

仕様

プロセスとしてウォーターフォールのように最初の方で仕様を固める場合は仕様に問題があると致命的な事になりかねません。いざプログラムが動くような段階になって大きく仕様を変更するような事があれば計画が守れるはずはありません。また最初の製品開発だけではなくその後のV2、V3…というバージョンアップの開発にも大きな影響を及ぼします。それは互換性を維持しなければならないからです。例えば次バージョンでスペックファイルのフォーマットが維持できなかったとしたらコンバートするしかありません。普通製品のリリース時期というのは開発の事情ではなく経営的企画的要請で決まるものですから、無駄にやる事が増えればそれだけ計画は難しく、大変になります。また作りの上でも複雑になってしまい品質問題を起こしやすくなってしまいます。

設計

仕様程の影響はありませんが、やはり仕様と同じように途中で変更が発生すれば日程を圧迫する事になります。設計に大きく問題があると幾ら作っても品質が安定しなかったり、下手をすると動かなかったりします。また設計が仕様に比べて怖いところはリリース後に問題が発覚する事です。仕様に関しては動かない仕様というものはまず存在しません。例えば「電話番号入力」という仕様で「入力チェックは英字である事」などという矛盾した動かない仕様はあり得ません。良い仕様かどうかは別にしてリリース時には全ての仕様が無矛盾で動くものになっているはずです。ところが設計の場合はリリース時には分からずにリリース後に問題が発覚する事は多々あります。こうなるとトラブルとして割り込み的に対応をしなければならず、「次の開発」の日程を圧迫する事になります。

製造

計画に対する製造の影響はシンプルに品質です。バグを沢山作りこんでしまえばそれだけ日程を圧迫してしまいます。しかし実際は「問題点の対応のプロセスについて」で述べた様に製造の問題は少なく、多くは設計の問題です。

品質

いかなる局面においても問題点を作りこんでしまえば、発覚した時点で割り込み的にパワーを割かれる事になります。従って品質が低ければ計画に深刻な影響を及ぼします。一般に上流工程になればなるほど品質の影響は大きくなります。つまり設計の出来より仕様の出来の方が重要で、仕様の出来より企画の出来の方が重要という事です。


人間というのはプログラムに比べれば色々と不規則で予想外の事が起きやすい訳ですから、人間が関わる内容をいかに安定的にするかというのは計画にとって一つの大きな課題と言えます。また、計画的な意味合いを分かりやすく例えるならば、「人はソフトウェアを作り出す機械」とも言えるので、この機械の性能やメンテナンスに気を配るのは当然の事です。どんなに適切な計画を立てたとしても機械の調子が悪ければ決して達成できません。

文書知

ゼロから始めるのではなく、過去の経験を踏まえて始められればより確実に進められるのは明らかです。問題はそれを個人の中に持たせるのではなく、いかに文書として外に出して利用できるようにするかという事です。属人的で個人頼みになってしまうと、人の組み合わせによってうまく行ったりいかなかったりしてしまいます。こういう不安定な要素を極力排除するのが計画的に進める為には必要な事です。

どのように取り組むべきか


以上の内容を読んでいただくと分かりますが、「計画」自身以外は全て計画立案後に実際に進める際に影響のあるものです。どんなに精緻な計画を立てられるようになったとしてもそれだけでは限界があります。技術的なレベルが低くバグを大量に作りこんでしまえば、計画があっという間に破綻するのは誰しも理解できるところだと思います。
先程プロジェクトを暴れ川に例えましたが、計画が堤防だとすると技術的な中身の要素は川の水そのものです。幾ら堅固な堤防を築いたとしても、それを上回る水量が押し寄せれば決壊してしまいます。ですからそもそも水量を堤防で抑え込める程度の量に絞っておかなければなりません。どちらか一方だけでは成り立ちません。両方の関係性によって初めて上手くいくかどうかが決まります。従って計画的に進める為には計画を立案するという外側の技術を向上させるのと同時に、ソフトウェアを作るための仕様や設計などの中身の技術も向上させなければうまく行きません。この両方が揃って初めて計画的に進める事が出来る様になります。

一覧


メニュー

関連


どこまでが仕様の範囲か
問題点の対応のプロセスについて
売れない小説家のジレンマ


記事を広める



posted by 善 at 20:33 | Comment(0) | 計画 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。