【一般会計】 仕訳種別 は一般的ではない？

 このところ会計の仕事をしているのですが、今まで普通と思っていたことが実はあまり一般的ではないことに気付きました。仕訳種別です。会計システムの主軸項目に、決算期、勘定科目、部門があることは間違いないかと思うのですが、実務上は仕訳種別が必要というか肝です。決算期、勘定科目、部門は考える要素はほぼありません。補助科目もだいたい顧客とか仕入先とかですね。仕訳種別は前期繰越、普通記帳、決算整理など勘定科目とは別軸で仕訳の性質を表現するために使います。試算表を確認する際に役立ちます。仕訳種別のない会計システムで決算を行うことなど想像できないのですが、どうもこれが一般的ではないようです。大企業向けの会計システムSAPでは伝票タイプという名称で用意されていますが、他ではわからなかったです。

EXCELのシンプルな仕訳帳

仕訳種別はごく普通のものだと思っていました

摘要には仕訳個々の事由を記載するので業務的なまとまりを示す仕訳種別を記載してしまうとシステムで(簡易に)集計することができません。なので仕訳種別という項目を独立して用意します。前期決算が完了・確定する前に翌期が開始されます。そのため概算残高でいったん翌期繰越を行い、債権債務確定、原価在庫確定と順を踏んで何度か繰越を行いますが、仕訳種別があれば再繰越を行っても他仕訳と取り違えることもありません。個人事業でも上場会社でも同じことです。いまだにERP、市販会計ソフト弱いです。

また原価管理だと原価要素という勘定科目とは別の勘定軸や、工程という部門とは別の部門軸を設けています。摘要とは別項目にするのは仕訳種別と同じ理由です。在庫受払、原価計算、資産評価は個別開発(もしくはハンド対応)になるのですがその話はまた次回に。

ACCESS アクセス が動かなくなった!

Officeアップデート の ODBC トラブルです。2022年5月24 日リリースのバージョン2205を適用するとODBCがおかしくなります。リンクテーブルで主キーが文字列型だとアウトです。MariaDBもこの影響を受けました(MariaDB ODBC Driver 3.1)。

対策はOfficeのダウングレードです。関連リンクの [ACCESS]#Deleted問題 が助けになります。私は被害なしだったのですが、ベータテスト（＝MS社内・シンパテスト）どうなっているのでしょうか？ERP、パッケージソフトのデータベーステーブルの主キーは文字列型になっていることが多いのですが。

cd %ProgramFiles%\Common Files\Microsoft Shared\ClickToRun
officec2rclient.exe /update user updatetoversion=16.0.15128.20248

関連リンク

[ACCESS]#Deleted問題

Officeの更新履歴

 

会計ソフトが動かなくなった！

令和3年度の確定申告無事終わったでしょうか。私は年末年始に個人事業の決算と必要書類の整理をするのですが、某社の会計ソフトを起動したところ自動更新の不具合でそのまま動かなくなりました。アクセスの自作会計ソフトをメインで使っていたので穏やかな年越しをすることができましたが、過信禁物ですね

（下の画像はアクセスではありません。Googleスプレッドで作った仕訳帳です）。

Googleスプレッドの仕訳帳。ギリギリ使えそうです。

ピボットテーブルが使えるので仕訳帳から試算表

決算整理は手入力ですが、BS、PLの小計が0になるようバランスするだけです

90年代はこの手の不具合はしょっちゅうでしたが2020年代になってもまだこんなことがあるとは！市販ソフトやクラウドはブラックボックスなのでシステム不具合時はバックアップも意味がありません。来年以降は電子帳簿ごとクラッシュするのでしょうか。

システム設計で一番重要な考え方は simple is best です。中でもデータベース設計がカギになります。重要なデータを格納するテーブルをコアテーブルと呼び、教科書通りの単純な構造とします。会計であればコアテーブルは1つしかありません、仕訳帳テーブルです。私のような個人事業者でも日本を代表するような大企業でも違いはありません。

重要な仕訳帳はEXCELに簡単にコピー出来るように設計します。何かトラブルがあっても仕訳帳を開くことはできます。そもそも記帳の手前で、EXCELのシートを費目別に分けて整理していると思います。自作の会計ソフトは費目別シートからの転記を便利にするために作ったものでした。

今回のケースはアプリケーション障害とデータ喪失にあたります。クラウドではないのでデータ流出の心配はありません。大ごとではありますが、別のアプリケーションを並列運用していたので実害はありません。社会インフラ系では、一世代前のシステムを待機系として維持する方式が以前はありましたが、最近は聞きません。現用系と待機系で異なるシステムを持つというのは、企業・商用システムの障害対策、可用性対策として見直されてもいいかもしれません。

Googleスプレッドの仕訳帳は、アクセスの会計ソフトをさらにシンプルに出来るのでは？と思いついて作ったものです。(総)勘定元帳兼用になっていてフィルターで勘定を絞ると相対勘定と合わせて確認することができます。決算整理は手入力ですがバランスさせるだけなので大した手間でもないと思います。アクセスは自動計算にしていますが、そのロジックを抜くとGoogleスプレッドで試算表まで行けてしまいます。Googleスプレッドで仕訳記帳と決算が出来るのは個人事業者にとっては大きいです。それを実感したくてEXCELで作ったものをGoogleスプレッドにUPしました。EXCELなのでソフトの使い方を新たに覚える必要もありません。これも大きいです。

結局 simple is best ということでしょうか。資産台帳、減価償却、在庫評価、原価計算などありませんが、私の仕事ではすべて0行なので。

中小企業の上手なITとのつきあい方

デジタルという言葉は毎日ように聞こえてきますが、企業向けのデジタルは何であんなに高いのでしょうか？PCが10万円そこそこなのに業者からの機器見積もりは数百万円が普通です(故障率に差はありません)。家にインターネット引くのと会社にインターネットを引くのも10倍違います。Webサイトは10倍ではきかないケースもあるようです。大企業はいざ知らず中小企業は参ってしまいますね。電子化、クラウドと騒がれても結局出費がかさむだけです。

そんな疑問に、IT企業に属さない専門家ならではの裏話を友人が話します

中小企業の上手なITとのつきあい方セミナー

会計、法律、労務の専門家がいるようにシステムの専門家もいていいようなものですが国の制度に基づくものではないので、なかなか難しいです。友人も私も専門分野に分業化してしまう前からITを経験しているので、見積が膨れ上がる裏事情を知っています。セミナーは会員限定のようですが、後日一部をご紹介できると思います。

永島志津夫

簡単！電子帳簿保存

改正電子帳簿保存法の施行が延期になりました。難しく考え過ぎているようです。間違いなくIT屋がいけないのだと思います。私は会計帳簿を自作のアクセスで管理しています（連結会計システムを開発していた役得です）。元々売上仕訳は契約書類のPDFを添付できるようしていますが、契約通知、請求書送付メールへのリンクを追加し他の仕訳も同じ修正をしました。

電子メールはメールサーバによる授受の記録が正確なタイムスタンプと共に記録されています。郵便の消印にあたるもので改変ができません。最も身近な電子証跡です。これを利用しない手はありません。売上仕訳は相手先、金額、計上日を持っているので仕訳を検索をすれば自ずと電子証跡を確認できます。同じことを仕入、経費に適応すれば電子請求にも対応完了です。後日メールやPDFを探す手間もかからずおすすめです。

紙の請求書を無理に電子化する必要はありません。電子メールやWebで授受される契約書、請求書を会計帳簿から容易にたどれるようにしておけばOKです。

永島志津夫

ランサムウェア対策は？ 基本に忠実なセキュリティ設計でシステム寿命も長くなります

コンピューターが進化し、面倒なアップデートにも付き合い、コストも払っているのになくならないセキュリティ被害、どうしたらいいでしょう。ヒントはコンピューター、ネットワーク技術の基本理解にあります。商用OSのセキュリティの基本的な考え方は、セキュリティソフトをアドオンするのではなく、リスク要素を除きシンプルにしていくものでした。いつの間にか基本がなおざりになった感があります。インターネットが日本で使われだした頃を思い出しながら、基本注意事項をまとめました。20年、30年と使い続けられた設計や技術はシンプルで費用対効果が高く、システムの長寿命化に寄与します。

 

１．管理者権限でログインしない(必須)

Windowsで理解できないのは管理者権限でネットサーフィンが出来ることです。インターネットは自己責任です。相手が国外であれば日本の法律は無力です。交通ルールが定かでない国で運転するのと同じです。ドライブは出来ても安全ではありません。

・管理者権限のないアカウントを作成し、通常のログインはそれを使うようにします。

・アカウントのパスワードは英数字、記号などランダムな16文字以上として紙に書いて保存します。セキュリティ情報はシステムから分離の原則です。

２．セキュリティの高いブラウザを使う(是非)

広告、特に仲介業者を通したアフィリエイト広告が氾濫していて、どこに落とし穴があるか分かりません。安全なブラウザを使うことで、アフィリエイトを抑止できます。表示されない以上、クリックすることもなくなります。フィッシング詐欺対策にもなります。

お天気サイトを閲覧した例

Google chromeの画面、アフィリエイト広告を抑止できない

Firefoxの画面、アフィリエイト広告を抑止できている

３．アプリを入れない・入れさせない(必須)

管理者権限がなければアプリを入れることもできません。利用者がそれと知らずメールやWebでだまされてアプリを入れてしまう事故も起きません、ウィルスやランサムウェアの被害が発生してもはログイン権限の範囲内に留まります。

４．Windows以外のOSを使用する(是非)

ここからはシステムの専門領域ですが現在ではLinuxを選択することが多くなると思います。LinuxはオープンソースでOSの技術情報や運用ノウハウに透明性があります。良いことも悪いことも広く共有され、OSについて知ることの出来ない情報はありません。そのためセキュリティ対策を立てやすく、迅速に対応することができます。

５．ネットワークからログインできないようにする(是非)

セキュリティは流行り、廃りとは関係ありません。機密性の高い情報を扱うシステムは監督者と物理的に近い場所に設置し外部とは遮断します。利便性とセキュリティはトレードオフになります。政府、金融機関等では現在でも普通に行われていることです。

Linuxであってもネットワークからログインできないようにします。サーバというと以前はシリアルポートからの接続が基本でした。シリアルコンソールは導入・運用が容易で費用対効果が非常に高いものです（導入コストはただみたいなもの）。大企業はもちろんのこと、中小企業、スタートアップ企業にこそ導入して欲しい対策です（DDoS対策・ファイアウォール、リアルタイム侵入検知、ウィルススキャン、証跡ログなどどれだけのコストが掛かるでしょう？設定ミスは大規模トラブルの元にもなります。専門知識、専門家の助けも必要不可欠です）。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します）

寿命30年の自社開発システム！

（システムの費用対効果〈 システムの寿命 〉を改題）

30年動いてきたオフコンがありました！すごいですね。開発の費用対効果もさることながら、バージョンアップやデータ移行などの無駄もなくシステムの鑑です。パッケージ、ERPの方が楽だというのは本当でしょうか？大企業でなければERPのバージョンアップコストとても払えません。

30年前の設計書も残っていました。手書きで感動しますね。設計書を見ると、30年の間にシステムの使われ方が変わってきたことがわかります。現在は販売管理業務がメインなので使用帳票とヒアリングから、業務フロー、データ定義、画面プロトタイプも起こしました。ただ30年前のデータ仕様書は参考にしました。業務システムの根幹はデータ設計です。今回のシステムはマスタ以外のデータ移行はないので、テーブル構造、データ定義の制約はないので、データ設計をさらにシンプルにしましたが、イレギュラーケースの想定など念のためデータ仕様書を確認しました。

リレーショナルデータベース（MariaDBです）のビューやトリガのおかけで性能を維持しプログラム数も減らすことができました。フロントエンドがアクセスなのでクエリにデータフローを記述できるので手書きのプロシージャも最小限です。その分、便利機能を盛り込むことができました。

過去、私の関わった比較的大規模なシステムで、アパレル全社基幹システム、医薬品卸営業支援システム(SFA)、配送トラック動態管理サービス* があるのですが、どれもシステム稼働から10年を越えて安定稼働を続けている・続けた* ものです。ハードウェア交換は行っていますが開発されたプログラムは動き続けています。どれもスクラッチ開発です。

一方、パッケージ導入は稼働延長したものでも8年が限界でした。意外なのですが、パッケージの方が寿命が短いです。古い環境に特別対応できないからですかね？メジャーバージョンアップにぶつかって、実質的に再導入というケースもありました。もう別の製品ですね。

パッケージといっても大体アドオンするのでそんなに安くないし、アドオンプログラムのバージョンアップ対応でお金が出ていきます。製品保守費の15-20%が毎年自動的にかかっているのに、さらに上乗せされるお金です。会社の中で、金食い虫と情報システム部が白い目で見られる訳です。でも自社システムを開発する要員もいないし、中途半端にベンダーに頼らざるを得ないのが現状ですね。問題は業務別のシステム、パッケージという名のブラックボックスの乱立で、今度は運用管理やデータ連携に苦労することです。そこまでは外部に頼れず、結局、運用管理にシステム部の人手がとられてしまう。悪循環です。

パッケージソフトって、それ一つだけだとメリットが感じられるのですが、複数の組み合わせとか、連携とかになると途端に出来ないことが出てきて運用しづらくなります。
ユーザサイドも苦労して導入したソフト、せっかくなので長く使い続けたいですね。費用対効果のメリットも出てきますから。運用まで考えてパッケージ選定、システム設計したいです。

パッケージ導入、コツがあります。システムフローの尾っぽ部分はセーフです。頭部分は要注意、胴体部分は・・・
SAP 困っていませんか？ 国産ソフト、クラウドベースやオープンソースですっきりさせるのも一案です。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します

追記 2020年1月6日
ワークフローソフトをパッケージ導入頂いたお客様を久しぶりにご訪問させて頂きました。無事、運用されているとのこと。安心いたしました。
お客様が大変協力的で（システムは賢くはないことをご理解いただき）アドオンなしで導入頂いております。末永くご利用いただきたいと思います。

30年後も動いているシステム設計

システムの寿命を縮めるバージョンアップ、Windows11のリリースがアナウンスされていますが会社でPC管理している方にとっては面倒なお話です。社員1人に1台ずつPCがある時代に、機器やOS、他ソフトウェアの更新、その計画、費用、手順等々・・。在宅、テレワークということもあり今回はこれまで以上に面倒になりそうです。経営からは「なんでそんなに金がかかるんだ！」と言われ。情報システム部がまた悪者扱いされそうです。

本業と関係ないところで手間がかかる断トツの悪者がパソコンです。Windows登場当初からアップデートと保守切れ問題はありましたが、Windows10になってからウィルス対策の頻繁なアップデートが目立ちます。システム管理者権限でログインしないというのが一番のウィルス対策なのですがWindowsはもう戻れなくなり、負のループに陥っています。Unix系では当然の対策である管理者権限のないログインはWindowsでも有効なので自衛策としてオススメです。

OSに加え、データベースソフト、パッケージソフト、ERPなどのバージョンアップ＝保守切れが業務システムの寿命を短くをする原因になっています。自社開発の場合は保守切れはありませんが、OSやデータベースソフトのバージョンアップの影響を受けることがあります。

業務システムの要はデータベースです。幸いデータベース設計の考え方は30年前から変わっていません。業務に適したデータ構造、データ間の主従関係、i一意識別子の設定です。一般会計であれば、決算期、勘定、部門などを主マスタとした仕訳データテーブルとします。設計の基本は30年前から変わっていません。基本を守れば30年後も動いてるシステムを設計することができます。流行りベストセラーに惑わされずロングセラーに徹します。

私が仕事で使用しているパソコン、2010年製造ですが問題なく一般会計と販売管理のデータベースが動いています。SSDに交換しているので性能も満足です。

ところでWindows10は2025年までサポートされるようです。またオフィスソフト（ワード、エクセル、パワーポイント）なら、FreeOfficeも使えるのでLinuxも良いと思います。

永島志津夫

今さら？Googleフォームで注文受付

Webシステムはクライアントサーバよりも開発に手間取ります。スマホ、PC様々なブラウザ、バージョンへの対応という厄介な問題がありシステム寿命も短く、自前で作ることはお薦めできません。ただ、あり合わせで使える場合は例外です。高い開発生産性、費用対効果が期待できます。簡単なアンケートに特化したGoogleフォーム（Forms）がその一例です。

流行りのデリバリーもこんな感じで。

Googleフォーム、帳票はいたってシンプルなのですが、注文が入ると自動的に通知メールを飛ばせます（お客さんには注文確認、お店には注文通知）。これを使わない手はありません。メール通知はセキュリティも関係し、開発するとなるとそれだけで結構、手間と費用がかかります。Googleフォーム、優れものですね。

またGoogleフォームはユーザ管理を完全に省略しています。何か代用が必要なのですが、実はメールアドレスがここでもポイントになっています。ユーザ管理をショートカットした効果は大きいです。結果的に大変シンプルなソリューションになっています。

あり合わせ（AsIs）で使えれば儲けものと考えましょう。一歩でも個別開発に踏み出せば途端に苦労します。注文受付はGoogleフォームでカバーできそうです。

受付の後工程、受注・販売管理をWebで作るなんて無謀なことはやめましょう。開発費が数倍に膨れ上がります。そこは、今さら？クライアントサーバ 方式で。

Googleフォームから自動的にデータを取り込むことが簡単にできます。データベースは業務システムにとっては本当に魔法の箱で、進捗・配送管理、送り状、納品書、請求書、会計仕訳など小回りよく応用が可能です。Webと違ってアクセスなら動作環境を気にすることもありません。そもそも365にバンドルされているので使わないと損というものです。

マイクロソフトもGoogleも使いようです。オープンソースと合わせてバランス良く。

デジタルトランスフォーメーション、要はこういことです。

永島志津夫

オフィスエヌ ショートレビュー5万円から。
全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。

中小企業のテレワーク 手軽で安全なネットワークは？

大企業では定着しつつあるテレワーク、自宅から会社のシステムへの接続に困っていませんか？ベンダーからの高額の見積に断念した中小企業の方もいるのではないでしょうか？高い安全性で月々のランニングコスト数千円で済む方法があります。

既存のネットワークには手を入れません。データ通信のSIMを入れられるリモートアクセス用のルータを設置、自宅とルータの間の通信を暗号化(VPN)します。社外からのアクセスを許すシステムにネットワークインターフェースを追加し、システム、アプリケーション側で機能制限をかけます。

※この制限は必須です。社外アクセスを許可すると1時間と待たずに様々なアタックが始まります。社外からのアクセスに制限を設けない設計はあまりに危険です。

この方式はインターネットの世界では古典的な設計で、信頼性も高く堅牢です。保守性も良く、無理がないので長く使い続けることができます。セキュリティにも優れておりベストプラクティスの一つに違いないのですが、提案するベンダーはまずいません。

・固定回線の通信事業者は提案しない（モバイル回線では商売にならない）

・機器販売の代理店は提案しない（安い商売にはつきあえない）

・ネットワーク＋システム、アプリケーションの知識も必要

IT業界も専門毎に分業化されており、ネットワークとシステム、アプリケーションの両方がわかる人は限られています。両方がわからないと全体最適の設計は出来ません。セキュリティまで含めネットワークだけで解決しようとすると、ファイアウォール、侵入検知装置の導入など大げさで高額になります。無理のある設計は寿命が短いのでライフサイクルコストも高くなります。

結局自分たちで何とかしないといけません。実際、あるお客様では、通販でルータとSIMも調達しました。どちらも1週間以内に用意できました。値段もさることながら、見積をとっている間にテレワークの準備が出来てしまいます。

企業用機器が通販で買える時代に、ＩＴ業界はいつまで古い商売続けるのでしょう？機器は格安で調達でき、ランニングコストも格安スマホと同じレベルです。

VPNはインターネットからのアクセスを許すので、専門知識が必要です。　ご紹介した構成は、既存のネットワークと独立しているので、ビギナーでも進めやすいのですが、後々、危ういことになったり、追加コストで大変な目に合わないよう、疑問、不安があればご相談ください。

永島志津夫

オフィスエヌ ショートレビュー5万円から。

今さら？Accessで会計ソフトを自作 バージョンアップもシステム寿命も心配なし

SQLを知っていると会計ソフトは自作できてしまいます。SQLは本当に会計処理と相性が良くて、かのオラクルも当初のアプリケーションは会計でした。アクセスのビュー定義（クエリ）だけで試算表まで出来ました。

会計ソフトに入力する前に、売上や経費をエクセルで管理することが多いと思うのですが、会計ソフトにコピー＆ペーストできません。毎月同じように発生する経費を逐一入力しないといけません。会計ソフトの中でコピーも出来るのですが、エクセルのようにはいきません。売上の場合は売掛金の入金消込もあります。決まりきった入力があまりに多いのが自作の理由です。減価償却もないので会計ソフトといっても簡単なものです。

工夫したのは、毎月同じように発生する経費入力画面です。金額を1ヶ所に入れれば、SQLの力で12ヶ月分の仕訳が自動的に作られます。

売上はエクセルからコピペしやすいよう、データシートに入力します。また証憑ファイルもデータベースに添付できます。これは便利です。顧客と月次でインデックスになっています。一般の会計ソフトにありそうでない機能です。

顧客１，２，３は次の画面で定義します。私のような仕事だと得意先数は知れたもので、だいたい年度が契約の単位なので年毎に得意先を定義するようにしました。支払サイトも定義しておき、入金消込も自動で仕訳生成します。

※都度発生する経費は普通の手入力仕訳画面です。

COBOLは事務処理に向いているといいますが（なのでSAPの開発言語ABAPはCOBOLライク）、SQLはさらに強力です。画面と帳票にアクセスを使えば、中小企業から大企業まで、ほとんどの業務をカバーできます。システムの寿命の長さという点でも有利ですね。PCのパフォーマンスがCOBOL全盛期のスーパーコンピュータを超えている現在、性能には何の懸念もありません。→今さら？クライアントサーバ

自作なので費用対効果は言うまでもないのですが、空き時間を見て1週ほどで作りました。アクセスは手軽なので商業高校の簿記とコンピュータの実習にもピッタリです。もちろん大企業も活用できると思います。バージョンアップやシステム寿命の心配もありません。

永島志津夫

※アクセスで自作した会計ソフト、自分のようなコンサルタント、システム設計業用のものです。在庫なし、原価計算なし、固定資産なし、減価償却なしで、売上と経費から税引前利益＝資本勘定が直ちに決定します。製造業だとこうはいきません。

個人事業の場合、特別なことがなければ試算表＝決算書となります。また株主資本等変動計算書（旧 利益剰余金計算書）はなく、事業主貸借勘定がそれに相当します。なので作りは簡単で会計ソフトとしては必要最低限の機能しかありませんが、Excelから自由にコピーできるので、個人的には使いやすいと感じています。

大企業よりも難しい？中小企業のシステム導入

大企業のシステムプロジェクト、バリューエンジニアリングのお手本になることはまずありません。何故でしょう？

1. 30%の保険コスト
2. 10%以上の事務局コスト
3. 10％前後の承認待ちコスト
4. 30%のエンジニア・マージン
5. さらに機器、ソフトウェアなどの調達品のマージン

どれもこれも、ユーザ、発注者からすると腹が立つコストですよね。トータルで２倍前後になります。機能、性能、品質は変わりません。納期も短くなりません。システムの寿命が長くなるということもありません。まったく最低です。

でも大企業側が自分で責任を持つから、安くしてくれという話は聞いたことがありません。システムプロジェクトの失敗が怖いからです。

しかし中小企業の社長さんが、こんなバカげたコストを認めるでしょうか？システムインテグレータが中小企業を避ける理由の１つがこれです。

ホームページくらいなら目をつぶるにしても、気になるのは販売管理、在庫管理システムです。IT業界も２０代で辞めてしまうことが多く業務知識まで頭に入っているエンジニアは大手でも多くはありません。業務要件は大企業でも中小企業でも変わりません。あたりまえですが勘が働かないと要件定義は出来ません。出来ていないことすら気付けません。

冒頭のバカけたコスト、要はシステムインテグレータの教育代です。大企業は払えても中小企業は払えません。実は中小企業のシステム導入は経験者にしかできません。中くらいのエンジニアでは出来ません。しかし規模の小さい案件に限られた経験者をアサインすることはシステムインテグレータの商売の理屈として成り立ちません。これが理由の２つ目です。

売上高100億円から1000億円の事業だと、オフコン現役というところも珍しくはありません。IBMだと AS/400、NECだと A-VX、他富士通など。そろそろ寿命も尽きます。そこで新システム構築なのですが、パッケージソフトがはまりません。大企業では逆にパッケージソフトやERPからの移行という案件も聞きます。だいたい無理にパッケージ、ERPをはめ込んだシステムは寿命が短くなります。パッケージの方が費用対効果が高いとは限りません。

お医者さんや、大工さん程ではありませんが、システムエンジニアにもヤブと腕利きがいます。腕利きにあたれば同じコストで、タフで使いやすく、長期にわたり安心、安全に使えるシステムが出来上がります。大手に依頼しても運が悪ければ、そもそもプロジェクトが進みません。疑問があればご相談ください。

永島志津夫

オフィスエヌ ショートレビュー5万円から。
全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。

今さら？クライアントサーバ オープンソースとAccess

販売管理、生産管理などの基幹システム、最も生産性の高いアーキテクチャは2021年の今もクライアントサーバです。

業務管理システムとして、ユーザの操作性、費用対効果、システム寿命の3つの点で最強の組み合わせはクライアントサーバです。

Webアプリは元々、限られたサーバリソースをコネクションプールを経由し効率良く使うためのものでしたが、性能が向上した今では、家電量販店で売られているPCで3万人企業のデータベースも快適に動かすことができます、クラサバで。

最近関わったプロジェクトのシステム構成が冒頭の図です。MariaDBですが8コアで毎秒300トランザクション以上の業務処理ができます。8コア8GBのPCなんて10万円もしません。

MariaDBはレプリケーション構成も出来るので可用性対策も簡単に済みます。ネットワーク障害やセキュリティ対策のコストを考えるとクラウドよりもオンプレミスでマシンを持ったほうが有利です。拠点間接続も10万円程度のルータでインターネットVPNを組めます。これもIoTニーズのおかげでSIM内蔵でVPN機能を持つルータが10万円くらいです。

Webブラウザの仕様違い、バージョンアップにさんざん悩まされて、もはやPCで最も重いアプリになってしまった現在、業務システムをWebベースにする必然性はありますかね？

どうか、流行り言葉（ＤＸとか？）に惑わされませんように。

永島志津夫

オフィスエヌ ショートレビュー5万円から。
全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。

確定申告と言えば決算ですが、帳簿はどうしましょう？

確定申告、早々に済ませたいですね。個人事業主の場合その前に決算をします。日頃の記帳が出来ていれば決算は簡単です。仕訳帳を合算してBS,PLにおかしなところがないかの確認くらいです。システム設計だと毎月の記帳などしれたもので、売上、費用、売掛回収など10件もありません。私は固定資産、減価償却はないので会計ソフトの機能が多過ぎるのが気になりました。Excelに付けているメモを会計ソフトに転記しているので二度手間ですし、Excelで決算まで完結させたくなります。

そもそも表計算ソフトの主な用途がアメリカの確定申告でしたね。

会計ソフトの機能は突き詰めると記帳と決算です。基本となるデータは仕訳帳テーブルです。仕訳帳は会計システム唯一のトランザクションテーブルです。仕訳帳を合算する際の条件や合算項目（集計軸）によって決算書、試算表、各種元帳、月次売上推移表などに見た目が変わりますが、ファクトは1つということです。システム設計としては簡単で、せいぜい貸方、借方で1記帳2レコードになることと、勘定科目の貸方、借方に応じて符号があることくらいです。なので仕訳帳をもとにピボットテーブルを作れば、決算書になります。形式に凝ることもないのでBS,PL,SSが一緒になった試算表形式がいいと思います（個人事業の場合SSはBSの事業主貸借で済ませます）。貸方がマイナスになりますが、自分しか見ないので、そのままでも、エクセルの表示形式で直してもいいです。

このようなイメージになります。ピボットテーブルで決算書になるのか？という疑問があるかもしれませんが、会計ソフトの内部ではピボットテーブルと同じことを行っています。BIと会計は相性が良くて多次元データベース Essbase も管理会計の定番でしたね。

オンライン版のExcel（Office365）でも使えました。シート間参照、ピボットテーブルも問題ありません。FreeOfficeの表計算もOKでした。私はこれで十分です。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。

オフィスソフトもオープンソース

サーバーOSではLinux系が主流になって久しいですが、デスクトップも間近かもしれません。最後の砦であるオフィスソフトもマイクロソフト一強ではなくなってしまいました。互換性と使いやすを合わせ持つ Free Office （FreeOffice）を使ってみたというお話です。

Windows10 、何もしていないのに、しばしばディスクがフルアクセスされたり、CPUが100％ 近くに張り付いていませんか？勝手にOSのアップデートを行っているからなのですが、オフィスワークだとCPU時間の7割以上がOS自体の維持メンテなのではないでしょうか？たまに家のPCをONにすると、アップデートが顕著ですね。ユーザよりもOSの保守が優先されています。おかしくありませんか？サーバだったら大問題になります。

ソフトウェアの基本は単純であることです。Windows に比べ、単純、軽量な Linux がサーバで好まれる理由がここにあります。性能、可用性、セキュリティどれをとっても、単純な OS が有利です。熟練したシステム設計者は、求められる要件、場合によっては要件そのものもシステムに無理のないよう調整して、費用対効果の高い設計をします。後付で必要な機能も最小限に抑え、使わない機能はオフ設定にします。

Windowsはほぼこの裏返しです。システム設計者がついているわけでもないので無理もないのかもしれません。ユーザは何も知らない、できない、何をしでかすか分からない、という前提で、途方もないユースケースを検証したのでしょう、OSが肥大化してしまいました。さらに、ネットワークがつながる限り、OSを自己保守、最新化するという機能が実装されました。自己保守機能が問題というより、その程度です。”コンピュータを使い続けるための保守から、保守のためにコンピュータを使う”  本末転倒ですね。

昨年の大規模アップデートで懲りて、最近 PC のハードディスクをSSDに換装したのですが、空き部分に Linux (Ubuntu) を入れました。OS + Firefox + Python + FreeOffice で 9GB です。 Firefoxがあればメールもストレージも使えるので、ちょっとした仕事はできますね。Webベースでオフィスファイルも閲覧、編集できますから。そして FreeOffice ですね。マイクロソフト・オフィスではありませんが、ほぼ同じことができました。ほぼというのは、マイクロソフト固有の凝った機能は、互換性のある別の機能で代用すれば済むということです。Windowsの自動更新を我慢してまで、使いたい機能が果たしてマイクロソフト・オフィスにあるでしょうか？印刷もPDF経由ならドライバーの問題もありません。

あと、Python が入っているのは、なかなか便利です。昔のBASICと同じです。ちょっとしたプログラムを組めます。学生さんだったら Ubuntu で何の問題もないのではないでしょうか。この記事は Ubuntu から書きました。日本語もOKです。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。

入札提案の実際(2) 工数計算と進捗報告

技術点は必要条件、価格点は十分条件と前回紹介しました。価格点に少なくないウェイトを占めるのが工数です。進捗報告の基準にもなる工数計算ですが、みなさん自信ありますか？

工数計算は設計屋の仕事です。では、プロジェクト企画、計画作りは？プロジェクトマネージャーの仕事ですね。プロジェクト計画の根幹である工数計算をプロジェクトマネージャーが検証できる能力、経験があればよいのですが、なかったとしたらどうでしょう？設計屋の計算をそのまま採用するのでしょうか？それでは品質管理の基本要素であるダブルチェックが効いていないことになります。

プロジェクトの品質管理はどれだけ正確にタスクを洗い出し、工数計算を行い、リソースとのバランスからスケジュールを立てられるかにかかっています。それがシステムの品質を決めることになります。議事録、要件定義書、設計書、プログラムなど個別成果物のレビュー、ダブルチェックも重要ですが、プロジェクト計画が妥当なものでなければ、個々の努力も水泡と化すでしょう。

品質管理プロセスは重要です。プロジェクトの最初の品質管理は、プロジェクト計画に対して行います。この時点で成否は半ば決まります。

工数計算ですが、設計者自身が複数の方法で自己検証します。積み上げ法と経験法ですね。ダブルチェックは積み上げ法の要素分解の妥当性を検証します。もちろん経験的に工数が大きく逸脱していないかも見ますが、大きな逸脱があるなら設計者自体が問題です（アサインミスです）。

プロジェクトマネージャーは自分自身で要素分解を行い要素毎の工数を見積もります。安全バッファーなどを考慮し最終的なスケジュール、工数とします。工数計算はスケジュール、進捗管理と連動しています。しっかり移行、総合試験、受け入れ検証の期間をおさえることが重要です。

工数が膨れる要因は上流工程にあります。プロジェクト計画の具体性・現実性、要件検討会の運営、要件定義から基本設計にベテランをあてられるか、にかかっています。

開発スタッフの単価、人数で、基本設計のまずさは取り返せません。はじめが肝心です。納期、品質で取り返しのつかないことにならないようにしましょう。

EVMで進捗報告を行うことがプロジェクト管理の要求要件になっている入札案件もあります。正確な工数計算とプロジェクト計画、なおさら必要ですね。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。

入札提案の実際(1) 技術点は必要条件、価格点は十分条件

入札提案の実際はどんなものなのか？開示できる範囲で紹介したいと思います。

一般競争入札では入札公告前に意見招請が行われることがある。

仕様ないし入札条件について質疑、意見発言ができる重要な場である。

入札金額と技術評価

入札は安く札入れをした提案者を落札者としますが、入札方式も種類があります。システムでは総合評価方式をとることが多いのでその紹介をします。

総合評価方式では

総合評価点＝価格点＋技術点として、総合評価点の最も高い提案者が落札します。

見当違いの提案者が安値で落札されても困るので、提案内容も評価するというものです。

技術点は評価表が公開されますので、それに従って加点されていきます。ただし必須要素というものがあり、これが提案書に記述されていないと失格になります。

価格点は次の式で決まります。

価格点＝入札価格に対する得点配分×（１－入札価格/予定価格）

ただし、入札価格が予定価格を超過した場合は失格になります。

入札価格は開札まで明らかにされません（封筒に封かんされています）。もちろん予定価格も封かんされています。開札の時点で初めて担当者もこれらの数字を見ることになります。

提案者としては技術点は必要条件、価格点は十分条件と考えればいいと思います。

”自分たちは必要条件を満たせるシステム設計、プロジェクト運営ができるかどうか？”かつ ”想定される競合他社よりも費用対効果に見合うシステム提案ができるか？”

コンペ自体は民間案件よりも公平感があります。当て馬ということもありません（仕組み上出来ません）。なのでベンチャーがチャレンジするには格好だと思います。そもそも政府入札案件なんて案件実績としては抜群です。官報に公表されます。

基礎検討と提案書作成

入札仕様書は100ページくらいあります。A4文書で5万字くらいです。

要求仕様そのものは20ページくらいで、あとは提案要綱、情報管理規定、契約書等です。

私が作成した提案書本文は50ページくらいでした。50ページのパワーポイントではありません。A4文書として50ページです。3万字くらいです。図・表は別添形式です。

さすが国として公開される要求仕様書です。入札仕様書は曖昧さがないようにしっかりしたドキュメントになっています。プロジェクトリスクを抑えるため、要所要所で重要な要求が書かれています。入札審査は書類審査になります。プレゼンテーションはありません。

読解、論理・文章構成

なんだ20ページ、そんなものかと思われるでしょうか？これまで数億円規模のRFPを出す側も、提案する側も複数回経験してきましたが、それらに比べても入札提案はなかなかハードです。かなりのベテランでも入札仕様を頭に入れるのに1週間はかかります。それまでは1行も提案書は書けません。

ミドルレベルの設計者やPM専門屋ではそもそも頭に入りません。理解に至らず退場です。

仕様理解、提案作成の段階で提案者の能力が試されます。試されるのは、システム設計能力に加え、論理思考、文書構成力です。エンジニアが論理的に思考できるわけではありません。

要求仕様を満たし、費用とプロジェクトリスクを抑える工夫が求められます。

お金の出どころは国民の税金ですから。民間のようにプロジェクトが遅延したとか、予算オーバーしたとか、動かなかったとか言ってられないのです。それだけの高いシステム構築、プロジェクト運営能力が求められます。だからこそベンチャーにとってはどうしても欲しい勲章です。

以前にも書きましたが、設計能力、プロジェクト運営能力はタスクとスケジュールの具体性、工数計算の正確さに表れます。プロジェクトの根幹なのですが的外れな提案の多いこと。PMBOKは工数計算について何も語りません。工数計算はシステム設計者の領分だからです。論理的な思考ができるシステム設計屋でなければ適格な線表も工数計算も出来ません、もちろん経験も必要です。問題はそれらを軽視するベンダーが多いことです。なのでRFPを出す側はだめな提案を見抜かないといけません。それが入札提案書です。

入札提案書は評価表に沿って記述することになっています。基本設計に近いレベルでシステムの具体的なイメージを記述し、タスクとスケジュールを提示、このようなプロジェクト体制で期間内に実現できる、ということが合理的に伝わるように記述します。なので ”がんばります” ”がんばって作り上げます” は No です。提案時点で存在、利用可能な製品、技術を使用することが求められます。パッケージメーカにありがちな、”必要な機能を期日までに用意します” は通りません。用意できる保証も根拠もないからです。入札提案に限らず枯れた基礎技術、既存機能を絞り込んで組み合わせたシステムは成功します。工数も正確に出せますし、新しい技術にありがちな不安要素がないからです。

いかがですか？ ”うちには無理だよ” でしょうか？そもそもですが、以上書いたことは納期、品質、コストを守るためには入札提案に限らず必要なことなのですが。

※入札の基礎知識についてはこちらをご覧ください。

用語集（入札業務）

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。

官報掲載 統計センター 【ＡＩ技術を用いた文字認識サービスの提供業務】

私がシステム設計、提案した案件が官報に掲載されました。統計センター【ＡＩ技術を用いた文字認識サービスの提供業務】です。これは紙の統計調査票をAI-OCRという文字認識技術で自動読み取りしてデータの整備を行うというもので、AI技術の実使用として国内最大規模のものです。令和2年国勢調査を含む大規模調査の自動読み取りに5年間使用されます。

第3次AIブームも重要なマイルストーンを通過しました。

期待値だけでは技術の自然成長はあり得ません。実使用に耐え、経済価値をもたらすかがポイントです。同じAI、ニューラルネットでも音声認識はOCRほどお金になりません。官庁であれ民間であれ業務情報は書類として記録されており、オーディオで保存されている訳ではないからです。画像認識の応用として医療がありますが、医師抜きの画像診断に診療報酬をつけられる訳でもなく、お金になるのでしょうか？AI-OCRがちょうど実使用期に入った良いタイミングでこの入札がありました。書類を対象とするAIは今後も発展していくでしょう。

AIだけでは実用レベルのシステムは出来ません。他のIT技術を組み合わせた全体設計となって、ようやく使い物になります。要件分析、基礎設計、プロジェクト計画など全てを私が行いました。建築のような目に見えるデザイン、意匠はありませんが、システムにも筋のいい設計、悪い設計があります。基礎技術を使って費用対効果の高い、シンプルで安定したシステムを設計するのが私の得意です。1人称で書いていますが、本当に1人称です！入札提案は難易度の高い仕事ですが、落札提案がまさか1人の手によるものだったとは競合もあきれ返ることでしょう。

入札提案の実際はまた次の機会に

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します)

コンペ提案 〈勝ち抜き〉

RFPとか競争入札の提案活動のお話です。私はベンチャーが性にあっているので、だいたいチャレンジャーサイドでした。競合は大手、有名どころばかり、そんな不利な立場からの勝ち抜き、仕事の醍醐味です。

この8月（2020年）まるまる、某AIコンペに費やしました。夏を制する者は受験を制す、と言いますが8月までに下期の案件が決まるのでシステムの仕事でも8月は重要です。RFP対応とかコンペはこれまでもこなしてきていますが、これだけどっぷりというのは初めての経験です。

コンペは最後にだいたい2社の争いになります。チャンピオンサイド（大手有名どころ、既存ベンダー）対チャレンジャー（ベンチャー、新顔）になることが多いです。チャレンジャーがコストに勝るからで、大手の似たような提案は途中で絞り込まれることが多いです。コンペは、コンペをして発注先を決めたという手続き自体に意味があることも多く、はじめから当て馬というケースも多々あります。そうでなくともチャレンジャーサイドは負けること多く、光る技術、製品があっても、トータルで大手企業の求める品質基準についていけず、落とされます。会社の名前が品質を表すものではありませんが、名前で選ばれるのが現実です。

勝率は高くはありませんが、チャレンジャーが勝ち抜ける例があるのも事実です。なぜか？と問うよりも、実力勝負、興味ありませんか？ ” ここがロドスだ、ここで飛べ！ ” 

高校受験とか大学受験はみんな実力勝負でしよね。仕事でもその道何十年という経験を積んだ以上、自分の力で勝負したくありませんか？そんな機会を多く経験してきた私は幸せなのだと思います。システム大手では専門分野毎に、アプリ、基盤、プロジェクト管理・・と分担します。そもそも組織、部署が分かれていますから、担当分野以外のことに手を出せないようになっています。チャレンジャーサイドに分があるとしたら、一人の意思の全体設計で大手ではできないようなQCDを実現することにあります。顧客が見落としている大事なポイントがあれば、勝算は上がります。チャレンジャーの描くストーリーが評価基準になるからです。競合関係にない相手の場合、能力として自分より下の人間よりも上の人間を選ぶ傾向があります。 ”何でもやります” という提案よりも、 ”こうしなさい” という提案が選ばれます。名前で有名どころを選ぶのも同じ理由です。チャレンジャーはストーリーでそれ以上のことします。提案担当ができることと言えばそれくらいです。

競争ですから、案件の中身、要求仕様もさることながら、案件の状況を知ることが大切です。見極めの一番のポイントは、なぜ依頼をしたかの理由、経緯そして今後の段取りです。段取りがあいまいな相手に付き合う必要はありません。相手を立てれば案件が取れる訳でも、事業や自分が成長する訳でもありません。発注者に思い違いがないようこちらの出来ること、立場を知ってもらうことが大事です。コンピュータは人間ほど利口ではないし、簡単ではないし、開発には時間もお金かかるということです。私は最初にはっきりそれを言います。勝算のない案件に時間を使うことよりも実需に合わせた製品コア機能の拡充に時間を使うべきです。

ところで初めから勝算のない当て馬案件、見分けは簡単なのですが営業の立場だとなかなか捨てられません。ノルマがあるからですが、結局期末に悲しい結果を迎えます。当て馬ばかりというのは、営業の問題ではなくて製品、事業が当て馬レベルでしかないということです。そういう会社からは早く離れた方がいいです。ITの場合、営業で製品の不足を補うことは難しいです。いい仕事をするためには、いい環境に身を置きましょう。自己中心的、わがままでいいと思います。会社や上司も、みなさんの先のキャリアを考えている訳ではありません。その時々で役に立つ人間が欲しいだけです。自分のキャリアは自分で作る、そういう心構えがなければ、意思の通った全体設計なんてできないと思いますが、いかがでしょう。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します)

システム開発と原価計算 プロジェクト管理に実際原価がそぐわない？

製造業の原価計算システムを設計開発することもあります。前工程から実際原価を算出し後工程に反映していきます（転がし計算）。これを連結ベースで計算することもあります。そんな高度なことしつつも、灯台下暗しで、システム開発会社で実際原価計算をしているところは滅多に見かけません（私が知るのは過去1社だけです）。

エンジニアはだいたい固定給なので実際原価把握が容易なのに、なぜでしょう？どうも原因はプロジェクト管理にあるようです。プロジェクト管理と原価計算はもちろん別物ですが、一緒にやろうとすると実績原価（標準時間単価×実績時間）でプロジェクト管理して、原価差異を足し引きして財務上の原価を出しますが、実際原価に戻ってきます（当たり前ですが）。標準原価法を使ったところでプロジェクトを推進するプラスアルファは何もありません。予定原価と実際原価がほぼ一致する業種ならいざ知らず、試験や移行の工数を漏らすレベルで標準原価法を使う意味はありません。プロジェクト計画のリアリティチェックをするだけなのですが、できていないですね・・

EVM（Earned Value Management）という進捗管理法があります。これは予定原価が信頼できる前提ですから、システムの世界ではダブルクエスチョンものです。そもそも信頼できる予定原価計算ができていればプロジェクトは成功を約束されたようなものです。すべて見通している訳ですから。形式的なプロジェクト管理も必要ないでしょう。待っていればQCDいずれも満足のいく結果が得られるます。前にも書きましたが見積、工数計算はシステム設計でも高い習熟度が求められる能力です（システム開発〈見積・工数計算〉）。　要は経験、能力が未達ということで、人材不足なのでしょう。新しい言葉、言語、開発フレームワーク、資源管理・・が出ては消え、出ては消えを繰り返して、本質に切り込めず、周りをまわっているだけのような印象です。予定原価に信頼性がない以上、システム開発の原価計算は実際原価で十分だと思います。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します)