代表 稲垣の自己紹介③

自己紹介3
目次

情報システムで活躍・Djangoに出会い本格的にプログラミングを習う

代表稲垣の自己紹介、第3回目です。前回は、内定先の民事再生による取消からプログラミングを覚えて業務改善を数々おこなったことまで書いてきました。今回は、その続きを書いていこうと思います。

情報システムに兼務になり最初の打ち合わせで「???」が飛ぶ

会社に入ったころには、システムを担当する部署や課はありませんでした。時代的にもないほうが普通でしたね。

入社してしばらくすると、システムを担当する部署ができ、そこに兼務することになりました。

まだまだ、システム化やIT化が出来ていなかったので、本当に色々経験することができました。電子稟議やSaaSシステム導入、自社開発のサービスからパッケージソフトへの移行など、本当に色んなことに携わることができ、色んなスキルを身につけることができました。

兼務の辞令がでて、情報システムでの仕事の一つ目は、ネットワークの更新でした。WANとLANの同時更新。当時では珍しく、完全無線LAN化する決断をしたことを今でもはっきり覚えています。

そんな判断をすることになるネットワークの更新でしたが、最初の打ち合わせでは、「グローバルIP」「254から出る」「デフォゲは・・・」など、知らない単語が飛び交っていて、知らないことをメモすることしかできませんでした。

あれは、心が折れそうになったなぁ。

1時間「???」の打ち合わせを終えて、知らない単語をググって、その解説を読む。解説にわからない単語があるから、また、それをググる。のエンドレスをやっていました。

ネットワークの更新が完了したら遅すぎてクレームの嵐

ネットワークの更新を完了し、しばらくするととにかく、

「インターネットが遅すぎる」

「メールが届かない!」

「システムがエラーで落ちる」

など、本当に毎日、課員の方から役員に至るまでクレームを言われる日々でした。

この時、ネットワークの更新を担当した会社も調査してくれたんですがお手上げ状態でした。なんにも進まない日々。でも、現場の人からは、ネットワークが遅すぎて、仕事が回らない状況がしばらく続くことになりました。わたしもじっとしていたわけでなく、自分なりに色んなことを調査しました。

Wi-Fiのチャネルや2.4GHzと5GHzの違いや特性。周りに飛んでいるWi-Fiの調べ方。HUBやLANケーブルの仕様、トレースの調べ方、時間帯によるネットスピードの状況、本当に色んなことを調べました。

毎日23時前まで残ってやっていたなぁ。上司には、「もういいよ」って言われていましたが、情シスでの最初の仕事をちゃんとしたいと意地になっていたかもです。

夜遅くまで残って調査した資料をみながら、ベンダーさんと話をしたところ

「セッションが足りなくて、待ちになっているのではないか?」

という、仮説にたどり着きました。

セッションとは、パソコンとWebサイトを結ぶための糸電話のようなイメージです。

セッションの上限を当時1万2千に設定していました。この数は、ネットワーク更新前の機器設定と同じでしたが、実は、ネットワークを更新した直後に、Office365を導入したのですがこれにより、社内でインターネットへ接続する人が増えたこと、特に、Outlookのスケジュールは、めっちゃセッション数が増えることを知らず本番導入したので、セッションが想像以上に急激に増えたことが原因でした。

仮説どおり、セッション数の上限を増やすと、一気に問題が解決!
良かった(^▽^)と安堵したことを覚えています。

残念なのは、スピードが戻っても感謝の声をいただくことは、ありませんでした。
使う側からしたら当たり前だから仕方ないですよね(笑)

Office365や資産管理システムの導入

今では、Office365(Microsoft365)というと、みんな知っているサービスになっていますが、わたしが導入に携わった時には、まだまだ知られていないサービスでした。当時は、サイボウズ社のOfficeやガルーンの方が有名でした。

Office365を選んだ理由は、ファイルサーバーとしての役割ができるSharePointやOneDriveがあったからです。クラウドにファイルを保存するなんて、2015年ぐらいの時には、企業では考えれなかったことです。実際、あるベンダーさんからは、ファイルサーバーやめるなんて、絶対運用できないですよ!って、言われるほどでした。

実際に、テスト的にチームで使用し、『ファイルサーバーとしてクラウドが使える!』と、判断したのは、今となっては時代の最先端いってたなぁと思います。(自画自賛 笑)

Office365の導入により、掲示板機能、会議招集での電話連絡の禁止(社長でも)、社外メールと社内メールの統合、ファイルのクラウド保存など、劇的に業務の方法を変えました。が、ファイルのクラウド保存や会議招集(電話で●●の打ち合わせ、●●日の●●時間からいいですか?)の確認電話をなくすまでには、2~3年かかり定着の難しさを感じることでもありました。

定着させていった方法、スケジュールの確認電話は、上層部に「Outlookでスケジュール見てもらって、空いてたら、招集してくれていいよ。電話しなくていいからね!」と、言ってもらうことで徐々になくなり、ファイルのクラウド保存は、パソコンをシャットダウンするときにファイルを削除するよう処理(パソコン紛失時の情報漏えい防止目的)を入れてにして、強制的にするようにしました。

部署単位で使うシステムではなく、会社全体で使うようなシステムで、今までの運用方法が強制的にできないようにできない場合、システムを浸透させ定着させることの難しさを情シスにいってから、すごく感じるようになったことが、本当にためになりました。

システム開発の提案依頼⇒発注⇒テスト⇒稼働までを中心でおこなう

入社当時の会計システムも、7~8年たち今後どうするかの検討に入ることになりました。

いろいろ状況が変わったのが理由です。入社当時は、会計担当者1人が20~30物件の処理をしていまた。

その後、業務改善に目覚めたわたし。VBAやExcelの活用、システムの機能追加で手書き帳票の印刷化や、自動仕訳作成化などで、たくさんの業務改善をおこなったことで、なんと、会計担当者1人が40~50物件の処理、約2倍担当できるようになりました。

経費で言えば、2分の1にですよ!すごいですよね!

今、思ってもめちゃくちゃ業務の効率化できましたので、本当によくやったと思います!

1人当たりの処理できる物件数は、増えましたが、ずーーーーと問題だった、処理ミスによる事故。これを減らしていきたいと思うようになりました。

なぜなら、私自身、入社1年目で処理ミスをしたことにより、お客様に直接謝りに行く経験を何度かしました。こんな思いを後輩にはさせたくないという気持ちで、処理ミスを防止する業務改革と、それに合わせたシステムの構築をすることになりました。

RFP(提案依頼書)の作成

システム開発の見積もりを取得するときには、RFPという提案依頼書を作成します。代表的な内容は、

  • システム開発の目的
  • システム使用する人数やOS情報
  • 今抱えている問題
  • 実現したこと
  • ネットワークの情報
  • 開発期間と条件等
  • 現行システム機能一覧

です。

入社当時に一緒に部屋にこもり、システム稼働を目指した尊敬するエンジニアさんと一緒に作成しました。エンジニアさんとしては、他の会社へも提出する提案依頼書を作成するなんて、ちょっと複雑な気持ちだったと思います。でも、快くやってくれたことを感謝しています。

約1か月弱で完成し、複数の開発会社とパッケージ会社に提出し、提案をしてもらいました。

発注先の選定

発注先の選定としては、

  • 金額
  • プロジェクトマネージャーの印象
  • 開発期間

判断材料としては、これでしたが、他のシステムとの統合も視野に入れたり、金額的なこともあり選定することになりました。

もし、今から何かシステム関係の発注をするなら大切にしてほしいと思うのが、『プロジェクトマネージャーの印象』です。

実際、私は少し大丈夫かな?って思っていたら、そのプロジェクトマネージャーが色々あって、稼働中止も一度なりました。そのあと、プロジェクトマネージャーが変わり、いい方向に行き結果、成功しましたが、プロジェクトマネージャーの大切さを感じた開発でした。

金額ってどうしても会社にとって判断材料として大きなウエイトを占めてしまいますが、安くても高くても、実際にやってくれる人、仕切ってくれる人、その人と今後お付き合いできるか?という観点を優先度1位にしてみてほしいと思います。

データ移行とVBA

システムは数億円以上の規模だったので、2年以上かけて開発をしました。システムプロジェクトって、絶対に後半押していきます。移行データは、一般的にベンダーさんが作ることが多いですが、開発スケジュールや工数から、自分たちで作成するという判断をしました。

この時に役立ったのが、VBAです!

ACCESSは、データベースへ接続しデータを取得することができますので、旧システムからACCESSでデータを取得し、新システム用にVBAでデータを加工する。これでエンジニアさんは、開発に専念することができ、スケジュールをも守れる!という方法です。

移行データのプログラム作成は、契約上、開発会社のお仕事ですが、そんなことを言っていたらスケジュールも守れない、システムも完成しない、最悪、裁判してお互いの責任の擦り付け合いになり、疲弊する。そして、結果システムも完成せずに遺恨と、投資した時間が無駄になってしまったという道になりかねません。(実際にそうなった会社を知っています)

移行データを自分たちで作る!と、決めたんですが、問題だったのは、社内でVBAを使えたのが私だけだったのですが、わたしはその頃は、スケジュールや課題管理などプロジェクトの管理作業が中心で、プログラムをゴリゴリ書いている時間がありませんでした。

そこで、移行プログラムを作ってもらう5人選抜し、VBAを教えていきました。変数や、繰り返し処理、SQLなど。

VBAを教えてそれを使いこなしていく姿を見て、とっても感激し、自分は教えるの好きだなぁ。って、思ったのを今でも覚えています。

みんなの成長のおかげで、スケジュールの遅れが出た人のフォローのためにVBAを書いたりしていました。コードを書くのは本当に楽しいですよね。

テストはどかからユーザーが参加すべきか

システム開発の世界では、ユーザー側のテストは、受入テストや並行稼働テストと呼ばれ、本当に試練の場です。開発会社は単体テスト、結合テスト、総合テストという一連のテストを行い、ユーザーに納品します。

このプロジェクトでは、スケジュールの都合で、単体テストもやっていない状態のプログラムも含め、開発会社の窓ものないミニ会議室に3か月間閉じ込められ、テストをすることになりました。朝、7時前にはいって、夜も遅くまで働いていました。今では、絶対してはいけない働き方ですね。

ユーザーがテストを請け負うことで、エンジニアは、プログラム開発に専念できる。

これ、本当に良かったです。なぜなら、単体テスト⇒結合テスト⇒総合テストしてから、テストして問題がありました!ってなると、プログラムを修正して、また単体テスト⇒結合テスト⇒総合テストってやっていると、エンジニアさんにとっては、工数が重なるばかりです。

テストって結構、ストレスがありますしね。エンジニアさんにとっては、プログラムを修正したらすぐにユーザーがテストしてくれるので、とっても効率的に仕事をすすめれます。

大きな問題は、ユーザー側としてテストをするメンバーは、

『ちゃんと仕様を伝えたのになんでこんな作りになっているの!?』

『ぜんぜん、ちゃんと動かない!』

という、ストレスです。本当にすごかった。

どうしてやってみんなのモチベーションを下げずにいくか、モチベーションコントロールのマネジメントが非常に重要になりました。

わたしがおこなったのは、毎朝ミーティングで、鼓舞するために、アントニオ猪木が引退試合で詠った一休宗純の『道』という詩をモノマネをしながら、メンバーに聞いてもらったり、色んな施策をおこないました。

人は歩みを止めた時に、そして挑戦を諦めた時に年老いていくのだと思います。

この道を行けばどうなるものか。

危ぶむなかれ、危ぶめば道はなし。

踏み出せばその一足がみちとなり、その一足が道となる。

迷わず行けよ、行けばわかるさ。

アントニオ猪木引退試合

このプロジェクトで、もし通常のシステム開発のように、総合テスト後にユーザー側としてテストします!にこだわっていたら、開発側のストレスはすごい状態になっていたことは容易に想像ができます。舌打ちの嵐だったでしょう。

開発会社は、総合テスト終了後は、自分たちは完成した!っていうことになるので、SEやPGやテストをする人も一気に減らしにかかります。費用を削減するためです。人を減らしてしまっているので、バグが見つかっても対応スピードも遅くなります。

総合テストまで開発会社に任せていると、期間も長くなってしまい費用面でも問題になってきます。開発会社としても、ストレスもたまってくるし、費用のことなもプレッシャーになり、ユーザーとも言った言わないなどの問題などに発展しやすくなります。

本当に協力体制で挑まないと、揉める原因になるんですよね。お互いが協力姿勢で挑み、実際に行動でも示すことで、プロジェクトはいい方向に進みやすくなることを経験しました。

このプロジェクトの後、開発したシステムについては、単体テスト作成から積極的に関わるようにしました。単体テストの作成段階で、開発側との認識齟齬をみつけることができることは本当にお互い最小工数で、本来の機能に戻すことができ、いい効果がいっぱいでした。
請負なんだから、開発側の責任だし、なんていう思う気持ちもあると思いますが、ユーザーは積極的にテストに参加することをオススメします。

並行稼働テスト

並行稼働は、新旧システムに同じデータを入力し、同じ結果になるかをするテストです。重要な基幹システムほど、並行稼働でのテストは必須になってきます。

新旧のシステムに同じデータを入力するって、単純に作業が倍になります。これ、担当者にとって苦痛でしかありません。本当にすごいストレスなんです。作業量が倍になると、なぜかストレスは倍以上なんですよね。

そんな問題をクリアするために、RPAを導入することにしました!
RPAとは、パソコンを操作するプログラムが作成できるソフトです。このおかげで、数千時間の時間削減が達成できたとっても素晴らしいソフトです。

Windows10以降のユーザーなら、PowerAutoMateDesktopというRPAソフトが無料で使えるので、ぜひチャレンジしてみてくださいね。

RPAのおかげで、並行稼働テストも無事終え、本番リリースが完了しました。新システムでは、処理ミスが激減し目的を達成することができました!ほかにも、いろいろ効率化するための機能も追加したことで、1人当たりの物件担当数はあまり変わりがなかったですが、残業時間を大幅に削減することができました。

Djangoに出会い本格的にプログラミングを習う

システム開発を終え、また新たなシステムの開発や導入を日々、検討実施していました。

そんな日々でもVBAを使って日々、業務改善を行っていましたが、VBAは独学で覚え、エンジニアさんたちにちょこちょこ教えてもらっていましたが、本格的に習ったことはありませんでした。

ちょうどこのころ、会社を経営している友人から、Excelやホームページの相談をされるようになり、Webシステムの作成に興味を持ち始めたころ、後輩がDjangoというものを紹介してくれました。

Djangoは、Pythonという言語のWebシステムを開発するためのフレームワークで、もともとアメリカの新聞社が素早くWebシステムを構築するために作ったものです。

Djangoを独学で学びながら、なんとか、掲示板、シフト管理、顧客の情報共有するためのプログラムを作り、なんとかサーバーにデプロイし動かすことはできました。が、わからないことも多くその愚痴をSNSでつぶやいていました。そのつぶやきを見てくれた話し方の学校の仲間が、ご主人さんが、エンジニアということで紹介してもらいました。

このご主人さんが、ちょうどプログラミング教室を始めるということで、これは、絶対に何かの縁だ!っていうことで、入学することにしました。教室は、半年間で基本からオブジェクト指向、Dockerでデーターベース作成、Webシステムの構築まで一貫して学ぶことができっました。このおかげて、VBAの書きか方もどんどん変わっていきました。

これがきっかけで、プログラミングの技術が向上し、2023年から、大手システム開発会社の新人研修講師として、Javaという言語を教えるという立場になりました。

友人が経営する会社の課題をVBAを使って業務改善し感謝される

友人がExcelでの作業がとにかく嫌いだ!パソコンが嫌いだ!得意な人がいない!っていうので、作業を楽にするためのプログラムを書いてあげました。内容としては、税理士さんからもらったExcelシートに、レシートを見ながらデータ入力すふのですが、レシートは、だいたい20ぐらいのお店で購入するけれど、お店の名前と適用を毎回、入力するのが面倒ということでした。

Excelですでに入力してあるもので、流用したい行をどこかダブルクリックしたら、今から入力する行に自動でコピーされるようにし、さらに、入力順にカーソルが移動するように制御しました。

これで、月間2時間以上効率化になり、めっちゃ感謝されました。今でも使ってくれています。

このころから、事務部門と情報システム部門で色んな業務改善をおこなってきた自分の経験と、ACCESSやExcelのVBA、RPA、業務フロー分析からの業務分析や開発するスキルで、他の会社のお手伝いをすることがしたいなぁ。と、思うようになっていきました。

会社を辞めて業務改善のお手伝いをする決断

さらに、知り合いから会社でパソコンを購入するが、スペックの選定基準が分からない。とか、スケジュールの共有したいけど何使ったいいの?とか、いろいろ相談を受けるようになっていきました。

中小企業では、もともと情報システム担当者がいない。そんな人を割り当てできない。今は人を用意できないから、相談できる相手が欲しい。という話も聞いたりしていたので、自分のスキルでお役に立てるのではという気持ちが強くなっていっていました。

このころ、マーケティングで有名な森岡毅さんが、

『関西の未来はやばい』

という話をしているインタビューを見ました。日本の中小企業は、IT化が遅れ、海外の会社との競争力が弱く、東京より経済規模の小さな大阪から衰退してくという話でした。それも10年先には危ないっていう感じの話だったと思います。

自分が15年以上システムやITにたずさった経験で、『関西の未来はやばい』を救いたい!と思い、お世話になっていた会社を辞める決断をしました。

まとめ

自己紹介3回目で、いちよこれで終わりにしようと思います。

ひとつひとつを深堀すると、色んな伝えたいことがあります。システム導入の難しさ、定着の難しさ、教育の大切さ、個々のスキルアップが大切なこと、小さなステップアップが重要なこと、チーム運営、仕事の管理術、Redmineの活用方法などなど。

今後、記事にしてこうと思いますので、LINE公式アカウントか、Xでブログ記事を更新したらお知らせしますので、ぜひ、フォローをお願いします。

友だち追加
よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

目次