Mogicはかんがえる

親孝行の罠という話

Mogicで働いている人は遠くに親族がいるケースが多く、いつか誰か離れた場所から介護することもあるでしょう。

なれば、そんなときを見越して会社はどうあるべきかと考えています。

まずは、遠距離介護の実像が分かりやすい書籍から引用します。

ーーーーー
遠距離介護の幸せなカタチ
柴田 理恵（著）
https://www.sun.s-book.net/slib/slib_detail?isbn=9784396618155

柴田：（現在、東京に住んでいる）私は一人っ子で、母は父がなくなってから富山の実家で一人暮らしでした。

ですから母が病で倒れて介護が必要になったとき、最初は引き取ることも考えたんです。

でも、やめました。

断られるのがわかっていたから。

略

遠距離介護と言えば聞こえはいいですけど、おためごかしというか、他人様に全部お任せですから、ちゃんと親の面倒を見られない言い訳をしているみたいで、本当にこれでいいのかな、という思いも心のどこかにあったんです。

略

ちょうどそんなときテレビでご一緒させていただいて、私、川内さんに言われたんですよ。

「親に介護が必要なったからといって、離れていた親子がいきなり一緒に住んでもなかなかうまくいきませんよ」って。

略

川内：そもそも親と離れて暮らしている場合、実家にはそう頻繁に帰れませんよね。

交通費も大変ですから、年に一、二度、お盆やお正月に帰るだけという方が多いんじゃないでしょうか。

そういう方が、親に介護が必要になったからといって、それまでの適度な距離感を飛び越えて、いきなり濃密な関係、つまり、自宅に引き取ってしまうと、お互いにイライラが募って、子どもの思いとは裏腹に親子に親子関係が崩れてしまうことが多いんです。

「親孝行の罠」と言います。
ーーーーー

そうか、親孝行の罠というのかとハッとさせられます。

相手を大切に思い、自分にとって最善を尽くすことが一番良いことのはず。

ですが、それが双方にとって望まぬ結果をもたらすという話。

どこかで聞いた古い諺のようだと思うとともに、難しい局面こそ誰かに話を聞いてもらい、一緒にはたらく人たちでさりげなく助けられるのが理想かなと感じています。

家計簿と損益計算書、独自科目

家庭における家計簿と同じく、会社では損益計算書をよく使います。

平たくいえば毎月の収入と支出をみて、黒字か赤字かを確認するといった具合です。

家計簿なら区分する科目は収入、住居費、水道光熱費、通信料、保険料、交通費、自動車費、教育費、交際費となり、損益計算書では売上、給与、広告宣伝費、販売促進費、賃借料、水道光熱費、消耗品費、交際費、旅費交通費、減価償却費がおなじみです。

大枠は似ているのですが、違うところは会社の規模や業種によって科目のバランスが大きく異なることなんです。

3人の核家族がいきなり10人の大家族になることは滅多にありませんが、会社なら3人が20人になったり、違うビジネスを始めたり、売上が大きく上がったり、大型の設備を買ったりしますから。

ということを鑑みて、損益計算書では把握しやすくするために、自分たち独自の科目を作っていいことになっています。

運送業なら車両科目、卸売業なら仕入科目が増えるでしょうし、Mogicならウェブサーバ群、ライセンスサービス関連、パソコンや椅子などが細分化されています。

そして年に1、2回は計上する科目を見直して、新しく追加したりします。

大変そうだなあと思われるかもしれませんが、その過程で意外な発見があるので割と面白いものです。

専門職とのコミュニケーション

代表インタビュー5回目のテーマは、エンジニアやデザイナーというIT専門職とのコミュニケーションでした。

普段意識せずに話しかけているので、言葉にすると「ああ、そっか」となります。

-----
-　専門外の人が専門職に依頼するのは大変な気がしますが、そうでもないのでしょうか？

山根：専門職であるなしに関わらず、実はどんな職であっても他の職種の仕事って細かくは分からないんですよね。

例えば、今みたいにインタビュー記事を1本作るとしますよね。

ライターと写真家がいて、同じ場所で仕事をして最後に組み合わせて完成です。

ですが、ライターは写真家が細かく何をしてるか分からないし、写真家はライターが細かく何をしているかは分からないんです。

分からないけれどもライターは写真家にフィードバックできそうだし、写真家はライターにフィードバックできそうということです。

それと同じでエンジニアが作るプログラムや設計は見えないけどフィードバックできそうですし、デザイナーが作るデザインも同じです。

じゃあ、違う職種にまたがってアドバイスをしなきゃいけない、指示を出さなきゃいけない時に何が大事なのかということですね。

最低限の知識は必要ですが、あとはゴールのイメージを共有できる信頼感でしょうか。

信頼できる関係をどう作るかが根本にあると思っています。
-----

ITを山盛り使っているのに、信頼関係が大事って意外かもしれないですね。

本編はただいま絶賛編集中とのことで、今しばらくお待ちください。

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

2009年Mogicの旅

Mogicモジックという社名は設立当時よく間違えられていて「Magicマジックさん」はあるある、かなり遠めで「文字組みさん」「文字校正さん」といわれたこともあります。

さいわい最近はほとんど間違われなくなりましたが、逆になぜMogicという社名にしたのかを話す機会がなくなってしまいましたので、ここに書いておこうと思います。

-----
会社を作った時は一人でしたから、社名を考えるにも自問自答するしかありません。

まず思ったのは、会社は人。

どんなにITをバリバリやっても最後は人。

だからいろんな人が集まった時にどんな風に思えると素敵かなと。

「この場でいい出会いがあったなあ」と思えると申し分ないですね。

じゃあ、どんなのがいい出会いっていえるんだろう？

弾けるような笑いがあって、一人じゃできないことがパッと目の前に現れたらいいし。

そう、SF作家アーサー・C・クラークがいってたな。

「十分に発達した科学技術は、魔法と見分けがつかない」と。

だから、そうしようと閃きました。

「人と人が出会って素晴らしい化学反応を起こし、十分に発達したITを駆使して成し遂げられた成果は魔法と見分けがつかない」んじゃないかと。

作り話のように聞こえるかもですが、本当にアルキメデス風に湯船に浸かっていて思いついたんです。

少し短縮してベースのフレーズは「人と人をつないで、知恵を分かち合い、魔法のように成し遂げる」にしよう。

さらに、それを社名まで凝縮するにはどうすればいいか？

うん、人と人という漢字を二つくっつけるとMに見えるね。

次いで、つなげるってのは◯で表現しよう。

魔法は、Magicだ。

だから、M＋O＋Magic＝Mogic。

モジック、変な響きかもしれないけど、覚えてもらえそうだからこれで！

-----

そんな流れでした。

だから、会社のスタイルとして個人技より「共に成長し、チームワークを重視する」のは当然です。

そして、途中でインターン生がつけてくれた「Creativity Beyond Imagination」というキャッチフレーズ。

自分一人の想像を超える、みんなの個性を重ね合わせた創造という意味でこれもマッチしているのです。

2009年に会社として飛び出して、みんなであちこち旅をしてきました。

過ぎ去る日々に「いい出会いでした」と聞くことが増えれば、星空はるか湯船に浮かぶ自分からすればうれしいばかりです。

たかが、されど、そうして

とある料理研究家のレシピに感動してエッセイを読んでいたら、思いもかけず鍋やフライパンの手入れをしたくなりました。

まずは一番大変そうなやつ、ちょっとくびれて小さなミルクパンから。

外の焦げを大まかに削りとり、粗めのやすりをかけて、布で磨いて仕上げていきます。

はぁと息をかけて拭うと、使い込まれた道具は鈍くしっとり輝きはじめました。

不思議なもので、じぃと眺めるとまた料理がしたくなります。

慣れ親しんだ道具だからこそ、きちんと手を入れておく大切さ。

これはビジネスでも通じるように思います。

例えば、ごく簡単にメールを書くということ。

キーボードやマウスの操作、辞書に登録された固有用語、できるだけ誤解を減らす書き方、主語／動詞／目的語の明示、コピペのミスを防ぐ方法、メールの往復を最小化する流れ、相手が選びやすい選択肢の提示、見やすいように入れる区切り文字、抽象単語と固有名詞の配分、相手が返しやすい送信のタイミング、送信前のセルフチェック、迷惑メールフォルダに入る可能性の考慮、セキュリティを意識したファイルのやりとり。

一つずつ磨きこんでいれば、自分の思うように使えますから。

たかがメール、されどメール、そうしてメール、見なおして悪いことは一つもありません。

ベストじゃないプロセス

いつもベストなプロセスで進められればいいのですが、必ずしもそうではありません。

むしろベストの方が少ないんじゃないか、と考えれば日頃からトレーニングの仕方が変わります。

ITサービスを作るにあたり、プロジェクトを立ち上げます。

メンバーを集め、お金を算段し、アイデアを出し、市場を調査し、スケジュールを立て、モチベーションを上げ、要件にまとめ、デザインを描き、コーディングして、インフラを構築し、システムを設計して、プログラムを書き、データを流し込んで、テストをしたのち、不具合を修正し、プレスリリースをまとめ、メディアに出てから、ユーザーが使い始める。

簡単に書いてこのステップ数ですから、すんなりいく方が珍しいでしょう。

さらにメンバーのスキルが違い、コミュニケーションの方法が違い、得意分野が違い、これまでの経験が違い、抱えている仕事量が違い、これまで生きてきた環境が違い、重視している価値観が違い、年代や性別が違い、楽しく感じることが違います。

いわずもがな、バラけている方が普通です。

ならばと、普通であるはずのベスト“じゃない”プロセスにどんなものがあるかと想像してみるのです。

少し考えると、むしろその方が難しいと分かります。

なんといっても分岐していくパターン数が膨大になりますから、そこから思考が先に進みません。

でもそうすると、ベストじゃないプロセス自体を想定できませんからトレーニングができないことになります。

ベストなプロセスを目指すために、ベストじゃないプロセスへの対応力をつけたくても、ベストじゃないプロセス自体を思い描けないということ。

このジレンマをどう克服すべきなのか？

そもそもあらかじめ人のスキルや経験を標準的に選抜し、プロセスに共通ルールを適用することでブレを最小化するという解決策もあるでしょう。

ですが、本当はベストなプロセスなんて存在しないという感性を共有し、目の前に立ち上がる不完全さにチーム全員が足を止め、納得するまで膝をつけ合わせる時間が重要なトレーニングになるんだろうと思っています。

当たり前をスローモーションで

ゆっくりと時間のある時にこれまで知らない分野を覗いているですが、最新の化学領域に目をやるとアト秒、つまり10のマイナス18乗秒という単位で新たな測定が始まっていると聞いて驚くばかりです。

ーーーーー
アト秒科学で波動関数をみる　※括弧内の秒数は分かりやすく追記
日本化学会 (編)、 新倉 弘倫（著）
https://www.kyoritsu-pub.co.jp/book/b10039911.html

それぞれの時間領域には、それぞれ特徴的に起こる現象がある。

物質に光を当てたときに生じるりん光の寿命は、マイクロ秒（100万分の1秒）の領域である。

同様に物質に光を当てたときに生じる蛍光の寿命は、ナノ秒（10億分の1秒）からピコ秒（1兆分の1秒）の領域である。

略

分子の振動波束運動や分子中の原始の組み換えを伴う化学反応は、フェムト秒（fs：1000兆分の1秒）の領域で起こる。

アト秒（as：100京分の1）時間では、分子の構造変化が起こるよりも速い時間で、電子ダイナミクスを測定することができる。
ーーーーー

ここまで微小な時間単位とはいわず、日常生活でも設定された時間の枠によって見えるものが違ってきます。

高速道路を飛ばして流れていく景色とぶらぶらと道草して感じられる風情。

せかせかと急いで向かう通勤路とふっと夕ご飯の支度が感じられる帰り道。

達成したくジリジリ焦る気持ちとありがたさにしみじみと感謝する心持ち。

ということで、今年は一つ、当たり前だと思っていた仕事をいろんなスローモーションで捉え直してみようかと思い立ちました。

スローにすればこれまで見逃してきた大事なことを見つけられるかもなあ、とまで書いてから、ああ、すでにこの前置きこそ、年始のご挨拶としては長く間をとりすぎました。

気をとりなおして、今年のMogicは15周年イベントが盛りだくさんです。

みなさまに楽しんでいただけるよう、準備をはじめています。

本年もどうぞよろしくお願いいたします。

静かに仕事を納めていく

年末はインフルエンザや風邪が流行っていて、静かに仕事を納めていくモードになりました。

緊急連絡網はアップデートしたかな、戸締りし忘れそうなところ分かってるよね、元旦のメール配信は事前にテストするんだろうなあ、仕事始めの準備もしないとね。

いつもと違う流れだからこそ、見落とさないようにしっかりチェックしたいものです。

立場柄、うん、そうですね、そうこう言ってはみるものの、このゆったりした空気感も捨て難く。

ズザザザとシュレッダーに書類を入れたらあと1週間で来年だなんて、信じられないなと思っています。