Mogicはかんがえる

やっぱり基本が悩ましい

誰かに仕事を頼む。

そんな基本的なことが一番悩ましいものです。

いつまでに、こういうものを、そうやって作ってほしい、という。

要件が伝わればいいから、整理するだけで十分なはず。

漏れなく、遅れなく、抜かりなく伝えました、と。

ですが、まあ、それだとうまくいかないことが出てきます。

思ったものじゃない、想定より遅い、言ったはずなんだけど。

されば、整理する以上のことを考えねばなりません。

さもありなん、これが悩ましい。

はじめての人だから、対面で誠実に話した方がいいんだろうか。

いや、それとも、ちょっと冗談でもいったほうがいいか。

いつもの人だけど、なんか、かなり忙しそう、大丈夫かな。

話し方は変わらないけど、なんで、くぐもった顔なんだろう。

切り出すなら月曜朝イチか、だけど、水曜午後イチがいいか。

メモ書きで間に合うけど、うん、スキのない資料がうれしいかも。

声で緊迫感が伝わるかな、そうだな、あえて言わなくてもね。

さくっと理解してもらってうれしい、けど、フォローはくどいかなあ、と。

気にかければ、とめどなくあふれてくるものです。

なれど、それにも限界があります。

「そんなに考えられません。頭がパンクします」

といわれそうですから、一つだけアドバイス。

これまで頼まれた仕事を思い出してみたら？

やりやすかった人と、やりにくかった人がいるよね。

その差ってなんだろう？

と。

いつか「あなたとの仕事はラクね」といわれたら、上機嫌。

こぼれる笑みに、締切がかすんできます。

ロングインタビューは続く

今年からロングインタビューをちょくちょく掲載していくことになっていて、新しく「クリエイティブについて」を話しました。

公開はまだ先なので、今回もさわりを先に

ーーーーー
- 一つ目は、「手に取れるクリエイティブ」についてお聞きします。MogicはIT企業ですから、プログラムやウェブデザインといったデジタルな制作物が中心です。ですが、なぜモノとしてのカレンダーやノベリティを社内で作っているのでしょうか？

山根：一般的な会社だとちょっとロゴを入れたり、色替えぐらいで済ませるのに、ゼロからアイデアを出して、素材を選び、デザインを作って、印刷に出して、検品して、梱包して、発送までをなぜ自分たちでやるのかということですよね？

- そうです。社内の人がやると時間がかかり、コストもかかるので外部の専門家に頼んだ方がいいのではないかと疑問が湧いてきます。

山根：これは、クリエイティブというものをどう捉えているかに関わっているんでしょうね。ちょっと遠回りになりますが、現在僕らが置かれている時代の背景からいってみます。

現代はモノがあふれてますよね。だから、モノは作るより買うほうが簡単です。1年のうちゼロから自分の手で新しいものをつくるという経験がどのくらいあるかなって数えたら、3個もないと思うんですよね。

新しいアプリをインストールしてみたり、ちょっと模様や形を変えるぐらいはあるかもしれないですけど、ほとんど誰かが作ったものを組み合わせてます。組み合わせることが悪いってことじゃないですよ、それはそれで便利な世の中ですから。

ただそれが普通になったとき、何かを作ろうとする人の気持ちやプロセスってどうやって知ればいいのかなと思うわけです。本当の意味でのゼロから作るってのはできないのですが、できるだけゼロベースに近いところから作るようにしてみると。

買うだけだと、これをなんで作ろうと思ったのか、どういうふうに表現したかったかなというのになかなか気付きづらい。作り手の気持ちをトレースするために自分たちで作ってみているんでしょうね。

時間をかけて一つずつ自分たちはどうしたいのか、どんなものが心地いいのかを確認するために、ゼロからつくろうとしている感じですね。
ーーーーー

何だか話したことを後で見返すと、他人のように感じるものです。

【後日追加】インタビュー記事の続きはこちら
https://www.mogic.jp/category/interview/13694

いきはよいよい、帰りはお任せ

誰かにサービスを提供しつづけるのは難しいものです。

ITだと一度プログラムを作れば後は半自動で楽じゃんと言われますが、これが落とし穴です。

分かりやすい表現があったので引用しますと

ーーーーーー
人が増えても速くならない
https://gihyo.jp/book/2023/978-4-297-13565-2

プログラムで新しい機能を開発する際には、すでにある構造の上に積み重ねるように作っていくものです。

略

プレッシャーに負けて一時的に妥協したとして、その直後に妥協して作られたものと同じ機能を、妥協しない品質で、時間をかけて開発しなおすことができれば理想ですが、それは事業側の人間からすると受け入れることは難しいでしょう。

略

そうして数年が経つと、「これ以上は機能を追加するにはどうにも手を出せない」状態になってしまうのです。エンジニアたちは、そうした状態のソフトウェアに機能を追加することに大きな不安とストレスを抱えることになります。このようなプレッシャーなどによる一時的な妥協は、借金や負債のようなものとして「技術的負債」と呼ばれます。

略

つまり、乱雑・複雑に作ってしまったものをシンプルな状態に戻すのは不可能と考えたほうがいいでしょう。
ーーーーーー

勢いにまかせれば、スタートは軽快です。

あれこれスピードを求めてやりつづけると、2年で詰まってくるでしょう。

打開すべくハイスキルな人を探し、大幅にリソースを増強し、さらなるモチベーションアップを図ってなお、最初よりスピード、クオリティ、ボリュームすべてが下がってきます。

目に見えない技術的負債が最大化された状態ということを、口に出さずともエンジニアやデザイナーら作り手が一番よく分かっています。

要は、技術的負債がもたらす利子を余分に支払っているのです。

それでも表向きのビジネスで大胆にスケールを追求した戦略を宣言しつづけるとどうなるか？

力強いビジョンという大義のもとに、力技で押しきる組織のメカニズムに抗いきれず、力あるエンジニアやデザイナーから辞めていきます。

覆い隠された構造的な問題は、個人レベルで解決しようがないからです。

残念ながら、技術的負債はそこではじめて目に見えるようになります。

ということで、ITのサービスを"続けること"は難しいのです。

別の角度からいうと僕らがサービスを提供しつづけられるのであれば、誰かが抱える技術的負債を代理でクリアにしていることになるのかなとも考えています。

いきはよいよい、帰りはお任せください。

塩がつないだ縁

オフィスの魔除けとして外ドアの左右に1つずつ盛り塩を置いていたのですが、コロナ禍の対応が一区切りついてやめることにしました。

円錐形の型に塩をギュッと詰めて逆さまに置くと、凛とした白い山ができます。

見た目がきれいで邪気払い感があったものの、しばらくすると崩れているということがよくありました。

特に1Fドアの外に置かれた盛り塩はよくバラバラになっていました。

なんでだろうね？と話していて、もしかしたら良くないことが起きているのではと頭によぎった夕方、インターフォンが鳴ってようやく分かりました。

「すみませーん、ドアの盛り塩なんですが……うちの子がさわってくずしちゃって……珍しいみたいで……」と若いお父さんの声。

「あら、そうですか、ちょっといきますね」とメンバが返答。

階段を降りていくと、たしかに皿の周りが砂場のように散らかっていたままで誰も見当たりません。

それからも忘れた頃に、人知れず塩の山は崩されていました。

やがて姿は見えずとも、きっと小さい子たちが遊んでるんだから良い兆しなんだと勝手に納得したという次第。

そうして盛り塩をやめると決めたとき、不思議と気になったのは彼らのことでした。

世には、人の預かり知らない縁があるものです。