valid,invalid

関心を持てる事柄について

人間をリソースと呼ぶことの何が問題なのか

かねてより人間、とりわけ労働者や従業員をリソースと呼ぶことについて批判的な意見を聞くことがあった。

加えて、これらの主張に対するカウンターを見たこともある。「問題の所在が不明瞭」「情緒的な意見のみで代替が示されない」「人材を人財と書くような言葉遊びでは」等々。俗っぽく言えばここにあるのは、「モノ扱いしないでほしい」vs「とは言っても経営管理上はヒト・モノ・カネ・情報はリソースでしょ」という対立である。

この件について「人間をリソースと呼ぶことの問題についてアカデミックな見解・理論はあるのか」「人間をリソースと呼ぶことは、別の問題から来る結果なのか」が気になり調べてみたところ、経営管理における実利上の問題との接続を見出すことができた。*1

結論: 忙しい人のためのまとめ

3行まとめ。

  • 人間をリソースと呼ぶことへの拒否を「受け手の情緒的な問題だ」とは言い切るのは容易いが、人的資源管理を通じた経営管理上の課題を見落とす可能性がある。
  • なぜなら、まさにその「情緒や感情を持って行動する主体であること、言い換えれば"人間性"こそが価値を生む」と考えるのが人的資源管理の理念であり、労働力の側面に着目した文脈でリソースと呼称する場合、この理念に反した経営管理が行われている兆候でありうる。
  • 人的資源管理の理念に反するというのは単なる倫理や信条の問題ではなく、間接的あるいは直接的に組織文化・企業価値の毀損に繋がる可能性がある。

各論の実証可能性はさておき、どのように上記の主張に筋を通せるのかを以下に記述していく。

人的資源をリソースと呼ぶことの歴史

そもそも人間をリソースと表現するのはどこから始まったのか。その由来からネガティブに捉えられていたのだろうか。

人的資源管理論の始まり

人的資源管理論と組織文化の関係性」によれば、人的資源管理論は20世紀中盤にアメリカで起きた企業経営の問題に由来するという。労働生産性の低下の問題と、人間性が毀損される労働疎外*2の問題に端を発した社会運動が勃興していた当時*3、この問題は人事労務管理の領域で解決されなければならないとされ、Human Resource Management (HRM)が生まれた。この論は1980年代以降ヨーロッパや日本にも伝わり、日本には人的資源管理という訳語で定着した。*4

人間をリソースと表現したはしりと思われる人的資源管理論においては、前時代が毀損した人間性の回復を目的としており、リソースという呼称もモノ扱いするといった意味合いは感じられない。*5

人的資源管理論の有効実践の前提となる理念

人的資源管理はQuality of Working Lifeの話に閉じるものではなく、企業経営を支える有効的実践、競争優位性の創出も目的としている。その実践には以下の2つの管理理念を基礎とする。(「人的資源管理論と組織文化の関係性」)

  1. 経済的資源としての人間重視
  2. 人間的存在としての人間重視

加えて、人間はモノ・カネ・情報とは絶対的に異なる特性を持つことを前提とする。

  1. 人間はモノ・カネ・情報を活用する主体であり、経済活動における根源的に重要な存在である
  2. 人間は高度な思考をする主体であり、感情があり、自由で自律的な行動を求める
  3. (2)の特性があることから、どのような状況・環境でも機能する決定的なマネジメント手法が生まれることはありえない

2つの理念を逸脱したり、人間の資源特性を誤って捉えることは経済的にもネガティブに働くとしており、前時代を克服しようとする気概以上の"強さ"を感じる。

ドラッカーと人的資源

ドラッカー理論における人的資源概念の検討」によれば、人的資源管理は1960年代以降に誕生したが、ドラッカーは1950年代から人的資源の重要性を指摘していたという。曰く、人的資源は他の資源と異なり経営と双方向の関係が生じ、これを見落としてはならない

また、人的資源の「人的」部分は人格にあるとしていた。情緒だエモだと切り捨てられかねない箇所こそが最も重要視されていることは注目に値する。

リソースという表現が人間性軽視だというのはどこから?

ここまでの背景をおさえると人間をリソースと呼ぶ人的資源論の理念は、むしろ人間をリソースと呼んでほしくない側の主張と近しいことがわかる。

それにもかかわらずどのように捻れて「リソースと呼称することはモノ扱い」といった受容をされるに至ったのか。「人的資源管理論と組織文化の関係性」や「人的資源管理の現代的意義と検討課題」によると、人的資源管理の理念が忘れられ当初の想定通りに運用されていないことが原因だと言えそうだ。

人的資源管理の失敗

人的資源管理の現代的な課題と失敗は以下に起因する。

  1. 人的資源管理の経済面・戦略面に偏重して経営管理がなされること
  2. 人間性を捨象して労働力としてのリソースとみなすこと
  3. 他のリソースと混同すること

いずれも先述した人的資源管理論の有効実践の前提となる理念に反している。人的資源管理が生まれてから数十年が経過したことにより理念が忘れ去られ、有効的でない運用が横行しているのが課題だという。

マネジメントの次元の混同

ヘンリー・ミンツバーグ『マネジャーの実像』(2009)にも興味深い一節があった。*6

従業員を人的資源(リソース)と呼べば、従業員を人間ではなく数字として扱うことになる。言い換えれば人の存在全体ではなく労働力という一つの側面だけに着目する結果を招く。

人間の次元で対人関係のマネジメントをしているつもりで、その実、情報の次元で非人間的なマネジメントをしているケースが極めて多い。

ここでは従業員をリソースと呼ぶことにより異なる次元の物差し・議論を混同する危険性が示唆されている。この次元とは何かというと、ミンツバーグによればマネジメントには3つの次元があり、これらを行き来してブレンドすることが優れたマネジメントであるとされる。

  1. 情報の次元
  2. 人間の次元
  3. 行動の次元

経営上の数字としてあらわれるヘッドカウントはあくまで"情報の次元"におけるマネジメント対象。しかし、数字を構成する個々のメンバーの人間性は"人間の次元"におけるマネジメント対象。これらを適切に区別して場面に応じて扱うことが有効で実践的なマネジメントであるが、そうでないマネジメントも残念ながら存在する...という論旨。

実利的な課題は何なのか

ここまでで人的資源管理論が登場時の期待通りに理解・運用されていないという課題提起、および、その課題にリソースという呼称/ネーミングが関わっているという指摘を紹介した。

最後に人的資源管理論の理念に反することがどのように実利上の課題に繋がるのかを見る。

知的・物的生産量の低下、価値創出の機会損失

人的資源管理論の人間観として特徴的なのは人の人間性を強調する点ではなく、人の人間性に資源的価値を見出そうとすることである。前述した「モノ・カネ・情報を活用する主体」「高度な思考をする主体」という特殊性こそが価値を創出する源泉であり、モノ・カネ・情報では代替できないという点だ。

人をモノ・カネ・情報と同列に扱うことはこの人間観に反するだけでなく、経営管理を通じて実現したい価値、特に人間性に依拠する価値を生み出す能力の喪失につながる。抽象的な話が続いたが具体的には下記のような事例を想像できる。

  • モノ扱いされることがモチベーションの低下や職業倫理の喪失を起こし、知的・物的生産量が低下する
  • 代替可能な範囲の業務しか委任されず高度な思考が行われなくなり、価値創出の機会を損失する
  • 人をモノやカネを交換可能とみなし、非現実的な人員計画やスケジュールを立案する

これらはいずれも実利的な課題である。

組織文化の衰退・破壊

人が組織文化を構成する/つくりだす最重要要因である。また、組織文化は集団における模範的な行動を再生産し、企業内の価値創出システムとして機能する。

人間の労働力の側面のみを数字で扱うことは人間の組織文化の形成能力を軽視するものであり、組織文化の再生産能力や関与度が低い構成員を増やし、組織文化の衰退あるいは破壊を招きうる。組織文化が経営や事業にどのような影響を及ぼすかについては数百もの書籍や研究が存在するはずなのでここでは述べない。

こちらも間接的ではあるが実利にかかわる課題である。


以上、ここまでの調べにより冒頭の「結論」に書いた主張に強度を与えられるのではと考えた。

なお、長々と書いたが自分には人間をリソースと呼ぶことについて特段の主張はない一方、ソフトウェア工学やプロジェクトマネジメント、リスク管理には関心がある。その範疇で人的資源管理や経営管理について遠くから考える機会は多々あったように思う。特に本記事を書きながら『人月の神話』のことを思い出していた。

(余談)呼称が問題を生むのか、問題が呼称に現れるのかについては因果性のジレンマである。とはいえ、後述する人的資源管理論の歴史や理念を主張の拠り所とするなら、人間をリソースと呼ぶことが問題であると声高に言うより、経営管理やマネジメントの問題の兆候が呼称に現れていることを懸念するとするほうが話を通しやすそうに思えた。

まだわかっていないこと

  • 人的資源管理は2024年現在においても真に主流の経営管理手法といえるのか。アカデミックにおける最新の動向はどのようなものか。特に2020年以降の労働環境の変化が本論とどう関わるか。
  • 人的資源管理にまつわる実証的なデータやエビデンスがどれだけあるのか。
  • 本論は国内外の話をごちゃまぜにしているが、文化的差異がどれだけあるのか。

本記事は非専門家による短時間の調査結果に過ぎないので、詳しい読者がいたらぜひ教えていただきたい。

*1:本記事では経営管理を「企業や組織が目標達成のために計画を策定し、実行し、評価、監視する一連のプロセス」の意味で用いる。この中にはヒト・モノ・カネ・情報の管理・活用が含まれる。

*2:マルクスにおける"労働が労働者の人間性を疎外すること"。 https://kotobank.jp/word/%E5%8A%B4%E5%83%8D%E7%96%8E%E5%A4%96-1440282 余談だが本記事の筆者は学部の卒論でヘーゲルフォイエルバッハ疎外論について書いた

*3:あまりよくわかってないがフレデリック・テイラーアンリ・ファヨールから数十年後のムーブメント?

*4:企業戦略と人事管理の一貫性、戦略的な側面に着目して戦略的人的資源管理(Strategic Human Resource Management)という呼称も用いられているとのことだが、本稿では区別しない

*5:なお、日本語における"資源"が物的で代替可能なイメージを持つのに比べ、英語における"resource"はいくらかポジティブな意味合いを持つとのこと。重要人物を"resouce person"と表現するなど

*6:同書が手元にないため、記事筆者の記憶に基づく要約

Ruby Weeklyに自作のgemが掲載された

毎週購読しているRuby Weeklyに初めて自作のgem pbtが掲載された記念。

rubyweekly.com

おそらく先週Hacker Newsで少し目立ったので拾ってもらえたのだと思う。おかげでまた少しstarsが増え、ようやく自分のGitHub repositoriesのtopを更新できた。(長らくtopにあったのが6年前に作った学習用のtemplate repositoryみたいなやつだった)

実際のアクセス数や伸びでいうとHacker Newsのトレンドになったときのほうが大きかったのだが、普段読んでいるNewsletterに掲載されるのはまさに"光栄"で、異なる嬉しさがある。

Hacker Newsで自作のOSSを紹介したらRanking 1位になり一晩で+100 stars付いた

自作のRuby gemをHacker Newsにて紹介したところ、一晩でGitHub repositoriesに100以上のstarsが付いて驚いた。また、リアルタイムでは見逃したのだがHacker News Rankingで数時間1位におり、20時間ほどトップページに載っていたらしい。2024-05-26現在は落ち着いて195pt。

投稿はこちら Show HN: PBT – A property-based testing library for Ruby | Hacker News

2024-05-22のdaily rankingでは11位だった。

続きを読む

Ractorを用いたproperty based testingの並列実行についてRubyKaigi 2024で発表しました

表題の通りRactorを用いたproperty based testingの並列実行についてRubyKaigi 2024で発表してきました。かつスピーカーとしての参加は初めてで、いろいろ稀有な体験ができて総合的にはめちゃくちゃ楽しかった。

続きを読む

RubyKaigi 2024に登壇します

RubyKaigi 2024 に "Unlocking The Potential of Property Based Testing with Ractor" というタイトルで登壇します。Ractor枠、もしくはtesting枠といったところでしょうか。

rubykaigi.org

Abstractに書いた通り、Property based testingというテスト手法のイテレーションをRactorで並列化したら効率的だし誰もやってなくて面白いのではないか?という話をします。

何かしら引っ掛かるものがありましたらぜひ見に来てください。


Ractor。Rubyで真に並列処理が簡単にかけてしかもスレッドセーフであることが保証されてるの、すごいことだと思うのだけどなかなか普段のプログラミングでユースケースが見つかっていなかったんですよね。

一方僕は、普段から並行並列処理をガンガンやっているわけではないものの、Fintech事業従事者としてテスト設計や手法にはそこそこ関心があり。昨年にはProperty based testingに興味を持って他言語のライブラリコード読んだりRubyで試したりしていました。

その過程で

「テストコードって独立した小さい単位の処理だよな」

「propety basaed testingだとそれが数百回イテレーションで実行されている」

「これは並列化の恩恵を受けそうだし、Ractorの良いユースケースたりうるのでは?」

と着想し、今に至ります。


スライドの初稿を完成させて事前提出した段階でこの記事を書いているのですが、練習したところ5~10分ほど時間オーバーしており、削りどころをどこにしようかまだ悩む日々が続きそうです。

いつもは技術的な"深さ"よりも"理解りやすさ"を重視する傾向にあり、深さを求める相手とはAsk the speakerなどで議論するというスタンスをとってきました。が、今回はあのRubyKaigiということもあり、"自分が面白いと思うこと"を詰め込む方針へ転換してみようかなと思っています。

吉と出るか大凶と出るかはわかりませんが、動画を組み合わせた解説やデモなど、これまであまりやってこなかったこともやっていみたいですね。


いやー、RubyKaigiへの登壇は人生でやりたかったことリストに含まれていたので、本当に感無量です。

残り一週間、健康に気をつけていきます。(GWに一度体調を崩した人の顔)

YAPC::Hiroshima 2024のついでに広島観光してきた

YAPC::Hiroshima 2024に関する記録はYAPC::Hiroshima 2024に参加してIdempotency-Key Headerの話をしてきた - valid,invalidに残したので、この記事は旅行記とします。

かつてTwitterで "広島の粗大ゴミ" を名乗っていた男の、人生初の広島遠征────

続きを読む

YAPC::Hiroshima 2024に参加してIdempotency-Key Headerの話をしてきた

表題の通りYAPC::Hiroshima 2024にスピーカー、およびスポンサー企業の一員として参加してきました。最近はブログ不精となっていてイベントに参加しても記事を執筆せずにいたものの、YAPC参加者のすさまじい熱量にあてられたので久々に筆をとってみます。

自分とYAPCとbuilderscon

YAPC初参加です。が、実はYAPCには思うところがありました。

YAPC::Asiaの後継として開催された(ですよね?)buildersconに2017, 2018, 2019と参加しており、このイベントからは過去にめちゃめちゃ感化されていたのでした。特に初参加のbuilderscon 2017に強く影響を受けてから僕は登壇やOSS活動を始めたので、勝手な思い入れがあるカンファレンスです。

「buildersconにもやがて登壇するぞ」と思っていたものの直近の数年は非開催となってしまったので夢が潰えたような気もしていました。ところがどっこい「buildersconに一番雰囲気が似てるカンファレンスはYAPCなのでは(想像)」「YAPCに登壇できたら目標達成では(妄想)」という気づきがあり、プロポーザルを出してみたところ採択いただき、広島凸という背景でした。

トーク「My Favorite Protocol: Idempotency-Key Header」について

YAPC::Hiroshimaのテーマが"What⁨ I like"ということで、僕の好きなプロトコルであるIdempotency-Key Headerの話をしてきました。RFCにはなっていないものの、StripeやPayPalといった著名決済SaaSでは実運用されている便利HTTPヘッダーです。

僕が携わるB/43でも2021年から導入しており、データ堅牢化に一役買っているという自慢をしました。

テーマ的にソフトトークやキャリア論でもプロポーザルを出せそうだなと思ったのですが、初見のコミュニティで顔を売るならしっかり技術的な内容で興味を惹きたいと思ったのでテクニカルな内容にしました。

ベストトーク賞は取れなかったものの同僚のmitaniさんが素晴らしいトークで広島凱旋&受賞という偉業を成し遂げていたのでオッケーです。いや、ぜんぜんオッケーじゃなくて悔しい!このような投票型の企画があるカンファレンスをあまり知らないので、今度登壇する際にはベストトークを獲りたい。

というわけで逃したものの「ベストトークとして投票しました!」という方に懇親会でお声がけいただいたり、複数の方がブログにて言及してくれたのを観測しており、しっかりと人の心に残る登壇ができたのはポジティブです。

登壇のふりかえり

  • 前夜祭の番宣リレーで「冪等!冪等!冪等!」がウケてたようで良かった
    • SmartHRのブースでinaoさんに挨拶したとき「あっ、冪等の人ですか」って言われて嬉しかった
  • 時間が押してて即開始となってしまい、会場を暖める"前説"ができなかった
  • 愛機のLogicool Spotlightがかっこいいと言われた
    • けど会場でうまく動かないシーンがありちょっと焦った
  • 質疑応答がいっぱい来て嬉しかった
    • YAPC、全体的に質問が多くてとても良い雰囲気だった
  • 大量のスライドを作っておきつつ「時間がないので」と言って飛ばしまくるテクを褒められた
    • Appendixに書いてても読まれない・触れずに終わってもったいないので本旨に混ぜ込んだほうがいい
    • 「ここで止まる」スライドが面白い

スポンサー企画「CTOを破産から救おうチャレンジ」

所属するスマートバンクが椅子スポンサー────椅子にチラシを掲載する権利を得る────となった機会を活かし、今回は軽めのコーディングクイズを出題してみました。

Idempotency-Key Headerを理解するとシュッと解ける問題になっており、僕のトーク内容で学んだことを実践し、身につけていただけるような教育的なクイズを意図しました

github.com

Perl, Ruby, Goの3言語のいずれかで挑戦可能ですので、参加者も非参加者問わずまだ見ていない方はぜひ一度cloneして挑戦してもらえると喜びます(Xにpostしていただけると更に喜びます)。

ちなみにLTにはこのクイズに関連したコード難読化ネタで応募していました。残念ながら非採択でしたがどこかにて供養したいと考えています。

fortee.jp

良かったトーク

naoyaさんの「関数型プログラミングと型システムのメンタルモデル」

  • 以前の講演のスライドだけ目を通していたがリアルに聞くとさらに面白かった
  • これは型にとどまらないモデリングの話だと僕は捉えている
    • なので静的型付けを用いない言語であってもある程度のエッセンスを活用できる
      • RubyでUserをActiveUserとDeactivatedUserに分けたって良い
      • classである必要がないならDataやStructで宣言したって良い
    • 型は検証のためのツール。それでもメンタルモデルに影響を与えるので型とモデリング間の相互作用が生まれるので当然あると良い
  • どうしたって副作用はあるけどどうする?という問いに「純粋関数の世界とIOの世界を分けるという」のは納得感が高い

...のようなことを思っていたらご本人も同じようなことをpostされていました。

naoyaさんにできれば質問したかったのは、「世界を切り離さずに済む、あるいは近づける方法としてRDBでイミュータブルモデリングを実践するのはどうか?」という点。

世界を切り離すことへの納得感はありつつ、RDBにおける物理表現と論理表現の間にギャップがあるのは大部分の開発者にとって難しい(変換の認知負荷が生じる)と考えていて、そこを埋めるアプローチがあるのではないか?

t_wadaさんの「理解容易性と変更容易性を支える自動テスト」

  • 自動テストについて最もよく整理された資料だと感じており、折に触れて引用したい
  • Test ScopeとTest Sizeのマトリクスが特に好き
  • 僕はデトロイト学派

変更不可能な外部からの要求で大量のパラメーターを送りつけられるWeb APIのように、自分たちが管理できないコードベースとの接合点で信頼性の高いテストを書くにはどうすればいいか?」という質問をさせていただきました。

仮定をテストに混ぜ込むしかない、自作自演にならざるを得ない、実物をCIで呼び出せない...といったことが起こりがちなこの課題に対して「腐敗防止層やHumble Objectの導入でTest SizeとScopeを狭めていき、信頼性の高いテストの割合を増やしていくと良い」という回答を頂いた。

mitaniさんの「VISAカードの裏側と “手が掛かる” 決済システムの育て方」

身内びいき抜きに一般公募では最も感銘を受けたトークでした。

今回のmitaniさんの登壇内容に、僕はmoznionさんの「Javaカードの世界 」(2018) を勝手ながら重ねており、どちらも技術者の心のくすぐり方が最高に巧かったなと感動していました。そういえば、どちらもカードの話題だな...。

このように業務上で学んだことを公知にしていく試みがベストトーク賞というのも感慨深いものです。というのも、登壇しない/できない理由の第一位は「ネタがない/業務で大したことやっていない」というものだからです(ohbarye調べ)。いち事業会社の中で必要に迫られ行う日々の業務の延長にも、このように多くの人の心を捉える登壇があるのだ... と多くの人が思えたのではないでしょうか。

加えて、クレジットカードのように現実世界に存在する物理的なアイテムとソフトウェアの交差点に存在する難しい課題と、それらをどう解いていくかに関心を抱くエンジニアは思っていたよりも多そうだというのも発見でありました。

とほほさんのキーノート

もはや何を言うまでもなく、とにかく今回のYAPCテーマにもぴったりで圧巻の内容。技術でもそれ以外でも、自分も好きな何かをゆるくても長く続けてみようと思える素晴らしいトークでした。

懇親会で話した20歳ぐらいの学生さんもとほほさんを知っており、オールタイムレジェンドであることを知りました。

その他の感想

良かったこと

  • お昼の穴子めし弁当がめっちゃおいしかった
  • ゲストや登壇者はシニアな方が多そうだったが、参加者の年齢は幅広く、学生の方とも話せた
  • 見知らぬ人にも話しかけてくれる良い雰囲気があった
  • serimaさんなど久々にリアルで話せた方がいた
  • karasawaさんが話しかけてくれた

反省 / 心配

  • 2日目の懇親会後に腹痛になってしまい二次会に参加できなかった
  • ogijunさん、kyannyさん、shibayuさんなどじっくり話したい方がいたが話す機会がつくれなかった
  • YAPCのクオリティやホスピタリティが高いものの、一方チケット安すぎて大丈夫...?と思った

ニュートラルなこと

  • ベストトーク賞の投票数は非公開でいいけどフィードバック/感想文を共有してもらえると嬉しい
  • 前夜祭はトークと飲み会が同時会場で行われており、TokyuRuby会議みたいだと思った

広島旅行の話も混ぜると大変な長さになりそうなのでYAPCの感想だけで筆を置くことにします。