会社員とIC(インディペンデント・コントラクター)の間

本日はIC協会の月例セミナーがあり、参加してきました。テーマは「どうつくる『好きを究める協働型組織』」ということで、プリンシプル・コンサルティング・グループ株式会社 代表取締役の秋山進氏がご講演をされました。秋山さんは知る人ぞ知るIC協会の初代理事長で、現在もIC協会の顧問をされています。久々の秋山さんの登場とあって、参加者もいつもより多めでした。

雑談レベルでは「秋山さんは、自らICではなくなった」というような批判めいたご意見を耳にすることもあり遺憾に思っていたのですが、今日のお話を伺って「全然そんなことは無い。むしろ秋山さんはやっぱりICだ」という確信を抱きました。

とはいうものの、今日のテーマはICというよりは、ICが「第3の働き方」だとすると「第4の働き方」とでも言いましょうか。ICというのは自立していてオールマイティに何でも自分で出来ちゃう人というイメージがありますが、そうではなくてやらせればすごく出来るんだけれどオールマイティではない、良い意味でオタクっぽい人にフォーカスしていました。事実、秋山さんは現在そういう方々を個人事業主あるいは法人としての契約を結びながら束ねておられます。これはIC協会を立ち上げたとき以上にチャレンジングなことだと思うのですが、使命を持って活動をされています。

独立というのは元々コンサルティングとか営業とかをされていた方にとっては何も難しいことは無いのですが、技術職や専門職でやってこられた方にとっては営業や集客といった面で壁にぶつかることが多く、私もどちらかというと後者なので今日のお話には膝を打ちました。実は私も常々こういった個人事業主や一人会社の方々と協業できたらどんなに良い事かと思い巡らしていたからです。

本当の意味で独立独歩なICにとってはIC協会という組織も不要で、でも私みたいに出来ることに偏りのあるICにとっては、IC協会という組織にサポートしてもらいたいという気持ちは少なからずあるだろうと思います。もちろん中には「ICとはこうあるべき」という高い基準をお持ちのICもいらっしゃいます。ですがそれは少なくとも秋山さんが想定しているIC像ではない。もっと気楽にゆるくやれるICのスタイルを垣間見た気がしました。具体的なことについては追々書きます。

まだ消化し切れていませんが、このことについては考えを深めていきたいと思います。


混雑時でもレジで待たされないパン屋さん

本日12日付け日経新聞の首都圏経済面に面白い記事がありましたのでご紹介します。DONQというパン屋さんのチェーンがありますが、明日、西国分寺にオープンする店舗で新しい会計システムを導入するということのようです。

その新しい会計システムというのは、画像認識の技術を応用してパンを載せたトレーをカメラで撮影し、その画像を基に商品を特定して合計金額を表示するというものだそうです。

この記事を読んで「なるほど」と思いました。週に1回くらいは近所のパン屋さんを利用するのですが、いつも感心するのはどの店員さんもパンを見ただけで商品名を暗唱しながらレジを打っていく事です。店によっては種類も豊富で、よく間違えずにレジ打ちが出来るものだと思います。おそらく新人のアルバイトはまず商品の名前と単価を覚えるところから始めるのでしょうね。

ただ、いくら店員さんの処理能力が高いといっても、混雑時にはやはりレジに並んで待たされますよね。今回の会計システムは、混雑時でも待たされること無く会計が出来る画期的なものです。課題があるとすれば、パンは全く同じ形ということはありえませんので、ある程度の割合で誤認識が発生するのではないかということです。この辺をどうやって補正し、あるいはシステムにパターンを学習させていくかが運用していく上での鍵となるのではないでしょうか。期待したいです。


組織として成果を出せるようになるためには?

7日にJSDG(日本システムアドミニストレータ連絡会)の第36回東京ミニ研修会が開催され、参加してきました。私自身は半年振りの参加です。発表者はY2研究所の吉田裕美子さん。タイトルは「どう違うの? 外資系企業の情シス・シスアドの仕事」、テーマは「日・米『良いとこ取り』で考える、シスアドのためのリーダーシップとチーム力」という内容でご講演を頂きました。

リーダーシップについての話は別のエントリに書くことにしますが、日本において典型的な外資系企業、特にアメリカ企業の日本法人のイメージというとどんな感じでしょうか。外資系企業で働いた経験のある知人によると、社員ごとに役割分担が明確で、自分の仕事だと認識していないことについては協力せず、社員同士が足の引っ張り合いをし、また、社員の入れ代わりが激しく、多くの人が腰掛けのつもりでいて、給料は高いが帰属意識は低いのだそうです。

吉田さんの話ではこれらに加えて、明確なJob descriptionがあり、成果にコミットする仕事のやり方をし、人選はトップがコストパフォーマンスを考えて行うのだそうです。この考え方の根底には一人ひとりが高い成果を出せば、組織全体の成果が高くなるという発想があります。しかし、それがうまくいくこともあるでしょうが、たとえそうだとしてもそれは長続きしません。一方で、日本企業の良いところを取り入れた外資系企業もあり、そこでは社員同士が協力し合ってチームとして成果を出すため、人が辞めていかないのだそうです。こちらの考え方の背景には、個人ではなくチームとして成果を出すということを意識している点。そのために銘々の強みを組み合わせるようなチーム作りが行われているとのことです。

面白いと思ったのはこれだけ明確に両極端の会社がある一方で、どちらともつかない会社があるということ。これは成果主義を取り入れている会社に多いのではないかと思いますが、人事制度には業種によって向き不向きがあるようで、多業種に事業を展開していながら画一的な制度を敷いている会社はそういった制度疲労を起こすケースがあるのではないかと感じました。

じゃあ結局どちらのタイプがいいのさ、という話ですが、これは人それぞれ好き嫌いもあるので一概にどちらが優れているということではないのですね。自分がどちらのタイプの組織で働きたいかという問いを自分に対して発してみましょう。そして、後者のタイプの組織がうまく機能するための秘訣が「リーダーシップ」なのだと理解しました。


エキスパートではなく、プロフェッショナルに

本日はIC協会のセミナーがあり、久しぶりに参加してきました。今回の講演はIC協会理事長の田代さん。テーマは「私のIC論~収益安定化の道のりを振り返り、今後を展望する~」でした。私は田代さんのお話を何度か聴いていますので、そういった意味ではサプライズなお話はなかったのですが、大儲けしているわけでもなければ苦しくもない、そんな安定したICライフを送っておられるその秘密を改めて総括してくださいました。田代さんの考え方で共感しているのはエキスパートではなくプロフェッショナルたれということ。その中で今日学んだことは、エキスパートだと顧客は必ずしも満足しないということでした。少なくともどんな球でも打ち返せる守備範囲の広さは必要ですね。

ICという働き方と安定収入というのは業種・職種によってはなかなか両立の難しいテーマでもあります。ICとして働いたからと言って全てが田代さんのように実践できるわけではありません。こういったセミナーでタメになるお話を伺っても、ではそれをいかに自分に適用するかということは、誰にお願いするでもなく自分で取り組んでいかなければいけない問題であるのです。

今日のセミナーの参加者のある方から、よくICとしてやっていけますねといった言葉をかけられました。なるほど、私が田代さんや諸先輩方の働きぶりを見て一種の憧れや驚きをもって見ているように、ICでない方からすると少なくともICとして数年の実績を持っている人に対しては同じように賞賛というか驚嘆の思いで見ておられるのかもしれません。

いずれにせよ、今回のセミナーを終えて感じたことは、やはり多忙な折にも人と交流する時間を作ることは必要だなということ。そういった何気ないことの積み重ねがICとしての活動を支えることにつながるのだなということです。私自身も調子に波があるので、いつもいつも外に向けて活動できるわけではありません。時には内にこもって思索と自問を重ねる時間も必要です。ましてそういった時間すら取れない日々が続いた後は特にそう感じます。ですので無理せず自分のペースで、ただし危機感を持って過ごして参りたいと思います。


変更を想定しないシステムはダメなのか

こんにちは。今日は久しぶりに新聞記事を採り上げます。日経新聞の企業面(10面)に今日から「消費増税の焦点」という連載が始まりました。

「消費増税」という表現には違和感を覚えますが、これは2014年4月と2015年10月に予定されている消費税率の引き上げの事を指しているようです。(といっても巷ではほとんどこの言い回ししかされていないようですが)

コンピュータシステムの中でも勘定系や決済系のシステムでは諸税法の改正などにより日々のメンテナンスを余儀なくされます。基準日や割合(率)、基準値の境界などの定数を書き換えなければなりません。ただ変えれば良いのではなく、新しい率がいつから適用されるのか、またどの範囲に適用されるのかといったことを緻密に管理していかなければなりません。

今日の新聞記事で採り上げられていたのは東日本旅客鉄道のIC乗車券といえばお馴染みの Suica です。記事によると Suica のシステムは、サービスインの期日を優先するため消費税率の変更機能の作り込みを見送ったそうです。おそらく見送った機能はそれだけではないと思いますが、それでも、今度の税率引き上げ期日までに消費税率変更機能を実装するには1年以上の期間と数十億円の費用を見積もっているとのこと。

記事はここまでの状況を淡々と伝えるにとどまり、このことについてどう評価すべきかについては何も書かれていません。これは非常にげんなりする状況です。だからといって設計者や当システムのオーナーを簡単に責めるべきではないと思います。サービスインの期日を優先するということはビジネス戦略上の判断だったと思います。2000年問題の時もそうでした。多くのシステムでは将来の改修費用よりも現在のストレージ費用の節約を選びました。しかしその一方で、必ずやって来る2000年を想定して最初から年を4桁で格納するように設計されたシステムも存在していたのです。

最初からあらゆる変更に対応できるように、あるいはあらゆる業務に対応できるように汎用的なシステムを望むユーザーは多いです。しかしそのためにはシステムの設計からテストまで費用も時間もかかってしまうし、汎用的であるということは裏を返すと「どの局面においても使い勝手がイマイチ」となるリスクもあるのです。重要なことはあらゆる変更や変化を想定した上で、どこで折り合いをつけるかというトレードオフであるということ。そして判断には少なからず責任が伴うということではないでしょうか。


「パーフェクトソフトウェア」ジェラルド・M・ワインバーグ著

皆さんはシステム障害のニュースを耳にしたとき、どのように思われるでしょうか。私はこれまで何度もソフトウェアのテストを行ってきましたが、それでもシステム障害のニュースを聞くとつい「本当にテストしたの?」と思ってしまいます。これは本書の前文に紹介されているエピソードと丁度重なります。そしてその反応は「テストをすれば完璧な製品ができる」という誤解からくるのだと指摘されています。実際、全くテストをせずにリリースされるソフトウェアというのは存在しないでしょう。しかし、テストの結果を正しく使えていないソフトウェアというのはそこそこあるかも知れません。本書はそんなソフトウェアのテストについての誤解を解き、ソフトウェアのテストについて様々な示唆を与える著作です。

本書に何度か出てくるテクニックとして、バグの分類が挙げられます。実際の開発現場ではバグ(障害)をどのように分類するかということがしばしば議論になります。(もっとも何も議論せずに決められているパターンも残念ながら多いです)よくある分類は重要度や優先度でしょう。ところが重要度や優先度はどちらかというと主観的な基準であるため、誰かが統一的な判定を下すのでなければ基準が曖昧になり、せっかくの分類が機能しなくなってしまいます。そこで弊社では本書で薦められているバグレベルによる分類を次のようにアレンジして現場に適用しています。

  • レベル0 ・・・他テストを妨害
  • レベル1 ・・・業務遂行不可
  • レベル2 ・・・作業効率低下
  • レベル3 ・・・頻発すれば問題

この分類のメリットは基準がどちらかというと客観的だということです。それでも最初は迷うこともありますが、それぞれどういうケースかということを考えていけば自ずと分類は決まってきます。例えばログのメッセージが不適切というケースでは、障害時の原因究明に余計な時間がかかってしまうということで「作業効率低下」に分類できます。例えばサイズ0のファイルをDBに登録できてしまうというケースでは、通常の操作ではサイズ0のファイルを扱うことがないと考えれば「頻発すれば問題」に分類できます。このバグレベルのおかげで分類作業の効率が上がりました。これは一種の優先度による分類ですが、紛れもなくレベル0のバグは優先して対応すべきものです。極端な話、レベル3のバグであれば状況により対応を見送るという判断もあるでしょう。

本書でも紹介されているように、ソフトウェアの開発に理解がない(あるいは理解があると自認している)管理者や営業担当者が、開発者に対してバグゼロを要求するケースを何度も見てきました。しかし、何がバグであるかが自明なケースもあれば、ビジネス環境に応じてバグの基準は変化することもあり、仮にリリース時点でバグがゼロであったとしても(それもあり得ないのですが)それを将来に亘って保障することはできないのです。本書はテストを担当する技術者のみならず、開発チームに関わる管理者や営業担当者の方にも読んでいただきたい一冊です。

――――
書名:パーフェクトソフトウェア
副題:テストにまつわる幻想
著者:ジェラルド・M・ワインバーグ
発行:日経BP社/2010年5月31日
ISBN:978-4-8222-8429-9

社員を雇うべきか、雇わざるべきか?

昨日24日はIC協会の月例セミナーがあり、久しぶりに参加してきました。テーマは「ICから『社員を雇う』タイミングとは?そして、その陥りがちな落とし穴」というものでしたが、今回は少人数だったので全般を通して参加者同士の活発な意見交換ができました。去年「案件確保と料金設定」というテーマについての講演がありましたが、その続編という位置づけだとのことです。

初めにアイスブレイクとして参加者全員がそれぞれ「どんな話を聴きたいか」という点について順番に発言しました。参加者の中には社員の雇用を検討したことのある方だけでなく、過去に実際に社員を雇用されていた方もおり、序盤から生々しい話になりました。ですので、アイスブレイクを終えたばかりの段階で「もう結論は出てるよね」といった雰囲気になりました。

私は法人化してから「会社を大きくしないのか」とか「社員を雇わないのか」といった質問をされることが増えてきました。やはり「会社経営」という言葉の持つイメージがそういったものなのでしょう。ただ、何も考えずに社員を雇うというのはあまりにもリスキーで、社員を雇うべきかどうかというのはきちんと考えておきたいものです。また、一人で捌ける仕事量には限りがありますので、例えば多少大きな案件に取り組みたいと思った時、社員を雇った方がいいのか、協業という形態でチームを組んだ方がいいのかは悩むところです。そんな背景もあって私は参加しました。

講演者の実体験、また参加者の実体験を聴いている中で、社員を雇うことのメリット及びデメリットの比較があったのですが、どう見てもデメリットの方が大きい。少なくともデメリットの穴を埋めるほどのメリットはなさそうに思えました。別にIC協会のセミナーだからそういう結論になったのでは必ずしも無いと思いますが、クロージングでの参加者の感想を聴く限りでは皆さん同様の思いだったようです。少なくともICとして活動している人は一人で好きなように仕事をしたいからICになったというケースが多いはずなので、社員を雇って別の制約に縛られるくらいなら一人のままでいた方が良いというのは自然な思いではないでしょうか。

仮に社員を雇うとしても、今一人でやっている仕事を拡大していくということではなく、全く別の新しい事業を立ち上げて、初めから従業員を雇うという前提でビジネスを構築していく時ではないのかなと思いました。もちろん、そんな時が来るのかどうかは定かではありません。しかし、そのような心の割り切りができたことは大変有意義でした。

東日本大震災から一年、改めてBCPを考える

今日はJSDGの東京ミニ研修会が開催され、参加してきました。今回のテーマはBCPです。東日本大震災から早一年が経ちまして、当時を振り返ると直接的な被害だけではなく、交通や物流の問題、在庫や仕入の問題、電力供給の問題等ビジネス環境に様々な影響をもたらしました。そこで急に注目を浴びたキーワードがBCP(事業継続計画)です。

今回は発表が2つありました。1つ目はBCMS(事業継続マネジメントシステム)についての発表でした。特に複数の拠点を持つ企業の場合、個々の拠点でBCPを策定していたりすると、それはそれで良いのですが、会社全体としては足並みが揃わないということがあり得ます。そこで、BCMSを規格化する動きが出てきているという要旨でした。ちなみにBCPとBCMの関係ですが、BCPは計画、BCMは運用でして、運用のための仕組みがBCMSということになります。ですのでBCPはBCMSにおいて用いられるものということです。災害対策、防災訓練は重要ですが、それ以上にマネジメントが重要なのですね。

尚、ここでいう規格というのは国際標準規格(ISO)のことで、ISO22301という規格がおそらく今年中には正式に発行されるのではないかということです。また、上位に当たるリスクマネジメントの国際規格としてISO31000というものも紹介されました。

2つ目は、東日本大震災発生時に実際にシステムダウンを体験された方の発表でした。震災を機に社内システムをクラウド化する動きも加速しました。しかし、クラウドサービスというのは原則としてどこにサーバが在るかは知らされていません。(中には国内にサーバが在りますと謳っているものもありますが。)特に海外にサーバが在る場合には、サーバが在る国の法律の制約を受けるという説明がありましたが、正直なところ私は余り意識していませんでした。問題になる頻度としては低いけれども影響を想定しておく必要はありそうです。最終的にクラウドサービスを選定し、社内サーバをクラウドに移行するに当たり、震災後検討に3箇月、準備と移行に1箇月かかったそうです。

その後休憩をはさんで意見交換・情報交換が行われました。普段聞くことができない事例をたくさん聞くことができ、大変有意義な研修会となりました。ここには全てを記載しきれませんが、一部ご紹介します。

  • やらなきゃいけないことは分かっている。では、本当にどこまでコストをかけられるのか。最後は経営判断でしかないが、その判断材料は充分に集める必要がある。
  • どこまでリカバリーを想定するかを判断し、その範囲を超える場合の覚悟を決めておかなければいけない。
  • BIA(ビジネスインパクト分析)は通常は起こりえないけど、起こったら大変なこと困ることは何かを考えることから始める。
  • 災害に限らず、原因はどうであれ何らかの理由で事業の一部が行えなくなった時に代わりにどうやるかを考えることが重要。原因型のBCPではなく機能停止型のBCPでないといけない。
  • 東京では地震の時のBCPよりもインフルエンザの時のBCP(社員の大半が出勤できない時の対応)の方が役に立ったそうだ。

作業に詰まったときの処方箋

仕事に取り組んでいると何かに詰まって作業が止まってしまうことがあります。私自身も時々そうなってしまうことがありますし、一緒に動いているメンバーがそうなってしまったことに遭遇したこともあります。

しかし、何かに詰まってしまった時、視野が狭くなって全く何も見えなくなってしまう人がいる一方で、そのような時でも自分を客観的に見ることの出来る人がいます。もちろん後者の方が建て直しが早く、まるで全てが順調に見えることすらあります。

作業に詰まるレベルにはどのようなものがあるか予め洗い出しておくことで、そういう状況に陥った時に気付きやすくなるのではないかと思い、やってみることにします。上から詰まり度合いが高い状態です。

  • 何をすれば良いか分からない。(取っ掛かり)
  • それは分かるが、どうすれば良いか分からない。(方法論)
  • やり方も分かるが、作業中に問題が発生した。(制約)
    • それは未知の問題である。
    • それは既知の問題である。
  • 問題はないが手際が悪い。(不慣れ、習熟度)
  • スムーズだが分量が多い。(捗っているように見えないだけ)
  • 時間が取れない。
  • モチベーションが低い。

他にもあるでしょうし、もちろん人によっても観点や粒度は異なるでしょう。一度こうやって整理しておくと、何で詰まっているのかが見えやすくなります。何で詰まっているのかが分かれば対処もしやすくなるのではないでしょうか。

雇われないシスアド

昨日はJSDGの研修会が金沢であり、発表者の一人として参加してきました。金沢での研修会は5年ぶりで、とても楽しみにしていました。先月の後半から全国的に寒くなってきましたが、日本海側は特に雪が積もっていました。私は上越新幹線と特急はくたか号を使って行きました。途中の越後湯沢付近はとても雪深く、その景色は圧巻でした。それでも新潟や富山に比べたら金沢は雪が少ないようで、駅から会場までの道中、そして研修中も吹雪く時間帯もありましたが、それ以降は晴れることはないものの天気が崩れることもなく、大変楽しい研修旅行となりました。

さて、研修会では私の他に2名の方が発表されました。トップバッターは私が担当させていただきまして、2人目は北陸電力で水力発電のダムを担当されている方の事例発表、3人目は会社の辞令(?)でスマートハウス(スマハ)についてレポートするため1か月間青森で生活された方の事例発表でした。具体的な内容は事情がありここには書けないことになっていますので割愛いたします。

一方、私は「インディペンデント・コントラクター」についてお話しさせていただきました。私はシスアドの会(JSDG)とICの会(IC協会)の両方に所属していて、実はシスアドとICってぶつからないよなぁと予てから思っていたのです。だったらJSDGのメンバーにICについて知ってもらったらいいのではないか、と考え今回のテーマを決めました。最初はICとは何かという話から始め、ICの持っている特性を紹介して、JSDGの皆さんはそのような特性をお持ちですよね、という風につなぎました。このテーマについては追々このブログでも触れていけたらと思います。

この話に端を発して幾人か共感のコメントや質問をしてくださいました。今回参加されたメンバーも仕事における立場やスタイルは様々ですので、もしかしたらピンと来ない方もいらしたかもしれません。ですが、まずは存在を知ってもらうことから始めて、そのうち「自分もICになってみようかな」と思う人が一人でも出てくれば嬉しい限りです。とはいえICに成ることが全てではありませんし、人によって向き不向きがあるのは事実です。でもそういった自分の性格を見極められるのもシスアドの素養の一つではないかなと思っています。


NPO法人インディペンデント・コントラクター協会
http://www.npo-ic.org/

プリンシプル・コンサルティング株式会社(IC協会初代理事長・秋山進さんの会社)
http://www.principleconsulting.co.jp/

株式会社田代コンサルティング(IC協会現理事長・田代英治さんの会社)
http://www.tashiro-sr.com/