技術と人のあいだ

tech-and-human

コラム 技術と人のあいだ

WEBシステムという選択肢を読み解く

WEBシステムという選択肢を読み解く WEBシステムへの理解 システム開発を検討する場面で、現在もっとも一般的な形となっているのが、ブラウザから利用するWEBシステムです。業務システムや顧客向けサービスを問わず、「まずはWEBで構築する」という判断が選ばれることも多くなりました。しかし、その選択が何を意味するのかを整理しないまま進めてしまうと、後になって制約や課題が表面化することがあります。様々な立場・目線で「WEBシステム」を見ることで、理解を深める助けになればと思います。 利用者目線 利用者の視点から見ると、WEBシステムの利点は非常に明確です。ブラウザさえあれば、PC・スマートフォン・タブレットといった端末を問わず利用でき、場所にも縛られません。大阪に本社を置く会社のシステムを、東京の拠点や出張先から同じように使える。この「距離を意識しなくてよい」点は、働き方や組織構造の変化と相性が良いと言えます。 大阪のシステム開発会社であるヨドックでも、大阪と東京の各拠点メンバーでスケジュール調整を行うなどの使い方をしています。 管理者目線 運用・管理の立場から見ると、WEBシステムは別の価値を持っています。従来のクライアントサーバー型と比較して、利用端末ごとの設定やサポート、バージョンアップ対応が軽減されます。データはサーバー側で一元管理され、リアルタイムで共有されるため、拠点間で情報が食い違うリスクも下がります。 開発者目線 開発者の視点を加えると、WEBシステムは公開仕様やオープンソース技術の組み合わせで構成されることが多く、比較的短期間・低コストで高度な仕組みを実現できる可能性があります。その一方で、構成が複雑になりやすく、どこまでを自分たちが理解・管理できているのかが見えにくくなる場面もあります。利便性と理解度のバランスは、設計段階で意識しておく必要があります。 ビジネス目線 事業の観点では、WEBシステムは拡張性の高さが特徴です。ECサイトであれば利用者の増加が直接売上につながり、プラットフォーム型のサービスでは継続的な収益モデルを描きやすくなります。将来的な成長を見据えたシステム開発を行う際、この点は経営判断とも深く関わります。 前提条件 ただし、共通する前提条件も忘れてはいけません。 WEBシステムでは、通信の暗号化やデータ改ざん対策など、セキュリティの確保が必須となります。特に顧客情報や業務上の機密情報を扱う場合、一度問題が発生すると、影響は局所的にとどまりません。 不正アクセスや情報漏洩が起きた場合、データは短時間で大量に流出し、どこまで拡散したのかを正確に追跡することが難しいという特性があります。これは、紙の書類や特定端末内のデータとは異なる、WEBシステムならではのリスクです。 まとめ WEBシステムは、場所や端末に縛られず利用でき、拡張もしやすいという点で、現代の業務やサービスと相性の良い仕組みです。一方で、セキュリティや通信環境といった前提条件を含め、成り立ちそのものに特徴があります。これは優劣の問題というより、「どういう性質を持った仕組みなのか」という整理に近いものです。 システム開発を考える際には、WEBであること自体を目的にするのではなく、その特性が自社の業務や組織、事業の方向性とどう重なるのかを見ていくことが重要になります。選択肢を一度フラットに並べ、それぞれの立場から眺め直すことで、判断の精度は自然と高まっていくはずです。    日々の業務で、お客様への提案や若手エンジニアへの説明をする機会が多くあります。大阪でシステム開発の仕事に向き合う日々の中で、限られた時間では伝えきれないことや、「これも知っておいてほしいな」「前にも同じ話をしたな」と感じることを、ここに少しずつ書き留めていきます。

コラム 技術と人のあいだ

品質に対する誤解

品質に対する誤解 担当者のお悩み 「もうでき上がっているのですが、お客様が完成度に納得されず、なかなか公開できないのです。現行の古いデザインよりは確実に改善しているので、早めにリリースして、運用の中で少しずつ改善していけばよいと思うのですが……」 ホームページ制作部門の担当者と雑談をした際に、このような話を聞いたことがあります。このやり取りは、ソフトウェアの品質に対する考え方の違いを端的に表しているように感じました。 ソフトウェアの品質は「100%を目指すもの」であり、工業製品の品質は「100%を保証するもの」であると考えられます。この違いは表現としてはわずかですが、実際の現場では判断基準や期待値に大きな影響を与えます。 モノづくり屋さんの感覚 工業製品の世界では、大量生産を前提として品質が設計されています。製造工程では歩留まりが管理され、不良率は数値として把握されます。市場に出る段階では「規格を満たしていること」が保証されており、問題が発覚した場合でも、リコールという形で責任の所在と対応方法が明確に定義されています。設計段階では試作品を用いた検証が重ねられ、量産前に品質を作り込むことが前提となっています。 ソフト屋さんの感覚 一方、ソフトウェア開発、とくにスクラッチ開発では事情が大きく異なります。ソフトウェアは物理的に摩耗しない代わりに、要件変更や利用環境の違い、利用者の操作によって無数の状態を取り得ます。そのため、完成時点で品質を100%保証するという考え方は現実的ではありません。品質はテストや運用を通じて徐々に高まっていくものであり、その過程は信頼度成長曲線として説明されることが多いです。 このような品質観を象徴する考え方として、ソフトウェア業界では「No Silver Bullet(銀の弾丸は存在しない)」という言葉が知られています。これは、ソフトウェア開発における本質的な複雑さや不確実性を、一挙に解消できる万能な方法は存在しない、という認識を表したものです。ソフトウェアの品質は、単一の手法や工夫で保証できるものではなく、積み重ねによってしか高められない、という前提がここにあります。 オープンソースの上に成り立つ世界 オープンソースソフトウェアも、この考え方の延長線上にあります。OSSは多くの実績と改善の積み重ねによって高い信頼性を獲得していますが、それは「完成した品質」を意味するものではありません。OSS自体が運用と改良を前提に育てられている以上、それを基盤として構築されたシステムの品質もまた、運用の中で成熟していくものだと言えます。 ギャップの存在を認識する こうした前提を踏まえると、ソフトウェアの品質を巡る判断には、常に揺らぎが生じます。品質を「完成した状態」と捉える人もいれば、「運用の中で育てていくもの」と捉える人もいます。どちらが正しいという話ではなく、立場や経験によって、品質に対する認識や常識が異なるのは自然なことです。 そのため、ソフトウェアの現場では、品質に対する前提が毎回同じであるとは期待できません。相手が変われば、求められる完成度の感覚も変わります。その違いを前提としたうえで、「今回はどこまでを完成とし、どこからを運用で改善していくのか」を一つずつすり合わせていく作業が必要になります。 ソフトウェアの品質を巡る判断は、技術だけで完結するものではありません。相手ごとに異なる認識を受け止め、その都度調整し続けること自体が、ソフトウェア開発の一部なのだと思います。    日々の業務で、お客様への提案や若手エンジニアへの説明をする機会が多くあります。大阪でシステム開発の仕事に向き合う日々の中で、限られた時間では伝えきれないことや、「これも知っておいてほしいな」「前にも同じ話をしたな」と感じることを、ここに少しずつ書き留めていきます。

コラム 技術と人のあいだ

移行から考える

移行から考える システム開発プロジェクトにおいて、忘れがちだけれど非常に重要なことがあります。 それが「移行」です。 既に運用中のシステムから、新しく開発したシステムへ置き換える。 こうしたプロジェクトは決して珍しくありません。 私が一メンバーとして関わったあるプロジェクトでも、設計・開発フェーズがとにかく難航しました。 そして開発フェーズの終盤になって、ようやく「そろそろ移行のことを考えないといけないですね」という話が持ち上がりました。 移行は“別の開発”である 移行元と移行先のシステムでは、キー項目やデータ同士の関係(リレーション)が異なることが多くあります。 それが数十万件単位で積み上がっている場合、 単純なコピーでは済まず、「移行専用のプログラム」を作って加工する必要があります。 ここで注意したいのが、移行プログラムの特殊性です。 通常の業務プログラムは、 開発後にテストを重ね、実運用の中で想定外を経験しながら品質が磨かれていきます。 一方で移行プログラムは、次のような性質を持っています。 原則として一度しか使われないため、品質保証が難しい 切替作業中の限られた時間内で、確実に完走することが求められる そのため、繰り返しリハーサルを行い検証を重ねる必要があります。しかし、一度しか使われないという前提は変わらないため、移行はどうしても「想定外のコスト」になりやすい領域です。 「どう飛ぶか」ではなく「どう着地するか」 たとえ話をすると、少し分かりやすくなります。 飛行機が発明された当初は、「どれだけ高く、どれだけ長く飛べるか」を競う時代でした。 しかし現代の飛行機は違います。最も重要なのは、滑走路に無事着陸できることです。その前提のもとで、機体が設計され、運航計画が立てられています。 システム開発も同じです。 「どう作るか」だけでなく、「どう切り替え、どう着地するか」について、開発ベンダーとシステムオーナーがあらかじめ目線を合わせておかないと、想定していたコストや納期に間に合わない、という事態が起こり得ます。 移行対象はすべて同じではない 参考までに、データは種類ごとに整理して考える必要があります。 マスタデータ 顧客情報、商品情報など トランザクションデータ 見積伝票や請求データなど、履歴性の強い情報 マスタデータは新システムへ移行するが、トランザクションデータはCSVファイル保存で十分、といった判断が現実的なケースも少なくありません。 用語の整理 最後に、よく混同されがちな用語を整理しておきます。 移行 多くの場合、データ移行を指します。 切替 ユーザー目線 旧システムの利用を停止し、新システムで業務を開始すること ベンダー目線 システム切替そのものに加え、DNSやロードバランサの切替作業なども含みます    日々の業務で、お客様への提案や若手エンジニアへの説明をする機会が多くあります。大阪でシステム開発の仕事に向き合う日々の中で、限られた時間では伝えきれないことや、「これも知っておいてほしいな」「前にも同じ話をしたな」と感じることを、ここに少しずつ書き留めていきます。

コラム 技術と人のあいだ

スクラッチ開発とパッケージシステム

スクラッチ開発とパッケージシステム よくあるお悩み お客様からシステムに関するご相談をいただく際、いくつか“よくあるパターン”があります。 一つは、 ExcelやAccessで業務を回してきたものの、さすがに限界を感じ始めたケースです。そこでパッケージシステムを検討してみたものの、「全体としては良いが、どうしても一部の業務に合わない」という壁にぶつかります。 もう一つは、 すでにパッケージシステムを導入しているものの、 「そろそろ置き換えたい」「バージョンアップの時期が来た」というケースです。 ところが、バージョンアップに伴ってさらなるカスタマイズが必要になったり、 そもそも対応できないと言われてしまうこともあります。 なぜパッケージは変化し続けるのか パッケージシステムが変化していく理由は、決して気まぐれではありません。 脆弱性への対応 法改正や業界動向に合わせた機能追加 ベンダー自身のビジネス環境の変化や競合への対応 こうした事情から、パッケージは「止まることなく進化する」宿命を持っています。 なぜパッケージのカスタマイズは高いのか パッケージシステムは、 「そのまま使うこと」を前提に、全体の整合性が丁寧に設計されています。 そこに想定外の処理や独自要件を割り込ませる場合、 全体への影響を考慮しながら調整する必要があります。 結果として、そのコストはどうしても高くなりがちです。 建築にたとえると パッケージシステムは、いわばプレハブ住宅です。 そのまま使うことを前提に作られているため、 大きな改造や間取り変更は得意ではありません。 一方で、条件に合えば安価で、品質も安定しています。 対してスクラッチ開発は、大工による注文住宅のようなものです。 いびつな土地にも建てられますし、内装や動線に強いこだわりを持たせることもできます。 ただし、費用は高くなりがちで、品質も作り手次第です。 そのあいだをどう埋めるか 理想を言えば、 「パッケージの安定性」と「スクラッチの柔軟性」 その“いいとこ取り”ができるのが一番です。 ヨドック式開発は、まさにその間を埋めるためのアプローチです。    日々の業務で、お客様への提案や若手エンジニアへの説明をする機会が多くあります。大阪でシステム開発の仕事に向き合う日々の中で、限られた時間では伝えきれないことや、「これも知っておいてほしいな」「前にも同じ話をしたな」と感じることを、ここに少しずつ書き留めていきます。

コラム 技術と人のあいだ

システム保守費用は必要か?

システム保守費用 「システム保守費用」についてはこのように思われたことはありませんか? システム開発に高額の費用を払ったのに、さらに月々費用を払う必要があるのか 特に作業をしてもらっているわけでもないのに払い続けるのは納得いかない 例えば家電(ドライヤーなど)を購入・使用する際は、使っていくのに月々の支払いは続きません。 自動車の場合はガソリン代や車検、税金はかかりますが、整備費用は点検作業を依頼した時に支払います。 マンションを購入すると修繕積立金がありますが、これも改修工事など具体的な作業費に充てられます。 このように比べると、システムを利用するうえで毎月保守費用が必要というのは、理解しにくい面もあるでしょう。 ユーザー目線での保守には、日常的な運用活動が含まれます。 具体的には、システムの稼働状況の監視、データバックアップの実施、障害発生時の初期対応などです。 これらは普段目に見えませんが、適切に行うことで業務の安定性を高め、トラブルによる損失を防ぐことができます。 ベンダー・保守提供者側の視点では、担当者が変わっても知識やノウハウを組織として保持し、継承していくことが重要です。 これにより、ユーザーは安心してシステムを利用でき、障害や業務変更による影響を最小限に抑えることができます。 システムを深く理解した専門技術者が体制として維持されていることで、万一のトラブルでも迅速に対応可能です。 このように、保守とは「問題が起きたときの保険」ではなく、事業を止めずに価値を最大化するための継続投資です。 開発規模や業務独自性に応じた適切な保守体制を維持することで、スクラッチ開発システムの柔軟性や独自性を損なうことなく、長期にわたって活用できます。 つまり、保守費用は単なるコストではなく、システムを経営資産として守り、変化に強い組織をつくるための戦略的投資なのです。 結果として、継続的な保守によって、ユーザー企業は日々の業務に集中でき、ビジネスの成長に注力できます。 システムの安定稼働とリスク回避は、企業の信頼性や業務効率、ひいては収益に直結する重要な活動であり、月々の保守費用はそのための投資と考えることができます。    日々の業務で、お客様への提案や若手エンジニアへの説明をする機会が多くあります。大阪でシステム開発の仕事に向き合う日々の中で、限られた時間では伝えきれないことや、「これも知っておいてほしいな」「前にも同じ話をしたな」と感じることを、ここに少しずつ書き留めていきます。

お問い合わせ

CONTACT

業務システムに関するお困りごと、WEBサイトの制作など、
まずはお気軽にお問い合わせください。

会員サイト
CONTACT
06-6305-2278
採用サイトはこちらRECRUIT