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

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

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

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

トラックナンバー

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

トラックナンバーは当然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知ってる人の書いたものに譲ります。適当にググってくだせい。

2018-01-12

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

ソフトウェア工学アジャイル 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

作者: 西村直人,永瀬美穂,吉羽龍太郎
出版社/メーカー: 翔泳社
発売日: 2013/02/13
メディア: 単行本（ソフトカバー）
購入: 5人クリック: 13回
この商品を含むブログ (33件) を見る

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

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

【追記】続きです↓

bonotake.hatenablog.com

【追記おわり】

2018-01-09

追記：ディープラーニングをやる人向け『仕事ではじめる機械学習』のオススメと注意点

ディープラーニング機械学習書籍

一昨日、このような記事を書きました。 bonotake.hatenablog.com

そしたらまぁ、自分の想像を遥か超える勢いでバズりまして。1日も経たないうちにブクマが軽く100を超えてしまいました（これ書いてる時点で171）。今まで、1記事につきブクマ1桁しかもらったことないんで、いやはや、びっくりです。

それ以外にも色々なところから反響ありました。

『仕事ではじめるディープラーニング』が出るらしいですよ皆さん！！！（と煽る業界の老害） https://t.co/bmPFQvbeF9
— TJO (@TJO_datasci) 2018年1月7日

あのTJOさんに煽られました。

他、紹介した『仕事ではじめる機械学習』著者の方々からも。

ディープラーニングをやる人向け『仕事ではじめる機械学習』のオススメと注意点 - bonotakeの日記
本にも書きましたが古典的なMLは特徴エンジニアリングがDLはネットワーク設計が大事ですね。教師データは規模の違いはあれど両方重要かなあ
2018/01/08 07:18

b.hatena.ne.jp

仕事ではじめるディープラーニング、めっちゃ読みたい

ディープラーニングをやる人向け『仕事ではじめる機械学習』のオススメと注意点 - bonotakeの日記 https://t.co/MFLWHmLgww
— ところてん (@tokoroten) 2018年1月7日

いや、ありがとうございます。

しかし、何でこんなバズったんだろう……ベストセラー本に手をつけたから？「ディープラーニング」ブームだから？最後に「俺が本出すぜ」アピールしたから？

一緒に本の企画している編集者さん（私の過去いた界隈では知ってる人は知っている、Sさんです）曰く

あのブログの煽り力が秀逸ですw

煽ったつもりはなかったんですが……まぁいいや。

それはともかく、ちょいちょい気になる反応も頂いたんで、ここに追記という形で言及しておきます。

書いてることがおかしい

昨日の晩くらいに、会社のSlack経由で、同僚の1人から感想もらいました。曰く、

なんかだいぶDL案件への感覚が違いますね

ええ〜(；´Д｀)

で、他の人も巻き込んでSlack上で議論してたんですが。とりあえず、その方から指摘されたのは2点。

ネットワークを論文のまま使わないことはよくある。むしろそのまま使うことのほうが稀
一番時間がかかるのは学習ではない

1つめについては、その方曰く

だいたいベースラインとしては、公開されたネットワークを使いますが、その後は、あれこれネットワークの層を削ったり、レイヤーを変えてみたり、分岐の場所を変更したり、っていうのをよくしますね。

との事。なのでこれについては、僕の経験不足だったということで、前の記事を訂正しておきます。（既に前回の記事内にも訂正を入れています。）

2つめについては、これは僕の本意ではないです。確かに「極めて時間がかかる」とは書いたし、感覚としてMLよりはDLの方が時間かかると思ってますが、そこが「一番」時間を食うというつもりではなかったです。

じゃあ、何が時間がかかるか、というと、前処理と学習データ（教師データ）の作成、評価指標の選定とテストデータの作成、あたり。

この辺は僕としても全然異存はなくて。ただ、この辺はMLもDLも一緒で、『仕事ではじめる〜』にも書いてあることそのものなんですよね。僕は『仕事ではじめる〜』と「違う」ところを書こうとしたために、そっちばかりが強調されて読めてしまったのかもしれません。

とりあえず、学習に一番時間がかかるわけではないことと、前処理、学習データの作成、評価方法のセットアップが一番大変というのはここに強調しておきます。

『仕事ではじめる〜』は読む価値がない？？

Twitter眺めてると、ごく少数ですが、僕の記事が『仕事ではじめる〜』を否定しているかのように捉えてる方がいましたが。

ぜんぜん違います。むしろみんな読めです。

肌感覚ですが、DLでも書いてあることの7割以上は通用すると思ってます。細かい個々の手法などはともかくとしても、プロジェクトの回し方や、ML/DLに対する基本的な考え方なんかはほとんど同じです。どうぞ誤解なきよう。

僕が企画してる本について

最後に、僕が今企画してる本ですが……皆さんがあまりに「『仕事ではじめるディープラーニング』読みたい！」とおっしゃってくださるので、若干気が引けてきました（笑）

一応お断りをしておきますが、そこそこ近い路線を狙ってはいますが『仕事ではじめるディープラーニング』そのものではないです。多少趣旨は変えているというか、違う攻め方をしたいと思っています。まぁそれなりにはタメになる本にしたいと思ってますので、どうか宜しくお願い致します。

今後、本の進捗などあれば、ここなどでちょくちょく書いていこうと思います。