bonotakeの日記

ソフトウェア工学系研究者 → AIエンジニア → スクラムマスター・アジャイルコーチ

ビットコインの価格が既に採掘の損益分岐点を下回り始めた件

友人と某所で話してて、ビットコインの価格が「採掘の損益分岐点を下回ったらしい」という話になり。

それは興味深い、と思って軽く調べてみると、こんな記事が↓

www.bloomberg.co.jp

この記事は先月のなので「半額になっても…」と書いてるんだけど、実はもうとっくに半額切ってる

記事によると、中国での採掘損益分岐点は6925ドルだそうだが、

https://invst.ly/6k5e1

これが過去24時間の、bitfinexでのチャート。真ん中のオレンジのラインがおおよそ6925ドル。1日の半分は下回ってることになる。ヤバイ。

まぁ損益分岐点を下回ったらすぐビットコイン死亡、というわけではないだろうけど、この状況がずっと続けば、あるいは更に価格が下回るようになれば、現在のビットコイン価格を支えている中国資本の多くが撤退することになるだろうし、そうすると価格はさらに雪崩式に下がっていく可能性も。

そして、流通すら困難なレベルで採掘者が撤退してしまうと、それこそビットコイン完全死亡のお知らせ、かもしれない。

ただし、先の記事によると、

中国の正規の電力料金は最高でも、1キロワット・時間当たり0.13ドルだが、電力業界の供給能力過剰のため交渉によっては同0.03ドルの低料金すら可能だとル氏は書いている。この場合、損益分岐点は3869ドルになるという。 (強調は引用者)

とのことなので、もし損益分岐点が現在既に3869ドルあたりまで下がってるとなると、さすがにその価格を下回るのはもう少し先の話になりそう。

【追記】ちょうど今日付けの記事で、上の記事の元ネタになってるBNEFが、こんなことを言ってる。

newspicks.com

【/追記おわり】

非エンジニアな初心者にもわかる(かもしれない)コンピュータの基礎を紹介する本

僕は普段、ディープニューラルネットワークをハードウェア(主にFPGA)上にコンパイルするお仕事をしてるわけですが。

昨日、同僚の女性(非エンジニア)のHさんから、

bonotakeさんがしてる仕事を理解したいので、入口的な、比較的簡単そうな、オススメの書籍を紹介してほしい

と頼まれまして……

いやー、DNNをFPGAに変換する業務を1冊で紹介できる本なんて、たぶん世界中のどこ探してもないでしょ……

てな感じで、どこが知りたいのかもう少し聞いてみると、要はハードウェアの知識がないので、そのへんの仕組みを知りたいと。

ということで、とりあえず紹介してみたのが以下4つ。

コンピュータの基本構成と動作原理〜知識編

qiita.com

本じゃなくてQiitaの記事ですけど、とりあえずHさんの反応を見るために紹介してみました。で、このレベルならまぁとっつきやすいと。

とはいえこの記事だけだと短すぎて、きちんと理解を深めるのは難しいですよね。たぶん。

ディジタル作法 −カーニハン先生の「情報教室」−

ディジタル作法 −カーニハン先生の「情報」教室−

ディジタル作法 −カーニハン先生の「情報」教室−

SNS経由で社外の知人に意見を求めたところ、オススメされたのがこれ。そしてこの本を担当した編集者も知ってる方(笑)

あのK&Rのカーニハン先生がこういう本書いてたんですね。オススメした知人曰く

リテラシ高い人でコンピュータだけは今まで知る機会がなかった、というケースにぴったり

だそう。裏を返せば、リテラシーがある程度要求されるということでしょうか。

ハードウェア・ソフトウェア・コミュニケーション の3章立てになってるとのことで、ハードウェアだけというよりは本当にコンピュータ全体を俯瞰する本て感じなんでしょうね。

CPUの創りかた

上記の本より、もう少しハードウェアに特化した本ということで、こちら。

CPUの創りかた

CPUの創りかた

これ、出たときは相当話題になりましたよね。中身と、あと表紙(笑)

今でこそこういう萌え絵が表紙の技術書ってよくありますけど、たぶんこの本が最初なんじゃないかなぁ。

当時も絶賛されてましたが、とっくに絶版になったと思ってたら未だに売れてるんですね。アマゾンでベストセラーだし、レビューでも絶賛されてるので驚きました。

むしろ、表紙が萌え絵の本が普通になった今だからこそ、中身がきちんと評価されてる、のかもしれません。

コンピュータシステムの理論と実装―モダンなコンピュータの作り方

コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方

コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方

おそらく、『CPUの創りかた』の類書。オススメした理由は、僕がAmazonにオススメされたからw

とはいえ名前だけは前から知ってて、気にはなってたんですよね。こちらもベストセラーだし。

『CPUの〜』に較べると新しく、2015年発行の本です。で、邦訳はオライリーですが、原著はMIT Press。

The Elements of Computing Systems: Building a Modern Computer from First Principles (MIT Press)

The Elements of Computing Systems: Building a Modern Computer from First Principles (MIT Press)

なので、基礎から入っている入門本とはいえ、結構本格派の本といえるかも。NANDゲートの仕組みから入ってOSまで説明するという、結構基礎からがっつり勉強する感じではあります。

てな感じで

オススメしてみたのはいいものの、CS系学科出身のエンジニアが、非エンジニアの方に本を勧めるのはやっぱり難しいです。さじ加減がわからないですからねぇ。あんまり「非専門家にもわかりやすく」書きすぎた本だと、ちゃんとした理解にならないことが多いし。かといって数式バリバリ並べるような本も厳しいだろうし。

そんなあたりで、若干苦し紛れに勧めてみた感じではありますが、どうでしょう。Hさんの読んだあとの感想が気になります。

機械学習工学の話:会社でブログ書いた

先週、1/18〜19にあったウィンターワークショップ2018の参加報告記事を、会社ブログに書きましたんで、こちらでも備忘録がてら紹介。

参加報告に絡めて、今やってる機械学習工学とは何なのか、について語ってみました。

leapmind.io

なお、当日の様子や議論内容は、こちらにまとまっています。

スクラムは属人性を排除しない??

今朝書いた、下記記事の続きです。 bonotake.hatenablog.com

一旦は「Facebookで議論すんのしんどいから」という理由でやり取りを打ち切ったはずでしたが、この記事に対してアジャイルコーチの守田さんが「SCRUM BOOT CAMP THE BOOKをお読みなら話が早い」と仰って、結局その後もFB上にて守田さんとやり取りしてました。

結構長々とやり取りしたんですが適当にまとめます。

前回記事のざっくりした要約一部切り抜き

Scrum*1で「チーム内の属人性は排除する」と考えるのは誤りらしい。本当?

守田さんのたとえ

従来型バッチ処理の担当者に必要なスキルと、バッチ処理技術ルールをドキュメント化して、属人性を排除する。

アジャイルバッチ処理をペア作業などで実施して、誰かもう1、2人くらいは分かるようにする。

よくある誤解アジャイルだから、チーム全員がバッチ処理を書けるようになるべき。

要は、各メンバーが多能工化するのはするんだけど、エクストリームに何でもできるようになる訳じゃないと。 ある程度はスキルを共有して、共有できた範囲で属人性を排除するということのようです。

トラックナンバー

blog.fenrir-inc.com 「ある日突然トラックに轢かれてもプロジェクトが停止しないメンバーの数」らしい。(後述する同僚のEは初めて知ってめっちゃウケてました。) 僕はとっさに「トラック転生するから何人でも大丈夫では」とか考えてしまい(ry

トラックナンバーは当然1だとまずくて、ただ2, 3確保すればとりあえずはOK、なんでしょうか? 言い換えれば「1人の人が2,3のスキルを身につけるって感じ」だと。

この程々感がまぁ、アジャイルっぽいっちゃ、アジャイルっぽい(小並感)

スキルマップ

www.ryuzee.com

似たようなものは BOOT CAMP本でも登場してました。

なので、「チーム内の全員が同じスキルを持つ」という前提はないし、「属人性の排除」でなく「スーパーエンジニアを評価して、その人から学ぶ事で、チームの能力を向上させる」と捉えるべきである、と。

閑話休題:Regional Scrum Gathering Tokyo 2018

2018.scrumgatheringtokyo.org

今日たまたま、このイベントで「Scrumと属人性」にまつわるセッションがあったそうで。

チェックしてた守田さんによると 「とことん掘り下げた尖った人を集めて、ポートフォリオで(必要なスキルを)揃える。そうでないと、今時の次々に新しい技術やフレームワークがでてくる状況に対応できない。」という話だったようです。ふむ、見事に今回の話題につながっておる。

同僚のスクラムマスターE登場

とまぁ、基本守田さんが色々と解説してくれ、まぁ肯けるところは肯けるし、ふむふむと僕がもっぱら聞き役になっていた感じではあったんですが。

ここでふと、会社で隣に座ってる同僚のEにこの話を振ってみました。というのも彼、前職ではずっとScrumで開発を回しており、その経験から、来月からの我がチームでおそらくスクラムマスターを勤めることになるだろう人物だったからです。

拙い英語で*2「チーム内の属人性とかスキルの偏りとか、どう考えるべきなの?」と聞くと、

「traditionalな*3Scrumでは、チーム全員同じスキルを持つって考えるのが基本だよ」

うぉーい話がひっくり返っとるやないかーい!

Eによれば、チーム内の各人のスキルの持ち方は”T-shape”であるべき、なんだそう。つまり1点では深い専門知識を有する(かもしれない)けど、その他のスキルについても広く浅く有しているべき、だと。

あれー話がおかしくなったぞ、と思いつつも。 ふとこのとき、以前職場でScrum導入するかどうか皆で話し合ったときの話を思い出したんですよ。

そのとき別の同僚が「チーム内で各人が持ってるスキルも熟練度もバラバラなのに、どうやってチームのベロシティ*4を評価できるの?同じタスクでもAさんがやるのとBさんがやるのとで速さ違わない?」と質問して、それに対するEの回答が「Scrumではみんな同じスキルを持つと考える」だったんです。

これこそ、僕が「チーム内全員同じスキル」が非現実的だと思いつつ納得した瞬間だったんですよね。彼の説明は筋が通ってる。非合理だけど。

てか、そう考えないと「ベロシティ」って概念こそが非合理になってしまう。

守田さんの反論と旧友N

一応Eが話したことも、かいつまんでFBに書いたんですが、守田さんの反応は

誤解と思われます。

まぁ、話食い違ってますもんね、明らかに。

その後も色々なんで「誤解」か説明してもらったけど、ここではざっくり省略。

僕は結局、2つの「正解」の前にわからなくなってしまった、というのが正直なところで。 守田さんとは、そのうちEも入れて一緒に議論&情報交換しましょう、といった感じで話は終わったんですけども。

晩になって、ふらりと旧友のNがそのスレッドに現れ、こんな書き込みを残していきました。

N おそらく言うまでもなく、「チーム全員全知全能」が理想形で、その場合当然属人性は排除されてて、現実そこに至らないときに、個々人の能力を広げてカバレッジを上げるのか、マニュアル化でスキルがなくても出来るようにするのか、業務をスキルがなくても出来る範囲で設計するのか、アプローチが違うだけなんでしょう。実際にはどのアプローチも程よく必要だと思いますが。

何やらうまいことまとめおって。

結局N的視点から言えば、(前回の記事の話に立ち戻って)アジャイルも伝統的WFも、「アプローチの差」でしかないと。 アジャイル信者でも否定論者でもない僕からすれば、この立ち位置が一番バランス取れてて腑に落ちる感はありました。

まぁやっぱ、Scrumは一見シンプルなようでいて、奥が深いというか底が知れないというか。イマイチまだ疑問は残ったままではありますが、そのうち「やればわかる」的境地に達する……といいな、とは思っています。

【追記】 西尾泰和さんが僕の前回の記事の記事を読んでくれて、以下みたいな記事を書いてくれました。 scrapbox.io 「二種類」とも、Nの言及した「アプローチ」に含まれていますね。

【追記おわり】

*1:見出しにはカタカナで「スクラム」としましたが、どうも個人的にはScrumと書くのが好み(というかカタカナ書きがイマイチ好きじゃない)ので本文はScrumです。でもスクラムマスターは「スクラムマスター」です。統一感なくてすいません。

*2:彼は東欧人で、うちの会社に来るまではずっと英国で働いてました。なので彼とは基本英語でやりとりしてます。「属人性」とか訳すのめっちゃ辛かった。

*3:彼は結構、Scrumの亜流というか派生版というか、そういうものにも色々詳しいようなのです。

*4:スプリントごとにチームがこなせる仕事量のこと。間違ってたらスイマセン。正確な定義はちゃんとScrum知ってる人の書いたものに譲ります。適当にググってくだせい。

ソフトウェア開発での属人性は排除すべきでない??

昨晩、このような記事を読みまして。

ascii.jp

この中に、このような話が。

江草氏がたどり着いた答えは、「属人化を排除するのはよくない」だ。少人数のエンジニアが開発したものが大規模に普及している現実がある。

これについて、僕がFacebookの限定公開の記事にて、こう書いたんですよね。

ソフトウェア工学の基本思想とは相反するんだけど、一面の真実なんですよね……

すると、守田憲司さん(アジャイルコーチな方)からコメントが。

一言で「属人性の排除」と言ってもいろんなコンテキストが有りますが、一昔前のソフトウェア工学で言われた属人性の排除は、現在では概ね否定されていて、相反するって事は無いと思います。

(強調は筆者)

おおう、これは、ついこないだまでソフトウェア工学の研究者だった者にとっては聞き捨てならないぞ。 ということで掘り下げて聞いてみました。以下ログ。

Takeo Imai > 現在では概ね否定されていて

というのは、どのへんで言われてることなんでしょう?

Takeo Imai 僕自身、ついこないだまでソフトウェア工学の研究者だった(今も研究自体は続けてる)ので、ちゃんとしたソースを知っておきたいです

守田 憲司 端的には、CMMIなどは使われなくなって、アジャイル開発が一般的になってるという事です。

アジャイル開発自体は、現実には、従来型以上に属人性は排除されますが、ちょっと意味が違います。この記事のように。

従来のソフトウェア工学の流れも続いてると思いますが、それら全体が使われなくなって来ていると思います。

Takeo Imai > 現実には、従来型以上に属人性は排除されますが、ちょっと意味が違います。

この辺がよくわからなくて、もう少しきちんと教えて頂ければ……たとえばScrumだと、基本的にチームの構成員は「みんな同じスキルを持っている」(=チーム内に属人性はない)という考え方がベースにあると思いますが、これはどう「ちょっと意味が違」うのでしょうか。

守田 憲司 『Scrumだと、基本的にチームの構成員は「みんな同じスキルを持っている」(=チーム内に属人性はない)という考え方がベースにある』というのはよくある誤解です。

基本的にクロスファンクショナルチームなので、混成員のスキルが様々な事が基本です。

まぁ典型的なWFと比較すれば、多能工を志向しますが。

守田 憲司 大きな違いは、ドキュメントでしょうかね。従来型だと、ドキュメントを整備して、それに沿って作業すれば誰でも、作業ができる事を目指しますが、アジャイル開発では、そこが暗黙知になってる事を許容する代わりに多能化して、誰か居なくなっても大丈夫なようにします。

この時点で、「FBでやり取りするのは難しい」ということになって、「またお会いしたときに!」となって終了したのですが。

僕もわかったようなわからないような、何とももやもやした感覚。

ざっくり要約+補足すると、

  • 今はCMMI(的な手法・プロセス)は使われなくなり、アジャイル開発が一般的
  • アジャイル的な手法では、属人性の排除はなされるけど、その考え方が従来型のソフトウェア工学のものとは違う
  • Scrumでの「チーム内の属人性は排除」は「よくある誤解」

僕自身はそこまでアジャイル信者でもない(否定論者でもない)ので「アジャイル開発が一般的」と言われると、ちともにょってしまうのですが。ただ、より多くの現場に普及しつつあるのは確かにそうでしょうね。

結局、誤解を恐れず、守田さんの言葉をざっくりまとめると要はアジャイルでは属人性は排除されない」ということでよろしいか(誰に聞いてる?)

で、Scrumでの「チーム内の属人性は排除」は「よくある誤解」とあって、いや実は僕自身、Scrumに違和感感じていた点でもあるんですよね、このへん。 ただやっぱり、説明されてもよくわからず。「多能工を志向」すると、究極的には全員が同じスキルを持ってしまわないのだろうか……

例えば、以下の記事。 qiita.com ここには、

スクラムでは生産性を上げるためにも「自立や向上」を目指している。

そのためには、属人化を出来るだけ排除する必要がある。

とあって、属人性を排除してるように読めなくも。

あるいは以下。

デメリットとして最近感じているのは属人化を排除することで同時に個々人の責任感も削り落としてしてしまったのではないかという点である。

属人化の排除と責任感のトレードオフについて - MogLog

もっとも、「属人性」と「属人化」がまた違うものを指しているような気もして、そこがミソなのかもしれないけど。守田さんのいう

誰か居なくなっても大丈夫なようにします。

は、「属人化の排除」なのかな。

それに、僕がScrum勉強した(うちの1つの)この本を今ざっと読み返すと:

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

Scene No. 22. さまざまな状況に対応する この作業は苦手です…… に、チーム内の各人のスキルを書き出す、なんてやってるから、「全員が同じスキルを持つ」っていう前提ではないようではある。

ううーん、やっぱりよくわからん。今度守田さんにお会いしたときに、がっつり聞いてみよう。

【追記】続きです↓

bonotake.hatenablog.com

【追記おわり】

注:bonotakeは、amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、 Amazonアソシエイト・プログラムの参加者です。