法人の運営に使っていて便利だったサービスたち
僕は法人登記した時はまるっきり素人だった (普通) し、前職で事務所管理はやっていたものの、バックオフィスに投げるまでの管理と、事務所契約時の契約対応くらいなので、運営業務自体はまったく知らなかった。
幸運な事に、近場に経営や法人運営を教えてくれる人がいて、(僕に経営や運営を教える事を) 仕事としてお願いする事でなんとか今までやってきた。
その中で使ってきた WEB サービスを書いておこうと思う。
経理
会計といえば、みんな大好きマネーフォワードの MF クラウド会計。
最初 freee を使うつもりだったんだけど、それなりに会計を理解したいなら MF 会計の方がいいと言われ、こちらを使う事にした。 また、理由は他にもあり、こちらは依頼予定の税理士が対応しているという点もあった。
正直、どちらじゃないと駄目という事は無いと思う (freee は全然使ってないから適当な事は言えないけど) し、基本的には税理士と相談して決めると良いと思う。 ただ、どっちも使えないという感じだったら、税理士を変えた方が良かったりもするかも知れない。 基本的に会計データをオンラインでやりとりできないと結構面倒そうだった。
法務
法務とだいそれた事を銘打ったけど、やった事は契約締結周り。 クラウドサインというサービスを教えて貰って使っていた。
PDF の上に電子サインを設定して、サインを行なう事で締結が出来る。 また、電子契約にする事で印紙税が発生しない (現時点で) という話だった。
これに関しては、クラウドサインを受けいれてくれる相手にしか使えないため、 事前にクラウドサインが許容できるのか、取引先の方針を確認しておく必要がある。
月毎の契約数が少ない場合、無料分で問題なくこと足りる。
労務
労務関係は SmartHR が良く出来ていて助かった。 人を雇う事があり、色々な手続きや、年末調整など分からない事だらけでもガイドラインがあるため、 教えて貰いながらでもなんとか進められた。
請求
結構面倒なのが、 請求書対応。 僕は最初から MF 会計を使っていたけど、途中まで請求書発行は Misoca を使っていた。 けど、Misoca が途中で弥生会計とくっつく事になり、 請求書の発行など料金体系が変わったため、MF クラウド請求書に移行した。
請求書の発行はテンプレートを探したり印刷して送付するのが最大の手間だったんだけど、 請求書発行サービスを使えば 請求書の作成から送付まで全部オンライン上で完結するので非常にありがたかった。
自分で対応して分かったのは、この印刷して送付という対応が非常にコストが高い作業で、これを PDF 作成から書類送付までやってくれるというのは本当に使う価値がある (ただし、物理書類送付はチケット購入制)。 もちろん、MF 会計とも連動しているので関連データを吸い上げてくれる。
ドキュメント管理
会社で作成した書類 (全ての書類) は、スキャンして Google Drive に UP して管理するようにしている。 紙の書類も残すけどファイルに入れたあと、なるべく引っ張りだしたくないため、Drive 上で検索してでてくるようにする。
また、税理士とは様々な書類のやりとりをするので、税理士への共有用フォルダを作成し管理しておくと不足している書類などが直ぐに分かって良かった。
また、検索する際に「いつ」作成した書類かを元に探す事を考慮して、日付や書類の性質、書類タイトル (国関係だと全て届の名前がある) を書いたり、契約書類なら、相手先、自社名、契約種別名 (契約まで入れておくと良いかも) などやっておくと便利だった。
結論
小規模の会社なら上記サービスで十分まかなえるかなという感じがあった。 ただ、知識が無いとどうしようもない対応などもあるので、ちゃんと専門家に相談できる体制を用意しておくのは必須かなと思う。 変にコスト削減とかやってしまうと色々良くない事になるので (脱税するつもりなくても計算間違いで結果的にそうなるというケースなどは多々ある)。
多分、これからはこの手のサービスを使って内部労力を削減しつつ、そのサービスが分かる専門家を付ける動きになっていくんだろうなと思った。
プログラマが知らない会社と税金と保険の話
プログラマと書いているけど、実際には会社員と置き変えられる話。
最近はエンジニアはフリーランスになるべき or 会社員を続けるべき論争みたいなのが多くネットで見られるようになったが、正しいコスト感を持った上でその話を展開する人が全然見られず、大企業ベースのコスト計算で話をする人や、フリーランスの売上がそのまま入ってくるみたいな事を言う人まで色々である。
個人的には会社員にもフリーランスにもそれぞれメリットデメリットがあるので、正しく理解した上で自分にあった働き方を選べば良いと思うんだけど、皆メリットデメリットをベースに話をするから余計にややこしくなってる気はする。
僕はメリットとデメリットなんていうのは主観に依存しているため、他人が言う評価は所詮他人事として自分で判断するしかないと思っている。 その上で、事実だけを書いている所は無いかな？という気持ちで自分の知っている範囲でこの件に関して書いてみる。
もちろん僕は税制や国策の専門家ではないので無知な部分も多いし、間違ったことを発信している可能性は大いにあるので、ちゃんとソースを自分で確認して判断して欲しい （こう書いておかないとお前のせいで大変な目にあったとか言われかねない空気を現代のネットでは感じる）。
年収の話
正直、みんなが気にしてるのなんて、色々すっとばしてここに尽きるんだと思ってる。 個人的な感覚で言えば、常駐型フリーランスでの単価月 60 万というのは、本当に直ぐ貰えるようになると思う。 これは本当に謎でしかないんだけど、世の中何故か 60 万という数字を律儀に守ろうとしていて (この辺に SES 業種の闇を感じる) 、経験年数 3 年くらいあればそれなりに真面目に勉強を続ける人で、最近のフレームワーク使えれば出るのではないだろうか。 これは大阪で活動している僕の感覚なので、単価感が 10~20 万くらいベースが高くなってそうな東京だと下手したら 2 年くらい業務経験あれば貰えるんじゃないかな。
ただ、一言言うと、貰えるようになるというのと、業務が滞りなく出来るというのとは全然意味が違うし、自分の能力にあっていない金額を貰うと、質問すら出来ない空気に呑まれて自爆するハメになるとも書いておく。
その上で、月 60 万の話を続けると、フリーランスで月 60 万が実際どれくらいの価値があるかをちゃんと計算しないといけないと思う。
月 60 万という事は、年 720 万で、一見かなりの金額に見える (いや実際結構な金額なんだけど)。 しかも商売という事になるので、ここに消費税を含んで請求できる (たまに消費込で 60 万とかの話があるけど、消費税別を前提とする)。 フリーランスを名乗るという事は、個人事業主か法人の代表という事だと思うけど、両方年間の売上が 1000 万未満の場合は消費税を国に収めなくても良い制度があり、今だと消費税分 8% が売上に加算される事になる。
つまり、720 万の * 8% なので、加算後の金額は 7,776,000 円となる。金額 50 万マシくらいとなる。 ここまでが常駐型フリーランス売上の話で、仮説単価 60 万の限界点となる。
残業など、超過分の請求が乗る事も良くあるが、そこは計画的に実行される確定値ではないため計算に入れないものとする。 あとはどれだけ金額が下がるのか、リスクと税金の話になってくる。
リスクの話
フリーランスのリスクの話は各所で色々言われているが、一番は自分が動けなくなった場合のリスクである。 これは病気、事故など、心身どちらかに問題が発生し、労働できなくなった場合に保証されるものはどこにも無いという話である。 フリーランスには労災もなければ有給もないし、勿論、産休も育休もない。 つまり何も法は守ってくれなくて、弱者とすら見てくれなくなるという事である。 そのため、フリーランスになる事で売上を全て自分のものに出来る反面全てのリスクは自分でケリをつける必要がある。 もちろん不祥事を自分が起こした時に守ってくれる先輩も、会社すら無いので損害賠償イコール自腹清算しかない。 とは言え、常駐型フリーランスには損害賠償はそうそう発生しないので、不用意にぺらぺらと現場の話を外で話さないという事 (NDA はちゃんと結びましょう) が重要になる。
更に、営業も自分で行なう必要があるため (代行やエージェントを使ったりは自由)、そこもリスクになる。 年売上の仮説を立てたけど、実際には営業活動が上手くいかない場合は年の売上が毎月 60 万下がるという話になる。
税金と保険の話
正直ここまでの話はなんとなく知ってたり、良く知ってるなんて人もたくさんいると思う。 考える事をやめる人がいるとするとここからで、税金と保険を詳しく理解しておかないと、それぞれのメリットデメリットを自分にあてはめて考えるところまで行きつかないんじゃないかと思う。
消費税
これは自分が営業を行なって得た売上に対し消費税を払う必要があるという話なんだけど、前述した通り、年間1000万未満の場は払う必要がない。 また、実は1000万を越えた場合でも、2 期先までは支払う必要がない。 これは、1 年の売上が 1000 万を越えた申告をしてから、2 期後の売上から消費税の回収が始まるためである。 そのため、創業初年から 1000 万を越える場合には 2 年免税期がある事になる。 また、消費税は自分の商品の値段に対し別途請求を行なう事になるので、常駐型フリーランスを行なう場合、自分の値が月額 60 万だと主張する場合は、60万 + 税を請求することになる。 気をつけたいのは、不親切なエージェントや顧客の場合、税込で 60 万という価格設定で話を通してくる可能性が大いに考えられるという事。 年間で 50 万程度も金額差がでるから顧客もエージェントも消費税をどうにかして払いたくないという訳である。
住民税
会社員として給料を貰っている場合、住民税は給与に合わせて徴収される為フリーランスに比べると控えめだと思うが、個人事業主の場合、売上 - 経費 = 収入になるため、この収入分に合わせて徴収されてしまう。 つまり、経費が無い場合は 770 万オーバーの収入に対して住民税を徴収される事になる。
僕は大阪の人間なので、大阪市で計算してみる。 詳しい計算は面倒なので、下記シミュレータで計算してみて欲しいが、会社員とフリーランスでこれだけの結果が変わる。
会社員、年収 770 万想定
- 542,800 円
個人事業主、事業所得 770 万想定
- 739,800 円
個人事業主が何故住民税が高くなるかというと、会社員には実は給与所得控除という所得に関する控除項がある。控除というのは実際には給与を貰っているが、税額計算の時には控除金額分だけ減らして計算してくれる仕組みの事。
計算式は国税庁にある。
今回のケースでは、770万の給与という想定のため、660 万越かつ 1000 万未満のレンジに収まっている。 そのため、計算式は給与額の 10 % + 120 万が控除額となる。 770 万の 10 ％ は 77 万なので、 会社員というだけで、197 万が控除対象となり、額面では 770 万とある筈なのに、実際の計算では 570 万程度で計算されるのである。
個人事業主は利益計上額がそのまま計算に乗るため、経費 0 円の場合、770 万から計算される事になる。 この時点で会社員よりも不利な状況にあるのが良くわかる。
所得税
所得税は住民税と並んで給与から引かれる謎のお金になっている人が多いのではないかと思う。 ここでも先程使った計算の給与所得控除が出てくる。
その前に国税庁のリンクを貼る。
会社員の場合、給与所得控除を給与額面から引いた額をベースに所得税の計算を行なう。 給与 770 万の場合、200万弱が控除されるため、おおよそ 570 万が所得税計算の対象となる。
上記リンクの表と控除後の金額を照らしあわせると、「330万円を超え、695万円以下」に合致する。 この場合の税率は 20％ で、控除額は 427,500 円である。
つまり、570 万の 20% が所得税として計算され、その計算結果の 114 万から 427,500 円を更に控除する。 結果、所得税額は 752,500 円となる。
個人事業主の場合は、給与控除がないため、770 万をベースにする事になる。青色申告の場合は最大 65 万の控除を得られる。 ここで新しい言葉の青色申告というものが出てくるが、ここでは詳しく説明せず、経費計算をちゃんとすれば受けられる控除という認識で通す (受ける為の条件が細かくあるが、ここでは話に絡んでこない)。
控除出来る金額については、保険料の控除がでてくる。配偶者控除など細かな (かつ人による) ものは省く。 保険料の計算は後で再度書くので、こちらでは結果だけ話をする。
770 万の収入とすると、残念ながら医療分保険料と後期高齢者支援金分保険料の 2 種が max となるため、58 万 + 19 万で保険料は徴収額が 77 万となる。 また、国民年金も控除の対象になるため、年金の計算も必要になる。 国民年金は収入に関係なく一律計算で、2019年5月7日、令和元年時点で 16,410 円/月 となる。 そのため、1 年で 196,920 円の徴収額となる。 さらに基礎控除 (全員受けられる控除) が 38 万円である。
これらを使って所得税額を計算すると、7,700,000 - 650,000 - 770,000 - 196,920 - 380,000 = 5,703,080 円が所得税計算対象額となる。 所得税速算表から「330万円を超え、695万円以下」が適応される事が分かるため、税率 20％ で 約 114 万、控除額 427,500円 を引くと会社員と同じ 752,500 円が控除後の所得税額となる。 実際には個人事業主にはここに経費計算分が税率計算前に実行されるため、経費を使う前提で考えるとようやく会社員と比べて遜色ないか、それ以上の効果を得る事ができると言える (ただ単純な生活費は経費にできないため、常駐型フリーランスでは経費に出来る項目がかなり少なくなる)。
保険料
会社員だと社会保険料という言葉を良く聞くと思う。 医療を受ける際に恩恵を得ている物なのだけど、会社員はこれを一部所属している会社に肩代わりして貰っている。
どういう事がと言うと、雇用主は社会保険料の半分を会社資産から支払う事が決められている。 つまり、給与から天引きされている額面と同じ額を会社が支払っている事になる。 良く会社員は得しているという話を見られるのはこれがあるからというのも大きい。
ただ、本当にこのおかげで会社員が得をしているかと言うと、会社側は社員の給与を決定する際にこの社会保険料の支払い分まで考慮して決定するため (逆にしていないのならそれはヤバイ)、そもそもその半面の支払い分までが実際の会社員の給与額面だという見方もできる。
実際に計算してみる。 これも自治体によって金額が違うため大阪市のデータを参照する。
こちらから大阪を参照する。
- 大阪市の保険料 PDF https://www.kyoukaikenpo.or.jp/~/media/Files/shared/hokenryouritu/h31/ippan4gatsu_2/h31040227osaka.pdf
年収 770 万という事は、月額報酬が 64.16 万円程度となるので、こちらに該当する行を探す。 該当等級は 35 等級 (非常に高い...) となり、料率は保険料が 10.19% の 66,235 円で、厚生年金は 18.30% だけど最高額になるため 113,460 円となる。 これを会社と社員で折半するため、支払い額はそれぞれ半額になり、33,117.5 円 と 56,730 円 で 89,847.5 円が月々の支払いとなる。 年間では 1,078,170 円を支払う事になる。
個人事業主は国民健康保険と国民年金の支払いがあるが、その支払いは社保よりは安く (社保というよりは厚生年金が高い)、住民税の話で計算した内容である、58 万 + 19万となる。
その計算根拠は下記 2 ページである。
国民健康保険は内訳が医療分保険料と後期高齢者支援金分保険料の 2 種あり (歳をとると介護保険料も乗る)、それぞれを計算して足した金額が支払い額となる。 仕組みはどれも「平等割」+「均等割」＋「所得割」となっており、所得割以外は対した金額ではないので割愛。 所得割は、算定基礎所得金額と書かれているせいで分かりづらいが、総所得金額からの算出で、控除額 33 万があるというだけのため、総所得が 770 万とするなら、770 万 - 33 万を計算したのち、それぞれの % で計算すれば金額がでる。 そして、770 万という所得は非常に高額なため、2 種とも Max の金額を支払う事になる。
その金額を足した額が、前述した 58 万 + 19 万で計 77 万となる。 さらに国民年金の計算が入ってくる。
国民年金は収入に関わらず金額が固定の為計算し易い。
日本年金機構に乗っている内容によると、令和元年では 16,410円 が月の支払い額となる。 年間で 196,920 年の支払いとなり、先程の 77 万と合算すると、966,920 円の支払いとなる。
ここだけみると、じゃあ個人事業主 (フリーランス) の方が安く済んでいるように見えるのが落とし穴である。 国民年金は厚生年金と比較して受給額が低くなる。 それはあたり前の話で、厚生年金は収入に応じて割合を多く回収されており、しかも個人支払いでさえ多く払っているのに、更に半面を会社が収めているというロジックが存在する。 つまり、会社員との決定的な差はここで、「社会保険 + 厚生年金」vs「国民健康保険 + 国民年金」の比較をする事には実は罠がある。
比較をするのであれば、「社会保険」vs「国民健康保険」と「厚生年金」vs「国民年金」という構図を作らないといけない。 そして、「社会保険」は年 397,410 円 、「国民健康保険」は年 77 万という状況である。 会社が支払う半面を考慮すると大体同じなのだが、半面を払って貰えるおかげで大きく有利になっている。
また、年金ではどうなるかというと、「厚生年金」は年 680,760 円、「国民年金」は年 196,920 円となる。 これを見て思うのは、先程でた話で、回収された金額に応じて年金受給額が増額されるという話である。 つまり、この時点で 3 倍程度支払い額に差がある。保険料と年金の合計額は然程変わらないのに、という所がミソとなる。 さらに、厚生年金は半面を会社が負担しているため、実質的に支払われている年金額は年 1,361,520 円という事になり、もし同額年収だったと過程した場合非常に大きな額の差が埋まれる事が分かる (7 倍近くの差がある)。 ここが会社員が貰っている給与にプラスして支払って貰っている半面の金額を計算に入れた方がいいという話の所以である (実質的に年収が 100 万程増えている事になるのが分かる)。
手取り
最後に手取りを計算する事になるが、これは前述した内容全てを収入から差し引くことで計算できる。 会社員から計算する。
(年収) 7,700,000 - (住民税) 542,800 - (所得税) 752,500 - (保険料) 1,078,170 ＝ 5,326,530 円
続いて個人事業主の計算。
(年収) 7,700,000 - (住民税) 739,800 - (所得税) 752,500 - (保険料) 966,920 ＝ 5,240,780 円
このような計算となる。 金額的にはほぼ差はなく、若干会社員の方が手取りが高い結果となる。
ただ、ここでの会社員の年収 770 万というのは非常に高額で、会社員でこの給与が支給されるというのは現代の給与枠組みではなかなか簡単には達成できないと思う。 達成難易度という意味では、現在は、常駐型フリーランスで月 60 万という方が簡単に達成できると断言できる (が、将来性など色々なリスクを何十年も背負い続けられるかは人によるとしか言えない)。
ただ金額的な話で言っても、会社員は半面の支払いを会社に負担して貰える上に、労働者保護の恩恵を受ける事ができるため、リスクヘッジや年金の件と総合して考えると相当に会社員が優遇されている事は考えるまでもない。 金額的で表わしてみると、半面は会社が金額負担してくれているので、その分収入が低めになってもフリーと同等程度の実質年収と言えるため、実は 660 万程度でも十分 フリーランスの 770 万分の価値はあると思う。
また、有給が年 20 日付くようになると、20 営業日の休暇が年間で取得できるため、実質 1 ヶ月分は休暇を取りつつ年収を維持できる計算となる。これを加味した場合、月 55 万 (年収 660 万計算で) を実質稼いだと見なせるため、年収は実質 710 万 ＋ 660 万での半面 100 万 (詳細な計算はしていない) で 810 万程度の価値があると見なせる。 ここに失業時の雇用保険給付や怪我病気による勤務が困難な際に受けられる傷病手当など、様々なリスクに対する措置が存在する上に、産休育休など自己都合による場合の手当も受ける事が出来る (育休は取得条件を満たした上で申告する必要があるけど)。
結論
結論は自分で出して貰う必要があるけど、会社員が相当に優遇されている仕組みである事を理解した上で、納得出来る選択をした方が良いというのが僕の見解。 今時点での給与が低いから会社員をやめてフリーランスになるという選択は否定しないけど、給料だけが原因なのであれば転職活動で解決する方が王道だと思う。結局、今の会社で貰っている金額に不満があるだけなのだから。
独立したい、フリーランスをとりあえず 2, 3 年やってみたいという気持ちを持って僕も独立したけど、途中本当に色々考えたし (知り合いや家族にも漏らしていない悩みは常に持っていた)、手続きや書類対応、申請対応等々面倒な事も本当に多い。 正直、残業代がどうこうという発言をする人には絶対に個人事業主や法人登記は向いていないと思う (常駐型フリーランスだと、常駐先での業務が終わった後、経費対応、月末の請求書対応、申請書類を夜中や土日に作成するはめになる)。
また、今回の計算では経費計上を行なっていないけど、本当は税理士と顧問契約は結んだほうが良い (税務リスクは回避する手段を持つべき)。 良く、記帳代行だけという話を聞くけど、あれは自分が理解していて作業を外出しする人のためのサービスで安い変わりに全然リスクを教えてくれなかったりする。その為、始めて独立する人はちゃんとした税理士を探して契約する事が第一の仕事になると思う。
最後に、今回は言及しなかった方針に法人登記があり、会社の社長となる選択肢なんだけどこれは非常に面倒な作業が多く発生する変わりに税制上本当に有利な措置が多くある。 会社を作り、税理士と話をする機会を作り、経営の指南を受けつつ 3 期目を終わろうとする今こんな話を自分が書けるようになったのはそれなりに感慨深いものを感じる。
金融庁が提示した老後2000万問題もあるし、年金制度の破綻の疑義、終身雇用制度の限界など、今年は就業者にとって本当に大きな問題を考えさせられる年になっているので、税金や保険、雇用制度などを他人事と思わずちゃんと勉強した方が良いと思う。
Emacs を覚える際に体に染み込ませた方がいいデフォルトキーバインド
Emacs を使う人でそれ Emacs じゃなくて良いじゃんって感じの使い方をする人がたまに居るんだけど、これは Emacs 以外のエディタでも同様で、単に機能盛り盛りの豪華なエディタが良いなら IDE の方がオススメだよって良いたくなる。
で、自分が Emacs (や vi など他のエディタでも) で大事にしているのは、エディタを通してテキスト (プログラム等色々) を書く時の体験。
今回はその体験の内の一部、キーバインドについて書いてみる。
そもそもキーバインドってなに
という意見もあると思う。 キーバインドとは、キー (キーボードのキーの事) にバインド (束縛の事) されている機能実行を指す。
ショートカットキーみたいな物。 で、Emacs には基本的にこのキーバインドを扱ってエディタを操作するため、キーバインドを覚えないなら Emacs は単なる Lisp 実行機になってしまう。
上下左右などの移動のためのカーソル操作や kill - yank 等はわざわざ説明する内容でも無いので省く (もし矢印キーで操作してたり、範囲選択してツールバーの切り取りや OS の切り取り操作で対応しているなら Emacs のキーで覚えなおす事をオススメする)。
因みにターミナルも Emacs のキーバインドがデフォルトで ON になっているので、Emacs で覚えた操作は基本的な物 (カーソル移動や search、kill - yank などは対応している) は使える。
本題
Emacs は基本的に拡張を入れたり、自分でエディタをカスタムして使う事が出来るのであまりこう使うべきというものは無いけど、流石にこれは知っておいた方が良いよねというものもそれなりに存在していたりする (機能の組み合わせなど、色々)。
ファイル全体の再インデント
プログラムを書いていると、なんでこんなにインデントが汚いんだという状況に遭遇することが良くある。 その時にいちいち、ポチポチインデントをつけていく人が居るんだけど （みてて本当に悲しくなる) そういう時は、全体選択とインデントで一括インデントが可能となる。
# 全体選択 C-x, h # インデント C-i
ただし、空白文字とタブ文字が混ざっている時にどちらかに寄せるという挙動はしてくれない (タブ文字を空白文字に変更したり等)。 その時に良くやるのが下記。
# 全体選択 C-x, h # 正規表現置換 M-C-% # タブ文字指定 (C-q, C-i で文字として入力できる) -> 空白文字 C-q, C-i -> スペース
正規表現での置換は特にエディタを使っていて本当に良く使うのでなる早で身に付けるようにした方が良い。 これが使えるだけでプログラム書く時の面倒臭さが激減する。
コメント/アンコメント
一旦書いているコードをコメントしたい時は良くあり、その際に毎回範囲コメントを書いたり、一行コメントを該当行に書き加えるのは生産性が皆無なので、やめた方が良い。 コメントアウトしたり、コメントを外したりするなら、それ用のキーバインドがある。
# コメントアウトしたい行を全て選択した上で M-;
アンコメントする時は逆に、コメントを外したい行を選択してコメント時のキーバインドを利用する。 言語によっては範囲選択すると範囲コメントを使用するため、その場合は中途な範囲をアンコメントする事は出来ないため、一度最初にコメントした行を全てアンコメントしてから再指定、コメントアウトし直す。
ディレクトリ/ファイル操作
Dired モードも良く使うので覚えておくと細かな操作をターミナルで行なう必要が無くなり、Emacs <-> ターミナル間の移動を省けて便利。
例えば、削除したいファイル候補は d でマークを付ける事が出来る (行の左箸に D という文字と色が行につく)。 この選択状態の際に x を入力する事で削除を実行できる (yes or no の確認を済ませると個別確認はせず実行される)。
また、ファイルの移動やリネームを行ないたい場合は、対象ファイルの行上にカーソルを置き、R を入力する事で mv コマンドと同等の事が実行できる (対象ファイルはカーソルが乗っている行を選ぶ為、移動先を入力するだけとなる)。 単一コピーは C で、単一削除は D を入力することで、リネームと同じ確認を行なわれる。
また、複数行を対象にしたい場合は m を入力する事で、複数に対しマークを付ける事が出来る (これは d でマークを付けるのと似た操作となる。またマーカーは * となる)。 マークの取り消しは u で可能となる。
あとは、使用シーンはそんなに多くないけど、t を入力する事で現在選択している行と未選択行を反転する事ができる。 1 つ以外のファイル全ての様な指定をしたい場合に除外したいファイルにマークをつけ、その後反転といった使い方になる。
また、ファイルの中身を確認したい際には C-o を入力する事でファイルを確認する事ができる (カーソルは今のまま移動しない)。逆に、ディレクトリを表示したままファイルを開いてカーソルを移動したい場合は、o を入力する事で開いた上で移動する事が出来る。
カーソル移動
最後にカーソル移動の話となる訳だけど、Emacs でカーソル移動する際は基本の上下左右と思われがちなんだけど、それは非常に非効率で、出来ればインクリメンタルサーチを使うべきとなる。
なるべく少ないキー入力で対象の編集箇所に飛ぶ訓練はした方が良く、その最たるものがインクリメンタルサーチとなる。 他にも細かなジャンプ用キーバインドがあったりするけど、最初にサーチで移動する癖を付けてしまう方が色々と楽 (応用が効きやすく、細かな指定が出来るため) となる。
# 前方 C-s # 後方 C-r
サーチキーバインドを入力した後、検索したい文字列を入力し、C-s や C-r で前方、後方へ移動していく事ができる。 連続で実行する事で次々に移動していき、候補が無くなると、再入力でファイル内の最初のヒット文字列に移動してくれる。 途中で検索ワードを変更したり、検索をやめて移動した先からカーソル操作を続ける事でできる上、元のカーソル位置に戻って作業を行なう事も出来るため、ソースを確認して戻るなどもできる （ソースを見ながら入力したい場合などは Window 分割して同バッファ上で確認したい行に移動するなどは良く行なうのでそちらの方が良いかも）。
とにかく、生産性高くプログラムを書くには、いかに無駄な入力やカーソルの移動時間を使わない事に尽きる。そこにはマウスとキーボードの間を往復する手も要因に含まれるため、手をキーボードの上に置いたままマウスを使っているのかと思わせるくらいの操作を覚える事が重要になる (訓練するとプログラムを書くのにマウスを使う事が苦痛になる程パフォーマンスが上がってくる)。
結論
今回の話では僕が Emacs を普段から使っているため Emacs の話を書いたけど、これは vi (Vim) を使おうが、IDE を使おうが、どのエディタ環境でも変わらず、プログラマにとって必要な能力となる (キーボードショートカットを覚えて使いこなすという話)。 採用面接や試験などではプログラムをどれ程書けるのか、言語の習熟度、フレームワークの実績などを確認されるが、僕はエディタを重視して確認したりしていた。
それは、言語、フレームワークなどに習熟するのは業務でやっていればある程度できるようになるが、エディタの使い方を見るとどれくらい普段プログラムを書いていて、どの程度熱意を持っているかを測れると思っているからである。 プログラマは職人であり、エディタは長く触る事になる道具なため、その使い方を常に良くしていこうという気持ちが無いと時代についていってプログラムを書いていくのは難しいと思う。
そのためこれからプログラミングを覚えていく人はプログラムを書く事だけでなく、自分の使っているエディタでどう書くべきなのか、という所まで目を向けて書いて欲しい。
Laravel で save メソッド実行時に保存前処理を挟む方法
Laravel 5.6.36 での話。
DB のカラムデフォルト値設定が NULL 且つ、NOT NULL な制約のあるカラムはデフォルトの Laravel と非常に相性が悪く、困る時がある。 DB の設定の問題は DB で解決すべきという事も考えられるが、開発現場の状況によっては (政治的、現場的) 制約が多くあるため、今回は制約を守った状態で対応する場合の話。
Laravel はリクエストを受けつけた時に、未入力 (空文字) のフォームのデータは NULL に変換を掛ける。今回の問題点はこの機能にもある。 詳細は下記ページ「入力のトリムとノーマライゼーション」を参照。
Laravelのデフォルトグローバルミドルウェアスタックには、TrimStringsとConvertEmptyStringsToNullミドルウェアが含まれています。これらのミドルウェアは、App\Http\Kernelクラスにリストされています。これらのミドルウェアは自動的にリクエストの全入力フィールドをトリムし、それと同時に空の文字列フィールドをnullへ変換します。これにより、ルートやコントローラで、ノーマライズについて心配する必要が無くなります。
Laravel の middleware を触れる権限があったり、影響が少ない最初期の開発フェーズなら middleware から外す事で NULL に変換される問題は解決する。
この振る舞いを無効にするには、App\Http\Kernelクラスの$middlewareプロパティからこれらのミドルウェアを削除することにより、アプリケーションのミドルウェアスタックから外してください。
内容
前述した方法で解決できない場合、Controller, Model 等の層で解決する事を求められる。 この問題を解決する方法を考えてみると、いくつか方法が考えられる (清濁考えない場合)。
- Controller でそれぞれのリクエストパラメータを取得、加工後 update メソッドなどで流し込む
- FormRequest で加工
- Model の save メソッドでの保存前に加工する
1. Contoller で加工する
この対応は一番泥臭いやり方かなと思う。 メリットは手が込んでなくて、特別な知識を必要としないため、Laravel の Controller と Request を使った処理が書ければ対応できると思う ($request から input を取得して加工するだけ)。
デメリットは特定の Controller@function に依存するため、似た処理を必要とした際に色々な所に書く必要があり、変更が入ると全てを修正する必要が出る場合があること。
後々の事を考えず、とりあえずの対応をするならこれでも問題はない。
2. FormRequest で加工
日本語ドキュメントでは「フォームリクエスト」と表現されている (FormRequest ではググってもでない...)。
FormRequest は本来バリデータとしての役割を持つが、リクエスト処理を受けつけている都合上、Controller に $request が渡される前に加工する事が可能。 メリットは Controller 内でリクエストデータの確認と加工処理を書き散らす必要がないため、Controller@function で実現したいコードのみが記述され、やりたい事が分かり易くなる (読み易いコードになる)。
デメリットはリクエストデータを勝手に加工するため、第 3 者から見ると単なるバリデータだと思えるのに、実際はデータが変質してしまっているように見える事。
今回のケースで言えばフォームが未入力の場合は NULL が入ると思っていたが、実際は空文字列だったというものだったりする。 意味的には大きく変わりがある訳ではなく、本来 Laravel が勝手に NULL に変更していたものを戻しているだけに思えるが、この変更によって is_null 関数などの明示的な NULL のチェックにかからなくなる。
NULL と空文字の些細な違いではあるが、第 3 者がコードを書く際にどういう考えで書くかを保証しきれない以上、他者が触る可能性のあるデータを、通常の意識外の場所で変更するべきではない。
その意味では、Controller で直接対応している方がまだマシに思える。
3. Model の save メソッドの保存実行前に加工する
今回の問題では保存される際に NULL が明示的に渡される場合が困るという事 (DB 側で制約がかかっており、NULL が入るとエラーが発生するのが困り種) なので、保存時のデータに指定のカラムが NULL で無ければあとはどうでも良いと言える。
プログラミングのテクニックには「フック (Hook)」というものがある。これはフレームワークやライブラリなど、第 3 者に利用を提供するようなものに拡張性を持たせる用途で用意される。
フック（Hook）は、プログラム中の特定の箇所に、利用者が独自の処理を追加できるようにする仕組みである。また、フックを利用して独自の処理を追加することを「フックする」という。
処理を追加できる箇所は、元のプログラムの開発者によって、あらかじめ決められている。初期化処理や入出力処理などの直前・直後が対象としてよく選ばれる。
この機能は Laravel にも用意されており、Eloquent (エロクエント) モデルの機能として使用できる。
「イベント」を参照。 readouble.com
Eloquentモデルは多くのイベントを発行します。creating、created、updating、updated、saving、saved、deleting、deleted、restoring、restored、retrievedのメソッドを利用し、モデルのライフサイクルの様々な時点をフックすることができます。イベントにより特定のモデルクラスが保存されたりアップデートされたりするたび、簡単にコードを実行できるようになります。
モデルに dispatchesEvents を設定し、呼び出される Event と Listener を定義して加工処理を書けば終わりとなる。 やり方はオブザーバーを作る場合とイベント、リスナの場合で少し異なるが、大枠は同じ。
結論
この手の問題が起こったときは大元で対処できるならその方が確実 (DB の設定で解決されるものはなるべくアプリに持ち越したくない) なんだけど、そうも行かない気もある。
その際はなるべく現行の実装に影響がない範囲且つ、既存の実装が考慮を漏らしてる場合のケアが一緒にできる位置に入れるとうまくはまる。 ただ、データをアグレッシブに加工するタイプのものの場合はわざと局所的な実装にした方が良いということもあるので、自分が実装するコードがどの範囲に影響を与えるべきか考えた上で、適切な範囲で効力を持つ場所に実装するべきとなる。
また、hook という概念は Laravel 以外にも色々なところで使われるため、何かの処理の前後に処理をねじ込みたいときはまず hook の存在を確かめるようにるといいと思う。
Laravel でイベントとリスナを実装する時に面倒な手順で対応していた
今まで Laravel でイベントとリスナを実装する時にわざわざ手間がかかるやり方をやってしまっていたという話。
laravel 5.6.36 時点の話 (結論にも書いているが、5.2 のドキュメント時点では既にこのやり方が書かれている)。
内容
今まではイベントとリスナを実装する際は make:event と make:listener を実行し、それぞれを作成、EventServiceProvider の $listen に登録という流れで作っていたが、ドキュメントを見ているとそんなやり方は面倒だからこっちでやれという天啓が書かれていた。
毎回ハンドラやリスナを作成するのは、当然のことながら手間がかかります。代わりにハンドラとリスナをEventServiceProviderに追加し、event:generateコマンドを使いましょう。このコマンドはEventServiceProviderにリストしてあるイベントやリスナを生成してくれます。既存のイベントとハンドラには、もちろん変更を加えません。
今まで無駄な手順を踏んでいたらしい。
<?php ... protected $listen = [ // 既存分 'App\Events\OrderShipped' => [ 'App\Listeners\SendShipmentNotification', ], // 追加分 'App\Events\Hoge\SampleEvent' => [ 'App\Listeners\Hoge\SampleListener', ], ]; ...
$ php artisan event:generate
ドキュメントにある通り、既存分の App\Events\OrderShipped と App\Listeners\SendShopmentNotification には何も変化は起きず (既に存在している場合は何もしないという事) 、追加分のファイルが作成されていた。 また、今回追加分では namespace で Hoge を作成する用に書いてみたが、ディレクトリの生成と namespace の設定までちゃんとやってくれている事も確認できた。
イベントとリスナをセットで作成する時のオペレーションはこのやり方が一番手間がかからなさそう。
結論
event:generate 使おう。
この記事を書きながら調べてみたら自分が Laravel を使い始めた頃のバージョンである 5.2 では既に event:generate を使えと書いてあるので、どこかで局所的にやり方を覚えてしまったのかも知れない。
プログラマの使うキーボード
この間 (プログラマではない人と) 話をしていた際に、僕が勧めた物を即買ったみたいな話をされ (その時は iPad mini 5 を勧めた)、そういえば自分が良いと思ったものはリアルで会う人にはオススメするけどブログでは書かないなぁと思い、不定期で書いていってみようかと思った。
とりあえずキーボードについて書いてみた。
自分が使っているキーボード
自分が好んで使っているキーボードは HHKB Pro 2 TypeS (ハッピーハッキングキーボード プロ 2 タイプ エス) というキーボードで、無刻印、US 配列を好んで使っている。 金額は 3 万くらい。
PFU キーボード Happy Hacking Keyboard Professional2 Type-S 無刻印/白 PD-KB400WNS
- 出版社/メーカー: PFU
- 発売日: 2011/06/15
- メディア: Personal Computers
- クリック: 21回
- この商品を含むブログ (3件) を見る
HHKB Pro2 は高価なキーボードのため大体引かれるんだけど、物が非常に良く、非常に気に入っているためプログラミング等の開発用途ではこれ以外のキーボードに乗り換えるつもりはあまりない (一応今他に気になっているものはある)。
使い心地などのレビューは今や非常にたくさんあるため、自分がこれをネットに垂れ流しても狂信者の戯言が増えるだけと思うと、良さを語るよりも、自分が何故このキーボードを買って使う事になったのかを書くほうが有益だと思うので、そっちの観点で書く。
HHKB (高額なキーボード) を買うキッカケ
元々自分は開発にのめり込む前に使っていたキーボードはパンタグラフ式のキーボードを使用していた (愛用と言っても 3000 円くらいの奴だけど)。 当時 (今から14 年くらい前) メーカー標準でついてくるキーボードは個人的に非常に使いづらく、ノート PC のような凹凸のなるべく少ないものを探し、パンタグラフ式にいきついた。
その時はプログラミングなんて全く無縁だったため、ネットゲームでチャットするのと、ブラウザに入力する程度だったため、ハードユーザーではなかった。 もちろん配列は JP 配列。
後に研究室に配属される事になり、入った研究室では基本 HHKB Pro 2 しか挿さっていないという状況だった。 使った事がある人は分かると思うけど、初めて触るとかなり混乱する作りになっている。 その時のキーボードはベース黒色、US 配列、墨字刻印だった。
最初キーボードに刻印が無いようにしか見えず (黒キーに墨の色で印字しても殆ど見えない)、当時タッチタイピングが出来なかった自分はおっかなびっくり入力するという状況が続いていた。
丁度研究室に配属された辺りからプログラミングに熱が入り初めたので、その使い辛いキーボードでずっとプログラムを書いていた訳だけど、タッチタイプできない上に、キーボードの刻印は非常に見辛いとくれば苦痛この上ないという物。 ただ、僕は当時からマゾイチャレンジみたいなのが大好きで、「じゃあこのキーボード使いこなせるようになったら最強じゃん」という小学生並の発想で、研究室に入り浸ってキーボードを扱う特訓を初めた。
当時、丁度読んでいた「root から / へのメッセージ」という本に、著者がキーボード入力を早くする為にやった訓練方法が書かれており、その方法を自分のネットブック (当時は eeePC というネットブックが人気があった) を使い、家でも特訓、研究室に出てきたら HHKB で特訓を繰り返していた。
root(ルート)から/(ルート)へのメッセージ―スーパーユーザーが見たひととコンピュータ
- 作者: 高野豊
- 出版社/メーカー: アスキー
- 発売日: 1991/01
- メディア: 単行本
- 購入: 3人 クリック: 11回
- この商品を含むブログ (12件) を見る
練習の甲斐もあり、キーを入力する事に非常に慣れる事ができ、本に視線を固定した状態でプログラムを写経できるレベルになり、その時にようやく HHKB の使い心地のよさや、プログラムを書く人が欲しいと思うような配置になっている事に気付いた。 また、その頃くらいから、JP 配列のキーボードでプログラムを書く事が非常に煩わしくなり始め、実はプログラミングで良くつかう記号は JP 配列では入力するのに手間な配置になっているという事にも気付いた。
この気付きを得た時に高額な HHKB Pro 2 の一枚目の購入を決めた (Pro2 シリーズは今 4 枚くらい持っている)。 因みに、良く Pro2 を買うお金がないから Lite を買うという話を良くされるが、全く別物で、Lite 買ってから Pro2 を欲しくなる人が多いため、お金を理由に Lite を買う人には我慢して Pro2 を買う資金にあてるように諭している。
プログラマに向くキーボード
完全にプログラマに向くキーボードというのは個人の好みがあるので語る事は出来ないが、やはり US 配列は大きくプログラミング体験が変わると思っている。 また、どうしても長時間タイピングする必要がでてくるため (プログラムを書かなくても、wiki を書いたり、チャット対応したり、メールを書いたり)、指に変に負担を掛けないものが良い。Mac 標準のキーボードは個人的に指が痛くなるので長時間タイピングするのは辛かったりする (Thinkpad は未だいける)。
また、どのエディタを使っているかや、使っているエディタや環境のキーバインドによっても使い易いキーボードは変わるため、色々試してみて欲しい。
SSH 接続先にログインした状態で文字列展開等を使う
今まで esa.io を使っていたけど、色々あって解約することにしたのでブログにコンテンツを移していくことにした。 外部に出すこともできないものもあるため精査しつつ定期的に移していく。
目的
SSH でログインした先のホストで for in を使ってシェルを実行したかった。
#!/usr/bin/bash ssh TARGET_HOST "for host in `cat hosts.txt`; do echo $host; done"
雰囲気としてはみたいな事がしたかった。 実際は上記方法ではシェルスクリプトの実行時に展開されてしまうのでダメだった。
内容
対応方法としては、ssh 後に実行する処理だけスクリプトにして、bash の -s オプションで読み込むので大丈夫だった。
#/use/bin/bash for host in `cat hosts.txt`; do echo $hosts done
$ ssh TARGET_HOST "bash -s" < echo_hosts.sh
炎上する案件としない案件
エンジニアを目指すと一緒についてくるイメージのある炎上案件。 炎上する理由は色々言われがちで、マネジメントができていないから、技術力が無いから、というものは良く言われるもの。
ウォーターフォールはだめ、アジャイルで、SCRUM なら、本当に色々言われてるし、色んな手法がでてきたけど、結局炎上する案件は炎上するし、 その案件には燃える理由があるという事を認識しないといけない。
炎上とは
そもそもこの話を始めるまえに、炎上の定義が必要だと思う。
goo 辞書で意味を見てみると、1 に「火が燃え上がること」とあるが、エンジニアの業界でもこの言葉の意味で使われている。 この場合の「火」とは「トラブル」のことであり、トラブルが連鎖的に発生 (飛び火して燃えあがっていく) する事をイメージする。
そもそも何故そんなに連鎖的にトラブルが発生するのか、じゃあトラブルってなんだ、という事に問題は移っていく。
トラブル (単体の火)
トラブルとは「揉め事」のことであり、揉め事の相手は「顧客」となる。 「顧客」と表現しているけど、実際には社内プロジェクトでも炎上するので、顧客は「仕事の依頼者」くらいの認識になる。
つまり、トラブルが発生するという状態は、顧客との揉め事が発生したという話となる。 これが連鎖的に発生して手がつけられなくなってくると、「炎上」の状態となる。
連鎖的に発生するトラブル
トラブルが連鎖的に発生するなんてトンデモナイって思うかも知れない。 でも実際には「揉め事」というのは多く、しかも簡単に発生する。
「言っている事が違う」「前はこれで良いと言っていた」「出来ると言っていたのに出来ないと言いだした」などの問題や、単純な意見の食い違いから、深刻な問題まで色々ありうる。 この深刻度が様々な状態の食い違いのうち、深刻なものが抉れると、それが呼び水となって開発側に不信感を抱き、今迄許容できていたものにも我慢できなくなる。 勿論単純にやることなすこと全て駄目と最初から思われるケースもあるので、必ずこうとは言わないが、不信感を募らせた結果爆発的にトラブルが増加するのは本当によくある。 これはロジカルな話ではなく、人間の感情の部分が作用するので中々論理的に解決する事は難しく、結果「炎上」という事になる。
具体的な揉めるケースは大体は下記 3 つの内容にあてはまる。
- 機能の挙動が違う (足りない機能があるなど)
- スケジュールが遅れている
- 不具合がある
上記を見た限りだと、開発に問題があり、なんだ技術力がないから燃えるんじゃないかという考えになりそうだが、実はそうではない事が多いのが炎上を回避しづらい、厄介なポイントだったりする。
1. 機能の挙動が違う問題
顧客からの「機能が違う」「足りていない」という話は本当によくある内容で、言われた側は「言われた通りに作った」という平行線な主張になり易い。 これは完全にコミュニケーションの問題で、顧客が勘違いしないような具体性を持った方法で、実装される機能の動作を説明する必要がある。 これが出来ていないために、自分達が作ろうと思っているものと顧客が作ろうとしているものの機能が異なるハメになる。
「~みたいな機能」「~みたいなデザイン」という依頼を貰った際に、その内容のママ内部に持ち帰ったり、あいまいな表現のまま持ち帰るとこういう問題が特に起きやすい。 それは機能の仕様化と、その認証を怠る事で発生する (意図的に怠る場合と、意図せず怠る場合があるが、ここでは同列に扱う)。 定義された仕様に過不足が無いと承認 (承認の証拠は必要) を得られていれば、その通りに実装することでトラブルが発生することは無くなるので、この問題でトラブルが発生する場合は進め方に問題があったという事になる。
2. スケジュールが遅れている問題
この問題には色々なケースがありうる。
- 技術的に解決が難しい問題にあたった (局所的な問題)
- 開発チームのレベルが足りない (大域的な問題)
- 途中で仕様変更、作り直すと間に合わない
- 開発期間が短かすぎる
この中で本当に開発チームに過失が存在するのは 2 (厳密に言えばアサインした人の過失だけど) で、他は開発と別の所に問題があったりする。 1 も内部の問題に見えるが、実はこの問題を回避できたりする。
スケジュール問題 1：技術的に解決が難しい問題 (局所的)
一部の機能の実装で、システム全体の兼ね合いや、ベースに使ったシステムでサポートされていない問題など、様々な原因があるが、実は仕様の調整で問題ではなくなる場合がある。 その為、実装担当者が仕様的に難しいと判断した時や、かなり無理な実装をする必要があると思った段階で、顧客にその件を報告し、迂回策を提案する事が望ましかったりする。 仕様は絶対だという主義のチームでこの手の問題でスケジュールを遅らせて燃やすケースは多々ある。
一番良いのは見積り、仕様洗い出し時点で難しいポイントが特定できており、その検証を開発期間、費用に組み込んだうえで第 2 案 (プラン B とも言う) を用意する。この第 2 案は技術的に難しいポイントを仕様で回避する内容にする (確実に回避出来る見込みがない場合は複数プランを出す)。
スケジュール問題 2：開発チームのレベルが足りない
この問題は実はそんなに多く発生しなかったりする。 というのはあまりにも自分達の組織で出来ない難題を仕事として請ける所はそうそう無いため。 本当にチームの開発技術が未熟である事が原因の場合、案件を請けたことや、アサイン自体が間違えている事になる (最初から無理なチームだった)。
ただ、案件受託時に確証のあるものや経験のある開発のみ請けるという事は普通はなく、案件獲得時にはメンバーの成長見込みを含めた上で請ける事がほとんど。 そのため、その見積り (無茶な成長を狙ったこと) が間違っていた、という事になる。
この場合、回避策は開発チームのメンバーでは出来ない事を正しく認識し、それを出来る人を連れてくる (社内 or 社外) という事になる。
スケジュール問題 3：途中で仕様変更、作り直すと間に合わない
開発案件では途中が仕様が変更される事は良くある。 そのため、炎上した理由として一番多く挙げられる原因かもしれない。
仕様変更の問題が一番面倒な揉め事ではあるが、大体の場合は目先の話のみで仕様を決定するなどしてしまうために発生する問題だったりする。 顧客の「言葉通り」のシステムを作る時にこういった事が発生しやすく、本来仕様を策定する際にはその言葉の先にある要求を拾わないといけない。そのためには顧客と同じ視点に立てるだけの知識とそれなりの経験 (ドメインの話) を持つ必要があり、顧客がシステムを通してやりたい事、表現したい事を認識した上で、より良い仕様に昇華する必要がある。
また、顧客の「言葉」を仕様に噛み砕く作業をしない場合も「炎上」を呼ぶ一因になる。 仕様書に求められる内容は、誰が見ても同じものを認識できる曖昧性のないロジカルなもので、「~のようなもの」や、「~を参考に」「いい感じにする」等は仕様ではない。 これを仕様と思っている人が多くいる (仕様と思っていないがこういう資料しか書かない人は仕様を作っていない事になるので一番悪質) が、それはアイディアレベルのものである。
仕様をうまく書けない場合、顧客によほど恵まれるか、開発メンバーに恵まれない限りほぼ確実に炎上する。 それくらい仕様は大事となる (仕様を通しての顧客とのコンセンサスが重要という話)。 さらに、仕様を策定する際にエラーケース等、通常想定の使い方以外をした際にどうなるか、悪意を持たなくても発生しやすいもの程ここで詰められないと本当に苦労することになる。
ただ、あまりに細かい仕様は最初期のフェーズで詰めようとしても無駄になりがちなので、ある程度 (少なくとも正常系の動作を定義する程度は欲しい) 作成したら、一旦実装、動作検証、顧客からのフィードバック、仕様 FIX という流れがオーソドックスだと思う。 とくに最後の仕様 FIX のフェーズが大事で、この時点で一度確定させ、ここで細かな情報を仕様として盛り込んでおかないと、後々細かな仕様が不明になり論争の種になったりする。 仕様のアップデートをせず、納品まで仮作成時の仕様のまま放置されるなどが炎上の引き金になるので注意するポイント。
スケジュール問題 4：開発期間が短かすぎる
端的に言うと、見積りが明らかに間違っているケース。 とはいえ、見積りをどれだけ頑張ってもピッタリうまく行くというのは余程の練度がない限り難しい。
良くバッファ (空きのこと) を持たせるという話もでるが、バッファというのも本来の意味からするとおかしな話である (開発期間に余分な期間を入れる意味は顧客に説明できない)。 開発をする際、下記のようなステップが必要になり、それぞれである程度の期間が必要になる。
- 見積り
- ヒアリング & 要求分析 & 仕様策定
- 工程洗い出し
- スケジューリング
- 開発 (随時ドキュメントの作成も含まれる)
- 内部テスト
- 受け入れテスト
これだけある工程のいくつかは小規模の案件では省略されがち。 本来は見積りの際にこの工程全ての期間を考慮した上での金額と期間を提示するべきなのだけど、顧客側の強い要望によって色々なものが省略されることもある (勿論開発側がこの体制を何故かとっていないことも良くある)。
金額の減額交渉や納品までの期間の短縮交渉など (ひいてはその両方も) が顧客から良くある要望なのだが (この時点ではまだ要望)、仕事を取るために応じる事は良くあることなので、その際に上記項目が暗黙の内に削られることとなる。
その際には、本当は削られる分だけ何かが犠牲になるため、依頼してきた顧客にはその説明と納得をして貰うようにマネージャーは動く必要があり、それが出来ない場合は、内部の努力によって無理矢理捩じ込む事となる (そういう分かり易く駄目そうなものは、見積り段階から「炎上案件」と呼ばれたりする)。
不具合がある場合
不具合がある場合は請負の場合、瑕疵担保責任 (かしたんぽせきにん) が発生し、修正する義務が生じる。
そのため、修正するコストを開発側が負担する必要があるため、この修正で稼動した分は請求する事はできない。 不具合が軽微なものであれば、すぐに直してチェックにまわす事ができるが、重篤な不具合の場合は直ぐに納まらず、延々と顧客に怒られながら修正対応をする事になる。
正直、不具合のケースでは回避策というものはなく、いかにこれ以上燃やさずに後始末をするかになってくる。 現開発チーム (プロジェクトマネージャー含む) で収拾が付かない雰囲気があるのであれば、チーム外から人を連れてきて、不明瞭な仕様の洗い出しと、不具合の洗いだしを先に行なう必要がある。 この時に闇雲に修正作業を行なってしまうと、後でとりかえしの付かない不具合が別の箇所から出る事もありえるため、一旦作業の手を止めて、状況の精査と顧客とのやりとりを優先する事が先決となる。
また、修正作業の際に、顧客から修正に乗じて追加作業を依頼されたりもするのだが、直り切っていない時に追加機能を入れると更に状況が悪化するため、この状況のときは絶対に受け入れてはいけない。
結論
プロジェクトマネジメントは基本的にプロジェクト内での QCD が適切に定義されていないと滅茶苦茶になることがある。
一般的には上流 (この呼び方はあまり好きではないけど) と呼ばれるフェーズは非常に重要な役割を担っており、ここで転けている場合は全て開発に皺寄せがくることになるし、開発が始まる前から不穏な空気が漂うことになる。 また、上流工程の人間がプログラムを書けなくても問題ないという意見などがネットで見られるが、上流のみ担当し、プログラムが書けない人間が間に入る事で、顧客とのコミュニケーションが全く上手くいかず、大変な抉れかたをすることも多々ある。 そのため、上流工程のみを担当する人間は開発速度や生産性という部分では能力を求められないが、実際にプログラムを書く人間よりも幅広い知見と技術を持っていないと、開発メンバーの発言の意図が汲み取りきれず顧客に間違った話をしてしまう事がある。
ただ、プロジェクトマネージャーはプログラムを必ずしも書ける必要はなく、適切に顧客や開発チームの両方とコミュニケーションができ、両者の利益が最大になるようなバランス感覚を持っている事が重要だと僕は思っている。 その為、プログラマからプロジェクトマネージャーに昇格という文化は、マネージャーがバランス感覚を欠いている上に、マネジメントという専門技術を訓練せずに転職するに等しい行為のため、炎上を増やす仕組みに見えてしかたない (もちろん上手く人も多くいるが、それはその人が凄いだけで流れが適切という話ではない)。
本来適切にマネジメントすることで回避できる案件が非常に多いのを会社を立ち上げ、色々な業務に関わってくる事で非常に強く感じた。 立ち上げる前はチームの動かし方など、チーミングに近い方に関心が強かったのだなと思う。
0. プログラミングの学習を開始する前に困る問題
以前上記記事の中でやるべきことを書いたが、各項目を実際に掘り下げていく前に、プログラミングを初めたいという人から質問される内容を書いておく。 なのでステップ 0 という意味のタイトル。
PC は買うべきか問題
プログラミングを初める人が、かなりの割合で気にするのは PC は専用で買うべきか、何を買えばいいのかを聞いてくる。 これは仕方ない問題で、実際良い質問だと思う。
実際に判断する基準は、何をしたいか (なんのプログラムを書きたいのか) に依存するのだけど、それだけだと何も伝わらないので、下記候補を提示して説明している。
- ゲームを作りたい
- スマホアプリを作りたい
- Web アプリを作りたい
- 就活に有利であればなんでもいい
- 特に方針はなく、とにかくプログラミングを覚えたい (知的好奇心)
どの選択肢をとるにしてもノート PC を持つべきという前提を先に明示しておく。
1. ゲームを作りたい場合
現代のゲームというと、各種コンシューマゲーム機 (PS4 などのゲーム機のこと) か、PC ゲーム、スマホゲーム、ブラウザゲームという環境に分かれる。 その中で、スマホゲームやブラウザゲームは Unity か HTML 5 で作られる事が多い (他開発環境も多くあるが、Unity が非常に多い)。 そのため、Unity を利用したゲーム開発の場合、Windows、Mac がベース選択肢になる (確認用の実機を iPhone しか持っていない場合、Mac がないと作ったゲームを iPhone に入れられない)。
家庭用ゲーム機、Steam などは Windows を前提にした開発環境を展開している事が多く、Unity を使わないゲーム開発を覚えたい場合は C# と DirectX が使える Windows を用意しておく事が望ましくなる。
2. スマホアプリを作りたい場合
スマホアプリを作りたいという人は大体は iOS (iPhone) か Android のアプリを作りたいという話だと思う (ここでは他は除外しておく)。 iOS アプリの場合は Mac が必須になる。これはプログラムの動作確認を実機で行なったり、作ったものをリリースする際に Mac を使うからで、持っていない場合はエミュレータ上で動くものを眺めるだけになる。 また、Android は Windows、Mac、Linux など、主要 OS の上では動作するため PC 購入の際に OS を気にする必要はない。
3. Web アプリを作りたい場合
Web アプリはどの OS でも開発出来るのでそんなに気にしなくても良いが、Windows はまだ今から開発を初めるという人が使うには難しいポイントが多いため、出来れば Mac か Linux を使う方がいい。 ここで初めて Linux がでてきたが、サーバでは Linux を使う事が多く (Winows や Mac、他 OS もあるけど)、どの道使う必要があるのであればいつ覚えても同じというスタンスで考えている。 最近は Ubuntu など、Windows や Mac に非常に近い使用感で使えるようになっているため、インストールさえできれば後はググりながらでも使える筈。
Mac は、Linux を最初に覚えるのが難しい人向けだけど、Mac と Linux で微妙に細かい部分が違ったりするため、その面倒な所にぶつかった際が面倒だが、web 上に情報は多くあるため、とりあえず使い初めるには楽な環境だと思う。
4. 就活を有利にしたい場合
就活を有利にしたいというのであれば、2 か 3 をやるのが良いと思う。
5. プログラミングを覚えたい (知的好奇心) の場合
今目的のものが無いというのであれば、とりあえずお金がかからない方法で勉強するので良いと思う。 持っている PC、OS を使って CS の勉強があまりお金がかからないかなと (本の購入は必要だけど、PC を新たに買うよりは遥かに安い)。
結論
PC はやりたい環境によって必要になるものが違うので、すぐ買うのではなく、なにがやりたいのかを考えてから買うようにしないと、端末の問題で勉強するスタートに立てない等ある。 あと、ネットである程度勉強できる時代なので本を軽視しがちだけど、余程のことがない限り本は有用なため、自分がやりたい分野の本は何冊か買う事になると思う (とりあえずは一冊買ってやってみると良い)。
プログラミングを OJT で教えていて思うこと
最近業務の中で若い子 (具体的な年齢は知らない) にプログラミングを教えることがあって、その所管を書いておく。 その子のスキルと現場の方向性としては、下記のような感じ。
現場
PHP / Laravel / MySQL で、フロントは Vue.js だったり/ jQuery だったり。
学習者
管理画面の基本的な CRUD な画面は作成できる。 JS もプラグイン導入や簡単な動きをつけるくらいはできる。 DB の基本操作はGUIツール、エディタは VSC という感じ。
結構いろんなタスクを振られるようで、対応可能な作業は以外と多い。
本題
当該の子と深くコミュニケーションをしたわけではないので、想像の余地が大きいけど、 技術に対して苦手意識はないように感じる。
多分 Laravel 主体で開発を覚えたのかなという感じで、気になるポイントがいくつかあった。
- Class とオブジェクト、インスタンスという言葉やプログラミングにおけるそれらの役割と挙動を知らない
- 1 次元配列 2 つによる総当たりを書くイメージがない
- 集合を知らない
他にもユニットテストとか、知らないものをあげると色々あるけど、 それは業務中のどこかで知るし (テストは教えたけど)、業務で直接的に支障でそうだなというものをピックアップしてみた。
オブジェクト指向系の言語で class やらインスタンスやらが分かっていないのが一番の驚きだったことで、 $this やらインスタンス生成からメソッド実行まで色々書いている実績もあるんだけど、というのが衝撃だった。 自分は理屈で理解できないと全く書けない人間 (比喩ではなく、確信が持てないと書いても的外れなエラーになるので構造の調査を良くやる) なので、よくわからないけどテンプレートで書くっていうパターンでお願いした動作をするものが上がってくるのが不思議で仕方なかった。
ソースも確認して、レビューはしてる (言うことは勿論多いが言いすぎると進まないので少しずつ改善するようにしてる。) けど、そんなそぶりはないコードだったのを考えると、 実は自分が思っている以上に、詳細はよく分かってないけど目的の動作をするものを作れてる人は多いのかなと思った。
配列の総当たりの話にしてもそうだし、集合の話もそうなんだけど、 Webフレームワークを学習する中で別に必要にならないんだよな、と思うと途端に必要な筋力以外が発達してない感じかと納得がいった。 Webフレームワークに乗っかってルーティング、コントローラ、モデルを使ってビューに流し込みって言う流れの中で、1, 2, 3 のどれも (それ以外にも色々) 詳しく理解する必要がないのだとすると、 業務だけでは学ぶ機会が無くて、もしかしたら長い期間このままであることがあり得るなぁと思った。
結論
上記のようなことがふつうに起こりうることで、実際目にしたことを考えると、 プログラマーとして生きていくためには業務の時間外で勉強することはやっぱり必要だなと感じた。
それは、業務を業務外でやれとか言う話ではなく、 業務に全く関係ないことでも良いし、関係あるけど業務中で調べたり、勉強するのが憚られるものをやれば良いと思う。
もし勉強の目標がない人はとりあえず CS (計算機科学) を勉強すると良いと思う。 あと、自分が普段使っている言語の機能などの詳細な挙動や原理、使われてる概念の勉強も必要かな。
