システム開発はなぜ難しいのでしょう
当たり前のことを、当たり前に実行していれば
当たり前に、当たり前のものが、当たり前に完成します。
でも、その当たり前ができない！
なぜでしょう？？？
それは・・・・
当たり前が、当たり前ではないからですね！
当たり前は、当たり前にはできない！
だから難しい！
これが結論！
で、終わってしまっては夢も希望も無いので、「当たり前」について、もう少し考えてみましょう。
そもそも「当たり前」って何でしょう？
一般的な当たり前は、世の中に山のように溢れているシステム開発標準です。
この標準とは、これまで多くの人たちが多くの時間をかけて積み上げてきたナレッジをまとめたものです。
それを真面目に守っていれば当たり前が実現できるはずです。
まずは、この標準をちゃんと理解しているか、ちゃんと守れているかを確認しましょう。
そのうえで、個々のプロジェクトの特性に合わせてテーラリングすることを考えるべきです。
テーラリング：この言葉の意味が解らない時点で、標準ではない、つまり当たり前ではないので、まずはここから当たり前を目指しましょう。
特にPMBOKは標準中の標準なので、最低限、数回は目を通しておきましょう。
もちろんPMBOKだけでは「当たり前」は実現できません。
それでも、ゴルフの迷言に下手な練習、すればするほど下手になるという教えがあるように、理にかなっていない独自の理論で突き進めると、悪い癖が固まってしまい、ある特定の条件ではうまくいっても、その適用範囲は、ごく狭い範囲になってしまいます。
つまり、応用は基本ができてからということですね。
そして、その基本こそが、「当たり前」ということで、この基本を理解し、当たり前に近づけるための工夫を考えて行きましょう。
当たり前に、できるだけ近づけるための工夫
システム開発で、当たり前が難しいのは、次の３つのどこかに問題がある場合です。
（１）要求側が要件内容を正確に漏れなく開発側に伝える
（２）開発側が伝えられた要件内容を正確に漏れなく受取る
（３）開発側が受取った要件内容に従って正確に漏れなく製造する
中でも特に（１）と（２）、つまり開発工程の上流部分が重要です。
プロジェクトの３要素としてＱＣＤがありますが、上流工程ではＱ（品質）を、下流工程ではＤ（納期）を優先すべきで、そのためのＣ（コスト）配分を考慮する必要があります。
つまり、上流工程では品質を優先し、時間と費用をかけて可能な限り高品質な成果物を目指します。
逆に、下流工程では、すでに高品質な設計書があるので、あとは、淡々と単純な変換作業を効率的に進めることになります。
上流工程での当たり前
それでは、上流工程で、当たり前に品質を担保するためは、どうすればいいでしょう。
そのために、まず考えることは、要件の元となる業務を正しく理解することです。
ただし、元となる業務自体に欠陥がある場合、いくら正確に理解しても、思い通りのシステムを開発することはできません。
欠陥とまではいかなくても、無駄な処理、単純化できる処理、共通化できる処理、効率化できる処理などがあればシステム化を契機に見直すことを勧めましょう。
実は、システム開発には、業務改善を担う役割もあるのです。
その最たるものが、抽象化技術やモデリング技法で、これらは業務改善に欠かせない重要な技術です。
これも、標準の一つなので、是非身に着けてください。
業務改善の工夫
まずは、抽象化技術やモデリング技法を駆使して、業務を分析します。
特に、次の５Ｗ１Ｈの視点を考慮すると良いでしょう。
（１）入力情報（What）
（２）処理（How）
（３）出力情報（Why）
（４）タイミング（When）
（５）担当（Who）
（６）機能（Where）
ＤＦＤなどでフロー図にしても良いですね
また、構造化技法やオブジェクト指向、データ中心アプローチ（ＤＯＡ）など様々な標準があるので、活用しましょう。
次に見直す業務のポイントとして、いくつか考えてみます。
シンプル化
まず最初に考えることはシンプルにすることです。
複雑なものを管理するには複雑な管理ルールが必要になり
複雑 x 複雑 で複雑さが爆発し、手が付けられなくなる危険があります。
たとえば
・複雑なマニュアル
・複雑なチェックリスト
・複雑な様式
・複雑なルール
そこで、シンプルにするには２つの方法が考えられます。
ひとつ目は、1回に扱う要件を少なくすること
１個や２個くらいの要件であれば、間違ったり漏らす確率はかなり小さくなります。
現実的な方法としては、アジャイル開発のように1つのイテレーションのバックログを極力小さくして反復的に要件を追加してゆく方法です。
業務間の関連がシンプルになり、管理も楽になり、自己統制力が強化されることで、チームの成長を促進します。
また、1回のイテレーションで、開発の重要な工程（設計～実装）を一通り通すことができるので、工程ごとの課題が早期に発見できるようになります。
ウォーターフォール型のように、時期ごとに要員の数や必要スキルの変動が大きくなったり、最終段階で、プロジェクトの課題が露呈して手戻りになる危険も回避できます。
さらに、ウォーターフォール型のように、遠い未来を予測するより、部分的な完成でも直に目にすることで要求側と開発側の齟齬を回避できるようになります。
ふたつ目は、分割すること
複数の業務と複数の業務が互いに関連しあうと、その組合せは指数関数的に爆発し、複雑化して行きます。
まずは、関連を断ち切りましょう！
構造化技法やオブジェクト指向、ＤＯＡなどは、複雑化の解消に役立つ考え方です。
分割の良い例はソートアルゴリズムの中のクイックソートで利用されている分割統治法です。
単純なバブルソートよりも効率的にソートができます。
分割することで、問題領域を限定できるので、シンプル化にも寄与します。
たとえば、問題領域が小さい単体試験のうちに、ある程度バグを潰しておくことで、結合試験などで組合せが爆発するのを回避できます。
つまり、結合レベルで取りうる値の組合せをそのままテストケースにしてしまうと、膨大な組合せをテストしなければなりませんが、単体試験でクリアした点は結合試験では省略し、膨大な組合せを費用対効果による省略したカバレッジを許容することができるようになります。
ただし、オブジェクト指向には、せっかく、このような問題の限定化や設計から製造までをシームレス化できる仕組みが用意されているのに、それを損なう使い方をしている例が多くみられます。
オブジェクト指向を利用するときは、本来の意味を理解して、当たり前の使い方を心掛けてください。
業務の最適化
次に、業務を最適化します。
業務を分割整理することで、業務の無駄や共通化できる個所などが見えてきます。
さらに、業務を抽象化することで、業務の理解が進み、最適化策を見つけやすくなります。
構造化技法やオブジェクト指向、ＤＯＡなどは抽象化のための考え方でもあるので、上記の分割から抽象化をシームレスに行うことができます。
抽象化には様々な方法がありますが、特にオブジェクト指向には、インターフェースという抽象化をスムーズに行う仕組みが組み込まれているので、正しく使いましょう。
また、構造化技法でも「機能」という概念は業務側とシステム側を繋ぐ役割があるので、これを正しく使うことで抽象化をスムーズに進めることができます。
抽象化やオブジェクト指向については、こちらの記事も参考にしてください。
https://qiita.com/J_Cotan/items/eedec30843681f67e4e4
https://qiita.com/J_Cotan/items/3e28ee4cd52e2e2f199e
プロジェクト管理の工夫
次にプロジェクト管理での見直すポイントとして、いくつか考えてみます。
プロジェクト管理でも前述のシンプル化や最適化は同じ考え方になります。
開発工程を分析し、分割し、抽象化して最適化を目指します。
構造化技法的な視点で考えると、次のような工程で最適化を目指します。
（１）現行物理モデルの作成
（２）現行論理モデルの作成
課題の抽出
（３）新規論理モデルの作成
改善策の考案
（４）新規物理モデルの作成
抽象化することで、課題や改善策を発見しやすくなります。
自動化
次に自動化について考えてみます。
定型的で単純な作業は自動化に向いています。
逆に、人間が判断するような曖昧さが残る作業やイレギュラーが多い作業には向いていません。
このように無理に自動化することで、逆に効率を低下させたり、保守業務が増大して役に立たなくなる場合があるので注意が必要です。
さらに、最適化されていない作業を自動化すると、非最適な結果を量産してしまうリスクもあります。
標準化
最後が標準化ですが、前述のシンプル化でも説明しましたが、シンプル化や最適化がされていない標準化は次のような問題を引き起こします。
・大量の複雑なマニュアル
・大量の複雑なチェックリスト
・大量の複雑な様式
・大量の複雑なルール
まずは、シンプル化や最適化を十分行ったうえで標準化を考えましょう。
標準化は、チーム内の標準化だけでなく、社内やグループ単位で標準化することで効果が倍増します。
個別最適化から全体最適化の話になります。
つまり、自チームと他チームとでノウハウなどを共有できるようになります。
また、他チームと同じ物差しで比較できるので、自チームの成長度や課題も把握しやすくなります。