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

サーバー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 (#を@に変えてメールをお願い致します)

UI/UXとは言うものの・・・

UI/UXとか“クリエイター”さん達はかっこいい言葉を使うのですが、業務システムの場合どうでしょう？

本音ではオフコン時代からのキーでパチパチ速打ち入力がいいと思っている方も多いのではないでしょうか？あまり見ませんがWebでもできます。PCの性能が高くなっている分、Webページにマスターを持たせることもでます。通信が発生しませんから速いです。

サンプルです。1,2,3を打ってください

1日1回 朝食後

1日1回 昼食後

1日1回 夕食後

1日2回 朝食後/夕食後

1日2回 朝食後/昼食後

1日2回 昼食後/夕食後

1日3回 毎食後

薬の用法を分服回数（1日1回、2回、3回）で候補選択する様子を背景色で表示しました。同じように頭数文字でマスター（10,000件以下）を絞り込むことができます。候補をサジェスト表示するのがWebっぽいUIですが業務系では頭３文字＋スペースキーで候補表示する方が使いいいです。またUIの紹介したいと思います。

永島志津夫

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