ミニ・コンサルティングの「ITかかりつけ医」サービス開始!

先日の「情報システム・ドック」に続く新サービスとして「ITかかりつけ医」を開始しました。

http://www.crossidea.co.jp/services/doctor.html

社内にシステムに詳しい人がいない場合、この見積は高いんじゃないかとか、ベンダの言いなりになっているんじゃないかとか、様々な疑問を持ちながらも適切な判断が出来ないということがあります。また、ベンダにRFPを出したいんだけど内容として不備が無いかとか、ベンダから出された仕様書の内容に抜けや漏れが無いかとか心配になるものです。かといってシステムに詳しい人を専任で雇うほどの仕事も余裕もないというのが現実ではないでしょうか。そんな時、ITのプロとしてITに関する様々なご相談に乗ります。

「かかりつけ医」を和英辞典で引くと primary care doctor と出ています。何か調子が悪いかなと思ったらまず診てもらう町医者です。もしそこで処置が出来なければ他の専門医や大病院を紹介するように、当社では担えないご相談についてはより高度な専門家・専門業者をご紹介いたします。また、他の専門家や専門業者の提案に対するセカンドオピニオン(第三者による参考意見)を提供しておりますので、判断に迷う時など気軽にいつでも相談できる町医者のような感覚でご利用いただけるサービスです。

このサービスは元々「ITリベンジ」のサービスプランの一つとして用意していたものを、いわゆるスピンオフによって独立したサービスとして切り離したものです。一口にコンサルティングと言っても様々で、特にこういったことで困っている中小企業が多いのではないかと考えました。

尚、情報システム・ドックは無料のサービスですが、ITかかりつけ医は有料のサービスでサービスプランをいくつか用意しております。標準料金も設定してありますが、状況やご要望に応じてカスタマイズ可能です。お気軽にお声掛けください。

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


株式会社クロスイデア ITかかりつけ医サービスのご案内

他人のモチベーションをどう高め、維持するか?

日付が変わりましたが、昨日7日はJSDGの東京ミニ研修会が開催され、参加してきました。東京ミニ研修会というのはJSDGの東京のメンバーを中心に会員と会員の紹介の方向けの短時間の研修会で、年に4回の開催が計画されています。

今回の講師は会員の満川さん。ご本人は経産省の情報処理技術者試験が大好きで受験回数が30年で50回を超えたのだとか!その情報処理技術者試験の受験を継続できているという事実を題材にして、モチベーションをいかに維持するかというテーマで成功体験や失敗体験を交えてお話しくださいました。

最後はグループ別に「部下に情報処理技術者試験を受けさせるためにはどうしたら良いか」という仮想のテーマ設定でディスカッションを行いました。私のいたグループでは随分と議論が発散してしまいましたが、最終的な講師のまとめとしては「対人」なのでモチベーションの高め方は人それぞれで、例えば褒めるにしてもどう褒められたらモチベーションが高まるかというのは個人差があるというわけです。

そういう意味では特効薬というか「これだけやれば」みたいなのは正直存在せず、一人一人個々別々に対応していかなければならないという地道で気の遠くなるような話でもあるわけです。でも、考えてみたら人を育てるというテーマがもしもっと単純なものであれば、ここまで世の中で育成ということがテーマになり得なかったはずなんですよね。そういったことに改めて気づかされた研修会でした。


拙作ソフトがVectorに登録されました!

「クロスラボラトリー」ブランドの実績第一弾として、Windowsの.NET framework上で動作するアプリケーションを作成し、フリーソフトとして公開していましたが、この度、日本で最大級のソフトウェアライブラリであるVectorでも公開を始めましたのでお知らせいたします。

クロスラボラトリーというのは弊社の前身である個人事業主時代の屋号です。ソフトウェアの会社を離れ個人事業主として独立して10年目となりますが、古くからお付き合いのある方にとってはお馴染みかもしれません。やはり過去の屋号とはいえ愛着があるもので、クロスイデアとしてはコンサルティングやIT人材の育成をメインに据えたということもあり、弊社の「研究開発部門」のブランドとしてクロスラボラトリーの名称を今後も使っていこうと考えたのです。

一方、Vectorは大学生時代から15年以上利用させていただいているサイトで、今でもお世話になっております。そこで出会ったソフトウェアは数知れませんが、今回その仲間に加えさせていただくことが出来て大変光栄に思っております。とは言ってもやっていることはそんなにすごいことではないのですが、個人的には感慨深いものがあります。大学の研究室であるミニゲームをVectorからダウンロードして息抜きに遊んでいたのですが、社会に出てからあるプロジェクトで一緒に仕事をしているメンバーがそのゲームの作者だった、ということもありました(笑)

今回登録されたアプリケーションは以下の5個です。ちょっとしたツールなので全ての方に使っていただけるようなものではありませんが、お使いになれる方は是非一度お試しください。


チームとグループの違いって??

最近書かれたネット記事か最近発売された書籍のテーマなのか分かりませんが、ここ最近「チームとグループの違い」についてのトピックを良く目にします。(ネットを検索すると真新しいテーマではないようですね。)

別にそのこと自体は良いのですが、言葉の違いというのを本来の単語の意味の違いを指しているのか、あるいは業界用語のようにビジネス上の意味付けの違いを指しているのかが気になっています。きっとそれは私が世の中を斜めに見ているせいかもしれません。そこで、一度辞書に立ち返ってその違いを整理してみたいと思いました。

ロングマンを引くとまず「team」はこう書かれています。

a group of people who have been chosen to work together to do a particular job.

ああ、なるほどと思いました。ざっくり意訳すると「ある作業を共同で行う目的で選ばれた人のgroup」となります。そして定義の中にgroupが出てきます。
一方の「group」はこうなっています。

several people or things that are all together in the same place.

あるいは

several people or things that are connected with each other.

つまり「同じ場所にいる人または物の集まり」あるいは「お互いに関係のある人または物の集まり」ということです。

こうやってみると確かにチームとグループは違いますね。ちょっとスッキリしました。


※ 引用部出典:the Longman Dictionary of Contemporary English Advanced Learner’s Dictionary

そういえば、良いルールって何だろう?

世の中にはルールと呼ばれるものがいっぱいあります。規則や規定なども含めるともっといっぱいありますよね。中には「何でこんなルールがあるんだ!」と叫びたくなるようのものもあると思います。では、良いルールってどんなルールなんでしょう?診断サービスの企画を練っていく過程でそんなことがふと頭をよぎりました。

ルールと言っても、社会一般におけるグローバルなルールから、学校や家庭内のローカルなルールまで様々ですが、ここでは主に会社など組織のルールについて考えてみたいと思います。組織のルールと言ってまず思いつくのが「就業規則」ですが、もっともっと身近な業務ルールや作業手順まで範囲を広げてみましょう。

私が様々な現場にお邪魔してよく聞かされる話として「ルールはあるけど守られていない」というものがあります。なぜ、ルールが守られないのでしょうか。あるいはなぜ、守られないルールが存在しているのでしょうか。表面的には様々な理由が考えられますが、一つ思いつく根本的な理由は「ルールが現実的でない」あるいは「合理的でない」というものです。

そこから出てくる言い分は、例えば「ルールを守りたいのはやまやまだが、いちいちルールを守っていたら作業効率が低下する」とか、「こんな不条理なルールには従う必要はない」とか、「守ったところでどうにかなるものではないし、今のやり方で問題ない」など、捉え方は人それぞれだろうと思いますが、こういうのを一括りにして従業員のモラルの問題として片付けてしまいがちではないでしょうか。

仮にそうだとしても、それで従業員のお尻を叩いたり、鼻先にニンジンをぶら下げたりしても効果が出るものではないでしょう。今の私の考えでは、良いルールというのは「守られるルール」、逆に悪いルールというのは「守られないルール」だと思っています。

確かに、組織を運営するに当たっては組織ごとに「あるべき姿」あるいは「あるべきルール」というものがあるでしょう。しかし、それを全てそのまま実際のルールとして運用しようとしてしまうと、組織の成熟度によっては理想と現実のギャップが大きすぎるということが起こり得ます。

一般的なマネジメントシステムにおいては、ルールというのは一回作って終わりというのではなく、状況の変化に応じて適宜見直していくものとされています。ですので、組織の成熟度に応じて守れる大きさのルールから始め、それが守れるようになったらルールを改定し、それを繰り返すことで「あるべき姿」に近づけるといった工夫が可能です。

「あるべきルール」という目標を大きく持つことは大切なことですが、そこへ一足飛びに到達することを考えるのではなく、「守れるルール」という中間目標を細かく設定し、達成状況をウォッチしながら徐々に前進していければ良いのではないでしょうか。


制約理論先進国の事例に圧倒!

日付は変わってしまいましたが、本日、西新宿でTOCfEの月例勉強会に参加してきました。いつものような事例発表もあったのですが、今日は特に、海外での事例を紹介してくださった方がいました。

例えば、ポーランドでは幼稚園でTOCfEの使い方を教えていて、例えば単純なブランチとしては、童話などの物語を読み聞かせて、物語の進行に合わせた挿絵をカードにしたものを物語の順番に並べさせるといったことをしているようです。そしてなんと驚いたことに、幼稚園の先生たちが簡単に教えられるように、TOCfEのツールを教えるためのキットが作られているということで、今日は実物も見せてもらいました。(残念ながら写真を撮り忘れたので、どこかで入手できたら後日掲載したいと思います。)

このキットはレジャーシートの素材にツールのフレームが描かれているもので、水や汚れに強く、多少乱暴にしても壊れにくく、持ち手がついているので持ち運びにも便利になっています。興味せていただいたのはブランチのシートとクラウドのシートでした。書かれている言葉はさすがにポーランド語なのだそうですが、間もなく英語版が発売されるとか。日本語版、作ろうかな…。というか、ある意味言葉を書かなければ、それだけで万国共通になると思うのですが。

さて、日本がTOCfEが上陸してまだ3年なのに対して、こういったTOCfEの先進国というのはもう20年近く取り組んでいるのだそうです。教育現場、特に幼児教育の現場には当たり前のように定着しているようです。日本ではまだそういった取り組みは盛んではありません。ということはまだまだこれから日本は良くなっていく可能性があるということなのかもしれませんね。


論理削除か物理削除か

久しぶりにITの話をしたいと思います。情報システムには多くの場合リレーショナルデータベース(RDB)を利用しています。たとえスマートフォンのアプリであっても内部で組込み用のRDBを使っていることがあります。

RDBではテーブルという単位でデータの鋳型を定義して、その鋳型で出来る実際のデータはレコードと呼んでいます。レコードが不要になった時、レコードを削除するとその情報は消えてしまいます。一方で「削除したよ」という情報を付与するだけでレコード自体を残すことがあります。この場合、俗に前者を物理削除、後者を論理削除と呼んでいます。実はこの両者が、DB設計において一つのテーマであります。

それぞれのメリットとデメリット

というのも、物理削除の場合、一旦消してしまうとバックアップデータから復元するしかありません。もしバックアップデータが無ければ復元する方法はなく、必要ならもう一度登録し直さなければなりません。

また、論理削除の場合、うっかり削除してしまっても簡単に復元することができますが、本当に不要になっても完全に削除することが出来ず、ゴミ(不要なデータのことを俗にこう呼びます)が残ります。その場合、別に物理削除を行う手段を設ける必要があります。

操作画面上で「削除」というボタンが有った場合に、物理削除の場合は確認ダイアログを表示して本当に削除して良いかしつこいくらいに尋ねる必要があります。しかし論理削除の場合は確認なしに削除してしまっても簡単に復元できるので、結果として操作画面の利便性は向上することになります。

つまり、たかがDB設計なのですが、論理削除か物理削除かというのは運用設計や画面設計とも密接に絡んでくる複雑な話なのです。

私はRDBを学び始めて間もない頃、あるいくつかの現場では全てのテーブルに削除フラグを設けているRDBを見たことがあります。その影響もあって私は全てのテーブルに削除フラグを設ける方針で他の現場でもDBを設計していました。事実、内部統制が緩い現場においてうっかりの操作ミスが多く、論理削除を採用していたことによって何度も助けられたことがあります。しかし一方で次のような課題もお客様から突き付けられました。

  • 間違えて登録したデータを完全に削除できないのは困る。
  • あるデータに関しては通常の運用で完全に削除したい。

論理削除か物理削除かを決めるもう一つの観点は、取り扱うデータが情報資産であるかどうかです。情報資産というのはデータの所有者が、それを保有することに価値を見出している情報という意味です。一定の役目を終えたからと言って完全に削除してしまうと、新たなデータの参考にすることすらできなくなります。その場合は論理削除が良いのではないかと思っています。

削除フラグと設計方針

そもそも「論理削除」の業務的(仕様的)な意味は何でしょうか。もし本当に論理的に削除したということ以上の意味が無ければそれでも良いかもしれませんが、本当にそうでしょうか。良く考えてみると実際には「一時的に非表示にした」「公開を終了した」「有効期限を過ぎた」「処理が終了した」「退会した」といった意味があるのではないでしょうか。そうすると、論理削除を表すには「削除フラグ」よりも「公開フラグ」や「表示フラグ」「処理済みフラグ」という呼称の項目を設けた方が良さそうですね。あるいはそれらを複合的に取り扱う「ステータス」という項目を設けてもいいかもしれません。

また別のアプローチとして有効期間の開始日時と終了日時、公開期間の開始日時と終了日時を管理するという方法もあります。この場合、クエリー(問合せ)は多少煩雑にはなりますが、緻密な管理が実現できます。

ステータス管理が必要なデータは適切な管理項目を設けてステータスを変更し、単純な間違いなどのゴミデータは物理削除できるようにする。そして、ステータス管理の必要のないデータはそのまま物理削除するというのが現実的な方針かなと思っています。いずれにせよ、条件反射のようになんでもかんでも削除フラグというのではなく、きちんとデータの特性を考えて設計する必要がありますね。

「人気店はバーゲンセールに頼らない」齊藤孝浩 著

本書はインディペンデント・コントラクター協会の理事のお一人である齊藤孝浩さんの著作です。齊藤さんはいわゆるアパレル業界のコンサルタントで、商品陳列や適正在庫といったカテゴリでご活躍をされている方です。個人的にはいつもIC協会のイベント等でお世話になっております。

本書は誰もが知っているような国内外のアパレルチェーンにおける成功事例を集めた本です。私はアパレル業界には疎いのですが、そんな人でも本書を読めばアパレル業界のトレンドに詳しくなり、明日からでもアパレルチェーンを展開できてしまうのではないかと錯覚してしまいそうになるほど具体的なノウハウが詰まっています。もしかしたら業界内では普通に知られていることばかりなのかもしれませんが、ブランド名を明示しているので外の人間からするとそんなことまでバラしちゃっていいの?と思ってしまいます。明日は用も無いのにZARAに行ってみたくなりました。(実はまだ行ったことありません。)

さて、私が本書を読んで感じたポイント。それは本文でも触れられていることなのですが、成功する秘訣は業務のサイクルの短さだということ。いわゆるPDCAを週単位で回せるというのは月単位、四半期単位、半期単位で回している企業にとっては脅威でしょう。また、本書では言及されていませんが、ここに挙げられた事例は制約理論(TOC)を実践した実例なのではないかと思われます。特に、エリヤフ・ゴールドラット博士晩年の著作である「ザ・クリスタルボール」。そのテーマはまさに小売業における適正在庫であって、そこに書かれていることを実践したとしか思えません。

本書は、今まさにアパレル業界で働いている人はもちろん、これからアパレル業界で働きたいと思っている人にとっては必読の書ですし、直接関係ないと思われる人でも本書にはビジネスにおけるヒントを多く得られると思います。また、特に女性の方に対しては、本書を読めばまた違ったショッピングの楽しみ方が出来るのではないかと思います。まずは是非手に取ってみてください。

あと、私の関心は本書の内容を逸脱して、成功した企業が行っているオペレーションが素晴らしいだけでなく、このようなオペレーションを可能にした組織がありますが、そのような組織を作り上げたその方法論を私は知りたいと思いました。また、成功に至る判断のためには迅速で的確なフィードバックが不可欠ですが、その背後にはそれを可能にした情報システムがあるはずです。それらがどのようなシステムなのか、どのような処理でどのようなアーキテクチャなのかということにも興味が及びました。そういったチームビルディング、システム設計といった側面を取り扱った姉妹編が出版されたら間違いなく買ってしまいますね。

――――
書名:人気店はバーゲンセールに頼らない
副題:勝ち組ファッション企業の新常識
著者:齊藤孝浩
発行:中央公論新社/2013年4月10日
ISBN:978-4-12-150451-7


ファッション流通ブログde業界関心事 (齊藤さんのブログ)


クラウド事例を発表させていただきました

4月8日(月)に西新宿でTOCfEの月例勉強会に参加いたしました。これは先月初めて参加させていただいた集いなのですが、その時はどんなことをやるのか知らないままに誘われ手ぶらで参加したところ、参加者の皆さんの事例発表があまりにも素晴らしく、私も自己完結した事例ではなく相手がいる状況で実践した事例を作りたいと思わされたのです。その日、家に帰って早速クラウドを試してみて、紆余曲折はあったものの丸く収まり、今回その成果を発表させていただきました。

私は基本的にグローバルオプティマム社の飛田さんに教わっただけですのでよく知らなかったのですが、クラウドにもいくつか流儀があるのだそうです。クラウドを描くときに「AであるためにはBである必要がある」と読み上げるのですが、それに加えて「なぜならば・・・」とその前提条件を続ける方法もあると。方法もあるというよりは、少なくとも意識はしていた方がうまく行きそうではありました。次はそのようにやってみたいと思います。

もう一つアドバイスを頂いたのはDとD’の書き方。今回私が試したのは最初は主語がはっきりしておらず、そのことに途中で気が付いて明記するようにしたというお話をさせていただきましたが、DとD’に限らずBとCも主語(誰の立場なのか)を明記した方が認識のずれが発生しないということでしたので、これも次回はそのようにやってみたいと思っています。

私以外に数人の方が発表されたのですが、TOCfEの全てのツール(クラウドとブランチとアンビシャス・ターゲット・ツリー)について万遍無く事例があり、私にとって大変濃度の高い勉強会となりました。特にブランチ。これは済んでしまったことですが、一度ブランチを描いて因果関係を分析したい題材があるので、時間を作ってチャレンジしたいと思います。

電子書籍の登場で自費出版が身近に

本日はIC協会の月例セミナーがあり、久しぶりに(今年初めて)参加してきました。講師はIC協会の会員でもある、有限会社ニコラデザイン・アンド・テクノロジーの水野操氏。「電子書籍で出版しよう!~『初心者Makersのための3Dプリンター&周辺ツール活用ガイド』を電子出版したワケ~」というテーマでお話しくださいました。

電子書籍はもう5年以上も前から存在していますが、ではそれを自分で出版しようと思ったことがあるでしょうか。ちょっと知っている人であれば難しそうだと思うかもしれません。実は私もそう思っていました。電子書籍といっても複数のフォーマットが存在しますし、とあるフォーマットについて言えばオーサリングツールと呼ばれるソフトウェアも高価で誰でも気軽にという環境ではないと思っていました。事実かつて私が見たものはそうでした。

ところが今日の水野さんの実体験を伺い、今では思っていたよりもかなり手軽に、気軽に電子出版ができる環境が整っているということが分かりました。一方で、内容が伴い、かつ一定のクオリティを保っていないといけないという極々当たり前の話に帰結します。つまり、これまでは出版というと企画を通すことだったり、費用の高さや出版までの日数という障壁になっていたものが、電子出版という新しいプラットフォームの登場によって取り去られ、本質の部分で勝負できる(或いは、せざるを得ない)状況になったと言えるのかもしれません。

もちろんだからといって内容が良ければ売れるかというのはまた別な話で、そういった周辺の話も伺うことができて大変有意義だったと思います。