ファイルサーバー

思い出したので一つ書いておく。

会社にファイルサーバーがあるんだが、

『容量が足りない為、一時ファイルのみに限定して置きっぱなしにしないように』

などという通達があり、やむなく整理することに。

うーん、こういうもんは、一時ファイルこそ整理して

むしろ大事なファイルは置いておくべきだと思うんだが…。

なーんか本末転倒よねぇ。

広く浅くがいいの？

最近、設備特有の情報を「知らなくて」故障が長引くケースを目にする。
コレ絶対、適当に人動かした弊害だよな…。

どこでも見られる人材が欲しいのは分からんでもないけど
広く浅く、という方向に偏重するのもどうかと思う。


んでまた報告書も偽装するから根っこにある問題が伝わらない訳だ。

なーんかやな感じよね。

大船よいずこ

最近、カチョーの暴走っぷりが酷い。

尤も、昔からその「性質」については良く知られていたが、退職まで残すところ数年という時期を迎えて最後に華を飾りたいのか、無計画に指示（願望？）をあちこちにばら撒いてグループ長達を困惑させている。

目指すべき姿を設定し、実現方法を熟考した上で作った工程表に基づき進める、という事なら話は分かる。だが、何時何時(約半年後？)に発表したいから頼むというのは無茶ぶりもいいとこってもんだ。


カチョーがやりたい事というのは都合上、細かい内容までは書けないが、大雑把に言うと、とある部署が上手く進めている「やり方」を自部署にも展開していこうという話だ。

実はこれには自分も僅かながら一枚噛んでいいて、実現の為に自分をいまの所属から「抜きたい」というのだ。

これについては以前から話は聞いていたし、勿論本当は抜けたいのだが、大幅な組織変更により休みも取れない状況に陥ってるのに、流石に厳しいだろと思う。本当に後先考えてないというか…


おまけに肝心な部分で、とある部署の「やり方」が上手くいっているという話も建前だとわかり、もうどうするんだよ…って感じ。

出来てないことを体よく発表する体質、それを安易に信じちゃう浅はかなリーダー…
なんか色々間違ってる。


本当にこの船ヤバイ。
もっと安心して乗っていられる大船は無いのかいな。

VS2003の環境をVS2010へ

　以前、VS2003で作ったソフトは今も使われているのだが、あれこれ不具合が出ているにも関わらず、開発環境が無くて放置状態だ。

おまけに会社PCがいずれWin7に代わるとなると、まともに動くのかわからないので心配でもある。（一応動くみたいではあるが）

仕事の話なので本当は会社でやりたいが、そうも言ってられない状況なので自宅色々とやる事にした。

やる事は、開発環境の再構築（VS2003→VS2010)と、対象フレームワークのアップグレード。対象フレームワークは、会社にあるXPマシンでも動き、尚且つ将来的にWin7でも動く様に.NET3.5あたりを狙う。

Win7で動けばあの会社の事だ、１０年くらいは大丈夫だろう。その後はもう他の人に任せる事にする。

ソフトはデータベース(mdb)を使ってあれこれ管理する、といった有りがちなもの。ADOXを使ってデータベースファイルを作成したりする部分もある為、不安もあったが兎に角試す。

VS2010Expressを入れて、例のVS2003で作ったプロジェクトを開いてみると変換ウィザードが立ち上がり、何の文句も無く変換が終わった。うろ覚えだが、VS2005やVS2008あたりで試した時は色々怒られたような気がしたのだが…（まぁ警告はいっぱい出た）。

これは良いと試しにデバッグビルドしてみると、速攻でエラーで停止。エラーメッセージは以下の通りだ。

System.BadImageFormatException はハンドルされませんでした。
  FileName=Interop.ADOX, Version=2.8.0.0, Culture=neutral, PublicKeyToken=null
  Message=ファイルまたはアセンブリ 'Interop.ADOX, Version=2.8.0.0, Culture=neutral, PublicKeyToken=null'、またはその依存関係の 1 つが読み込めませんでした。間違ったフォーマットのプログラムを読み込もうとしました。

  

意味わからん・・・。

しかし、同じような状況に陥った方はやはり多かったようで、ネットをうろうろしてたら割とすぐに解決できた。原因は、(自分の環境がWin7 64bitなので)64bit向けにコンパイルしているのに、32bitのInterop.ADOX.dllを読み込もうとしたから、という事らしい。なるほど「間違ったフォーマットだ」というのはそういう事か。しっかしわかりにくいメッセージだ。

対策のひとつとして、コンパイルのターゲットプラットフォームをAnyCPUからX86にすれば良いとの事だが、Explessではそのような事が出来ない。
なので、プロジェクトを閉じておき、「ファイル」→「ファイルを開く」で、対象となる　.vbproj　ファイルを開き、直接編集する。

  
    x86
    Local
    8.0.30319
    2.0
    {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx}
    Debug

上記のように、3行目を追加してやると良い。


とりあえず一歩前進できた。

心情と立場

省人化の為、昨年末に無理なスケジュールで押し込まれた出来の悪いキカイ。

いずれ面倒を見ることになる我々ホゼンの意見は聞かず導入したため、計画部署と対立する形となっている。

自分としてもやはり気にくわなかったのだが、安定させようと苦労している様を観てるとどうしても手をさしのべたくなってしまう。

会社がタンクロ目指すと言ってる以上、協力しても良さそうなものだが、立場上そうも行かないわけで。

なんだかつまらない。

大往生

　先日、自分が作ったシステムを運用していたPCが逝った。もっとも普通のPCをサーバー代わりとして使っていた物だし、しかも誰もメンテしていなかったのだから無理もない。

昔、課が保持していたサーバーが古くなって更新という時に、代わりに与えられた物がその壊れたPCで、本当はその時点で大がかりなシステムは無理だと解っていたのに、面白半分でそのまま突っ走ってしまったのが間違いだったな。

まぁしかし、24時間毎日酷使して8年近く動いてたんだから大往生か。

問題のPCは一応修理という事になったが、案の定、中身は空っぽの新しい（でもOSはXP)PCとして納入された。

元上司に復元頼むと言われたはいいが、会社の監視下にばっちり組み込まれた状態（＝各種サービスが制限されている状態）になっていて、8年前と同じく「ルールを破る」ぐらいの事をしないとIISが動かせない為、それは無理に近い。

課長を動かして許可を得る事も出来なくはないだろうが、代替のシステムも開発途中だと聞くし、この辺で終わりでいいだろう。


少し寂しいけど。

懸念事項

OSをWindows7に移行しようという計画を会社は進めているようです。
この話を聞いたのは随分前ですが、XPですらそろそろちょっと…という感じなのに、Win2Kが現役だなんてちょっと厳しいですよね。

Win7に切り替えるのはまぁ良しとして、個人的に懸念事項が一つあったので久々にIT情報系サイトを覗いてみました。

懸念事項とは .NET Framework(どっとねっとふれーむわーく）の事。これは.NETアプリケーションの動作環境と説明されていますが、誤解を恐れず簡単に言ってしまうと.NETアプリを動かすエンジンみたいな物なのです。そして、これには色々なバージョンが存在します。

自分が過去に作った定量ソフトは.NETFramework1.1で動くようになっていて、そのへんWin7で動くのかな？と心配になったのです。

http://www.atmarkit.co.jp/ait/articles/1210/26/news086.html


上記URLにてWin7の項目を見たところ

Ver.1.1はインストールできる場合もあるが、マイクロソフトはサポートしていない

場合もある
場合もある
場合もある

 ちょっと何言ってるのかわかりませんね。
「インストールできるが」ではなく、「できる場合もある」だなんて。

そう言えば自分はWin7(64bit)でした。
百聞は一見にしかず、と言いますから試しに定量ソフトを起動してみると…あれ、難なく動いてしまいました。勿論1.1は入っていません。

まぁしかし全部の機能を試したわけじゃないし、恐らく難しいコードを書いてない分たまたま動いた、という認識でいいのかもしれません（そんなのあり得るのか？！）

どのみち頭が痛いです。もう知らん顔するかなぁ


一応、自分メモ用として下記リンクを残す。

どうする？ NET Framework 1.xアプリケーションの今後

賞味期限切れ

もう一度（オフライン）どうだ？なんて言われる事があった。

こちらとしても現在の職場が色々とキツく感じてきた(心身ともに）ので気にはなる。一応呼び戻すための表向きな理由らしきものは用意されてるらしいが、聞くとどうも誰でも出来そうな案件だし、反対する人もいらっしゃるようなので戻る事もないと思う。

表向きの理由は兎も角、本当は「色々と便利だから」と言う事らしい。ＳＥ的な仕事をさせたいんだろうなぁ。…まぁ嫌いじゃないんだけどね。

今まで事あるごとに○○が効率悪い、こうすればいいのに、とか、さも偉そうに言ってきたけど、冷静に考えると今の自分じゃもう無理だ。

あんなのはバリバリの30代の仕事で、俺ぁもう賞味期限きれちゃってるからな。

行く末

『ワシの後釜はアイツしかおらん！！』（アイツとは私の事）

と色んな人に言いまわってる予防組のI氏。

こんな自分を評価してくれるのは大変有難い事だが、何故こんな事を言ってるのかというと、
会社から完全に身を引くまであと２年を迎え、予防組の将来を危惧しているからだという。

曰く、先人の残した遺産を継続しているだけで、成熟した仕事とも言えるが実際は停滞している、もう一段上を目指した取り組みが必要（予知とか）なのだそうだ。

これには概ね同意で、将来どういう方向に向かっていくかはさておき、停滞しているのは事実。これは予防組だけに留まらず、現在の事後修理組や予備品・改善本部にしてもしかりだ。

一段上を目指す＝仕事の質を向上させるには余力も必要だ。何度かブログで書いているが、その為には全ての業務を一度整理し、合理的なものへと変えていく必要がある。

しかし組織の方向性というものは当然ながら経営陣が全て握っており、きっかけは彼らの考え方、価値観に委ねられる。年配のオッサンが騒いだところでどうにかなる話ではない。


先日、I氏は某CL（課でもっとも声の大きいと思われる方）にも『ワシの後釜は～』を言ったそうだ。すると理由も聞かずに『アイツは（抜くのは）勿体ない』と即答だったらしい。

これは現実的は判断だろうと思う。自分が引き抜かれたとしても、予防組の改革（というと大袈裟だが）を成し遂げるとは言い切れないからだ。
I氏は『アイツは何も考えてない』と随分憤っていたが、これは、イコール何も考えてない事の証明にはならないと前向きに捉えるべきだろう。


最も、何も考えてないのであるならば…10～15年はこのままという可能性もあるが。

ヒンカクショ

会社でこれに関する取り決めを見直そうという動き出ています。
書類フォーマットや発行基準、確認方法に関する事が主のようですが
こういう流れは歓迎すべき事だと思います。

せっかくの機会ですので、書類発行に大変時間が掛かっている等、いくつか問題提起しておきました。
理想を言えばIT（という言葉さえも古臭く感じるこのご時世だが）を駆使したシステムを作り上げて欲しいです。社内には優秀な方は沢山いらっしゃいますからね。

何らかのシステムがあれば、工数削減だけでなく、変化点管理も柔軟に出来て二重帳簿問題もいくつか改善しそうな気します。


もっとも、こんな話は取り合ってもらえないでしょうけど。

将来、働く人は減っていくのだから、少ない人数でより質の高い仕事をするにはこういう事も必要だと思うんですけどね。

ドヤ顔してるような感じになっちゃうのが非常に嫌なんですよ

会社にあるソーイクフー提案制度。
提案書にあれこれ工夫した内容を書いて提出すると賞金が貰えるアレだ。

あくまで自主活動という事なのにノルマが設けられてたりして、これのどこが自主活動やねんって感じなのだが、毎月書いてるとネタに困る事がしばしばある。

実は今月もそうだった。今回はちょっと前のエントリーで書いたEXCELソフト(?)の改造の事をネタにして逃れたが、藁をもつかむ思いで取った行動がまさかの間違いの始まりだった…。

ノルマクリアが目的だったネタが、もの珍しい為か上に回っていくうちに別途報告が必要な賞金にランクアップ。

まぁ普通なら喜ぶべき所なんだが、このネタ自体は一時凌ぎの物であり、自分が本来目指してる物とは違うので、このくらいでドヤ顔（＝高額賞金）してるような感じになっちゃうのが非常に嫌なのだ。

おまけに賞金に見合った効果に書き直す作業（この辺りで既にオカシイ）が発生してまぁ面倒くさいこと。（しかもあまり追加効果は無いという）

決めた、もう書かねぇｗ



…ところでこれ、よーーーーく考えると、
集計には使われない細かい内容までPCに入力してる事自体、意味が無い事に気が付いた。
（あくまで現時点では、だが）

他の人につっこまれたら返す言葉も無いわ。ヤバイ。

突破口は開くのか

月末になってくると、OUTPUT報告書のことが頭にちらちら入り込んできてなんだか鬱になる。

報告の元となるデータを打ち込む物は存在するのだが、なんせやりにくくて苦痛でしかない。
間違い、抜けが多いのでデータを一通りチェックしなきゃならないし、集計も結局コンピュータを目の前にしながら半手動というお粗末さ。

PCが導入されて15年が過ぎようとしてるのに、未だこの有様とは…。

作れと言うが

本日は夢工場様よりネタの提供。

間接的に聞いたので返事はしていないのですが、『スマホであんどんが見えるようにしろ（あいつに作らせろ）』なんて事を言われました。何故そのような話題が出てきたのかは不明です。しかし名指しという事は内製でやりたいという事でしょうか（外注でやりたいなら適任といえる人は沢山います）

確かにあんどんは把握しにくいので、似たようなことは私自身も考えたことあるし、同様に他の人も一度は考えたことがあるかもしれません。

これが実現した時の効果は数値として表しづらいものの、働きやすくする、環境を改善する（騒音をなくし精神的なプレッシャーを低減）といった意味では大変効果のある事だと思います。

では、このシステムを作り上げるにはどうしたらいいでしょうか。

まず、あんどん制御PLCとリンクしたサーバーが必要です。通信にはイーサネットを使う感じになるでしょう。難しそうですが、J社のPLCは通信方法やDLLを公開しているのでなんとかなると思います。

次にそのサーバーを中心としたネットワークを構築します。広大な範囲でも通信ができるよう無線ルーターをはじめ、中継器も相当数必要ですね。当たり前ですが、それらの機器までは有線での接続になります。

スマホはもちろん会社で支給でしょうね。 自分の組だけでよければ7台くらいは欲しい所です。個人だとOS,機種、様々な問題があるしWIFIの切り替えを忘れてあんどん見てませんでした、という話になりかねません。

アプリの仕組みはサーバープッシュ？(メールみたいな方式）知識はありませんが恐らくこういった形です。

…ざっくりと考えてみましたが、なんか随分と金、時間のかかりそうな話です。

今日、改善作業をする時間が出来た事くらいで喜んでいる現場の班長に何ができるでしょうか。

少しでもいいから全体像をイメージして物を言ってほしいものです。

あと、こうした話が出た時、上の方の考えにすっぽり抜けてるのは、完成したあとのサーバーを含めた機器の維持・管理の事です。機械である以上は我々が相手している設備と同じですからね。

…あーあ、ネタにマジレスしてかっこ悪い。

トラノマキ その7

コンテンツの追加/編集をどのように行うか。仕様を決めかねています。

初めの構想ではWindows系アプリでしたが、ユーザーの立場を考えると『誰がわざわざアプリをダウンロードしてまで（しかも自宅で）手順書メンテせなアカンねん』って話になりますよね。

開発が楽そうって理由で思いついたのですが、こういう視点では誰も受け入れてくれなさそうです。

手順書をメンテしたいと思うであろう瞬間を想像するとやはり仕事中。そうすると、(1)Webアプリをスマホで操作、(2)トラノマキアプリに機能を組み込むかの2択。

いや、文字入力や画像作成の事も考慮すると、(3)多目的Pにアプリ組み込んで一時的なファイル作成→スマホでアップロード→サーバー側で組み込み処理、という手もありでしょうか。

多目的Pが完全にネットにつながっていれば一番楽なんですけどね。いや待て、そもそも、課専用のちゃんとしたサーバー/ネットワークがあってWifiで個人用スマホをつないでやれば…ああ、言い出すときりがない。


この際、開発におけるハードルの高さは問わないものとして…あとは操作性、手軽さを優先すると(2)案か…？

うーん本当に難しい。

コスト改革？

とある書類に目を通す機会があったんだけども、銭の話しか書いてなくて本当に呆れる。

時間だってコストの一部だと思うのだ。

一つ一つは小さくても、それが積もり積もって現場は苦しんでいるのに、何故それに気付かないのだろう。

この件はいつか言わねば。

トラノマキ その4

大分完成が近づいてきました（ただしクライアント側の話）。

OutOgMemoryErrorの対策

bmpオブジェクトをリサイクルするだの色々あったのですが、トラノマキではImageViewを１つしか使っていなくて意味が無さそうだったので、画像を縮小して読み込む方向で解決できました。（参考記事：画面に合わせて画像を縮小して読み込む）

ライセンス認証もどき

PHPの勉強も兼ねていたし、SSL通信(HTTPS通信)や暗号化など初めて取り組みものばかりなのでかなり苦労しました。その苦労の甲斐あって、なかなかそれっぽい物が出来たんじゃないかと思います。
通信に関しては出来上がってみると通常のHTTP通信とさほど変わりないコードなんですが、未だ謎は多いですね。このあたりに手をだすなら通信技術の知識が必須だと痛感いたしました。


更新処理のパフォーマンス改善

いくつか前のエントリでも書きましたが、更新処理に時間がかかり過ぎていたのでアルゴリズムを大幅に見直しました。

変更前では目次ファイルを走査し、それぞれのファイルに対しサーバー側とSDカード内の更新日を取得し比較を行う、という方式でしたが、この方法だと (1)サーバー上に無いファイルも比較を行ってしまう (2)ファイル毎にHTTP通信によるオーバーヘッドが発生する　という２つの問題があります。

そこでサーバー側に『存在しているファイルとその更新日』をリストアップするPHPスクリプトを配置し、Android端末ではそのリストを取得、そしてそれを元にしてSDカード内ファイル更新日と比較を行う、といった方式に変更しました。

この変更によりパフォーマンスは以下のように改善しました（単位はミリ秒）

とまぁ、ドヤ顔でグラフを載せていますが最初に考えた方法が酷すぎるってことですね（このままリリースしなくて本当によかった・・・）。


という事で、あとは多少リファクタリングを進めてそれが終わったら次のステップに入る予定です。

答えを導く

算数の宿題が分からないと娘に聞かれる事が度々あります。今回はこんな問題でした。

半径が３cmの円が図のように３つ並んでいる時、この外周を最短で通る線（オレンジの線）の長さを求めよ


答えは至って簡単ですが、いつもこの手の問題は説明に悩みます。大事なのは答えを知る事ではなく、答えを導き出す為のプロセスを知る事だからだです。

これは仕事においても同じことが言えます。特に保全という職種では、故障した設備を素早く復旧する必要があるうえに発生する問題も多岐にわたる為、答えを導き出す（＝問題を特定する）知恵を持つ事はかなり重要な筈です。

多くの人はこの点に気づいてると思いますが、人材育成としてこの『問題を特定する能力』に着目した取り組みはあまり無かったのではないでしょうか。これは誰にでも異常が解るようにするとか、既に確立された調査方法を覚える事とは別の方向性です。

若い子らを見ていると（といっても知る限り2人か）、小難しい事はソツなくこなすものの、初めて見る現象に対して極端に弱い感じがあり、いささか心配になります。


今も昔も教育の場で教えていく内容というのは「交換手順」「操作方法」「調整方法」等が中心で、評価もそれに準じたものになっていますが(※)、早期育成を狙うのであれば、そこへ辿り着くプロセスについても重視すべきです。

もしかすると、『このような現象になったらこの部分を見る』のような答えを積み重ねていけば、こうした能力というのは経験と共に身についていくものなのかもしれません。

数少ない情報から様々な要因を想定し、切り分け、検証し、特定する。…と、言葉で言うほど簡単なものではありませんが、これは一人前に近づく為のステップであり、同時に修理屋としての醍醐味でもあると思うのです。


私は決して経験豊富ではありませんが、今後部下に対しては問題を特定していくまでのプロセスに重点を置いて物事を教えていこうと思います。（何の発表文だよコレ）


※『～についての調査が出来る』といった評価項目も存在したように記憶していますが、それこそ多岐多様なケースがあるため評価という点では順当ではないと思います。

ちなみに数か月前、技能評価で『若者の早期育成傾向が達成できている』との見解が出されましたが、こうした評価が上層へあがり社長の発言（URL参照）につながったのでしょうか。
http://sankei.jp.msn.com/economy/news/120322/biz12032218290019-n1.htm

トラノマキ その３

細かい部分の作りこみが完了しました。

1. 通信エラー時のメッセージ表示
2. 目次の唯一展開オプションの動作実装
3. 手順書ファイルのプロパティ表示
4. 他の画像ビューアから戻った時の挙動の修正

4項については、参考画像の拡大表示を他の画像ビューアに委託する処理に関してなのですが、拡大表示させた後にバックキーで戻ると同じ画像が2度表示され、正規の動作とは言え少し違和感を感じる部分でした（手抜きの副作用とも言う）。

呼び出し元のActivityはViewPagerなので、戻った時に手順書が表示されていれば違和感も解消されそうです。

そこで、ギャラリーの呼び出し方法を『startActivity』から『startActivityForResult』にしてコールバックを受け取るようにし、onActivityResultにてViewPager#scrollTo(x,y)を使って手順書のページへ強制的に戻す処理を追加しました。なかなかいい感じです。


忌むべき存在 ”OutOfMemoryError”

今まで真面目にAndroidアプリを作ったという経験は少なく（クソドラムを手掛けた事実は闇に葬る）、メモリ管理に関しては無頓着なまま作り続けてきましたが、今回は比較的大きな画像を扱う事もあって、予想されていたOutOgMemoryErrorがついに発生してしまいました。

『目次から手順書へ画面遷移』の繰り返しで出る同エラーは、System#gcでGCを呼び出す事で回避できました。しかし手順書の『リンクテキスト』で大きな画像を使った手順書へのリンクを繰り替えして落ちてしまう問題は解決できません。

鋭意調査中。

トラノマキ その２

ファイルを更新する部分がほぼ完成。おかげでテストが随分と楽になりました。あとはコネクションタイムアウト等で更新に失敗した時のメッセージを出したいところですが、この処理はバックグラウンドスレッドで行っているので少し頭を悩ませています…。

ずっと同じ部位にかじりついてると飽きてくるので、手順書の表示部（ListView)を改良してみました。

元々『サブタイトル』『手順』の２つの表現要素しか無かったところに新たな３つの要素を追加しています。

注意を促す『注釈』、補足説明のような内容を表す『ワイドテキスト』（←少し命名に疑問）、他の手順書へリンクする『リンクテキスト』の３つです。特にリンク機能はスマホならではのメリットで、なかなか良いんじゃないかと思います。

改良したとは言え文字ベースの手順＋参考画像1枚だけという制約に変わりは無く、表現力はまだまだ乏しいです。

技術力＋やる気があれば、紙媒体同様、表現力豊な物を作る事も可能でしょうが、そこまでするならブログにでも手順書をあげたほうが絶対早いと思います。

しかし、そうすると結果的に閲覧時の軽快さやメンテの手軽さが失われてしまいますし、セキュリティー上の問題もあります（例によってどうでも良さそうですが、やはりうるさい人は居るもので…）

実はトラノマキの仕様を検討する際、iPhoneユーザーもカバーしたくて、ブログやEvernote、GoogleDocs 等Webを利用する案も検討していたのですが、先述の理由により断念したという経緯あってのAndroidアプリなのです。

しかし使ってるデータはただのXMLなので、iPhoneアプリを作れる人さえ居れば解決しそうな問題ですが・・・多分企業レベルで動かないと完成しても配布すらできない予感がしますね（未調査）

まぁいずれは何らかの手段で解決したいところではあります。

トラノマキforAndroid

会社で役立つツールをAndroid端末で作る、という計画はゆっくりと進んでいます。今年の初めに少し、しばらく休止後、4月に入ってまた再開。本当にゆっくりですが、自身のモチベ維持の為に書いてみます。

名前は 『トラノマキ for Android』

基本的には作業手順書なんですが、それを見れば誰でも出来るという物にはせず、あくまで”記憶を助けるツール”という事をコンセプトとしています。また、現存する紙媒体の虎の巻では困難だった情報の共有化というのも一つの狙いです。

アプリケーション自体は単純で、起動すると機種等でカテゴライズされた手順書等のタイトルがあり、それをタッチすると内容が表示されるというものです。手順書画面はViewPagerで構成され、手順を書いたリストと参考画像の画面をスワイプで切り替える、という物になります。

手順書データは端末に無い場合に自動的に取得する仕組みで、一度取得すれば内部のデータを参照します。また、データを編集/追加していく事も必要なのですが、Android端末でその作業は厳しいので別途PCソフトを用意する必要があるかなと考えています。

現在はアプリの枠組みと呼べるものがおおよそ完成した状態です。まだ最新のファイルに更新する仕組みが未実装。データを編集するソフトについては未着手(これが一番大変そう)。コンテンツを充実させる作業もあるし、まだまだ先は長い。

完成したら若者を中心に広げてもらい、末永く業務に役立ててくれたら嬉しいと思います。