ソースコードを書くのは単純作業？ 97
ストーリー by nagazou
どうでしょう 部門より
どうでしょう 部門より
あるAnonymous Coward 曰く、
GitHub日本法人の記事によるとヤマト運輸のDX推進を担当する中林紀彦執行役員曰わく、「これまでの内製化はアウトソーシングからの見直しが主体でした。これからは、アーキテクチャのデザインや、GitHubを活用したソースコードのガバナンス・標準化が実行可能なメンバーによるコアな開発は内製化し、ソースコードを書くなど単純な作業は外部に委託するなど柔軟な対応が必要です」らしい（ITmedia）。
後日、記事は修正され、「これまでの内製化はアウトソーシングからの見直しが主体でした。今後は、アーキテクチャのデザインやGitHubを活用したソースコードのガバナンス・標準化が実行可能なメンバーによるコアな開発は内製化しつつ、短期的にリソースが足りない部分は外部に委託するなど柔軟な対応が必要になります」と書き換えられた。
通常このような記事は録音を元に書き起こされるものであるが、本当はどのような発言があったのだろうか。
配送などの単純作業は外部に委託 (スコア:3, おもしろおかしい)
プログラマだけど、宅配の配送などの単純な作業は外部に委託してる。
もしや (スコア:2)
リソースをブログのリライトのようなものだと勘違いして、
既存ページの焼き直しや量産は単純だから委託すると解釈した…のかな…
# その'ソース'とはhtml
ひとつの理想ではあるかも (スコア:2)
そのむかし、FORTRAN や COBOL は、仕様書（実際にはソースコード）から、アセンブラという成果物を自動生成するものという認識で作られたものだったようなことを読んだ記憶がある。
¶「だますのなら、最後までだまさなきゃね」/ 罵声に包まれて、君はほほえむ。
ソースコードを書くのは簡単なお仕事です。 (スコア:0)
単純作業じゃないのは
・仕様の決定
・テストパターン作成
・単体テスト・結合テスト・・・
・バグの低減
・バグ発覚時の修正（特にS後の瑕疵担保期間に・・）
・バグに対する顧客・上長説明
などなど上げればキリないけど、顧客対応・営業対応・工程管理じゃない？
コーディング単体なんて半分単純作業だと思う・・・
Re: (スコア:0)
＞コーディング単体なんて半分単純作業だと思う・・・
顧客対応も半分は単純作業ですよ。。。
決まり文句の挨拶や名刺交換とかね。
それなのに、そういう人らはプログラミングは「単純作業」だといい、
顧客対応は「複雑」な仕事で、単純作業なんてないかのごとく言う。
ダブスタもいい所
Re:ソースコードを書くのは簡単なお仕事です。 (スコア:1)
ほんとに「単純作業」ならAI化以前に自動化されてそう
Re: (スコア:0)
人間を使うことによって付加価値を与えてるんですよ。
Re:ソースコードを書くのは簡単なお仕事です。 (スコア:1)
Re: (スコア:0)
ヤマト運輸は単純作業の配送を外注してますし
Re: (スコア:0)
仕様通りに、スパゲッティなコードでもいいならそうかもだけど、
効率のいいとか、読みやすいとか、メンテナンス性がいいとか、
そういうのを考えるとなると、そこまで簡単なお仕事ではないとは思うんだけどね。
Re:ソースコードを書くのは簡単なお仕事です。 (スコア:1)
スパゲッティなコードの元はスパゲッティな設計書にある訳で
プログラム書く人間に判断させる設計してる時点でおかしいと思うけどな。
自分で設計して自分で書く場合も微に入り細に渡る仕様書を書いた方が
コーディングを瞬殺できるし障害対応の反映も楽で
結果としてコードと設計書の齟齬も生まれづらい。
メンテナンス性の高いプログラムはメンテナンス性の高い設計書から生まれる。
Re:ソースコードを書くのは簡単なお仕事です。 (スコア:1)
一人情シスで内製プログラム組む立場なんでそう思うのかも知れんけど...
プログラムのコメントから詳細設計仕様書を作成する為にできたのが、
JavaDocだったり仕様書工房なんだと思うんだが、詳細設計をしっかりやる人
からすると、あれは使っちゃいけない邪道なツールだったりするんかね。
実際の所、本当の詳細設計(関数名からその関数内で作業する内容、変数までを含む)
なんて書いてたら、やってる事ってプログラムのソースを書いてるのとあんまり変わらんでしょ。
違うのは、実際のコードを書いているかプログラムの詳細な文書を書いてるかって話だよね。
なんと言うか、詳細設計仕様書を書く事とコーディングを分けられてしまったから、
詳細設計仕様書を書く事とコーディングに違いが出ただけで、本来やってることは同じ筈で、
分けられてしまった結果が、コーディングをキーパンチャー的な仕事にしてしまった理由
なんじゃないかなぁ...と思うんだよねぇ...
Re:ソースコードを書くのは簡単なお仕事です。 (スコア:1)
Re: (スコア:0)
設計書なんて無しで、可読性の高いコードを設計者が自分でさらっと書いてしまうのが一番効率が良い。
メンテナンス性の高いプログラムに必要なのは、可読性が高く効率の良いコードで、そこに設計書など必要はない。
無駄な書面を残すことは、二重三重の管理コストが嵩むだけでしかない。
Re:ソースコードを書くのは簡単なお仕事です。 (スコア:1)
＞ 設計書なんて無しで、可読性の高いコードを設計者が自分でさらっと書いてしまうのが一番効率が良い。
問題はですね。そのレベルの開発者はほとんど居ないということです。
たいていの人は、良くてトランザクションスクリプト、悪けりゃスパゲティコードしか書けません（実体験より）。
ただし、そのレベルの人は設計書書かせても同レベルの品質です（地獄
Re: (スコア:0)
> コーディング単体なんて半分単純作業
しかし、その残りの半分が8割以上を占めるからね・・
折れ線グラフを描画するにも
まず仕様は「こういう夢いっぱいのキレイめの映(ば)える見た目のやつを描画する」と来るだろ
設計はせいぜい「この汎用ライブラリを使う」で、完成予想図をExcelででっち上げて終わるだろ
汎用ライブラリが対応していない、カスタマイズが必要な部分はコーダーに依存
細かすぎて伝わらない技術要素はコーダーが調べてくれ、てなもんや
その通り (スコア:0)
・顧客からの要求仕様書に抜けがない
・プロジェクトの詳細仕様書について客先からもOKが出ている
・モジュールの詳細仕様書、テスト仕様書も社内レビューが済んでいて完璧
・TDDに基づきテストコードはコードを書く人とは別のベテランが既に作成済、レビュー済
・当然途中で仕様変更なんて入ってくる事はない
・使う言語・フレームワークは普段から使い慣れたものだ
うん、コードを書くなんて単純作業でいいかな?
もちろんデバッグ作業が単純作業となるかどうかは知らん。
Re: (スコア:0)
まあ、「屏風から出せや」ってなりそうだなｗ
Re: (スコア:0)
発注側「屏風から出せや！」
おまえら「(なんで発注側に言われなあかんねん)」
金融系の「詳細仕様」まで作ってある場合は単純作業かも (スコア:0)
金融系システムとかでは、「詳細仕様」まで作られており、プログラマがやることは詳細仕様に沿ってコードを書くこと
（詳細仕様をつくるエンジニアがプログラムのことを考えて詳細仕様を作るので、本来のプログラマの仕事が減ってる）
ところが、金融系以外の多くのシステムでは、たとえ名前に「詳細仕様」とあっても、金融系の詳細仕様とは違い、
プログラマが自分であれこれ考えないといけない場合が多いのでプログラマの仕事は単純作業ではなく、
プログラマも仕様作成に関与したり、「仕様はコードを見ろ」みたいな部分も数多くある
Re:金融系の「詳細仕様」まで作ってある場合は単純作業かも (スコア:1)
つまり、そのレベルの完璧な詳細仕様を書くのがヤマト運輸の目指す「内製」だ!
…と言ってるのかと思ったら、訂正されたところを見ると、そうじゃないんでしょうね。
DX担当役員にしてこのレベル…まあ、DXのメインはDでなくてXなんだろうけど…
Re:金融系の「詳細仕様」まで作ってある場合は単純作業かも (スコア:2)
> DXのメインはDでなくてXなんだろうけど…
ヤマト運輸の場合、X は transformation じゃなくて transportation でしょうね。
Re: (スコア:0)
金融系以外でも、20年前のSIerではそんな詳細設計書書かされました。
まあ設計書書くのもプログラマーだったんで、みんなプログラミングしてから設計書に起こすんですが…。
もっと前の時代だと、開発環境的な理由でコーディング自体が一苦労だったと言うので、その頃の文化の残りなんでしょうねぇ。
Re: (スコア:0)
開発用コンピュータの価格・台数と、人件費やプログラマの人数のバランスによって最適なのが変わってくるのでは？
コンピュータが高価で台数も少ない場合、人があらかじめ詳細仕様まで作ってプログラミングコストを抑えるのが最適で、
コンピュータの価格が下がって一人一台開発環境を持つようになると、従来の詳細仕様にあたるのは作らないのが最適なのでは？
gitみたいな集団開発をサポートするシステムによって、さらにその傾向が加速した
Re: (スコア:0)
こんなことやってるから、日本のソフトウェア産業は海外と戦えないんだよな。
Re: (スコア:0)
昔、少しだけ手伝った金融系の仕事も、そんな感じでしたね。
ローカルな変数名までガッチリ決まってました。
Re:金融系の「詳細仕様」まで作ってある場合は単純作業かも (スコア:1)
まあ、システム業界で「金融系」といってまず出てくるのは、
投資金額が大きい商業銀行ですよね。
でもその商業銀行でも、トレーディング部門のシステムなんかは、プログラマがその場のアドリブでコードをガンガン変えたりするので文化が違う。
業界の雰囲気も、銀行、証券、ファンド、カード、消費者金融それぞれでかなり違いますからね（短資とかは見たことないから知らない）
単純なお仕事 (スコア:0)
指示された通りにキーボードを押すだけの簡単なお仕事です
Re: (スコア:0)
まあAIにも出来るしね
Re: (スコア:0)
キーボードを放すことも必要ですよ。
Re:単純なお仕事 (スコア:2)
キーボード上のキーを押したり放したりするのであって、
キーボードを押しても意味はないのでは？
（プログラマー的な指摘）
そりゃまぁ…… (スコア:0)
単純純粋にコードを書くという点だけに注目すれば、キーボート叩くだけの簡単単純作業でしょうけどねぇ……。
GitHubとか言い出しているあたり「その辺のコードを適当にコピペしまくれば簡単だろ」ぐらいに思ってそう。
簡単に外注とか言ってるけど、機密保持等のリスクをどう考えているのやら。
そんな言い分通すなら、貴方がたの仕事も「荷物を運ぶだけの簡単なお仕事」になっちゃう訳だけど……って、あぁ。業務委託ドライバー使っているのと同じ発想なのか。
単純作業 (スコア:0)
執行役員のことかな
Re:単純作業 (スコア:1)
執行役員は通常商法上の取締役ではないですが、
従業員（雇用契約）ではなく委任契約というケースもあります。
委員会等設置会社など、取締役のときに過半数が社外取締役になることも考えると、
「いわゆる役員」のイメージに近いのは、取締役ではなくむしろ委任契約の
執行役員なんじゃないか、という気もします。
昔なら (スコア:0)
他所でも書いたが、大昔の上級SE, 中級SE, 下級SE, プログラマ(コーダ), パンチャみたいに分かれてた頃なら単純作業だったかもしれない。
プログラマの仕事って下級SEの書いたフローチャートをコード化するだけだったし。
なのでCAEだとかでフローチャートからコード吐く仕組み作りに熱心な時期あったよね。1992年くらいだったかな。
この頃だと下級SEとプログラマの区別無くなってたけど。
各SI企業毎に独自のフローチャート形式もあったよね。
君らさぁ (スコア:0)
顔真っ赤にして怒るくらいメディアに出られるようになって見返してやんなよ。
Re: (スコア:0)
よくわからんが・・・
まず、見返してやるための前提となってる「顔真っ赤にして怒るくらいメディアに出られるようになる」の部分がマジで意味不明なんだけど、これどういう状態を指すの？
そうなってる人を例示する形でいいから教えて下さい。
Re: (スコア:0)
でも「物流なんてものを運ぶだけの単純作業」って言ったら、彼らも顔を真っ赤にして怒るだろうから。
ヤマト運輸のシステム会社 (スコア:0)
常に求人出し続けてる常連企業だったな
単純作業しかなくて定着率が悪かったのかな
Re: (スコア:0)
前の会社で、自社でやってた在庫管理と出荷業務をヤマトにアウトソーシングしたら初日からトラブル続きで、様子を見に行ったらヤマトのSEは終始キレっぱなしで話もしにくく「常識無いのかこいつ」という印象しか残ってないな。
なんか知らんけどストレス溜まる職場なのかもしれん。（営業担当はまともだった）
謝罪風謝罪 (スコア:0)
> しかし、記事化に当たり一部の発言内容が正確に伝わらず、結果的に誤解を与えてしまった」と説明。
正確に伝わらなかっただけ。あくまで誤解。
つまり、読み取り方の問題とな？
社内の広報に正確に伝わらずその結果、の意図だと述べた所で、それならそれで誤解を与えてしまったと弁明してるのは社内広報ってことになるな
「そんなふうに考えていた時期が (スコア:0)
国にもありました。」 [wikipedia.org]
,j;;;;;j,. ---一､ ｀ ―--‐､_ l;;;;;;
｛;;;;;;ゝ T辷iﾌ i f'辷jァ !i;;;;;
ヾ;;;ﾊ ﾉ .::!lﾘ;;rﾞ
`Z;i 〈.,_..,. ﾉ;;;;;;;;>
,;ぇﾊ、 ､_,.ｰ-､_',. ,ｆﾞ: Y;;f
~''戈ヽ ｀二´ r'´:::. `!
Re: (スコア:0)
そういやソフトウェア危機って聞いたことあるけど、
今見ると何をやってんだ？というという酷さだな。
しかも令和の現在でも非常に既視感の強さ。
量子計算やAIで全く同じ発想で同じことやっているという
官僚の方こそアウトソーシングすべきなのかもな
クロネコヤマトのアプリ(おふとぴ) (スコア:0)
DX推進担当の管理範囲かどうかは知らんが、都度パスワードの入力を要求してきて、
かつ、パスワード管理アプリも反応しないのでどうにも不便なんだわ。
「☑この端末では以降パスワードの入力を要求しない」と言うオプションを用意するとか、
OSのサポートする認証方式を利用するとかのもうちっとスマートな方法にしてくれんかの。
どういう人達が怒ってるのかよくわからないけど (スコア:0)
業務システムの末端のPGなんて基本的に単純労働だよ。
業務要件、仕様でガチガチに固まった内容をコーディングするだけで
単純ロジックの集合なんだから別に高度な言語理解とか業務知識とか必要無いし。
そりゃその中でもより専門的キャリアと知識を持って替え難い存在はいるけど、
文脈的にそういう人達について言及してるわけじゃないでしょ。
こう言うと業務や仕様が固まってないところを俺たちが良きに吸収してやってんだとか言う人もいるだろうけど
それは属してるお仕事や案件の性質の問題であって、この話には関係ない。
Re:どういう人達が怒ってるのかよくわからないけど (スコア:1)
> でも今のIDXはITで何が出来るか考えて実装できる人が必要だから
いまのデータベースはインデックス一つ作るのにもそんな能力が必要なのか……
Re:どういう人達が怒ってるのかよくわからないけど (スコア:1)
// Indexの作りはデータベースの何が重要で速度がどれで、というのがわかってないとできないでしょ?
「実行可能なメンバー」ねぇ… (スコア:0)
アーキテクチャのデザインやGitHubを活用したソースコードのガバナンス・標準化が実行可能なメンバーによるコアな開発は内製化しつつ
能力のことを言ってるのか、権限のことを言ってるのか…
問題の本質は、解ってない人が上にいた時大変だということだけどそれはどこにでも湧くのだろう (スコア:0)
こういう「ひと」が上の人だったりすると
大変だなぁ。という感想しか出ない。
トコロテンみたいに、押せば結果が出せるだろう、みたいな思考持ってると
更に厄介。(という言は誰の言葉だったかな)
Re:馬鹿は死ねばいいのに (スコア:1)
売上規模に対するシステム規模では、ヤマトは大きい方のはず。
逆に、商社・製薬あたりが売上に対してシステムが小さいイメージ。