AIは既に生活に入り込んできている

AIは既に生活に入り込んでますね。

ロボットは屋内に使われているようで、屋外ではもう少しブラッシュアップが必要だと思われます。その理由としてはプログラム上の分岐の複雑さによります。

  • 進む方向、距離の定義
  • 進む軌道がずれたときの修正（路面の状況に左右される）
  • 障害物（屋外の場合は突風とかも）の有無

他にも。

  • 機械の経年劣化、消耗
  • バッテリーの充電

小規模で外的要因による動作不良が少なくてすむので、屋内で始めるのは理屈に合っています。この結果を元に屋外の使用に耐えられるものが出来上がれば、農作業の負担が減って人手不足も解消するのではないでしょうか。

今回は農業ですが、他の分野でも同じことは進んでいきますね。ドローンでの配達とか話題になりましたが、法的な整備がされればすぐにでも始まりそう。

いろいろなところで人手不足が解消されてみんな幸せになれる！

その幸せな未来を掴むべく、人は主体性を持ってプロジェクトに積極的に関わっていきましょう！

やらないことを決めないと

こんなことをつぶやいてた。気持ちに余裕がなくなってきてますね。

実際にその通りで、まわりに投げれるかというとそーでもなくて、という状況です。正確には投げたけど、まったくダメでまわりの状況的にもうまくまわらなくて引き取りました。引き取った状況もまたひどく、これがなければ一週間程度の時間は確保できたはず。

問合せも溜まってきているし、なんとかしたいとこなんですよね。今のところ、解決方法はいかに仕事へ時間を費やすか、というところ。

自分が関わらなくてもなんとかなるものは他の人へ任せ、自分しかやっていないことだけに時間を使おうと思います。そのために断らないといけないことがあるので、心してかかろうと思います。

改善の見極めが大事でしょう

学ぶことが非常に多い。

この記事の中ではとりあげられており、どこにでも共通する考えがあった。その事例として上がっていたのは「浴室のチェックを時間ベースではなく利用者数ベース」にしたこと。なんでもないことですが、なにが問題となるかを理解しないとこの考えにはならない。メンテナンスが必要なのは利用者されることによって状況がかわることがほとんどでしょう。定期的に見回りをするのは簡単ですが、タイミング的にはずしていることも多いのだと思います。そのことに違和感を持つことも難しい。それに対して改善を実施するのがすごい。

この部分に気が回るのであれば、他の業務改善にも手を出して行けるし、お客さんが不満に感じることを拾い上げることができる。その結果、利益が伸びる。いい循環ですね。

この改善を推し進める人になるべく、がんばります！

ちょっと反省してます

1ヶ月ぶりくらいに元同僚の後輩に会いました。いろいろ苦労しているようでしたが、その中でもがんばっている様子。

自分も似たような状況なので頑張らねば！と思っているのですが、いろんなノイズが邪魔になって思うようにいかないです。

ノイズを打ち消すには集中するのが一番の方法だと思います。その妨げになる大きな要因は「電話」ですね。思考を切り替えなくてはいけないけど、内容が薄くなってしまうのが電話。なので急ぎの対応を除き、電話はしないようにする。メッセンジャーならまだいいんですけどね。

他にもノイズがあるけど、差し当たってはこの方法で凌いでみようかと。

忙しさに追われると見直すことができなくなり、結果としてパフォーマンスが落ちるので、振り返りの時間を確保するようにしていこうと思います。

チームで動くためにはどこを重要視する？

最近、近くの席の後輩が使っていたタスク管理ツール。以前アプリを入れてみたけど、操作感に慣れなかったこととタスクの引越しが面倒ですぐに削除してしまったのです。今はどーでしょうか。もう一回インストールしておきました。

チームで動くことを念頭に置いて再検討してみようかと思います。

  • 課題とされていること

    • 問合せの状況把握（致命的、緊急対応を迅速にするため）
    • 営業が客先訪問する際の問合せの残作業の確認

  • 可能であれば

    • 全体のスケジュール管理（遅延がないかの確認）
    • 外出予定の共有（スプレッドシートよりいい管理方法がないか）
    • 導入までの残作業を把握
    • 売り上げに繋げている人、そうでない人の把握

  • その他

    • できる人に権限をあたえて、アグレッシブに動けるようにする
    • できない人を放置してもよい環境作り

なにをするにしても、結果に繋がらなければ意味がないです。ユーザーの信頼という数字に上がらない内容も含み。それを踏まえて…上で挙げた内容はどれも重要だな。

スケジュール管理を考慮すると、自分が使っているタスク管理ツールだと機能が弱い。ただ、どこまで使えるかは事前の検証が難しいし。

後輩が使っていたasana、部署内で使っていたことがあるbacklogを再度試してみて、運用に乗せれるか確認しようと思います。

マンガがリアルにやってきた！

マンガでは見かける光景ですが、リアルだとこんな仕掛けが必要になるんですね。

このメガネを作ろうという気持ちはどこから来たのだろうか？角度を変えていき、どこかのポイントで決めポーズになるんじゃないかと、そこでポイントが見つからないと諦めてしまいます。でもこの人は違う。決めポーズのための小道具を作ってしまうのだ。この遊び心がいい。

ちょっとしたことをサクッと実現できてしまう行動力に感激。どんな壁が現れても解決策を提示し、乗り越えていくのだろう。見習わせていただきます。

ソース管理のために社内プレゼンをしました

つぶやいた通り、社内プレゼンを実施しました。

反省も含めて振り返ってみようと思います。

  • 目的

    • 現状はソースの管理ができておらず、デグレや複数人で開発したときのマージが人の手による確認しかない
    • 現地のバージョンと社内のバージョンが明確になっていない等の問題もあり
    • 問題解決のためにソース管理ツールの使用を提案し、全体の概要を掴んでもらうことが目的
    • 部署として使用するために指示者を対象に実施

  • 事前の根回し

    • 定例会で試験的に開発者の中で使用していることを説明
    • 運用方法も含めて文書として書き出してあり、運用開始できる体制を整えつつあることも伝えてある

  • プレゼンの内容

    • 製品をよくしていくために必要であることを一番最初に説明
    • システムサイドからのアプローチの１つである
    • ブランチの考え方、git-flowによる管理を提案
    • ブランチの考え方を見ると複雑だけど、操作は簡単であることを実演を踏まえて説明

  • Q&A

    • ディスクはどのくらい使うか
      • 物理的に管理するより少なくて済んでいる
      • すべての履歴を物理的に管理しているわけではない
    • マージはどうなるか、同一ファイルを修正していた場合は？
      • ブランチの終了を行うことでマージされる
      • 同一ファイルを修正していた場合は競合していることがわかり、自分の修正と他の人の修正がわかるように表示される
      • 競合が解消された、という操作後にコミットして完了
    • 基幹系はどの単位で管理するか
      • システム単位での管理がいいと思われる
      • exeの単位だと対象が多くなって管理できない
    • ソースを見る場合はすべてローカルにコピーしなくてはいけない？（ディスク容量が心配）
      • ローカルにコピーする必要あり
      • 終わったら削除すればよい
    • リポジトリが崩壊したらどうする？
      • 通常のサーバーのバックアップから復元させる
      • 開発者のローカルがバックあっの意味合いにもなるので、最悪の場合は開発者のモジュールを最新バージョンとして使用する

伝えることは一通り伝えたけど、反応はイマイチ。忙しくて便利なツールがあっても気にかける余裕がないのかもしれないですが、忙しいからこそ管理体制を整えた方がいいことは伝えました。難しそうな雰囲気を出してましたけどね…

少し検討期間をおいて議題としてあげる予定です。少しでも前へ進んでいることを祈る！