Matzの部屋 vol.4（まつもとゆきひろ氏 × 柴本優太）

よろしくお願いします！

はい。是非聞かせてください！

そうですね。生産性を正確に測る基準ってあまりないので、主観で「今回の仕事は生産性が高かった気がする」みたいな回答になっちゃうんですけど、割と放置気味のプロジェクトの方が生産性が高かった気がするんですよね。

私が大学を卒業して一番最初に勤めた会社って、いわゆるSES（System Engineering Service）の会社、いわゆる受託開発の会社だったんですけど、マネジメントされると辛いんですよね（笑）

何が辛いかっていうと、約束させられることなんですよ。
「この仕事をいついつまでに完了しろ」みたいな約束なんですけど、その前に「いつまでにできるか」を聞かれるんです。当たり前ですけど、それで約束した時期までにできないと怒られるんですよね（笑）

だから、「いつまでにできるか」って聞かれた時に予めバッファーを設けるんですけど、直感的に見積もると「自分が100%の能力を発揮できたらこのくらいの時間で終わります」っていう見積もりになってしまうんです。
でも実際のところ、例えば同僚が話しかけてきたりとか、電話がかかってきたりとか、会議が入ったりとかで、どんどん仕事する時間が減ってしまうので、100%の能力を発揮できず、言ったはずの期限までにできない事態が発生するんですよ。

そういう事態を防ぐために、「僕が100%の能力を発揮してこの仕事をするならばきっと1週間で済むけど、いろいろ妨害が入る可能性が高いから3週間って言っておこう」みたいに答えてしまうようになるんですね

多めに見積もってるから、だいたい約束は守れるし楽なんですけど、面白いことにですね、そういう風に伝えた時に限って、すぐにできてしまったりするんです。（笑）

これってつまり、本当だったら1週間でできるはずの仕事に3週間もかけてしまってるわけですよ。3週間かかるって約束して3週間でできてるので上司は文句を言わないけど、個人的には生産性は良くなかったなと思うんですね。

さらに言うと、クライアントの方は「もっと早くできるなら早くしてほしい」みたいに思ってるはずなんですよね。
まぁ僕はクライアントと直接話すことはなかったので、もしかするとの話ですけど、上司が「いついつまでできる」って約束してしまうからその日になるわけで……これって結果的に、ソフトウェアを作る時にあるべき生産性が発揮されないことにつながるんですよね。

だから、あまり約束をしないプロジェクトの方が良いなと個人的に思っています。

私が携わった別のプロジェクトで、社内で使うためのツールを開発するプロジェクトがあったんですけど、社員の効率化に関わるものなので早く開発すればするほどよかったし、別にいつまで作れとかいう期限も何もなかったんですね。
だけど、良いツールを作りたいって思いを持っていたからなのか、割り込みのない時は、自然と自分の能力を100%発揮できていたなと感じます。

こうした経験もあって、むしろ管理されないプロジェクトの方が生産性が高かったと感じるし、自分自身の満足感も高かったです。
受託開発はクライアントに「いつまでに作る」って約束するから、時間管理の部分でも融通が利かないけど、ファミトラみたいに自社サービスを作ってるところだと、別に対外的な約束はあまりないわけですよね。

だから可能性として、ファミトラだと主観的に生産性が高い仕事のやり方ができるはずなんですよね。そうだといいなと思っています（笑）

で、時間の管理っていうのは、約束するという面ではすごくいいし、ビジネスを回すために必要な時もあるんだけど、ファミトラみたいなビジネススタイルの場合だと、生産性のために敢えて時間の制約を緩める方が実は有効なんじゃないかなという気がしてますね。
だから、自社プロダクトを作っている企業さんと話す時には、大体そんな感じで「生産性を上げてみてはどうですか？」みたいな話をすることが多いですね。

逆説的なんですよね。

どうなんでしょうね。プログラマーなので、例えばパフォーマンスツールみたいなのが出てきたり、自分のジャンルに使えそうな色んな新しいツールが公開されたりすると、喜んで試してみたりはしますね。

あと私はだいぶオールドタイプなので、エディターにEmacs(※1)っていうすごく古いエディターを使っていて、これが体の一部になってるんですよね。
編集でカーソルを動かす時の指の動きとか、「Ctrl」を押したらどうなるかみたいなものが身体の一部になっていて、もうなんていうのかな……意識する前に「この関数の一番上に行く」とか「このファイルの一番上に行く」みたいなキーは、「行こう」と思った瞬間に指が動いているんですよ（笑）

もちろん最近のツール、例えば「VS Code」とかが素晴らしいっていうことは知っているんですけど、VS CodeのEmacsキーバインディングとかだと、なんかうまく動かないとか、サポートしていないキーバインディングがあったりとかして、変なポップアップが出て「あれー」みたいなことになっちゃうので、そのストレスに耐えられなくてまたEmacsに戻ってしまって（笑）

なので、そういう古いツールに染まりきってない皆様は「どうぞ新しいツールを使ってください」っていう感じでもあるんですが（笑）
私の場合だと、Emacsがないと文書書きやコード書きの生産性がだいぶ落ちるので欠かせないツールですね。

あとは、そうですね……私はトラックボール(※2)派なんですけど、トラックボールやキーボードにだいぶこだわりがあるので、たまに新しいのを試してみてはやっぱり古いのに戻すとか色々やっています。

そうですね。私は理不尽なことが嫌なんですよね。特にソフトウェア開発をしている時に、例えば上司の都合や会社の都合で、自分の開発力が阻害されるとか、あるいはガチガチなマイクロマネジメントをされて、一挙一動監視されるみたいなことも嫌なんですよ。私の中に、あんまり数値化されてないんですけど、主観的な理不尽ポイントみたいなのがあって（笑）

なので「会社の組織がその理不尽ポイントを超えると転職を考える」っていう感じでした。

最初の会社の時は、会社そのものがちょっと傾きかけていたので、そろそろやばいなと思って転職したんです（笑）2社目の時は、僕は名古屋の会社に勤めていたんですけど、東京転勤を命じられたんですよ。「東京で働きたくないから名古屋の会社に勤めてたのに東京に転勤しろとは何事だ」と、そこで私の理不尽ポイントを超えたので、転職を考えて結局島根の会社に就職しました（笑）そういう部分が私の基準になっています。

とはいえ新しい仕事を選ぶ時に、話が通じるか通じないか、理不尽なことが起こるか起こらないかを、事前に把握できることは少ないんですよね。
だから、マネージャーとか会社の雰囲気とかを見て、「理不尽なことが少なそうだな」って思うかどうかということを意識するようにしていますね。

あとは、「人としてリスペクトしてもらえそうなところ」っていう観点で選んで就職してきたつもりです。特に大きな企業って、開発者を数字で見がちなんですよ。「何人月(※3)」とかですね。だから
なんと言うか、「柴本さん」って「人」で見てくれるような、「一人月」って見られることがないような企業に就職したいなと思っています。

一つは「自社プロダクトを作っているところ」ですね。
受託開発は受託開発で大事なんですけど、やっぱりさっきの話のような”理不尽ポイント”が高まりがちなんですよね。ビジネスモデルとして自社プロダクトを作っているところは、その辺の融通が利きやすいという構造的なプラスがあると思います。

もう一つは「社長の三橋さんが、プロダクトを大事に、プロダクトを中心にしてビジネスをするんだ」ということを意識しているので、それは結構大事なことだと思うんですよね。

ビジネスをしていると、どちらかというと「お金を回すことが大事」とか「営業することが大事」みたいになりがちな企業が多い印象なんですけど、ファミトラは「プロダクトを良くして、そのプロダクトを中心にしてビジネスをするんだ」という意識が三橋さんにあるので、この2点については「プロダクト中心主義」ということで、ファミトラの本当にいい魅力になり得るんじゃないかなという風に思いますね。