画像の機械学習が劣化する理由 - Qiita
前書き 注意：ここに書いていることは2020年代としては、古すぎる見解になっている。 近年の自己教師あり学習の大幅な進展で、ここで述べているようなアプローチは大幅に古めかしいものになっている。 ・自己教師あり学習の進展は、画像認識タスクに対する共通のbackbone を作り出しており、後段で個々の画像認識タスクに対するfine-tuningをするアプローチに変わってきている。 ・そのため、ラベル付きの限られたデータで特徴量の抽出をしていたのが、自己教師あり学習に基づく特徴量の抽出になっている。 ・各人、自己教師あり学習について調べることをお勧めする。 主旨 単純に学習データを追加するだけでは学習が改善しないことがある。そのような場合へのヒントを著者の限られた経験の中から記述する。 はじめに 画像認識の機械学習を改善するためにはデータを追加すればよい。 そう思っている人が大半だろう。 ただ、
モグラたたき開発になる理由 - Qiita
モグラたたき開発になる理由 モグラたたき開発を卒業しようの一部として書いていましたが、項目が増えてきたので 別記事に独立させました。 これらは、ほとんどが推測です。 某銀行の次期システムとか、受注したが開発できすに中断した官公庁の案件とか、携帯電話開発の事例 その他もろもろの不幸な事例を元に推測で書いています。まるで自分のプロジェクトとのようだと思われる方がいらしても、他人の空似です。 チームとしての共通の目標を成し遂げようという意識が低下している。 ユーザー視点の欠落 セクショナリズムの蔓延、「それは自分の知ったことじゃない」 「今まで失敗しているから、次も失敗するに決まっているよ。だから今更何をしても無駄だ」というあきらめモードになっている。 開発体制がゼネコン方式になっていると、開発の上位側と下位側で共通の目的を成し遂げようとするチームという意識が形成されにくい。 チームがチームとし
若手エンジニアを不幸にしないための開発の「べからず」集 組織運営編 - Qiita
若手エンジニアを不幸にしないための開発の「べからず」集が 長くなりすぎたので、組織運営に関する部分を別項目として独立させました。 ここに書いてあることを、組織運営を行っているリーダー以上の方は冷静に読んで欲しい。 組織運営に失敗すると、 優秀なエンジニアがいてもどうしようもないほどに開発速度の低下を引きおこす。 資金を投入して外部に開発を委託したものが、まったく使い物にならないことになる。 対外的な信頼をぶち壊しにすることができる。 優秀なエンジニアの心を、組織の開発目標から引き離してしまうことができる。 リーダーでない人もリーダーではないなりに組織運営に関わっている。 組織の運営に失敗して、成果の達成ができなければ不幸である。 1人1人のエンジニアの成長を実現できなければ不幸である。 不幸にしないための「べからず」を書いてみました。 自分たちの強みを何におくかを考えない。 仕事として開発
優秀な技術者を追い出してしまう方法 - Qiita
若手エンジニアを不幸にしないための開発の「べからず」集 組織運営編から記事を独立させました。 優秀な技術者ほど辞めてしまいやすいのは、多くの会社に共通していることです。 この文章では、どうして優秀な技術者が辞めていってしまうのか、その理由を探るとともに、そうならないようにするための対処方法を少しずつ書き足していきたいと思っています。 マネジャーのみなさんへの前書き 会社の資産であるソースコードはきちんと管理されてますか？ 「きちんと金庫にしまってある」ではありません。 開発が進みやすく、今のソースコードはどのように品質が保たれているのかがわかるようになって 管理されてますか。 ソフトウェアの開発などで生じている課題は、どのように管理されていますか。 「去年の△月ごろに問題になっていたあの件は、結局どうなったのかい。」 「担当していた○○さんがだったら知っているんですけれども、もうやめちゃい
若手エンジニアを不幸にしないための開発の「べからず」集 - Qiita
若手エンジニアを不幸にしないための開発の「べからず」集を書いてみました。 「若手エンジニアを不幸にしないため」とは書いていますが、若手に限った内容ではありません。 いろんな開発の「べからず」のために不幸になるのは、とりわけ若手が多いということを意識したためだと思ったからです。 ・若手には、方針の決定権がない。 ・若手は、組織の中で道具のように扱われてしまう場合がある。 ・(今の）若手は、将来も働き続けるための力を付けるための組織内での教育が、（昔ほど）なされなくなってきている。 ・コスト意識が乏しいので必要性が乏しいことについてまで残業前提の仕事のスケジュールを組織がたてることが多い。（その分野の理論を知っていれば自明のことを実験で証明することを要求されるのは苦痛である。） 設計指針の「べからず」 何ができれば十分かを明確にしない 開発目標は、何ができれば十分なのかを明確にしないまま、追加
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
