サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
WWDC24
zenn.dev/339
この記事は、↓の記事の続きです。 前の記事では、個人差に基づいて給与を支払うべきなのかという事にフォーカスを当てていたのですが、この記事では、開発チームがどのようなメカニズムで効果的に機能するかという事を考えていきます。 要約をすると...作業の速さと知の2つの概念を分離した上で、チームにおいては必ずしも個人の作業量だけが貢献ではないことを示し、知がどのように蓄えられるものか、どういった性質を持つかという仮説について述べます。そのような知の蓄積については、個人に還元して考えることにはあまり本質がなく、チームとして機能する状態を作るのが重要で、その意味で作業量(だけ)を全てとする"成果主義"では部分最適になってしまう、という事が一つの結論です。この知の蓄積は「森」のメンタルモデルで表現でき、事業やチームを拡大していく場合はどこかで「森」を作るという戦略に切り替えていく必要があります。 という
サブタイトル:「個人差」あるいは「知」と向き合う - 成果と継続、そしてチームについて語りたい記事だった。 この記事では、チームにおける成果と継続の価値について私が考えたことを述べようとしていたのですが、その問題提起の部分の話がかなり膨らんでしまったので問題提起部分だけを分けて書きました。 一応、どういう事を考えているかの概要もこの記事の末尾に書いておきます。 2023/4/18:補足を追記しました。 2023/4/29 とうとう、続きをかきました! 2023/4/30 結論"じみたもの"も書きました。↓ 問題提起:"成果主義"は解か? まず手始めに「他人の10倍仕事ができる人に10倍の給与を支払うべきなのか問題」について考えたいと思います。 様々な人が、プログラマ、あるいはソフトウェアエンジニアの個人の能力には大きな差があると話しています。例えば、ピープルウエアにおいては、コーディングの
まえおき(本題と関係ありません) 最近、エンジニアとビジネスという謎の話題が流行っています。 エンジニアとビジネスということについては、私は次のように思っています。 仕事には役割分担があるので、エンジニアの人は必ずしも利益最適化を考えなくてもよい 下手の考え休むに似たり、餅は餅屋 ただし、自分で考えないとすればそれは委任であって、結論に従う義務がある もし自分で考えたとしても、チームや会社の結論は個人の意見と関係なく是とすべき 法律や道徳的信念に反する場合は別 また、ゼロベースで考えることはしなくても、出た結論について誰かがエンジニアリング観点で再設計・最適化することは実装上必要 ただし、私個人に関しては、プログラムを書くにあたって利益構造を理解しないという事は考えられない 例えば、サービスとしてある機能を作るべきか否かの判断の大きな部分は本質的な利益構造に基づく 技術的負債を返済すべきか
「プログラマー脳 ~優れたプログラマーになるための認知科学に基づくアプローチ」という本がとても売れているようです。タイトルが若干引っかかりつつ、各所で褒める言葉を見かけたので私も購入して一通り読んでみました。 プログラマー脳 ~優れたプログラマーになるための認知科学に基づくアプローチ(amazon) これはめちゃくちゃいい。 私が考えてきた事との類似性、新しい考え方、チーム戦略、全てにおいて示唆がありました。プログラミングに関する書籍としては、これまで読んだ本の中で一番ためになったように感じていて、実際にすぐに行動に反映されるような内容も多々ありました。 そこで、この本から特に感銘を受けた内容と、一部はそこから発展させた私の考えについて述べます。 (ちなみになぜ自分の考えを述べるのかという事については、この本に紹介されている意味波の考え方でその意義を説明できるので、後述します。) この本は
プログラムを使ってある仕様を実現するとき、多くの場合、そこに"唯一の答"はありません。 同じ仕様、機能を実現するコードにも多様性があります。 プログラミングにおいてしばしば問題になるのが、「その様々なコードのうち、どのコードを選んで実装するか?」ということです。 とりあえず機能が実現されるという点においてはどのコードを選んでも同じであっても、その後の保守性や拡張性などにおいて、自分がどんなコードを選んで書くか という事は重要です。 今の時点では正しく動作しているコードであっても、可読性や拡張性などの観点でクソコード、悪いコードなどと揶揄される場面がしばしば見受けられます。クソコードというのはかなり強い言葉で、あまり良い言葉だとは思わないですが、その言葉を発する人からすると、どうしてもそう言いたくなるような問題があるのでしょう。 ところで、同じ労力で悪いコードを避けて実装できるのであれば、そ
恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。(まじで意味不明) いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおk。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。(そのうち消したい) システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま
概要 みなさんは「フロー効率」や「リソース効率」という言葉を聞いたことはありますか? 最近、アジャイル開発やソフトウェア開発の文脈において、「リソース効率よりもフロー効率を重視すべき」といったニュアンスのコメントを見かける場合があります。このコメント自体は必ずしも間違いではないのですが、このコメントをふわっと解釈して、実態と異なる理解や説明が為されているのを見かけます。 そこで、この記事ではそうした誤解がなくなるようにフロー効率について説明をしていきます。 結局何をすればいいのか、端的に言うと フロー効率の概念を踏まえて結局どうすればよいのか?という事ですが、簡単にまとめると以下のようになります。 ソフトウェアはデプロイされた時点から顧客に価値を提供するようになるので、他にしがらみが無ければフロー効率を上げた方がよい アジャイル開発の文脈で、フロー効率とリソース効率は多くの場合トレードオフ
先日、 という記事を書いたところ、思ったよりも反響がありました。その影響があったかは不明ですが、また値オブジェクトについての話題がちょびちょびと発生していました。 そのやり取りの中で、私は未読だった論文が紹介されていて、その論文を読んだことで「このようにすると値オブジェクトに誤解が生じる」という一つのストーリーを認知できたため、どのようにこの論文を読むと誤解が発生するか、という事について説明します。 なお、前回書いた記事も、この記事も、誤りを糾弾したいとか、誤ったから著者が悪であるといった事を主張しているわけではありませんので、改めて記しておきます。この記事では、単純に事実の指摘と修正の提案、およびなぜ文脈や定義を大事にする必要があるのかという事について述べます。 いい加減、値オブジェクトの話題はしつこすぎるのでは?非生産的なのでは?そんな事よりもっと生産的な事をしたら?というご意見もある
「良いコード/悪いコードで学ぶ設計入門」という本がとても売れているようです。私の所属している開発チームでも、何人か購入した人がいたので、私も購入して一通り読んでみました。 結果として、いくつかの考えが整理され、私としてはこの本によって考えが深まり、本を読んで考えた事自体は有意義であったと思いました。ただし一方で、あまり知識がない状態で(自分の中での判断軸が無い状態で)この本を読むと、色々と誤解が生まれるのではないか?という事を感じました。 一つの技術書がこれだけ売れるという事はそんなに多くはない事だと思うので、つまり、 その内容が改善されるとその効果は相対的に大きい という事になります。そこで、私が本を読んでいて思ったことや、この本の内容で正しいこと、現在も賛否両論とされること、事実として認識が間違っているであろうこと、この本で触れられていないが設計において大事なこと、などについてまとめて
Twitterで適当に垂れ流した感想が、(私のTwitter力のなさにより)スレッド分断されて散り散りになっているので、一旦こちらにまとめる。おそらく最も重要なValue Object / Domain Primitiveの混乱については末尾に記載している。 このスクラップは、別途語尾を調整するなどして記事にする予定。その際のタイトルは良いコード/悪いコードで学ぶ設計入門の感想と改善点(仮) 最終的な記事はこちら↓ 良いコード/悪いコードで学ぶ設計入門の感想と注意点 命名スタイルについて いろんな命名が出てくるが、これがオリジナルなのか一般的なのかはもうちょっとあっても良い気がする。ただ、数学書も引用付きで示していなければオリジナルかどうかを厳密に判定する方法はない気がするので、めくじら立てなくても案件かもしれないが。 データクラスについて ストラクチャー(構造体)にやたら否定的な感じを受
※noteにも同じ記事がありますが、Zennの方がユーザ層とあっているかも?と思い書き直しています。 (2021/4の追記) 末尾に重要な追記があるので、追記をよんでください〜 (2022/8/11の追記) 実際に模擬面接活動を見て、対話して思ったことを追記しました はじめに 競技プログラミング界隈で、"怪文書"が流行っています。 この文書の誤読がリトマス試験紙になる... 正しいけど絶望的な状況について、なんだろう、感情を揺り動かされてしまい、その状況をもう少しお互いにわかるようにするための「解説」をするためのものです。とにかく"誤読"というか、相互で見えない立場が気になってしまった。それに尽きます。 はじめに、どういうスタンスで自分がこの記事を書いているか?という事を示しておきます。 chokudai氏は、頂上じゃないところにも価値があるという事をきちんと思っていて、「(当人を含めて)
このページを最初にブックマークしてみませんか?
『さざんかぬふさんの記事一覧』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く