4
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

初めて基本設計を担当した振り返り

Posted at

はじめに

普段は詳細設計や製造、テストを担当している私ですが、今回は小規模なシステムながら基本設計から担当する機会をいただきました。
初めてのことが多く、振り返ると多くの学びがありました。
いくつか間違った判断もあったかもしれませんが、まだ駆け出しのSEとして経験したことをまとめたいと思います。

担当業務

以下の設計業務を担当しました。

業務フロー設計

業務全体の流れを視覚化し、業務プロセスがどのように進むのかをシステム上で実現できる形に落とし込みました。
具体的には、どのタイミングでユーザーやシステムがアクションを行い、その結果がどのように次の業務に影響を与えるかといったことを設計しました。
顧客が実際に行っている業務をシステム化するために、業務手順をイメージし、システムで実現可能な形に整理しました。
ここが最も難しく時間を使いました。

論理DB設計

データの構造を設計し、システムで扱う情報を整理しました。
どのデータをどのテーブルに格納するのか、どの項目がキーになるのかを考えながら効率的にデータを管理するための仕組みを設計しました。
システムの実現に必要なデータを過不足なく挙げていくというところが難しかったです。
最小限のリソースで実行するために、「必要そうであれば何でも入れておけ」の精神ではいけないということが理解できました。

画面遷移図設計

ユーザーがシステムを操作する際の画面間の流れを設計しました。
業務フローである程度決まっていたのでそこまで難しくなかったですね。

画面レイアウト設計

各画面でのボタンや入力フィールドの配置を決定しました。
一般コンシューマー向けのシステムではないのでそこまでの細かく設計したわけではないです。
しかし、ユーザーの目線でどういう情報が重要なのかを理解して、それを強調するように表示するなどの工夫はしました。

シーケンス設計

システム内のモジュール間のデータのやりとりやプロセスの流れを時系列で表すシーケンス図を作成しました。
特定のイベントが発生した際に、どのモジュールがどのタイミングでアクションを起こし、どのように結果が返ってくるかを視覚的に整理することが目的です。

感じたこと

  1. 顧客の要望を翻訳する難しさ
    エンジニアではない顧客の要望を、システム設計に落とし込む「翻訳作業」が非常に大変でした。
    特に、業務の要件をシステムでどう実現するかを考える際、技術的な視点と業務的な視点の間で橋渡しをする感覚が求められました。
      
  2. 正解のない問いに答える難しさ
    設計作業では、正解のない問いに答える場面が多くありました。
    例えば、論理DB設計において、どのパラメータをマスタで管理するべきか、どこまでデータを細かく分けるべきかなど、複数の答えが考えられる状況で最適な選択をする難しさを実感しました。
    これに比べて、詳細設計や製造ではある程度仕様が固まっており、やるべきことが明確です。そのため、実現方法を考える部分に大きなギャップを感じました。
      
  3. 全体像の把握の難しさ
    設計を進めていく中で、システムの全体像を解像度高く把握することの難しさも感じました。
    大まかにどういうシステムになるかは理解できていましたが、細かい部分の理解が足りず、途中で迷子になることもありました。
      
  4. 経験と知識の不足
    特に、何が「システム実現に必要か」という経験と知識の不足を強く感じました。
    例えば、論理DB設計の際、何をマスタ管理すればよいか、どこまで詳細に設計するべきか、パターン化された知識が不足していることを痛感しました。
      
  5. 不要なものを入れすぎない
    最初は「とりあえず入れておこう」という考えがありましたが、不要なものを設計に盛り込みすぎると、リソースの無駄遣いになってしまいます。
    設計の際は、できるだけ最小限のリソースで実現することが重要だと感じました。
      
  6. 専門用語を使わずに説明する難しさ
    顧客にシステムの全体像を説明する際、専門用語を避けて分かりやすく伝えることの難しさを感じました。例えば、「オブジェクト」という言葉を使っても、顧客にはあまりピンとこなかったようです。
    非エンジニアに対する説明力の重要性を強く感じた瞬間でした。
      
  7. 実現可能性に対する不安
    自分が考えたシステム構成が本当に技術的に実現可能かという部分に神経を使いました。
    設計段階では、この構成が後に問題になるかもしれないという不安が常にあり、頭を悩ませる要素でした。
      

最後に

本当は、設計後の製造やテスト、さらには運用まで担当したかったのですが、別プロジェクトにアサインされてしまい、それは叶いませんでした。
しかし、この基本設計の経験を通して、設計の難しさや自由度が高いことの難解さを理解できました。
自由に設計できることは一見良いことに思えますが、最適な方法を選択する責任が伴うため、そう簡単ではないと感じました。

今後も、設計業務を含めてスキルを磨き、より良いエンジニアを目指していきたいと思います。

4
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?