サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
TGS2023
kumagi.hatenablog.com
「禅とオートバイ修理技術」これら2つの間にどのように関係があるのかまるで見当が付かず、タイトルだけ聞くとキワモノのようだがWikipediaによるとアメリカでは一番良く売れた哲学書とされている。 海外のエンジニアのブログを読み漁っていた時にオススメされていたのでKindleで買って読んだのだが想像以上に良かったのでメモを残したい。と言ってもwikipediaで説明されている内容を改めて説明しても面白くないのでソフトウェアエンジニアとして響いた部分を引用して僕の感じた事を書き連ねていく。 大都市の重工業地帯に一歩でも足を踏み入れてみれば、そこにはその全てが存在している。テクノロジーである。正面には有刺鉄線を施した高い塀が立ちはだかり、門は常に閉ざされ、「立入禁止」の札が掛かっている。そしてその向こうの薄汚れた大気の中には、金属や煉瓦で造られた醜い建物が立っている。その目的は不明であり、またそ
リングバッファのイメージ図 1. リングバッファとは何か 機能的にはFirst In First Out (FIFO)とも呼ばれるキューの一種であるが、リング状にバッファを置いてそれの中でReadとWriteのインデックスがグルグルと回る構造をとる事によって容量に上限ができることと引き換えに高速な読み書き速度を得たものである。キューを単に実装するだけなら山ほど方法があって線形リストを使ってもいいしスタックを2つ使っても原理的には可能だ。その中でもリングバッファを用いた方法の利点はひとえに性能の高さでありメモリ確保などを行わないお陰でシステム系の様々な場所で使われている。 これの実装自体は情報系の大学生の演習レベルの難度であるが少し奥が深い。まずリングバッファのスタンダードなインタフェースと実装は以下のようなものである。 class RingBuffer { public: explicit
エンジニアの奇行 嚢中の錐という言葉がある。有能な人物は自ずと傑出していくという意味だが、有能さとは例えば学歴の高さとは一致しない。 たとえMIT卒であろうとも大成するとは限らないし、ましてや入試の点数などで見れる人間の側面は限定的である。 企業などで採用する側からしてみたら当然ながら採用後の活躍を期待して雇用するのであり、入社をゴールとしてそれ以降働かなくなる人は望ましくないし、学歴や入試の点数によってそういう人かどうか判定する事はできない。 活躍という観点で言うと長いキャリアにおいてより重要となるのはキャリア開始時での能力の高さよりも、険しく長い道のりを自己メンテナンスしながら歩み続けられる根気の強さが重要とされている。その根気の源泉は執着だったり崇拝だったり妄信だったりトラウマだったり原体験だったり人によって様々だが、ここではひっくるめて「やる気」と簡略化して呼ぶことにする。 さて「
前回のブログから90日以上経ってしまったので広告が載ってしまったから短文でもアウトプットしておく。 プログラマとして仕事をしているとコードと向き合っている時間の9割以上は既存のコードを読んでいる、だから読みやすさは重要である、という言説は耳にタコができるほど誰もが言っている。 仕事で書かれるコードが誰のレビューも通ること無くマージされている現場は凄惨だが、自分より明らかに経験を積んだ人たちが何度もレビューを重ねたコードが読みやすいかというとそうとは限らない。良いコードが守るべきルールをすべて守っていても不可解なコードはあるし、どんなに読みやすいコードでも数千行の規模になってくるとやはり脳内からこぼれて一度に覚えておける範囲からはみ出る。 変数名や関数名をわかりやすくするとか不必要な技巧を凝らさないとかわかりやすい設計にするとか主観的な事を偉そうに語る本は山ほどあり、それらの本を崇める事は悪
TL;DR 正しく設計するとキャパシティは常にカツカツになる これはpyspaアドベントカレンダーの8日目の記事です。前日はShibukawaさんです。 世はクラウド時代、ソフトウェアはひとたび作られたら何億回実行されても摩耗するものではないので、どんな間抜けなロジックであろうと動く以上は別のどこかで瑕疵が出てくるまで使い倒されるのは日常茶飯事である。 サービスを負荷の前提の上に定義する クラウドより前の時代においてサービスを支えるマシンは「ロードアベレージが1.0を超えてなければとりあえずOK、超えたらマシンを増やして負荷を分散する」というノリのベストプラクティスがよく言われていたがそれはサーバ資源の確保にそれなりに時間がかかる時代の常識であって、クラウド時代でサーバは分単位で確保できるようになった。 クラウドの利点としてその即時的なスケーラビリティが常套句として使われて久しいが、これは
はじめに chike0905.hatenablog.com この記事は大変楽しく拝読したが、ブロックチェーン素人ながら気になる点がいくつかあったので指摘する。要旨は以下である。 タイトルで「できない」と言ってる割には「できるけど筋が悪い」だけに見える 研究中で結論が出ていないトピックを「できない」と呼ぶのは違うのではないか 文体が学術めいている割には用語の使い方がやや雑に見える ブロックチェーンに「不可能」な事にフォーカスすべき 浮足立つ界隈に対して問題提起するならば的を絞って指摘すべきで、容易に解決可能そうに見えてしまう批判はかえって混乱を招く恐れすらある ノードの独立性 各自で検証し、他のノードに依存するプロセスは本定義のブロックチェーンの動作の中には含まれない。 従って、他のノードに何かを問い合わせる必要もなく、信頼する第三者などは存在しない。 この部分はあまり正しく理解している人が
blog.j5ik2o.me この記事は彼のブログ投稿への返信です。 彼とのtwitter上でのreplyの応酬スレッドが見返すと引くほど長くなっていたので僕の観点からの要約を纏める。予め断っておくとこれは本当に自転車置き場の議論以外の何物でもなく、技術的な学びはどこにもない不毛なやりとりであって、苦労して理解する価値がなかったなどの苦情は受け付けない。 kumagi: 値オブジェクトはIDによらない等価比較をするオブジェクトの事であって、ドメイン固有の値オブジェクトもそうでない値オブジェクトもある。 かとじゅん: それはおかしい。全ての値オブジェクトは何らかのドメインオブジェクトの一部であって、Integerすらも整数ドメインの問題を解決するために設計されたドメインオブジェクトと言える。Evansも肯定しているはずだ。 kumagi: なるほど、その整理の中で逆にドメインオブジェクトでな
blog.j5ik2o.me 値オブジェクトはドメイン固有型の一種です。なので、不変と等価判定だけではなく、なにかしらのドメイン固有の不変条件(invariant)を維持する責任があると考えます(もちろん型として切り出すわけですからその投資に見合うだけの見返りがないといけません)。 違う。値オブジェクトとはID以外で等価判定をするオブジェクトの事であって、RubyのHash、Pythonのdict、C++のstd::unordered_setすらも値によって等価判定を行うのでこれらは値オブジェクトであるがドメイン固有型ではない。RubyでHashに入れて渡されたユーザ入力値をValidationしてドメイン固有型に詰め直すのはもちろん必要ならやれば良いが、Hashクラスそのものにモンキーパッチなり特異クラスなりを行って不変条件を維持する責任を負った自分専用Hashを作って普通のHashクラ
Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a
TL;DR 疑いの目を向けてみると怪しい奴ばかり 通貨発行は楽しい、これは真理である。 www.sinseihikikomori.com 1人プレイ用のゲームの中で敵を倒してゲーム内の通貨を得る行為は広義の通貨発行と見做せる。ドラクエの世界でスライムを倒して3ゴールドを得る行為すら通貨の発行であるという観点で考えた時、このブログの読者は誰しも通貨発行の体験があるはずである。 現実で使われる通貨を鋳造したら普通の犯罪であるが、この日本で法に触れずにこれに近い行為を達成できるのが借金である。人から10万円を借りて、その引き換えに「x万円を○月○日までにお返しします」と借用書を書けばその「○月○日にx万円を受け取る権利」自体が債権としてそれなりの値段y円で市場で取引される一方で自分はx万円を得ることができ、世界に存在する価値の総量がy円だけ増えたことになる。これは経済の基本である。 この借用書、
えふしんさんに何の恨みも無いのだけれど わからないことを偉そうに書いて怒られて進化したいという芸風なので書いてみました。 Web3というテロリズム｜えふしん #note https://t.co/84SoYtIzDC — えふしん (@fshin2000) 2022年2月17日 というのだから技術的に正確なツッコミを入れて欲しいという事だと信じて書く。まさか後釣り宣言など来ないだろう。 Web3という言葉は、既存の権力構造に対する宣戦布告と考えれば、割と素直に受け入れられる。 ここは本当にその通りで「下剋上」の雰囲気感だけで業界が振り回されているのは見るに耐えない。権力構造を敵対視するあまり、本当に味方に付けるべきエンドユーザーの事がなおざりになっているとすら感じている。市場経済で世の中が動く中、エンドユーザーは確かな利益が無ければ動かないし、利益無しで人やお金を動かさせたら詐欺である。こ
前回の記事に更に返事を頂いた。応酬が全部長文なのでこの記事から読み始める人は「まとめ」から読んで興味が湧いたかどうかで全文を追うか検討して欲しい。 sasakill.substack.com まさか本当に返事が貰えるとは思っていなかったが、実に興味深く、かつ知見として共有すべき事が書いてあったので「いつまでそのネタ擦ってんだよ」と突っ込まれるのを覚悟の上でさらなる返事をまとめる。 kumagiさんは「アテンション・エコノミーが最高であるとは思っていないが、市場の競争によって良い体験が生まれていることは認める」というもので、一方私は「アテンション・エコノミーの影響力が強くなりすぎていて、それ以外の良い体験の可能性を押しつぶしている」ととらえている。 これは確かにそうで40億回/日の再生数のうちどれだけが真にユーザーの利益になったかどうかについて僕は何らコメントできる立場にない。全ユーザーが全
前回の記事に長文で反論が付いていたので興味深く拝読した。 sasakill.substack.com 書いた人はSmartnews社のVice Presidentのようで、予想外のところまで記事がリーチしたのは少し驚いている。 メタバースはNFTの使い途の一部でしかなく、Web3によって完璧な非中央集権的な社会が実現するなんてこともない。 僕の記事では「メタバースにNFTは不要」と言ったのに「NFTにメタバースは不要」というような受け取られ方をしているあたりは少し気になるが、彼が論点に挙げたいのはメタバースでもWeb3でもなくNFT単体であるようだ。そのつもりで僕の意見をまとめる。 私の考えでは「ノーコストでコピーが可能」という議論の土台にそもそも穴がある。 繰り返すがコピーはやはりノーコストである。この記事の読者が自身のデバイスに僕の記事を表示させるまでのコピーに掛かった電気代・通信費の
TL;DR NFT投機界隈のデタラメに気をつけましょう ブロックチェーンはデータに価値をもたらすのか もたらさない。 NFT界隈がよく言う「希少性」自体には何の価値もない、部屋の隅に落ちている埃だって厳密には世界に全く同じ物は存在しないしデジタルデータのように完璧かつ無制限に複製することもできない、それでも価値はない。 ブロックチェーンのwalletを作成したら既にそのwalletは自分の唯一無二な所有物となるが作成時点でwallet自体の価値は空である。希少や有限であること自体を根拠に出資を迫ってきたらそれは詐欺である。 希少or有限な物にお金を払うモチベーションがあるとするならばそれは実需を除くとそういう信仰があるからに他ならない。伏見稲荷大社に21万円払えば5号の鳥居が奉納できるがやってる事はそれと変わらない。伏見稲荷大社に置ける鳥居の数は当然有限だが、有限であることだけを理由に奉納
TL;DR 並行処理を実装する人のこれからのスタンダードになる一冊。買い。 並行プログラミング入門 ―Rust、C、アセンブリによる実装からのアプローチ 作者:高野 祐輝 オライリージャパン Amazon 買ったら思いの外早く届いたのでパラパラと読み始めたら一気に読み終えてしまった。 総評 敢えて雑な喩え方をするなら The Art of Multiprocessor Programming (通称TAoMP本) の内容を薄めてRustやアセンブラや計算モデルを足したような本だった。 日本語の書籍としてはかなり珍しくWait-Free, Lock-Free, Obstruction-Freeの違いなどを適切に論じており、TTAS Lock, MCS Lock, TL2といった日本語では希少な情報が書かれているレアな本である。これらに付いて論じている日本語の本は知る限り (TAoMP本と昔僕
買った戸建てに付けた表札、住所はぼかした プロローグ 新型コロナが世間を騒がせ始めて以来ずっと在宅勤務をしている。 転職に伴って会社近くに引っ越したので通勤のドアtoドアで30分台を叩き出していた好立地はその活躍の機会をすっかり失った一方で、妥協した40平米の部屋の狭さと1LDK+Sの間取りが巣ごもり子育て核家族を襲った。 外で遊び足りない娘は泣き、広がった活動範囲で家中の物を無秩序に引っ掻き回すので必然的に触られたくないものは高いところに置くことになり、立体的に活用される事になった1LDKの空間は生活の難度を高めジワジワと真綿で首を締めるような状況が続いた。 住んでいたマンションは駅に近いのは良いが作りは古く、冬には窓枠が結露しカビが発生する。窓から降りる冷気はそのまま壁や床にすら結露を起こし室内はカビに見舞われた。それとの因果関係は不明だが冬場の慢性的な体調不良が家庭内の治安を更に悪化
TL;DR スタンディングデスクは良い コロナ禍が始まって以来、在宅勤務を続けているが勤務先へのアクセス利便性を優先したが為に住居は1LDK+Sという状況で、2歳になった娘も居る状況で労働環境の確保と充実は急務であった。 スタンディングデスクで探すと昇降デスクと1m程度での高さ固定デスクの2種類が見つかるが、人間の身長は±30cm以上の個人差がある中で特定の固定の高さがジャストフィットする望みは薄く、長時間作業を前提とする場合は微妙な高さのズレが腰痛や肩こりなどの形で跳ね返ってくるのでジャストフィットに調節できる昇降デスクをおすすめしたい。 スタンディングだと疲れるという人は疲れた時には椅子を使ってもいいし、定期的に立ち上がって仕事をするほうが座りっぱなしよりは健康に良いとされる。昇降デスクはもちろん椅子の高さに合わせて下げる事もできるので、高さを替えやすい昇降デスクはその点でも有利だ。
TL;DR アフィ記事です 1歳半になりました 先日めでたく友人に子供が生まれ、他でも安定期に入ったとかめでたい報告が相次いでおり、そういう年代に入った実感が湧いてきた。 前々回の記事で書いた娘が無事に一歳半検診を終え、この期間であっても学んだ事は多い。特に子育てに関わる便利アイテムというのは実際に子育てをしないと触れる機会もないし、子供も家庭事情も千差万別なので有用なものもあればそうでないものもある。 実際に子育てを始めるまでは、3ヶ月までは首が座らないとか（そもそも首が座るって何さ？）、そのうち首が座ってもまだ腰が座らないとか、乳児の中でも複数の段階に別れていることすら知らなかった。  スイマーバで遊ぶ娘 6ヶ月にもなれば徐々に離乳食を始めていくことになるのだけど、離乳食が食事の教育であることも考えるとできれば座って食べさせたいのが親心である。が、6ヶ月というのは首は座っていても床や
Googleオフィスの窓からの眺めをGoogle Photoが自動加工したもの TL;DR AtCoderやろうぜ Googleの(僕から見て)偉い人が立て続けにブログを書いており ctrl-x-s.blog hoge.blog ここ数件の僕のブログへの反響を読んでも「Googlerだから特別」みたいな意見が散見され、入社へのハードルが変に高く見られてしまっている気がするので、僕がGoogleに入社する準備として取り組んでいた事とそのレベルを紹介する。程度の低さに安心して欲しい。 英語 英語の論文は興味の赴くままに読んでいたため読むことに関してはあまり苦手意識は無いものの、絶対的な英語力に関して言うとTOEIC500点というスコアが端的に表している。これがどれぐらいかというと、得意分野から外れると長文を読む速度と精度がガタ落ちし、リスニングも結構な単語を聞き落とし、文脈からの推測と辛うじて
TL;DR アフィ記事です 転職してからすっかりSNSで音沙汰がなくなったなkumagiと一部の界隈で噂されているようですが、twitterやFacebookにはたまに書いていたように娘が産まれました。 Googleでは子供が生まれた時に育休を取ることができる。 単なる育児休業は育児・介護休業法に定められた労働者の権利であるけれど、Googleではそれに加えて3ヶ月間フルに給料が支払われる有給休暇が付与される*1。これに加えて雇用保険から給付金をもらう育休を取っても良いとされているが、ソフトウェアエンジニア的な意味で遅れを取り過ぎるのも憚られたのでまずは3ヶ月の有給休暇をありがたく頂戴することにした。 授乳について 3ヶ月までの赤ちゃんは昼夜問わず3時間おきに母乳やミルクを欲しがる。大抵の成人は3時間おきに母乳やミルクを与え続けると精神的にだいぶ参ってくるという知見が広く共有されていたので
最終退社時の自分の机 2012年に修士卒からの新卒でNTT研究所に入り、6年間お世話になりました。 研究所では同期や先輩や後輩や上司に恵まれ、存分に書籍や論文を読んで勉強して力を蓄えたり、対外的な発表の場にも恵まれ外ではできないような体験をすることができました。 ありがとうございました。 入社当時に作られたtogetterを見返すと togetter.com togetter.com まるで昨日のように感じられる。 NTT社内で僕が何をやっていたかについては言える物は軒並みアウトプットされているのでわざわざここでは触れない。 NTT研究所について NTT研究所を客観的に見た時にどうかを書いていく とにかく人に恵まれている。採用の倍率が高いのもあって潤沢な学生エントリーからよりすぐりのエリートが謎の力でポテンシャルを見極められて採用されている。同期を見てひと目ですごい奴も居れば、一見してわか
TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン
NTTがブロッキングを発表してから様々な反響があったのでざっと眺めて反応を主観でカテゴライズしてみる。 TL;DR; NTTも政府もしっかりしろ。あと違法行為はやっぱりダメだ。 今回の措置に賛成だよ派 困ってる人がいるからしょうがないよ派 プロバイダ責任制限法を越えるから仕方ないよ派 やまもといちろうが気に食わないよ派 他の国ではやってるよ派 反対派は漫画村ユーザだよ派 ブロッキングは合法だよ派(宛先は通信の秘密に当たらないよ派) 政府がそう言ったらしいよ派 緊急避難が適用されるから合法だよ派（児童ポルノと同じだよ派） なるべく速やかに立法すべきだよ派（結果整合派） 違法だからどうした派（アナーキー派） 今回の措置に反対だよ派 本当に緊急回避が成り立つなら賛成だよ派（漫画村もうないじゃん派） 立法の後なら賛成だよ派 さっさと立法しろ派（法治重視派） 憲法21条も一緒に修正しろ派（整合性重視
注意： この記事は私の所属する組織の意思も意見も絶対に断固として欠片すらも表明する事を意図して書いていません TL;DR;今回のサイトブロッキングは私見ではダメだと思ってるけど、国の言うロジックは一応わかるし勘違いベースで応援するのも叩くのも止めて欲しい 前提知識 まず大前提として、日本には憲法というものがあり、その21条にはこのように明記されている。 憲法第二十一条 集会、結社及び言論、出版その他一切の表現の自由は、これを保障する。 検閲は、これをしてはならない。通信の秘密は、これを侵してはならない。 憲法に沿った国の運営をするためここから派生して制定されている法律のうち、今回の件に関係が深いのは電気通信事業法である。 電気通信事業法 （検閲の禁止）第三条電気通信事業者の取扱中に係る通信は、検閲してはならない。 （秘密の保護）第四条電気通信事業者の取扱中に係る通信の秘密は、侵してはならな
 TL;DR; 「分散ロック」が分散システムの設計図に登場した時 だいたいその設計は間違っていて本当に必要なものはトランザクションだ 並行システムを実装する際にロックを用いるのはとても自然なことだ。 僕も普段はロックフリー系のアルゴリズムに詳しいと言われがちだが知識量でいったら実はロック系の方が多く蓄えているかも知れない。 分散システムは並行システムであることが多いので、その中にロックが登場するのはとても自然な発想である。 よく「分散」「並行」「並列」の言葉の定義がごっちゃになっているケースがあり、この記事の主題にしたいわけではないので深くは言及しないが、分散システムは環境などの要因で突如として参加者が音信不通になったり復活したりする点で並行システムと大きく異なる。 並行システムと同じノリで分散システムを設計しようとした際に陥る頻出の過ちが「分散ロック」である。そのアイデアはとても簡単で
8/10のNTT Tech Conference #2 にて発表の時間をもらってこのタイトルで喋ってきた ntt-developers.github.io 発表が決まるまで これはNTTグループ内のソフトウェア・ネットワーク系技術者が集まるコミュニティで、誰が発表者になれるかは投稿されたProposalに対するコミュニティ内での投票によって選考される。 何を話したいか自分の中でも固まりきっていなかった上に、主催者の話をロクに聞いていなかった自分は小さい部屋で僕のことを知る人しか集まらない不人気セッションを勝手に想像しており、abstractを書く欄に「実世界で使われている分散システムを構成する際に理解してほしい議論についてkumagiが一人で滔々と語る。」という漠然とした説明を書いた。初心者にこそ聴いて欲しいという身勝手な理由でレベル設定をBeginnerにし、自己紹介欄に至っては本当は経
こんな記事が目に入った。 www.itmedia.co.jp 大雑把に完全に間違ったことを言っているわけでもないが、読んでいくといろいろ鼻につくところがあり、どのあたりから間違っているのかと自分に問いただすのは現時点での自分の知識を棚卸しするためにも有用かも知れないと思ったので一言一句漏らさず思うところを書いていこうと思う。 中には枝葉末節な難癖もあるので全部を真に受けない感じで読んで欲しい。 Cloud Spannerの特徴は、これまでリレーショナルデータベースで不可能とされていた「トランザクション処理の大規模分散処理」を実現したところにあります。 単一のトランザクション処理を分散して実行しているかというと、Spannerはトランザクションごとに担当のトランザクションマネージャがそのトランザクション処理全体を取り仕切って行う仕組みになっている。なので「トランザクション処理の大規模分散処理
TL; DR; 「神輿は軽くてバカがいい」というのは文字面以上に誠実な上司と社員の信頼関係 大きい企業ではとにかく会議が多い。僕の務めている部署では意図して会議を減らしているのでかなりマシな部類ではあるものの、その減っている会議の中でもときおり大きい組織らしい側面がひょっこり顔を出す。 それは、僕が普段から「ファントム」と呼んでいる現象である。僕の脳内ではFate/Grand Orderに出てくるファントム・オブ・ジ・オペラのイメージでだいたい合っている（画像はゲームから引用）。 会社は組織として動いているので、例えば「部」のレベルでの意思決定が必要な問題に対し、ヒラ社員が勝手に意思決定をすることは当然できない。 そこで部のレベルの承認を得るための道筋を、一個下の課のレベルで検討をするためヒラ社員と課長で会議する。その中での意思決定は「その場に居ない」部長の意思をみんなで想像しながら行う。
以下ポエム。 TL;DR; 悪者が居ない組織でも無能で勤勉な会議体は未知の力学で動き続けるのだ。 一般に、大企業に就職するのは簡単ではない。 知名度がある分、エントリーしてくる人間の数も多く自然と競争が熾烈になる。 その熾烈な競争を勝ち残った分、そりゃ優秀な人間が多いというのは採用を担当した人事の弁である。 実際に仕事で役立つ力と、採用の現場で重視されるコミュ力では尺度に乖離があったりで必ずしも現実はうまく回らない。 世の中のIT系の巨大プロジェクトは往々にしてデスマーチに見舞われる。 デスマーチに巻き込まれた末端の人間は目の前の個別の問題に対して「おいこりゃやべーよなんとかしないと」とか思いつつも末端故に全体を止めるような力を持ち合わせてない。 であれば、デスマーチの頂点付近にいる重役ぐらいにしかそれを止める強権を発動し得ないのではないかというのは妥当な考えである。だが世の中はうまく行か
次のページ
このページを最初にブックマークしてみませんか？
『Software Transactional Memo』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
