内閣府「規制改革・行政改革に関する提案」に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企業であっても設備投資に消極的になってしまう実態があります。これが国際競争力の足かせになってしまっています。

当該規制の根拠となっているもの

法律や政令

上記の具体的な根拠法令等

地方税法

「零細企業経営にはほとんどの意見が参考にならなかった話」を書けと言われたので

書けと言われたので、雑に。人に意見されたことはあまりないつもりだったんだけど、思い出してみたら、結構あったような気がしてきた。

人の意見は参考になるか?

基本的に利害関係のない人間の話は「参考にならん」でいいと思う。逆に利害関係のある人間の話は重要で、それは社員だとか、顧客だとか、株主だとかになってくる(うちは株の100%が自分が持ってるので、株主って自分ですねになるのだけど)。

世間には「勝ちに不思議の勝ちあり、負けに不思議の負けなし」という良い言葉がある通りで、

  • 成功体験をもとにしてくる意見はまず参考にならん
  • 分析付きの失敗体験からなら役に立つかもしれない

ぐらいの話かなと思う。

とはいえ、鵜呑みにするのは「まず無駄かな」というのが7年ぐらい会社経営してた実感。

「百聞は一見に如かず」「やればわかる!やらなければ、一生わからん!」という素晴らしい言葉がある通り。やったことがある人間の意見ですら、その人間とは条件が同じではないわけで、やらんとわからん。

とはいえ、そもそも机上レベルですら成立してないものをやったらアカンです。

助成金を取れ

創業支援機関みたいな人たちが勧めてくれることが多い。お墨付きが付くとかなんとか。

「やってもろくな事にならんぞ」という話は前に書いた。

terurou.hateblo.jp

自社製品の方向性に対してのご意見

うちは今のところ、成功している製品がないので、まあそれこそ参考にならん話ですが。

最初期立ち上げ時のコンセプトに対しては、褒めてくれる人もいれば、ダメ出ししてくる人もいる。で、参考になったかを答え合わせすると、「両論、ほとんど役に立たなかったな」というのが正直なところ。

私個人の経験値としては、人の話を鵜呑みにしすぎてコンセプトがブレまくった上に重厚にしてしまった感が非常に強い。直感を信じてシンプルにやって、ダメならどうせユーザーも居ないんだから、ピボットしまくって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機関の人たちがオリジナルだという認識です。このあたりに本家の情報がまとまっています。

kyon-mm.hatenablog.com

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時間スプリントレビュー&プランニング

前スプリントまでの作業成果の共有と、次スプリントのでやる作業の計画(の補正)をします。全員が参加した状態で、次のようなテンプレートに沿って各自に話してもらっています。

f:id:terurou:20200913190201p:plain

テンプレートを使うという発想も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言語に近い書き方が導入されます。

haxe.org

この機能は既にマージ済みとなっているので、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デフォルトなのかに差異があることが、気になるといえば気になります。

UXデザインとHCD(人間中心設計)の本を教えてもらった

TwitterでUXについて雑なこと(後に認識違いだとわかった)を言っていたら、@nobkz 氏にいくつか本を教えてもらったので一気に読んだ。紹介してもらった本は、タイトルの通り教科書的な内容で、基礎知識を得るには良い本だった。

UXデザインの教科書
UXデザインの教科書
安藤 昌也(著)
¥3,300 (2020-08-16時点)
5つ星のうち3.9
人間中心設計の基礎 HCDライブラリー第1巻
人間中心設計の基礎 HCDライブラリー第1巻
黒須 正明(著), 黒須 正明(編集), 松原 幸行(編集), 八木 大彦(編集), 山崎 和彦(編集)
¥4,180 (2020-08-16時点)
5つ星のうち2.4

改めてUX本を読んで、UXという用語の定義範囲について完全に認識が誤っていた。UXは企画~設計プロセス(特に反復開発とユーザビリティテストに重きを置く)事を差していて、UIはスコープ外だった。5年ぐらい前にいくつかUXの本は読んだ記憶はあるのだが、おそらく当時はマイクロインタラクションなどのUI/UX本(UI要素が強い)を中心に読んでいて、UX単著の本は読んでなかったことで認識誤りが生じていたようだ。

「UXについて理解してるつもりだけど、そういえばUX単独で学習をしたことがないかもしれんなー」っていう人は、おじさんのように実は用語の理解が誤ってる可能性があるので、見直しのために読んでみるとよさそう。

2冊紹介してるけど、UXデザインの教科書の方だけ読めば十分かなあと思う。

「心理学,認知・行動科学のための反応時間ハンドブック」を読んだ

読みました。

www.keisoshobo.co.jp

全ての人間が読むべき本かというと、そうではないです。

私がプログラマーなので、プログラマー文脈になってしまいますが、

  • ゲームおよびゲームに非常に近しい分野(VRなど)に携わるプログラマーおよびプランナー
  • 特にUIの応答速度、入力性、使いやすさなどに強い興味のあるプログラマー

あたりの人間が読むと、知識に深みが出そうです。

実務的な数値とかは、こういった記事の方が揃ってます。ただ、こういった記事を読む際に「そもそも反応時間とは???」という基礎知識を得ておきたい場合には非常に良い本でした。

jp.gamesindustry.biz

私が読んでた時のログはTwitterに流してました。これを見てもらえば書いてある雰囲気は伝わると思います。

各用語や過去の研究等の説明がかなり丁寧で、入門レベルの人間でも読めるようになっています。元々の想定読者に研究者が想定されていて、関連論文のサーベイ本みたいな感じもあり、引用文献は巻末に大量に書かれています。この本を片手に用意しておけば、反応時間関連の英語論文もなんとなく理解できる程度のは読めそうな気がしてきます。 ただし、かなり工学書に近い書き方をしている本なので、こういった本を読みなれてない人にはかなりしんどいと思います。

設計書には何を書くべきなのか

設計とは、

  1. 要求(やりたいこと)をヒアリングする
  2. 要求を要件(何を満たさないといけないのか)に落とし込む
  3. 要件を実現するために考えられる手段を洗い出す
  4. 手段の検証を行う
  5. 検証結果を元に、どの手段を使うかを選定する
  6. 選定した手段を合意する(一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する)
  7. 合意内容を元に、実装や設定に落とし込む

をやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。

設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、

  1. 要求
  2. 要件
  3. 方式
    1. 対応案(いわゆる比較表で書いていくのが楽)
    2. 検証結果
    3. 選定・合意結果(合意した代替策や妥協ラインについても記載する)
  4. 詳細設計(どういう実装にするとか、パラメーターにするとか、細かい話)

という感じで書いていけばよい。

ありがちな失敗としては、4.詳細設計しか書かないことである。これだと、後から読んだ際に「なんでこれ使うことにしたんや…」がわからないという事態が発生してしまう。前述のとおり、画面設計や機能設計では方式を選ぶという事が薄いので、普段このあたりを多くやっている人ほど、3.方式を書くという意識が飛びがちになる。

あと、2.要件はまあまあ書かれるのだが、それに対して 1.要求は「ちゃんとした設計書」ですら書かれていないことがあり、やはり「なんでこの要件になったんだっけ?」が発生しがちになる。