↓まだチャンネル登録をしていない人はこちらから！↓<a href="https://www.youtube.com/channel/UCytjAXJpeqzSotBHYJ7lMqQ" target="_blank" rel="noopener noreferrer">【click】YouTube エンジニアファースト</a>

今回は我々、グラントホープがなぜエンジニアの独立支援をしているのか？ なぜエンジニアファーストというチャンネルを立ち上げたのか？ そんな話をしています。15分だけ時間をください。

動画はこちらからご覧ください。 <a href="https://m.youtube.com/watch?v=48BimW3jTHs" target="_blank" rel="noopener noreferrer">https://m.youtube.com/watch?v=48BimW3jTHs</a>

【独立を迷っているエンジニアに伝えたいこと】

猫が大好き。食べることが大好き。寝ると嫌なことは忘れるタイプ。
いろんな人に出会い、いろんなものに触れて、思考を柔らかく、自分の世界を広げていきたい駆け出しライターもどき。


こんにちは！タカトです。 &nbsp; 2022年からちょくちょく話題に上がっていたインボイス制度。皆さんは具体的にどういった制度か把握してますか？会社員の方は特に意識する必要はありませんが、副業でそれなりに稼いでいたり、個人事業主・フリーランスの方は意識しないと今後の仕事に影響が出てきます。今回はそんなインボイス制度について解説していきます。 &nbsp; できるだけシンプルかつ分かりやすくお伝えしてきますので、インボイスが気になるぐらいの感じで読んで頂いて大丈夫です！時間にして3分ほどで読めるのでランチやお茶のお供にどうぞ！

インボイス制度はシンプルにいうと、消費税を払わせる制度です。 &nbsp; 消費税は物を購入した際に商品購入代金と一緒に払っていますが、その消費税とは別であなたが個人で請け負った仕事に対する消費税のことを指します。（詳細は後述で解説します） &nbsp; 消費税を払った人には適格請求書発行事業者として番号が発行されます。 適格請求書発行事業者になるためには課税事業者になる必要があり、課税事業者になる＝消費税をしっかり払いますということです。

消費税をなぜ今更払うのか？今まで免除されてた理由は？

ここで質問です。 &nbsp; あなたが物を購入し10%の消費税が掛かりました。お店には商品代＋消費税を支払いますが、この10%の消費税は誰が国に払っているか？ &nbsp; 答えはお店が代わりに国に払っています。 &nbsp; お店、または会社は毎年確定申告を行っており、その際に貰った消費税をまとめて国に支払っているワケです。 &nbsp; 次に、あなた自身が個人で仕事を受注し請求書が来ました。その請求書には売上の10%の消費税が加算され、振込の金額として提示されてます。（売上が10万だったら11万が振込対象額。1万は消費税。） &nbsp; ではこの消費税は誰が支払っているでしょうか？ &nbsp; 多分、この回答は言葉に詰まると思います。 &nbsp; 本来であればお店と同じであなたは消費税を受け取っているので、それを国に支払う必要があります。 &nbsp; これを払わなくて良いのには理由があって、売上が一千万以下の個人事業主は免税事業者と呼ばれて、消費税を支払わなくてよいとされているからです。 &nbsp; なので知らぬ間に脱税してた！？といったことにはなりません。 &nbsp; インボイス制度が施行されると、売上が一千万以下の個人事業主も課税対象者になり、毎年売上の10%を国に納める必要があります。

インボイス制度の施行は2023年10月1日からになります。 &nbsp; なので2024年に行う確定申告ではインボイス制度を考慮した申告が必要になります。 &nbsp; 各種会計ソフトもそれに向けて対応を実施中です。

適格請求書発行者って何なのか？番号は無いとダメなの？

適格請求書発行者になると番号が発行されます。番号を発行しない（適格請求書発行者にならない）選択も可能です。 &nbsp; では番号あり／なしでどういった違いがあるのでしょうか？ &nbsp; あなたに仕事を依頼する会社からすると、番号あり／なしでの違いは国に納める消費税分を全額免除できるか、できないかの違いがあります。 <img src="https://images.microcms-assets.io/assets/03df7942ab184c4fb92ae2a6d548e115/f466d12227d94fe2a6d56a13bbff7eca/image2.jpeg" alt=""> 会社からしたら、番号がない人と取引するのはデメリットしかないんです。 &nbsp; こうなると個人は仕事の受注にモロに影響が出るので、実質番号あり（自身で消費税を納める）を選択せざるを得ないのが実状です。

適格請求書発行者になると収入はどれだけ下がるのか

適格請求書発行者になるということは消費税を新たに納めるということです。 &nbsp; 2023年現在、消費税は10%なので、自身の年間売上が300万の人なら年30万、500万なら50万の税金が新たに発生します。 &nbsp; 消費税が上がれば、この税金もどんどん上がっていきます。 &nbsp; ただでさえ多くの税を払っているのに、更にまた税金が重くのしかかる。中々厳しい現実ではあります。

インボイス制度が反対される理由

インボイス制度は今まで対象外だった免税者（売上が一千万以下）から消費税を徴収する制度というのはお分かり頂けたかと思います。 &nbsp; 売上が100万円の人も10万という額を追加の税として納める必要が出てくるので、売上が少ない人にとっては死活問題で、反対されるのは当然の結果です。 &nbsp; 実際、エンタメ業界へのダメージがかなり大きいと言われています。 <a style="color:#1155cc" href="https://maidonanews.jp/article/14719374" target="_blank" rel="noopener noreferrer">「インボイス制度は日本のエンタメ業界を破壊する」　声優の甲斐田裕子が反対の声を上げる理由</a> &nbsp; これで徴収しても300億程度にしかならないので、反対されるのも無理はありません。

インボイス制度施行に向けて出来ること

正直この制度は個人事業主にとってはかなり痛い制度です。 &nbsp; とはいえ決まってしまったのは仕方ないので、出来ることとして売上額を上げるのが一番だと筆者は感じます。結局10%もっていかれるなら売上額を上げて少しでも税の負担を減らすのが今できる最善の策です。 &nbsp; もう1つはインボイス制度に対しての対応は会社によって様々なので、そこをお世話になってる会社に確認し、より良い対応をしている会社を選びなおすという手段です。 &nbsp; 例えば適格請求書発行者にならなくても良いや、その税の分を上乗せして支払ってくれるなど対応は様々かと思います。 &nbsp; グラントホープは業界的にレアな対応をしており、適格請求書発行者になることを止む無しと感じているエンジニアや個人事業主の人はグラントホープなら心配ない対応を取っています。 &nbsp; 話を聞くだけでも全然良いと思うので、興味のある方は聞いてみてはいかがでしょうか。

まとめ：しっかり理解した上で施行されるまでに準備をしよう！

いかがだったでしょうか？2023年から年収の10%が減るのは目に見えたので、そこをどう補填するか事前に考えて準備すること、もしくはお世話になってる会社を見直すことが今できる策なのかなと思います。 &nbsp; もちろん、適格請求書発行者にならなくても問題はないです。 &nbsp; 実際、施行された時にどれだけの人がなるかは未知で、下手したら適格請求書発行者にならない人が多い可能性もあります。 &nbsp; 自分の将来に関わることなので、しっかり理解した上で自身が望む選択をしていきましょう！ &nbsp; 本日も読んでいただきありがとうございました。

インボイス制度とは？施行される前に抑えておきたいポイントを解説！

タカト

2児に父でフリーランス歴8年目、主にPMO・サポート業務をメインに案件をこなしています。Webライターとしても活動中。

PythonのWebフレームワークにはDjango、Flaskが良く使用されますが、今回はFastAPIというフレームワークを紹介したいと思います。 FastAPI は、Pythonの標準である型ヒントに基づいてPython 3.6 以降でAPI を構築するための、モダンで、高速(高パフォーマンス)な、Web フレームワークです。

FastAPIの特徴とDjangoとの比較について

・パフォーマスが高く、処理が早い

FastAPIはPythonの有名なWebフレームワークのDjangoパフォーマンスを比較しても、NodeJSやGoと同じくらいにパフォーマンスが高いと言われており、Djangoよりも処理が早いとされています。

・コードが書きやすく、バグ等も見つけやすい

コーディングもDjangoに比べて書きやすい特徴もあり、コードによる重複も最小限にしていることから、ヒューマンエラーよるバグも削減と開発速度の向上が見込まれています。

・習得にそれほど時間がかからない

FastAPIはDjangoに比較して簡単に習得できるようにデザインもされていることから、ドキュメントに読む時間やその他調査にかかる時間も短縮されます。

必要条件:Python 3.6以上 ※開発環境(動作はMac環境を使用しています。) OS: MacOS Big Sur 11.4 Python: 3.9.7 Django: 3.1.7 IDE: PyCharm &nbsp; Pycharmを起動して、左下の「terminal」をクリック

(Macのデスクトップの右上の虫眼鏡マークから「ターミナル」起動→指定した階層に移動でも構いません)

ターミナル上で以下のコマンドを入力してください。 pip install fastapi 以下のように「Successfully〜」と表示されれば問題なくFastAPIはインストールされています。

次に以下のコマンドを入力後、エンターキーを押してください。 pip install uvicorn こちらも問題なく、エラーメッセージが表示されなければ正常にインストールされています。

任意のディレクトリ配下にmain.pyを作成して、以下のコードを入力します。 main.py &nbsp;

&nbsp;以下のコマンドを実行します。 uvicorn main:app --reload &nbsp; ブラウザのURLバーに <a href="http://localhost:8000/" target="_blank" rel="noopener noreferrer">http://localhost:8000/</a> を入力してください。

{"Hello":"World"}と表示されていますね。 &nbsp; 先程作成した、main.pyの5行目から7行目にて @app.get("/") def read_root():　 　&nbsp; &nbsp;&nbsp;return {"Hello": "World"} @app.get("/") →@app.get("/")と書くことで、localhost:8000以降のURLを指定するパスになります。 ("/")と書くことにより、localhost:8000で動く関数ということになります。 def read_root(): return {"Hello": "World"} →@app.get("/")と書いてありますので、 uvicorn main:app –reload Webサーバーを起動した際にWebブラウザにて localhost:8000と入力した時に動く関数ということになります。 &nbsp; こちらのサンプルではread_rootという関数名にしていますが、任意の関数名に変えていただいても構いません。 returnも{"Hello": "World"}とありますが、こちらも任意の文字列に変えてもよいです。

では次にブラウザのURLバーにて <a href="http://localhost:8000/items/10?q=sample_fastapi" target="_blank" rel="noopener noreferrer">http://localhost:8000/items/10?q=sample_fastapi</a> を入力してください。

このように表示されていれば成功です。

解説をしていきます。 main.pyに記載をした@app.get("/")と@app.get("/items/{item_id}")の2つ関数がありますが、WebブラウザのURLにて、localhost:8000以降の/&nbsp;と&nbsp;/items/{item_id}のパスで HTTP リクエストを受けます。 /items/{item_id}&nbsp;パスのパスパラメータ&nbsp;item_id&nbsp;は&nbsp;int&nbsp;でなければなりません。 <a href="http://localhost:8000/items/10?q=sample_fastapi" target="_blank" rel="noopener noreferrer">http://localhost:8000/items/10?q=sample_fastapi</a> →こちらの10という数値がint型指定です。 パス&nbsp;/items/{item_id}&nbsp;はオプションの&nbsp;str&nbsp;クエリパラメータ&nbsp;q&nbsp;を持ちます。 <a href="http://localhost:8000/items/10?q=sample_fastapi" target="_blank" rel="noopener noreferrer">http://localhost:8000/items/10?q=sample_fastapi</a> →sample_fastapiの箇所がstr型となります。 @app.get("/items/{item_id}") def readitem(itemid: int, q: str = None): 　　&nbsp;return{"item_id": item_id,&nbsp;&nbsp;"q": q} 今回使用したURLですと、 http://localhost:8000/items/10 →10がread_item_idの第一引数の、item_id: intの箇所で <a href="http://localhost:8000/items/10?q=sample_fastapi" target="_blank" rel="noopener noreferrer">http://localhost:8000/items/10?q=sample_fastapi</a> →sample_fastapiがread_item_idの第二引数のq: str = Noneの箇所になります。 &nbsp; 試しに<a style="color:black" href="http://localhost:8000/items/%7bitem_id%7d" target="_blank" rel="noopener noreferrer">http://localhost:8000/items/{item_id}</a>の{item_id}の箇所にて、int(数値)以外の値を入れてみましょう。 WebブラウザでURLバーにて以下を入力してみてください。 <a href="http://localhost:8000/items/sample?q=sample" target="_blank" rel="noopener noreferrer">http://localhost:8000/items/sample?q=sample</a>

value is not a valid integer〜とエラーメッセージが出力されましたね。 &nbsp; では次に行きましょう。 WebブラウザのURLバーで以下を入力してください。 http://localhost:8000/docs &nbsp;

こちらの画面が表示されましたと思います。 こちらは自動対話型APIドキュメントです。 &nbsp; 次は以下のURLをWebブラウザで表示させてください。 http://localhost:8000/redoc

代替の自動ドキュメントが表示されます。

アップグレードの実装(PUTリクエスト)

PUTリクエストからボディを受け取る実装を進めます。 main.pyを修正しますので、黄色の部分を追加してください。 &nbsp; &nbsp; &nbsp; &nbsp; main.py &nbsp; from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class Item(BaseModel): &nbsp;&nbsp;&nbsp; name: str &nbsp;&nbsp;&nbsp; price: float &nbsp;&nbsp;&nbsp; is_offer: bool = None @apgep.t("/") def read_root(): &nbsp;&nbsp;&nbsp; return {"Hello": "World"} @app.get("/items/{item_id}") def read_item(item_id: int, q: str = None): &nbsp;&nbsp;&nbsp; return {"item_id": item_id, "q": q} @app.put("/items/{item_id}") def update_item(item_id: int, item: Item): &nbsp;&nbsp;&nbsp; return {"item_name": item.name, "item_id": item_id}

次は以下のURLをWebブラウザで表示させてください。 http://localhost:8000/docs

item_idに任意の数値を入力し ※画面の例の10以外の数値でも可

ユーザインターフェースはAPIと通信をして、パラメータを送信し、結果を取得して、画面下部に表示されます。 &nbsp; 次は以下のURLをクリックしてください。 <a href="http://localhost:8000/redoc" target="_blank" rel="noopener noreferrer">http://localhost:8000/redoc</a>

代替のAPIにも新しいクエリパラメータやボディが反映されています

このようにFastAPIは関数のパラメータとして、パラメータやボディ の型を宣言して、簡単にAPIエンドポイント定義と実装が可能になります。 &nbsp; &nbsp; 参考URL <a href="https://fastapi.tiangolo.com/ja" target="_blank" rel="noopener noreferrer">https://fastapi.tiangolo.com/ja</a>

PythonのWebフレームワークFastAPIの紹介

中川　彰吾

フリーランスSEで色々なWeb系の案件に参画中。言語はPythonやRuby
自宅でもパフォーマンスが落ちない様、リモートワーク中心の生活を過ごしながら、
IT技術だけでなく、英語や株式投資など学習中。


皆さん、こんにちは。 Sgiです。 今回はエンジニアに是非活用していただきたいサービスがありますので、この記事を執筆致します。 最後まで読んでいただけると嬉しいです。

年収査定ってやったことありますか？

筆者がおすすめしたいサービスとは「年収無料査定」です。 これ、あまり見かけないですよね？ 正社員SEはまた話が別ですが、フリーランスSEは一般的に &nbsp; エージェントへ登録 ↓ 面談（ヒアリング） ↓ 案件紹介 ↓ お客さんと面談 ↓ 合格 ↓ 契約 &nbsp; という流れでお仕事が決定します。 &nbsp;

しかし今回ご紹介する年収無料査定の違いは図の通りです。

こちらの図を見ていただければ分かりやすいですが、 エージェントでのヒアリングの時点で自分の報酬額がおおよそ分かる仕組みとなっています。

どうやって査定してもらえる？

そもそもどうやって査定額をだしているのか。 気になったので色々聞いてきました。 &nbsp; &nbsp; この年収無料査定をするには、事前に &nbsp; ①&nbsp;&nbsp;&nbsp;技術経歴書 ②&nbsp;&nbsp;&nbsp;プロフィール &nbsp; を作成する必要があります。 エンジニアなら誰もが作成したことがあるはずです。 それをこちらの会社フォーマットに書き直すだけで完了となります。 &nbsp; 年収無料査定をヒアリング前にすることで、より具体的な希望条件の話ができる、という仕組みのようです。 &nbsp; &nbsp; どうやって査定額を出しているのか、謎ですよね。 どんどん解説していきます。

こちらの会社で実際にご成約されたエンジニアのスキル感・契約単価をもとに査定額をだしているそうです。 &nbsp; 査定額と契約時に決定した単価の誤差は月額換算で「約2万円前後」だとか。 これは正確すぎる…。 &nbsp; 会社の実績に基づいた査定額ということでした。 &nbsp;

実際にご成約された方の年収アップ事例

これは一般論ですが、IT業界の場合 正社員からフリーランスに転身した場合、年収は約1,5～2倍以上になります。 &nbsp; 理由は割愛していきます。 &nbsp; 今からお見せする事例も、査定額と契約時の単価（月額）の誤差はやはり2万円前後のようです。 それでは一気にお見せいたします！！ &nbsp; 今回はスキル感も教えていただけましたので、ご参考までに見ていただければと思います。

こうみると、皆さん年収が確実にUPしているのがわかります。 &nbsp; &nbsp; 他エージェントは契約が確定するまで自分の報酬額が不明瞭ですが、 こちらの会社は案件を選ぶ前に自分のスキル感ではどれくらい報酬が貰えるのかが分かるため、収入が不安定と思われがちなフリーランスですが 先の見通しがつくことがメリットになりますね。

査定後にヒアリング→案件紹介をしてもらうメリット

こちらは私が思うことですが、以下4点です。 &nbsp; ①&nbsp;&nbsp;&nbsp;&nbsp;金額が分かることで収入の見通しがつく ②&nbsp;&nbsp;&nbsp;&nbsp;単価をあげるために何をするべきなのか、ヒアリングに相談できる ③&nbsp;&nbsp;&nbsp;&nbsp;具体的な希望が言える ④&nbsp;&nbsp;&nbsp;&nbsp;希望に沿った案件を紹介してもらえる＝ミスマッチが少ない &nbsp; 順にお話させていただきます。

①	金額が分かることで収入の見通しがつく

先ほども少し触れましたが、フリーランスは収入が不安定、と世間一般的には思われています。 しかし、実際にはエージェントを利用することで大半のエンジニアは安定した収入を得ることが出来ます。なぜならエージェントの営業マンが案件を探してくれるからです。 &nbsp; その案件も、事前に報酬額がわかることで収入の見通しがつくため大半の不安は払拭されるはずです。

②	単価をあげるために何をするべきなのか、ヒアリング時に相談できる

査定をすると、おおよその自分の単価がわかります。 査定の金額をふまえて、もしくは将来的にもっと稼ぎたい！というエンジニアは多くいるはずです。 単価を上げるためには、当然スキルアップする必要があります。 スキルアップし、上流工程に参画したり、リーダー業務を行ったり、色々なチャンスがある案件を紹介してもらうことが可能になるはずです。

単価が明瞭になることで、自分のスキル感や立ち位置など、市場価値が見えてくるはずです。 その中で、 「単価を上げたいのでスキルアップできる案件にアサインしてほしい」 「今までリーダー業務ばかり任されてきたけど、本当はプログラマーがいい」 など、より自分のやりたいことを優先させた希望が言えるはずです。 &nbsp; 実際にアサインされるかはエージェントの営業力や個人の面談力にもよりますが、どこのエージェントでも自分の希望はしっかりと伝えるべきです。

④	希望に沿った案件を紹介してもらえる＝ミスマッチが少ない

これに関しては少し論点がずれますが、ヒアリングの時点で自分の希望をエージェントに伝えきれない場合にミスマッチが起こってしまいます。 &nbsp; 案件のミスマッチはエンジニアにとって結構な痛手となります。 「せっかくフリーランスになったのに、希望していた案件にアサインされない・・・」 &nbsp; なんて、そんなもったいないことしてはいけません。 やりたくないことに時間も労力を費やすのはナンセンスですから、しっかり自分の希望を伝えましょう。 ミスマッチが起こらず、やりたい案件にアサインされ、単価もアップ、スキルも習得出来たら最高ですよね。

・・・この会社、一体どちら様？

お待たせいたしました。 今までお話してきたサービスを展開しているのは このメディアサイトを運営している<a href="https://www.granthope.jp/" target="_blank" rel="noopener noreferrer">株式会社グラントホープ</a>さんです。 <img src="https://images.microcms-assets.io/assets/03df7942ab184c4fb92ae2a6d548e115/398019c5b09d483c82b4f1aaaf3d0c72/image.png" alt="">

グラントホープさんの特徴は、まず今回ご紹介させていただいた、年収無料査定。 そしてヒアリングには結構力をいれているようで、まさにエンジニアファースト。 &nbsp; しっかりヒアリングをするからこそ、やりたい案件がどんどん紹介される営業力。 &nbsp; 年収無料査定から最短3日でご成約された方もいらっしゃるそうです。 &nbsp; &nbsp; この年収無料査定は、誰でも実施できるようですよ。 &nbsp; ※フリーランスなので、未経験者は対象外のようです。 	ご実績が２年ある方が対象です。

いろんなフリーランスのエージェント会社がありますが、 それぞれの特徴をふまえて活用していきましょう。 &nbsp; 私個人的な意見としては、無料年収査定はおすすめです。 正社員の方は、フリーランスに転身した場合、今の自分のスキルではどれくらい貰えるのか。 フリーランスの方は、単純にエージェントによって単価が異なりますので比較対象として活用していただけばと思います。 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; これは豆知識？かもしれませんが グラントホープさんは役員の皆さんは、全員元フリーランスエンジニアのようです。 元フリーランスエンジニアによる、フリーランスエンジニアのための会社でありたい。 &nbsp; そんな強い思いがあるそうです。 &nbsp; 拙い文章でしたが、最後まで読んでいただきありがとうございました。

エンジニア必見！一度は全員試すべき年収無料査定？！

汎用系はなくならない？明確な5つの理由と汎用系の未来を解説

こんにちは！&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;タカトです。 &nbsp; 今のIT業界は「オープン系」が主流ですが、オープン化が主流となる前は「汎用系」が主流だったのをご存じでしょうか？「汎用系･･･？」と言われてピンとくる人は数少ないと思います。何故なら汎用系の新規開発はほとんど行われておらず、新規案件はオープン系がメインだからです。汎用系は運用保守がメインになります。 新規開発はないけど、オープン系に切り替わらず無くならないって不思議ですよね。 今回は汎用系がなくならない理由と汎用系の未来について解説します。 &nbsp; 当記事はこんな人にオススメです。 ・一昔前に主流だった汎用系について知りたい ・今の現場が汎用系主流なので未来について興味がある ・実は汎用系のエンジニアに憧れている

システムを開発する上でパソコンは必須です。 昔は「汎用機」という大型のコンピューターを用いており、そこに向けてのシステム開発を総称して汎用系といっています。 汎用系の特徴は、様々な目的の処理を1つの大型コンピューターで処理できることです。 &nbsp; データが多いと処理に負荷が掛かったりしますが、汎用機自体が演算に長けているため処理速度も早く短時間で処理が可能になります。

汎用系は1つの大型コンピューターで処理するので動作に安定性があるのと、ネットワーク等に繋がないので高いセキュリティ性があります。（ほぼオフライン状態） &nbsp; オープン系は様々なパソコンをネットを介して繋ぎ処理をするため、回線が不安定になると処理は遅くなりますし、ネットを介する分セキュリティ面で外部から攻撃を受けやすいです。 これだけ聞くと「汎用系の方が良いのでは？」と思いますが、汎用系は莫大なコストが掛かります。というのも1台の大型コンピューターをそのためだけに購入しないといけないのと、大型コンピューターの維持コストがオープン系と違い割高になります。なので一概に汎用機が良いというわけではないんです。

汎用系のシステムは身近なもので使われているのが多く、代表的なのは銀行です。 ほぼ全ての銀行は汎用系のシステムを使っています。 これは当時汎用系が主流だったのと、銀行のシステムはそれぐらい昔から存在していたからです。 また、汎用系は大規模な演算処理に長けているため銀行のシステムとしてはうってつけというワケです。 銀行以外でも、自動車関連、クレジットカード、保険など昔から存在しているシステムはほぼ汎用系を使用しています。

オープン系が主流となっているのは何故？

汎用系は先ほど述べましたが莫大なコストが掛かります。 1台の大型コンピューターを購入し、専用の場所を借り、熱が上がらないよう空調を常に入れておくなど維持コストが驚くほど出ていきます。 オープン系はパソコン1台と置く場所さえあれば維持コストはそこまで掛かりませんし、処理自体もネットワークを介して行うので、熱もそこまで上がりません。 開発のしやすさ、コスト面で圧倒的にオープン系の方が安上がりのためオープン系が主流となってきてます。 &nbsp; とはいえ、汎用系がまだまだ無くなっていないのには5つの明確な理由があります。

汎用系がなくならない5つの理由

１．システムの複雑化とブラックボックス

汎用系システムはとにかく古いため、今のシステムのように最適化されていません。 そのため、膨大な数のプログラムで組まれており、システムが複雑化したままです。 最適化しようにも、資料が紙ベースでしかなく解読も難航し、ほぼブラックボックス化。 正しいのはプログラムだけど、プログラムも複雑といった状態のため、結局手が付けられずにいます。

システムを運用保守していく中で、全容を知っている人が存在します。汎用系は非常に古いシステムが多く、有識者がそれなりのご高齢になっていたり、下手したら定年退職しています。こうなるとオープン化しようと思っても、システムの全容やオープン化に伴う影響範囲がつかめません。ちゃんと技術や知識の継承ができていれば事なきを得ますが、それが出来てない会社が数多く存在しているため、オープン化を諦める会社も少なからず存在します。 &nbsp;

３．ドキュメントが整理されてない

有識者が不在ならドキュメントを確認すればよいのでは？と思いますよね。 &nbsp; ここにも問題があり、昔は全て紙で行っており、仕様書・DB設計・テスト仕様書なども全て紙です。しかも手書きで読めない字もあったります。これを電子化していれば多少なんとかなりますが、資料が膨大な量なのでほとんど紙ベースのままが多いです。紙ベースから読み解くのは至難の業で、これを元にオープン化となると正直厳しいところがあります。 &nbsp;

４．オープン化に伴い莫大なコストと時間が掛かる

オープン化するということは維持コストは下がりますが、開発コストと時間は計り知れないお金と労力が掛かります。現行システムの解析、新システムの開発、大型汎用機の撤去費用 など、とにかくお金が掛かるんです。開発期間も1年では済まず3〜5年という長期的な期間で段階的に移行していくため、長期的な要員確保も必要です。その要員確保も必要最低限のコストでやろうとするので、人が集らず人手不足のまま走って炎上・・・なんてこともあります。ちゃんと余裕のあるコストを出してくれれば良いんですが、一番最初に削られるのは要員コストなので悩ましいところだったりします。

上の人間はオープン化するメリットを理解しつつ、総合的に判断します。 開発コスト、規模が大きければ大きいほどシビアになりますし、元々動いていたシステムの機能は絶対的に保証しないといけないためメリットは分かるけど・・・ということが起こります。また、古い考えの人がいると操作性が変わることで、操作手順を覚えなおす手間になるため拒む人もいたりします。こういう人たちからYESを貰うのは大変で、結局既存ホスト系のままになることは普通にあります。そういう人たちの言い訳は「現状動いてる緊急性がないならそのままで」といって他のプロジェクトを優先します。ホストも機器の保守期限があるので割と急ぎなんですが、現状動いてるというのが足かせにもなっているようです。

10年汎用系の業界にいた私の見解として、汎用系はなくなることはほぼ無いです。 上記5つの理由から、予算がないとオープン化はできないですし、汎用系の言語（主にCOBOL）を読める若い人がいないからです。こうなるとオープン化自体が難しく、現状の汎用系を維持することになります。なので未来はあるけど、そんな明るい未来ではないというのが本音です。

まとめ：汎用系はなくならないけど技術習得するならオープン系がおすすめ

なくなることがないなら汎用系を学ぶのもありだと思います。 技術者もどんどん高齢になっており、若い技術者は重宝されます。ただ、汎用系の言語はこれ以上の進歩がないため技術力の向上は不可能です。逆にオープン系は今も尚、進歩しており技術力の向上も可能です。主流となっている分、案件も数多くあるので汎用系で重宝される技術者になるよりは、日々技術の向上を図りながら、様々なプロジェクトに携われるオープン系をオススメします。 &nbsp; プログラム言語は合う合わないがあるので、実際にやってみて自分のキャリアにあった選択をしてみてはいかがでしょうか。 &nbsp; 本日も読んでいただきありがとうございました。

皆さんは、システムエンジニアとしてどの工程を担当していますか？ 上流工程を担当していますか？それとも下流工程を担当していますか？ &nbsp; フリーランスで働く以前に、システムエンジニアとして働く以上、システム開発工程を理解しておく必要があります。 &nbsp; そこで、シリーズ企画として、システム開発工程の概要から各工程の大切なこと、やっていく上でのコツをこのシリーズ企画でお届けしています。 &nbsp; 今回はver5として、遂に「下流工程」の話になります。 &nbsp; ここからは、上流工程で作成した設計書がどのように下流工程で利用されているかを中心に纏めていきます。 &nbsp; ぜひ、下流工程に従事されている方、下流工程の仕事をされたい方は、ぜひご覧ください。

下流工程（プログラミング～テスト）

まずはこちらの図をご覧ください。 この図が、「上流工程と下流工程の関係性」を表しています。

左側が上流工程で、一番最下部と右側が下流工程になります。 一つずつ解説していきます。

一番最下部の「開発実施」は「プログラミング」で、上流工程で作成した以下設計書を元に、実際のシステムを構築していく工程になります。 ＜使用する設計書＞ ・外部設計書（基本設計書） ・内部設計書（詳細設計書） この工程で、遂に「プログラム言語」を利用します。 「java」、「perl」「ruby」、「html」など様々な言語の中から、構築したいシステムに適した言語でプログラミングしていきます。 実際にモノを創り、そしてモノが形になる工程です。 モノを創り上げるという楽しさが一番実感できるので、モノ創りが好きな方には向いている工程だと思います。 ただ、基本的には、設計書通りにプログラミングしていくので、「自由な発想」は求められず、「設計書通り」にプログラミングしてくことになります。 ここで、自由にプログラミングすると、予期せぬバグや仕様を満たせないことになるので自由な発想で仕事をしたい方には、少し窮屈感を感じることがあるかもしれません。 プログラミング言語の特徴などは、また別の記事で纏めてみようと思います。

プログラミング工程が完了したら、実際に構築したプログラミングが正しく動作するかをテストします。 システム開発では、「小さい単位」から「大きい単位」という流れでテストするため、一番初めのテストは「単体テスト」です。 ここでは、「プログラミングの対象単位(モジュール)」毎にテストします。 この工程では上流工程で作成した以下設計書を元にテスト観点をまとめる「単体テスト仕様書」を作成。そして、「単体テスト」を実施し、プログラム（モジュール）が正しくプログラミングされていることをテストします。 ＜使用する設計書＞ ・内部設計書

【項目説明】 　分類：設計書内の一番大きな処理。 　試験・確認項目：処理内の一つ一つの動作 　試験・確認内容：処理内の一つ一つの動作が仕様通りに動くときの挙動

代表的なテスト観点は以下です。

【テスト観点】 　・正常系テスト 処理が正しく動くことを確認するケースで、設計書通りの挙動になることを確認します。<h2 id="hdfa5d1cefd"> </h2> ＜例＞ 「文字列に「ようこそ」を格納する」処理があった場合 ①文字列に「ようこそ」が格納されることを確認 　・条件網羅テスト ロジックのIf文などの条件を網羅するテストケースです。 全ての条件式に対して、正しく条件通りに処理されるかを確認します。 ＜例＞　 「If (文字列＝A or 文字列＝B)」があった場合 以下３パターンのように条件網羅するようにテストするのが基本です。 ①文字列＝Aの場合、条件一致 ②文字列＝Bの場合、条件一致 ③文字列＝Ｃの場合、条件不一致 　・境界値テスト ロジックの不等号（＜,＞,＝など）を確認するテストケースです。 全ての不等号に対して、不等号通りに処理されるかを確認します。 ＜例＞ 「If（数値＜10）」があった場合 ３点検証だと以下①～③を、２点検証だと以下①②をテストケースとします。 ①数値＝9の場合、条件OK ②数値＝10の場合、条件NG ③数値＝11の場合、条件NG ３点検証は、対象の数値とその数値の前後±１を検証する方法で、 ２点検証は、対象の数値と、対象数値－1を検証する方法です。 私の経験上では、産業系システム開発などの速さを優先するところでは２点検証で実施し、金融系や公共系システム開発などの品質を優先するところでは３点検証が使用されているように思います。 　・異常系テスト 異常値や、エラーが発生した場合の挙動を確認するテストです。 ロジックに応じて、様々な検証を行う必要がありますが、ここでは「日付」と「文字列」を例として挙げます。 　＜例＞ １．「If（日付＝2021/2/28）」があった場合 ①日付＝2021/2/28の場合、条件OK ②日付＝2021/2/29の場合、存在しない日付のため、条件NG ２．「If（文字列＝A or 文字列＝B）」があった場合 ①文字列＝Aの場合、条件OK ②文字列＝10の場合、文字列ではなく数値のため、条件NG 単体テスト工程もプログラミング工程と同じで、創り上げたモノが実際に動く楽しさを一番実感できる工程なので、モノ創りが好きな方には向いていると思います。 ただ、この工程も自由な発想よりは、設計書通りに作業することが大切です。 工程の目的が、仕様通りに稼働することを確認するため、自由な発想はあまり必要としないためです。

単体テスト（モジュール単位）で問題が無ければ、各モジュール同士を結合してテストを行います。 この工程では上流工程で作成した以下設計書を元にテスト観点をまとめる「結合テスト仕様書」を作成。そして、「結合テスト」を実施し、データの受け渡しや画面の切り替わりなど、プログラム同士が正常に連携するかをテストします。 ＜使用する設計書＞ ・外部設計書

【項目説明】 　単体テスト仕様書を同じ 単体テストとは元にする設計書が違うため、確認内容が「ロジック」単位ではなく、実際の「画面機能や帳票機能」単位の確認内容になります。 代表的なテスト観点は以下です。 &nbsp; 【テスト観点】 　・機能テスト ソフトウェアの機能が、上流で決めた仕様通りに動作するか検証するテストです。 ＜テスト観点例＞ 「画面に　「ようこそ」を表示する」があった場合 ①画面に「ようこそ」が表示されることを確認 　・疎通テスト システム間でリクエストとレスポンスが成立するかどうかを検証するテストです。 ＜テスト観点例＞ ネットワークを経由するシステムA、システムBでデータ連携があり、システムAで、「名前」、「性別」、「住所」のデータが必要な場合 ①システムBから、正しいインタフェース（*1）を利用し必要な項目が連携されていることを確認 (*1)インターフェース システム間で必要となるデータを連携するために使用するもの 　・回帰テスト 回帰テストは、リグレッションテストや退行テストとも呼ばれます。 システムの改修を行っていない部分に不具合が発生しないか（デグレ）検証します。 ＜テスト観点例＞ 処理A,Bを使うC処理があり、A処理のみ改修した場合 ①処理B,Cが既存通りの挙動をすることを確認 結合テスト工程も単体テスト工程と同じで、創り上げたモノが実際に動く楽しさを実感できる工程なので、モノ創りが好きな方には向いていると思います。 この工程も自由な発想よりは、設計書通りに作業することが大切なのですが、単体テストとは違った作業を行います。 それは、「関連システムとの調整」が発生することです。 「疎通テスト」では、関連システムと正しく疎通ができることを確認するため、関連システムと「実施日の調整」や、「実施内容の調整」を行うため、テスト実施だけではなく、調整を行う必要性がでてくる工程です。 そのため、実際にモノを創るだけでなく、他のシステムの調整を経験したい方は、結合工程を経験しても良いと思います。

プログラム同士の連携が問題なければ、ユーザが要求する機能や性能を満たしているかをテストする工程に入ります。 この工程では、この工程では上流工程で作成した以下設計書を元にテスト観点をまとめる「システムテスト仕様書」を作成。そして、「システムテスト」を実施し、開発したシステムを使用してユーザ業務が行えるかをテストします。 ＜使用する設計書＞ ・要件書 単体テスト／結合テストとは元にする設計書が違うため、確認内容がロジック／画面単位ではなく、実際の「ユーザ業務」の確認内容になります。 代表的なテスト観点は以下です。<h2 id="h443647bd06"> </h2>【テスト観点】 　・ユーザビリティテスト 開発したシステムで実際に業務を行うことや、業務シナリオを想定してユーザの操作感や使用感などを検証することが、ユーザビリティテストです。 ＜テスト観点例＞ 決済処理を行うための機能を作成した場合 ①以下の画面の流れで決済処理を行えることを確認する。 決済受付画面→決済画面→決済確認画面→決済帳票出力 　・性能テスト 実際のユーザの利用に耐えられるかどうか検証を行います。 ＜テスト観点例＞ 同時に画面アクセスした場合に、レスポンスが5秒以内の要件があった場合 ①５人で同時に画面アクセスして想定時間通りにレスポンスが返却されることを確認する。 この工程も自由な発想よりは、設計書通りに作業することが大切なのですが、大きく他のテスト工程とは違った作業を行います。 それは、「顧客折衝が発生すること」、「ユーザ業務を知れる」ことです。 「システムテスト」では、ユーザさんに実際にシステムを使用していただくため、システムの使用方法の説明を行う必要が出てきます。 また、実際にユーザ業務通りにテストを行うため、ユーザはどの業務でこのシステムを使用するかを知れるため、業務知識を身に付けることができる工程です。 そのため、実際にモノを創るだけでなく、実際に顧客折衝や、業務側の仕事に興味がある方は、システム工程を経験しても良いと思います。

ここまでが、下流工程と呼ばれる工程になり、この工程が終われば、あとは「【8】運用テスト→【9】システム移行(リリース)」の流れでリリースを行い、システム開発は完了します。 リリースしたシステムは、「【10】運用・保守工程」で、常にシステムを監視し、不具合が生じた際には即座に修正する工程になります。 この工程では、システム利用がなくなるまで発生しますが、システム開発よりは少ない人数でこなしていくことになります。 また、この工程では「保守案件」と呼ばれるシステムを改善／拡張する開発が発生します。この「保守案件」が立ち上がると、「【1】要件定義～【9】システム移行(リリース)」のサイクルで、小規模なシステム開発がスタートします。 そのため、システムリリースしたからといって、システム開発が終わりではなく、システム利用がなくなるまで開発作業は発生するので、このサイクルを続けていくことになります。

いかがでしたでしょうか？ こちらが下流工程になります。 この工程は、実際にモノ創りの楽しさや、チームで何かを創り上げる楽しさも実感できる工程です。モノを創りたいと思っている方には、もってこいの工程ですね。 また、巷ではこの工程がＩＴの仕事だと思っている方が大半です。 このＩＴの醍醐味である工程に興味ある方はぜひ、チャレンジしてみてくださいね。 &nbsp; ちなみにこのシリーズ企画はこれで最終回です。各工程の良さが伝わりましたでしょうか？ 私自身は、下流工程より上流工程の方にやりがいを感じますが、上流工程の良さや、下流工程の良さがこのシリーズ企画を通じてお伝えできていれば幸いです。 また何かの記事でお会いしましょう！

システム開発工程ver5

土谷　貴志（つちたに　たかし）

システムエンジニアとして案件をこなしつつ、ライターとして執筆活動にもチャレンジ中。株式会社グラントホープ所属のフリーランスエンジニア。
システムエンジニアの他に、キャリアコンサルタントとして若者のキャリア支援や、LifeTime-Smileというコミュニティ運営など幅広く事業を展開中。
ごく稀に、コミュニティメンバーの記事を投稿するかも。お楽しみに！
LifeTime-Smile：https://www.lifetime-smile.com/


皆さんは、システムエンジニアとしてどの工程を担当していますか？ 上流工程を担当していますか？それとも下流工程を担当していますか？ &nbsp; フリーランスで働く以前に、システムエンジニアとして働く以上、システム開発工程を理解しておく必要があります。 &nbsp; そこで、シリーズ企画として、システム開発工程の概要から各工程の大切なこと、やっていく上でのコツをこのシリーズ企画でお届けしています。 &nbsp; 今回は番外編として、「各種設計書の詳細」についてお届けします。 &nbsp; ぜひ、設計書の詳細を知りたい方は、ぜひご覧ください。

システム開発の上流工程では、様々な設計書を作成いたします。 図を用いながら、どのような設計書を作成するのかをご説明いたします。

＜外部設計書の種類＞ ①画面一覧、画面遷移図、画面レイアウト、画面項目定義書 ②画面イベント定義書 ③帳票一覧、帳票レイアウト、帳票項目定義書 ④テーブルレイアウト定義書、データ定義書、E-R図、CROD図 ⑤外部システム関連図、外部IF一覧、外部IF定義書

①	画面一覧、画面遷移図、画面レイアウト、画面項目定義書

システムで開発する画面周りの設計書類。画面レイアウトはより具体化し、画面入力項目一覧、画面イベント定義といった資料を基本設計工程にて新たに整理します。

＜画面一覧＞ システムの画面を一覧化した設計書。

＜画面遷移図＞ 画面遷移を図で整理した設計書。

＜画面項目設計書＞ 画面レイアウトとセットになるもので、画面項目の入出力を明確にする設計書。

画面の項目選択したときの処理・動作を明確にする設計書。

③	帳票一覧、帳票レイアウト、帳票項目定義書

システムで開発する帳票周りの設計書。「レイアウト決定」、「出力項目一覧の整理」、「編集定義の決定」の３つが主な作業となります。

＜帳票一覧＞ 帳票を一覧化した設計書。

＜帳票レイアウト＞ 各帳票のレイアウトを明確にした設計書。

＜帳票項目定義書＞ 帳票項目や、その項目の編集仕様を明確にした設計書。

④	テーブル一覧、テーブルレイアウト定義書、E-R図、CROD図

システムで開発する主要なテーブルの設計書類。基本設計工程ではテーブル定義やCRUD図の整理が主な作業です。CRUD図は整理する組織と整理しない組織が大きく分かれる印象がありますが、整理しておくと機能漏れやデッドロックの防止につながるので、非常に大切です。

＜テーブル一覧＞ 主要なテーブルを一覧にまとめた設計書。

＜テーブルレイアウト定義書＞ テーブル一覧を元に、各テーブルのデータ項目をまとめた設計書。

＜E-R図＞ 主要テーブルの関連性がわかる設計書。

＜CROD図＞ 各テーブルの作成（C）・参照（R）・更新（U）・削除（D）を整理した設計書で、機能漏れやデッドロックの防止が期待できます。

⑤	外部システム関連図、外部IF一覧、外部IF定義書

システムを構築する上で必要な外部システムとの連携（インターフェース）について整理した設計書類。

＜外部システム関連図＞ 関連システムとの関連性を図解した設計書。

＜外部IF一覧＞ 関連システムとのIF（インタフェース）を一覧化した設計書。

＜外部IF定義書＞ 関連システムとの各IF（インタフェース）の連携項目をまとめた設計書。

＜内部設計書の種類＞ ①処理詳細仕様書（IPO） ②クラス図 ③アクティビティ図 ④シーケンス図

IPOは機能の入力・処理・入力を記載した設計書。 入力=Input、処理=Process、出力=Outputの頭文字をとってIPOと呼ばれています。

システムを構成するクラスの関係を表す設計書。 プログラミングする際の見取り図になり、作業の優先順位をつけたり、複数名で作業を分担する際に有効です。 画面設計書やアクティビティ図から必要なクラスを洗い出しながら各クラスの関係を整理していきます。（記載ルールは下記を参照）

実際に記載ルールを元に作成したクラス図

アクティビティ図はユーザーの操作とシステム処理の流れが分かる設計書。 処理の流れが分かることはもちろん、操作に応じた処理をどこに実装するかが分かる。 より詳細なメッセージのやりとり（どのクラスで実現するか等）を整理する場合は、シーケンス図にて整理します。 基本的な書き方はフローチャートと同じで、利用者のアクションやシステム処理を枠で囲み、それを矢印でつないでいく。作成するための情報源は、基本設計で作成した業務フローや画面設計書です。

シーケンス図はアクティビティ図よりもシステム内部処理をさらに細かく記載した設計書。 クラスやオブジェクト間のやりとりを時間軸に沿って表しており、縦軸が時間、横軸がユーザーやシステム機能（オブジェクト）です。 ユーザーからのアクションを受けて、オブジェクトがどのような情報を受け取り、次のオブジェクトにどのような情報を渡しているのかを矢印で表現しています。 シーケンス図の作成にあたっては、基本設計工程で作成した業務フローや画面設計書だけでなく、同じ詳細設計工程で作成するクラス図も必要です。

いかがでしたでしょうか？ こちらが外部設計と内部設計にて作成する主な設計書になります。 ＰＪによっては、これ以上に作成する場合や、少ない場合もあります。 想像していたよりも多かったですか？それとも少なかったですか？ この設計書と呼ばれる、システムの説明書をシステムエンジニアが作成し、その説明書を元にプログラマーがブログラミングをしています。 &nbsp; プログラミングも、この設計書がないとできません。設計書と言えば簡単ですが、ここからシステム開発ができるので、非常に大切なものですね。 プログラミングは苦手だけど、システム開発をしたい方は、ぜひ設計工程にチャレンジしてみてください。&nbsp;

システム開発工程<	番外編>

皆さんは、システムエンジニアとしてどの工程を担当していますか？ 上流工程を担当していますか？それとも下流工程を担当していますか？ &nbsp; フリーランスで働く以前に、システムエンジニアとして働く以上、システム開発工程を理解しておく必要があります。 &nbsp; そこで、シリーズ企画として、システム開発工程の概要から各工程の大切なこと、やっていく上でのコツをこのシリーズ企画でお届けしています。 &nbsp; 今回はver4として、「内部設計」についてお届けします。 &nbsp; ぜひ、内部設計に従事されている方、内部設計の仕事をされたい方は、ぜひご覧ください。

内部設計の仕事・仕事をこなす上でのコツ

システム開発の上流工程の最後である「内部設計」の仕事と、仕事を行う上でのコツを私の経験談からお話します。

内部設計が、上流工程の最後の工程になります。 「外部設計書」から、「内部設計（詳細設計）書」を作成することが主な仕事になります。 &nbsp; さて、いきなりですが、クイズです！ 上部の図で２人に「見る」の矢印が出ていますが、一体、誰のことを指しているでしょうか？ 答えはこちらです。

「コーディングする人」と、「単体テストをする人」が見る設計書となります。 わかりましたでしょうか？ ここでお伝えしたかったのは、コーディングする人と、単体テストをする人が見るということは、設計書を見ただけで、プログラミングができる設計書を作成する必要があるということです。 そのためここからは、システムの思考で設計書を記載することになります。 ただ、内部設計書は、外部設計と同様で、一つの成果物を作成するわけではなく、以下の成果物を作成します。 ＜外部設計書の種類＞ ・処理詳細仕様書（IPO） ・クラス図 ・モジュール構成図 ・アクティビティ図 ・シーケンス図 などです。 内部設計でも作成する成果物が多く、プログラミングを意識したシステのム内部処理を考えて記載することになります。 そのため、ユーザさんには見せない成果物になるので、システム目線で記載しても良い成果物で、ユーザさんと接する機会はないため、システム開発に集中できる工程とも言えます。 なので、システムのことを考えたい人は、内部設計の工程から携われると良いと思います。 各種設計書については、外部設計書と合わせて、別の記事で纏めてみようと思います。

私が思うこの内部設計を行う上でのコツですが、以下４点だと考えています。 　①あいまいな表現はしない。文章だけでなく、図や表を利用する。 　②内部処理の利用方法を十分に理解しておく。 　③画面側処理と、サーバー側処理で行う内容を、明確にしておく。 　④エラーハンドリングを十分に検討する。

①あいまいな表現はしない。文章だけでなく、図や表を利用する。

内部設計書を見て、コーディング、単体テストを行うことになります。 そのため、条件式などを曖昧な表現にしていると、バグを作りこむ原因になるため、注意が必要になります。 「条件式（個数が１以上の場合）」の記載にするとプログラマーは、「if（kosu &gt;= 1）」というプログラミングを行います。 もし、この記載の他に「条件式（個数が１を超える場合）」や、「条件式（個数が１未満の場合）」などの記載があった場合は、どうでしょうか？ 不等号として、「＞」なのか。「＜」なのか。はたまた「＜＝」なのか。プログラミングに困ります。そのため、内部設計書はユーザさんには見せない設計書のため、ある程度の専門用語を利用し、「条件式（個数＞１の場合」のように、不等号などの記号を直接記載することや、フローチャートや表を利用し、伝わりやすい表現で記載することが大切です。

②内部処理の利用方法を十分に理解しておく。

内部設計では、複数の内部処理を適切な順番に呼び出すことで、１つの機能を設計していいきます。その過程で、既に準備されている内部処理を流用することや、新しい内部処理を作成することがあります。 その「内部処理」を、新しく作成する必要があるのか。や、既存処理を流用できるのか。を考える必要があり、その考えるために、システムの内部処理を十分に理解しておく必要があります。 内部処理を十分に理解していない場合、正しい順番で処理を呼び出す設計ができない。や、同じ内部処理を複数作成することになるため、内部設計書を書く前に、内部処理について理解しておくことが大切です。

③画面側処理と、サーバー側処理で行う内容を、明確にしておく。

最近は、画面（クライアント）側とサーバー側に分かれてプログラミングをし、最終的にその２つをつなぎ合わせて、システムとして稼働させる方法がメジャーになっています。 そのため、画面側のみできる処理や、サーバー側のみできる処理、その逆で、どちらでもできる処理があります。 どちらかのみできる処理は、できる方でやれば良いのですが、どちらでもできる処理の場合は、どっちで処理をするのか。を明確にしておく必要があります。 明確にせずにプログラミングした場合、両方ともに同じ処理を実装することや、両方ともに実装されていないことがあるので、画面側、サーバ側で行う処理を明確に決めて、記載しておくことが大切です。

④エラーハンドリングを十分に検討する。

内部設計書では、プログラミングを意識した設計が必要です。 つまり、プログラム内でエラーが起きた場合の、対処を十分に設計する必要があります。 外部設計書では、システムが正常に稼働した場合の流れを中心に記載されていることが多く、システムが想定外でエラーになった際の挙動などはあまり記載されていないです。 なので、想定外でエラーになった際に、どのような挙動とするのか。を明確に、設計書内に記載する必要があります。 記載していないと、想定外エラーが発生した際、何が起きているかを調査できない事態が発生するので、エラーハンドリングを十分に検討することが大切です。

いかがでしたでしょうか？ こちらが内部設計の仕事とコツになります。 この工程からは、システム開発のみに携われる工程なので、実際に手塩をかえて、細部にこだわってシステムを作成することができます。 こだわることができると思うと、非常にやりがいがある工程だとおもいませんか？

システム開発工程ver4

皆さんは、システムエンジニアとしてどの工程を担当していますか？ 上流工程を担当していますか？それとも下流工程を担当していますか？ &nbsp; フリーランスで働く以前に、システムエンジニアとして働く以上、システム開発工程を理解しておく必要があります。 &nbsp; そこで、シリーズ企画として、システム開発工程の概要から各工程の大切なこと、やっていく上でのコツをこのシリーズ企画でお届けしています。 &nbsp; 今回はver3として、「外部設計」についてお届けします。 &nbsp; ぜひ、外部設計や内部設計の仕事に従事されている方、外部設計や、内部設計の仕事をされたい方は、ぜひご覧ください。

外部設計の仕事・仕事をこなす上でのコツ

ここからは、システム開発の上流である「外部設計」の仕事と、仕事を行う上でのコツを私の経験談からお話します。

外部設計から、システム開発が本格的に開始されます。 「要件定義書」から、実際にシステムを作成するための工程になります。 外部設計は、まだユーザよりの内容ですが、プログラミングを意識した成果物を作成することが必要です。 要件定義書と、システム処理の両方を意識しながら、「外部設計（基本設計）書」と呼ばれる成果物を作成するのが主な仕事になります。 ただ、外部設計書は、一つの成果物を作成するわけではなく、以下の成果物を作成します。 ＜外部設計書の種類＞ ・画面レイアウト、画面項目定義書 ・帳票レイアウト、帳票項目定義書 ・画面イベント定義書 ・テーブルレイアウト定義書、データ定義書、E-R図 ・外部IF一覧、外部IF定義書 ・CROD図 などです。 外部設計工程になると、作成する成果物が多くなり、内容もシステムをきちんと理解していないと書けないものになりますので、いかに「システム理解」と「要件理解」をしているかが重要です。 また、要件定義では決めきれなかった内容を、ユーザさんと打ち合わせすることもあるため、少しだけユーザさんと接する機会があることも外部設計工程の特徴といえます。 なので、システム開発に携わりたいけど、ユーザさんと接する機会が欲しい方は、外部設計をしてみても良いかもしれません。 外部設計書の種類の詳細については、別記事で纏めてみようかと思います。

私が思うこの外部設計を行う上でのコツですが、以下４点だと考えています。 　①システム改修の場合は、改修を行うシステムの処理内容を細部まで理解しておく。 　②新規システム構築の場合は、自由な発想で処理内容を考える。 　③お客さんと話すときは、システム視点の話だけではなく、ユーザさん目線で話す。 　④後続工程（設計・開発・テストなど）のことも意識し、プログラマーの方が読みやすく、理解しやすい成果物を作成する。

①システム改修の場合は、改修を行うシステムの処理内容を細部まで理解しておく

システム改修の場合は、システム内の一機能の改修を行う外部設計が多いです。 そのため、改修を行う機能の知識がないと、使いやすいシステムで、品質が良いシステムを開発することができません。 設計工程だと要件定義とは違い、機能の細部まで知る必要があり、一機能の中のこの処理をどう組み替えるのか。という要件定義より、システムに一歩踏み込んだ視点を持つことが重要です。

②新規システム構築の場合は、自由な発想で処理内容を考える

新規システムの構築の場合は、元になるシステムがなく、ユーザ要件とIT要件だけが存在する状態になります。 そのため、どのような画面で、どのような処理を実現するのか。という点は、システム開発する人に任せられることが多いです。 なので、自由な発想で考える必要が多くなりますので、在るものから考えるのではなく、無いところから、何かを生み出す思考が必要になってきます。

③お客さんと話すときは、システム視点の話だけではなく、ユーザさん目線で話す。

結構、システム利用されるユーザは、システム開発やＩＴ技術を知らない人が多く、システムでは実現が難しい要望を言ってくることがあります。 そのため、開発者の視点と、ユーザ視点ではギャップが生まれることが良くあります。 その結果仕様検討会という会議で、ユーザさんと検討する場面があった場合は、単にシステムとしてはこういう挙動になります。というシステム視点の考え方だけではなく、ユーザさんが何を実現したいのか。という思考と、ユーザさんに伝わる説明の仕方を意識して、会議に臨む必要があります。

④後続工程（設計・開発・テストなど）のことも意識し、プログラマーの方が読みやすく、理解しやすい成果物を作成する。

外部設計は、要件と開発を繋げる橋渡しとある工程です。 そのため、外部設計の内容を元に、プログラマーが実際のシステムを構築していきます。 なので、プログラマーがいかに読みやすいか、また伝わりやすいか。を意識して、外部設計書を作成することが重要です。 プログラマーが読みづらい設計書だと、バグを生み出すやすく、また、プログラマーに意図が伝わらず、効率よく開発が進めることができなくなります。設計者からしたら当たり前。と感じる内容も、プログラマーからしたら、当たり前ではないこともありますので、主語や当たり前の内容でも、設計書に記載しておくことが無難です。 そこで、プログラマーの方に伝わりやすくするために、フローチャートを作られることもあります。 また、こちらも別記事でかけたら良いなと思っています。

いかがでしたでしょうか？ こちらが外部設計の仕事とコツになります。 ユーザさんとも会話でき、システム開発にも携われる工程になります。 直接ユーザさんの声も聴くことができるため、やりがいが感じやすい工程でもあると思います。実際に手塩をかえて作成したシステムが、ユーザさんに役にやっているのか。や、直接感謝の言葉もいただけこともあるかもしれません。 そう思うと、非常にやりがいがある工程だとおもいませんか？

タグ:【システム開発工程】の記事一覧