
ラベルプリンターと言えば、SATOが有名なのですが如何せん高い(-_-;)
その点、brother様は市場調査をじゅうぶんおこなっているからか
価格がかなり手頃です。
以前、セシールに見学に伺った時に感動した点が、
コンテナのデバンニングの際に、
ローラーコンベアの上に乗った商品が流れてくるのですが、
外装のバーコードを読ませると行き先が印刷され、
ラベルを外装に貼り付ける事で、
人間の介入を極力減らしているということがありました。
うちの会社でもやりたい!
何年越しの宿題を重い腰を上げてやっとやろうかと思いました。
でも、使ったことない商品を購入して失敗するわけには行かない・・・(-_-;)
ということで利用させていただいたのが、
brother様のラベルプリンター2週間お貸しします
サービスです。
brother様はインテックス大阪で開催される展示会で何度も拝見しております。
今回、もうやらねば!と思い貸与の申込みを先週の日曜日にしたら
翌日に貸与についてウチの会社の環境を聞いてくるメールを受信して、
それに返信したら木曜日の昼には商品が届いていました(・・;)
因みに担当者様からいただくメールタイトルに
SRE
の文字が(・・;)
何か課題をお抱えのようで・・・
そうか、SREプロジェクトを行っているから異常な速さでレスポンスがあるのですね(・・;)
SREとは
SRE(Site Reliability Engineering)はGoogle発祥の運用モデルです。
ソフトウェアエンジニアリングの手法をシステム運用に適用し、サービスの信頼性・可用性・パフォーマンス向上を目指します。
SLI/SLO設定、エラーバジェット、自動化、手作業(トイル)削減、障害からの学習(ポストモーテム)などを通じ、システムの安定稼働と開発速度を両立させます。開発と運用の連携を重視し、継続的な改善を推進するアプローチです。
上の説明文はGeminiが教えてくれました。
私の言葉で説明すると・・・
プロジェクトを異常な速度で行うための開発手法の一つです。
これまでagile(アジャイル)やDevOpsという開発手法がありましたが、
超並列処理を提唱するGoogle様の最新の開発手法がSREとなります。
Google様の何が凄いって、10%改善するよりも10倍にしたほうが早いと思っている会社だとか^^;
agile(アジャイル)では、ちょっとずつ地べたを踏み固めるというイメージでしょうか?
プロジェクトを進める中で、一歩一歩の歩幅を狭くして、失敗した時の後戻りにかかる時間を短くする感じかな?
DevOpsというのは、Development and Operationsの略のことで、
開発と運用を一緒に行う開発手法です。
それまでの新商品(実物だけでなくソフトウェアでも)の作成は
要件定義→設計→開発→テスト→リリース
という順番で行われることがよくありました。
この順で開発を行うという認識がされていない状態だと、
新商品はこの様に作るのか!
と思うかと思います。
この手順は悪くはありません。
世の中である程度の殆どの会社でこの様に開発が行われています。
ところが、もっと開発の速度を上げたいという願いから出てきたのが、
agile(アジャイル)
となります。
細かく分けてちょっとずつ進むことで、後戻り作業の時間を短くして、
新しい商品を短時間で市場に供給するという目的で作られたようです。
ですが、agile(アジャイル)にも問題がありました。
その問題を語るには文字数が少ないので割愛しますが、
その後出てきた開発手法がDevOpsとなります。
私が数年前に開発したアプリがあるのですが、
開発は私が行い、顧客に相当するアプリユーザーは社内の人であったり運送会社の集荷担当者であったりします。
一人で開発して、ユーザーの意見を聞くのも私でしたので
DevOpsと言えるのかもしれません。
こういうふうにしたいという目的があって、
何をどういうふうに使うという基礎設計があって、
プログラムと道具を使ってコーディングをしていくという開発をして、
出来た商品をデプロイ(配置)して、
ユーザーに使ってもらう。
ユーザーから使い勝手や希望を聞いて、
設計を修正して、
コーディングを行って、
機能追加した商品をデプロイして、
ユーザーに使ってもらう。
自分で使いながら改善点が見つかったら・・・以下同文
バージョンアップ履歴を見たら、
2021/01/04に初版を作成して、
2022/04/11までに20回のバージョンアップを行っておりました。
全部書いたわけではないのでバージョンアップはもう少しありそうですが^^;
バージョンアップ履歴を書くのってまぁまぁ大変な作業なので、
2022/04/11以降もちょこちょこ変更していますが、
それでもそれから3年の間ノートラブルで運用できています。
一体何作ったん?
という話ですが、ウチの会社は出荷が2拠点ありまして、
拠点ごとに運送会社別に出荷予定数を自動で表示させるものです。
当然、運送会社間でお互いのデータを見ることは出来ませんが、
社内ではすべてのデータを見ることが出来ます。
これって集荷する側からすると喉から手が出るほど欲しい情報なんですね^^;
確かに今日何個荷物があるのか?何立米の荷物があるのか?カゴ台車何台分の荷物があるのか?
って集荷のオペレーションに直結しますからね^^;
うどん県ではそういう情報を提供してくれる荷主は無いとか(-_-;)
私が知りたくて、でも作業をやりたくなくて自動化したアプリなんですけどね(-_-;)
DevOpsは自分で行ったのですが、
確かに開発&改善する速度は高かったように思います。
ですが、DevOpsでもGoogleは問題を感じていたようです。
Googleのチーフエンジニアは休日でもトラブルの電話がかかってきて
会社に行くことも頻繁にあったとか・・・
そういう問題に対して出てきたのがSREとか・・・
SREはエンジニアがサイトの信頼性を向上するためにかけて良い時間が決められているとか・・・
しかも、信頼性が担保されるようになると新商品の開発にかける時間が定められているとか・・・
信頼性というのはエラーが発生させないためにかける時間と言い換えるかもしれません。
または、顧客の要望に対して高速で答えることに対して
例外を想定の範囲内にするための作業であるかもしれません。
SREではその作業にかかる時間が決められています。
SREではその時間が超えそうになると開発の方に作業を委ねることを良しとしています。
SREは顧客からのフィードバックに対して改善するための時間を決めていて、
設計から見直すことにより改善する時間を減らしていき、
その見直す時間が少なくなっていって一定時間を下回ったら
新しい商品(機能)を追加することとされています。
閑話休題
会社というのはなんらかしらの課題を抱えていると思います。
企業活動というのはその課題を早く解決することだと思います。
その解決する方法は
agile(アジャイル) → DevOps → SRE
と移行しているようです。
確かにSREを行うことで、
旧来からするともはや異次元とも思える速度で会社の環境の改善が出来ます。
すごいな・・・
brother様・・・・