NC-15

「『頭のよさ』をコンビニの現場から考える」を読んで「頭のよさ」をシステム開発の現場から考える

Text

　この人のコンビニシリーズは面白い。なんつーか、地に足がついた考え方してるというか。

　コンビニについては、実家が客商売してたんで、仕事内容についてはおおかた想像つく。散々手伝いという名目で小学校時代から働かされたからな。この業界入って、販売管理系のＰＯＳシステムにも関わったことがあるし。

　そういう経験があるんで、すげえ興味深く読めた。

[雑文]「頭のよさ」をコンビニの現場から考える

http://d.hatena.ne.jp/nakamurabashi/20090118/1232254355

　頭のよさ、悪さということについて、ずっと考えている。店長を始めたころからずっとだ。コンビニというのは、ご存知のとおり、バイトのなかでも「相当に楽」と思われている職種なのだが、ある程度レベルを追求しだすと、とてもではないが楽とはいえない。そして、高レベルで店を回すために仕事のシステムが完全に組みあがってしまっている店だと、いわゆる「使えない」やつは振り落とされる傾向が出てくる。

　確かに、コンビニのバイトって、楽なイメージが一般的にあるけど、ただレジ打てばいいってもんじゃないしな。まともに極めようとすると結構難しいんじゃないかなとは俺も思う。

　まあ、チェーン店の場合はマニュアル化されてる部分も多いが、高度にシステム化されてるとそのマニュアルを覚えるので一苦労だったり、そもそも対象が客という一番マニュアル化できないところだからなあ。

コンビニの仕事の特徴は、小売業界でも有数なほどに仕事がシステム化されており、ひとつひとつの仕事は平易だが、その平易な仕事がやたらにたくさんあると思っていただければいい。求められるのは、記憶力、そして覚えたことを即座に実行できる覚えのよさ、覚えたことを忘れないこと、そして最後に「それでも思い出せなかった場合、どうするか」だ。

　これは同感。てか、どの業界にも必要な資質なのかな。ただ、最後の観点が客商売だなと。

そのときアルバイトにはもうひとつ、「自分の責任の所在はどこまでなのか」を把握する能力も要求される。集団における自分のポジションの自覚だ。

　これ、意外と難しいかも。常に把握してなきゃいけないことなんだけどね。そんでもって、そのポジションの相対的な位置は状況によって変わるんで。

　問題はここから先だ。コンビニが小売業界で、まぎれもなく最先端を走っている分野がある。販売データの蓄積と、その活用システムだ。それを「基本的に」素人でも使えるようにしているところにコンビニの特徴がある。

　これで俺たちは飯を食えてるというのはある。それほど多い。どちらかというとコンビニのＰＯＳってそれが目的というのが多い。

　そんでもって、このくだりは、特に販売管理系のシステムに携わることが多いＳＥは必見。まあ、ある程度こなしてる奴は基礎知識として持ち合わせてるだろうが。

　発注・商品管理でなにより必要とされるのは、過去の販売データが「どういう意味を持つのか」把握することだ。固定客が極端に同じ商品を買い続ける場合を除き、売れる商品というのは、パッケージ、価格、商品の中身、販売時期、その店の客層、陳列した場所など複数の要因によって、必ず「売れる理由」がある。あまり細かく書くと業界者しかわからない世界に突入するので、ごく大雑把にまとめると「商品が売れるという、一見、運や偶然に頼っている現象を、できるだけ細かいパラメータに分解し、パラメータがそのようになっている理由を把握すること」とでもいえるだろうか。

（中略）

　ある商品がある。「こうすれば、売れる」という単一の理由ならばそれはひとつのシステムだ。しかしその理由が何十にもなれば、それはほぼ不確定要素に近い。そして発注をする人は、可能な限り、その不確定要素の占める割合を潰していくのが仕事になる。ちなみに、何年にも渡り経験を積んで、こうした要素のひとつひとつを体感で把握していき、達人の領域に達した人の発注能力のことを「勘」といったりする。

　俺たちがＲＤＢ作るときのテーブル構造は、この「商品が売れる要因」をキーとして検索しやすいような構造を意識しないと、使う側にとっても非常に使いづらいシステムになってしまう。が、実際は制約があることが多い。パッケージ、価格、中身、については本部のマスタで取れるけど、販売時期、客層、時間帯、場所等は店舗側で入れる必要がある。まあ、レジについてもそれらを入れやすいような作りにしてるが。不確定要素を潰す場合、店舗側でなきゃ把握できない情報を多く入れて、キーにしたほうが分析はしやすいが、そうすると今度はレジ業務が煩雑になるという欠点がある。ましてやそれを検索キーとする場合、慣れない奴はレジでもたつくだろうな。実際は店舗側で把握してる情報を全部放り込むのは不可能に近い。情報量が膨大だし、あまりにもリレーションをややこしくすると今度はパフォーマンスに支障が出る。何より現場は混乱するだろう。

　設計する際は、その辺も勘案して、何を使って、何を外すか決めないと拙い。結局、システム化には限度がある。

　そして、最終的に完成した「稼げる売場」が、実際に稼げるかどうか、稼げなかったのだとしたらどこがまずかったのか、それを自分自身で把握し、売場にフィードバックする能力こそが、最後に必要とされるものだ。

　まあ、システムはあくまでも補助的なものにすぎないからな。そういう観点では。

　でもって、こういうことを長年、えんえんと現場で考え続けて、あるいは観察しつづけてみて、こと仕事においては、頭のよさというのは、つまり「システムを把握する能力」と断言してよいのではないか、と考えるようになった。システムとは、つまり因果関係であり、構造だ。対象が、目に見えない、手にも触れないものの場合は、そうしたものを頭のなかで展開させる能力でもある。

　そして、システムを万全に把握したうえで、新たに自分自身でシステムを作り出せる人間が、いちばん強い。

　これは同感。いわゆる器用な奴は、その構造把握能力の習得が早い。俺の場合は「イメージング能力」と言ってるけどね。それが自分の周りだけでなく、他者の眼に置き換えて見ることができる奴が「頭がいい」と思う。

　そんでもって、システムを作り出すには、それが必須。俺の業界で言うなれば、「ＰＧとＳＥの壁」がそれに当たるかなと。特に業務系はその傾向が大きい。業務系のＳＥは、大体、得意分野持ってることが多いのもそうかな。

id:novtanは金融系が強いし、俺は人事給与系が強い。ここから先は俺の想像だけど、その手の得意分野の養成というのは、経験したプロジェクトの影響も大きいのかなと。そんでもって、それって一朝一夕につくものではない。

　やってるうちに、得意分野がつくって感じかな。

　まずはＰＧの頃に、「自分が作ったプログラムはシステムの中でどういう役割があるのか」というのを把握した上で、「そのシステムはお客様の業務の中でどういうポジションになるか」を把握する必要がある。詳細設計書だけ見るんじゃなく、その上位にある基本設計書を理解し、さらに要件定義書を理解するようにしないと、ＰＧからＳＥの壁は乗り越えられない。

　設計書というのは、地図のようなもんで、上流に遡るにつれて、縮尺が大きくなる感じ。大きくなるにつれて自分の位置というのは把握しづらくなる。上流に携わるようになると、よりでかい縮尺の中での自分の立ち位置の把握が必要になる。それにはイメージングが必要になる。

　まあ、こう言うと、古典的な守破離ってな話になるわけなんだけど、まあそれはそのとおり。必要なのは「守るべきこと」というのが単なるシステムであり、現実にあわせて柔軟に変化させなければならないのだ、つまりシステムが「なんのために」存在しているのかを理解できること。

　これは同感。システムだけじゃなく、そのシステムが存在する背景も読む必要がある。その背景が変われば適切なシステムの形も変わるしね。てか、ＳＥの教科書として使うのもいい内容だ。俺が後輩や部下に教えてる内容も概ね近いな。さらにいえば、マクロで見る目とミクロで見る目の両方持てとは言ってるが。マクロな目で自分の立ち位置を把握して、ミクロな目で細部を作り上げるという感じで。

　アホなバイトを使いこなすのに苦労している世の管理職とか店長の方へ。上述のようなことを考えて、俺がたどりついた「アホの使いかた」的なものを書いてみます。参考になれば幸いです。

　俺も後輩や他の協力会社の下位者を使うのに結構苦労してるんで参考になる。

　仕事を教える場合は、可能な限り、すべてを定型業務に還元すること。単純作業ってことですね。「こういう場合は、こう」というように定式化する。そして同時に「そのときに絶対やってはいけないこと」という禁止事項を徹底的に叩き込むこと。「やらなければならないこと」と「やってはいけないこと」の両面から行動を制約することによって、単一のシステムで動くようにその人間を縛るわけです。もちろん例外的な事態は日常的に起こるわけですけど、その場合「パターンから外れることはすべて、ほかの人に質問しろ」と言う。もちろん手がかかるわけですけど、そこはもう、仕事において能力のない人を使っているわけで、そこをコストと割り切るしかないです。また、禁止事項については「こんなことをすると、おまえは（あるいは周囲のだれかが）ひどい目にあう」というかたちにすると効果があります。利益とか損失とかだめです。それは抽象概念ですので。

　俺も似たようなスタンスだな。習熟度によって違うけど。「やるべきこと/やっちゃいけないこと」の徹底は先にやるし、指示内容も定式化、具体化を意識する。禁止事項の影響についてもなるべく具体的な形で言うな。

　例外時の対応は俺の場合はちょっと違う。最初は「とにかく他の人に聞け」で、「聞いて実際にやった内容を報告」させて、「次回同様の事態が発生したらどうやるべきか考えてみ？」と投げかけて、帰ってきた結果をレビューする。これはある程度習熟度がついてからの話だが。なれてきたら、定型業務の中でもさらに効率化できる案を考えろとはいうな。同じこと何回も聞くのって、結構不細工な話なんで。

Permalink | コメント(0) | トラックバック(0) | 10:59