アール公式?ブログ「無からの創造」

小売業向け基幹システムの開発会社「アール」 執筆者は4名体制で、マーケティングコンサルタント、システムエバンジェリスト、システム導入コンサル、管理部門が週2回、とっておきの役に立つ/くだらない話をお届けします。(くだらない話の方が多いのですが。。。) 提供:株式会社アール(http://www.eighteen.co.jp)

2015年11月

第2弾!
※twitter総集編(つぶやきチョイス!思わず耳を疑う女子高生たちのまさかな会話(もう無敵だわ!))から抜粋。

■笑1
後ろにいる女子高生っぽい人が「よく性格悪い女嫌いとか言ってる男いるけどさ?性格悪くなかったら女じゃねえから」って言っててなるほどなって思った。

■笑2
バスに乗ってきた 巨大な虫に対して女子高生が 「お前誰だよww 定期持ってんのかよ」 って言ってて吹いた。

■笑3
郵便局で並んでたら、前の女子高生が切手を買っており窓口の人に「糊でつければいいんですか?」と。 水で濡らしてください、との返答に 「は?!みず??水って!とれませんか?!」 ってなやりとりをしており。 早くしろ!!!!くだらん!!

■笑4
隣の女子高生が 「お母さんいない時はご飯にパイナップルジュースかけて食べるねん」って言った瞬間、その話聞いてた女子高生と俺の表情が凍った。

■笑5
店のオレンジジュースと氷がなくなったからドンキでオレンジジュース10本と氷6.6㎏買ってたら、後ろの女子高生が「オレンジジュース屋さんかな??」とか会話してたんだけど、汗だくのハゲがオレンジジュース屋さんなんてやって売れるとでも思ってんのかよ。

■笑6
11人の女子高校生集団のおしゃべり A:お父さん,出張中は食事はずっとテンヤモンばっかりで嫌やったというてた。 B:‥‥?‥‥テンヤモンって何? A:‥‥さあ?‥‥全然知らんけど,添加物一杯ってことちゃうかな? C:うわぁ‥‥体に悪そう! 誰も「店屋物」を知らん世代らしい。

■笑7
コンビニにコーヒー買いに行ったらすごい可愛い女子高生店員がバイトしてたんだけれども、少し言葉が訛ってて「ありがとナス!(ありがとうございます)」と言われて動揺が走った

■笑8
女子高生「もしもし?リカだよね?」 私「違います〇〇です」 女子高生「えー...何で?これリカの番号なんだけど」 私「もう5年以上ずっと私はこの番号なんですが」 女子高生「リカじゃない...んですか?リカ知らないですか?」 私「知りません。知り合いにもいません」

■笑9
さっき女子高校生がご飯食べに来たんだけど シーザーサラダ食べてて、 「まじゲロみたいな匂いなんですけど?」って言ってて 飲食店従業員として、手が出そうになりました。

■笑10
電車の中で女子高生達が 「ひげのはえてる人って不潔よね!!」 「ねっ!!なんか、ひげでカタツムリ飼ってそうだよねキャハハハ!!」 飼ってねーよ!!

私も時々ヒゲを蓄えますが、カタツムリは生息不可能です。(笑)

20151124-1


20151124-2

 昔は独自のシステムを開発することが当たり前で、独自性を売りにして業務にも活かしていました。最近では独自のシステムを開発するのではなくパッケージを導入してパッケージに自社の運用を合わせていく考え方が多くなりました。これには2つの要因が考えられます。

型抜き


 ひとつは費用です。独自システムを開発依頼すると時間も費用も掛かります。パッケージ導入の数倍というのが一般的でしょう。景気が伸び悩む日本経済においてシステム開発に巨額な投資をするような余裕はない。ということだと思います。

 もうひとつは人材不足。独自のシステムを維持、保守していける人材が居ないのだと思います。「いやいやそんなことはない。昔は業務用のパッケージが無かったから作ったのであって最近はいろんな業務パッケージがあるから採用したいんだよ。」なんて声も聴こえてきますよね。「業務を考えたシステムが多いだろうから採用されているシステムに業務を合わせることで、うちの業務ももっと効率的になるんじゃないか」なんてことも聞いたりします。ではパッケージシステムを導入してシステムに業務運用って合わせられるものなのでしょうか?


 僕自身は【無理】なんだと思っています。これはシステム導入側の問題なのですが、業務運用を変える(改善する)のであればそれなりの人材教育と部署間の調整が必要になります。場合によっては外部取引先にも影響することかもしれません。それは現場担当者だけで進められるような簡単な話ではなく企業として取り組まなければならない事案なのです。システム導入します。パッケージで決定しました。じゃああとはシステム部でよろしく。なんていう会社は絶対に改善出来ません。システム部がそこまで運用に口を出せるわけもなく。現場からは「やりにくいから前と同じようにできるようにしろ」と言われて終わりです。現場だって今のやり方が良いとは思っていないかもしれません。でも一つやり方が変わると関連するものが中途半端になってしまい手間が増えてしまうのです。改善どころか負担増になるわけです。それを変えることでどこまで影響するのか。いま作業していることは前後にどのような部署への影響があるのか。パッケージ導入でそこまで考えているのでしょうか?パッケージシステムは業務表面上の機能は網羅しているかもしれません。でもバックヤードで作業する人が必要としている情報をすべて提供してくれるわけではありません。パッケージ導入している企業がみんな同じ運用ができるわけではないのです。


 いままで使っていた帳票が出ない。似通った帳票はあるけどいままでと同じものが必要。と現場からは必ず言われます。ではなぜその帳票が必要なのでしょうか?だれがそれを必要としているのでしょうか?「いままで出してるから」「それを保管してるから」そんな理由で帳票が必要と言っていませんか?システム導入を考える前に、いまある情報はだれが必要としているものなのか。なぜ必要なのか。その帳票のどの情報が必要なのか?を社内で整理してからシステム導入を考えるべきだと思います。「このシステムは使えない」と言う前に自分たちの必要としているものが何かを明確にすることで実は運用も変えることができるのです。

クッキー


 システム導入で運用変えるなんて考えないで下さい。運用を変えるためにシステム導入なんて考えないで下さい。まず自分たちが本当に必要としているものが何か?を理解し、なぜ現場がそれを必要としているのかを真摯に聴くことから始めて下さい。継続した業務は悪癖を増やすことが多いです。常に明日を考え自分たちの業務を見直すことをお薦めします。

24時間営業の飲食店。
漫画が沢山置いてあります。
日本の飲食店のマナーとして、「読んだら戻す」と
いうのは、常識と思っていました。

20151110-1


このメッセージ、どう感じられますか?
私は同じ老眼として共感してしまいました。(笑)
苦肉の策なんでしょうが、若い人が一人もいないんでしょう。
これからの日本を象徴している様です。

20151110-2


このメッセージ。
「分かりにくい。」

要するに単行本の間が抜けると後から読む人が困ると言いたいのでしょう。

いずれにしても、盗む奴は悪い。

 システム開発の契約は議論の尽きないところです。日本ではまだウォーターフォール型を軸とした契約が主流となっています。最近の開発スタイルはアジャイル開発にシフトしつつもどうしても契約締結が難しくユーザー企業に受け入れられていないのが実状です。契約書では機能範囲と納期、金額の3つを明確に示すことが必要ですが、アジャイル開発ではこれらがはっきり決まらないことが多いというか、進めながら決めていくスタイルなので事前に契約書に示すことが出来ないのです。ハイブリットという表現でウォーターフォール型とアジャイル型を組み合わせた形式で契約を締結する案件が増えてきていると聞きますが、まだまだウォーターフォール型で進むのでしょう。

niagara-218591_1920


 ウォーターフォール型が悪いのか?と言われると決してそうではないのです。至極当然のススメ方であるのは間違いありません。ではなぜ議論され続けるのか?それはシステム開発に対する考え方が大きく変わってきたからです。システム開発に求められるものは「何を構築するのか」「何を作るのか」です。顧客要件でありRFPなどで提示される内容です。これがなければ何も進みません。RFPを具体的にする作業工程が要件定義なのですが、ここに問題が多くあります。要件定義工程は一般的に準委任といって作業時間を成果として支払をする契約をとります。ひとつひとつユーザーの要件を具体的にして機能に落とし込み、パッケージ製品であればカスタマイズ範囲も具体的にする工程となります。工程として問題はないように思えます。では何が問題なのでしょう。
定義した内容が正しく相互に伝わらないことが問題のひとつです。


 ユーザーは自分たちの業務から話をします。業務システムであれば当たり前のアプローチです。システムベンダーは自分たちのシステムが持っている機能から話をします。同じキーワードが飛び交っているとお互いに「同じこと」を話している気になっていますが、その本質は異なることが多いのです。システムベンダーは「機能の代用と運用の改善」を求めますが、ユーザーは自分たちの運用にシステムを合わせたがります。要件定義で合意したつもりでも出来てきたものは「言ったことと異なる」ものになっているのです。結局作るのはシステムベンダーであって、ユーザーではありません。要件定義はシステムベンダーの都合の良い理解の上に成り立っているものが多いのです。


 もうひとつ問題があります。それは時間です。
たしかにその当時はその要件に対してその実現方法で良かった。でもあれから何ヶ月が経過したのかもしかしたら年単位で経過していることも有ります。もうその要件の根本が変わっているなんてことも多いでしょう。でもそれを変更すると「仕様変更」になってしまい他の機能との整合性が取れない場合もあるためそのまま突き進むしか無いもしくは、出来てきても使えない代物になっているのです。機能、運用に対する理解は一致していいてもそれを実現しなければいけない「時間」が置き去りになっていることが多いことで発生する問題です。ウォーターフォール型での問題はシステム開発に時間がかかるほどに問題となってしまう契約形態なのです。
どうやったら改善できるのでしょうか?

時計/ドライブ


 一部で取り入れられ始めたのが顧問エンジニアの採用です。これは医療などで言われるセカンドオピニオンと同じで第三者の意見を入れることで改善を促すのです。顧問エンジニアはユーザーの立場で要件定義などの打合せに参加をします。そのときにユーザー課題の本質とシステムベンダーからの回答の本質を噛み砕くことが仕事になります。とくにシステムベンダーの説明内容をユーザーが理解できるようにしてあげること。その内容で何か問題が考えられることを意見する。そういった立場になって意見することで契約上問題となる「機能」「時間」「費用」を整理するとプロジェクトが大炎上することなく進めることが可能になっていきます。もともとはPMOと言われる立場の人がこれを行うべきなのですが、ほとんど機能していません。それはユーザーへの理解が薄いからです。PMOはシステムベンダーがプロジェクトを遂行するための立場になっています。プロジェクトの内容云々ではなくシステムベンダーとしてプロジェクトの納期を守ることが最優先なのです。そんな人材にコストをかけるプロジェクト自体いかがなものかと思います。


 顧問エンジニアはユーザー企業内での理解が必要です。即日で用意できるほど簡単な立場ではありません。最初は何も知らない人材からユーザー企業の状況、課題、部署間の問題、向かっていく方向性などを理解していただくことからはじめなければなりません。またユーザーが求めるシステム情報の提供も必要でしょう。これはこれで費用も時間も掛かります。でもシステムが不要な業務遂行が考えられないのであれば、一日も早くこういった考え方を取り入れるべきではないかと思います。IT業界が人材不足である今日でユーザー企業におけるシステム部門の人材確保及びシステム部門としての存続も難しい状況です。社内人材を育てることを社内だけで考えるのではなく、顧問エンジニアとともに相互に育て上げていくことが望ましいのではないでしょうか。継続できるチカラを得ることが重要だと私は思います。

お金がある人には目いっぱい融資します。
担保がある人には担保価値の限度額まで融資します。
その他の人にお金は貸しません。

20151027-1


最近、ある金融機関が融資を持ちかけてきました。

その時に頭をよぎったのが冒頭の3行です。(笑)

「下町ロケット」というドラマ。

銀行と中小企業の関係を如実に表現している。
爆笑しながら観ています。

経営者の方は絶対観るべし!

20151027-2

このページのトップヘ