■今後、投稿したいこと １．システム開発について ・経験機種は、IBM/MVS、 IBM/Z-OS、IBM/AS400、 Windows ・経験言語は、COBOL、PL/I、 VBA (Web系の経験はなし） ・経験DBは、DB2、ADABAS、 SqlServer、MS-Access ・経験業務は、受発注管理、 在庫管理、商品管理、 献立栄養管理、 スケジュール要員管理 ・他、シ
仕事を依頼するIT会社と 開発工程について説明します。 ■仕事をどこに依頼するか IT案件を依頼する場合、 依頼先企業の選択が 案件の成否が決まる。 メーカー系IT企業 コンピュータメーカーや 情報機器メーカーの子会社 である。 自社製品の知識が豊富なのが、 メリットだが、他社製品の 知識が疎く、 マルチベンダ環境のシステムを 構築する場合は、注意が必要で ある。 ユーザー系IT企業 銀行、商社の子会社である。 特定業務に非常に精通して いるのが、メリットだが、 特
IT会社には、様々な技術職が 存在します。 システムエンジニア(SE)を 中心にして様々な職域を説明します。 ■SEの職能（大きく２つ） 業務の流れは、上流から下流まで、 下記のような形になるのだが、 開発系技術者は、上流工程、 運用系技術者は、最下流工程を 担当することとなる。 一般的に、 開発系の方が、創造力を発揮でき、 給与も高いが 運用系は、地味で、給与も低い このため、運用系には優秀な 人材が集まらず、モチベーションも 上がらない。 ■開発系の技術者プログラマ
在庫を正確に把握するには、 在庫に関わる全ての業務の把握と その業務における商品数変化を正確に 把握することです。 今更ながらですが… 受注業務 システム上は、下記を考慮する 必要があります。 ① 受注商品の納品予定日 （出荷予定日）を把握 ②「入荷予定」の同一商品の 入荷予定日を把握 ③「出荷予定」の同一商品の 出荷予定日を把握 上記①～③の予定日を把握し、 ・受注商品は納品可能か？ ・該当日に在庫用品が存在 しなければ、発注を行うのか？ 以上、将来の在庫を踏
病院、学校、施設など集団給食を 行っている場所で、 「献立管理」、「栄養管理」を システム化する場合の業務流れ、 各種情報（データ）の保存手順について 解説します。 献立管理、栄養管理にて使用するデータシステム化を行う場合、 各種情報整理し登録する必要が あります。 マスタ (M) 日々の業務で使用される基本的な データを登録する（例：食品 等） トランザクション (T) 日々の業務で発生するデータを 登録する（例：献立 等） 共通項目の登録システム化を行う前
受発注、入出荷、在庫、支払請求の 管理を システム化する場合、 パッケージ（市販）ソフトを使用する のか？ 自社開発（他社依頼を含む）で 対応するのか？ の２点となります。 コストパフォーマンス（CP）が 一番良いのは、カスタマイズ無し （個別修正無し）で、 自社業務に最適なパッケージが 見つかるのがベストです。 しかし、 ・一部の業務は自社開発、 一部の業務はパッケージ ・一部の業務はパッケージ、 一部の業務は他社パッケージ 等の状況で業務を行っている場合、 業務
受発注、入出荷在庫管理をシステムを 利用して管理する場合、 各種データを保持するファイル （テーブル）が必要になります。 ① マスタファイル ・各種ファイルより参照されるが、 日々の業務で頻繁に更新されることは 無いデータ ・基本は、「コードとコードが意味する 各種設定」で構成されるデータ ② トランザクションファイル ・個々の業務で発生するデータ ・業務の処理タイミングにより 「日次、週次、月次」などに 分けられるデータ ③ マスタファイルの例 ④ トラン
在庫まわりの各種業務について 解説します。 ① 在庫と受注 ・顧客からの受注を受ける場合、 在庫状況を確認する ・在庫に影響を及ぼす 出荷予定、入荷予定を確認する ② 在庫と発注 ・在庫欠品を発生させないように 発注を行う ・商品単位にその属性に応じて 発注を行う ・定量発注 ・定期発注 など ③ 在庫と入荷 ・入荷による商品在庫数増加 ④ 在庫と入荷返品 ・入荷返品による商品在庫数減
在庫商品が存在しなければ、受注顧客 からの注文に即時出荷対応 できません。 しかし、在庫を持てば、 ・保管すれば、倉庫賃料、光熱費、 保険料、固定資産税などの経費が かかる ・運搬すれば、付帯作業、輸送費、 人件費がかかる ・廃棄すれば、輸送費用、処分費用が かかる のような在庫管理費用がかかります。 以上を踏まえて、 該当商品を「在庫管理するのか？」、 「在庫管理しないのか？」を 決めることとなります。 ① 顧客からの受注 ② 受注商品を仕入先へ発注 ③ 仕入
1980年代、この頃のソフトウェア 会社は、現在の人材派遣業と変わらない 業態である。 技術を売るのではなく、 人を売って利益を上げるのである。 このような環境の元に起業し、 お粗末な事業を未だ続けている 地方独立系ソフト会社の一例を ご紹介する。 ■誕生 かっては大型コンピュータも 扱っていた会社よりスピンアウト した社員により設立された。 当初の業務は中堅ソフト会社への 派遣により利益を得て、 細々と直取引を模索していた。 ■初期成長期 東京に大手直取引
ソフトウェア業界を目指す方々へ 新卒採用、中途採用など様々な形で 当業界を目指す方が いると思いますが、 就職、転職の一助になれば幸いです。 当記事は、以下について記載して います。 ・企業の自社サイトをどのように 判断すべきか？ ・本当に技術力はあるのか？ ・残業時間をどように判断すべきか？ ・年収をどのように判断すべきか？ ・社内見学ができるなら ・入社後の判断 ■企業の自社サイトをどのように 判断すべきか？ 当然ながら、企業の自社サイトは、 企業の
【ユーザー】 葬祭業（葬儀、法要時の商品販売・ 在庫・会員管理） 【システム開発経緯】 ① 開発当初 富士通機よりIBM機に移行 （開発言語は、COBOL、データベースは DB2） ② 法要商品、墓地・墓石、仏壇・仏具の 会社を吸収合併 （システム開発言語、データベースは、 MS Access） =>IBM機とWindowsの両機種稼働 ③ 元号対応、消費税対応 ・IBM機、Windows両機種システム 改修 ・
【ユーザー】 協同組合と提携し、そのユーザーを 元に物販事業を展開 【システム開発経緯】 ① 開発当初 VBA.netを使用し、経理業務、販売 管理、在庫管理、営業要員管理 等を開発会社に依頼しシステム化、 データベースは、SqlServer =>現在、最新ソース、システム 仕様は残っていない、 実行ファイルのみで稼働 ② 不具合解消 上記①の不具合解消を目標として、 MS Access (mdb)にてシステム再構築
システム移行（コンバージョン、マイグレーション等）時の プログラム言語変換の事前準備（調査項目）について解説します。 （移行元は、大型汎用機のCOBOL、PL/Iを想定しています、） ■制御言語（業務アプリケーション を制御するJCL等）調査項目 １．資産棚卸（移行対象ソースの 洗い出し） ２．JOB制御命令（ジョブ単位の 制御、管理情報） ３．実行制御命令（プログラム実行、 入出力割り当て 等） ４．帳票関連定義（ページ行数、 行単位文字
プログラム言語移行調査の概要について 解説します。 １．移行元の制御言語はJCL、 業務プログラムは、PL/Iを想定 しています。 ２．図によるイメージが中心となり ます。 【相関チェック】 ■バッチプログラムに漏れはないか？ １．以下情報の相互チェックを行う ・「JCL分析」の業務プログラム ・「PL/I分析」のプログラムメンバー ■DCプログラムに漏れはないか？ １．以下情報の相互チェックを行う ・「PL/I分析」のプログラムメンバ
大型汎用機（ホストコンピュータ）で 使用されている言語、 COBOL、PL/Iについて簡単に 解説します。 ■COBOL （1959年誕生） １．事務処理言語統一のため、 アメリカ国防総省の提案後、 CODASYLにより開発される ２．言語仕様は古いが、拡張が 続けられ、オブジェクト指向にも 対応し、稼働プラットフォーム も多い ３．オープン化が進められ、 Windows、Linux上でも稼働する ４．レガシーシステム （過去
