初のゲスト紹介
どうも、スティーブです。
コアラです。
Macbee Planet ササキと申します。
よろしくお願いします。
よろしくお願いします。
今日は、コアラがいるので、いつものコぽエンなんですが、
聞き慣れない声とお名前が今、登場しましたが、
コぽエンで初めてのゲスト、社外のゲストをお呼びしております。
コアラから簡単にご紹介いただきます。
情シスのイベントをきっかけに、1年前くらいですかね、知り合ったんですけれども、
とても明るい方で、仲良くしていただいているので、
ゲストにも来ていただきました。
自己紹介をお願いします。
改めまして、株式会社Macbee Planet、
管理本部コーポレートITグループでマネージャーをしております。
佐々木亮一と申します。
情シス歴は今、3年ちょっとですかね。
元々はフロントにいたんですけれども、
いろいろあって、最初にコーポレートITをやることになりましたという感じです。
よろしくお願いします。
タスク管理の工夫
社外のゲストの方が一番ちゃんとした自己紹介をしていただいたという。
本当です。
社外のイベントで出会ったんですね、お二人は。
そうですね、はい。
いいですね、そんな繋がりで、ふとわく軽くこんなポッドキャストに出ていただいて、
とても嬉しいです。
いろいろあって情シスになったみたいな、いろいろな部分とかすごい気になって聞いてみたいなとも思ったんですけど。
全然話せない内容とかではないので。
端的に申し上げると、当時上場して1年ぐらい経ったタイミングですかね。
社内のセキュリティとかココレートインフラ周りをしっかりと管理しないといけないよねっていう状況ではあったものの、
やる人が誰もいなかったっていうのでやるようになっただけではあるんですけど。
上場の後ですか。
はい、上場前は頑張ってそれっぽく取り繕って一応上場できるぐらいにはなっていたんですけど、
やはり最低限だと足りない、しっかりやっていかないといけないっていうところがあったので、
それで知らなかったといいますか。
なるほど、せざるを得なかった。
上質あるあるかもしれないですね。
そうですね、いろいろ拾わなきゃいけないっていうのがあるあるかもですね。
今、僕は無理くりあるあるって出しましたけど、
今日はどんな話題で佐々木さんもお招きして話していきましょう。
そうですね、せっかくなので上質あるある的なやつかね。
楽しいことも苦労話もお聞きできたりご相談できたりしたら嬉しいなと思っています。
タイムツリーはね、まだ上場していなくてそんなに組織の規模もないですけど、
小原と毎週放送で話してますが、毎週というか毎月いろんな悩みとか課題があって、
それをちょっと佐々木さんにも聞いてもらおうみたいな回ですね。
早速一個思いついたんですけど、
上質っていろんな細かいタスクがたくさんできやすいかなと思っていて、
ヘルプデスク的なこともそうですし、入体職対応もそうですし、
何か作るみたいなコーディングだったりとかシステムの導入だったりとか、
いろんなものが同時並行で動いていくことが多いと思うんですけど、
僕は自分の性格もあるのか、いろんなことを手出して全部中途半端なタスクが残るっていう感じで、
結構てんやわんやしちゃうんですけど、
そういうタスクが多いときに工夫されていることとか、
ちょっと佐々木さんにお聞きしてみたいです。
はい、そうですね。
タスク管理どうしているかっていうお話と理解したんですけれども、
自分自身も小原さんと同じように、
いろんなところから依頼が来たり、あれやりたいよね、これやりたいよねってなって、
結構発散しがちなのは多分これもあるあるだと思っています。
その中でどうするかというと、
まずはしっかりとタスクを起標するっていうところが重要になってくるのかなと思っています。
弊社ですとNotionを使っているので、
そちらでプロジェクト関連のタスクについては全て管理をしております。
あとはヘルプデスク系ですね、依頼来るものについては、
スラックのワークフローから自動的にタスクが起標されるようになって、
スラックのリストでタスクを管理しています。
それ以外にもあれやりたいよね、これやりたいよねみたいなものについては、
プロジェクト化する前の段階で、一旦アイデアとしてこれもまたNotionのタスクボードに起標することで、
とにかく全部手を出す前に一旦整理した上で、あとは優先導付でやったりとか、
期日設定をすることで、何でもかんでも中途半端になるというのを極力避けようとしてはいますね。
プロジェクト化の進め方
さすがですね、僕まだスラックリストとかもいまだにちゃんと使ってないっていうところなので。
なんかあれですよね、いろんなところからの依頼が来るっていうと、それぞれ文脈が違っていて、
それぞれのコンテキストを理解しながら、これってどういう依頼なんだっけっていうのを理解してやるって結構大変ですよね。
そうですね、把握できているものであれば全くないですけれども、
把握できていないものを一から事情聴取をしないといけないので、
その上で、必要なのかどうか、あとは緊急性と重要性を考慮した上でいつやるのかみたいな、
そういったものを考えながらやらないと、みんな好きかって言うんでね。
いいダクダクとしたがっていたら、何もできなくなるとなるなっていつも思います。
だからそういうことを、例えば今の緊急度とか重要性を落ち着いて考えるためにまずは一回全部リストアップするみたいなので、
そこは自動化して仕組み化するっていうところを佐々木さんやってらっしゃるんですね。
そうですね、当然自動的に起票される、ヘルプデスクとかについては、
対応してほしい人、希望者側がフォームを入力するので、それは自動的に起票されるようになっている。
一方でユーザーのヘルプではなく、もっと全体感を持ったツール導入であったり、
そのツール導入だけではなく、社内の運用ルールとかも含めての大幅な変更を加えるものについては、
そのプロジェクトとして立ち上げるという段階があるので、自動化できない部分ももちろんあるんですけれども、
可能な部分については自動化はしています。
いろんな文脈の質問が来て、でもそれをこっちが理解するのって、
結構何往復とやり取りが必要になることって結構あるかなと思うんですけど、
そこってフォームの作り方とか工夫ってされてたりしますか?
そうですね、フォームについて、ヘルプデスクに関してはもう一定パターン化されているので、
例えばPCの困りごとであれば、PCのOSが何で、メモリが何でどうこうっていう必要な情報ってある程度決まってくると思いますし、
特定のアプリケーション、例えば今使っているスラックとかノーションで何か困っているのであれば、
具体的にどういったエラーが出てとかっていうのを書くようにという風に誘導して、
フォームの中でも書いておけば必要な情報っていって集められるので、
そこのコミュニケーションコストはできるだけ低減できるようにしています。
一方で、先ほど言ってたプロジェクト化しないといけないような大きなものについては、
フォームで、要はテキストベースのやり取りだけでどうにかなるものではないので、
基本的にプロジェクトキックオフと言いますか、プロジェクト化する前段階として一度ミーティングとかを挟んで、
しっかりとヒアリングをした上で、プロジェクトとしてどう進めていくのかみたいなものは常に考えていますし、
仮にプロジェクトに起こすとした場合は、これもノーションでプロジェクト管理を行っているんですけれども、
プロジェクトの目的とタスク管理
プロジェクト検証として、そもそもプロジェクトの目的であったりゴールであったり、
そういったものは必ずまとめるようにしています。
なるほど、めちゃくちゃ勉強になるというか、
ちょっとラジオレギュラーでやっていただけないですかね。
あの、乗っ取っちゃうことになるんで。
いや、さすが、さすがですね。
コアラから学ぶことは多いですか、コアラとしても。
でも、そうですね。
自動化できるものはして、
でもやっぱりテキストだけだと、それはそれで見えない部分とか周辺情報とか得られなかったりするので、
そこはちゃんとミーティング設置しようねみたいなところって、
結構僕の場合めんどくさがり屋でテキストでいったみたいなところになりがちなので、
その辺りもっと意識した方がいいんだろうな、ちょっと思いました、真面目に。
テキストだけでできるんだったらその方がいいなとは思いつつ、
だいたいそんなシンプルな依頼ってそうそうないですよねっていう。
なるほどね。
そうですよね、マニュアルとかって。
コアラはどうしてるんですか、ごめんなさい。
コアラはどうしてるんですか。
僕の場合のタスク管理みたいなところだと、
一応弊社も似ててスラックとノーションを使ってるので、
ノーション上にタスクは作ったりはしてます。
そこで誰が何をしてるとか、
ちょっと進捗があったら忘れる前にすぐノーションに反映させておくとかはやるんですけど、
スラックでもワークフローは設置はしてたりはするんですけど、
その辺の整理がちゃんとできてなかったりとかするので、
わりかしメッセージで直接やり取りするみたいなところを頑張って即レスするみたいな、
そういった力技みたいなところが結構あって、
その辺り、例えば、
タイミングによって問い合わせが集中するみたいな偶然があったりするんですよね。
そういう時に漏れが発生したりとか、
あとタスク化するだけでもちょっと面倒、手間に感じてしまうので、
タスク記表すら漏れてるっていうこともあったりとかして、
その辺りのマンパワーをどうにかできないかなみたいに思ってたところでした。
なるほど。なんでコーラがすぐ黙っちゃうっていう。
社内コミュニケーションの重要性
話の終わり方が多分下手くそ。下手くそかもしれない。
そのコミュニケーション、そうですよね。
ジョーシスって結構、言っても社員とのコミュニケーションだったりとか、
そういう工夫も必要だったりするので、
なかなか技術だけをいろいろ管理してればいいって話でもないですもんね。
いわゆるITリテラシーみたいな言葉もよくあると思うんですけど、
やっぱり従業員の方の職種とか職務領域によっていろいろばらつくので、
どういう伝え方をしたらいいのかっていうところも結構、
自分自身も幅広く持ってないといけないのかなとは思いますけど、
佐々木さんとかも苦労とかありますか、その辺。
そうですね。自分はあんまり苦労してないんですけれども、
チームメンバー新しく入ったりすると、
社内の誰がどういう人でみたいな情報がないから苦労してるのはよく見てますね。
自分は子さんの部類なので、社内大体全員把握しているんですよね。
だからこの人はITリテラシー高いから、
この程度の説明で多分理解してくれるだろう。
逆にこの人はそこまでITに慣れていないから、
丁寧に説明してあげないといけないよね、みたいな。
やっぱり人によって必要とする情報量が異なってくるのを、
いかにうまく検知して対応するかみたいなのも一つ重要になってくるかなと思っています。
自分はそこ苦労してないのも、
しっかりと社内コミュニケーションをとって、
どういう人なのかみたいな、
どういう人がどういう業務をやってるのかっていうのを積極的に把握するっていう、
日頃からのコミュニケーションみたいなところは徹底的に意識してやっていた。
これは別に上質になる前からなんですけど、
やっていたので、そこは生きているなと思いますし、
逆に社内コミュニケーションをあんまりやっていない方針もあって、
対応のクオリティもコミュニケーション量に比例するんだなっていうのは、
最近ちょっと見えてきたものはありますね。
これは直接のコミュニケーションもそうなんですけれども、
例えばスラック使っているのであれば、
スラックのパブリックチャンネルにどんどん入っていって、
誰がどういうやり取りをしているかみたいなの、
パブリックであれば当然見ていいものとして、
積極的に取りに行くであったりとか、
やり方っていくらでもある、
直接会う以外にもリモートでもできることはあるし、
オフィスしかあってもできることはある中で、
どこまで誰が何をやっているかを把握しに行くか、
ここの積極性で結構、
上質の特にヘルプデスとか、
要は部外の人とのやり取りにおいての成果物のクオリティの差が
生まれてくるのかなというのは、
最近すごく感じていましたね。
