Re: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている
この記事を読んだ。
よーある話だなと思いつつ、「業務委託はダメで、社員ならOK」という話はちょっと話が雑だなあと思ったので、コメントを書く。
スクラムチームで人の出入りが激しいとキツイ
これはそう。 ただ、スクラムかによらず、出入りが激しいとキツイけど…
業務委託では、高パフォーマンス人材は単価つり上げがきつく、結果契約打ち切りになる
実際の事象としてはよくある話。ただし、業務委託のみの話ではなくて、社員でも「会社に不満があったからやめた」は良くある話。
たぶん、ここが気になるのは、このあたりの違いだとは思う。
- 報酬の見直し頻度
- 社員だと給与体系の見直しが年1回であるのが普通
- 業務委託だと契約期間ごと（業界慣習的に3カ月単位が多い認識）
- 条件交渉者が本人なのか営業なのかの違い
- 営業の仕事は売上を上げることなので、当然ガンガン言ってくる
- 対して社員が自分の雇用条件について、個人の資質はあるが、外部の営業と比べると全然よわい
業務委託は完全に商取引として行われるので、条件交渉が不調に終われば即撤退となる。もちろん、社員も不満があれば辞めていくのだが、業務委託の出入りの頻度に比べれば相当頻度が低いのはそうだと思う。
業務委託の単価を上げないためには
何を言ってるのかわからない…。社員は賃金を上げない前提なの？？？？？、と書くとちょっと意地悪だろうか。
まあ、会社というか予算執行者の思考を考えるとわからんでもなくて、
- 社員の場合は賃金上昇率も含めて、予算計画を立てやすい
- 業務委託の場合、想定外の条件を提示されて予算額を超えてしまい、契約解除せざるを得なくなりがち
という違いかと思う。
全部直接雇用にしろ
これは日本の雇用環境（解雇規制）を考えると、一概に正解とは言えない。
元記事でも言及はあるが、業務委託であれば気軽に契約解除できるのに対して、社員であれば配置転換が原則となる。業務委託であればこそ、気軽に人を入れられるメリットがあり、トレードオフとしてコストは高くなる。
何がわるい？
大前提として、
- チームメンバーの離脱は減らしたい
- スキルが上がれば、契約形態に関係なく、報酬は上がるべき
これがある上で、問題となるのが、
- 業務委託では予算予見性が低く、契約改定のタイミングで離脱が発生しやすい
という点かと思う。単価が上がること自体は仕方がない。
この問題は、業界の商習慣から発生するギャップによって発生する。
- 受託側は単価を上げたい
- 対して発注側は単価を抑えたい
- 初回取引では期待値がわからない分、初回取引時は発注側がつよく出られるので単価が低くなる
- 契約更新時、抜けられては困るような人は受託側が強く出られるので、単価アップ要求が出る
- 単価アップ要求が折り合わなければ、契約解除
というロジックになるので、どちらが悪いというか、これでやってたら絶対にここから変わる余地がない。
業務委託ではこれが顕著だが、社員でもこれに似たことは発生していて、単にサイクルが長いか短いかの違いである。
積極的に契約に関与していくしかない
この手の話では散々言われていることだが、チームが自分達の契約に積極的に関与していくしかない。
業界慣例通りにダラダラ契約してるから、問題が発生し続ける。だから理想は、チームとしてチーム内の予算決定権と人事権を持つことである。
特に初回取引時は、発注側の予算感や受託側の希望単価についてちゃんと話す
- 初回取引時、受託側は暗黙的に販促費込みの割引単価を提案するスタイルの営業が多い（業界の慣習）
- 発注側は割引単価に悪ノリしない
ここをクリアにしておくことで、予算予見性が上がる。希望額を聞いたうえで「初回はスキルレベルがわからないので安くしてくれ」というのは応相談できるレベルの話である。
柔軟に契約条件を探る
もちろん受託側の希望単価では折り合わない可能性はある。そこで終わらせずに、週3日稼働ならどうかとか、業績連動報酬ではどうかとか、交渉に使える材料は色々ある。
自分達で受託会社を開拓する
大手であったり古臭い営業スタイルの受託会社では、そもそも柔軟な契約条件を受け入れる可能性が低い。
こういった会社から提案を待っているだけでは解決しないので、柔軟に対応してくれる会社（フリーランス含む）を積極的に開拓していくしかない。もちろん、相応の労力が必要になるが、楽して都合の良い会社を集めたいというのは虫がいい話である。
さいごに
業務委託であっても、柔軟に契約条件を相談できる相手であれば、ちょっと話が折り合わなかっただけで即契約終了になるとは限らない。
業務委託に不満があることは事象として受け止めたうえで、実は自分達でそういう相手ばかりを集めてるような環境になっていないかは疑ってみてもいいかなと思う。
補足：弊社デンキヤギでは受託も発注もこういう感じの契約が多く、数年単位でお付き合いしてる事例も複数あるので、再現性のある話。
NGK2021SでHaxe最新事情の話をした
要点は、
- もしHaxeの最新情報が欲しかったら Haxe Roundup を見ような
- Haxeはゲームクライアントでの採用事例が多いけど、Webフロントエンドでの採用は減り気味
という話です。あと、少し説明を端折った内容としては、JVMターゲットに関して、
という感じです。
Webフロントエンドについては、TypeScriptがデファクトスタンダードだが、静的型というイディオムをどうしても受け付けられない人がJavaScriptで書くというの多数派の世界です。何らかの信条がある少数派が、Haxe/JSに限らず、Scala.jsとかElmとかBlazorとか、その他の手段を取っている世界でもあります。
スライドではあまり触れませんでしたが、私がHaxe/JSでWebフロントエンドを書いている理由を補足すると、
- TypeScriptは機能不足だし、型システムに無理がありすぎると思っている
- 代数的データ型（もっというとGADT）とパターンマッチがないし、マクロというか、コンパイル時に型安全にAST変換する機構がない
- 過去のJavaScriptで実装されたライブラリの「何でもありのインターフェース設計」に対して無理やりにでも型がつけられるようにしているせいで、複雑怪奇すきる（JSに型を付けるという考え方が出自なので、この方向性自体は間違っていないと思うが、Not For Meという話）
- TypeScriptはコンパイルが遅い
- JSのツールチェインにそれほど興味がない
- 私のメインの開発領域が業務システムやPWAなので、JSのダウンロードサイズを数10KBレベルでカリカリにチューンすべき！みたいな意識が薄い（もちろん小さいに越したことはない）
- ブラウザ上で動作するゲームの開発に関わった時に、突き詰めてもビルド後JSサイズが圧縮前で15MBを切れなかった（それでも当初から7-8分の1ぐらいにはした）のだが、そこに対してはほぼノークレームだった経験から、かなり認識が変わってきている
- もちろん、10msec単位の表示遅延が発生すると、売上に直結する分野があることも認識しているので、活動分野が違うよねとしか
- Haxe 4以降で不満点がかなり改善されてきている
という感じで、TypeScriptに不満があるので、消去法と過去の経験値からHaxeを選んでいるという状況です。Haxe/JSでWebフロントエンドを開発すること減少傾向にあることは、取り巻くを環境を考えると仕方ないなあと納得できる面と、必要な材料が揃ってきたから死んだ扱いにするのも違うかなと思います。TypeScriptが嫌だというケースにおいて、Scala.jsと同列ぐらいには候補と考えても良いんじゃないでしょうか。
ちなみにデンキヤギという会社では、Haxe/JSとScala.jsの人口比はほぼ同じです（アルバイトはカウントしていない）。その他には、F# Boleroで開発している人間もいます。
もしHaxeが突然死するようなことがあれば、普通に考えればScala.jsに行くかなーという感じですが、私一人で勝手にやるとしたらNimに強い関心があります。Haxe 3にはかなり不満があったので、Haxe 4が来るのがもっと遅かったら、今頃はNimの人だったかもしれません。
とはいえ、TypeScriptは絶対やらないということはなくて、必要があればTypeScriptもやる可能性はあります。
内閣府「規制改革・行政改革に関する提案」に「電子帳簿保存の申請方法緩和の提言」を投げた
これの流れでもう1つ書いた。
内閣府「規制改革・行政改革に関する提案」にPC等の固定資産税に関する提言を投げた - terurouメモ
提案事項名
電子帳簿保存法の申請が複雑かつ制限が強すぎる
提案の具体的内容
■申請内容の簡略化
複数ある申請書式を1つにまとめ、記載内容を簡略化する。
https://www.nta.go.jp/taxes/tetsuzuki/shinsei/annai/denshichobo/mokuji.htm
■申請時期
現行の「3カ月前までの申請」を、新設法人の届け出と同様に「電子帳簿の保存開始から2か月以内」のように事後申請も許容する。
■備え付け開始日の制限撤廃
「原則として課税期間の初日」という制限を撤廃する。
提案理由
電子帳簿保存法の運用については法改正で規制が緩和されてきていますが、申請の部分が複雑かつ制限が強く、電子化の阻害要因となっています。
・備え付け開始日が期初にしか設定できない
・備え付け開始日の3カ月前までに申請を提出しなければならない
・申請書類が、電子化環境が完成していないと記載できない内容になっている
ということから、現実的には1年ほど前から準備をしないと開始ができません。日程ありきで失敗不能な導入計画を立てざるを得なくなるため、プロジェクトが大ごとになってしまいます。
零細規模の弊社でも4年ほど前から検討はしていますが、導入に至るどころか、試行すら開始できていなのですが、これが最大の要因です。
制度設計として、申請順序が逆転させ、次のような流れとすべきです。
・思い立った時に電子化環境の準備と試行（課題の洗い出し）を開始する
・実運用が可能だと判断した時点を備え付け開始日とする
・税務署に事後申請を行う
当該規制の根拠となっているもの
法律や政令
上記の具体的な根拠法令等
内閣府「規制改革・行政改革に関する提案」にPC等の固定資産税に関する提言を投げた
これ。
応募数が多く、いったん2020年11月27日 18時で受付が終了するとのことなので、忘れないように提言を出した。ちゃんと推敲せずに一気に書いたけど、まあ趣旨は伝わるやろ…。
追記：ブコメもされてるけど、最後の国際競争力のところは飛躍があるので、元気がある人は提言する際に修正してくれるとなお良いです（このあたりは推敲不足…
提案事項名
デジタル機器の固定資産の扱いが原因で、IT化・生産性向上・国際競争力向上の阻害要因となっている
提案の具体的内容
デジタル機器（PC、サーバー、タブレット、スマートフォン等）の減価償却資産の特例を設置し、法定耐用年数も短縮する。
■減価償却資産の特例（一般企業向け）
企業規模に関係なく、デジタル機器は30万円以下は損金算入できる少額減価償却資産とする特例を設ける。
■減価償却資産の特例（IT企業向け）
企業規模に関係なく、デジタル機器は50万円以下は損金算入できる少額減価償却資産とする特例を設ける。
■法定耐用年数の短縮
PC・タブレット・スマートフォン：現行4年→2年
サーバー：現行5年→3年
提案理由
デジタル機器は、会計処理の都合から、消耗品扱い（10万円、特に事務向けで多い）または一括償却資産（20万円、3年均等割り）の範囲内で調達されることが一般的となっています。この金額を超えないように買い控えが発生していることが実情です。
特に事務用として使われることが多い10万円以下のPCでは、処理性能が不足しているため、処理時間が大きくなってしまい、生産性を低下させています。また、性能不足が原因で、有用な機能が使用不能であったり、要求スペックを満たさないためソフトウェアの新規導入ができないなど、生産性向上の道も閉ざしている状況です。
さらに、デジタル機器の進歩のスピードから見て、法定耐用年数が長すぎるため、生産性の低い機器が更新されずに長く使用されてしまっていることが、さらに問題を大きくしてしまっています。
また、IT企業の場合では、開発用途のデジタル機器を購入する必要がありますが、
・20万円（中小企業特例でも30万円）以内で購入できる機材では性能不足であったり、最下位モデルでもこの予算額で購入できない機材も多い
・2年程度で性能不足となってしまっており、1年で更新することも普通（固定資産というよりも消耗品的な性質が強い）
ということから、法定耐用年数より大幅に短い期間で機材の入れ替え・処分が発生するため、会計処理の煩雑化を招いてしまい、結果的にIT企業であっても設備投資に消極的になってしまう実態があります。これが国際競争力の足かせになってしまっています。
当該規制の根拠となっているもの
法律や政令
上記の具体的な根拠法令等
「零細企業経営にはほとんどの意見が参考にならなかった話」を書けと言われたので
書けと言われたので、雑に。人に意見されたことはあまりないつもりだったんだけど、思い出してみたら、結構あったような気がしてきた。
零細企業経営にはほとんどの意見が参考にならなかった話 https://t.co/sUpRX51RJq ポエム書いた。
— V (@voluntas) 2020年11月22日
これは是非 @terurou にも書いていただきたい。
— V (@voluntas) 2020年11月22日
人の意見は参考になるか？
基本的に利害関係のない人間の話は「参考にならん」でいいと思う。逆に利害関係のある人間の話は重要で、それは社員だとか、顧客だとか、株主だとかになってくる（うちは株の100%が自分が持ってるので、株主って自分ですねになるのだけど）。
世間には「勝ちに不思議の勝ちあり、負けに不思議の負けなし」という良い言葉がある通りで、
- 成功体験をもとにしてくる意見はまず参考にならん
- 分析付きの失敗体験からなら役に立つかもしれない
ぐらいの話かなと思う。
とはいえ、鵜呑みにするのは「まず無駄かな」というのが7年ぐらい会社経営してた実感。
「百聞は一見に如かず」「やればわかる！やらなければ、一生わからん！」という素晴らしい言葉がある通り。やったことがある人間の意見ですら、その人間とは条件が同じではないわけで、やらんとわからん。
とはいえ、そもそも机上レベルですら成立してないものをやったらアカンです。
助成金を取れ
創業支援機関みたいな人たちが勧めてくれることが多い。お墨付きが付くとかなんとか。
「やってもろくな事にならんぞ」という話は前に書いた。
自社製品の方向性に対してのご意見
うちは今のところ、成功している製品がないので、まあそれこそ参考にならん話ですが。
最初期立ち上げ時のコンセプトに対しては、褒めてくれる人もいれば、ダメ出ししてくる人もいる。で、参考になったかを答え合わせすると、「両論、ほとんど役に立たなかったな」というのが正直なところ。
私個人の経験値としては、人の話を鵜呑みにしすぎてコンセプトがブレまくった上に重厚にしてしまった感が非常に強い。直感を信じてシンプルにやって、ダメならどうせユーザーも居ないんだから、ピボットしまくって1人でもユーザーを付けることを最優先にした方がよかったなとは反省している。
とはいえ、全ての意見が参考にならなかったかと言われるとそうではなくて、id:dominion525 っていう人に「このサービスが終わったときに、サービス内で作ったコンテンツはどうなるの？」という趣旨のこと言われたことだけは強く印象に残っていて、これは今後意識したいなと思っている。ただ、個人的に印象が強いという話であって、売上面ではほとんど役に立たない意見である気もするけど。
あ、実際の顧客からの意見は別かなと思う。これも全部鵜呑みにしてはいけないのだけど、利害を考えながら。
海外に目を向けろ
手段の話なので、必要なら言われんでもやるんちゃうの？
聞いても無駄の典型ポイントっぽい。私は幸いなことに言われたことがない。
資金調達しろ
手段の話なので、同上。これは言われたことがある。
銀行から借りろ、借りるな
手段の話なので、同上。これもどっちも言われたことがある。
キャッシュフロー上、必要であれば借りないといけないし、別に借りなくても回るんだったら借りなくてもよい。「急に借りようと思っても銀行は貸してくれないぞ」というのはほとんど間違いで、そもそも借りられないような経営状態でない限りは、2週間もあれば融資は実行される。「銀行は晴れの日に傘を貸す」という言葉の通りかなと。
ちなみにうちは、正直借りなくても回るのだけど、とはいえ潤沢なキャッシュがある訳でもないので「今の金利なら借りても誤差だなー」という気持ちで借りている。金利が無駄になってると言えばそうなのだけど、銀行口座に大きなお金が入ってることによる精神安定効果は非常に大きい。今の利率であれば、例えば1,000万円借りたとすると年に10-20万円ぐらい（月に1万円前後ぐらい）の金利が発生するのだけど、これが精神に安定をもたらす金額として高いとみるか安いとみるかは、人それぞれかなと思う。
営業を雇え
この手の話が出たときに「営業雇いたいんだけど、今の会社の規模だとペイできないんですよねー」って言うと、話が終わる。
類型で、このビジネスに精通した人間を雇えと言われるのだけど、「じゃあ紹介してくれ」って言うと何も返ってこない。
バックオフィスを雇え
すごく総務を雇いたいんですが「どう雇ったらいいですか」って質問をしても、みなさん参考にならない回答しかしてくれません。
本気でナイスソリューションを教えてください。オンラインアシスタントみたいのは残念ながらニーズに合わないし、身内を雇えっているのは既に嫁が役員になっていて経理と労務の一部はやってるので、もう結構です。
人を増やせ（会社の規模を大きくしろ）
たぶん言われてるのだけど、初めから聞く耳がない部分なので、記憶してないのだと思う。
きれいなオフィスにしないと企業イメージが上がらないぞ
デンキヤギっていうふざけた名前の会社で、企業イメージもクソもある？
社員からは「固定費上げるとか馬鹿じゃないの」的な反応があり、こっちが正しいと思ってる。
なんで名古屋なんだ、東京に出てこい！
はい、そうですね。
まあ実際、顧客は東京に多くて、以前は初回顔合わせ程度までは東京に出向いてたのだけど、いわゆるアフターコロナとか言われるご時世になったら、全部リモートで済むようになってしまった。
あと、うちの社員は結構優秀なんだけど、東京拠点では雇えていた感じはしない。
社会に還元しろ
これは何度か言われた記憶はある。ちゃんと話を聞いたことはあるけど、零細の人間にこういうことを言ってくる人間は、単に説教したいだけの人なので、話しても時間の無駄じゃないすかね。
社員をもっと働かせろ
一時期、VCめぐりしてた時期があって、その時にこういう趣旨の話を言われたような記憶はある。アホか。
なんか役になったご意見はないの
自営業で一人親方の父親に言われた「学生からいきなりフリーランスになるのはやめとけ。最低でも2-3年は勤めて業界の商習慣ぐらいは知っとけ。できれば営業先を確保してからの方がいい」は、今思い返せば確かにそうやなと思うし、過去に滅んでいった人間を見てきたのだろうなあ、と。
会社経営で役に立ったのはこれぐらいかなあ。
後から追加した分。
社長がプログラミングなんかするな
これは本当によく言われるのだけど、最初から無視してるやつなので失念してた。
予算執行権を持ったうえでプログラミングするには、会社経営者になるのが一番手っ取り早いだろ、何を言ってんだ。
そもそも、零細企業で社長が現場で働いてない会社なんかあるの？（年食って引退したとかはあるかもしれないけど
一つだけどうしても無視できんなというコメントがついてたので、追記。
零細企業を想定してる人はVCに来るな
id:andalusia 零細企業経営としては全く正しいと思う。ベンチャーとしては間違っているので、VCには来ないで。お互いに時間の無駄。
会社というのは事業をやることが目的で、VCから資金調達してバーンレートがどうとか、零細でやるとかは手段の話に過ぎない。とはいえ、事業には資金がいる。
会社を立ち上げたときに、零細企業的に継続的にやっていくのがいいのか、スタートアップ的に短期に資金をぶち込んでやるのがいいのかっていうのが判断がつく人間って、そう多くないと思うんよね。そら、資金が多ければ選択肢が増えるので、多いに越したことはない。
うちは会社の立ち上げから4年目ぐらいまで（うちは今8期目なので、結構最近まで）、数はそこまで多くはないがVC巡りをしていた。ただ、ネタがVC受けしなかったというのもあるが、それ以上に、想定顧客に持っていっても現場では好反応な反面、予算執行者には全く話が通じないということが続き、売るには数年単位で待たないとダメだなという判断をした。期を待っている間の資金をVCが出してくれるとは到底思えないので、現状は零細企業という手段になっている。
で、7年ぐらい受託と自社開発を並行させるのをやってると、経験値も資金力もついてきて、別にVCから資金調達しなくても回せるようになってきてしまった。なので、ここしばらくはVCに出向いていない。
これはあくまでもうちの現状であって、事業には資金がいるので、投資側が最初から来るなと言うスタンスを取ることには疑問符がある。
「自社製品の方向性に対してのご意見」にもかかる話だけど、後からの答え合わせをすると、VCからの意見を聞きすぎたというのが実感としてある。このコメントの人がVCの中の人なのかは知らんのだけど、「お互いに時間の無駄。」っていうんであれば、VCは出資する価値がないなと判断したときは結果だけお伝えして、意見を伝えるのは時間の無駄なんじゃないですかねえとは思う。
『2時間スプリント』とフルリモートワークなシステム開発
デンキヤギという会社で『2時間スプリント』が定着してきたので、その話でも書きます。
2時間スプリント？
みなさん、すでにスクラムで開発してますよね！
ぶっちゃけ、スクラムがよくわかってなくても、とりあえずスプリントと称して開発のメリハリをつけるために、1週間なり2週間なりで区間を区切って開発をしていくのは、普通にやってるんじゃないかと思います。
2時間スプリントとは、その期間を2時間にするという話です。
スプリントを超短期サイクルにすること自体は、47機関の人たちがオリジナルだという認識です。このあたりに本家の情報がまとまっています。
2018年に実際に47機関の人たちのチームに入って1時間スプリントで働くという機会があって、それ経て、デンキヤギでもパクって導入しています。本家ではのちのち15分スプリントになっていったらしいんですが、うちはうちの実態に合わせていったところ、2時間スプリントという形に落ち着いてきました。
後段でも言及しますが、1時間にするか、2時間にするか、はたまた15分にするかは、チームの状況や練度によって異なってきます。ただ、一般的な常識で考えるスプリント期間よりも超短期にすることが重要な要素の一つとなります。
超短期間スプリントを導入するメリット
成果報告のタイミングで「えっ、まだ完了してなかったの？？」「えぇ…、その作業をやる必要は一切なかったんでは…」「何でもっと早く相談しなかったの？？」ってなってる場面に出くわすことありませんか？こういうことに身に覚えのあるチームであれば、導入を検討する余地が十分にあります。
私は超短期間スプリントの本質を「時間経過をトリガーとして、他動的かつ適切な方法でチーム内で情報を同期し、高頻度に計画を見直す」ことだと認識しています。
いわゆる報連相とかいうやつを各自の判断でやらせると、強く属人性が発生します。結果、適切に動ける人と破滅する人間に分かれていきます。
残念ながらチーム内に破滅するタイプの人間が出てしまうと、チーム全体の生産性を低下させる要因になりがちですし、当人の人事評価も自己評価も下がってしまうし、全くいいことがありません。破滅しない側の人間であっても、忙しくなってくると報告が滞りがちになることは多々あり、結果的にチーム全体の生産性を低下させる要因となってきます。
この部分から属人性を排除すれば、作業ロスを減らすことができるはずです。みなさんが大好きなトヨタ生産方式で言うところの『ムダ取り』を、作業プロセスに対して適用しようという話です。
超短期間スプリントとリモートワーク
超短期間スプリントはリモートワーク専用ではありません。全員がオフィス勤務でも適用でき、非常によく作用します。実際、オリジナルの1時間スプリントを体験したときは、ほぼ全員がオフィス勤務でした。
そのうえで、超短期間スプリントは同じやり方のままで、オフィス勤務でもリモートワークでも、どちらにも対応できることができます。デンキヤギに関していえば、2時間スプリントの習熟度が上がってきたこともあり、フルリモートワークになる以前よりも今の方が生産性が上がってきていると認識しています。
そもそも「リモートワークになったから、生産性が落ちたよねー」という話は、リモートワークになったことで対話するきっかけが少なくなり、非常に属人的な『チーム内で情報共有する能力』に生産性が強く依存していたことが顕在化しただけのことです。 超短期間スプリントは、まさにこの部分の属人性をなくそうぜという話なので、ここが問題にならないのであれば、生産性に影響はありません。
とはいえ、リモートワークでは、ペアプロやらモブプロをやるには制約はあるし、大部屋の壁に付箋を貼りまくるような情報ラジエーターにも制約はあるし、といった空間的な制約で出来ないことや苦手なことがあるのは間違いありません。この点ではオフィス勤務の方が明らかに有利です。一方で、通勤による時間と体力を消耗していることが過少評価されている気もします。
2時間スプリントを行っている実感値としては、フルリモートだろうがオフィス勤務だろうが、生産性はほとんど同じだと思っています。もし差があっても、オフィス勤務が1-2%ぐらいは有利になるケースがあるかもね？ぐらいです。
繰り返しますが、超短期間スプリントは、オフィス勤務だろうが、リモートワークだろうが、全く同じやり方のままで仕事できます。今後、リモートワークが必須でなくなったとしても、やり方を変える必要がありません。
チーム構成と業務内容
デンキヤギ内で2時間スプリントで開発をしているるチームは、現状はこういう感じの体制です。
- terurou（役員定額働きたい放題） - 1人
- 時短正社員（6時間勤務） - 1人
- 学生アルバイト - 4人
- だいたい週2-3日、14時～19時の時間帯で2～5時間ぐらいの稼働
- 学業や私用で突発休みもOKにしているため、勤務日や勤務時間はかなり不定
- フリーランス - 1人
- 週で8時間ぐらいで、特に時間帯を決めていない勤務体系
- この人は今のところスプリントには参加していないが、学生アルバイトの担当作業の技術面や管理面を主体に支援してもらっている状況
- ある程度同じような時間帯に働いてはいるが、始業/終業時間かかなりバラつきがあり、全員が揃う日はほとんどない
業務としては自社サービス（yagisan）の開発がメインですが、内製ツール開発やOSSにPRを投げたりする他、受託の技術コンサルティングやサブスクリプション契約の開発なども並行しています。常時3-5プロジェクトが動いています。terurouは普段普通にコードを書いてますが、PMやPO的なロールもこなしていたりする一方で、代表取締役的な業務があったり、営業対応なんかもあります。
まあ、何も考えずにやっていたら、管理面が破滅するしそうだなという雰囲気です。実際には普通に回せてしまっています。
1日のタイムライン
- （みなさん適当な時間に始業）
- 11:00 スプリントレビュー＆プランニング
- （昼休憩、みんな時間はバラバラ）
- （14時ぐらいからアルバイトがぼちぼち始業しはじめる）
- 14:30 スプリントレビュー＆プランニング
- 16:30 スプリントレビュー＆プランニング
- 17:00 KPT（レトロスペクティブというよりも雑談）
- （みなさん適当な時間に終業）
細かいことは後述していきます。
プロダクトバックログ
プロダクトバックログにはやっていく作業リストがたまっています。デンキヤギではAzure DevOpsをメインに使っていますが、開発対象によってGitHubも併用しています（以前はGitLabも使っていましたが、今は使ってません）。ここには超短時間スプリント固有の話はありません。
各担当者レベルのプランニング（随時）
各担当者は、作業の着手時や割り当てられたタイミング等で、割り当て作業をタスクレベルに細分化してもらっています。
タスクの最小粒度は5分で、30分より大きくしないことを推奨値にしています。最近は弊チームではみんな慣れてきているので、各自のプランニングにお任せ気味になっていますが、「かなり細かくタスクを分割する」ことは重要なポイントです。
タスクを切る粒度の例としては、
- GitHubにprivateリポジトリを立てる（5分）
- XXX処理をするクラスの命名を考える（15分）
- XXX処理のバリデーションを実装する（20分）
- ダミーレスポンスが返せるようにする（10分）
- XXXの公式ドキュメントのGetting Startedのページを読む（20分）
- XXXを公式ドキュメントに沿ってインストールして起動してみる（30分）
という感じです。XXXを実装するとか設計するとかで計画が終わらせがちなところを、もっと細かく切ります。ただ、どうにも細分化しづらいタスクというのも当然あるので、そういう場合は無理して細分化せず、とりあえず大きな粒度のまま残してもらいます。
細分化することで、どこに時間がかかりそうかといったことを、着手前に可視化します。
ウィークリープランニングやマイルストーン
2時間じゃないやんけ！みたいな話になりますが、月曜日11時のスプリントレビュー＆プランニングで、1週間でだいたい何をやっていくか決めていくことはやっています。
超短期間スプリントは超短期計画でしかないので、全体の方向性は決めることができません。マイルストーンを置いたり、週次のおおまかな計画は、これはこれとして考えていきます。
ここも一般的な期間のスプリントでやるプランニングと大差はありません。
デイリープランニング
やっていません。毎日11時のスクラムイベントで「今日中でここまで終わらせたい」みたいな話をすることもありますが、デイリープランニングになっているかと言われると、なっていません。
前述の通り、全員が11時のタイミングでは揃っておらず、14:30でも始業していないことが普通にあるので、朝会なり昼会なりでデイリープランニングするということ自体が稼働実態にマッチしていません。
超短期間スプリントだと、朝会なり昼会に参加しなかったせいで、一日の計画がよくわからない！ということは発生しにくくなります。1日に何度もプランニングをしているので、どこかのタイミングで参加すれば、最新に追いつくことができます。
2時間スプリントレビュー＆プランニング
前スプリントまでの作業成果の共有と、次スプリントのでやる作業の計画（の補正）をします。全員が参加した状態で、次のようなテンプレートに沿って各自に話してもらっています。
テンプレートを使うという発想も47機関のパクリです。このテンプレートは紙に印刷して、スプリントレビューの際に視界に入るようにしておくことを推奨しています。
このテンプレートで会話する作業は、前述の各担当者レベルのプランニングで細分化したタスクレベルになります。ここで、各自が立てた計画に『違和感』を感じた場合や、何か課題が発生している場合は、チーム全体で対応策を検討したり、計画の補正をかけていきます。
- 当人は知識がなかったので半日ぐらいかかるつもりだったが、実はチーム内にかじったことがある人がいて、その人からの情報を足掛かりにすれば30分ぐらいで終わりそう
- 逆に30分ぐらいで終わるつもりだったが、傍から見たらどう考えても見積もりが甘すぎる
- やってみたら実はめちゃくちゃ実装が難しいので助けてほしい
- 要求仕様がよくわからないので悩んでいた など
また、テンプレートに「成果デモの実施」とありますが、これも非常に重要です。「全部完成する前に、上の人に方向性が合ってるか見てもらうね」と指導された経験がある人は多いと思いますが、これを2時間毎にワークフローとして強制的に実施します。全部作りきってしまってから、実は方向性が違ったとか、過剰品質だったとか、品質不足だったとかという不幸は、本当によくあります。
適切な手法で超短時間にスプリントレビューを実施することで、ムダの発生を早期に検出して対処していくことで、生産性が高くなっていきます。リモートワークではコミュニケーションが取れないから生産性が落ちるという話を、属人性にゆだねることなく、仕組みで未然に防いでいきます。
超短期間スプリントの期間の決め方
スプリント期間をどれぐらい短くするかという点は、47機関とデンキヤギで考え方の違いが出ている大きな箇所です。デンキヤギというか、PMとしての私の考え方では、
- 最悪半日ぐらい工数をドブに捨てるようなことになっても、他に得るものがあったなら、まあ仕方ないかなー
- とはいえ、1日まるっと無駄にされたら、若干イラっとするよね
- 2時間ぐらいなら全然仏の顔できますよ。人間、眠気に襲われたりして30分ぐらい意識が朦朧としたりすることもあるよね
- 1時間間隔でチェックポイントを仕込むのは、せわしくなくなりすぎて、逆にストレスが溜まる…
という仕事感覚なので、2時間に落ち着いてきた次第です。
KPT（レトロスペクティブというよりも雑談）
スクラムではレトロスペクティブ（ふりかえり）が重要ですが、それに該当するもので、KPT形式で行っています。
デンキヤギの場合、レトロスペクティブという面もありますが、社員間で雑談する機会を設けるという面を優先しているので、別に実業務とは関係のないことを話してもらってもOKにしています。ちなみに参加者は社員のみに絞っています。
- アルバイトは稼働時間が短く、スプリントレビューも含めると、稼働時間の結構な割合が打ち合わせ時間になってしまう
- チームをまたいで人が参加するので、当然他のプロジェクトの話が出てくることがあり、社員間ならともかく、アルバイトの人に不必要なNDA的リスクを負わせたくない
という判断でやっています。このあたりの匙加減は、これで正解とは思ってないので、今後変わる可能性はあります。
細かなテクニック
仕事に集中していたりして、スクラムイベント（スプリントレビュー＆プランニング、KPT）の時間になったことに気が付かないみたいなことは結構あるので、少し前に時報を鳴らすようにしています。フルリモートワークになる前はチャイムを鳴らしていましたが、フルリモートワーク以後はチャットに通知を流すようになりました。
超短期間スプリントをやらなくても、時報を鳴らすこと自体はかなり良いです。自分で時間を確認しに行かなくても、時間の経過がプッシュされてくるのは、仕事のリズムを作っていくためのフックポイントとして使いやすいです。
超短期間スプリントが適用できないチーム
チームメンバーの働いている時間帯が全く違っていて、全く重なっていないという場合には適用ができません。こればかりはどうにもなりません。
さいごに
長々と書いてきましたが、興味があるチームは id:kyon_mm にアジャイルコーチを依頼するといいじゃないでしょうか。正直、うちが高精度に2時間スプリントを導入できたのは、オリジナルを実際に体験できたことが大きいんじゃないかと思っています。
とはいえ、とりあえず時報を導入して、時報が鳴ったら強制的にチーム全体で話すようにするというところからでも良いかもしれません。そして、前述の報告テンプレートを適当に改変して使えると、なお良いという感じがします。
報連相とかいう属人性の塊みたいな文化を抹殺しましょう。
Haxe 4.2で導入される Module-level fields を試した
Haxe 4.2は順調にいけば、2020年10月14日にリリースされるはずです。とはいえ、Haxeのマイナーバージョンアップのリリースは、バグフィックスも含めると2か月前後ぐらい後ろ倒しになる印象なので、2021年初に使えるようになってるかなーぐらいでしょう。
Haxe 4.2の目玉機能の1つとして、Module-level fieldsが導入されます。雑に言ってしまうと、Go言語に近い書き方が導入されます。
この機能は既にマージ済みとなっているので、nightlyビルドで動作確認することができます。
とりあえず、次のコードはコンパイルできて、ちゃんと動作します。
// Main.hx final version = 4; function main() { trace("Hello from version " + version); }
このコードは、次のコードと等価です。要はシンタックスシュガーに過ぎません。要点としては、
- クラス名はモジュールファイル名から設定される（ここではMain.hxなので、Mainになっている）
- すべて
public staticとして扱われる
class Main { public static final version = 4; public static function main() { trace("Hello from version " + version); } }
このような変換ルールなので、例えばこのように関数定義なしにロジックを記述することはできません。
// このコードはコンパイルが通らない final version = 4; trace("Hello from version " + version);
サブモジュールを作る/使う際も、特に難しいことはありません。
Haxeを知っている人には、import Lib1してるだけなのに、なんでadd(1, 2);って書けるの…？となる部分がありますが、これはimport Lib1.*しているのと同じ扱いになっていようです（ちゃんと情報を読み込んでないので本当に*のシンタックスシュガーなのか自信がない）。
// Main.hx import Lib1; function main() { final result = add(1, 2); trace(result); }
// Lib1.hx function add(a:Int, b:Int):Int { return a + b; }
モジュールの初期化を行いたい場合は、__init__()関数を使います。急にPython感が出ますが、実は少なくともHaxe2の時代には存在していた機能です（Haxe2以前は触ったことがないのでわかりません…）。
// Lib1.hx var value:Int; function __init__() { value = 10; }
ただし、残念ながら__init__()でfinal変数の初期化はできないようです。シンタックスシュガーであることを考えると仕方ない感じがします。
// これはコンパイルが通らない final value:Int; function __init__() { value = 10; }
また、モジュール外に公開したくないものはprivate修飾子を指定します。
// Lib1.hx private function add(a:Int, b:Int):Int { return a + b; }
全的的に、かなり直感的に書けるようになった印象です。いちいちclassとかstaticと書かなくて良くなったことは、特定の層には刺さりそうな感じがします。
強いて気になる点を挙げると、クラス構文の場合とは、importの挙動が異なることと、publicデフォルトなのかprivateデフォルトなのかに差異があることが、気になるといえば気になります。
