こんにちは mtjです。

作業の自動化という話は昔から依頼あるのですが　それには様々な分析が必要になります。

まず人が判断している　作業にどのような判断が存在するかの分析が必要になります。
そしてそれをソフトに入れる事が可能かを判断します。
人がノリで右か左を押します　のような案件はソフトでは難しいです。
ソフトでは最終的には0か1かが必要になります。

それを人が判断している場合は　判断している要件をまとめて　センサーなりなんなりで0,1の判断できる状態まで落とし込む必要があります。
完全自動は上記をすべてデジタルに落とし込める段階になっていれば可能です。
判断が難しい箇所等は外部から人が操作する等で半自動化で進めます。

極端ではありますが１日一回人がボタンを押す半自動化か、その押す動作をどれだけの費用かけて完全自動化するか
という話が自動化、DX化には常に付きまといます。

基本は費用と時間があれば　根本的に不可能な物でない限り可能です。
現実は期間も予算もあるのでその中で可能な限り　効果のあるシステム、仕様を提案するのが自分たちの仕事になります。
何かの本でプログラマーには政治も大事との話がありますが　本当に大事だと感じます。

こんにちは mtj です。

工場等では昔から進んでいる自動化、省力化　最近はレストランでも進んでいますね
普段の店で見るのであればセルフレジ、配膳ロボットでしょうか

猫ロボットは動いているとなかなかかわいかったです、普段自分たちが良く見るのはあれの下だけのパターンなので容姿があると印象が結構変わりました。
猫ロボットは配膳だけですけど行き来の回数を考えると効果はかなりの物になると思いました

やはり省力化はこういった細かい事から行う方が導入のハードルは低いんだなと感じました

工場等でこういった提案をするとよくあるのが　人のほうが安い、全部自動化しないと意味がない等言われることがあります。
全部自動化を猫ロボットで考えた場合　料理を自分で乗せて、自動的に判断して目的の場所へ移動、空の食器等は片付ける等でしょうか
面白さはありますが導入ハードルも開発期間もとてつもないでしょう

今後も労働人口が少なくなるに連れ省力化に取り組んでこなかった企業が淘汰される時代になると思います
プログラム開発もそうで　効率の良いIDE、ライブラリ等、テストの省力化等を使う能力が大事になってくると思っています
またシステムの提案の考え方も変わってくると思います

開発手法でもそういった方法を逃さず手に入れるようにしていきたいですね

こんにちは mtj です。

プログラムと一概に言ってもそれを使用する場でかなりの意識の変化が必要になります。

• 組み込み系
• ネイティブのアプリ
• WEBアプリ
• サーバーサイドのプログラム

上記のそれぞれで考える事、注意する事がばらばらで同じ動作をさせようとしてもそれぞれで難易度が異なったりします。
また使用する言語、フレームワークの向き不向きもあるためかなり広い範囲での知識が必要になるように感じます

個別にどれをやっていたからどれが簡単等も少なく 基本はその分野について知っているかになると感じました
大まかなくくりの中にもどのネイティブ環境か　フレームワークかCPUかだったり細かい違いがあるためさらに細かい分野知識も必要になりソフトが改めて奥が深いと感じます。

AI等も流行ってくるのでそれらも応用できるようになっていくのが時代の流れかもしれません。

こんにちはmtjです。

何かしらのソフトを触っていると なんでこんな使いにくい　だったり　おかしい動作があるんだって思う時があると思います。
開発の中では簡単な部分は完成してしまっていると通過点になってしまっておりそのまま開発が続けられる可能性が高いと思います。
その通過点に使いにくい部分があったりする事で上のような明らかにおかしいような動作が残されたりするのではないかなと思います。

大事なのは実際に使ってみてのテストになるのですが
それもテスト者がどの程度効率化、使いにくさ、わかりにくさを認識するかになると思われます。

結果としてはなかなかそういう事を防ぐのは難しいと思いました

こんにちはmtjです。

ソフトの受託開発は基本的にはお客さんの仕様通り作る事が仕事ですが
明らかに操作フローが不明だったり　違和感あるような内容は少し細かく踏み込んだりします。

依頼側が詳しければきちんと教えてくれたりしてくれます。
特に詳しくない場合UIもフローもだいたいなんとなくだったりします

そういうときにこちらが意識して問い合わせる内容は以下のような内容です。

• 誰が
• どの程度の頻度で
• どういった目的で触るか
• 触ったり 情報を得た結果、操作後はどのようなフローか

上記の情報からその立場で仮想的に使ってみてUXを検討します。

誰が
操作者の知識量を想定します。
システムに慣れた人かどうかか特定の一部の人だけかでUIのわかりやすさ等を検討します。

どの程度の頻度　どの機能をどの程度の頻度で触るかで使いやすさの検討を行います。

どういった目的で触るか
主に画面操作時に見せる内容、入力等を検討するため

結果、操作後の動作
操作結果の見せる情報、物理的に出力する内容の検討のため

上記を意識し 提案をしていく事で良いシステムが出来上がると思います。

普段生活している時も意識してシステムを見ることで普段作っている側では発見できないような事も発見できるかもしれませんね。

こんにちはmtjです。

最近といっても数年前からですがAIでプログラム出力が盛んになってきました。
AIのプログラムはしっかり読んで覚えるべきかどうかが度々議論になっている気がします。

自分は自分の価値を高めたいのなら見るべきだし、作業としてさっさと終わらせるだけなら見なくていいという意見です。
自分の場合は基本読んで理解します、読まずにAI作成プログラムを導入するのはリスクが高いです
見ない人の気持ちも上に書いた通り さっさと終わらせたいならそうすればいいという感じです

上のような話はプログラムをコピペで作るだけという話にも似ているような気がします
読んで理解して書くより　動いている動作をコピペして目的通り動けばいいという考えですが
早いといえば早いけど コードで見たら酷い物になっていると思います、酷いものと理解できるのであればそもそもそういうレベルでコピペなんてしないと思いますが

AIを読まない人の話も コピペでプログラムを作る人の話も　システム制作の話を深堀りしていった時にからっぽになってしまうのではないかと思います
自分が面接をしていたら そんな怪しい人は取れない気がします

よく言われていますが　今後はシステム開発はAIを使っている人　使われている人を見極めるスキルが必要になるのかなと感じます
使われている人の場合はシステムがうまく行っている場合は問題ないように見え、速度も早いですが 爆弾を含んでいるような人材になると思います
AIで上手くいかない場合の対処が難しくなり 復旧等も時間がかかり最悪復旧不可のような自体もあるかもしれません。

システムを完成できない人よりも見極めが難しくなるかもしれませんね

こんにちはmtjです。

.Netの画面遷移について
デスクトッププログラムを作る上でWebのような画面遷移は悩んだことがある人が多いのではないでしょうか
WPF UWP等を扱わずに初期状態のWinForm等でできる動作としては以下のような作りになると思われます。

1.新しいFormを作る
　画面毎に切り離せるので作りが綺麗にしやすいのと作りやすいです
　移動時に画面が新たに開くのでWebのように見せるためには少し工夫が必要

2.コントロールの表示を切り替える事での動作。
　見た目は１つの画面で遷移ぽく見えるので綺麗です。
　欠点としてはForm側での管理もあるので気をつけないとコードが汚くなってしまう事です。

自分は新しいFormを作り 現在の表示用の画面に中身のコントロールを配置するようにしました
１のForm別の作りやすさはそのままに遷移のように作れるので割とうまくできました。
懸念点としては別Formの物を移動しているので予想外の挙動をするのではないかというぐらいです。

利点としては置く場所さえあればよいので本当の画面遷移のように表示したいFormさえ何かで受取表示さえ行えば上位はほぼ気にすることなく動作を行える点です。
コントロールの時のようにコントロールの表示の切り替え等を作ったりする必要がなく それぞれのやり取りも必要最低限のデータで行えます。
１つのFormで完結していればデータの受け渡しも必要ありません。

結構WinFormでも工夫することで面白い表示が行えるので色々試したいと思いました。
以上です。

こんにちはmtjです

仕事上あまり外に出る機会はありませんが　いざ展示会等含めて他のシステム、物を見る事は大事だなと感じます。
主にソフトの話にはなりますがやはり別業界のソフト、システムを見ると勉強になることが多々あります。

細かくはその業界での知識になるかもしれませんがデザイン、システム全般はソフトであれば使える、応用できることが多いです。

良いデザインがあればそのデザインを学び、面白い動作であればそれを覚えたり等システムの挙動として覚えることが多かったりします。
コードは見えないので真似する事はできませんがそれ以外ではかなり勉強になる事は多いです。

特にお客さんに提案したりできる事が増えるためやはりそういった外部からの刺激は大事だなと感じます。

こんにちは mtjです。

プログラマーをやっている人であればわかると思いますが結構趣味と仕事の内容が被ってきたりします

家でサーバーを立ち上げて何か趣味のWEBサービスを立ち上げたり
それこそ何かのソフトを作ったりまあまああります。

使う知識も仕事で知ったことだったり、趣味で得た知識を仕事でも使ったりします。

そういう意味ではプログラマーという仕事は結構境界が曖昧で使える知識も多岐に渡っているんだと感じます。
ゲームのコントローラー等を自作したりハード関係に波及できたりもします。

覚えて知識を本当に色々なとこで活用できるのでなかなか楽しいですね

こんにちは　mtjです。

失敗から学ぶということで　ソフトは基本失敗から学ぶ事が多いです
なので自分は成功事例も失敗事例も色々な物を見ています、開発秘話等の難しかった所等を見るのはかなり好きです。

そういった事例を蓄えておくことで事前に収集しなければいけない情報もわかるようになります
その情報を元に発生するかもしれない動作以外の問題について対策していきます

よくある話だとサーバーのログイン関連でしょうか
同時にログインされる想定人数等を元にソフト、サーバーの規模等を決めていきます。
同時に約１０人しかログインしないサーバーに１万人規模のログインサーバーを建てる必要はないので

それ以外にもサーバーであれば今後のスケール等を元にそういった実装も加えていくのもいいかもしれません

というように設計は経験、知識で要求機能以外の問題点を確認していくと思います。
自分は同じ業界の友達とニュースになったような不具合等で雑談する時もあります
いろんな業界の人がいるので勉強になることも多いです。