最近の天気予報はすごい
今日の徳島は、雨です・・・
とっても寒くなってきました。
昨日も天気が悪く、地元の小学校で予定されていた運動会は延期になったようです。
プロ野球ではクライマックスシリーズファーストステージ、甲子園での試合が通常では中止になるような天気の中、日程の関係で強行されましたね。
この判断には賛否両論あるようです。
プロ野球の中止判断は、今は連盟がすることになっているようです。
去年までかな？主催球団の判断だったと思うんですけどね。
で、その判断材料には今現在の天候は当たり前なんですが、その後の雨雲の動きなんかも判断基準になるようです。
この後どんどん雨が強くなるようであれば早めにやめちゃう、とか、ちょっと辛抱すれば弱まりそうなら様子見で待っておく、とか
そんな予想も、今ではボクら一般の人でも手に取るようにわかります。
〇時ごろになると雨はやむだろう、なんて判断できますよね。
毎朝、ムスコに傘を持たせるか判断するために、学校に着くであろう時間帯までの雨雲の様子を必ずチェックする習慣になっています。
恐らく気象予報ができるようになったときから、雨雲の様子は分かっていたんでしょうが、インフラがなかったからでしょうね、一般人がその様子を手元で逐一確認することはできませんでした(たぶん)
ITをうまく使うと便利な世の中になりますね。
リスクを除く
夏のような暑さが続いていた徳島ですが、天気が悪くなり、グッと気温が下がってきました。
ボクは夏以外の季節は寝るときにマスクをしています。
特に寝ている間はのどが乾燥して風邪をひきやすいので・・・夏も年中マスクをしておきたいところですが、暑いときは知らず知らずのうちに取ってしまっていて、意味がないので外しています(^^;)
そうやって、風邪をひく、のどに違和感を与えない、ように少しの努力をしています。
さて、組織の業務において、何かあった時のリスクを考え、準備しておくことは大切です。
リスクマネジメントなんていう考え方もあったりします。
分かりやすい例でいうと、「バックアップ」
何度もあわてて問合せをいただいたことがあります。
「パソコン壊れた！」
「データがなくなった！」
できる範囲のお手伝いはしますが、そのあと必ずバックアップ体制を取るようにお伝えしているのですが、ほとんどが対策を取られません。
まさしく「喉元過ぎれば熱さを忘れる」
です。
人も同じです。
人依存は組織としては危険です。
組織対組織でも結局は人対人
でも、情報は組織として管理することによって、人依存を脱却できます。
個人としてではなく、組織としての情報管理を徹底しましょう。
データに残すこと
今年は、なぜか公的支援機関からのIT相談や、情報セキュリティ関係のセミナー依頼が結構あります。
スケジュールの関係でお断りしていることも多いのですが・・・
人前でしゃべるのは元来得意ではないので、セミナーはとても緊張しています。
IT相談は楽しいです♪
最近あった相談は、データに残すにはどうしたらいいですか？ということでした。
先日、所属する経営者団体の報告会に参加した時、「経営者の頭の中にある理念を成文化する」というお話がありましたが、では、技術や情報は？
ここが結構ポイントで、技術や情報が頭の中にあって、その人がある日突然いなくなれば、事業継続自体が成り立たなくなることに多くの人が気づいていないのです。
それは経営者に限ったことではありません。
営業さんが突然退職したら？
組織対組織でも、個人対個人の関係性により取引をしている場合は少なくありません。
個人にほれ込んで取引してくださるお客様に、担当者がいなくなれば離れてしまうリスクは高まりますが、お客様の情報も担当者の頭の中だけだった場合・・・
別のパターンで、個人の技術で仕事をしている場合、職人さんのような場合、完全に事業は止まってしまいますね。
IT化ということは、業務改善・改革にとどまるだけでなく、事業の継続化にもとっても大切なことです。
個別開発のオリジナルソフトを使うこと
先日ある人と、シャハルのサポートモデルについてのお話をしていました。
その中で、個別開発と市販されている安いパッケージソフトの違いは何ですか？
と聞かれました。
要は、安くてデメリットがないならパッケージソフトの方がいいよね、ということです。
パッケージソフトの場合、安いです。
ただ、デメリットとしては、業務をソフトに合わせなければいけません。
そこで何が起こるかというと、結局は「ムダ」が生じます。
ITを使って業務効率化を図るのに、その効果が半減以下になってしまいますね。
パッケージソフトにはいろんな業種業態に合わせるために多くの項目を設けています。
結果、複雑なソフトになり煩わしさが増します。
そして、必要な機能が不足していることが多いでしょう。
同業種でも全く同じ業務フローを持った組織は皆無と言えます。
必要な機能をパッケージソフトに追加することにより、結局個別開発した時と同額、あるいはボクの経験から言えば、ほとんどの場合が割高になります。
そのうえで、不要な機能も付いているから複雑です。
ただし、今から起業して業務を始める！という場合には、金銭的にも、業務をソフトに合わせる必要もないため、メリットは大きいと思います。
個別開発のオリジナルソフトでは、業務にソフトが合わせ、しかも必要な機能をもれなく付けることができます。
その反面、開発費はその組織のみに乗ってくるので、割高になります。
どういったパターンがいいのか、じっくり考える必要があります。
ITリテラシーを考える
情報リテラシー（じょうほうリテラシー、information literacy）とは、情報 (information)と識字 (literacy) を合わせた言葉で、情報を自己の目的に適合するように使用できる能力のことである。「情報活用能力」や「情報活用力」、「情報を使いこなす力」とも表現する。したがって情報リテラシーとは、情報を主体的に選択、収集、活用、編集、発信する能力と同時に、情報機器を使って論理的に考える能力が含まれている。
(ウィキペディアより)
情報を使いこなす能力
業務システムの開発現場でよくみられる光景として、「システムを作ったけど使えない」といったことが起こります。
なぜでしょう。
それは、一番にユーザーのITリテラシーを考慮していないからだと思います。
例えば、ローマ字読みができないこどもにローマ字入力で打て、と言ってもできないですよね。
MicrosoftOfficeを使えない人に、MicrosoftOfficeを使ってチラシを作れ、と言ってもできないですよね。
できることからゆっくりと進めていかないといけません。
お客様には、早くやりたいこと全部できるようになって、安心したい・・・とおっしゃる方もおられます。
が、ひとつひとつの機能を確認しながら、すこしずつ進めていく方が、必ずいい結果が得られると思っています。
「As Is」と「To Be」
ギャップ分析と言われる、経営改革手法のひとつですが、「今ある姿」と「あるべき姿」を比較し、その差「ギャップ」をどう埋めていくか、ということです。
それを一足飛びにしようとすると、失敗します。
現状をしっかり見て、地に足のついた業務改革を進めていくべきですね。
お客様と会話をしていて、丁寧にわかりやすく話しているつもりでも、まだまだその「ギャップ」に驚き、反省することがしばしばです(^^;)
罠に陥る
システム開発をしていると、よく罠に陥ることがあります。
なぜこういったことが起こるのか、プログラムを見ても全く分からない。
デバッグ(プログラムの処理を任意の場所で止め、設定した値などを見る)しても、分からない。
今日は罠に陥った日でした。
具体的には「改行」
不要なところでは改行はカットしているはずなのですが、ある事象の時だけそれがうまく作動せず、帳票に正しく印字されていませんでした。
しかも、データベースの値を直接見るツールにより、開業が正しく認識されるものとされないものがあるのです。
貴重な時間が・・・
これも経験ですね。
最小の構成と過剰投資
この業界、よく耳にするのが、過剰投資
ボクもそういった相談をよく受けます。
ユーザーがITに詳しくないことをいいことに、必要以上のハードウェアやソフトウェア、設備を備えさせます。
基本的にボクはそういったことはしません。
そもそもボクにメリットないし、騙す(言い過ぎ？)理由もないので
お客様にモノを買って納めることもありますが、卸でないのでマージンももらいません。
買った額でそのまま売ります。(人件費が必要な場合はそれは別明細でいただきます)
ただ、ボクの提案を「過剰投資だ！なんでそんなもんが必要なんだ！」と言われたことはあります。
「IT化における過剰投資」という言葉だけは知っていて、また知り合いにちょっとパソコンに詳しい人がおられるのだと思います。
できるだけわかりやすくかみ砕いてお話しますが、なかなかITリテラシーがそれなりのレベルにない人に、必要なもの・ことをすべて理解していただくことは至難の業です。
特に機器の選定なんて、「なぜこれを選んだか・・・」
その時点では、ボクとの信頼関係が薄いからそういったことが起こるのでしょう。
特にお付き合いを始めたばかりのユーザーさんでは仕方ないのかもしれません。
ただ、いつも「最低限必要」のレベルを提案しているので、それを「拒否」されてしまえば、お手上げですね・・・(^^;)
開発スピード
年々ボクの開発スピードは上がっています。
中身もどんどんブラッシュアップして、使いやすくなっていっていると思います。
それは、作れば作るほど新しい知識が増えるから。
色々経験し、学び、知識を蓄積することで、スピードでも、機能でも、品質でもより喜ばれる仕組みができていっています。
休暇
今日は火曜日
実は日曜日から東京に行っておりまして、昨日の夜に徳島に帰ってきました。
何をしにかというと・・・半分仕事、半分遊び
メインはU22プログラミングコンテストの表彰式に出席するためです。
U22プログラミングコンテストとは、22歳以下のプログラマーが自分の作品を競うコンテストです。
我が小２のムスコ、小学生で唯一最初の審査を突破！
40作品に選ばれました！！
1,200作品の応募があったそうなので、倍率30倍、表彰式の時に聞いてビックリです。
ただ、次の審査では漏れ、最終審査には残れなかったのです・・・
まぁ、だいぶ年上のお兄さんお姉さんのプレゼンを聞いて、これは仕方ないな・・・という作品ばかりでした。
最終プレゼンを聴いてモチベーションアップになりました(^^)
さて、U22部門では最終審査に残れなかったのですが、小学生部門で受賞が決まっておりまして、表彰していただきました！
本人満足気
表彰式は、懇親会も兼ねて夜行われたので、この日は徳島に帰れず、宿泊することに・・・
ということで翌日は学校を休みネズミの里に行ってきました。
まぁ、こちらはとっても疲れましたが、帰りの飛行機で「もうちょっと東京にいたかったな・・・」と言っていたので、楽しかったのでしょう♪
平日の月曜日、おそらく開業以来初の「仕事用電話完全オフ」にしていました。
ギリギリまでパソコンを持って行こうかとも迷いましたが、完全シャットアウト！
さて、やっと仕事できます(^^)
業務システムで必要なこと
システム開発プロジェクトが失敗すること、よく見ます。
先日、大きな業務システム開発プロジェクト裁判の控訴審判決が出ました。
結果は、100%ユーザー側の過失を認めるものでした。
内容はともかくとして、この判決が意味すること・・・
それは、開発プロジェクト完結にはユーザー側にも大きな責任があるということです。
いつも言っていますが、ユーザー側の大きな協力がないと、開発は続けられません。
仲間として一緒になって作り上げていくものです。
今回の裁判のプロジェクトの場合、大きなお金が動くので、企業としては致し方ない部分がありますが、そこに至る部分で、一緒になって作り上げる仲間意識があれば、もっと違う形になっていたのかもしれませんね。
« 過去の投稿へ 以前の投稿へ »
