ヤマト運輸、Githubの活用事例で「ソースコードを書くなど単純な作業」と発言してしまい炎上。 [472567884]
■ このスレッドは過去ログ倉庫に格納されています
theatrical エンジニアにアピールするためにgithubのインタビューうけてるのに、その中でコーディングを単純作業とか言っちゃうの、リクルーティングのセンスなさすぎでは。
W53SA “ソースコードを書くなど単純な作業は外部に委託するなど柔軟な対応が必要です”
Nunocky プログラミングが単純作業になるレベルの実装仕様書があるということならぜひ参考にしたい・・・
kaorun それも大事かも知れんけど、クロネコメンバーズでブラウザの戻るボタンが使えないとか、送り状作成の手順がやたら冗長な上にEdgeでは必ず途中でエラーとか、顧客のユーザー体験をもっとちゃんとして欲しい。
greenbow 言わなくて良いことを言ってしまった感。「コアな開発は内製化し、それ以外は外部に委託するなど柔軟な対応が必要です」みたいな表現ならよかったのに。
napsucks 卑しい卑しいコーディングは下賎な下請けに丸投げしてワシらはパワポで小綺麗なイメージ作り頑張りますよと読めてしまういいっぷりだが大丈夫だろうか
mtk_inrs 自分の仕事軽視されるとむかつくでしょ？はてブユーザー他の職業には平気でそういうこと言う人いっぱいいるよ？
b.hatena.ne.jp/entry/s/github.co.jp/customer-stories/yamato
https://github.co.jp/customer-stories/yamato 仕事出す側はみんな思ってることだから
言わないだけで >>6
単純だからこそ管理職がそんなことやっちゃ駄目でしょｗ ヤマト子会社のシス開はどんな気持ちなんだろなんだろな プログラミングの基礎から教えます！って求人ばっかだからな
そんな余裕のある現場はない >>11
まあ、トラックをナビの言うとおりに運転する程度には単純作業ではある
そのナビが正確である保証がないだけでw 作業はキーボードを叩くだけの単純作業。
仕様どおりに動かなくても良いなら。 ヤマト内部で使ってるタブレット端末がズブくてくそ遅いのでなんとかしろ 批判してる人は視点が間違ってて、ヤマトには簡単なコーディングでできるものしか必要とされてないんだよ。Amazonとは違うってこと。新しいことしてないからマイナス100点！🙆 こんなのに噛み付いて…発注側の心理を未だに読めない受注SEがまたいたのか。 そりゃロジックが完全に仕様書に書かれてれば
あとコード書くのは単純作業なのかもしれないが
仕事でそんな仕様書に出会ったこと一回もないわ コーディングを単純作業にしてくれる程仕様を固めてくれてんの？ >>24
官僚は知らない
大手で管理職してるけど仕事はシンプル ヤマトは倉庫で商品預かって注文来たら配送するサービスしてたと思うけど
それがGitHub相当でコーダーは配達員か 無能がどう思うかは知らんが単純作業であってるぞ
複雑の基準は無能と有能で差異があるだけ 絶対安全で正確丁寧に運んでくれるドローンの制御プログラムでも書いてくれんのか？ 確かに送り状作るの面倒臭い
修正すると気がつけば着日最短日になってるし >>15
ナビレベルまで正確な仕様書って存在するの？ 本当にコーディングすれば良いだけの状態からコーディングするだけなら単純ではあるな >>18
要求仕様が明確で、知っている範囲の関数なりメソッド、ぱっと思いつく程度のアルゴリズムだけで実現できる範囲の仕事しかしてないんですねｗ >>14
管理とか調整とかは一言で済むもんな
実態は複合的で説明の難しい事が多いんだけど、バブルの管理職見てると簡単を通り越して丸投げだもの >>36
無いとは言わない
それを書くよりコード書く方が楽ってだけで 「理系でもわかる～（文系分野）」というタイトルがまず見当たらないのはコンプレックスの裏返しか
童貞が女を馬鹿にするような githubの日本支社従業員もワイン飲んで飯食って帰るタイプなのか？ すでにあるものを改修するのは他の部分を参考にかけばいいから楽
新しいものを作るのは一から色々調べたり検証したりしながらやらないといけないからめんどい 単純作業レベルのコーディングが外部に委託するほどあるなら、
自分でツール作って吐き出すわ
外注向け仕様書作って出来たら検収、不具合連絡して再テストって方がよっぽどめんどい なるほど納得
ここ数年、端末やシステム周りがgdgdなのは
そういうことなのね 修正してやがるな
修正前（Internet Archiveより）
「これまでの内製化はアウトソーシングからの見直しが主体でした。これからは、アーキテクチャのデザインや、GitHubを活用した
ソースコードのガバナンス・標準化が実行可能なメンバーによるコアな開発は内製化し、
ソースコードを書くなど単純な作業は
外部に委託するなど柔軟な対応が必要です。どこまで自社のコアコンピタンスを内部リソースとして持つかを見極めることにより、
1歩進んだ内製化の道も見えてきます」
修正後
「「これまでの内製化はアウトソーシングからの見直しが主体でした。今後は、アーキテクチャのデザインやGitHubを活用した
ソースコードのガバナンス・標準化が実行可能なメンバーによるコアな開発は内製化しつつ、
短期的にリソースが足りない部分は
外部に委託するなど柔軟な対応が必要になります。どこまで自社のコアコンピタンスを内部リソースとして持つかを見極めることにより、
1歩進んだ内製化の道も見えてきます」
ヤマト運輸 執行役員 （DX推進担当）の中林 紀彦氏のインタビューの発言を書き起こしたものだろうから訂正は改竄とも言える むっちゃ設計書が整備されてて何一つ疑問がなくて有識者がなんでも質問に答えてくれるような環境ならって理想的な条件付きで単純と言えば単純なんだけど
現実は目も当てられないくらい土台がズタボロな事もあるんだよな ソースコードを書くってのが範囲大きすぎる
内製ツールとか公式サイトのサーバー側を構築するくらいなら単純作業だろうけど 内製してる１００人が凄腕だったら別に何の問題もなく単純作業になるよ
それはいいんだけど、全体的にやたらGitHubの事を持ち上げてる方が気になったわ
// 「DevOps開発体制を構築・浸透させる上ではデータグラビティ（データの蓄積によりビジネスに与える
// 影響力が高まること）がより重要になるため、ソースコードの維持・管理で最も信頼でき、かつ付加価値
// の高いGitHubを選択することは自然な流れでした」
この文章の前半のデータの蓄積と後半のソースコードの管理とか、内容が全然関係なくて文章がつながってなさそうに見えるし 中の人間だけど
ほんと終わってるからなこの会社は
増収減益により業界で一人負けなのも顕わになった ヤマト運輸は何十年にも渡り違法に信書を宅急便で配達し続けています。
宅急便で信書を送る事は郵便法違反で最長３年の懲役刑です。
送った荷主も配達したドライバーも刑罰に課されます。 宅急便でなど信書が送られてきたら違法行為ですので、警察へ通報しましょう。 バブルの管理者は糞だからな。
簡単な仕事をややこしくする。
仕事を増やす。手続きを増やす。
ろくなことしない。 330 国道７７４号線[] 2022/11/30(水) 21:19:27.35 ID:TUMlxneE
運送業界の最大の問題は、賃金が安い、労働がキツい、ではない。どんなに安かろうがキツかろうが、やりたい本人の自由で他人が口出しする事ではない。
法定賃金、雇用保険、失業保険、法定勤務時間による残業代等の人件費削減で利益を生む為、個人事業主に偽装した委託契約を結んだ人間を、運送業を騙る無免許の労働者派遣運送業者から積極的に仕入れているヤマト運輸や佐川急便、
運送業を掲げながら、無許可で人材を斡旋し、ピンハネをするという犯罪行為が公然と行われて、しまも募集広告が掲載できてしまうという、土人の様な倫理観。
これは、令和の人身売買であり、宅配業界は人身売買の温床であるということを、日本人は知り、そして恥じるべきである。 >>54
記事全体がGitHubのプロモーションだからな いまだにプログラミングが特殊技能だと思ってるのか
PGなんか最底辺なんだから間違ってないだろ きっとヤマトさんからは、完璧な要件・要求・設計・実装仕様書が出てくるって事だろ。
それか昔みたいに「紙にプログラムを書く人」と、「その紙を見てコンピュータに入力する人」に分かれてて、後者の事を指してるか。 仕様も書けねえ底辺PGの見当違いな批判が笑えるスレ
だからおまえら給料安いんだよバカだから 今どきコーダーって存在するのか？せめて内部設計を自身でしてレビュー指摘を受けた上で自身で製造するのがエンジニアだと思うんだが。 現場の人間に責任もすべて丸投げで無駄なことばかりする上の方たちが60%を占める会社だからな ヤマト運輸のiOSのアプリ、変な動きなんだよ。
直せよ！ ピラミッド業界では設計と実装って完全分業なの？
うちでは外部仕様から先は全部PGの仕事だけど >>64
不足してるのはマネジメントと設計できるエンジニアだろ
単純にコーディングするだけの人は足りてる コミットやってプルリクしてからマージするときコンフリクト >>72
単純にコーディングするだけの人に任せられるだけの設計が出来る人がいないから、単純なコーディングするだけのはずの人にまで設計能力が求められてしまうジレンマ 多分アプリ開発してるエンジニアと
業務システム開発してるエンジニアでイメージしてるプログラマー像が違うだけ
業務システムの場合設計に落とし込めていればプログラミングは単純作業だよ >>72
単純にコーディングするって実際どういう作業を想定してんの？マジで謎何だけど ヤマト運輸の下請けアプリの星がいつくかご存知ですの？
ソースコード以前の問題ですわ やっぱ外国の知識をそのまま便利だからつって移植したせいで、訳の分からない日本語を平気で使う奴が増えちまったな
英語を単純に翻訳したらそらクソみたいな日本語になるわ >>78
誰でもできるような低レベルの仕事しかできないから、上層部から「単純作業ｗ」なんて言われてるんじゃね 詳細な実装仕様書のままコード書くだけならそりゃ単純作業だわなｗ
そんな実装仕様書作るとか、本人がコーディングしたほうが早いだろうけどｗ お前ら詳しそうだから教えてくれ
ローコード開発とフレームワークって何 すげえな何言ってるか全然わからん
ソースはブルドッグ派です >>77
単純な機能ならモジュール概要が纏まっていて入出力仕様と部品の利用が分かればいいし
複雑な機能ならあとクラス図やシーケンス図までまとまってればあとは単純にプログラミングするだけだろ 配達だって物運ぶだけの単純な作業とも言える
実際は単純じゃないけど 新人研修のときソースコードと1：1レベルの詳細設計書書かされたことあるけど
今時実務でそんなことしてるところあるの？
それなら実装は単純作業と言えると思うけど >>85
それ単純作業じゃないだろ
これだけでもできれば仕事はいくらでも見つかるぞ >>88
ちがうわ
そこまで設計してる前提だから単純にソースコード書くだけと言ってる
ヤマトさんが言ってるのってそういうことじゃないの？ >>90
頭使わずに手を動かすだけではこの作業はできないだろ
それを単純作業というのがおかしい 小学生の時にやった漢字の練習みたいに左に書いてあることを右に移すだけと言う意味で単純な作業って言うのは理解出来るんだけど、
多くの場合はいうほど完璧であることは無いので、多分単純と思ってる中に複数の解釈の余地が含まれてるケースがあるんだよな
本当に左から右にうつすだけなら設計する意味ないしな、常に解釈して理解した後に同じ認識になる知識の共有の訓練みたいなのが必要なんだよな Githubの文字見るとASUKAのギフハブ思い出して笑ってしまう 本当に単純作業レベルに落とし込めてるなら
その辺から人攫ってきて最低賃金程度で日雇いできると思うよ そもそもほんとうに単純作業レベルに落とし込める仕様書があるならコード化なんて自動化できるはずだろ
単純作業に人知の介入する余地がないはず >>90
どーなんだろうなこれ
全部揃ってる前提ならAIコーダーが読める形にすれば人なんていらんし
新規要件が発生するなら別途スケジュール組んで同じように対応しろよってことで雇い入れる必要ないし
そうじゃないなら結局運用システムに造詣が深くて突発の要件にも対応できてAIが理解してくれない機微の部分をコーディングするいつもの難解作業になるわな プログラミングなんて中学英語より簡単だからお前らも勉強してキャリアアップしようぜ >>91
新人に毛が生えたレベルでも出来る作業なんですが…
これはこの業界だと単純作業と言います 単純という言葉の意図は多分知識を共有しやすいとか、複雑じゃないから同じ認識になれる、とか記憶しやすいみたいな話で、
本当にそうなのかは実際見てみないと分からないね。多くのケースがあるので一般的に単純な作業だと言い切るのは難しい 日本語の問題だけど
単純作業と単純な作業の意味は違うぞ？
前者だと単純さはかなり高いけど後者なら相対的な単純さになる >>98
最近は有能がIT業界を避けるようになったからどんどんレベル落ちてるよ
こんな作業すらできない >>96
そうなんだよね
実際はジレンマ抱えるんだろうなとは思う 俺はゴールまでの道が見えていてあとは実行するだけなのが単純作業で道順を考えなければいけないのは単純作業ではないと思うね
そういう意味ではプログラミングは単純作業ではない
ヤマトは末端の仕事を単純作業と思ってるようだけどそれに該当する仕事をしてるのはプログラムを実行しているコンピューターだろ でもさ
荷物を運ぶなど汚くてきつい作業は業者に委託するなど柔軟な対応が必要だよな ITは新人に毛が生えた時点で単価80万取るし
偏見だけど平均的な運送業の人件費より高いんじゃないかなあ… ただ動くモノなら簡単単純かもな
想定外の操作で不具合を出さないような仕事に使えるモノを作るのは楽じゃねーよ ＩＴ業界は外人の借り物の概念、知識で労働してる割にイキリピンピンが多いのか不思議すぎる ヤマトのえらい人の頭の中を想像してみる
世の中には命令する人と作業する人がいて作業する人にやらせるのが単純作業なんだろう
そして末端がプログラマーだと思ってるからプログラミングは単純作業だと思ってしまっているのだろう
実際はプログラマーは命令する人で作業する人に該当するのがコンピューターなのに 何すればいいかわかってる作業ではあるな
センスの良し悪しでコードがシンプルになったり複雑になったりはするだろうが無から有を生み出す苦しみ的な苦悩は少ない >>109
プラモで例えれば部品と組み立て図を用意するのがヤマト側のSEで
実際に図に従って組み立て作業する役割を単純な作業と言ってる
実際は図が分かりにくかったり想定外の事象が発生するかもだけど
図や部品を考える側からすると比較すれば考える部分が少ないから単純な作業に見えるわけだ Javaはまあまあ単純だけどJavascriptは複雑怪奇
画面の細かい動きの実装なんか、どうやっても設計があるから、単純に作れるもんじゃない マイコンの組み込み以外ならプログラマあぶれてるからな >>49
プログラマーやってるけど言いたいことはわかるわ
ぶっちゃけ既成のAPIやライブラリ使ってるぐらいだし 実際、コーディングは誰でもできる単純作業だからね
アルゴリズム作るのは一部の技術者しかできないし
コミュ力ないと要件聞き取りもできないけど
コーディングなんて単純作業には違いない
AIにそのうち仕事を奪われるよ >>111
実際には高速化だの軽量化だの、エラー処理だの考えないといけないことはいっぱいあるからな
同じ結果得られても書き方ひとつで性能変わる訳だし >>111
というのが理想論でだな。
君もわかってるとは思うけど。 単純作業って誰でも手順通りにやれば結果が得られるってことでしょ？
ならバイトにマニュアル渡してやってもらえばよくない？
最低賃金で済むじゃん >>119
ある程度の規模の開発なら末端には単純作業オンリーの人間もいるけど、同時に設計も製造も両方見る立場の人間も混ざってくるからなあ
小規模開発ならなおさら、わざわざ単純作業しか出来ない外部に投げるような仕様書作るより自分でコード書いた方が早いしw 厳密な設計書があれば単純作業かもしれんが、そんなもん書けるなら自分でコーディングまでやった方が早い
実際には詳細設計とコーディングは一緒にやるものなんで 誰にでもできる作業だから面接１０分とかで即採用だしな ソースコードを書くことが単純かどうかは別として、ヤマト運輸の上位層が単純作業と発言しちゃうのはアレだろｗ インタビュー受けたのって広報かなんかのひと？システムの人にやらしゃよかったのにね
もしくは広報の隣に牢名主みたいなエンジニアにハリセンもたして待機させとくとか 俺もプログラマーとして客先に派遣されて発注者と仕様の打ち合わせして要件貰って、
計画書と要件定義書と基本設計書書いて、
詳細設計したらコーティングしてテスト項目が出来たら他のメンバーに投げる単純作業してる
この程度しか出来ないから手取り250万たけど楽しいよ >>132
俺なら３人は派遣して９００万は取れるね。やっぱりプログラマーは交渉が下手だな。 事実プログラミングは単純作業だろ
土方みたいなもん。設計書に従って書くだけ >>132
なんというかその、本当お金を稼ぐのが下手くそなんだろうな…という人は多いな…
俺も似たような事をやってるが額面なら1000万は超えている
確かに業界で仕事していて（なんでそこに居る事にこだわってるんだろう…？）という人にはたくさん出会う あ、月ってことか…はずかしいｗ
年収かと思って憐れんでたら大金持ちだった たぶん夜仕分けして夜中に
長距離走って夜明け前にセンター
仕分けして各営業所に運ぶ
実働の人達が1番ハードだろ。
しかもそこは全部使い捨て扱いの
人達だろうし。 設計でも
図面するのは単純作業で
偉いのは一部の人だからなあ 約束事を決めないとちゃんと動かないバグだらけのものができてしまう
どのくらい仕様書やアルゴリズムやデータ構造やロールバックや排他制御とかを検討してあるかによる
デバッグもそれだけいろんなことをテストすることになる
例外時にちゃんとロールバックできるかとか
異常系から正常系に戻れるかとか 物流の運転は自動運転とか遠隔操作とかが入ってくるようになるんじゃないかな ほとんどの書き込みがエアープログラマのものなの笑えるｗ >>72
何て足りちゃうか分かる？設計ができないからだよ。
設計書がないんだからコーディングできないだろ。 セキュリティもままならないPGでよくこんな発言ができるな そうだな
最近はpythonのように数行でカメラから取り込んだ画像から機械学習したり推論出来るからね
原理を知らずに書いてるプログラマーが多いのは事実だよ アスカが警告してた通りになったな
これどうすんの？ 機械学習の1タスクを実現するのと
業務システム全体を考えるのは違うスキルだろうな 日本のお偉いさん達はこうした分野に関して
無知すぎると思う。 創価学会は犯罪を繰り返す邪教です。
創価学会員にはマニュアルが配られ、日常的に気づかれにくい犯罪を繰り返しています。
マニュアルは脱退者が暴露したものが多数あり、検索ワードに「創価学会 敵対者 マニュアル」などで適当に検索するだけでもたくさん出てきます。
このような邪教を野放しにしてはいけません。創価学会をつぶしましょう 今のヤマト運輸、ブラック企業さが増してるよ
マジやばい
報復人事とか陰湿で
愛人を社員にするとかあって
現場は辟易 >>132
250は月じゃなくて年？
もしそうなら働き方変えるべき
フルリモートの月40時間ぐらいの稼働で月80もらってるよ
副業だけど成果給かつリモート可だからできてる >>111
残念ながらプラモに例えるならヤマト側がやるのは箱の絵を用意するだけ
それを元にどんな部品が必要か洗い出して作って説明書までつけてあげるのはぜーんぶ下請け データグラビティはソースコードとか設定データや処理対象データの量が増えて何十テラとかになるとコピーしたり移動するのが大変になることを
物の重さ、重力に例えた言い方のようだな 実際に単純作業だろw
自分等がそんな崇高な仕事してると
思い込んでるのが笑ってしまうw ヤマトの物理業務をITを使ってどうしたいか決めるのはヤマトだけど
それを具体的に実現できるようにする所は請け負った側だろうな
発注側の関与の程度もプロジェクト毎に色々違うだろうけど コーディングするだけの単純な仕事です
先輩社員が丁寧に教えます
アットホームな職場です！ >>160
だよね...
家事を単純作業と言われて女がTwitterとかでキレてるのと、すんごい似てる
たんに単純な工程が多いと言われてるだけで、べつにラクとは言われてないじゃんって 個別に色々違うだろうな
細かいところまで設計してるならそっちのコストの方が高いだろうな
コーティングだけならバイトを雇えば足りるんじゃないか 中途で入った会社だが、仕様書が知ってる前提で書かれているからかなりキツイ まあこれだから情報処理は人気ない
ごくごく一部の出来る人のイメージで語ってはいけない 実際にはコーディングすらできない人が設計してんだよね 元々どうせ機能一覧どころか
ユーズケース一覧書いて発注し、
設計、開発、テスト、リリースのみならず
受け入れテストもさせてのだろう。
あまりに酷いのがリリースされるから
エンジニア雇いだした。
でもこの記事にあるような内製化なんて
無理でしょう。
githubコーポレート版を使用開始しても
vpnとかで繋がせることで設計もコーディングも
全く変わらず外注。
雇ったエンジニアは発注管理をきめ細かくしたり、
マネジメント層とコミュニケーション密になったり
システム構成管理や保守管理を良くすることなどで
手一杯になる。 >>1
プログラミング界隈は言語オタクみたいな奴がいるからな >>158
その説明を書くところまでを内製化して
組み立て作業を外注したいと言ってる記事だろ >>164
そうそう
無から道筋を立てる人と比較すれば
基本的には道すじに従って動く人は「単純な作業」なだけ
実際は道すじに従ってもうまく行かないことあるから単純じゃない！って言ってるんだが
相対的な話をしてるだけ 効率悪いだろ
下請けに裁量を持たせないでうまくやってるところなんて見たことがない 設計書の粒度によるんじゃまいか
プログラム設計書とかいうレベルだと単純だと思う >>176
ヤマトはそういうことをやりたいのかもしれないけど効率悪すぎて実現不可能だろうね 単純作業には違いないんだが
デスクに座ってるから頭脳労働と勘違いすんのかね >>173
それが出来るなら自分でコード書いた方が早いというオチがあるからね 日本ではプログラマーの地位が低いけどそれを象徴してる発言だね
コーディングなんて土方仕事と思ってる人が多いんだろうな 専業としてソフトウェア開発やったことないから
IT土方がどの程度の人なんかよく分からん >>183
そりゃ職業プログラマーの大半が地位向上につながる行動をとってないからだろ
他人が勝手に地位を上げてくれるとでも思ってるのか？ 人の技能を過度に単純化して考えるのは仕事できないやつの典型 要件にも充たないレベルのもんをただどんどんぶん投げて、エンジニアがよしなに作って、品管とやり取りして整えて、それをプロジェクトマネジメントと勘違いしてるPMのほうが単純作業感ある 単純な作業でもうまくいかないから
高度なことをやってるように見える 単純作業だと思ってる人間が投げる仕事ほど、単純作業にならないというヤツ プログラムってコードを書くことなんやけど
こいつら何してんの？ >>193
プログラマーの仕事は無能な上流から流れてくる理想と現実のギャップをすべて解決することだぞ >>193
コードを書くってお前が書いてるんだがお前は何してるの？ >>170
ある会社の業務を知っているのはその会社の人だとされているからな
物理会社とか食品会社とかの中にバリバリの開発者がいるとは限らない
システムを組み合わせる事はできるとしても個別の専用装置やソフトウェアを作ったり人は少ないだろうな 不沈と言われ沈んだ戦艦ヤマトと同じだ
時代についていけない老害は今も昔もだ これだから脳筋でイキってこれただけの連中は(笑)
常時開放型発達かよ 自分で書いてない奴がなんか意見できるとは思えないからなぁ
ヤマトのアプリってそもそもバグで動かないゲームでも2.5位なのに
一時期1.1記録した史上最低評価だったぐらいだからな
本当の意味で給料泥棒って連中だわ、発注せんで作れよw 単純作業ならお前らでやれよな
金も大して払おうとしないぐらい簡単なことだからお前らが片手間でやれよな 「ソースコード書くなんて簡単な作業はやったことないけど、パワポでイメージ作るよりは簡単なんでしょ？」
ということなんだろうな アメリカの企業は社内にシステム部門持っていて基本は内製
日本企業もシステム部門あるだろって？
そいつらは外注管理してるだけで仕事は全部SI業者に丸投げでしょ
そして多重下請けと中抜きの連続
これでは日本のITはダメなままだよ ヤマトシステム開発に弟が派遣でかつて行ってたが
無能ばっかりだったらしい 物を運ぶだけの単純な作業をしている人に言われたくない ロジスティックスの仕事をした事が無い人達は知らないと思うけど
ヤマトより佐川の方が電算系は進んでたんだぜ
配達集荷の伝票もヤマトより早くからイメージ化して伝票No入力で即PCで閲覧出来てた
その頃のヤマトは発店→横持ち（路線）→着店だけの情報のみで伝票の内容欄とか見れなかったんだ まぁ、ヤマトのアプリのデキがあんまりよくない理由がなんとなく分かるな 結局のところ内製するか外注だとしても開発チームを無期限で契約するくらいの体制じゃないとまともなソフトなんて作れんよ
その体力がないならパッケージ買ってきて業務をシステムに合わせるが吉
安易な外注は三方良しの真逆の結果しか生まない ヤマト運輸、長年に渡り違法な信書配達
本来、国の認可を受けないと配達してはいけない信書をヤマト運輸は長年に渡り配達し続けています。
もし、あなたが宅急便で信書を受け取ったら警察と総務省へ報告しましょう。
受取人は処罰されません。
総務省 信書のガイドライン
https://www.soumu.go.jp/yusei/shinsho_guide.html 頭の中で組み立てるまでが仕事で、ソースコードを書き出す段階では単純作業
で間違いないと思うけど？ 完璧な設計なんて絵空事
実際は単純作業じゃないのが目に見える まぁ、最終的にこの手のものの品質を決めるのは、プログラマのやる気と現場の協力具合だからな
どっちも無さそうなのが透けて見える
そらやっつけ仕事になるわっていう
運送業界ではマシな方ではあるけども 完璧な仕様書を、完璧に実装する単純作業です。
LINEを使ってる人なら誰でもできる。 >>206
それは日本の雇用制度によるところが大きいな >>215
その頭の中で考えている事を他人にわかるようにしておかないと他人には伝わらない
本人は伝わるように漏れなく書いたつもりでも読む側には伝わらないこともある Amazonは自社で高給エンジニアがコード書いているぞ 取りあえず動くものは下手くそプログラマーでも作れるけど
それを何年もメンテして運用していくのは無理
その辺が偉い人には分からんのですよ ヤマト運輸さんのシステムってちゃんと動いてるの？心配です 運転するだけの単純な作業
配達するだけの単純な作業 ■ このスレッドは過去ログ倉庫に格納されています
