天気予報はニュースやネットサイトでの確認してますが、その予報を出した情報源は民間企業だったり、日本気象協会だったり異なるようですね。
そんな予報ですが、昔は民間企業が予報する事はダメだったんですね～
※予報を報道することは良かったですが。
有料制限ページなので詳細は控えたいですが、
気象と波浪、火山と地震、津波、高潮の順番に平成7年から徐々に予報が解禁されていき、今年や来年には洪水と土砂災害の予報も認められるかもしれないようですね。
そして、大事なのは制限されていた理由と解禁理由ですね。
制限理由：事実と異なる精度の低い情報が出回るとイタズラに社会が混乱するため。
解禁理由：テクノロジー進化で精度向上と国や公共機関だけでは手がまわない部分があるため。
気になるのは精度が低すぎる予報を出していると、行政指導とか入るんですかね・・・命に係わる災害情報だと厳しいほうに予報するのが人情で、そうなるとあるサービスで危険予報がでたから避難行動や買い占めが発生してしまう可能性がありますよね。そこも国の検討会での議論ポイントになるんでしょうね～
自分が学生時代に今の世の中は、もっと自動化が進んでいるのかなと思ってましたが、これから芽がでそうなレベルでもうちょっと時間がかかりそうですね。
ただ、いよいよ業務遂行にこの手の技術が不可欠になったという記事があり、気になったので読んでみました。
概要
・ベンテンの暗黙知が必要なケースがあるが、定年退職してしまう。またその人数も次第に多くなってきている。※社内が高齢化しているため。
・退職とあわせて、そもそもの人手も減ってきた。
・業務遂行の省力化が避けられなくなり、機械学習（AI）をいれて対応するしかない選択肢がない。
・そのうえ電力業界の場合、太陽光や風力などコントロールできず、また変動要素が大きい発電の比重が増えてくる。そのため、刻々と変わる状況に応じて、機械学習と自動化の組み合わせによる早急な対応が安定した電力供にはが必要となる。
これは、従来の電力業界のスキルはまた別のものとなり、負担が大きい。
人手不足とますます業務が複雑になるのでは、より大変ですね・・・人のスキルはすぐに変化しないと考えると、テクノロジーでなんとかするしかないですが。
日々勉強しないと、他社に負ける前に、自社が提供している業務遂行すらできなくなる時代がくるのかもしれないですね。
営業vs技術という対立はどの会社でも発生してしまう事が時々あるかと思います。
営業目線ではせっかくお客さんも乗り気で、（たいてい少ないながらも）予算確保してもらったので受注したい。一方、技術目線では、短い納期で（見えて）、特別利益が高くもなく美味しくない案件はうけたくない。お互いの立場からすると、状況次第では協力が難しい事もあります。
そのため、成果を出す営業になるには、社外は前提として社内営業もしっかり行う必要がとの事です。この記事では、そんな社内営業についてエピソードを紹介しています。
概要
・自分の所属する事業部の稼働状況を把握すること
案件PMは誰で、サブは誰で、キーマンは誰なのか把握すること。
またその働きぶりや評価を掴む。
・案件のPMには言いにくい事や状況を、他のメンバは掴んでいる事がある。
※雑談とかで
その方とも交流をもって、リーダだけでなくメンバレベルからも状況を聞き、判断を間違えないようにすべき。
スケジュール策定に悩む事あるかと思います。既存案件や過去に経験した事がある案件なら、だいたいのスケジュール感は真似する事で見えてきます。しかしながら、完全な新規案件には通用しません。
とはいえ、全体スケジュールを描かなければ何も進まないため、どうすればいいのか、悩むことがあるかと思います。
その答えの一つが、記事として掲載されていましたので紹介しておきます。
概要
・矢羽ブロックで開始と終了のプロセスの箱を準備
・ざっくり方針レベルで矢羽ブロックの中に文字を入れる。
（例、企画→製造→販売とかのレベルでも）
・各矢羽ブロックの下に何をするのか箇条書きで記載
（企画なら、目標顧客選定、要件定義、体制構築、とかでしょうか。）
・各矢羽の長さをざっくり必要そうな期間に応じて調整する。
・各矢羽で終了時期が明確になっているなら右上に記載
こんな感じで、まずは方針レベルを策定する事からはじめようという記事ですね。完全ゼロベースの案件も少ないと思いますが、参考案件が何もないときは上の考えを使って考えてみるのがよさそうですね。
実態は終了時期だけ決まっている炎上案件が多そうですが・・・
社内システムが正常動作をしていても、そもそも電気通信事業者側のネットワークに障害があればどうしもないですよね。電気通信事業者側は非常に高い信頼性設計をしていると想定されますが、それでも障害や事故は起きています。
そこに文句をいうのではなく（仕事ではクレームいれますが・・・）、そこから得られる教訓を社内システムに生かせないか、調べているうちに障害や事故から振り返りの記事があったので残しておきたいと思います。
https://www.soumu.go.jp/main_content/000500043.pdf
総務省のこの勉強会で同一内容があるので、日経とあわせてメモしておきます。
概要
・事前防止、事故時、事後の３つからの教訓
（1）事故の事前防止の在り方
ー適切な設備量とバックアップ
→トラフィックに応じて設備設計とそもそもトラフィックを監視できるように
→適切な頻度でバックアップをとり、復旧手順をかためておくこと
ー冗長構成の機能確保と試験
→付帯設備の冗長を忘れずに（電源、空調など）
ー監視項目・監視方法の適切な整備
→サイレント故障に注意
ー組織外の関係者との連携
→バグ情報などの共有
（2）事故発生時の対応の在り方
ー速やかな故障検知と事故装置の特定
→切り分け手順の明確化と訓練を行う事
ー利用者への適切な情報提供
（3）事故収束後のフォローアップの在り方
ー事故報告の第三者検証
ー事故報告の活用・共有
電気通信に限らず、システム関連に広く使えそうな考えですね。
詳細は、以下の検証会議を見ていくと更に深く追えます。勉強ですねー
携帯・スマホはベストエフォート側であり、宣伝されるほどの速度がでない事は周知の事実でありますが、それが総務省の検討会にあがっていた事もあったようです。
報告の肝は利用者に誤解を生じさせないよう、また一部事業者が計測時に有利にならないように計測拠点はランダムに選択されるなど工夫がされています。
ポイント
■対応周波数、通信規格、OSが同一の機種ごとに計測する。
実証の結果、OSが同一で、同じ対応周波数かつ同じ通信規格である複数機種を比較し
た場合において、計測結果に有意な影響は見られなかった。
一方、OSが異なる場合には、計測結果に違いが見られたため、対応周波数、通信規格、OSが全て同一である機種は結果の共用を可能とした。
（https://www.soumu.go.jp/main_content/000371345.pdf）のP6より
※実証結果はこの検討会第7回の↓のNRI資料ですかね。（P15,P16）
https://www.soumu.go.jp/main_content/000352315.pdf
→同一OSで同一通信規格に対応している端末なら「有意な」速度差はない
→OSが異なると都市毎に速度差がある。
となると、今回はスマホが対象のためios/Androidによる差があるとの事ですが、PC
/タブレット/他機器でも同じ事は発生しそうですね。メーカのOS・ファームウェアによって品質が異なるという事はありえるので、測定器を調達する時や複数のOSが異なる端末を使う時は通信速度の挙動が異なる理由にOSの違いを頭に入れるべきでしょうね。
プレゼン資料を作成するのはいつも時間かかりますよね。いきなり資料の絵から作るのではなく骨子から作るっていくにしても、そもそもどう考えればいいのか。
そんなプレゼン資料作成において、この要素はつくるべきという所をまとめたテンプレートが無料公開されていたのでここで紹介しておきます。
勉強になりますね。
