はてなブックマーク

この記事は、以前書いた記事知的な仕事の量と深さ - 10倍の成果とIQ、執念、知識、認知で説明した「ダブルバインド(ではないが、認知の中でダブルバインドとして捉えてしまう)」の部分に関する、メカニズムと解決方法の少し詳しい説明です。 事例 これは架空の事例です。 普段、Aさんは上司に対して敬意を持って作業をしていますが、うまく成果を上げることができません。Aさんは足を引っ張っているという自己認識をしており、上司の時間をあまり使いたくありません。それでも、上司からは「わからないことがあったら、すぐに質問をしろ」と言われてしまいます。 そこで質問をしようと思うのですが、上司の時間を無駄にしたくありませんし、質問を具体的にまとめてから質問しようと努力をしているつもりです。わからないことを質問しようとしているので、当然どのように聞けばよいかもわからず、かなり時間を使ってなんとか質問をまとめたつもり

概要 この記事では、 アンラーンの重要性: システム開発・教育においてアンラーンがとても重要であること 具体的なアンラーンの方法、技術 教育とはなにか: 教育の重要な目的は記号接地であり、そのために積極的にアンラーンを促す必要もあること についてシステム開発の文脈でDDDの用語を交えて説明します。と言っても深くDDDに依存しているわけではなく、システム開発全般・ひいては認知を合わせる必要のある仕事全般について共通することの説明になっています。 DDDに関連する部分については、『関数型ドメインモデリング ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう』という本から一部引用します。この本には開発者の誤解によってどのようにして認知のズレが生じるか、またそれをどうやって修正するかという具体的な場面が示されており、この具体例から「アンラーンがいつ必要になり、具体的にどう作用するのか」「ア

次の記事が最近公開されたので、読んでみました。 結論としては、例えば同著者の「良いコード/悪いコードで学ぶ設計入門」という書籍と比較すると、だいぶ受け入れやすい主張になっていると感じました。(以前の書籍についてのコメント記事へのリンク) ところで、私は「良いコード」についての議論や指摘や検討を積極的にやったほうがよいと思っていますが、主に「消耗しない」という観点でこの記事についていくつかの構造理解やテクニックの部分で補足できそうだったので、以下補足していきます。 ざっくりとした主張でいうと、 トレードオフに見える部分は学習・教育で解決できるケースも多くある 品質特性への還元が難しいがコードの良し悪しを定める概念がある Webアプリにおいても再利用性は必要だし、モバイルアプリでも再利用性を求めて失敗することがある 再利用性というよりは、現実に即した概念の線をどこで引くかのバランスを大事にする

あらすじ 徹夜明けの深夜テンションで書いた怪文書が思いの外多くの人の目に止まったようなので、実際にどういうコードが汚くて、どう改善できるのか、みたいな事を簡単にまとめてみる。 モジュール・クラス・変数の名前がおかしい 名前から全く想定できない作用がある、名前が嘘 例えば、validateForm()という名前のメソッドを実行すると、決済処理が完了してレシートが印字されるとケース。おまえはvalidationではない。でもvalidationなので、DBには保存しない。 (何を言っているんだ???ちなみに、外部APIやデバイスのコールはこのメソッドの中でできてしまうが、フレームワーク制約でDB更新はここではできない、みたいな状況でそういう事が起こる) const blue = "#ff0000"、おまえは青色ではない。真っ赤なウソだ。 これは、しばしば致命的なバグにつながる。既存のblueを

汚いコードはよくない (2024年9月22日 追記:続編を具体的にかきました!) コードを書くと、コードは増える プログラムは、ソースコードと呼ばれる文字列を記述する事で作成されます。このことを、単にプログラムを書く、コードを書く、などと言ったりします。 ほとんどの場合、プログラムを書くときには、その目的があります。 なにかの目的を達成するために、ソースコードと呼ばれる文字列を記述します。 この記述方法にはいろいろなものがあり、同じ目的を達成するにも無数の方法が存在します。 どの方法を選ぶかは作者に任されている、という言い方もできます。 ところで、ソースコードを記述していき、プログラムで実現できる事が細かくなるにつれて、文字の数はだんだんと増えていきます。 コードの増え方にもいろいろある この文字が増えていく様子を比喩的に表現することを考えます。例えば書類を積み上げることや、積み木を積み上げ

知的な仕事に従事する人の成果には、個人差があります。 その個人差は、時に何十倍という差になります。 といっても、個人で何十倍という想像はしにくいかもしれません。後ほど、本文中で具体的に失敗ケースの流れを列挙しますが、ここでは話を簡単にするために集団での仕事を想像してみます。 何十億、何百億と費用をかけて、結果的に「使えないシステム」を作った、あるいは完成しなかったという事例を想像しましょう。このような事例は実際にいくつかあり、裁判にもなっています。そのようなプロジェクトの成果がほぼゼロとすれば、これらの効率はとんでもなく低く、効率を比較すると何十倍・何百倍では済まない事もあるでしょう。これは「結果的なもの」あるいは「プロジェクトの問題」かもしれませんが、しかし確実に個人の成果の"合計"には差があるということです。 では、知的な仕事において、なぜこのような成果の差が生まれるのか。この差をどう

あるサービスがローンチから5年経過し、10万行のソースコード、開発メンバー50名の体制でメンテする、という話をツイッターで見かけました。ソースコードには、神クラスが含まれるとか、含まれないとか。 ソースコードの桁を間違えちゃったのかな、と思うのですが、10万行・100万行の場合について、それぞれ私だったらどういう戦略で修正するか、を考えてみます。この戦略は、自分がメンバークラスでもリーダークラスでも有効です。 前提:恵まれたビジネス このサービスには、50名でメンテする価値があるという事になります。一般論として、5年経過したサービスを50名体制で開発をするとしたら、それは損切りをクリアして50名でペイすると判断をされて開発しているということなので、そのサービスが生み出す売上はそこそこの額であると考えられます。 世の中には開発だけで成立するサービスもあると思いますが、神クラスが出来ているとか

私が個人的に0→1や1→10のフェーズで知っていて得をした(と感じた)ことをまとめます。 なんかひたすらMPと連呼する変なおじさんになってしまった 精神的・感情的な疲弊をさける、MPを大事にする 0→1や1→10で結果に大きく影響する支配的な要素として、"体力"ないし"スタミナ"と呼ばれるような、行動力的な要素があります。しかし、この行動力の本質というのは、私が思うには、筋力とか身体的な体力(?)というよりは、精神力的なものです。つまり、主観的に楽しければ/充実していれば(そして若ければ?)、まあ体力の限界が来ても寝たら復活できるのですが、主観的に悩み事が多かったり、ハードな判断あるいはハードでないけど微妙に難しい判断みたいなものを大量にやっていると、精神力みたいなものが枯渇してすぐに動けなくなります。 組織が整っていない場合、言い換えると定型業務が決まりきっていない場合、あらゆる物事につ

この記事は、↓の記事の続きです。 前の記事では、個人差に基づいて給与を支払うべきなのかという事にフォーカスを当てていたのですが、この記事では、開発チームがどのようなメカニズムで効果的に機能するかという事を考えていきます。 要約をすると...作業の速さと知の2つの概念を分離した上で、チームにおいては必ずしも個人の作業量だけが貢献ではないことを示し、知がどのように蓄えられるものか、どういった性質を持つかという仮説について述べます。そのような知の蓄積については、個人に還元して考えることにはあまり本質がなく、チームとして機能する状態を作るのが重要で、その意味で作業量(だけ)を全てとする"成果主義"では部分最適になってしまう、という事が一つの結論です。この知の蓄積は「森」のメンタルモデルで表現でき、事業やチームを拡大していく場合はどこかで「森」を作るという戦略に切り替えていく必要があります。 という

サブタイトル:「個人差」あるいは「知」と向き合う - 成果と継続、そしてチームについて語りたい記事だった。 この記事では、チームにおける成果と継続の価値について私が考えたことを述べようとしていたのですが、その問題提起の部分の話がかなり膨らんでしまったので問題提起部分だけを分けて書きました。 一応、どういう事を考えているかの概要もこの記事の末尾に書いておきます。 2024年7月7日 10倍、という部分の構造について掘り下げた記事をかきました! 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氏は、頂上じゃないところにも価値があるという事をきちんと思っていて、「(当人を含めて)