『日本のITの未来を担うSES、あるいはプロダクトオーナーの重責について - GoTheDistance』へのコメント
スクラムの教科書的にはPOは顧客じゃないほうがいいって話じゃなかったっけ。/ https://www.ryuzee.com/contents/blog/7143 で書かれてるような印象がある。/ ソース https://scruminc.jp/training/owner/ POは顧客でない想定に読める。 <blockquote class="hatena-bookmark-comment"><a class="comment-info" href="https://b.hatena.ne.jp/entry/4683781687071625954/comment/tpircs" data-user-id="tpircs" data-entry-url="https://b.hatena.ne.jp/entry/s/gothedistance.hatenadiary.jp/entry/202
日本のITの未来を担うSES、あるいはプロダクトオーナーの重責について - GoTheDistance
先日、アジャイル開発を推進するために大変有意義な資料が公開されています。ESMの木下さんといえば、アジャイル開発の現場にずっと携わってきた著名な方です。 note.com でも、令和2年にこちらの記事が何百もはてブされるのも、おいおいマジかよって思う所がありまして。今までどうやってたのだろうか...。準委任(時間単位のチャージ)以外の選択肢がないやり方だと思っていたので。請負でアジャイルを取りに入れるわけないですよね。一般的なSIerさんでは、どういう理解をされて、どう取り組んで来たのだろう。 アジャイルと受託開発の相性は最悪では ムービング・ターゲットを請負で追いかける自傷行為を誰がやるんだって話と、要件固めて下請けに出せないから誰もやりたがらないよねという話を書き散らしています。 10年前に書いた記事の内容がまだ通用してしまうのも、自分でも少し寂しい気持ちがあります。 gothedis
エンジニア業界を少し外から眺めて - Qiita
Help us understand the problem. What is going on with this article? お断り ここに書いたことは、私が所属する会社とは何の関係もない個人的な考えです。 特定の業種には不快感を与えるかもしれませんが、日本のエンジニアが楽しくモノづくりができるようになる未来を願っているだけで、他意はありません。 あるqiita記事で、「格上と格下」という技術者の類型について熱い戦いが繰り広げられていました。 私がそういうモノに参加すると炎上することはわかっていたので、参加しないほうが良かったのかもしれませんが、ついつい参加してやはり沢山の方に敵認定されてしまったようです。 言い訳というわけではありませんが、私の考え方について書いておきたいと思います。 業界の病 日本のIT業界は病にかかっている。そのことは、どのエンジニアもうすうす気づいているの
プログラム開発者格差の話をしよう - Qiita
Help us understand the problem. What is going on with this article? 先日、とある記事が削除された。 数時間の寿命だったのでご存じない方もいると思うので、つかみだけ紹介しよう。 簡単に言うと、Unityの有志開発ライブラリ、UniRxについての記事だ。 企業プロジェクトでUniRxを気軽に採用すると地獄だぞ、という内容だった。 そしてこの記事が削除された理由は、コメント欄に 「それ全部あんたのチームの問題であって、UniRxの問題ではなくない？」 という趣旨の反論、批判が発生したからである。 彼らの言い分はこうだ。 技術力が低い人間が高等な武器を手にしても自爆スイッチ押すだけだ、と。 なので、技術力を身に着けてから着手すべきだし、追加人員も教育してから実戦投入しろと。 ■ さて、この発言そのものは真理である。 チームの全員が
オブジェクト指向プログラミングの現在・過去・未来
2. 自己紹介 2019/11/23 2 増田 亨 (@masuda220) 最近の仕事：JavaとSQLでプログラミング（したい） 今日は、この本の背景にある オブジェクト指向プログラミングの 基本的な考え方を説明します 仕事レベルで使った言語 Z80アセンブラ, C, PL/SQL, C++, COBOL, FORTRAN, BASIC, Lisp, Prolog, Smalltalk, awk, Perl, PHP, Ruby, Python, Groovy, Objective-C, JavaScript … 試したことのある言語 Haskell, OCaml, Schema, Scala, Kotlin, Go, Rust, IO, TypeScript, … 面白いと思っている言語 Haskell, Prolog, Rust
未来のプログラミングについて再考（機械学習とソフトウェア2.0、配管工プログラマ、オープンソースでは十分でない？） - YAMDAS現更新履歴
昨年のエントリだが、その後現在までマイク・ルキダス（Mike Loukides、O'Reilly Media のコンテンツ戦略担当副社長）の文章を追って、これを書いていた当時ワタシが理解していなかった文脈、そしてそれに対応するニュースや問題意識が見えてきたところもあるのでつらつらと書いておきたい。 こちらは2019年末に、マイク・ルキダスが O'Reilly Media のチーフ・データサイエンティストである Ben Lorica と共に書いたエントリだが、2020年3月に開催される O'Reilly Strata Data & AI Conference に向けた露払いである。 ワタシはタイトルだけ見て、「ソフトウェア2.0？ 今さら〇〇2.0は古いだろー」と思ったのだが、これは Tesla で AI 部門長を務める機械学習の専門家 Andrej Karpathy が2017年11月に公
メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
だめなITベンダー・SIerの行動特性：ITソリューション塾：オルタナティブ・ブログ
もし、あなたが、次のようなことをしているのであれば、これは大いに反省すべきだ。 自分たちの「できること」でしか解決策を示そうとしない。 機能や性能については説明できるが経営や事業の成果にどのような貢献ができるのか説明できない。 これからのテクノロジーやその可能性について分かりやすく説明できない。 お客様が新しい方法論や見積を求めても旧来のやり方で提案しようとする。 新しい方法論やテクノロジーの適用を求めると保証できない、実績がない、時期尚早などのネガティブ・ワードで翻意を迫る。 やがて、お客様から愛想を尽かされてしまうだろう。 工数の需要がなくなるわけではない。ただ、作業工数に応じた労働力に対価を支払うというやり方は、自動化ツールやクラウド・サービスとの競合や人口の減少と相まって、そこでの収益の拡大を期待することができなくなる。 また、工数需要そのものの内容が変わる。例えば、「コードを書く
システムの複雑性と戦う方法 - CARTA TECH BLOG
こんにちは。Zucksでエンジニアをやっています@karahiyo_nです。 先日社内向けに「Zucksで働き学んだ成果に繋がるプラクティス」という発表を行いました。今回はその一部を紹介したいと思います。 発表では6年間でシステム構成がどう変わってきたのかと実際にやってきたタスクを紹介しつつ より妥当な意思決定をするために より早く価値を提供できるように システムの複雑性と戦う方法 などいくつかプラクティスを紹介しました。 今回はその中のひとつ「システムの複雑性と戦う方法」について書きたいと思います。 対象のシステム像 元の発表ではZucksのシステムを取り上げて解説したのですが、ここでは次のようなシステムをイメージしてください。 非常に高いサービスレベルが求められるシステム(例えばAmazon Compute SLA相当) 低レイテンシ、高トラフィック(で、さらに増加傾向) 機能要望は尽
Javaプロジェクトにおけるリリース周りの手法あれこれ - Kengo's blog
考慮する点 成果物のデプロイ ビルドの成果物（artifct）をアップロードすること。アップロードと公開は分けて考えることに注意。デプロイ先にはいくつか候補がある： GitHub Packages (旧GitHub Package Registry) Maven Central Repository Docker HubなどのDocker Registry GitHub Packagesはコンテナも.jarもまとめて置けるが、コミュニティ標準の場所ではないので利用する際にひと手間必要になる。プライベートプロジェクトの場合は積極利用することになりそう。FOSSなら基本的にMaven Centralに置くことになる*1。プロジェクトによっては.jarファイルとしてではなくコンテナとしてデプロイすることもあるだろう。 リリースノートの作成 CHANGELOG.mdやsrc/site以下のファイル
プログラマーテストの原則 by Kent Beck
チョコレート対バニラTDD対BDD。このテストツール対あのテストツール。テストビフォー対テストアフター対これは動くから俺を信じろ。ある時期から、こうした詳細に関する議論には飽きてしまった。もっと原則について議論したい。 詳細に関する議論はなかなか結論に至らずに、話が行ったり来たりする。チョコレート対バニラ。チョコレート。バニラ。チョコレート。バニラ。 詳細の議論に負けを認めさせられるようなことがあっても、その譲歩は絶対的なものではない。私の状況がチョコレートを勧めているのに、私にバニラを食べさせてくれと言えるだろうか？ これでは埒が明かない。 原則一方、原則は議論を生み出す基盤になる。原則には賛成しても状況が違っているのなら、答えは違ってくるかもしれないが、そこで論争になることはない。原則が、異なる状況における異なる答えを生み出したのである。 詳細で論争するよりも、原則で論争したほうが生産
ノンプログラミングで大規模システムを開発可能、ラクラスがフレームワーク「SQN」を発表
ノンプログラミングで大規模システムを開発可能、ラクラスがフレームワーク「SQN」を発表：SQNで開発した「ラクラス人事クラウドサービス」の販売も開始 ラクラスは、プログラミングを必要とせずに大規模情報システムを開発できるフレームワーク「SQN」を開発した。クラス図やフローチャート、各タスクに対するデータ操作をそれぞれ定義することで、所望の処理を実行させる。 ラクラスは2018年5月10日、プログラミングを必要とせずに大規模情報システムを開発できるフレームワーク「SQN」を開発したと発表した。同時に、同フレームワークを用いて開発した「ラクラス人事クラウドサービス」の販売も開始した。SQNは、ラテン語の「Sine Qua Non」（シン・クア・ノン）の頭文字をとったもので、「必要不可欠なもの」を意味する。 SQNでは、データ構造を定義したクラス図や、業務プロセスを定義したアクティビティー図（フ
『希薄化したTDD、プロダクトの成長のために必要なものは？〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （６）』へのコメント
テクノロジー 希薄化したTDD、プロダクトの成長のために必要なものは？〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （６）
限られた裁量の中で新規プロダクトを最短リリースした、という話 | アピール | 未来の教育を作る人のマガジン
Mobile Developer｜羽田 健太郎 新卒でヤフー株式会社に入社し、インフラのオペレーション改善や、iOSアプリ開発に従事。プライベートではハッカソンに参加したり、Go言語でWebサービス開発をしているマルチプレイヤー。2016年RareJobで唯一のMobile Developerとして入社し、ネイティブアプリケーション(iOS/Android)を担当。WebRTC技術を活用したサービス化のエンジニア責任者として、日本フィリピンを横断し、ブロダクト企画から開発、運用まで担っている。 降って湧いた大きな裁量 「羽田くん、Skypeなくしてよ」 月一の上長とのMTGでなんとなく言われたその一言。 しかも「プロジェクト化は、今のとこないんだけど。」と仰る。え？1人？？？ 最初はとんちかと思って、 「iPhoneで屏風にskype出してVRでなんとかするアプリ」を作ろうと思っていたが、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニア業界を少し外から眺めて - Qiita
プログラム開発者格差の話をしよう - Qiita
（採用担当者向け）エンジニア採用をする上での基礎知識 / recruting_engineer_basic
『ドキュメントを残さない』へのコメント
『Microservices Maturity Model on Rails』へのコメント
正しく失敗しながら進むプロダクト開発/railsdm2018
