AsaHP
開発手法
長いプログラムのコードを開発する方式には、ウォーターフォール型、反復型・スパイラル型、アジャイル型の３種類がある。特に問題がない場合は反復型・スパイラル型を選択すべきだ。安定性と柔軟性を兼ね備えた手法で、どんな状況でも開発しやすい。ウォーターフォール型には柔軟性に大きな問題があり、アジャイル型は不安定になる可能性がある。残念ながら反復型・スパイラル型は他の2つと比べて有名でない。
他に開発ツールを全面的に使う超高速開発・ローコード・ノーコードがある。これらは開発ツールの利用によりコード開発を最小またはゼロにしている。近年では開発ツールが非常に多く存在するので、可能ならこれらを使った方がいい。ビジネス・運用側から見たDXやDevOptという方法論も、開発ツールの発展と密接に関係している。
中規模以上のソフトウェアの開発管理は小規模の場合とは質の違う手法が必要になる。人員等を含めたリソースの配置を階層的に行い、中核部分と周辺部分を分けて開発しなければならない。
実績のある別ソフトを中核部分に使えば高品質が望める。企業向けの作り込みを行う場合はこの方が望ましいだろう。しかし汎用製品の作成だとメリットが低くなってしまう。誰でも容易に作れるため競争力は低く、中核部分の機能も自由度がなく開発しにくい。結局開発自体は行えても営業時に苦労する可能性がある。
自力で中核部分を作る場合、重要なのは有能な人材を集中的に配置する事である。この部分の質が開発全体の質を決定する。開発計画も中核と周辺を分け、中核部分を先行して作成する必要がある。残念ながら日本のソフトウェア開発ではこのような人材を集める事が難しく、汎用的な大規模ソフトウェア開発自体が少ない原因になっている。
DXやDevOptに関しても、日本の現状では実現困難である。日本のIT人材はIT業界に集まっており、一般企業のIT能力が低い。これはSE企業による囲い込み・多重請負・無駄なシステム開発などの要因になっている。一般企業でのIT人材募集や教育などにより、ITの能力を高める必要がある。
工数の見積もりと進捗管理
工数の見積もりは経験のある開発者が感覚的に行うしかない。ファンクションポイント法という有力な見積もり方法もあるが、計算単位である機能（ファンクション）の抽出は感覚的に行うしかない。特に前例のない開発の場合は予測できない問題点が数多く発生するため、機能を列挙しても十分とは言えない。結局は経験と感覚が頼りだ。
重要なのは問題点をいかに抽出するかと言う事である。ソフトウェア開発は複雑で必ず問題点が出てくる。問題点がなければ単純作業に近く工数を見誤る可能性は低い。管理者が問題点を無視すると最悪の結果になる。常に問題点を抱えながら解決して行くのが、正しい進捗管理方法である。
予測が難しい場合は、前述のスパイラル型などで開発スパンを短くすればいい。例えば1年の開発を半年ごとに区切れば、問題点の見通しは遥かに楽になる。
ウォーターフォール型
古典的な工程管理方法で、設計・開発・テストを順番に行う。メインフレームの時代は一応機能していたが、根本的に仕様バグが残るため最近は利用頻度が減っている。
問題は検証が後回しになる事だ。大規模であるほど開発期間は長くなるため、問題が先送りにされて最終的に行き詰る事態が多発した。回避するには設計の段階で十分な検証が必要だが、まだ動かないソフトに対して検証するのは困難である。
分散化やWWWの普及で開発のスパンが短くなっているというのも人気のない原因だろう。数か月単位の開発なら問題ないが、数年単位の開発をこの方法で行うのは避けるべきだ。
反復型・スパイラル型
反復型の方がスパイラル型より意味が広いが、ほぼ同じ手法である。
最も安定した工程管理方法である。一定のスパン（１か月〜２年程度）で設計・開発・テストを繰り返す。ウォーターフォールに対して優位なのは検証が後回しにならない事だ。短いスパンで実際に動くプログラムを検証するため、仕様バグが先送りにならない。特に大規模な開発ではこの方法を利用すべきだ。
スパイラルという言葉はPDCAサイクルに関係していると思われる。AはPDCとは意味が違い、PDCをやり直して周回する事だ。Aの部分で今までの円を外れて向上するため、スパイラルアップと表現される。おそらくここからスパイラル型という言葉が生まれたのだろう。
期間が短い事と開発を繰り返す事を除けばウォーターフォールと同じなので、今までの開発者にも馴染みやすい。途中で動くソフトをもらえるので利用者も安心できる。まずはこの方法を検討するのがいいだろう。ただし近年では以下に記載したツールを使った高速な開発手法が広まっており、ツールが使えるならその方が良い。
アジャイル型
スパイラルよりもさらに開発スパンを短く、数週間にした工程管理方法である。この長さだとウォーターフォールと同じ方法では間に合わないため、より高速化できる様々な手法を取り入れる。設計文書を極限まで削り、文書でなく動くソフトで利用者に確認を求める。特にWebサーバ上での開発には適しているので利用が増えている。プログラムを「早く」作るよりも、常に修正し続ける事が主目的である。継続的な打ち合わせとテストが非常に重要になる。
幾つか注意しなければならない点がある。最大の問題点は利用者がすぐに検証できる事を前提にしている所だ。開発から利用までが遠い、組み込み機器やゲームや数値計算などでは難しい。Webサーバのように利用者がすぐに利用できる状況は特殊だと考えるべきだろう。
テスト駆動（自動テストなど）とリファクタリング（完成後のソース整形）は必須である。これらを行わないとデグレードやソースの冗長化が起こり手に負えなくなる。
アジャイルの高速性から、これを乱雑な開発手法と見なすのは誤りである。アジャイルの推進者は乱雑な開発をカウボーイコーディングと呼び明確に区別している。サッカーで例えるなら、ゴール前にボールを放り込む乱雑なサッカーと、統率され高速でパスを回すサッカーの違いだ。速いという点だけは同じだが次元の異なるものだ。開発者には高い技術力と統率性が要求され、簡単にできる方法ではない。自分たちの技量や開発対象の適合性をよく考えるべきだ。
アジャイルでは開発ツールによるコードの削減は必ずしも考慮されていない。これもアジャイルにおける問題点である。開発ツールの利用が可能であれば、以下に述べるような最新の手法を取った方がいい。
超高速開発・ローコード・ノーコード
超高速開発はソースコード作成からテストまでを含む全面的な開発ツールを使って、とても高速に開発する手法である。フルスクラッチ開発とパッケージ利用の中間に位置し、パッケージの一部に作り込みを行う手法に近い。開発ツールに全面依存するため、上記の開発方式とは毛色が違う。ローコード・ノーコードも似たような手法であり、プログラムのコードを最小あるいはゼロにして開発を行う。近年では非常に多くの開発ツールが作成されており、利用もしやすくなっている。
昔からあるCASEツールの発展形であり、FileMaker、Access、Salesforceなどの有名ソフトによる開発も含まれる。開発速度や品質は明確に向上するので利用価値は高い。開発ツールの価格にもよるが、開発コストも安上がりになる。
最大の問題は、開発ツールに合う開発しかできない事である。開発ツールから外れて作り込みを増やしていくと、開発ツールを使う意味がなくなってしまう。万能ツールではないので割り切りが必要になる。また開発ツールに対する知識を習得しなければならない。ただし開発手法に対する知識はどの開発でも必要なので、超高速開発が他より難しいという事はない。
DXとDevOps
現在流行しているDXは、ビジネスをITにより変革するという考え方である。これは開発よりもビジネス・運用側の見方だが、上記の開発手法とも密接に関係している。近年ではWebやPRAに関して非常に多くのツールが作成されており、これらを利用する事で簡易的にIT化・デジタル化が実現できるようになる。
DevOpsはアジャイルの進化形であり、開発と運用を一体的にする手法である。アジャイルを実現する上で開発・運用の一体化が非常に重要なため、その部分だけが別の手法となった。DevOpsについては管理ツールの利用が重要になる。
DXとDevOpsは、ビジネス・運用側の見方である点と、ツールを使う点が共通している。開発ツールを含む様々なITのツールを使い、ビジネス・運用レベルまで一体化して考える事が重要になる。
