ソフトの開発技術には何が要る
実装技術ってどんな技術
実装技術としてまず第一に大切なのは、何をおいても計算言語についての技術ですね。技術というよりも知識と言ったほうが良いですが、使う言語の文法やよく使うライブラリの仕様などは何を置いてもまずは覚えておかないとソースコードが書けません。計算機言語の技術と並行して開発環境に関する技術も必須です、ここが十分に判っていないと、実務としてのソースコードの作成が進みません。ソースコード管理システム、デバッグ方法、バグの報告・追跡システムなど様々な開発環境を使いこなさないと、ソフトウエアの実装が進みません。
実装技術として二番目に大切な事は、綺麗なソースコードを書く技術です。綺麗なソースコードは２つの面を持っています、実行面と視認性の２面です。実行面で綺麗なソースコードとは、ソースコードの実行パスが簡素に整理されていてるソースコードの事です。ソフトウエアに限らず物事はシンプルイズベストの場合が多いです。同じ機能を実現するのに、複雑なソースコードよりも簡素で単純なソースコードのほうが、バグが入り込むリスクも少なくて良いソースコードです。視認性で綺麗なソースコードとは、人が読みやすい配慮が十分にしてあるソースコードです。見やすい段下げがしてあり、理解し易い変数名や定数名が使われていたりというような工夫があると、他の人にコードレビューをしてもらう時にも、自分自身がデバッグを行う時にも、作業の効率が良くなります。
では、綺麗なソースコードを書くにはどうすれば良いでしょうか？ 実は言葉を覚えるのと良くにていて、綺麗なソースコードを書けるようになるには、綺麗なソースコードを大量に読むのが一番の近道です。世間一般で綺麗と言われているソースコードを一度見てみると、なるほどと納得する所があると思います。
テスト技術ってどんな技術
ソースコードが書けたらいよいよテストです。まずは単体テストから初めて最終的にはシステムテストや妥当性検証まで、様々な段階のテストが始まります。ところで、最近のソフトウエアの開発では設計や実装に比べてテストの難しさや重要性が高まってきているのですが、皆さんはどのように感じておられるでしょうか。
フトウエアの規模が大きくなると、全部のソフトウエアを自社で開発するのが無理になるので、社外から買ってきたりオープンソフトウエアを取り込んだりと、自社開発以外のソフトウエアも使って全体のソフトウエアを開発するようになってきます。 自社で開発する部分は設計や実装が要るのですが、買ってきたりオープンソフトウエアを採用したりした部分は、設計や実装は要りません。ですが、製品として品質を保証するには、買ってきたりオープンソフトウエアを使ったりした部分についても、テストをしなければなりません。つまり、ソフトウエアの大規模化は実はテストの大規模化に繋がっているのです。そして、大規模化したテストは規模が大きいというだけでテストの設計も実行も難しくなってきています。
話が少しそれましたが、設計や実装に比べてテストという作業が今難しい領域に入りるるあるという事は間違いないと面ます。大規模で複雑なテストを実行するには、まずテストの目的を明確にする必要があります。テストカテゴリとよばれるテストの分類方法を使ってテストの目的を明確にし、その目的に沿ったテストの設計をするというテスト設計の技術事が大切になってきます。
また最近ではシステムとシステムとが連携する事で新しいサービスが生み出される場面が増えてきています。装置や機器が単独で使われる事は少なく、何かと繋がって色々な機能を提供する現在では繋がって動く事までテストをする必要があり、システムインシステム、でのテストの技術も必要です。
また、昔からあるのですが２つ以上の機能が同時に動作する競合動作時に多くのバグが潜んでいるので、競合動作でのテストは十分に必要です。しかし競合動作のテストを総当たりでやると組み合わせの件数が爆発的に増えてしまい、現実的なテスト期間では終われなくなります。組み合わせの数が大きいテストで、どこをどうやってテストを間引くのか、このあたりは昔から色々なテスト設計の技術が検討されてきています。
テストの技術はこの１０年ほどで大きく変わってきています、皆さんもぜひ最新のテスト技術に目を向けて、世の中の新しいテスト技術を貪欲に取り込んでいって下さい。
管理技術ってどんな技術
設計技術、実装技術、テスト技術が実際にソフトウエアを作るための直接的な技術だったのに対して、管理技術は設計・実装・テストを計画通りに進めて目的に到達するための間接的な技術です。ソフトウエアの場合は工場での製造という工程が無くて、設計・実装・テストをまとめて開発と呼ぶ事が多いので、管理技術も開発管理技術と呼ばれる事も多いです。
管理技術は計画どおりにソフトウエアを仕上げるための技術で、３つの柱があります。１つ目の柱は、しっかりした開発計画を作る技術です。どんな社内体制で開発を進めるのか、必要な技術/機材/人員は何か、完成時期は何時か、機能/性能/品質の目標は何か、開発の途中で解決いしなければならない課題は何か、などを明らかにした開発計画書がまずは必要です。良い開発計画書とは、目標がはっきりしていて達成の状況が監視し易いものです。良い開発計画書を作るには、開発計画書の作成技術が必要と言って良いでしょう。
２つ目の柱は監視の技術です。計画書ができたら、次は計画どおりに開発が進んでいるかどうかを確認する技術が必要です。ところでソフトウエアの開発では何を監視するのでしょうか？ 最初に思いつくのは開発工程の進捗です、設計・実装・テストが日程どおりに進んでいるのかを監視します。ガントチャートによる工程表を使ったり、マイルストーンの到達状態を監視したりと方法はいろいろです。では、工程以外に監視する項目は何があるでしょうか？
実は、計画書に書いてある項目は全てが監視の対象になり得ます。開発費用だったり、レビューの実施回数だったり、バグの検出数だったり、テストの項目数だったり、開発計画書に書いてあって、測定ができる全ての項目は監視対象とできます。 ただし、全ての項目を監視する必要はありません。その開発プロジェクトにとって大切な項目のみを選び出して、それを監視するので十分です。
計画書の色々な項目を監視していればそれで開発管理ができているかというと、ここまででは５０点です。管理の目的は、計画どおりの物を作る事なので、計画からのズレが起きている事が監視で見つかったら、そのズレを直すアクションを実行する事が重要です。例えば、設計の工程を監視していて、工程遅れが２週間と判明したら、その工程遅れを挽回する方法を考えて実施し実際に工程遅れを挽回する、そのうえで残りの工程を計画通りの日程でソフトウエアを完成させるのが、開発管理の目的です。
この、計画からズレた時にどうやって最初の計画に戻すのかというのが、開発技術の３つ目の柱です。実はここが一番難しい所ですが、計画からのズレを挽回するのと今後ズレが再発しないようにする対策を、開発リーダ一人に押し付けるのではなく、組織として対策を考えて実行する体制ができているかどうかで、開発管理の技術が在るか無いかが大きく分かれます。
ソフトウエアの開発技術 の概要は判りましたでしょうか？
グータラ親父の考える開発技術について概要を紹介してきましたが、まあこんな考え方もあるのだな～程度で読んでいただければと思っています。
ここで紹介した個々の開発技術について、もう少し突っ込んだ内容を個別の記事として書いていって、この分類を充実させていく予定でいるのですが、、、他にも書くのが溜まっていてなかなか進みません。記事が書けたら、この下に具体的な記事のリストが見えるようになりますので、興味のあるかたは参照ください。