エンタープライズのシステム開発において、複雑化・高度化するシステム要求に対し、QCD を守ってシステムをリリースしていくことは難易度が高く、ソフトウェア開発に対しての成熟度、リテラシーが求められます。このホワイトペーパーではシステム開発における豆蔵のアプローチについて説明し、豆蔵がプロジェクトに参画する意義をできるだけ具体的にイメージしていただくことを目指しています。
業務要件を満たす(Quality : 品質)システムを、予算内で(Cost : コスト)、期日(Delivery : 納期)までに完成させることが求められます。これには必要な資源(ヒト、モノ、カネ)と妥当な開発期間の確保が必要です。
Q と D の間にはトレードオフの関係があります。C を適切なタイミングで適用しないと Q の達成は時間の経過とともに指数関数的に困難になっていきます。日本ではまだ建前のウォーターフォールモデルを捨てきれていないにもかかわらず、仕様確定はプロジェクトの最終局面まで遅延します(1)。プロジェクト終盤に増員しても手遅れなのです。
システムのカットオーバー後も、業務の変化に応じてシステムの振る舞いを変更していく必要があります。変更についても同様に QCD が求められます(2)。
(1) ステークホルダーが多くて調整に難航する、そもそもの業務に不確定要素が多い、など理由は様々です。
(2) 変更に際しては、変えなければいけない部分だけが変わり、変えてはならない部分は変わっていないことを保証する必要があります。当たり前のことなのですが、現実にはリリースしたら今まで使えていた機能が使えなくなってしまったというのはよくある話です。既存の機能が影響を受けていないことを自動化されたテストで回帰的に確認可能になっていればある程度安心できます。
QCD の Q には機能要件の達成だけでなく非機能要件の達成も含まれています。非機能要件には、信頼性、可用性、保守性、安全性、保全性、拡張性、操作性、処理時間・・等々、達成すべき品質特性(3)があります。非機能要件を実現するためには機能要件の実現と同等のコストを掛ける必要があります。
(3) 非機能要件定義書に「応答時間3秒以内とする」などと一文で書かれていることがありますが、これは完全なる思考停止です。データ量、トランザクション量、ピーク時のトラフィックなど、性能に関する品質特性も具体的なシナリオで実現可能性を検討すべきです。
QCD を満たすのは一昔前の OA 化時代より遥かに難易度が上がっています。IT の進化、グローバル化、M&A による企業規模の拡大などを背景として業務システムにもこれまでにない要求が次々と発生しています。システムを統合し柔軟なサービスコンポーネントを提供すること、PC、スマートデバイスなど多様な端末をサポートすること、SNS に対応すること、データサイエンスに取り組みマーケティングやリスクヘッジに活用すること、クラウドネイティブなプラットフォームに対応すること、DevOps に対応しシステムの進化を加速させること・・等々。
業種・業態にもよりますが、企業の存続・成長にとってソフトウェアがこれまでになく重要である時代と言えるでしょう。まさにソフトウェアファーストな時代に突入しています。高度な要求の実現のためには単に「仕様通り動く」業務システムを構築するだけでは不十分です。業務をモデル化してソフトウェアとして実現し、モデルの変化にあわせてソフトウェアを変更できるシステムを構築することが必要なのです。
(4) これには分析能力・抽象化能力が必要とされ、モデリングやアーキテクチャ構築のスキルが必須となります。その上で実現可能性についても検討し方式設計を行うことが求められます。たとえ業務知識に精通していても従来型の台帳入出力システムを構築するスキルだけでは対応できません。
システムの機能・非機能要件を実現するため、適切な技術を採用し、技術の利用方針を決め、開発生産性を高めるためのフレームワークを準備し、機能をどのように実現するのかを決定する必要があります。この過程の成果物がソフトウェアアーキテクチャです。アーキテクチャの検討過程で技術リスクや実現性が洗い出され、開発プロジェクトの後工程で問題が露呈することを予防できます。
アーキテクチャ、コンポーネント「サーバーはクラスター構成、 OS は Linux 、データベース は Oracle、アプリケーションサーバは WebLogic……」のようにハードウェアやミドルウェアを含んだシステム構成を指すシステムアーキテクチャと、ソフトウェアの構造にフォーカスしたソフトウェアアーキテクチャがあります。後者は業務要件に占める「ソフトウェアの比重が高いシステム」には特に重要です(「ソフトウェアの比重が高いシステム」とは、ソフトウェアがシステム全体の設計、構造、導入、および進化に極めて重要な影響を与えるシステムである。- IEEE 1471) 。
本ペーパーでは、ソフトウェアアーキテクチャについて言及しています。RUP 第3版 (統一プロセス)によるアーキテクチャの定義を見てみましょう。
"アーキテクチャとは、ソフトウェアシステムの構造に関する「一連の重要な判断」「構造要素」の選択、そしてシステムを構成するインターフェイスに加え、これらの要素間のコラボレーションで明記されたその「動作」、徐々に大型化するサブシステムへのこれら要素の「組み込み」、そしてこの構造の指針となる「アーキテクチャスタイル」である。つまり、これらの要素とインターフェイス、そのコラボレーション、そして構成である"
アーキテクチャの構成要素であるコンポーネントについては、かつて、再利用を促進するということが喧伝されたことがあります。確かに再利用できればいいのですが、どちらかというと変更を容易にする、拡張性を確保するという効果に着目すべきでしょう。
業務システムは複雑で多機能になりがちです。このため多くの開発者によって大規模なコードが書かれることになります。だからこそ構造設計が必要不可欠なのです(5)。アーキテクチャはシステムの構造を表現し、開発者の理解を助け、機能を追加したり仕様を変更したりする際の地図・道案内になります。アーキテクチャは、開発者がソースコード書く際のルールも提供します。これはコストやスケジュールを検討する上での手がかりにもなります。
アーキテクチャがないと、指針なく場当たり的にコードを書いていくことになるので、構造が安定せず、常に開発者が迷う状況になります。その結果、手戻りが多く発生し、開発に時間がかかり、バグ発生率も高まります。理解しづらく実行効率の悪いコードが量産され、保守が難しくなります。ひいては、ビジネス的な損失を招いてしまうことになります。
(5) アーキテクチャは大規模なシステムでしか必要ないのでしょうか？ 数百行のプログラムでも、機能分割をうまく考えて作らないと理解しにくいコードになり、修正が困難になります。優れた開発者は理解しやすいコードを書く上で常に構造設計を意識しています。
アーキテクチャは開発チームの構造や開発プロセス、開発スタイルも規定します。アーキテクチャに則ったシステムを実現するにはそれにあった開発チームの組織化とプラクティスの実践が必要です。昔ながらの非効率なやり方で開発を進めていると QCD を守れない確率が高まります。
一般的な SIer は 21 世紀の現在でも十年一日のような労働集約型スタイルです。経験の浅いプログラマーと経験が浅いままプログラマーを卒業し SE やマネージャと呼ばれる職責になった人達で構成されています。IT に疎いか全く知らないことも珍しくなく、効率の悪い手作業を長時間労働で実施し、ミスを多発します。大手のベンダーであっても状況は変わりません。技術リスクをヘッジすることなくプロジェクト終盤を迎え、デスマーチに突入してしまいます。
ありがちなベンダーとデスマーチエンジニアリング
・構造設計という概念が欠落しており、複雑さを分割して統治するという意識がない
・開発者が基盤テクノロジーを理解せずにコードを書いている
・テストや作業の自動化を考えたこともなく、手作業と気合とか根性で何とかしようとする
・チェック体制がやたらと厳重なのに、品質に反映されない。
・性能や拡張性を考慮した設計・コーディングをできる開発者がいない組織
・WBS と Excel による課題管理だけを生業とする「マネージャ」がいる
・管理職が服務管理ぐらいしかしておらずプロジェクトへの貢献をしていない
・ソースコードと変わらないレベルの「詳細設計書」を延々書いている「設計者」がいる
・その詳細設計書を忠実にコードに落とすだけの「コーダー」がいるその結果…
・場当たり的な設計・実装により欠陥品が大量に製造される
・テストせずにひたすらコードを書いてビッグバン結合テストする
・単体テストレベルのバグが総合テストフェーズに続出
・進捗報告では順調だったはずなのにスケジュール遅延
・カットオーバー直前にも単体テストレベルのバグが出る
・リリース判定でリリース決定できない、受け入れでトラブル
・なんとかカットオーバーしても業務を止めるような障害が頻発する
国内では、コンシューマ向けのサービス事業者が先行的にソフトウェアモダナイゼーションを実践して、高い生産性を獲得しました。コンシューマ市場ではサービスの品質と投入までのリードタイムがビジネスの成否を決する重要ファクターなので、成功している事業者では、テストの自動化に始まり、継続的インテグレーション (CI)、分散 VCS によるソフトウェア構成管理、ITS によるバグトラッキングなどを当たり前のようにシステム化しています。環境構築やデプロイなど従来インフラチームが手順書に沿って手作業で行っていた作業も Infrastructure as Code の進化により、開発チームがコード化して自動構築する時代になっています。エンタープライズの基幹システムでもこれらの開発手法が取り入れられ効率化が進んでいきます。上記のような旧態依然たる開発スタイルに甘んじている組織は競争力を失い、淘汰されることでしょう。
まずは、要件検討から入り、典型的な業務機能を元にアーキテクチャの検討を行います。この段階では多くても数名のアーキテクトで検討を行います。Java や C# などのプログラミング言語を使えるプログラマーを 100 人集めても(6)アーキテクチャは生まれてきません。このフェーズではアプリケーション開発者はまだ登場せず、多くても数名のアーキテクトが知見を持ち寄り、決定していきます。その間技術の評価をしたり、アーキテクチャに基づいて実際にコードを書いて実現可能性の検証(フィージビリティースタディー)を行ったりすることもあります。どのようなエンティティを扱うのか、トランザクション制御はどのようにすべきか、他システムとの連携はどうするか、変更の入りやすい箇所はどこか、期待される性能は・・等々、諸々の機能・非機能要件を踏まえアーキテクチャ目標を決め、実現手段を検討します。この際、典型的な機能や技術リスクの高い機能をターゲットとして検討していくことになります。
アーキテクチャ構築フェーズは、サイクリック、イテレーティブなプロセスが適しています。要件を踏まえ仮説検証型で作業を進めます。このため、業務システムの要件定義フェーズ同様、準委任での活動となります。このフェーズの成果物として、後に参画する開発者や保守担当者向けにアーキテクチャ説明書や参照実装を残します。開発チームがスケールアウトした時に統制を維持するため、構成管理方法や開発環境の構築、イシュー管理などについても方針を決めます。その他コードのフォーマットや収集するメトリクス、開発ツールの細かい設定に至るまで、品質を上げる上で必要であれば実施します。
(6) 豆蔵は量より質を重視し、パートナーを採用する場合も面談を重ね、スキルの高い人を選定しています。従って大量調達は難しいですが、メンバーのパフォーマンスには期待できます。
アーキテクチャかソリューションかベンダーによっては特定の製品・ソリューションを担いで提案をしてくる場合もあります。それらのソリューションの効能をカタログどおりに受け取らないほうが賢明です。殆どの場合はさほど開発効率に寄与しないばかりか、逆に足を引っ張ることすらあります。自社製フレームワークを担ぐベンダーもいますが、陳腐化していたり悪い設計だったりして使い物にならない場合もあります。
豆蔵は特定の製品やフレームワークに拘りません。旬な、評価の高い技術を採用し、効果的にアーキテクチャを構成します。
実際に開発が始まったら、新規参入開発者向けにアーキテクチャや開発手順の説明などのオリエンテーションを実施します。チームの立ち上げにはパワーがかかりますので、実際にコードを書いている側でコーディング、開発ツール・構成管理ツールの使い方など製造活動全般のわたり知識伝達を行います。
スキルトランスファー開発者への技術移転も豆蔵の重要なタスクとして位置づけられます。単に実装方法を伝えるだけではなく背景にある設計思想・意図を理解してもらうことでアーキテクチャの伝承に努めます。技術移転はユーザーであるお客様だけでなく開発や保守を担う他のパートナー会社のメンバーに対しても行います。
情報システム部門やシステム子会社には一時期のアウトソーシングの流れで技術が内部に残らず、顧客の調整や予算に追われているケースが少なくありません。「システムの掌握ができていない」と、空洞化を自覚して相談にみえるケースもあります。このような場合、アセスメントを実施した上でパイロットケースとなるプロジェクトを実施しその中でスキルトランスファーしていくというご支援形態もあります。
開発者が作成したコードのレビューを行い、問題を指摘するとともに改善方法の提示も行います。これにより、開発者のコード品質の向上、後工程で問題となるようなコードの早期排除、開発者のスキル見極めなどを行っています。
レビュー観点静的コード分析で自動的に検出できるものはそちらにまかせ、アーキテクチャ遵守、保守性・性能などの観点でのレビューを行います。
・アーキテクチャへの違反を犯していないか
・適切なクラスの責務分割がなされているか
・クラスの凝集性や結合度は適切か
・実行効率の悪い実装になっていないか
・冗長で可読性の悪い書き方をしていないか
開発が進むにつれて必要に応じてアーキテクチャを修正し、開発者向けのフレームワークを改善していきます。
豆蔵は技術的側面ばかりを支援するのではありません。必要と判断すれば、アーキテクトの立場に拘らず、要件定義やプロジェクト推進に踏み込んだ支援も行います。例えば開発フェーズにもかかわらず要件定義が滞り、開発チームへの仕様開示が滞る場合があります。この場合、豆蔵チームとして、要件定義そのものを支援したり、組織の問題を分析し改善提案(7)を したりするような動きも取ります。
(7) 推進のために必要な役割を定義し、その役割を担う人が意思決定できるような会議体の定義を行い、会議進行・ファシリテーションも担います。また、明示的にそのようなロールを担わないケースであっても改善案を提示したり、意思決定のためのオプションを提示することは豆蔵の行動規範になっています。
豆蔵チームが保守フェーズまで残ることはそれほど多くありません(8) が、中には長期にわたり運用・保守をご支援するケースもあります。
保守フェーズでは開発チームが縮退し、属人的な知識は霧散してしまいます。残ったメンバーは担当したことのない箇所のコードを修正し、やったことのない作業を実施することになります。開発時に十分なドキュメント整備され、引き継ぎがしっかりなされていれば、デグレードや作業ミスによるシステム障害が起きる可能性はそれほど高くないでしょう。しかし現実にはリリースまでの仕様変更対応やバグ対応に追われ十分な知識伝搬ができていないケースが殆どです。時間に追われて書かれたコードは、十分テストされていなかったり、修正が難しい形になっていたりすることが往々にしてあります。そのため、保守チームは手がかりも人数も少ない中、膨大な量のコードに立ち向かい、地雷を踏まないよう、いなくなった開発者達の意図を推測しながら、試行錯誤で修正作業を進めることになります。保守というのはある意味で新規開発よりもずっと難易度が高く厳しい作業なのです。
このような事情から保守作業は文字通り ”守り” の作業になりがちです。「言われたことだけやる。」「障害が発生したとこだけ対応する」という状態になってしまい、システムのユーザーにとっての価値や利便性を高めるような改善はほぼ困難となります。
豆蔵は、”攻め” の保守を行うこともあります (9)。攻めの保守は、日々の大過ない運用にとどまらず、中長期的にシステムのあるべき姿を設定して近づけていく活動です。そのためには、問題があるところはシステムの根幹であるデータモデルや、開発フェーズまでに確定した画面仕様であっても積極的に見直し改善提案をしたり、時には業務フローそのものの改善を提案したりすることもあります。定例リリースを粛々と行うだけでなく、状況に応じてタスク、スケジュールをダイナミックに組み替えるという動きも可能です。
(8) 成果物に問題が少なく、お客様やパートナーのベンダーで保守可能なアーキテクチャを残しているということもあります。もちろん一般的なベンダーに比べて単価が高いため、予算都合という面もあります。
(9) もちろん十分な保守体制が組まれていることが大前提となります。
保守フェーズにおけるメソドロジーの改善保守作業は開発フェーズで採用されたツールやドキュメント・手順書などを遵守するため、年月が経つと陳腐化し、非効率なやりかたを続けていることが殆どです。豆蔵では初期開発時のツール、ドキュメント、方法に固執せず、積極的に最新のツールや方法論を取り込み保守作業の効率化を図ります。
ここまで、アーキテクチャ構築や開発・保守という各分野の活動における豆蔵の取り組みを説明し、行動規範を描写してきました。
豆蔵社員の特性として、座学や理想像を振りかざして終わりではなく、あるべき姿を具体的なイメージやモデルとして表現し、そこにいたる具体的なアプローチを実践できるということが上げられます。一般に IT コンサルティング会社は絵に描いた餅だけ提供して終わりになりがちです。いわゆる「上流」のみで完結して泥臭い部分はノータッチで終わります。具体的指針がないため、残されたメンバーは困るだけです。豆蔵はモデルを提供して終わらせるのではなく、実際にアーキテクチャとして提供し、アーキテクチャ上でのアプリ実装も支援し、場合によっては運用に入ってからのブラッシュアップにもお付き合いすることができます。そして、ここまで出来るのが豆蔵の強みなのです。そのためにアーキテクチャ構築時のメンバーがアーキテクチャのトランスファーや技術支援のためにアプリケーション開発チームに入り込みます。その結果、開発チームも納得の上で、モチベーション高く開発に取り組みます。
豆蔵は特定の業種に特化したり、ニッチなテクノロジーに注力したりする会社ではなく、オブジェクト指向や開発方法論といった普遍的・工学的な手法を業務システム開発に適用しシステムの価値を高めることを目指す組織です。豆蔵社員は経験の浅い分野でも持ち前の問題意識と適応能力によって短い期間で最適に近いプロセスを導いてきた実績を持っています。
豆蔵エンジニアの特長組織／風土・上司としての管理者はいない。リーダーはいる
・コードが書けない、著しく生産性が低い、技術負債をため込むメンバーはいない
・互いの成果物をレビューしあう。議論を避けない思考／行動パターン・一貫性／整合性を重視する。
・問題を発見するのが速い
・新しい技術や業務分野であってもキャッチアップが速い
・問題の原因追求を粘り強く行う
・非効率を憎み、モダンなやり方を好む。
・自動化・効率化のための手間を惜しまず、生産性を上げるツールの情報収集、適用を行う
・現実的なアプローチを提案する
・根性論や人海戦術を否定する
・リスク管理をする
・QCD のバランスを考えて機能やスコープの調整をするエンジニアリング・複雑な対象を一度に把握するのは難しいため、段階的に詳細化、コンポーネント化する
・コンポーネント間の依存関係を少なくする。
・機能追加や仕様変更する前後でこまめにリファクタリングしてコードの保守性を保つ
・システムを構成するコンポーネントの凝集性、結合度、依存関係を大切にする
・クラスを小さく保ち、保守しやすく理解しやすい形にする
・冗長でない要所を抑えたドキュメンテーションができる。
・ブレークスルーになるようなテクノロジーがあれば評価した上で適用する
クラウドネイティブなどの新しいパラダイムはもちろんのこと、ごくふつうの業務システム開発においても、ソフトウェア工学の知見に基づいたベストプラクティスが存在します。ソフトウェア比重が高まる昨今、業務要件が変化し続ける中、5 年 10 年と使い続ける業務システムだからこそ、開発開始時点で利用可能な、最新かつ信頼性の高い技術を選択し、要件定義、方式設計、開発、保守というソフトウェアのライフサイクル全般に渡り改善策を講じながら、ベストプラクティスを実践する必要があるのです。豆蔵はこの活動を全方位的に支援します。
※転載元の情報は上記執筆時点の情報です。
上記執筆後に転載元の情報が修正されることがあります。
/assets/images/6899879/original/2fcf17aa-4638-4b0f-bc0f-f2f8122b147d?1622699171)
/assets/images/6899879/original/2fcf17aa-4638-4b0f-bc0f-f2f8122b147d?1622699171)
/assets/images/6756290/original/4bfb75e2-33cb-4789-8c8d-2648546016b4?1621923578)