基本設計書 テンプレート。 システム開発用テンプレート

基本設計書/詳細設計書の作成を支援するクラウドサービス

基本設計書 テンプレート

基本設計とは情報システムを作る工程の一つで、情報システム全体を機能単位に分割して、それぞれの機能がどういうものか、どういうことができるものか、機能同士がどうつながるのか決めていく作業です。 基本設計を行うタイミングは、要件定義の後、詳細設計の前になります。 基本設計とはどういうものか…については、全ての関係者が納得する一つだけの答えはありません。 なぜなら、情報システムを作る作業には、法律や業界団体などで決められた、決定版ともいえる手順や成果物がないからです。 情報システムを作る人、プロジェクト、会社、方法論ごとに作業の仕方が違うのです。 それでも、広く共通しているのは、基本設計は情報システムの具体的な姿を、全体的な観点で考え始める工程だということです。 要件定義で決められた、情報システムで実現しなければならないことを、どうやって具体的な画面・帳票・バッチ処理・データベースで実現するかを、みんなで考えるのです。 この記事では、基本設計とはどういうものかを、情報システム構築の初心者向け、情報システム構築に興味がある方向けに、分かりやすくお伝えします。 1.基本設計では情報システムの全体像を考える 1-1.基本設計は何をどう作るかを決めるもの 基本設計は、情報システムを実現するために何をどう作ればいいのかを決める作業です。 情報システムを作る作業の中では、要件定義の次にある作業です。 基本設計では以下のようなことを行います。 情報システムの画面や帳票、バッチ処理などの作るべき機能を全て洗い出す• それぞれの機能が、どういうことをする機能か明確にする• 機能の間の関係性、特に入出力するデータを明確にして、情報システム全体で業務をどう行うか決める• 情報システムで持つデータを、どういう形式・項目として扱うか決める• 連携先の既存情報システムとどんなデータをやり取りするかを決める• どんなハードウェアやミドルウェアを組み合わせれば、要件が実現できるか考える 1-2.基本設計のインプットとアウトプット 基本設計のインプットは要件定義書です。 情報システムを作る工程の最初は要件定義で、そのアウトプットが要件定義書です。 基本設計のアウトプットは、その後の詳細設計のインプットになります。 基本設計は、要件定義書にある情報システムとしてのあるべき姿を実現するために、どういう方法で具体化するのか、どういうものを実際に作らなければならないかをプログラムを作り始める前にしっかりと決めて、アウトプットとして形にする作業なのです。 基本設計は情報システムとしての大枠、全体像、アウトラインとも言えるものを決める段階ですから、どのようなモノを使って実現されるか…例えばどのようにプログラミングされるかとは、少し距離を置いた抽象的なポジションで考えます。 1-3.基本設計はお客様と完成形をすり合わせる最後の機会 基本設計は、お客様が SIerに注文した情報システムがこうなるはずだという姿を、お客様自身が確認できる最後の機会であることが多いものです。 基本設計が進んでいく中で、画面の流れや帳票のイメージ、それらを使った業務の流れが分かるようになった時点で、お客様にレビューをしていただきます。 レビューでのお客様からの指摘事項や情報システムへのご要望は、基本設計のアウトプットに反映して再レビューします。 こうして認識のずれを防ぎます。 なお、お客様が IT企業の情報システム部門など、情報システムの知識がある人たちなら、詳細設計以降のアウトプットを都度確認することも普通です。 でも、 ITの知識がないお客様だと、情報システム構築の知識がないことが当たり前なので、詳細設計以後のアウトプットを理解することが難しくなっていくのです。 1-4.外向けの設計と内向けの設計 知っておいていただきたいのは、基本設計は情報システムが形作られるべき姿を、情報システムの外から眺めたものと、内から眺めたものの二つの観点から作るものだということです。 外から眺めたものとは、例えば画面のデザインや画面間の遷移、出力される帳票のレイアウト、関連する情報システムとのデータのやり取り、そして情報システムを使った業務の流れです。 ですから、情報システムが形になった後、お客様がこういうように使えるようになるはずだ、というものでもあります。 内から眺めたものとは、情報システムの作られ方に関係するものです。 お客様が使う画面の裏には、画面を表示するためのプログラムやデータを保存するデータベース、そしてシステムとしてそれらがどう組み合わさるかという、いわゆる「アーキテクチャ」があります。 基本設計はそれを決めるものでもあります。 2.基本設計のアウトプット 基本設計で作るアウトプットは、大体は以下のように分類されます。 もちろん、現場や SIerにより呼び方が違いますし、どんなやり方で情報システムを作るかで、作る必要があるものも変わってきます。 例えば、オブジェクト指向分析がベースの開発方法論なら、これ以外にも作るものがあります。 基本設計では、要件定義書の内容から、情報システム全体を機能に分割・分類して、それらの機能レベルで情報システムではどういうことをどう行うかを考えます。 同時に、情報システム上でデータをどう持つか、連携先のシステムとはどう連携するか、どういうハードウェアやネットワークとするかも考えます。 そして、基本設計の時点では、各機能や処理にはどういう入力があり、どういう処理が行われ、どういう結果が得られる…という「流れ」を重視します。 ですので、基本設計では処理の詳細までは踏み込まず、「この機能はこういうことができる」という観点で設計を進めていきます。 2-1.システム全体の機能を一覧化し、流れをまとめる アウトプット:機能一覧、業務フロー図、データフロー図、入出力関連図など 基本設計でまず作るものは、情報システムを形作る機能の一覧です。 基本設計が終わった時点では、情報システムで作るべきモノが全体でいくつあるのかが、具体的な数字でわかるようになります。 この機能の一覧は、基本設計の作業の進み具合や、情報システムの規模を正確に把握するためにも欠かせません。 この「機能」の単位はいろいろです。 画面、帳票、バッチ処理、 APIなどの同じモノの単位で一覧を作ることは普通ですし、もっと上位の「業務」とでも呼べるものでグループ化した上で、その中にはどんな画面、帳票、バッチ処理、 APIなどのサブ機能があるのか…という風にまとめることも普通です。 前述したとおり、機能の一覧は基本設計の最初に作り始めますが、最初から全ての機能を一覧にはできません。 要件定義書を見ながら、「この業務はこれとあの画面を使ってこうやるから…」とか「このデータを作るにはこの処理が前にあって…」という検討や試行錯誤をしながら、だんだん育てていくものです。 2-2.画面の役割と画面のつながりを業務視点で考える アウトプット:画面一覧表、画面遷移図、画面設計書、項目定義書 画面 など 情報システムの「顔」がいわゆる画面です。 基本設計では、どういう画面があるのか、その画面では何ができるのか、その画面にはどういう項目があってどう表示されるのか、画面間の繋がりはどうなのかという設計を行います。 要件定義である程度作られている画面を、さらに明確にすることも普通です。 この作業では、画面のレイアウトや、例えばボタンをクリックした時には情報システムがどんな動きをするのか 表示の更新、データ保存など を決めます。 そして、情報システムは複数の画面を持つことが普通ですから、それらの画面遷移がどういう条件でどういう時に行われるかなども明確にしていきます。 そして、画面は情報システムを使うお客様がいつも使うものですから、どういう画面にするかでお客様の情報システムへの印象が大きく変わります。 ですので、ユーザインターフェイス UI の専門家や、最近はユーザ体験 UX の専門家も交えて、喧々諤々な議論が行われることもあります。 2-3.どんな帳票をいつどうやって出すかを考える アウトプット:帳票一覧表、帳票設計書、項目定義書 帳票 など 情報システムに欠かせないのは帳票です。 前述した画面も広い意味では帳票の一種だと言えますが、ここで言う帳票は受注伝票や入金伝票などの業務上必要になるものや、 PDFや Excel、 CSVなどで売上高などの集計値を提供したり、お客様がデータをダウンロードして二次活用できるようなもののことです。 基本設計で考える帳票設計では、いつ、だれが、どんな情報を、どういう形式や書式で、どこから出力するか決めていきます。 帳票は画面で入力する検索条件やデータベース設計にも密着していて、関連する機能を一緒に考えながら徐々にブラッシュアップしていくものなので、最初から決定版は作れません。 基本設計で帳票を考える時は、まだこの時点では動くモノはないので、基本的には全て机上の紙や設計者の頭の中で考えます。 どうやって帳票を作るのかのロジックはもちろん考えますが、画面の入力条件がこうで、こういうテーブル構造ならこの帳票はこう作れるだろう…という「予想」の元に作業が進みます。 2-4.バッチ処理をシステム全体視点で考える アウトプット:バッチ処理一覧表、バッチ処理フロー図、バッチ処理設計書など 情報システムでは、画面や帳票以外の処理、いわゆるバッチ処理があります。 バッチ処理は情報システムの裏で動き、お客様の目には直接触れませんが、画面や帳票を情報システムが提供するには欠かせません。 さらに、バッチ処理がうまく流れるかは、情報システムでの業務が上手く流れるかとイコールです。 基本設計では、どういうバッチ処理があるか、それぞれのバッチ処理ではどういう情報を入力として何を出力するか、どういうタイミングで動くのか、バッチ処理同士の前後関係、連続するバッチ処理が途中で異常終了したらどうフォローするか…などを決めていきます。 バッチ処理を考える上で大事なのは全体視点です。 一つ一つの処理は入出力や処理がわかりやすいように上手に分割して、それをうまく組み合わせて大きな一つの処理結果をどうやって作っていくかを考えます。 ですので、細かいことを考えて組み合わせるのが好きな人は、バッチ処理が面白いかもしれませんね。 2-5.データベースで持つデータを考える アウトプット:テーブル一覧表、テーブル設計書、ER図、CRUD図など 今まで説明してきたのは「処理」でした。 でも、処理だけでは情報システムは作れません。 情報システムで扱うデータをどう保存し、必要に応じて検索結果としていろいろな処理へどう提供するかを考えなければなりません。 ここで行うのは、いわゆるデータベースの設計です。 基本設計でのデータベースの設計は、どのような種類のデータベースを使うのか、使うと決めたデータベースでどのようにデータを管理するのかを決めます。 最近はリレーショナルデータベース以外のプロダクト いわゆる NoSQLなど も普通に使いますので、その関連知識も基本設計では求められることがあります。 例えば、一般的なリレーショナルデータベースを使うなら、要件定義から抽出したデータからテーブルを考え、どのような項目を持つか、インデックスにはどの項目を使うのか、テーブル間の関係がどういうものかなどを決めます。 大きな情報システムなら、全体で数百以上のテーブルになることも普通です。 2-6.システムの要件を実現できる構成を考える アウトプット:システム構成図、運用設計書など 情報システムは、今までお伝えしてきたアプリケーション側の領域と、サーバ・クライアント PCなどの OS・ハードウェア、ネットワークなどのインフラストラクチャ Infrastructure、いわゆるインフラ 側の領域の二つから作られています。 どちらが欠けても、情報システムは動かせません。 基本設計では、インフラ側の担当者がアプリケーション側の担当者と一緒に、どのようなハードウェアやネットワークの構成にすれば、要件定義で決められた処理性能や可用性や運用性などのいろいろな要件・非機能要件を満たすことが出来るかを考えます。 それらにかかるコストも、欠かせない検討項目です。 処理速度やデータを保存する領域の余裕をどのくらい持つか、情報システムの将来の拡張性はどう確保するか、ハードウェアの故障が発生した時はどうするか…など、インフラに求められるほぼ全てを基本設計の時点で予測し、対応方針を決め、必要なものを確保・発注するのです。 2-7.考えたことがきちんと全てつながるかを考える ここまでの記述で、「全体視点」という言葉が何回か出てきました。 基本設計を行う上では、作業を行う人にこの全体視点があるかがとても大事です。 何かの機能に偏った狭い視野ではなく、情報システム全体視点での広い視野が、基本設計でのアウトプット間の矛盾を見つけ出すのに必要となるのです。 基本設計では、まだプログラムとしての形が何もない時点で、最終的に出来上がる情報システムを想像しながら、全てが最後には一つにつながる前提でいろいろなアウトプットを作ります。 なので、業務知識、予測能力、想像力、論理的思考能力、問題領域の把握能力というようなものが、担当者には強く必要です。 しかも、情報システムの規模が大きくなればなるほど、全体像の把握は急激に難しくなります。 そのような情報システムの基本設計を取りまとめるには、大変な労力が必要になるのです。 3.要件定義と基本設計と詳細設計の違い この章では、情報システムを作る当事者以外の人、あるいは当事者であっても混乱しがちな、要件定義と基本設計と詳細設計の一般的な違いをお伝えします。 要件定義と基本設計と詳細設計は、いずれも情報システムのあるべき姿を考えるという、広い意味では設計の作業です。 そして、情報システム構築の方法論は世の中にはたくさんあり、それらの中では必要なアウトプットをどの工程で作っていくのかがずれていることも多いものです。 ですから、いくつかの現場や情報システムを渡り歩いた人は「なぜこの現場ではこのアウトプットをこの工程で作るの? 」という疑問を持ったりもしますし、同じ「基本設計」と呼ばれていても、作るものの内容や記述するレベルの認識が合っていなかったりするものです。 3-1.違いは誰向けのアウトプットであるか 要件定義と基本設計と詳細設計の違いは、誰向けのアウトプットなのかという観点が最も大きいと思われます。 要件定義はお客様と情報システムのあるべき姿を合意するためにあります。 ですから、お客様が理解できる言葉や図を使います。 基本設計は、要件定義の内容を情報システムの言葉に置き換えたものであり、どういう情報システムになるかを決めるものです。 ですので、お客様が出来上がる情報システムを確認するためにも使いますし、 SIerがどういうシステム構成にするかを明確にするものでもあるのです。 詳細設計は、完全に SIer側の言葉になります。 プログラムに落とし込まれる直前の状態ですから、使われる言葉や図も専門的なものになり、プログラマが読み込んで、出来上がるプログラムがイメージできる程度にまで、情報システムが動くべき手順が詳細に書かれるものです。 3-2.小さな案件ではこれらの区別はあまりない SIerが情報システムを作る時は、大体はこのような区別をして、工程の説明をお客様にするはずです。 ただ、大規模な情報システムならまだしも、小規模なものならこれらの作業は一体となっていることがあります。 お客様との「距離感」と言うべきものが近ければ、それでも十分だというケースも多いでしょう。 要件定義~基本設計~詳細設計と続く作業の流れは、ウォーターフォール型の情報システム開発の典型例ですし、批判も多くあります。 ですが、「何をどう作るのか」を段階的に明らかにして、なるべく手戻りがないように進めるのは、情報システムを作る上での王道ですし、何にしろ必要なことでもあります。 結局は「何をどう作るのか」が明確になっていて、お客様と合意がされていればいいのです。 開発方法の主流の一つになりつつあるアジャイルも、誤解を恐れず言うなら、お客様と SIerの距離を近くすることで認識齟齬が起きづらい開発体制を作って、素早くモノを作る、ということです。 目的は変わりません。 3-3.外部設計、内部設計との関係 基本設計を外部設計、詳細設計を内部設計と呼ぶことがあります。 基本設計では、情報システムを「外」から見た時の姿や動きを決める成果物が多いからです。 一方、詳細設計では情報システムの外面が決まった後に「内 なか 」がどうあるべきかを細かく決めていくので、内部設計と呼ぶのです。 ただ、繰り返しですが、情報システムを作る作業に関係する言葉は、同じ言葉でも SIerなどの文化や方法論で指すことがかなり違うので、どういう意味か有識者に確認しておいた方がいいでしょう。 4.基本設計を行う上で大事なコト この章では、基本設計をする上で押さえておきたい注意点や心構え的なものをお伝えします。 基本設計が上手くできていないと、後の工程が全て上手くいきません。 これらは、そういう悲劇を少しでも少なくするために、基本設計の担当者が知り、意識しておくべき事柄です。 大事なのは、全体視点を持って作業をすること、前工程である要件定義との整合性が取れていること、自信を持って作ることができるものであることです。 そして、基本設計の時点では完全無欠なアウトプットは残念ながら作れませんので、手戻りがあることを前提に作業を行うことも意識しておきたいです。 4-1.全体視点を持っていること 基本設計では、情報システムへの「全体視点」が欠かせません。 この全体視点には、情報システムの機能全体を見渡し把握するための、高く広い視点の他にも、お客様の視点、 SIerの一員としての視点、詳細設計・製造・テスト・構築・運用・保守をする要員の視点…という全関係者の立場での視点も含みます。 「この人の立場では、この情報システムはどう見えるだろう、使い勝手はどうだろう」という視点は、情報システムを作る最初、つまり基本設計の時点で組み込まれていなければなりません。 その視点のない情報システムは、要件を形や見た目だけにただ単に反映したものに過ぎず、「使える」ものではありません。 全体視点を持つ、視点を切り替えるには意識的な訓練が必要です。 そして、その立場で仕事をした経験が実際にあるなら、さらにいいでしょう。 ですから、基本設計に限らず上流工程の要員は、何かの領域に熟達している以外にも、今まで情報システムに関するどういった仕事をしてきたかが、必ず問われるのです。 4-2.要件定義とずれていないこと 基本設計が要件定義とずれていないかは、とても大事なことです。 基本設計に書かれていることは、元をたどればすべて要件定義のどこかの記述にたどり着く、というくらいでなければなりません。 それくらいしっかりと基本設計を作って残せば、お客様も含め、後に関わる人がすべて幸せになれるのです。 今までお伝えしてきたとおり、要件定義はお客様の言葉・視点での情報システムのあるべき姿であり、基本設計は SIerの言葉・視点での情報システムのあるべき姿です。 基本設計の時点で要件定義から言葉の「翻訳」が行われるので、要件定義と基本設計がずれていると、後工程の成果物が全てずれるのです。 基本設計は、情報システムで何か分からないことがあった時の拠り所です。 情報システムを作る時だけでなく、運用する時も、障害が起きた時も、改修する時も、次の情報システムに移行する時も、そのすべてにおいてです。 情報システムに関わる人は移り行きますが、基本設計は常にそこにあり続けるものです。 4-3.実際に作れるものであること 基本設計をする時は、まだ具体的な形がないだけに、いろいろと内容を盛り込みがちです。 しかし、基本設計は「こういうことができたらいいな」ではなく、「こうすればできる」「こうしなければならない」という明確な根拠ありきで進めるものです。 そうしないと、実際には作れない情報システムになります。 過去に担当した情報システムでの反省を生かして、今回は同じ失敗はしないという意識を持つことは大事です。 最近は既存の情報システムの改修や統合が多くなっていて、新しく情報システムを作る機会は減っているので、基本設計をする時にそう思うのは当然ですし、前のめりにもなるのは分かります。 ですが、情報システムは基本設計をする人の私物ではありませんし、趣味や嗜好や主義で作るものでもありません。 情報システムはチームで作るものです。 何かの設計には必ず明確な理由・意図があって、設計・製造をする人たちの間で合意が得られていて、かつ実際に作れるものでなければ意味がないのです。 4-4.設計の手戻りがない、はありえない 情報システムを作る仕事を続けていると、手戻りの無い工程はありえないことが分かります。 理想は前工程の精度を上げることですが、現実には限界があり、手戻りゼロは不可能です。 実際にやらないと分からないことはいまだに多いのです。 設計の工程は特に、机上や頭の中だけの考えなのでなおさらです。 手戻りがあることを前提に、取り得る選択肢や代替手段を考えておくのも、基本設計でやるべきことです。 さらに設計上のリスクに関しては、基本設計の時点でお客様に伝え合意することも大事です。 手戻りが発生しうるという現実に、どれだけ予測し準備できるかが、マネージャや SIerのノウハウであり実力です。 そして、基本設計後に詳細設計や製造をする際、設計上の問題を見つけたとしても、絶対に基本設計を変えてはならないわけではありません。 設計は都度変わっていくものです。 設計の変化に情報システムが追随するのは大変難しいのですが、避けられないことなのですから、準備はしておかねばならないのです。 4-5.設計作業にこそエンジニアのスキル・実力が問われる エンジニアのスキル・実力が本当に問われるのは設計作業です。 情報システムでもプログラムでも、何かを作り始める前には対象の全体を把握し、矛盾なく取りまとめる必要があります。 それには、一つの技術領域だけ知っていても駄目で、情報システムを形作るモノをバランスよく知り、経験する必要があります。 どんな人でも情報システムを作る作業に関わる時は大抵、製造やテスト、運用の工程から入ります。 これは、具体的な作業手順があったり、作るものが明確な工程なので経験が少なくても作業しやすいからですが、同時に情報システムがどういうものかを具体的に知る機会を与え、経験させるためでもあります。 いずれ要件や設計などの上流工程やマネジメントの仕事を目指したい…という人でも、実際の構築作業や運用作業の経験は、絶対にしておくべきです。 その経験や知見があなたを分厚く鋭くしてくれますが、その時にはただの作業としてではなく、知らないことを何か一つでも学ぶ・知るという姿勢を持つべきです。 5.さいごに 基本設計は、情報システムのあるべき姿をベンダの言葉で作り上げてまとめる、とても大事な工程です。 基本設計がお客様と合意されれば、お客様はそれが実現されるものと期待しながら、情報システムが出来上がるのを待ちます。 基本設計は、お客様とベンダとの間での最後の約束ごとだと言ってもいいでしょう。 基本設計が上手くいくかは、基本設計を行う担当者の実力とスキルと意識の持ち方次第です。 方法論はそれを補うものでしかありません。 基本設計のレビューを行うチームやプロジェクトやベンダの総合力も問われます。 また、基本設計ができる要員がいるかどうかが、情報システム構築の成否を分けるのです。 基本設計を上手に出来る力を持つ要員を育てるには、長い時間と広い経験が必要です。 長期的な視点での人材育成を我慢強く行えるかが、情報システムを提供するベンダの将来を左右する重要なことでもあります。 必要になって初めて慌てて周囲を探してみても、そういう要員を見つけることは難しいでしょう。 自分の仕事の領域を、設計工程やもっと上流に進めたいというエンジニアは、普段から情報システムの設計とはどういうものか、どうあるべきかを強く意識して、普段の仕事や作業に取り組み、情報収集しましょう。 設計とは、製造やテスト、運用の延長線上にあるように見えて、かなり違った領域の仕事なのです。 私たちは 「技術力」だけでなく 「人間力」の向上をもって遙かに高い水準の成果を出し、関わる全ての人々に感動を与え続ける集団でありたいと考えています。 高い水準で仕事を進めていただくためにも、弊社では次のような環境を用意しています。 定年までIT業界で働くためのスキル(技術力、人間力)が身につく支援• 「給与が上がらない」を解消する6ヶ月に1度の明確な人事評価制度• 平均残業時間17時間!毎週の稼動確認を徹底しているから実現できる働きやすい環境 現在、株式会社ボールドでは「キャリア採用」のエントリーを受付中です。 まずは以下のボタンより弊社の紹介をご覧いただき、あなたの望むキャリアビジョンをエントリーフォームより詳しくお聞かせください。

次の

基本設計とは?詳細設計とは?仕様書との違い、書き方、目次、成果物とサンプル (外部設計と内部設計)

基本設計書 テンプレート

はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書(仕様書)」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 <ご注意> 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する• 上は特に、設計フェーズよりも後々(例えばシステムテストや、保守や、機能追加時)に設計書を"漁る"場面で有効です。 まず初めに章立てを考える• 章立てを考えることは、設計書を設計すること、といえます。 できれば、章の見出しだけを書いた状態で然るべき人に見てもらうと、根本的な認識ズレのリスクが減らせます。 これは設計書でもプレゼンでも、どんな文書でも同じだと思います。 一行あたりの文字数に気を配る• A4横の書式で、横にながーい文章を書く人がいますが、私はとても読みづらいです。 一行あたりの文字数の最適解• ググると、横書きの場合は30〜35文字を勧めているWeb記事が多いようでした。 私の中では、設計書では40文字までということにしています。 読みやすさと、1ページあたりの情報量とのバランスです。 40文字に確たる根拠はないです。 でも、「一行80バイト」というとピンと来る方もいるのでは…• 文字数は各個人の基準でよろしいかと思います。 要は「気を配るべき」という主旨です。 一文を短くする• 長い文は、構造が複雑になりがちで、誤解を生むリスクが高まります。 個人的には「一文二行以内(つまり80文字以内)」を目安にしています。 三行に渡ってしまう文は、分解できないか検討しています。 箇条書きを使う• 項目の列挙によって長くなる文は、大抵は箇条書きに変換できます。 構造が複雑な文を分解する際にも、箇条書きが有効な場合が多いです。 図を使う• 人間は文字よりも図の方が直感的に理解できます。 特に全体像を示す際には図は文字よりも雄弁です。 表を使う• これは障害を防止する上で大変重要な意味があります。 複雑な条件を文字だけで定義しようとすると、読み手に誤解を与えます。 インデント(字下げ)を使う• インデントは、読み手に対して文章構成を視覚的に理解してもらうための、効果的な手法です。 主語を統一する• 設計書では通常「システム」か「ユーザー」、どちらかが主語かと思います。 どっちじゃないと絶対ダメということはないと思いますが、少なくとも文書内で統一しましょう。 ちなみに私は設計書では基本的に「システム」を主語にするようにしています。 用語を統一する• 同じ機能、同じ概念は、一言一句同じ用語を使いましょう。 同じことを別の用語で記載しないようにしましょう。 例:「日締め」「日次締め」「日締処理」• 些細なことのようですが、システム開発においては、担当者間の些細な認識のズレが大問題を引き起こすことが多々あります。 プロジェクト内で用語集を作りましょう。 略語についても用語集に記載するか、または文書冒頭に「Ruby on Rails(以下、RoRと記載)」という感じで書きましょう。 (「IT」など一般に浸透している略語を除く) 造語をしない• 良くありがちなのが日付関連です。 「実行日」「処理日」「当日」…• どこから取得するのですか?時刻を含みますか?タイムゾーンは?暦とズレる場合はありますか?• プロジェクト内で共通の概念であれば、用語集に定義を記載しましょう。 当該文書内に閉じた概念で、自分で作り出した用語であれば、その定義の項を作り、明確に記載しましょう。 表記ゆれを排除する 例:• 「サーバ」と「サーバー」• 「Web」と「ウェブ」• 「4月」と「4月」と「四月」• 「です・ます」と「だ・である」 自分専用のメモであれば、こんな些細なことを気にする必要はないのです。 しかし私は、読み手がいる以上、「こういうことで文書の良し悪しを判断する人がいるかもしれない」と考えた方が無難であると思います。 固有名詞は正確に• 例えば、「JAVA」は誤記、正しくは「Java」。 プロダクト名や企業名については勘違いして覚えていることが多いので、大文字小文字、単語間の空白の有無など、キチンと調べて正確に書きましょう。 チームをリードする際に心がけていること 私は、設計書の良し悪しに影響するのは、個人の努力や心がけよりも、チームとしての取り組みの方が大きいと思っています。 チーム全体として、設計書の書き方に統一感がないと、第三者にとっては設計書全体の価値が低く見えてしまいます。 記載粒度の認識を合わせておく• 基本設計書と詳細設計書で、どちらに何をどこまで書くか、みたいなことです。 必要以上に細かく書きすぎると、メンテナンスが追いつかなくなり、結果として誰も設計書を見なくなります。 章立ての記載方法を合わせておく あくまでも一例ですが、 1.xxx 1.1.xxx 1.1.1.xxx (1)xxx 全角/半角どちらにするのか、インデントするのか否かも含めて、細かく決めておくと良いです。 設計書を量産する前にサンプルを作っておく• 設計書のレビューアーとなるエンジニアがサンプルを作ると良いです。 サンプルを作ったら、「見ておいてね」だけではなく、どのように書いて欲しいのか、サンプル作成者の想いを全員に説明する場があると良いです。 テンプレートはなるべくシンプルに• 罫線の引き過ぎは生産性を落とします。 型にはめようとしすぎると内容が薄くなります。 フリーフォーマットの方が適切に表現できる場合もあります。 確かに体裁も品質の一部であり大切ですが、バランスのとれたテンプレートを作りましょう。 変更履歴の残し方について決めておく• それに対して「読みづらい!」と文句を言うメンバーが出て来たり(それは私)• Excelから脱却して、Markdownとかにして、バージョン管理システムに入れるのが良いのでしょうが…(政治的な要素もあったりして)なかなか難しい。 変更履歴シートを作って、どのシートのどの箇所をどのように直したか記載するのが現実的な落とし所でしょうか。 以上のような事項をガイドとしてまとめておく• レビューがスムーズ• メンバーが入れ替わった際に説明がスムーズ• どんなに忙しくてもガイドのメンテナンスをサボるべからず まとめ• 文章書きの上達のためには、訓練しかありません。 一番大事なのは、身近に厳しく添削してくれる方がいること、だったりします。 ということで、この文書に至らない点がございましたら、コメント等でお知らせください! (2018年2月15日追記) 多くのフィードバックをいただき、誠にありがとうございます。 あくまで私個人の経験則に基づく記事ですので、過不足・思慮不足はあるかと思います。 皆様の開発現場に合うように改編していただき、ご活用ください。 私は、教育やガイドによって「設計書の書き方」をチーム内で合わせておくことで、設計レビューにおいて「設計そのもの」に注力できるようになれば良いな、と考えています。 (2018年3月11日追記) 「一行あたりの文字数〜」、「一文を短くする」、「箇条書きを使う」について、表現を見直しました。 主旨は変わっておりません。

次の

Visual Studio Codeでソフトウェア設計書(Word文書)を書く環境を作る(設計書のテンプレートを作る)

基本設計書 テンプレート

基本設計とは情報システムを作る工程の一つで、情報システム全体を機能単位に分割して、それぞれの機能がどういうものか、どういうことができるものか、機能同士がどうつながるのか決めていく作業です。 基本設計を行うタイミングは、要件定義の後、詳細設計の前になります。 基本設計とはどういうものか…については、全ての関係者が納得する一つだけの答えはありません。 なぜなら、情報システムを作る作業には、法律や業界団体などで決められた、決定版ともいえる手順や成果物がないからです。 情報システムを作る人、プロジェクト、会社、方法論ごとに作業の仕方が違うのです。 それでも、広く共通しているのは、基本設計は情報システムの具体的な姿を、全体的な観点で考え始める工程だということです。 要件定義で決められた、情報システムで実現しなければならないことを、どうやって具体的な画面・帳票・バッチ処理・データベースで実現するかを、みんなで考えるのです。 この記事では、基本設計とはどういうものかを、情報システム構築の初心者向け、情報システム構築に興味がある方向けに、分かりやすくお伝えします。 1.基本設計では情報システムの全体像を考える 1-1.基本設計は何をどう作るかを決めるもの 基本設計は、情報システムを実現するために何をどう作ればいいのかを決める作業です。 情報システムを作る作業の中では、要件定義の次にある作業です。 基本設計では以下のようなことを行います。 情報システムの画面や帳票、バッチ処理などの作るべき機能を全て洗い出す• それぞれの機能が、どういうことをする機能か明確にする• 機能の間の関係性、特に入出力するデータを明確にして、情報システム全体で業務をどう行うか決める• 情報システムで持つデータを、どういう形式・項目として扱うか決める• 連携先の既存情報システムとどんなデータをやり取りするかを決める• どんなハードウェアやミドルウェアを組み合わせれば、要件が実現できるか考える 1-2.基本設計のインプットとアウトプット 基本設計のインプットは要件定義書です。 情報システムを作る工程の最初は要件定義で、そのアウトプットが要件定義書です。 基本設計のアウトプットは、その後の詳細設計のインプットになります。 基本設計は、要件定義書にある情報システムとしてのあるべき姿を実現するために、どういう方法で具体化するのか、どういうものを実際に作らなければならないかをプログラムを作り始める前にしっかりと決めて、アウトプットとして形にする作業なのです。 基本設計は情報システムとしての大枠、全体像、アウトラインとも言えるものを決める段階ですから、どのようなモノを使って実現されるか…例えばどのようにプログラミングされるかとは、少し距離を置いた抽象的なポジションで考えます。 1-3.基本設計はお客様と完成形をすり合わせる最後の機会 基本設計は、お客様が SIerに注文した情報システムがこうなるはずだという姿を、お客様自身が確認できる最後の機会であることが多いものです。 基本設計が進んでいく中で、画面の流れや帳票のイメージ、それらを使った業務の流れが分かるようになった時点で、お客様にレビューをしていただきます。 レビューでのお客様からの指摘事項や情報システムへのご要望は、基本設計のアウトプットに反映して再レビューします。 こうして認識のずれを防ぎます。 なお、お客様が IT企業の情報システム部門など、情報システムの知識がある人たちなら、詳細設計以降のアウトプットを都度確認することも普通です。 でも、 ITの知識がないお客様だと、情報システム構築の知識がないことが当たり前なので、詳細設計以後のアウトプットを理解することが難しくなっていくのです。 1-4.外向けの設計と内向けの設計 知っておいていただきたいのは、基本設計は情報システムが形作られるべき姿を、情報システムの外から眺めたものと、内から眺めたものの二つの観点から作るものだということです。 外から眺めたものとは、例えば画面のデザインや画面間の遷移、出力される帳票のレイアウト、関連する情報システムとのデータのやり取り、そして情報システムを使った業務の流れです。 ですから、情報システムが形になった後、お客様がこういうように使えるようになるはずだ、というものでもあります。 内から眺めたものとは、情報システムの作られ方に関係するものです。 お客様が使う画面の裏には、画面を表示するためのプログラムやデータを保存するデータベース、そしてシステムとしてそれらがどう組み合わさるかという、いわゆる「アーキテクチャ」があります。 基本設計はそれを決めるものでもあります。 2.基本設計のアウトプット 基本設計で作るアウトプットは、大体は以下のように分類されます。 もちろん、現場や SIerにより呼び方が違いますし、どんなやり方で情報システムを作るかで、作る必要があるものも変わってきます。 例えば、オブジェクト指向分析がベースの開発方法論なら、これ以外にも作るものがあります。 基本設計では、要件定義書の内容から、情報システム全体を機能に分割・分類して、それらの機能レベルで情報システムではどういうことをどう行うかを考えます。 同時に、情報システム上でデータをどう持つか、連携先のシステムとはどう連携するか、どういうハードウェアやネットワークとするかも考えます。 そして、基本設計の時点では、各機能や処理にはどういう入力があり、どういう処理が行われ、どういう結果が得られる…という「流れ」を重視します。 ですので、基本設計では処理の詳細までは踏み込まず、「この機能はこういうことができる」という観点で設計を進めていきます。 2-1.システム全体の機能を一覧化し、流れをまとめる アウトプット:機能一覧、業務フロー図、データフロー図、入出力関連図など 基本設計でまず作るものは、情報システムを形作る機能の一覧です。 基本設計が終わった時点では、情報システムで作るべきモノが全体でいくつあるのかが、具体的な数字でわかるようになります。 この機能の一覧は、基本設計の作業の進み具合や、情報システムの規模を正確に把握するためにも欠かせません。 この「機能」の単位はいろいろです。 画面、帳票、バッチ処理、 APIなどの同じモノの単位で一覧を作ることは普通ですし、もっと上位の「業務」とでも呼べるものでグループ化した上で、その中にはどんな画面、帳票、バッチ処理、 APIなどのサブ機能があるのか…という風にまとめることも普通です。 前述したとおり、機能の一覧は基本設計の最初に作り始めますが、最初から全ての機能を一覧にはできません。 要件定義書を見ながら、「この業務はこれとあの画面を使ってこうやるから…」とか「このデータを作るにはこの処理が前にあって…」という検討や試行錯誤をしながら、だんだん育てていくものです。 2-2.画面の役割と画面のつながりを業務視点で考える アウトプット:画面一覧表、画面遷移図、画面設計書、項目定義書 画面 など 情報システムの「顔」がいわゆる画面です。 基本設計では、どういう画面があるのか、その画面では何ができるのか、その画面にはどういう項目があってどう表示されるのか、画面間の繋がりはどうなのかという設計を行います。 要件定義である程度作られている画面を、さらに明確にすることも普通です。 この作業では、画面のレイアウトや、例えばボタンをクリックした時には情報システムがどんな動きをするのか 表示の更新、データ保存など を決めます。 そして、情報システムは複数の画面を持つことが普通ですから、それらの画面遷移がどういう条件でどういう時に行われるかなども明確にしていきます。 そして、画面は情報システムを使うお客様がいつも使うものですから、どういう画面にするかでお客様の情報システムへの印象が大きく変わります。 ですので、ユーザインターフェイス UI の専門家や、最近はユーザ体験 UX の専門家も交えて、喧々諤々な議論が行われることもあります。 2-3.どんな帳票をいつどうやって出すかを考える アウトプット:帳票一覧表、帳票設計書、項目定義書 帳票 など 情報システムに欠かせないのは帳票です。 前述した画面も広い意味では帳票の一種だと言えますが、ここで言う帳票は受注伝票や入金伝票などの業務上必要になるものや、 PDFや Excel、 CSVなどで売上高などの集計値を提供したり、お客様がデータをダウンロードして二次活用できるようなもののことです。 基本設計で考える帳票設計では、いつ、だれが、どんな情報を、どういう形式や書式で、どこから出力するか決めていきます。 帳票は画面で入力する検索条件やデータベース設計にも密着していて、関連する機能を一緒に考えながら徐々にブラッシュアップしていくものなので、最初から決定版は作れません。 基本設計で帳票を考える時は、まだこの時点では動くモノはないので、基本的には全て机上の紙や設計者の頭の中で考えます。 どうやって帳票を作るのかのロジックはもちろん考えますが、画面の入力条件がこうで、こういうテーブル構造ならこの帳票はこう作れるだろう…という「予想」の元に作業が進みます。 2-4.バッチ処理をシステム全体視点で考える アウトプット:バッチ処理一覧表、バッチ処理フロー図、バッチ処理設計書など 情報システムでは、画面や帳票以外の処理、いわゆるバッチ処理があります。 バッチ処理は情報システムの裏で動き、お客様の目には直接触れませんが、画面や帳票を情報システムが提供するには欠かせません。 さらに、バッチ処理がうまく流れるかは、情報システムでの業務が上手く流れるかとイコールです。 基本設計では、どういうバッチ処理があるか、それぞれのバッチ処理ではどういう情報を入力として何を出力するか、どういうタイミングで動くのか、バッチ処理同士の前後関係、連続するバッチ処理が途中で異常終了したらどうフォローするか…などを決めていきます。 バッチ処理を考える上で大事なのは全体視点です。 一つ一つの処理は入出力や処理がわかりやすいように上手に分割して、それをうまく組み合わせて大きな一つの処理結果をどうやって作っていくかを考えます。 ですので、細かいことを考えて組み合わせるのが好きな人は、バッチ処理が面白いかもしれませんね。 2-5.データベースで持つデータを考える アウトプット:テーブル一覧表、テーブル設計書、ER図、CRUD図など 今まで説明してきたのは「処理」でした。 でも、処理だけでは情報システムは作れません。 情報システムで扱うデータをどう保存し、必要に応じて検索結果としていろいろな処理へどう提供するかを考えなければなりません。 ここで行うのは、いわゆるデータベースの設計です。 基本設計でのデータベースの設計は、どのような種類のデータベースを使うのか、使うと決めたデータベースでどのようにデータを管理するのかを決めます。 最近はリレーショナルデータベース以外のプロダクト いわゆる NoSQLなど も普通に使いますので、その関連知識も基本設計では求められることがあります。 例えば、一般的なリレーショナルデータベースを使うなら、要件定義から抽出したデータからテーブルを考え、どのような項目を持つか、インデックスにはどの項目を使うのか、テーブル間の関係がどういうものかなどを決めます。 大きな情報システムなら、全体で数百以上のテーブルになることも普通です。 2-6.システムの要件を実現できる構成を考える アウトプット:システム構成図、運用設計書など 情報システムは、今までお伝えしてきたアプリケーション側の領域と、サーバ・クライアント PCなどの OS・ハードウェア、ネットワークなどのインフラストラクチャ Infrastructure、いわゆるインフラ 側の領域の二つから作られています。 どちらが欠けても、情報システムは動かせません。 基本設計では、インフラ側の担当者がアプリケーション側の担当者と一緒に、どのようなハードウェアやネットワークの構成にすれば、要件定義で決められた処理性能や可用性や運用性などのいろいろな要件・非機能要件を満たすことが出来るかを考えます。 それらにかかるコストも、欠かせない検討項目です。 処理速度やデータを保存する領域の余裕をどのくらい持つか、情報システムの将来の拡張性はどう確保するか、ハードウェアの故障が発生した時はどうするか…など、インフラに求められるほぼ全てを基本設計の時点で予測し、対応方針を決め、必要なものを確保・発注するのです。 2-7.考えたことがきちんと全てつながるかを考える ここまでの記述で、「全体視点」という言葉が何回か出てきました。 基本設計を行う上では、作業を行う人にこの全体視点があるかがとても大事です。 何かの機能に偏った狭い視野ではなく、情報システム全体視点での広い視野が、基本設計でのアウトプット間の矛盾を見つけ出すのに必要となるのです。 基本設計では、まだプログラムとしての形が何もない時点で、最終的に出来上がる情報システムを想像しながら、全てが最後には一つにつながる前提でいろいろなアウトプットを作ります。 なので、業務知識、予測能力、想像力、論理的思考能力、問題領域の把握能力というようなものが、担当者には強く必要です。 しかも、情報システムの規模が大きくなればなるほど、全体像の把握は急激に難しくなります。 そのような情報システムの基本設計を取りまとめるには、大変な労力が必要になるのです。 3.要件定義と基本設計と詳細設計の違い この章では、情報システムを作る当事者以外の人、あるいは当事者であっても混乱しがちな、要件定義と基本設計と詳細設計の一般的な違いをお伝えします。 要件定義と基本設計と詳細設計は、いずれも情報システムのあるべき姿を考えるという、広い意味では設計の作業です。 そして、情報システム構築の方法論は世の中にはたくさんあり、それらの中では必要なアウトプットをどの工程で作っていくのかがずれていることも多いものです。 ですから、いくつかの現場や情報システムを渡り歩いた人は「なぜこの現場ではこのアウトプットをこの工程で作るの? 」という疑問を持ったりもしますし、同じ「基本設計」と呼ばれていても、作るものの内容や記述するレベルの認識が合っていなかったりするものです。 3-1.違いは誰向けのアウトプットであるか 要件定義と基本設計と詳細設計の違いは、誰向けのアウトプットなのかという観点が最も大きいと思われます。 要件定義はお客様と情報システムのあるべき姿を合意するためにあります。 ですから、お客様が理解できる言葉や図を使います。 基本設計は、要件定義の内容を情報システムの言葉に置き換えたものであり、どういう情報システムになるかを決めるものです。 ですので、お客様が出来上がる情報システムを確認するためにも使いますし、 SIerがどういうシステム構成にするかを明確にするものでもあるのです。 詳細設計は、完全に SIer側の言葉になります。 プログラムに落とし込まれる直前の状態ですから、使われる言葉や図も専門的なものになり、プログラマが読み込んで、出来上がるプログラムがイメージできる程度にまで、情報システムが動くべき手順が詳細に書かれるものです。 3-2.小さな案件ではこれらの区別はあまりない SIerが情報システムを作る時は、大体はこのような区別をして、工程の説明をお客様にするはずです。 ただ、大規模な情報システムならまだしも、小規模なものならこれらの作業は一体となっていることがあります。 お客様との「距離感」と言うべきものが近ければ、それでも十分だというケースも多いでしょう。 要件定義~基本設計~詳細設計と続く作業の流れは、ウォーターフォール型の情報システム開発の典型例ですし、批判も多くあります。 ですが、「何をどう作るのか」を段階的に明らかにして、なるべく手戻りがないように進めるのは、情報システムを作る上での王道ですし、何にしろ必要なことでもあります。 結局は「何をどう作るのか」が明確になっていて、お客様と合意がされていればいいのです。 開発方法の主流の一つになりつつあるアジャイルも、誤解を恐れず言うなら、お客様と SIerの距離を近くすることで認識齟齬が起きづらい開発体制を作って、素早くモノを作る、ということです。 目的は変わりません。 3-3.外部設計、内部設計との関係 基本設計を外部設計、詳細設計を内部設計と呼ぶことがあります。 基本設計では、情報システムを「外」から見た時の姿や動きを決める成果物が多いからです。 一方、詳細設計では情報システムの外面が決まった後に「内 なか 」がどうあるべきかを細かく決めていくので、内部設計と呼ぶのです。 ただ、繰り返しですが、情報システムを作る作業に関係する言葉は、同じ言葉でも SIerなどの文化や方法論で指すことがかなり違うので、どういう意味か有識者に確認しておいた方がいいでしょう。 4.基本設計を行う上で大事なコト この章では、基本設計をする上で押さえておきたい注意点や心構え的なものをお伝えします。 基本設計が上手くできていないと、後の工程が全て上手くいきません。 これらは、そういう悲劇を少しでも少なくするために、基本設計の担当者が知り、意識しておくべき事柄です。 大事なのは、全体視点を持って作業をすること、前工程である要件定義との整合性が取れていること、自信を持って作ることができるものであることです。 そして、基本設計の時点では完全無欠なアウトプットは残念ながら作れませんので、手戻りがあることを前提に作業を行うことも意識しておきたいです。 4-1.全体視点を持っていること 基本設計では、情報システムへの「全体視点」が欠かせません。 この全体視点には、情報システムの機能全体を見渡し把握するための、高く広い視点の他にも、お客様の視点、 SIerの一員としての視点、詳細設計・製造・テスト・構築・運用・保守をする要員の視点…という全関係者の立場での視点も含みます。 「この人の立場では、この情報システムはどう見えるだろう、使い勝手はどうだろう」という視点は、情報システムを作る最初、つまり基本設計の時点で組み込まれていなければなりません。 その視点のない情報システムは、要件を形や見た目だけにただ単に反映したものに過ぎず、「使える」ものではありません。 全体視点を持つ、視点を切り替えるには意識的な訓練が必要です。 そして、その立場で仕事をした経験が実際にあるなら、さらにいいでしょう。 ですから、基本設計に限らず上流工程の要員は、何かの領域に熟達している以外にも、今まで情報システムに関するどういった仕事をしてきたかが、必ず問われるのです。 4-2.要件定義とずれていないこと 基本設計が要件定義とずれていないかは、とても大事なことです。 基本設計に書かれていることは、元をたどればすべて要件定義のどこかの記述にたどり着く、というくらいでなければなりません。 それくらいしっかりと基本設計を作って残せば、お客様も含め、後に関わる人がすべて幸せになれるのです。 今までお伝えしてきたとおり、要件定義はお客様の言葉・視点での情報システムのあるべき姿であり、基本設計は SIerの言葉・視点での情報システムのあるべき姿です。 基本設計の時点で要件定義から言葉の「翻訳」が行われるので、要件定義と基本設計がずれていると、後工程の成果物が全てずれるのです。 基本設計は、情報システムで何か分からないことがあった時の拠り所です。 情報システムを作る時だけでなく、運用する時も、障害が起きた時も、改修する時も、次の情報システムに移行する時も、そのすべてにおいてです。 情報システムに関わる人は移り行きますが、基本設計は常にそこにあり続けるものです。 4-3.実際に作れるものであること 基本設計をする時は、まだ具体的な形がないだけに、いろいろと内容を盛り込みがちです。 しかし、基本設計は「こういうことができたらいいな」ではなく、「こうすればできる」「こうしなければならない」という明確な根拠ありきで進めるものです。 そうしないと、実際には作れない情報システムになります。 過去に担当した情報システムでの反省を生かして、今回は同じ失敗はしないという意識を持つことは大事です。 最近は既存の情報システムの改修や統合が多くなっていて、新しく情報システムを作る機会は減っているので、基本設計をする時にそう思うのは当然ですし、前のめりにもなるのは分かります。 ですが、情報システムは基本設計をする人の私物ではありませんし、趣味や嗜好や主義で作るものでもありません。 情報システムはチームで作るものです。 何かの設計には必ず明確な理由・意図があって、設計・製造をする人たちの間で合意が得られていて、かつ実際に作れるものでなければ意味がないのです。 4-4.設計の手戻りがない、はありえない 情報システムを作る仕事を続けていると、手戻りの無い工程はありえないことが分かります。 理想は前工程の精度を上げることですが、現実には限界があり、手戻りゼロは不可能です。 実際にやらないと分からないことはいまだに多いのです。 設計の工程は特に、机上や頭の中だけの考えなのでなおさらです。 手戻りがあることを前提に、取り得る選択肢や代替手段を考えておくのも、基本設計でやるべきことです。 さらに設計上のリスクに関しては、基本設計の時点でお客様に伝え合意することも大事です。 手戻りが発生しうるという現実に、どれだけ予測し準備できるかが、マネージャや SIerのノウハウであり実力です。 そして、基本設計後に詳細設計や製造をする際、設計上の問題を見つけたとしても、絶対に基本設計を変えてはならないわけではありません。 設計は都度変わっていくものです。 設計の変化に情報システムが追随するのは大変難しいのですが、避けられないことなのですから、準備はしておかねばならないのです。 4-5.設計作業にこそエンジニアのスキル・実力が問われる エンジニアのスキル・実力が本当に問われるのは設計作業です。 情報システムでもプログラムでも、何かを作り始める前には対象の全体を把握し、矛盾なく取りまとめる必要があります。 それには、一つの技術領域だけ知っていても駄目で、情報システムを形作るモノをバランスよく知り、経験する必要があります。 どんな人でも情報システムを作る作業に関わる時は大抵、製造やテスト、運用の工程から入ります。 これは、具体的な作業手順があったり、作るものが明確な工程なので経験が少なくても作業しやすいからですが、同時に情報システムがどういうものかを具体的に知る機会を与え、経験させるためでもあります。 いずれ要件や設計などの上流工程やマネジメントの仕事を目指したい…という人でも、実際の構築作業や運用作業の経験は、絶対にしておくべきです。 その経験や知見があなたを分厚く鋭くしてくれますが、その時にはただの作業としてではなく、知らないことを何か一つでも学ぶ・知るという姿勢を持つべきです。 5.さいごに 基本設計は、情報システムのあるべき姿をベンダの言葉で作り上げてまとめる、とても大事な工程です。 基本設計がお客様と合意されれば、お客様はそれが実現されるものと期待しながら、情報システムが出来上がるのを待ちます。 基本設計は、お客様とベンダとの間での最後の約束ごとだと言ってもいいでしょう。 基本設計が上手くいくかは、基本設計を行う担当者の実力とスキルと意識の持ち方次第です。 方法論はそれを補うものでしかありません。 基本設計のレビューを行うチームやプロジェクトやベンダの総合力も問われます。 また、基本設計ができる要員がいるかどうかが、情報システム構築の成否を分けるのです。 基本設計を上手に出来る力を持つ要員を育てるには、長い時間と広い経験が必要です。 長期的な視点での人材育成を我慢強く行えるかが、情報システムを提供するベンダの将来を左右する重要なことでもあります。 必要になって初めて慌てて周囲を探してみても、そういう要員を見つけることは難しいでしょう。 自分の仕事の領域を、設計工程やもっと上流に進めたいというエンジニアは、普段から情報システムの設計とはどういうものか、どうあるべきかを強く意識して、普段の仕事や作業に取り組み、情報収集しましょう。 設計とは、製造やテスト、運用の延長線上にあるように見えて、かなり違った領域の仕事なのです。 私たちは 「技術力」だけでなく 「人間力」の向上をもって遙かに高い水準の成果を出し、関わる全ての人々に感動を与え続ける集団でありたいと考えています。 高い水準で仕事を進めていただくためにも、弊社では次のような環境を用意しています。 定年までIT業界で働くためのスキル(技術力、人間力)が身につく支援• 「給与が上がらない」を解消する6ヶ月に1度の明確な人事評価制度• 平均残業時間17時間!毎週の稼動確認を徹底しているから実現できる働きやすい環境 現在、株式会社ボールドでは「キャリア採用」のエントリーを受付中です。 まずは以下のボタンより弊社の紹介をご覧いただき、あなたの望むキャリアビジョンをエントリーフォームより詳しくお聞かせください。

次の