シュリンプークラブ

はじめにプログラムでは、数値や文字列などさまざまな種類のデータを扱います。しかし、異なるデータ型同士をそのまま計算したり代入したりできるとは限りません。そのため必要になるのが型変換（Type Conversion）です。一方で、「勝手に型が...

共通化する前に考えるべきなのは、コードではなく「変更理由」「同じような処理があるから共通化しよう。」システム開発では、ごく自然に行われる判断です。重複したコードを減らせば保守しやすくなり、修正箇所も少なくなる。一見すると合理的な設計に思える...

「名前なんて後から変えればいい」と思っていませんか？クラス名やメソッド名は、動けば何でもよいものではありません。「Manager」「Util」「Helper」のような曖昧な名前を付けた結果、責務が増え続け、修正のたびに影響範囲が読めなくなっ...

始めに「気付いたらクラスの責務が増えていた。」開発を続けていると、このような状況は珍しくありません。しかし、本当に原因は設計力の不足なのでしょうか。実は、多くの場合は設計そのものではなく、その前段階である要件の整理に原因があります。この記事...

はじめに同じ要件をもとに設計しているのに、設計者によって成果物が異なることがあります。障害調査を重視して詳細なログを残す設計もあれば、運用負荷を考慮して必要最低限に抑える設計もあります。バックアップの保存期間や権限管理の方針、将来の拡張性を...

はじめにシステム開発では、「検索できる」「注文できる」といった機能に目が向きがちです。もちろん、利用者が目的を達成するために機能は欠かせません。しかし、機能が完成しただけでは、安心して運用できるシステムになったとは言えないのです。　実際に問...

はじめに「利用者の要望どおりに作ったら、運用が大変になった。」「機能は完成したが、障害対応や仕様変更に時間がかかる。」このような問題は、利用者だけを見て設計したときによく起こります。設計とは、利用者が使いやすいシステムを作ることだけではあり...

はじめに（この記事で解決できること）設計というと、画面やデータベースの構成を考えたり、それを設計書にまとめたりすることをイメージする人は少なくありません。これらは設計工程で行う作業であり、設計そのものの役割ではありません。設計の役割は、定義...

はじめに（この記事で解決できること）要件定義では、必要な機能や画面、性能などを整理し、開発の方向性を決めていきます。しかし、「なぜそこまで細かく整理する必要があるのか」と疑問に感じたことはないでしょうか。その答えは、要件定義で決めた内容が、...

はじめに（この記事で解決できること）要件定義というと、「何を作るのか」を決める工程というイメージを持つ人は少なくありません。しかし、実際のプロジェクトでは、機能を決めること以上に、「どこまで対応するのか」「何を対象外とするのか」を整理するこ...