こんにちは mtj です

自分たちはシステムを依頼される側ですが　相手により依頼のされ方はバラバラです。

やりたい事、出したいデータ等を依頼される方、結構具体的な内容の資料を作らる方等あり
どちらが楽かというと一概には言えないと思います

具体的な場合のほうが作るだけだったりありますが　実現不可能な物を具体的に書かれていたり
システムとして矛盾があるような場合もあります

やりたい事、出したいデータのみの場合も あまりにも抽象的すぎたり、システムのイメージがなかったりするとそれも話が長くなります。

自分が思うシステムを依頼する場合に必要な物といえば

• システムに対する具体的な作業（データを見て〇〇する等）
• そのデータを表示、出力するために必要なデータ（人が入力　データベースから取ってくる等）
• 作業のために必要な具体的なデータ（データが〇〇の時は△△する等）

システムは何かすらの最終出力がある物だと思っているので 自分が抑えるのはシステムの最終結果どうしたいかを抑えます
そこが曖昧の場合は良いシステムが作れないと思っています。

改めて思うとUMLのユースケース、シーケンス図はユーザー側でも覚えたほうがいい図なんだと感じました。

こんにちは mtjです

プログラマーの仕事のメインはやはりプログラムを打つことがメインになると思います。
自分も他人に職業を説明する時は基本プログラマーと説明しています。

しかし実際にはプログラマーも範囲があり
本当にコードを打つ人、システムを作る人(メインはプログラミング)のような人もいるかと思います。

コードを打つ人であれば仕様書を理解して コーディングできる能力。
場合によっては軽く設計する力が必要かと思います。

システムを作る（設計する）人であればシステム周りの知識が必要でかなり広い範囲で知識が必要に感じます。

上記のような感じでシステムを作るにも段階的に知識が異なります
また上記のコードを打つ、設計、システムを考える等の境界はかなり曖昧だと思います。

コードに落とし込めるような仕様書を書くという話もどの程度書くのかでかなり所要時間に差が出ます。

但し、プログラマーを目指すならばシステム一連を作る知識も大事ですが 個人的には一日中PCの前で考えたり キーボード叩けるかが大事かと思ってます。
最終的にはどのような仕事も少しでも好きじゃないと成り立たないんじゃないかと思います。

こんにちは 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です

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

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

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

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