名古屋のとある企業様（太陽光発電、家屋リフォーム）から
お問合せ頂いた内容をきっかけに、提案・開発をしたソフトが
「Google Map連携ソフト」です。
 
 
お客様のお悩み・ご要望
お客様にはテレアポ営業部門があり、太陽光発電の提案ができる
見込みのお客様のリストを作成するという業務があります。
 

その際、Excelファイルで住所等のデータをもらい
その住所をコピーし、WEBブラウザからGoogle Mapを開き
そこへ一つ一つ住所を貼り付けし、航空写真モードに切り替え
家屋の大きさや周りの様子を見て、判断し
その結果を元のExcelデータに反映させながら
見込みのお客様のリストを、かなりの時間と手間をかけて作成していました。
 

お客様のご要望としては、
「とにかく手数を減らし、作業時間を短縮し、一軒でも多くの
見込みのお客様に電話をかけて商品やサービスの提案をしたい。」
ということでした。
 
 

「Google Map連携ソフト」とは？
上記のお客様のご要望を受け、私たちが提案・開発したのが
RAD（高速開発）型データベース・ソフトをベースに開発した
「Google Map連携ソフト」です。

 
どのような機能を備えたソフトかと言いますと・・

・元データであるExcelデータを一度のコピペで簡単に「Google Map連携ソフト」に取込む
・ボタン一つでGoogle Mapが4分割画面で表示される
・Google Map画面を見ながら判断し、その結果等を「Google Map連携ソフト」に保存
・ボタン一つで「Google Map連携ソフト」から、「CSVデータ」や「Excelデータ」を出力…

 
2021年度から中学校でもプログラミングに関する内容が拡充されていきます。
とはいえ、「現状の課題は何かあるのだろうか？」と疑問に思う方もおられると思います。
そこで中学校でのプログラミング教育必修化の現状についてまとめてみました。
 
 

現状の課題は？

・小学校との接続
多くの中学校では、地域の複数の小学校から1つの中学校へ生徒が進学します。
小学校でのプログラミング教育は明確に教材や学習項目が定まっているわけではないので、
各学校の裁量に任されている部分があります。
そのため、中学校でのプログラミング教育で
どのような学習事項を取り上げるのかの調整が難しくなります。
 

・予算
多くの生徒の分のパソコンやタブレットなどの購入費用は高額です。
予算を立てるのが難しい学校も当然あるはずです。
 

・セキュリティ
学校におけるパソコンやネットワークのセキュリティのルールは様々です。
例えば、
「USBメモリを接続してはいけない」
「インターネット上からソフトウェアをダウンロードしてインストールしてはいけない」
といった決まりが設けられている場合があります。
 

そうなると、プログラミングの授業を実施するにあたっての環境構築ができなかったり、
作成したプログラムをロボットに転送できないという事態が発生します。
安全性と使いやすさが両立できるセキュリティレベルを検討する必要があります。
 
 

先生へのサポート体制
・学習指導要綱の説明会を開いたり、改訂の主旨や内容を説明する動作を作成しYouTube上に公開されています。
 
・教職員支援機構（独立行政法人）という団体では全国の先生を集めて夏休み…

 
今後、さらに求められるノーコード・ローコード開発

ノーコード、ローコード開発とは、
プログラム開発言語でのコーディングを
ほとんどすることなくアプリケーションを開発することです。
 

ここ最近「ノーコード・ローコード」という
ことばがよく聞かれるようになってきましたが、
なぜ今「ノーコード・ローコード」が注目されているのか？
 

それは、日本の企業やIT業界がかかえている課題と
DX（デジタルトランスフォーメーション）を
加速させる大きな可能性を秘めているからです。
 
(*)ミック経済研究所
『DX実現に向けたローコードプラットフォームソリューション市場の現状と展望 2020年度版』
（https://mic-r.co.jp/mr/01830/）より
 
 
日本企業の大きなIT課題
以前、当ブログ記事でも少し触れましたが
総務省によるレポートでは、
現在、多くの企業がDXの推進を阻む課題を抱えており
それを放置すれば 2025年以降、最大12 兆円/年(現在の約 3 倍)の
経済損失の可能性があると言われています。
 

いわゆる「2025年の崖」と言われるものです。
 
その課題はというと・・
 

・レガシーシステムの問題：
既存のレガシーシステムのブラックボックス化により
データ活用し切れないだけでなく、システムの改修が困難で
その保守にも多額の費用がかかるため
新しい技術やシステムに投資することが難しい。
 
・IT人材不足の問題：
2015年では約17万人だったIT人材不足が、
2025年には、43万人まで増加する見込み。
 
・ユーザとベンダーの関係性…

 
当社では、帳票作成ツールでGrapeCityのActiveReportsを使用しています。
過去にストックフォームの罫線入り用紙に印字したときに、
用紙の下の方にいくにつれて徐々に文字の位置がずれることがありました。
 
調査したところ、セクションのCanGrowプロパティがTrueだったため、
セクションの高さが自動調整されていたことが分かりました。
（※CanGrowプロパティは、TextBoxコントロールやセクションで設定できます。）
 

セクションのCanGrowは、初期値がTrueですので、
CanGrow = Trueのままになっていることがままありますが、
罫線入りの帳票を作成するときには、扱いが難しい設定です。
 
罫線を引く帳票は殆どの場合均等に線を引きますが、
CanGrowがTrueだと、セクションの高さが自動調整により微妙に高くなるときがあります。
 
例えば、セクションのCanGrowがTrue、
かつ、セクション内にセクションの高さと同じ高さのTextBoxを配置したとき、
TextBoxのCanGrow設定に関わらず、
セクションのCanGrowの自動調整によってセクションの高さが変わります。
 
DetailのCanGrowプロパティをTrue・Falseで帳票を比較してみます。
（※Detailに配置するTextBoxは、セクションと同じ高さで、CanGrow = Falseとします。）
 
 

 
 
画像のように、セクションの高さが積み重なった帳票下部では、
印字位置のずれが著しいです。

実際に印刷をして比べてみましたが、
明細全体の高さを比べると3mm程の違いが…