00:10
こんにちは。
こんにちは。
キントン認定エキスパートに聞くのコーナーでございます。
ボリューム1としましては、柳徹さんにお越しいただいています。
ありがとうございます。
おはようございます。こんにちは。
柳さんは、2022年9月ですかね。
9月ですね。
キントン認定エキスパートの改善マネジメントエキスパートに合格されております。
はい、ありがとうございます。
いつもの感じで、徹さんと呼ばせていただいて、進めさせていただきますが、
よくあるキントン認定エキスパートとか、
キントン認定資格、受験対策的なところがあるので、
ノートとかいろんなことが書かれているかと思うんですけども、
受験対策じゃなくて、合格された方がどんな形でキントンに携わっているか、
業務改善と向き合っているかっていうのを、僕自身めちゃくちゃ興味があって、
ちょっとそっちを深掘りしたいなって思っております。
なるほど、なるほど。
で、とはいえ、キントン認定エキスパートには避けて通れぬ、
キントンサインポストっていうものがあるんですけども、
柳さんが大事にしているキントンサインポストのステップ。
ステップって何かっていうと、
皆さんここからはキントンサインポストのウェブサイトであったり、
書籍でいうと7ページあたりを見ていただいたりしながら、
聞いていただきたいと思うんですけども、
ステップ0はキントン概念理解。
ステップ1からいくと、1が目的設定、2がプロジェクト企画、
3が設計と構築、4がリリースと定着、5が運営、6が継続企画、
っていう全部で7ステップになっているんですけど、
チェスさん、キントンの業務改善するとき、どこを大事にしています?
2つあって、全部が大切って言っちゃ全部が大切だとは思うんですけれど、
僕がいろいろ体験してきた中で結構重きになるなって思うところは、
1と2を行ったり来たりするような感じが多いかなっていうのがあるんですよね。
1が先なのか2が先なのかって言われると、
当然1が先ではあるんですけど、
03:02
1の目的設定が先な感じはするんですけど、
1の目的設定を例えば枝番の05から12まで順々にやって、
じゃあ次に2に行くかっていうと結構そうじゃなくて、
1の05は最初結構定める部分もありながら、
2の方にちょっと重心を置いたりとか、
でもまた1の例えば07に行ったりだったりとか、
なんか行ったり来たり行ったり来たりみたいなのをしながら、
徐々に積み木を積んでいくような感じで、
この1の目的設定と2のプロジェクト企画っていうところに、
結構肘を置いてるところは結構多いんじゃないかなっていうのが思いますね。
行ったり来たりっていうのが面白いですよね。
なるほどなるほど。
多分2ってプロジェクト企画なんで、
どう進めるかっていうところの領域もあると思うんですね。
どう進めるかっていうところ。
3がどう作るかみたいな感じがあると思うんですけど、
2のどう進めるかっていう部分をやっていくと、
その進め方に結構軸足が置き始めちゃうことがあると、
目的を見失う。
よく言うのが手段と目的を履き違えるというか、
手段が目的化されちゃうみたいなところがあると思うんですよね。
なのでやっぱり1に戻ってきちんと軸がずれないようにっていうところで、
戻ってきたりっていう点で言うと、
多いんじゃないかなというふうに思うんですよね。
なんかそれって具体的なエピソードトークじゃないけど、
パターンってあったりしない?
それは…
もっと言うと、なんか212とかね。
121みたいな話。
もう少し見てない人もいるかもしれない。
121って何かっていうと、
目的設定とプロジェクト企画と目的設定を行ったり来たりとか、
逆に目的設定からきれいに進まず、
2からプロジェクト企画から始まったけど、
ちょっと目的設定の改めて戻りましょうよみたいな。
それで言うと、
例えば会社で、
キントンもそうですし、
業務改善のプロジェクトを立ち上げるってなった時っていうのは、
実は最初目的とか何のためにやるかってことは意外と曖昧で、
よくあるようにDX化したいだったりとか、
エパレス化したいみたいな形になったりとか、
スタートで来る場合っていうのは、
当然1を踏んだ上で2になってるわけじゃなくて、
2ありっきっていうのがスタートだったりするんですよね。
なのでプロジェクトはできてるけれども、
06:01
何のために集められてるのっていうのは、
実はプロジェクトメンバー自体が知らないとか、
自分ごとができてないみたいな形があったりするので、
そういう点で言うと、
2がちょっと始まってると思うんだけれども、
やっぱり1に戻んなきゃいけないよねみたいな形があったりするのと、
1って目的設定行って、
プロジェクト企画に飛んだのにまた目的設定側に戻るみたいなケースで言うと、
最初目的ははっきりさせたにも関わらず、
プロジェクト企画の中で、
例えば基本機能から考えるだったりとか、
自分たちのガバナンス設計みたいな形で、
ちょっと少しどのようにアプリを作っていくかみたいな風に考えたりとか、
デモアプリをいじったりだったりとかしていくさなか、
昨日ってこんなことできるね、あんなことできるね、
なんていう楽しくなっちゃう部分ってあるんですよね。
そうすると機能に惑わされるというか、
あれができたらいい、これができたらいいみたいな形になって、
無用なアプリが生み出されていくというか、
最初ってそのためにやろうとしたんだっけ?みたいなところが
すっかり埋もれてしまって見えない状況になって、
楽しそうな、でも役に立つか分からないようなアプリが
出来上がっちゃうみたいなケースがあったりすると、
いやいやでも何のためにやろうと思ったのかとか、
そこをきちんと解決されるのかどうなのかっていうところを、
やっぱりもう一回立ち向かおうっていうところで、
1-05だったりとか、それは基本機能とかが
均等なバランスを考える前に1-09の、
そもそも今の業務の流れを均等でアプリ化していくのが正しいのか、
いやそれはもともと違うなと。
もう一回そこも見直すべきところがあるんじゃないかな
なんていうのを、やっぱりもう一回立ち戻るっていう意味で言うと、
2をやってたと思ったらもう一回1に戻って再確認のような状況ですよね。
面白い。なんかあれですよね、なんかちゃんと、
1をね、1の目的設定をすごい大事にしている人であればあるほど、
すぐ均等開発したいとか、みんなに届けたいって思う人に、
まあ待てとか、ある意味おもちゃに触らせないみたいな、
いうようなことをあえて、いやいやもう均等に触る前に目的大事なんですよって、
我慢させるようなやり方も持っていく人もいるかと思うんだけども、
あえてちゃんと楽しさとか可能性をちゃんと会話させて、
前の目になった瞬間、まあとはいえちょっと一旦戻りましょうよみたいな感じよね。
ちゃんと面白さ楽しさ可能性を感じさせた上で、なるほど、面白い。
09:05
やっぱりね、進める言動力ってね、やっぱり感情の力を使うっていうのがすごく大事だと思うので、
今陽平さんおっしゃったような楽しいだったりとかワクワクするだったりっていう部分もやっぱり大事なので、
ワクワクするっていうエネルギーを使って目的を強固に固めていくみたいな部分になったりもするのかなーなんていうふうに思いますよね。
だって僕らもやっぱりなんだかんだ言ってずっと座学続けられてるセミナーとかってつらいじゃないですか。
そこにワークショップあったりとか、みんなでワイワイライブするようなもののほうが楽しかったりする要素もあるので、
それはやっぱり要所要所、目的見失ったときは戻るけれども、それだけだとつまらないから、
ちゃんとちょっとずつ形になれるようなものを触れたりとか、イメージできたりとか、感じられたりするような領域にも少し踏み込んでいく。
そういう点で言うと場合によっては、まさにデモ的なようなアプリを作るところで言うと、
設計構築の領域に若干足突っ込んで、また2に戻ったりとかっていうこともあるかもしれないですね。
1、2は結構最初はよく行ったり来たりするかなーと思いますけど、3とか。
1とか2とかっていうのがだいたい固まってくると、3と4行ったり来たりみたいな感じになるんですよね。
確かにね。
なんか臆病に進めてってるじゃないですか。
でもそれって臆病と言いつつ、なんかテストの中で過去の成功体験も過去の失敗経験もあるから臆病とか、もしくは臆病と言いつつ、
そう1、2をやってしっかり根付かせた方がその先、大きいサイクルとか長期的なサイクルを持っていけるっていう、
自負っていうか大事さとかね、あるからそう確信として持っていけるのかなって気もするんですけどね。
そうですね。
擦り傷ぐらいで済むものはなるべくちょっと触ったり着手したりっていうことはありますけど、
致命傷になっちゃうような危ないものはやっぱきちんとちゃんと基礎的なところをちゃんと踏むっていうのは、
その辺は大事にしているのかな?これにちょっと関係あるのかわかんないですけど。
致命傷ってどういう状態ですか?
12:01
致命傷っていうのは…
結局筋トーンダメで、エクセルでいいじゃんとか、やっぱ今のままがいいよねって思っちゃうとか。
しくじると影響ができすぎる領域?
例えば、お客さんにも関わるようなもの、社内だけに届く。
例えばお客さん側と筋トーンのデータを共有するだったりとか。
お客さんというか社外の人に、
例えばフォームブリッジなどを使ってデータを投稿してもらわないといけないようなステップがあるだったりとかっていうのって、
関わる領域が広いと、そこに嫌われてしまうと、
悪いアドバンテージの状態のまま、それを何とか挽回するためのいらない努力を強いられる形になるので、
そういう場合については、きちんとノリとか楽しさだけじゃなくて、
安定して幅広いところまで深く検討した上で進めていかないと、
取り返しのつかない部分になったりする可能性があるので、
なかなかそれが致命傷になりそうな業務領域っていうふうに勝手に言ってますけど。
いやでも、それってすごいよ。
なんかあれですもんね、失敗から学ぶっていう言葉とかね、僕らの身近だと山ほどありますけど、
でもその一回の失敗で致命傷とか立ち直れないような失敗もね、事実としてはあって、
そこはやっぱ避けなきゃいけないとかね、っていうのはあると思うし。
だから絶対に失敗していけないところは、やっぱりちゃんと抑えておかないといけない。
そういうことですよね。
それでもね。
そこは、その失敗でいうと、またサインポストのステップでいうと、
どこで歯止めかけてる感じですか?目的、1、目的設定、2、プロジェクト企画、3、設計構築、リリースと定着とかでいう。
3?
3、設計と構築時点で。
この辺あたりでは、これはって、ちゃんと1、2、きちんとやった上でやんないと、
15:05
まずいなっていうものが3ぐらいでは見えてきたりすると思うんですけどね。
そこって、地名書で導入するお客さん側だと気づかない、その時点で気づいてないこととかもあったりするじゃないですか。
それをそこ踏み込むと、こんな崖ありますよみたいな、崖踏み外すケースもありますよみたいなのをテッタのほうが伝えるってことですか?
全部ではないかもしれないですけど伝えるケースありますね。
でも結構出るのが、お客さん側が目の前の利便性を取って、親子アプリにしたくないとか、担当別アプリに発想がないみたいな形とか、
技術的というか専門的な話になると、これ絶対Lookupで制御した方がいいものをドロップダウンしちゃったりとか。
これはオペレーションの慣れで済ませられるのにかさまえず希望しちゃったりとか、後のメンテナンスとか。
っていうところが想像できたりすると、Aパターンの場合の良いところはこういうことです。
だけど後々の懸念心配はこういったものがあります。
むしろ逆にBパターンのメリットはこうで、デメリットはこうですっていう風に目の前にカードを並べてあげるっていう。
どっちも良いこと悪いことに。
なるほどね。
今あなたが進もうとしている道は絶対ダメですよって×つけるわけじゃなくて、良いことも悪いこともちゃんと見せてくれる。
なんとか僕は未来への心配が出る可能性が強そうだなっていう話を伺っているので、Aの方が良いですとBの方が良いですっていう風に言うんですけど。
それでそうだなっていうケースもあれば、そこについてはこういう風にやっていきますみたいな感じで、
はっきり返答されるケースの場合はじゃあそうやりましょうっていう形になりますけど。
やっぱり大事なのはリスクも含めてちゃんと飲み込んだ上で進められるかみたいなところは大事だと思うんですよ。
アプリの設計の部分だったりとか、フィールド一つとっての考え方でもですね、細かく言えばいろんな正解がある中で、
その正解を答えにするにはお客様側の方でというか、導入する側の事業者側の方でやっぱりその選択肢における一定の覚悟だったりとか、
そのリスクと利便両方合わせて飲み込むっていうところは結構求めなければならないようなところもあったりするので。
18:01
それあれですよね、なんか今気づいて思ったのは、クライアントさんだけじゃなくて、経営層から向けてスタッフ部門に対してもなんかありそうだなと思ってて、
僕らみたいに導入支援してる感じで言うと、もうそう半端く食らう可能性ありますよみたいなこととか、
ちょっと刻んだ方がいいと思うんだけどっていう時も、リスクを伝えた上で言うと経営者は結構肝据わってて、
いやあいつらは1ヶ月耐えると、最後わかってくれるからって、小説すれば大丈夫みたいなね、なんか覚悟を持って導入しようって前向きに言ってくれたりとか、
なんかその辺はさらけ出した上で、さっき言った覚悟とか決心とかいうとつながる場合もありますよね。
もちろんそれできちんとちゃんと乗り切れるケースもやっぱりあったりするので。
だからなんかどういうふうに世界を紡いでいくかみたいな部分については、いくつかやっぱりパターンを出してあげるっていうのは選べますよね。
僕らも普通にレッスン入ってこれしかありませんって言われるよりも、これとこれとこれがありますっていうのは多すぎて迷っちゃいますけど、
いくつかパターンを持った方がいいですよね。
治療、お医者さんでいう治療もそうですよね。
こういう治療方針でいくとお金かからないですけれどもとか、
例えば銀歯しか選べませんみたいな、自由診療とかだと白いセラミックが選べますみたいな。
別にそれって価値観の問題とか考え方の部分だったりするので、それが大事ですよね。
単純に一択の正解を示すよりも、1決定判断してもらって、
A、Bを選んだからこそ前に進みやすいとか成功率が上がるってこともあるようにしますしね。
あとはそういう点で言うと、2になるのか3ポスト上にはない可能性があるんですけど、
小さなリリース単位とかっていうところにもつながるのかな。
2の20?
そう、2の20。小さなリリース。
リリースしてるようでリリースしてないという状況を作るみたいな。
おー。
全員が使えるようになったらリリースっていう言葉を使ってあげることによって、
触ってる間が失敗が許されるトライアルタイムっていう。
あー。
これが聞くケースもあったかな。
それも小さなリリース単位って呼んでいいんだろうか。
本来だと20個ぐらいの関連性のアプリ全部一気に作ってからどんどん入れるっていうのじゃなくて、
21:00
もうちょっとシーズン1、シーズン2、シーズン3みたいな感じで、
ちょっとずつ単位を分けるっていうところだと思うんですけれど、
一つのアプリのリリースでもお披露目とテスト入力と、
改善後の再テスト入力と、トレーニングと、
いよいよ本格リリースみたいな形の5、5段階とか6段階に分けたほうが、
なんか怖いって。新しいシステム怖い。
キントンで怖いって思ってるけど、
そういうアプリのリリースっていうのは、
ちょっとずつでも自己成長感を持ってもらうとか、
なんか改めて反復し続けてる感じがしますよね。
そうですね。反復するような感じですね。
それの数が多いのが1と2なんだなっていう感じはしますね。
そういうアプリのリリースっていうのは、
一つのアプリのリリースの中で、
なんかそこが落ち着けば、本当に腰据えて3いけるんじゃないかなっていうところが。
なんかそう考えると、リリースまでしても、
現場に反発されてもまたね、
自己反省じゃなくて自己振り返りがあって、
リリースまでしても、
リリースまでしても、
リリースまでしても、
現場に反発されてもまたね、
自己反省じゃなくて自己振り返りで、
2とか1に戻ってきて、
ちょっともう一回再チャレンジするかみたいなね、
意外とか土壌も出てきてそうですよね。
だから決してこの順番でやるっていうことではないなっていうのは、
改めて今これ。
そういうことですよね。
1、2、1、2行ったり来たりしてると思ったら、
2、3、2、3行ったり来たりしてるような気もしますよね。
3、4、3、4でも行ってそうだなっていう感じがしますね。
そんな感じがしますね。
やっぱりこのステップが隣接してるのは今、
会話してても改めて思いますね。
そうですね。
ありがとうございます。
そんな感じで。
そんな感じで。
じゃあちょっと無茶ぶりですけど、
僕の大好きなゼロのゼロゼロ。
均等は均等。
24:01
やない鉄の均等は均等。
無茶ぶりですね。
でしょ。
均等は均等。
固まるといい感じなんですね。
そうですね。
均等をワークショップツールにしたらいいんじゃないですか。
すべてのいわゆるカスタマイズ、
一般的なシステム開発って、
要望に対してすべてぴったり寄り添いすぎるから、
利用者をわがままにするんですよね。
楽したがるじゃないですか。
でも自分が楽したいからっていって、
システム側に合わせるのが果たして早いかって言うと、
そうでもなかったです。
そのカスタマイズやる労力とお金をかけるんだったら、
均等の癖というか、均等の特性を理解した上で、
まさにそっちに寄せてしまった方が早いし安いし、
すぐだしみたいな。
いけたりするんじゃないかなっていうふうに、
思うことはありますよね。
均等は均等って言葉は、
俺はここにいるみたいな感じなんですよね。
こんな感じに見えますけれども、
その個性を理解してあげることで、
より早いし、楽に進むんじゃないかなと。
よくだから、
1企業でおけると、
お客さんと対等にとか、
あとは取引先も、
対等にパートナーとしてちゃんとリスペクトして、
みたいな形と同様に、
均等っていうのもツールとはいえ、
ちゃんと均等っていう存在をリスペクトして、
均等の価値をあって、
俺も俺であなたに会うし、
お前もお前で、
ちゃんと俺と向き合うよ、
みたいな感じで、
均等をちゃんとパートナーとして向き合う。
はい、はい、はい。
そんな感じですね。
人でも問題でもいいんですけど、
寄り添わないとうまくいかないですよ。
そこらへんとチームワークになりますね。
均等の価値をあって、
チームワークになりますね。
均等ですらチームワークメンバーですよ。
ということはね、
一人の仲間、一つの存在ってことですね。
均等っていう存在。
本当そう思います。
ありがとうございます。
27:00
ありがとうございました。
今回のゲストは矢内哲さんでした。
ありがとうございました。
ありがとうございました。
ありがとうございました。
