定例会議が主体性を奪う

実は4月から方式チームのリーダーになってしまったんですね。実務経験は約半年足らず。技術力、専門知識ともにまだまだ素人レベルにもかかわらず。まぁ厄介な先輩の下で働き続けるよりは、自分もチームも健康になったかなとは思いますし、自分がコントロールできる裁量が大きくなって、仕事は進めやすくなったとは思います。

ただ、当然悪いこともたくさんあって。もっとも個人的に辛いのは現場経験が詰めないことですね。そもそも方式へ転換したのだって、AP開発では設計のサル真似程度で、プログラミングもできず、技術力がつかないと判断したからなんですけど、リーダーポジションになってしまうと、サーバいじったりする機会が減ってしまう。皮肉な言い方すれば、人使ってなんぼの仕事でしかありません。

上記にも関連しますが、打ち合わせや説明をする機会が増えましたね。進捗報告用の資料を作ったり、内部の定例会議を開いて全員の進捗や課題を刈り取ったり、ルールを策定したり、と。わかっちゃいましたが、これが割と負担です。多くの情報を得られるようになったのはメリットだと思いますが、如何せんそれを活用しきれていない気がします。会議の時間もさながら、それに向けた準備や説明の仕方を考えるのも結構稼働がかかるんです。だから自分のやりたい仕事があんまり捗らない。

というわけで最近は、「定例会議って本当にいるのか！？」と強く思うようになりました。定例会議ってなんとなくあった方がいいし、ないと困りそうなんだけれど、そういったなんとなーくの理由で開催されている文化がありますよね。で、新人の頃にそれが当たり前のものとして洗脳されるから、誰も疑問を持たない。なんなら、新しくプロジェクトを始めることになっても、まず定例会議をいつやるかから決めたりする。う〜ん。

しかも、定例会議自体にどんな価値があるのかを考えてみると、ビックリするほど価値がない。議事録には「報告資料の通り。」の羅列が並んでいるだけだし、資料の内容を深堀する程度の議論（というかただの勉強会？）の証跡がたまに残っているだけ。

ぶっちゃけ、定例会議をやるのって偉い人が怠慢なせいなんですよ。

どうせ会議用に報告資料を作っているわけだし、事前に課長なり部長が資料に目を通してくれればいいだけじゃないですか。沢山人が集まる必要もないし、知りたい情報だけを選択して確認することだってできる。絶対に会議を開くよりもかかる時間もコストも小さい。

「資料だけではわからない部分があるから対面の方がいい。」こんな答えが返ってくるかもしれませんね。いやいや。わからないとこがあるなら、何がわからないかを明確にした上で、質問すればいいじゃん。社会人2年目だってそのくらいできるでしょ。それを課長や部長がやらないのはなんで？コストの無駄？会議に集まる人数考えたら、年収に5〜10倍ぐらい差がないとその理屈は通らないと思います。

彼らの本音はこうなんです。

例えば、映画を見るのと小説を見るのとどっちが疲れますか？ってゆう話です。間違いなく読書の方がしんどいです。それはなぜか？能動的な行為だからです。目を動かして、思考を働かせて、ページをめくらなければ読み進めることができません。これに対し映画は受動的です。ただひたすらぼーっと時間とともに流れていく映像を見て音楽を聞くだけ。楽なんですね。他人の説明を聞くのも全く同じ。受動的でもある程度の内容は理解できるんです。

あるいは、進捗における課題について議論するのも定例会議の目的だ、という人もいるでしょう。でも、課題は課題で議論する場を設ければいいだけの話ですよね。しかも、事前に資料を読んだ上で、議論をした方がいい意見や解決策が出るとは思いませんか。

先にも述べた通り、定例会議の場でなされる議論は議論になっていないことが多く、その結果特に何かが生まれるわけではありません。せいぜい、誰かが安心したいがための再確認の宿題が増えるくらい。これも大体が無駄な作業です。

なぜ、そうなるかって、初見で得た情報に対していきなり議論をしようとするからです。また、立場上何か発言や指摘をしないといけない、という観念的なものから、的外れな議論（本来必要ではない議論）に発展するケースが多々あります。（なのに自分は議論ができていると考えている「議論をしている自分に酔っている」人が大企業には沢山います。）実際のところ、瞬時に価値あることを考え出せる人間はごく一握りの人だけです。

有意義な議論をするためにもまず、事前に資料を読み込んで内容を把握した上で、課題について検討会を開いた方が良いでしょう。各々が解決策の叩き台を考えた上で議論ができれば尚良し。ただ、この「議論する場を設ける」という行為も主体性・能動性が求められる行為なんですね。だから、ほとんどの人は率先してやりたがらないんですね。

と、こうやって利益よりも楽を優先した結果が定例会議なんですね。そして、ここでいっている楽というのは「主体性が求められない」ことを意味しています。単純な話、定例会議があると、誰を呼ぶか、いつやるかは既に定められていて、自分が目的に照らし合わせた上で考える必要がありません。こういう組織風土が社員の主体性を奪う要因にもなっているんじゃないでしょうか。

ただ、もちろんここには逆のリスクもあって。主体性がない人間で構成されているのに定例会議がないと、課題の対応が遅延したり、漏れたりするんですね。主体性が必要なのに、主体性を発揮しなければ問題がおきます。だから定例会議を開催した方がいい、と結論が導かれることが多いのも事実です。（私自身そう考えていた時もあります。）が、ただ一つ言えるのは、定例会議を開催するのは主体性がないことに対する最も簡単な暫定対処でしかない、ということです。

定例会議を無くす方法について考えていたのに、主体性の話になってしまいましたね。ただ、こんな風にメリット・デメリットを押さえておけば、別の解決策も模索できそうな気がします。

クラウドはエンジニアの在り方を変える

最近、少しクラウドについて勉強しています。いわゆる、Dropboxとかが流行り出した頃から「クラウド」という言葉が一般的に使われるようになった記憶がありますが、これえはただのオンラインストレージサービスに過ぎません。つまり、自分が作った資料とかを自分のハードディスクではなく、どこの誰が保有しているかわからないサーバ常に保存できる、ただそれだけの機能だったんですね。

近年使われるクラウドとはもっとずっと広い概念であり、正確にはクラウドコンピューティングと言ったりします。代表的な形態は大きく三つあり、守備範囲が広い方から順にSaaS、PaaS、IaaS。それぞれ、サース、パース、イアースと読む。

それぞれの特徴を説明する前に、そもそも一般的なITサービスを提供するために何が必要になるかを理解しておく必要があります。ただ細かく説明すると、本が一冊書けてしまうので、すごくシンプルに二つの構成要素だけ。ソフトウェアとハードウェア。以上。

例えば、今ではご老人でさえ使っているLINEというサービス。あれを利用するためには、まずLINEアプリをインストールする必要がありますよね。このアプリというのがLINEを動かすためのソフトウェアのことだと思って貰えればいいです。じゃあアプリをどこにインストールするのか。スマホ、あるいはPC版使ってる人ならPCでしょう。これがハードウェア。

ハードウェアというのはソフトウェアを動かすために必要なもの、だと考えれば良いです。なので、Wi-Fiなどの通信回線などもハードウェアの分類に入ります。あるいは少し細かくなりますが、スマホやPCの中に入っているOSもハードウェアの分類となります。ハードウェアがないと、ソフトウェアを動作させることはできません。

上記を踏まえて、クラウドの各形態について説明していきます。

まず、SaaSというのは、遠隔地のソフトウェアを使えますよ、というものです。ソフトウェアを使うためにはハードウェアが必要ですから、ハードウェア＋ソフトウェアをサービスとして貸し出しますよ、というものです。

例えば、このはてなブログ。これも実はSaaSなんですね。なぜなら、エントリした記事内容に関するデータや、ブログ投稿用画面を動かすためのソフトウェアも自分のPCやスマホには入ってませんから。当然それらのソフトウェアを動かしているサーバ（ハードウェア）も私たちのものではありません。まさにサービスとしてブログ用ソフトを使っているので、SaaSというわけです。

ただ、デメリットとしては自由にカスタマイズができないことです。ホーム画面の配置を変えたい、と思ってもWebページのソースコードを編集して書き換える、みたいなことはできないわけです。（もちろん、ソフトウェアとして提供されている機能の範囲なら、テーマを変えたり、カスタマイズすることはできますが。）

もっとカスタマイズしたい、カスタマイズしなければ十分に使えない、となった時に検討すべきなのが、PaaSです。

たまに一般的なブログサービスではなく、自分のオリジナルのホームページを作って、ブログを書いている人いますよね。彼らはWordPressなどのフレームワークを利用してブログサービス用プログラムを自前で作っています。そして、開発したプログラムをレンタルサーバ上に乗せることで、ブログサービスを利用しているのです。そして、このレンタルサーバサービス、がまさにPaaSの一つです。

要するに、自分で作ったソフトウェアを動かすための”実行環境”を提供してもらえるサービスのことをPaaSと言います。

提供してもらえる部分はほとんどハードウェアと同じです。しかしながら、自作のプログラム以外のパッケージ製品を提供されているハードウェアに対してインストールしたりできない、というデメリットがあります。あとは、ハードウェアのスペックもせいぜい容量何GBぐらいにするか、という程度のもので、細かく指定することができません。そのため、あくまで”実行環境”を提供してくれるサービス、という表現を使われる場合が多いです。

というわけで、登場するのがIaaSです。IaaSもPaaSと同様ハードウェアをサービスとして利用できますが、これはハードウェアのスペックや構成、どんなソフトを入れるかについてもかなり柔軟にカスタマイズすることができます。よって、企業でも利用しやすい「クラウド」です。ちなみに今「クラウド」と呼ばれるサービスはほとんどがこれに該当すると考えて結構です。

と、ここまでがクラウドについての説明です。非IT系でここまで把握していれば、まぁ多少はクラウドのことを知っている人、で通るでしょうし、十分かと思います。ただ、ITエンジニアの方には、もう少しこれの意味するところを理解していただきたいかな、と。特に私のようなインフラエンジニアには。

今までの時代は、Linuxのスペシャリストとか、Oracleがバリバリ使える、そんな専門家が割と重宝されてきたと思うんですよ。サーバ構築スキルなどもきっと評価されていました。（スマホとかと違って、ソフトウェアをインストールするのもコマンド操作が基本なので、直感的にはできないので。）でも、こんな風に新しい技術が出てくると、もうそういった専門家は入らなくなります。ここでソフトウェアを指定してこのボタンを押せばインストール完了、みたいに。それこそ、スマホなんかはもうすでにそうなってますけどね。

エンジニア志望の人って、自分の専門領域にこだわりを持っている人が多いけど、これだけ時代の変化が激しい中専門領域にこだわりすぎることは逆に危険だな、と感じましたね。時代的にはフルスタックエンジニアへのシフトも推奨されていますし。逆に設計の考え方、みたいな方がずっと役に立つとゆうか、汎用的に使えるというか。

こんな風に考えると、エンジニアってよっぽど新しい技術好きじゃないと大変だなーと思う次第です。

新人IT担当者のための クラウド導入&運用がわかる本

イラスト図解式 この一冊で全部わかるクラウドの基本

まず、「できます」と言おう。

子供の頃は、きっと不言実行の方が相手に好印象を与えることが多かった。普段はおとなしいのにサッカーは上手いやつ、根暗なのに音楽の時間に歌を歌うと上手いやつ。能ある鷹は爪を隠す、ではないが、本当に能力のある奴ほど、自分の能力を誇示しないものだと思っていたし、そういう人の方が好印象だったと思う。

でも、社会に出ると、こういう人たちは誰からも目を当てられず、単なる普通の人、で終わってしまう可能性が非常に高くなる。なんでかって。それは機会の平等性が子供の世界と大人社会では全く異なるからだ。

子供の頃は、みんなが同じように様々な科目を勉強し、色んなスポーツをやり、芸術などに勤しむ。だから、否が応でも、自分の能力が人目に晒される機会があったわけである。しかし、仕事の機会というのは全くもって平等ではない。自分で起業でもしない限り、その時、その場所でやらなければならないことを仕事としてやらされるだけだ。基本的に自分がやらされる仕事は他人はやらない仕事である。

そんな限られた範囲ではあるが、仕事の中には当然つまらないものと面白い要素が詰まった仕事がある。では、面白い仕事（ここでは難易度の高い仕事のことだとする）が誰に与えられるかというと、その仕事が出来そうな人物に与えられるのである。つまり、その仕事をできる能力があるのかないやつなのかは全く関係ない、ということだ。

もちろん、過去の実績なども参考にはなる。ただ、過去と全く同じ仕事をする、ということはないし、全く新しい事業を始める場合にはそもそも皆が未経験、という場合だってある。そんな時、何を頼りに仕事を任せる人を決めるのか。それが自信であり覚悟である。

自信と覚悟を示す、実に簡単な方法がある。まず、「できます」ということだ。

もちろん、できる根拠などはない。そもそも未来の出来事について100％断言することなんて不可能である。それは周知の事実である。にもかかわらず、「できます」ということの意味は？自信と覚悟を相手に示すことだ。未来にコミットするというと表明なのである。

これはプロポーズと全く同じである。永遠の愛を100％誓うことなんてできない。ただそれでも誓うのだ。極端な話、ハッタリでも構わない。でもベストエフォートで努力はするという覚悟を貫く必要はある。ただ、無理だったとしても平謝りして離婚するしかできない。

仕事で失敗したって、謝って怒られるだけだ。失敗しなければ、一つあなたの実績ができるし、こんどはその実績があなたに仕事を任せる裏付けにもなる。

まず、「できます」と言おう。

好奇心を取り戻すには

会社の打ち合わせでとある質問をすると、「それは何を意図した質問なの？」と聞かれることがある。こちらからすれば、まず自分なりに意味を解釈した上で質問に答え、その後で意図を確認してほしいものだが、平気で逆質問をしてしまう人がいる。

大学の講義などではいきなりこのような切り返しをされることはまずない。別にどんな意図であったとしてもそれを知りたいという学生の好奇心に答えることが重要だからだ。しかし、ビジネスの現場では、目的のない質問は排除される傾向にある。それは仕事が理解ではなく、成果を目的とするものだからだ。すなわち、最小限の理解で最大限のアウトプットを出す、これがビジネスにおいては理想とされる考え方なのである。

だから、何にも知らない人が多い。私もそうだ。短期的な成果を出す上で、”理解している”ことは、それほど重要ではない。むしろ本当に理解する必要に差し迫った時に、「あの人に聞けばわかる」とか「あそこの設計書を読めばわかる」ということさえ把握していれば十分なのだ。そう考えられている。それを理解することに時間を使うぐらいなら仕事をしてくれ、という話になる。

これが好奇心を奪う元凶である。好奇心がないと、物事の理解は浅くなるし、行動の活力もなくなる。これでは能力の向上は最小化され、特定の分野に特化することもなくなる。サラリーマンにプロフェッショナルがいないのは、こういう文化的背景もあるんじゃないだろうか。

好奇心がないと新しいことができず、人生もつまらなくなる。大人よりも子供の方が楽しかったのは、好奇心を抑制されない文化の中で、好奇心を抑制しないだけの時間があり、色んな新しいことを学ぶことができたからだ。

だから、大人は好奇心を取り戻す必要がある。確かに、社会として、ルール上好奇心を持つことはあまり推奨されることではない。好奇心は秩序を乱す恐れのある発想だからだ。しかし、新しいビジネスを考えたり、価値を創造するフェーズでは、むしろ好奇心無くして行動することはできない。だって、「聞けば答えを教えてくれる人」も「答えの書いてある設計書」もないのだから。

そんなこと言っても自分の知らない世界に興味がない、という人は多いだろう。正確には、多少の興味はあるけど、それを深く調べるのは時間がもったいないと。私たちはこの情報社会の中で、調べることを毛嫌いするようになった。丸一日かけて何かを調べる、なんて今ではあまり考えられない。ネットで調べればほんの1分足らずで欲しい情報が手に入るのが当たり前だと思っているからだ。だから、自分で仮説を立てたり、様々な情報を収集したりすることを億劫に感じてしまう。1次情報を得るために行動することもない。私だってそうだ。

でも、そこは苦しい時期を超えるしかない。よく人間関係や性格などの問題に対する解決策として、「好奇心を持ちましょう」が提示されることが多いが、これは実は問題の裏返しでしかなく、好奇心を持つためにどうすれば良いかがわからないので、好奇心の持ちようがないのだ。

ではどうすればよいのか。苦労して新しい知識を取り入れる、に尽きる。実は、好奇心というのは、自分が全く知らないものに対しては強く働かない傾向がある。少し知っているけれど知らない部分がある、つまりは無知を自覚しているものに対して好奇心を抱くのだ。

例えば、ミステリー小説は好奇心を煽るタイプの作品である。中盤あたりから結末が気になって止まらなくなる。ただし、序盤は背景となる人物についての情報をインプットするだけなので、はっきりいってそれほど面白くはない。ただし、そのインプット情報があるからこそ、中盤で事件が発生した時に、犯人は誰なのか、彼らがどうなるのか、が気になるのだ。

小説やドラマなどの作品は好奇心の煽りと知的欲求を短時間で満たしてくれる。当然、苦労する時間は短い。しかし、人生でもこの構造は変わらない。始めに苦労して学ぶ時期を設けると、好奇心を持てる幅はきっと広がる。まずは新しい知識を取り入れるところからスタートしてはどうだろうか。

インプット本はこちら↓↓↓

子どもは40000回質問する あなたの人生を創る「好奇心」の驚くべき力

説明が下手？理解力が足りない？

会社の打ち合わせで誰かが説明を聞いている内容を聞いていて全くわからない時、逆に自分が説明する側に回って相手に理解してもらえない時、きっとあるだろう。説明が理解されない、というのはどんな場所でもよくあることだ。

この問題の原因はたった二つ。話し手の説明が下手か、聞き手の理解力が足りないか、そのどちらかである。でも、結局どっちが悪い、と白黒ハッキリさせるのは難しい。そもそも説明が下手でも理解力のある人が聞けば、あるいは、理解力が低くても説明が凄く上手ければコミュニケーションとしては問題は発生しない。両者は補完関係にあるのだ。

この、問題の根本をどこに求めるのか、が実は学生と社会で異なってくる。学生の頃、先生の話を聞いて理解できない人は理解力が足りない人、すなわち学生側の問題だと考えられることの方が多い。確かに、先生によってわかりやすいわかりにくいは当然ある。けれど、優秀な学生は先生の話を理解することができていたはずだ。

しかし、社会人になると、説明がわからないとなると、説明する側に問題がある、という判断になることが多い。相手の理解力のせいではなく、話し手に非があるとする考え方だ。特に、上司への説明、お客さんへの説明の場面でこの構図は顕著に表れる。

なぜ、こういった差が表れるのか。これは主従関係が逆だからである。

例えば、先生と生徒の関係。先生は生徒に勉強を理解してもらうために、生徒は勉強を理解するために先生の話を聞く。しかし、先生は生徒に勉強を理解してもらおうが理解してもらわまいが、別に大きな違いはない。（詳細を知っているわけではないが、クラスの平均点が高いからといってボーナスが増えるわけでもないだろう。）

反対に、生徒の方からすると先生の話を理解できるか理解できないかで、進学する高校、大学、さらに言えばその後のキャリアも大きく変わってくる。（もちろん、全ての人がそう考えているわけではない。）つまり、生徒の「理解したい」気持ちの方が、先生の「理解して欲しい」気持ちよりも上回っているのだ。これがすなわち、先生が主で、生徒が従、という状態である。

しかしながら、社会で自分がお客さんに説明をする時。この場合は、お客さんが主、自分たちが従となる。社会の場で説明をする場合は、ほとんどのケースで、相手に何らかのアクションを取ってもらうためである。わかりやすいのは企画書の提案など、その説明如何によっては、受注できるかどうかが決まる、という場合などだ。

私たちが「売り込みたい」という気持ちの方が、お客さんの「買いたい」という気持ちよりも強い。（お客さんからすればメリットのある提案なら受け入れるが、その検討とか理解には時間・コストを掛けたくないのが普通。）だから説明する方が相手に理解してもらうための工夫をしなければならない構図となる。

もちろん、学生と社会人の違いとして述べたが、塾講師と生徒の関係や、BtoC企業の場合など、主従関係が反転するケースもある。（例えば、iPhoneの説明が不十分だって、ユーザの方の使いたい気持ちの方が強ければ、自分たちで調べるだろう。）大切なのは、主従関係がどうなっているのか、だ。理解できなかった時に一番困るのはどちらなのか、ということなのである。

IoTと監視社会

IoTとはモノのインターネット化、すなわち世の中のあらゆるデバイスが相互に情報通信を可能となる概念のことである。これはセンターの小型化、高精度化に起因して成長を遂げたITの分野である。

例えば、IoTを使って何ができるかというと、遠隔地点の監視、あるいは遠隔操作などだ。これらができることによって、今まで行動が制限されていた物理制約が緩和され、シームレスに、リアルタイムで自分たちが見たいものを見る、やりたいことをできるようになっている。

IoTはセキュリティと親和性が高い。不正や防犯を検知するために、人の目が届かない場所に入ってリアルタイムで監視したり、それらを通知する機能は、必ずや社会に対して大きな貢献をするものだと考えてられている。

しかし一方で、あらゆるところが監視されることは我々にとって本当に望ましいことなのだろうか、という懸念もある。それはセキュリティとは相反する概念、プライバシーの考え方だ。

今までのツイッターなどSNSの普及によって、一部の芸能人たちのプライバシーが全世界にさらされる問題があった。色んなことを共有できるということは色んながことが共有されてしまうということでもある。

基本的に芸能人に限らず、スマホを使っている我々の行動は全てデータとしてあらゆるところにネットを介して送信・蓄積されている。そして、それらの情報がビッグデータとして解析され、広告などに利用され、我々の消費行動に影響を与えているのだ。ただ、それがプライバシーの侵害として認識できるのは、芸能人などの一部の有名人ぐらいというのが真実である。

IoTはさらに個人に関するデータを膨大化させ、今までならわからなかったはずの個人情報にういても世間にさらすことになる可能性がある。情報の流入ルートがスマホだけではなくなるし、ということは情報を取得する場所も増えるからだ。

とりわけ悪事を働かない人であっても、自分がどんな人間で、普段どんな人間であるかを24時間監視されているというのはあまり好ましくはないと思う。息が詰まって仕方がない。

例えば、今は子供の安全を謳って、親がいつでも子供を監視できるサービスがあったりするが、常に親にコントロールされることは、子供の自我を抑制することにもなりかねない。そもそも、子供ながらに危険に自分で対処する経験がなければ、大人になった時に問題解決力や自分で考える力に影響を及ぼしてしまうのではないか、とも思う。

何より、あんなものは子供にしてみたらいい迷惑でしかないと思う。私が親に常に監視されている子供なら、自分が檻に閉じ込められた動物園の動物であるかのように感じる。親としては子供の安全を思ってのことだろうが、実際は、自分の安心と子供の自由がトレードオフになっていることを理解しておく必要はあるだろう。

IoTはこういった社会を助長する。つまりは社会としての安心を優先することによって、個人の自由が侵害されるリスクを孕んでいるということだ。IoTはセキュリティと親和性が高いからこそ、使う範囲や使う機能を制限して、自由についても考えを巡らせる必要がある。

新規事業を考えて虚しくなった話

今私の担当では新規事業の立ち上げに向けて少しずつ検討を開始している。背景としては、お客さんの事業・業界がシュリンクしているため、別の業界を相手に新しい事業を生み出すことを視野に入れている、といった感じだ。

私の会社はまぁ正直業界ではそれなりのブランド力を持っている、と思う。だから、社内を探せば提案するためのパイプは何かしらあったりするし、新規で営業活動をしても話ぐらいは聞いてくれるお客さんはいる。

また、お客さんの課題を解決するためのソリューションは社内にたくさんあるので、そこをマッチングさせることで利益を上げようとする、というのが基本的な方針である。皮肉な言い方をすると、転売活動である。

でも、こういった活動はほとんどが失敗する。仮に受注までたどり着いたとしても、直接的な開発を請け負うのが自分たちの担当という形になることはない。なぜか。マッチングさせるところで我々は役割を終えてしまうからだ。

もちろん、我々はそうではないと主張するだろう。マネジメント力で貢献します、と。別の会社と競争しているのであれば、それでも良いのかもしれない。ただ、同じマネジメントを強みとしている会社の中で争うのであれば、マネジメント力は大した強みにはならない。別にあなた方にお願いしなくてもうちでやりますよ、という話になるのが自然だろう。

では、技術力を生かすのは？新しい技術を使っていたり、既に確立したソリューションがあれば、その経験・ノウハウを生かすことはできる。しかし、そういう開発経験がないとどうなるか。結局、他で生かすための開発力がないので貢献のしようがない。そもそも技術を生かせないから、外部とのマッチングでプロフィット化を目指す方向に進むしか選択肢がないのである。

うちの会社は基本的にはお客さんとかその業界単位で部署が縦割りになっている。なので、自分たちと他の担当を分けている最大の強みは自分たちだけの顧客を持っているところにあるのだ。つまり、別の顧客を探すという行為は、自分たちの最大の強みを捨てるのに等しい。そんな強みを失った組織が、他者を利用したビジネスをして、自分たちの利益が多くなるように計らうなんて、都合が良過ぎないだろうか。到底うまくいくとは思えない。

などと考えていると、希望であるはずの新規事業を考えても虚しくなってくるだけであった。

リリース準備にかける時間の妥当性は

僕思うんですけどね。もし、高校入試とか大学入試のタイミングが、自分の好きなタイミングで選べるとしたら。日本人のほとんどはいつまでも勉強してるんだろうなって。そう思います。いくら勉強したって合格率100％にはならないけれど、勉強した分だけ確率は上がっていく、あるいは上がっていくような感覚になるから。

人生には本番という、ここだけは絶対に失敗できないって場面が何度となく訪れます。受験もその一つです。そして、失敗のリスクを避けるためにできることはひたすら準備です。準備不足で失敗する人もたくさんいます。絶対に失敗できないからこそ失敗のリスクはできるだけ避けたいと考えます。それは日本人なら尚更です。

私もどちらかといえば慎重派ですが、必要以上にリスクに備える時間は無駄だと考えています。だって、やったことない作業の成功確率なんて測りようないし。模試の結果で80％で合格とか言われても無意味だし。それが本当に8割の合格率を保証する数字でもなければ、8割が正しくても残り2割に入ることだってままあることです。

こんな私にとって、システム開発のリリースにかける準備稼働というのは実に不毛なんですよね。クソつまんない。リリース手順書を作って、Rvして、リハーサルやって、切り戻しのリハーサルやって、本番を迎える、みたいな流れ。メールアドレスの宛先を一つ追加します、程度の改修で。失敗しても大きな影響が出るリスクも小さいのにもかかわらず。

ぶっつけ本番でやれば、1日で終わりそうな作業を、もろもろ準備して1ヶ月ぐらいかけてやる。コストを30倍かけてでもやるべきことなのでしょうか、と私はずっと疑問に思っている。

とは言え、「リスクが小さい」ということを論理的に説明することってできないんですね。みんな、リスクの大小というのは感覚に頼って判断しているんです。それはつまり、リスクの対策が不足なのか過多なのかを論理的には判断できない、ということです。

で、日本組織の場合は、必ず一番慎重な人の意見に合わせる決断が下されることが多いです。勇敢な上司ならわかりませんよ。けど、現場の実態がよく見えない、ソースコードの構造がよく見えていない課長クラスの人達が安心するためには、品質を高めるプロセスをどれだけ踏んでいるかが極めて重要になってきます。そのプロセスにかかっているコストよりも、失敗してお客さんに迷惑をかけるリスクを避けるのは、特にコスト意識の低い大企業ではもはや普通ですね。

上層部クラスがこの当たりのリスクを許容する、あるいはコスト感覚と照らし合わせて考えてもらえないと、いつまでたっっても無駄な仕事は減らないし、現場の生産性は上がらないままです。標準化された枠組みに縛られず、規模に応じてスリム化する柔軟さが必要でしょう。

顧問ITエンジニア

先日RPAについて少し紹介しました。

n1dalap.hatenablog.com

RPAの一番のメリットは、今まで予算的に切り捨てられてきた領域が自動化できるってことです。反対に、今までは採算が合わないせいでシステム化されてこなかった領域がたくさんあったってこと。

その理由は、システム屋さんの戦略都合と現場業務の多様性です。システム屋さんの基本戦略、大規模な開発案件を受注すること。ほとんどのシステム屋さんは「うちは大企業のお客さんがいます」を売り文句にしているのはこのためです。大規模なシステム開発の方が儲かります。（もちろん、難易度も上がるので必ずしも良いわけではありません。）

しかし、裏方の仕事はそんなにリッチなシステムを作る必要もなければ費用対効果も低い。また、製品化されているパッケージ製品をそのまま適用するにはあまりに標準的でない会社ならではのやり方だったりします。よって、こういったすごく小さい規模だけれど、オーダーメイドで作らないとダメな業務は今のスキームではシステム化されない、というわけですね。

ここに実はビジネスチャンスがあるんじゃないかな、とは考えてまして。

例えば、顧問弁護士ならぬ顧問ITエンジニアみたいな労働形態で、小規模なシステム開発のみをターゲットにする。開発に関わる人が少ないと、システム開発にかかる工数やコストは激減します。というのも、システム開発が一般的に高いのは、開発に携わる人が多く、情報連携などのコミュニケーションコスト、進捗などの管理コストがめちゃくちゃかかる上、作業上のバッファが色んなところで積まれているからです。よって、人数が少なければ少ないほど、安く済みます。

ぶっちゃけ1k程度のシステム開発であれば、優秀な人なら一人で1ヶ月ぐらいで作れちゃうと思いますね。それで、30人が1時間かかってた作業が1分で終わるともなれば、月5、6万のプラスですよね。SIerの単価である月80万〜100万ぐらい払うとしても、1年ぐらいで発注側は元はとれますし。

あとは保守とか運用も統合的にサポートする形にすれば、どちらにとっても悪くない話だと思います。ただ、まぁ一人でやる、というのは全く一般的でないのか、こういう事例をあんまり聞くことはないですね。

むしろ私はそんな感じで仕事したいけど。

イジのオシゴト

新年度始まりましたね。今年度から大学生になった人、社会人になった人、異動になった人、たくさんいると思います。私はというと、開発プロジェクトも3末で完了し、本格的に維持・運用に変わります。

で、維持運用になって初日に感じたこと。

仕事がない！！！

はい。システムの維持とか保守って基本的にやることないんですね。だってもうサービス動いてますし。できあがっちゃってますし。もちろん、バグが発生したり、システムが停止するようなトラブルとか（インシデントと言います）があったら即時に対応する必要はあります。

ただ、長年動いているシステムとかだと、もう致命的なバグは枯れてるんですね。なので、やることといえば、日々の業務の改善であったり、ちっちゃい故障改修とか定期的なメンテナンスぐらいなもので。しかも大抵の業務は手順が確立されているから新しさがない。要するに結構退屈です。

開発だと、自分がやらないとダメ、とかいつまでにやらないとダメみたいな仕事が次々と出てきて。しかも、これ今までやったことあんのか？できんのか？みたいなとこからスタートする。これはこれで納期やら課題に追われて本当に大変なんですけど、実はこういうハラハラする側面が面白かったりするんですよね。

私が新人で入った頃に、当時私の育成担当をしていた維持チームの先輩はずっと私のことを羨ましいと言っていましたが、その気持ちも今ならよくわかりますね。考えてみれば今までずっと開発だったし、忙しすぎて維持がうらやましいなーと思う時期もありましたけど、結局仕事としては開発の方が面白いだろうなって。

ただ、発想を変えてみると、維持だと空き時間が増えるので、結構自由にいろんなことができるんじゃないか、とも思っています。というのも、開発をしていると、改善したいポイントがあってもついつい優先度が下がって結局何もできなかったりと、本業以外は手付かずになるケースが非常に多いからです。

私が常に考えているのは正規化と自動化ですね。

正規化というのはデータをなるべく一元管理できるようにすることです。例えば、PC管理簿と固定資産の管理簿があって、PCは固定資産でもあるからどっちの管理簿にも記入する、みたいな無駄を省くことです。会社ってとりあえず色んなところに情報を残し過ぎていて、何が正しい情報なのかわからないこと多いじゃないですか。あの影響は計り知れませんよ。

自動化は言葉の通り自動化です。作業を自動化する。これ、社会人ならみんな考えてほしいんですけどね。やることが決まっていて、やり方が決まっていて、手順書になっている業務は絶対に自動化できるんです。絶対に。

先日紹介したRPAという技術なんかに頼らずとも、ちょっとプログラミングができれば、自動化できます。バッチファイル、マクロ、VBSぐらいが使えればできます。ただ、手順やフローが明確になっていないものは、そこを整理するところからですかね。そこが結構重たいです。

まぁモチベーションは全く上がらない中ですが、これも一つの経験だと思ってやっていきます。

働き方改革でコンテンツビジネスはシュリンクする？

実のところ、ブログのアクセス数というのは平日の方が高いんです。土日や祝日はだいたい平日の半分ぐらいに下がります。最近は本ブログのアクセス数が割と安定してきたこともあり、こういった傾向が読み取れるようになってきました。

この結果、どうですかね。個人的には意外でした。なんとなーく土日の方が高くなりそうな気がしませんか。みんな休日だで暇だし、ネット見る機会も増えるんじゃないかと。ショッピングモールとかも土日の方が混みますよね。

ただ、理屈を考えてみると、ある意味土日のアクセス数が減るのは当然なんです。だってみんな休日って出かけるじゃないですか。どこかへ出かけたり、友人と遊んでる時に、目的のないネットサーフィンとか調べ事とかしないですよね。だからそもそもアクセスしてくる人が減るっていう。

平日のアクセス数は勤務中時間も多いんです。よく電車の中とかお昼休みのエレベーターの中とかで、２ちゃんねるの記事とかよくわかんないブログとか読んでる人多いですしね。むしろ忙しい時のスキマ時間とかにこういったコンテンツは利用されるんでしょう。

逆に休日は午前中のアクセス数が平日に比べて少ない。みんな休みだから寝てるか、起きていてもテレビみたり出かけたりと別のことしてると読み取れます。まぁ家にいればコンテンツを探すよりも別にやりたいことがあるってことですね。

この事実から一つの仮説が導けます。働き方改革、例えばリモートワークなどが当たり前に普及すると、ブログなどのコンテンツ系ビジネスはシュリンクする可能性が高い、ということです。

ほとんどの人は、電車で1時間以上かけて会社勤めをしています。徒歩で会社に通っている私からすれば、考えられない芸当ですが、これがむしろ一般的な生活スタイルです。

今のコンテンツビジネスとして大きなターゲットとなっているのは、この満員電車に群がる人たちなんですね。電車で移動する間の暇を有意義にしてくれるものがコンテンツだからです。

例えば、電車で移動する時に音楽を聴いている人が非常に多いですよね。でも、あれ電車移動をする必要がなくなったらどうでしょう。私は学生の頃は毎日音楽聴きながら通学してましたけど、社会人になって電車にのらなくなってからはほとんど音楽を聴くことはなくなりました。

電車の中でコンテンツを楽しむのは、そのコンテンツが好きだから、というのは本質的ではなくって、電車の中でできる面白いことってコンテンツぐらいしかなから、なんです。だから、電車で移動する必要がなくなったり、家で仕事ができるようになったら、コンテンツの価値ってかなり小さくなります。というよりもちゃんとした価値のあるコンテンツしか利用されなくなっていく、といった方がいいかもしれません。

組織に必要なのは「タバコミュニケーション」の関係

「髪切った？」

この一言を言えるか言えないか、言われるか言われないか。この差に人間関係のありようは露呈される。学生の頃であれば、嫌というほどこんなやり取りをしたはずだが、社会人になってから耳にすることもほとんどなくなった。これが友人か否かを分ける一つの指標になると個人的には思っている。

同僚は友達ではない

あなたが友人と話をする場面を想像してほしい。たぶん、その相手に共有する必要もなければ、その時に共有する必要もない。きっと、その話である必要もないだろう。中には相談ベースの会話もあるかもしれないが、友人とのコミュニケーションというのは9割以上が必要のない会話なのだ。

でも、私たちは必要のないコミュニケーションをとる。それは、友人とのコミュニケーションはそれ自体が目的になっているからである。コミュニケーションをとること自体に喜びを感じ、意味を感じる。それが友人関係というものだ。だから、先ほどの「髪切った？」なんて一見無駄に見えるやり取りにも意味が生まれるのだ。

翻って、会社の同僚や先輩、上司はどうだろう。必要のないコミュニケーションはあんまりとろうとしないのではないだろうか。みんな仕事もあるし、別に友人でもないんだから、コミュニケーションをとるのは必要性がある時だけ、と思っている人の方が多いはずである。

必要って何？

この、「必要がある時だけコミュニケーションをとる」スタイル。実は、チームで進めているプロジェクトの問題を引き起こすきっかけとなる大きな要因である。仕事の問題の9割はコミュニケーションが問題、とも言われるが、特に問題なのが、この日本型組織におけるコミュニケーションに対する暗黙のルールである。

新入社員として会社に入って、まず教わるのが報連相である。そして、この時点で多くの人が過ちを犯している。というのも、良い報連相の定義が「必要なことだけを必要なタイミングで伝えること」だからだ。

しかし、「伝える必要があるかどうか」を判断するのは誰なのか。「伝えるべきタイミングがいつなのか」を判断するのは誰なのか。言うまでもなく、これは新入社員自身である。にも関わらず、どういう問題については伝える必要があって、どういうことなら緊急で伝えなければならないのか、ということについては何も教えてもらえないことの方が圧倒的に多い。仮に聞いたとしても「それは自分で考えて」、みたいなことになり兼ねない。

必要性に対する認識を合わせられない理由は、何が必要で何が緊急度が高いのかが感覚依存で伝達できる形になっていないからだ。それは先輩や上司たちも誰からも教わることなく、独自の経験に基づいて判断軸を形成してきたから、ということでもある。

この結果として引き起こされているのが、必要性に対する考え方の差異だ。必要性に対する認識が揃っていないので、そもそも問題なのに報告されないとか、問題を報告するタイミングが遅くなるとか、そういったことが起こる。

また、必要かどうかを他者に任せるのはもう一つの危険性を孕んでいて、例えば、「相手に聞かれない限りは答えなくてもいいだろう」とか「問題があったら報告があるはずだろう」とか、受動的な思考に陥り兼ねない。問題の報告なんて誰だってしたくはないものだ。結局、解決までにロスが発生しプロジェクトが炎上する。

まずは問題の定義を明確に

一つのやり方は問題発生⇨問題報告⇨対策検討⇨対策実施までが円滑に行われるような仕組みをちゃんと構築してやることだ。おそらくほとんどの組織でやっているつもりになっているのだろうが、できていないのが現状である。というのも、上記で述べたようにほとんどの場合が問題発生⇨問題報告の時点でつまづいているからだ。

真っ先にやるべきことは、問題の定義を明確にすることである。問題かどうかの定義は「お客さんに影響があるかどうか」みたいなざっくりとした回答を平気でしてしまう人もいるけれど、こんな抽象的なものではいけない。これだと、自分はお客さんに影響がないと思ってました、みたいな感じで必ず漏れが発生する。

前提として理解しておきたいのは、意思決定をする際にはデータとロジックがセットで必要となることである。例えば、飲み会の幹事をする時に、店を決める場合を考えてほしい。最終的に予算4000円、20人席のA店を選んだとしよう。この場合、A店には「席数が20人、予算が4000円のコースがある」というデータ、飲み会の参加人数が18人、支払い可能な料金が4000円まで」というデータ、そして、飲み会の参加人数は予約可能な席数より小さくなければならず、また予算は4000以下でなければならないというロジックがあって初めて意思決定ができるのである。

よって、問題とは何か？を決定できるような事前にデータとロジックを揃えておく必要がある。分かりやすい例は進捗遅延＝問題、という考え方である。そんなこと当たり前じゃないかと思う人もいるかもしれないが、この進捗が遅延しているかどうかが曖昧になっている組織は極めて多い。

例えば、一週間（５営業日）で一つの資料を完成させるというタスクがあった場合、４営業日まで全く手付かずでも、５営業日に完成させればいい（マイルストンさえ守ればいい）と考える風土の組織はこれを遅延とは考えなかったりする。あるいは単純に５営業日で完成するところまでしか計画として定義されていないと、４営業日でどこまで進んでいるべきなのかがわからず、問題として認識されない可能性がある。

逆に言えば、一週間で完成させるためには４営業日でここまでは終わっていなければならないという基準をキチンと定義しておけば、今日終わるべきところまで終わっていない、よって問題であると判断ができるようになるのだ。そして、判断のためのデータとロジックを意識合わせしておくことも重要だ。

コミュニケーションを設計する

断言するが、退屈で無意味に見える定例会議を毎週やっている組織が多いのは、仲が悪いからである。仲が悪いと、問題が明確であっても、話したくない人にはなかなか話しづらいものだ。問題の定義が明確化されたとしても、「別に今じゃなくても」と適当に自分に言い訳をし、報告のタイミングを誤ってしまうことはあるはずだ。

私は打ち合わせが大嫌いだったので、最初のプロジェクトでそういうった打ち合わせを完全に排除し、適宜メールで報告・相談というやり方をとったことがあったが、まぁ悲惨だった。既にプログラミングが完成しているはずの時期になって、実はこの内容では実装できません、みたいな報告があったり、上司が検討するはずの内容が止まっているのにもかかわらず、作業者は何らアクションをしてこなかったり、と。これも全てはコミュニケーションを設計していないことが原因だったのだ。

コミュニケーションルールを定めれば、報連相はしやすくなる。毎朝メールで進捗報告をする、でも週次で定例会議を開く、でもいい。ただし、これがうまく機能するためには、問題の定義が明確化されその判断軸が全体で共有されている必要がある。ここを疎かにしたまま形だけでコミュニケーションをとっているので、報告会の場では何も問題が報告されないのになぜかみんな忙しそう、みたいな状況になる。

コミュニケーションルールの弊害

コミュんケーションを設計することの重要性は上記で述べたが、実はコミュニケーションを固定化してしまうことによる弊害もまた大きい。そして、日本の組織はこのコミュニケーションルールの弊害をもろに喰らっているといえよう。

例えば、週一で進捗報告会を開くルールを定めたとする。すると、報告会の翌日に緊急度の高い問題が発生したとしても、「まぁ来週の報告会の場で報告するか」みたいな考え方になるのである。フレキシブルに対応できなくなってしまうのだ。

あるいは、そういうことを防ぐためにルールを厳格化し、毎朝進捗報告会を実施することにしたとしよう。すると、特に問題も報告するべき内容もないにもかかわらず、うち合わせを実施することになる。これは組織の生産性を下げる。誰もが無意味なことを理解しながら、形骸化して残る。しかし、弊害はあるものの、やっぱり今の組織では必要と言わざるを得ない。

理想はタバコミュニケーション関係

上で述べた方法論は、仲の悪い組織を前提とした対策の限界だ。なので、これ以上を求めるのであれば、人間関係にメスを入れなければならない。結論から言うと、「タバコミュニケーション」ができる人との仕事が一番やりやすい。タバコミュニケーションで仕事を受注した、という風の噂があるように、タバコミュニケーションで問題の解決策が思いついたり、仕事の段取りが決まったりすることは本当によくある。タバコを吸っている時というのは、かなり自然体で話すことができるのだ。

というのも、タバコを吸う時は基本的に休憩中であるから、何を話してもいい。相手に気を遣う必要もない。また、喫煙者としての仲間意識みたいなものも芽生えたりする。こういう状況がいろんなことを話しやすくしてくれる。また、仕事の話をしていたって、すごく緊急性の高い話をしていたって、あくまでタバコを吸っている間はプライベートタイム、みたいな共通認識があるため、普段は言えないような本音レベルの話も提供しやすい。

こういうメリットを知って、社会人になってからタバコを吸い始める人もいると思う。個人としてのこういった対策は大いに結構だ。ただし、チームとしてこの「タバコミュニケーション」に近いコミュニケーションスタイルを実現するための方法を考える、という取り組み事例をあまり聞いたことがない。

すごく簡単な例としては、「1時間に1回は必ず5分休憩を取る」とかをルール化してもいいと思う。むしろ、「なぜ社会人にはお昼休憩しかないんだ？」というのが初めて社会人になった時の感想だ。実態として、休憩を取る取らないは本人の自主性に任せられているものの、非喫煙者は休憩も取らずにずっと働いていることが多い。あなたの職場もきっとそうだろう。はっきりいって不自然でたまらない。どんだけ真面目やねん、と。

むしろ、アルバイトをしている時は当たり前に1時間に5分休憩があった。休憩がルール化されているから、たまたま休憩時間が一緒になった人と喋る、みたいなルーティンが出来上がる。そんな日々をひたすら繰り返していたら知らない間にみんなとそれなりに仲良くなっていた、ということもしばしば。逆に社会人はこういうルールがないから、仕事で絡まない人とは一生しゃべるきっかけがないし、仲良くなるきっかけもない。

コミュニケーションを円滑にするために、すぐ飲み会とかを開きたがる偉いさんが多いのだけど、そんな大掛かりな会は不要。というか一部の人以外にとっては迷惑でしかない。酒に頼ったコミュニケーションは酒を失った瞬間に元の木阿弥だ。

そもそも、人間関係は時間よりも期間の影響を受ける。つまりは、丸1日、10時間一緒に過ごした人よりも、5分間の会話を120日続けた人の方が確実に親密になれる。勉強を反復的に繰り返した方が良い理由と全く同じで、記憶に定着しやすいからだ。

そんなわけで、飲み会を一回開くよりも、たった5分雑談をする機会を積み重ねる方がいい。さすがにコミュ障でも5分ぐらいの会話ならもつだろう。別にタバコミュニケーションを実現するために全員がタバコを吸う必要はない。それに代わるルールを作れば良いのだ。

企画、得意ですか？

企画、得意ですか？

自分の企画力に自信がある人はどのくらいいるのだろう。少なくとも、この人は企画力があるな、と感じる人は自分の周りにはいない。といっても、開発部隊が仕事を始めるのは、基本的に企画が終わった後の仕事なので、当然と言えば当然だろう。

正確な割合を知っているわけではないが、多分会社の中に企画型人材が2割もいれば良い方なんじゃないだろうか。例えば、研修でクラス全員でビジネスの企画書を作る、みたいなグループワークをやったことがあるけれど、「企画が得意な人？」と聞いても、自負を持って手を挙げる人はいなかった。

どうやって企画する？

企画をする、となると、まぁたいていの組織では「ブレスト」を行うんじゃないかと思う。三人寄れば文殊の知恵、ではないけれど、みんなで意見を出し合った方が良いアイデアが出せるという共通認識がある。別に間違ってはいないと思う。

しかし、このブレストの結果、良いアイデアが出たなーという経験はあるだろうか。私は今までに一度足りともブレストの結果に満足できた経験はない。たいていの場合が、特定の人物がいくつかアイデアを出し、残りの大多数がその羅列から一つの選択肢を選ぶ、みたいなやり方をとっているからだ。ブレストの本質である、複数のアイデアのコラボレーションから生まれる新しい名案、みたいなものに出会ったことが少ないのだ。

もちろん、ブレストっぽくグルーピングをしてみたり、掘り下げて考えてみたりして、より高次のアイデア創出に向けて活動している組織も存在はしているのだと思う。でも、そういう取り組みがうまくいかない場合も多い。具体的にどういうことなのか、とか似たような事例にどんなものがあるか、といった展開型の思考を働かせようとしてもアイデアが出てこないことがあるんじゃないだろうか。これでは残念ながら、最終的な結論はごく平凡なものになってしまう。

企画ができない理由

「企画ができない」というのは大きく二つだ。一つはアイデアが出てこない、もう一つはアイデアの先、ビジネスの企画書としてまとめられない、である。ただ、ほとんどの人が始めに感じる壁は「アイデアが出てこない」の方だと思う。ということで、ここでは、良いアイデアが出てこない理由にフォーカスする。

なぜあなたは良いアイデアを出すことができないのか。こう問えば、自分には企画力がないから〜、とかクリエイティビティがないから〜という理由を答える人が多い。もちろん、私たちのほとんどは企画力もクリエイティビティも求められずに育ってきた人がほとんどである。企画の経験値が少ないのだから、能力がないと思うのは当然のことだ。私もはっきり言って企画は得意ではない。ただし、それが自分の企画力やクリエイティビティが足りないせいだとは思っていない。足りないのは知識である。

企画の質は何に依存するのか？

実は人のアウトプットの質を決める要因は二つしかない。データとプロセスである。データ、すなわちどんな情報を元にしているのか、その情報自体がどれほど信用できるのか。そしてプロセス、すなわち情報の加工法であったり、情報の関連性から結論を導くためのロジックやスキルのことだ。質の高いものを生み出すには必ずデータとプロセスのどちらも必要である。これはアウトプットが企画やアイデアの場合でも同じだ。

クリエイティビティというと、どうしても創造性とか閃きといった言語では説明がつかない能力（＝プロセス）にばかり注目が集まってしまうが、閃くための素材（＝データ）がない状況ではクリエイティビティなんてものは発揮しようもない。

例えば、アーティストと言えばクリエイティビティに溢れた代表的な職業である。良い音楽を生み出せる人は間違いなく創造性が豊かである。ただ、彼ら彼女らが良い音楽を生み出せるのは、音階を知っていたり、言葉を知っているからだ。加えて、自身の経験から感じた思いの良い表現方法をしっていたり、曲調が与える感情的な効果を知っているからである。まさにフレーズを閃いた瞬間は「神から舞い降りてきた」のかもしれないが、そのための素材集めが終わっていたからにすぎない。

ビジネス企画はデータの質が支配的

アーティストの場合は、組み合わせる要素（音、言葉）自体は非常にシンプルであり、その組み合わせ方で良し悪しが決まってしまう。だからこそ、どんな知識を持っているかよりも、どんな風に組み合わせるのかという感性、センスの部分が重要視される傾向にあるとは思う。

しかし、ビジネスマンのアイデアなんて、ほとんどが既存の問題を少し改善しましたとか、別の業界でやってたことをこの業界にも適応しました、みたいな組み合わせ方がほとんどで、組み合わせ方はそれほど複雑ではないことが多い。となると、むしろどんな知識を持っているかが企画においては支配的な能力だと言えよう。

ただ良い知識・情報を得ることは簡単ではない。今はネットで色んなことが調べられる世の中にはなったが、誰でも速く最新情報を得られるようになっただけで、競争優位を保つことはできない。ネットに上がっているアイデアは既に誰かに実行している。つまり、2次情報ではなく、1次情報から自分で考えて知見を導く、というスタンスが必要になるのだ。

アンテナを高くはっておくこと、と社会人なら上司なり先輩なりに言われたことはあるだろう。ただ、アンテナを高くはっておくことの本当の意味は日経新聞を読みましょうとかそういうところに本質があるわけではない。どちらかと言えば、日々の生活の中から、変化を感じ取ることだと思う。

例えば、最近はiQOSという電子タバコを吸っている人が非常に増えたと思う。もしかしたら喫煙者ではないから知らない、という人がいるかもしれないが、これを知っているか知っていないかというのは一つの大きな差になる。

さらに、じゃあなんでiQOSが流行ったのかを分析してみると、さらに普通の人は知らないような情報にありつける。iQOSの特徴は何で、メリットやデメリットは何で、他の電子タバコとは何が違って、その中でもどんな部分に良さを感じている人が多いのか、などなど。

例えば、iQOSは正式に保障されているわけではないが、健康への害が小さいことが知られている。多くの人がこの部分に魅きつけられているとしたら、例えば、社会の健康に対する意欲が高まっているのではないか、という仮説が導ける。その上で、健康に対する意識調査アンケートとかを調べてみる。

案の定、健康に対する意識が高まっていた、ともなれば、他に健康のためにどんな活動をする人がいるのか調べてみる。ランニングをしている人が多いとなれば、じゃあランニングという活動を手助けすることができるビジネスはないだろうか、と想像してみる。流行りのウェアラブル端末と組み合わせて何かできないか考えてみる。じゃあウェアラブルで心拍を計るアプリを提供してはどうだろう、みたな流れ。（これは完全な後付けだが。。。）

ただ、一番難しいのは、「気づく」ことだと私は考えている。最近何か世の中変わったことありましたか？と問われて何か思いつくだろうか。パッと出てくる人はアンテナが高い方だと思う。そもそも、変化に気づけないことも多い。普段から意識していないと、変化があっても気づけないのが人間なのである。

ただ、カラーバス効果という言葉があるように、「今日これを見つける」と思いながら、生きていると世界の捉え方は変わる。例えば、私はそれなりの頻度でブログを日々更新しているが、こんな芸当ができるのは、ブログに書きたいテーマが既に頭の中にあったり、あるいは、ブログに書くテーマを常に探しながら生きているからである。ブログをやっていなければ、何かに疑問を持つこともないし、ここまで思考を活発にすることもない。ただのうのうと生きていたはずだ。

科学的に生きると企画力は身につく

ある意味、企画力というと、文系バリバリの営業職の人に求められそうではあるが、必要なのは科学的なスタンスである。事象に対して疑問を持って納得のいく理由を調べる、本当に正しいか調べる、本当に正しいとすると、別にどんな事象が起こりうるのか仮説を立てる、実際に起きているのか確認してみる、みたいな仮説検証のプロセスが重要なのだ。私は理系だけど、興味のないことに科学的スタンスを発揮できないから企画には向かないなーと思う。

結論、アイデアが出ないと思ってる人の9割は勉強不足ということ。

RPAの登場が意味するもの

最近のITのトレンドに「RPA」というものがある。おそらく、「AI」とか「クラウド」とかに比べると、かなり馴染みのない言葉だろう。まだ日本では言葉自体もそれほど普及していない新しい概念である。正式名称はロボティックプロセスオートメーション、直訳すれば「ロボットによるプロセスの自動化」である。

そう、簡単に言うと、RPAとは業務自動化によって作業を効率化するための技術概念である。主にターゲットとなっているのは、ホワイトカラーの、特にバックエンドで活躍する人たちの業務を自動化することだ。おそらくRPAの解説を読むとそんな概要が説明されているだろう。

新しい価値やサービスが次々と創出される時代の流れとは逆行しているように見えるかもしれない。ここに来て、業務の効率化なのかと。あるいは、業務の自動化なんてシステムでもできるじゃん、と思う人もいるかもしれない。SIに勤める一人として私も当初はそんな印象がなかったわけではない。

結論から言うと、RPAはSIerの価値を揺るがしかねない存在になる。RPAは単なる自動化の新しい技術、ではない。従来のシステム開発のやり方を根底から覆す可能性を秘めている新しいビジネス領域である。

▪️RPAの特徴

最初に述べておくべきRPAの大きな特徴は、従来のシステム開発では対応が難しかった領域の作業を効率化できる点にある。

近年、システム開発の現場で大規模な開発プロジェクト案件は減ってきている。実はもう、ほとんどの会社における主要な業務はシステムの導入によって自動化・効率化が進んでしまったからだ。ほとんどが機能追加とかプチ改修みたいな開発である。つまり、主要な業務について大きな効率化の余地は残されていない。

しかし、それはそれなりに大きな会社に限った話である。未だに小さな会社ではExcelやWordなどを駆使しながら仕事をしている現場もあるはずだ。あるいは大きな会社であったとしても、裏方の仕事、事務的な入力作業とかはなかなか専用システムが導入されていないのではないだろうか。

この理由は何か。システム開発はめちゃくちゃ高いからである。しかも発注側にとって、システム開発とは先行投資である。まず莫大な金額を払って、数年かけて運用して効率化された分のコスト削減によってその投資金を回収し、それ以降は利益に貢献できる、というモデルだ。

先日のエントリで述べたように、いかに単純そうなシステムであっても専用のものを作ってもらうとなるとどうしても多額の資金がかかる。なので、資本力のある会社か、業務が効率化された場合に削減できるコストの見込める業務しかシステム化できない、という本質的な問題を秘めている。実際、大企業としか取引しないSIerは多い。

n1dalap.hatenablog.com

しかし、RPAはシステム開発に比べると安い。正確なことは言えないが、数千万とか数億はかからないはずである。それはシステム開発の大部分を占めている人件費がほぼカットされているからだ。この理由は、RPAの二つ目の特徴でもあるプログラミングレスと関係がある。

例えば、一般的にシステムを作る場合は、ほとんどの場合、プログラミングという作業が必要となる。パッケージ製品をカスタマイズする場合も基本的には同じで、パッケージ製品を構成するプログラムを理解した上で、プログラムを追加・修正しなければならない。

しかし、RPAはプログラミングという作業を必要としない。具体的には作業者が行う業務手順を記録させることで、システムが出来上がるのである。エクセルのマクロの記録機能を使ったことがある人ならイメージが沸くと思うが、作業者が行った手順が自動でプログラム化され、それが再利用可能なシステムとなる。ただ、マクロと違って、PC上のあらゆるアプリケーションとのデータ連携を可能にするのがRPAである。

現在のシステム開発は要件定義、設計、プログラミング、テストと工程を重ねて業務システムを作り上げていくが、RPAは作業を記録させるだけでシステムが出来上がる。恐ろしく開発スピードが速いのだ。もちろん、データの違いなどを考慮した設定は必要になると思われるが、GUIを用いて直感的に設定もできる。また、AIを活用した技術ではあるため、そのレベルによってはユーザの設定さえ必要としない場合もあるだろう。

どちらかと言えば、ユーザが自由にカスタマイズしやすいソフトウェアパッケージ製品をイメージした方がわかりやすいかもしれない。ソフトウェアパッケージは、日本の現場にありがちな、標準化されていない業務への適用が難しく、またIT専門外の人間が改造することも難しかった。しかし、RPAはIT系人材ではなくとも自由に自分たちの業務に合わせて改造できるパッケージ製品。そんな感じで考えればわかりやすいと思う。

よって、小規模企業とか、バックオフィスの業務の効率化もターゲットに含めることがを可能にした。今まで収益化が難しかった領域を責めている感じが、なんとなーく、Amazonのロングテール戦略を彷彿とさせる。市場への影響も与えるんじゃないだろうか。（なお、かのマッキンゼーは）

▪️SIerはRPAをどう捉えるべきか

察しの良い人なら次の事実に簡単に気づくはずだ。

「RPAがあればSIerなんて要らないんじゃね？」

SIerが解釈すべきRPAの本質は、今まで業務効率化の難しかった領域の自動化が可能になったことではない。ユーザ自身のシステム開発が可能になったということである。だったらSIの存在意義はなくなる。

実際のところ、システムの内製化の流れは進んでいるし、従来型のSIのビジネスモデルは崩壊しつつある。そんな中、RPAの登場はさらに事を深刻化させるキッカケとなるだろう。

インプット本はこちら↓↓↓

RPA革命の衝撃

 参考↓↓↓

システムインテグレーション崩壊　?これからSIerはどう生き残ればいいか？

キャリアよりも小さなやりたいこと

先月の話ではあるが、主任というポストがついた。ついこの間まで新入社員、今もまだ後輩は二人しかいない。そんな中の、出世である。聞いた話によると役職がつかない人も一定数はいるらしいが、年功序列のお決まりみたいなもので、実質的な価値はない。

そんな経緯もあり、主任向けの研修とやらを先日受講させられた。テーマはキャリアである。平たく言えば、「あなたは将来にわたって何がやりたいのかを本気で考えましょう」、というやつだ。うちはITの会社ではあるが、会社が用意しているキャリアとしては営業とかコンサルとか、技術系のスペシャリストとか様々なものがあるので、その選択肢を考えることが趣旨となる。

日本人の中で、自分がやりたいことを明確に意識している人はほとんどいない。実際、私のグループは皆、私よりも年次が2年も上の先輩だったが、誰一人として、自分がどういうキャリアへ向かっていきたいか、ビジョンがはっきりしていなかった。かくいう私も技術系へ進むこと以外はそれほど考えていない。

あなたは自分のやりたいことを考えたことはあるだろうか。あるいは、やりたいことがない自分を嫌だと思ったことはないだろうか。

私は今まで自分のやりたいことを考えてきたつもりである。やりたいことをやる人生、自己実現が幸せだという仮説を信じているので、当然実行するための「やりたいこと」が必要である。逆に、やりたいことがなければ人生はつまらない、ということでもある。

だから、やりたいことがない、やりたいことがよく分からない自分が嫌であった。しかし、本当のところ、「やりたいことがある」状態にさえなれば、悩んだり考えたり苦しんだりすることなく、幸せになれる保証を手に入れたかっただけなのかもしれない。俗に言う、青い鳥症候群とはこういうことを言うのだろう。最近はこういう若者が多いのだとか。

さすがにこの年次にもなると、自分が永続的にやりたいと思い続けられることなんてものはない、ということを悟ってしまいつつある。人生というのは、具体的なやりたいことを見つけて、それをやって、それに飽きて、また別の新しいやりたいことを見つけて、それをやって、の繰り返しである。悩んだり考えたりする時期があって、楽しい時期があって、それを繰り返していくだけだ。そういう過程を通して、自分の中の抽象的なやりたいこと（しかし、それは単なる憧れとかではなく経験から帰納化されたもの）を理解していくしかないのである。

だから、今やりたいことがなくても問題はない。というか、子供の頃はやりたいことなんてなくても楽しかったんじゃないだろうか。ちょっと昼休みにドッジボールしたい、とか気になるあの子と話したいとか、みんなで花火やりたいとか、そんな些細なことをやってるだけでも幸せだったのではないだろうか。

ただ一つ、子供の頃と今の違いは、未知の領域の広さである。子供は普通に生きているだけでも教育の場で新しい情報を与えられ、初めての経験をさせられるが、大人はもう自分から動いたり行動パターンを変えない限り、新しい興味や関心を得ることはできない。そのため、些細なやりたいことすら簡単には思い浮かばないこともあるだろう。

そのためのやりたいこと探しだ。人生全てを捧げるほどのやりたいことを見つける必要はない。ただ少しでも新しい情報に触れる、新しいことをしてみるぐらいの努力をしないと、小さなやりたいことさえ見つからない。

さて。長期的なキャリアという視点にたつと、今の選択がすごく重要で、それを間違えると人生全てが崩壊するような気持ちになったりもするだろう。しかし、どれを選択したところで大して変わりはしない。むしろ、一度選択したきりで思考を停止してしまうのが問題なのだ。