∑考=人

そして今日も考える。

顧問ITエンジニア

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

n1dalap.hatenablog.com

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

イジのオシゴト

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

 

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

 

仕事がない!!!

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

「髪切った?」

 

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

 

同僚は友達ではない

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

 

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

 

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

 

必要って何?

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

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

 

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

 

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

 

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

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

 

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

 

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

 

すごく簡単な例としては、「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革命の衝撃

RPA革命の衝撃

 

 

 参考

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

ライバルの設定方法

昔は、ライバルと呼べる存在がいた。勉強でコイツには負けたくない、バスケットでこいつには負けたくない、ゲームでは、おしゃれでは、腕相撲では・・・などなど。数えればキリがない。たぶん私が勝手に思っていただけだけれど。

 

ただ、おそらく私に限らず、子供の頃は、この手の「誰かに負けたくない」という思いを抱きがちな時期なのではないかと思う。子供の頃に人間関係が悪くなったりするキッカケの一つには、常に敗北から来る嫉妬心がランクインしていたはず。

 

子供というのは思慮が浅い。例えば、自分と相手の生まれ持った才能の違いとか、育った環境の違いなどには目もくれない。ただ、今の自分と今目の前にいるライバルとの違いがあることを受け入れられず、負けたくないと強く思う。

 

この思いが良い方に転じれば自らの能力の向上につながるし、悪い方へ転じれば相手を陥れるセコいやつになってしまう。私は決して性善説を信じているわけではないが、少なくとも自分の経験では良い方に転じている人の方が多かった。というわけで、ライバルという存在は、実は自分の能力を高めるためのモチベーションとしての効力が高い。

 

ただ。会社に入って、ライバルと呼べる存在が身近にいるだろうか。

 

年齢を重ねると、人は人、自分は自分、という思考がかなり強くなる。これは幼少期とは逆で、相手の今ではなく、その人を取り巻く環境とか、その人の特性みたいな、自分ではコントロールできないところに原因を見出してしまうからである。

 

例えば、私はシステムエンジニアという仕事をしているが、このシステムエンジニアという仕事は文系の人間もかなりの割合を占めている。文系・未経験でもOKのIT企業はたくさんあるのだ。ただ、ちょっとした専門用語とか、サーバの操作とかは理系・情報系の人間の方が馴染みやすい。

 

さて、あなたが文系の人間だとして、理系の人間が例えばLinuxのサーバコマンドをバリバリ叩いたり、シェルスクリプトを作ったりできるところを見て何を感じるだろう。子供の頃なら、「なんであいつにできるのにおれにできないだ!おかしい!」と思う。しかし、大人になった今であれば、「あいつは理系でおれは文系だから能力に差があって当然だ」と考える。そういうことである。

 

もし、ライバルがいないと思うのであれば、自分が常に上記のような思考回路で他人を見ていないかを少し振り返ってみてもいいかもしれない。一番の原因が相手は相手、自分は自分と完全に切り離して考えてしまうことなのだ。

 

もう一つ原因があるとすると、社会人というのは学生の頃と違って、チームを構成するメンバの多様性が広がっているために、自分と相手との差をより明確に感じやすい、ということだ。

 

学生の頃に一緒につるむメンバは必ず、同じ学校とか同じ部活とか、生活の大部分を共有しており、かつ趣味嗜好も近いことがほとんど、そしてほぼ間違いなく同年代である。また、高校以降は能力の近いメンバが同じ学校に集まるようになる。類は友を呼ぶ、と言われるように、同類なのだ。共通点が8割ぐらいあるので、決定的な差を意識することは少ない。

 

社会人は背景も違うメンバの集まりだ。もちろん、思考パターンや行動特性など抽象的な共通点は多分にあるのだろうが、具体的な経験、興味・行動などは異なる。また、日本に強く根付いている年功序列の精神のせいで、先輩とか年上の人と対面すると、無条件に自分が下だと考えてしまうよう洗脳されている。

 

ライバルとはそもそも自分と同等相当の能力を持っている相手に対して定義される言葉なので、先輩に対してこの概念を当てはめることは難しい。ただ、それは先輩とは自分よりも経験があり自分よりも優れた存在だと勘違いしているからにすぎない。同様に、後輩が自分よりも経験が浅く自分よりも劣った存在だと勘違いしているからにすぎない。

 

確かに経験は大切である。長く経験を積んだ人へ敬意を持って接することも日本ではやはり大切だ。しかし、経験があるから自分より優秀、ということはない。ここは断言しておく。経験から何を学んだかが重要であり、経験を何に活かしているのかが重要なのだ。だから、なんかこの人に言われると腹立つな、と思う先輩をライバルとして考えてみてはどうだろう。

Webテストの数学攻略のコツ

最近、リクルートスーツに身を纏う学生を良く見かける。エントリーシートがどーたらこーたら。就活って8月からになったんじゃなかったっけ?面接が8月からだから就活準備としてはそろそろ本格始動という感じなのだろうか。

 

就活というと、エントリーシートの書き方はもちろん、Webテストという、日本の勉強しない大学生には頭を悩ます関門がある。中でも文系諸君は数学に苦しめられていたことだろう。私も数名の大学生のWebテストを手伝った記憶がある。

 

ただ、Webテストの問題自体はそれほど難しくはなく、ゆっくり考えれば誰でも(中学生ぐらいの知識があれば)解ける問題がほとんどである。つまり、難しいポイントは時間内に全ての問題を解くことなのだ。たぶんみんなそれをわかっているはずで、だからこそ数学のWebテストを受験する際は電卓を脇に置いて挑んだことだろう。

 

実は数学のWebテストにはコツがある。というよりも、そのコツを抑えることこそがWebテストで求められている能力だと私は理解していた。それは一言で言えば概算力であり、オーダーを把握することだ。そしてここがこれまでに私たちがやってきた数学のテストとは明らかに異なる点でもある。

 

例えば、こんな例題を考えてみよう。

 

問題

以下の表はとあるコンビニの過去3年間の売上である。 2011年において、ファーストフードの売上は、同年の売上総額のおよそ何%を占めているか。

項目2009年2010年2011年
ファーストフード 310 270 320
日配食品 150 170 140
加工食品 390 410 370
タバコ 170 210 200
文房具 270 260 260

 

[A] 14%

[B] 25%

[C] 36%

[D] 41%

[E] 50%

 

2011年の話なので、表の右端列の数字のみを見れば良いことはご理解頂けるだろう。ファーストフードが全体の何%かを問われているので、全体の売上額とファーストフードの売上額がわかれば解答が得られる。

 

まず、

全体の売上=ファーストフード+日配食品+加工食品+タバコ+文房具

     =320+140+370+200+260

     =1290

よって、

(ファーストフード/全体)×100=(320/1290)×100=24.806・・・[%]

したがって、正解は[B] 25%である。

 これが一般的な数学であれば模範解答である。Webテストの画面を見ながら必死で電卓を叩いてこのような計算を瞬時に導き出している人もきっといることだと察する。が、ことのほか、Webテストで上記のような解き方をするのはタブー中のタブーである。

 

私がこの問題を解くのであれば電卓は使いません(別に使ってもいいです)。頭の中で組み立てる計算式は、

3/(3+1+3+2+2+1+1)= 3/12 = 1/4

です。よって25%が正解であると導けます。

 

やったことは簡単です。合計値を出すときの100の位以下を全て無視して計算しただけです。すなわち概算、というわけです。上の例では、一応10の位が繰り上がる可能性を考慮して1を余分に足してますが、別に足さなくても結果には影響はありません。(3/11=27.27%)また、10の位を四捨五入してから足す、でも良いです。(ただ少し計算手順は複雑になるのでオススメはしません。)

 

なぜ概算でも解けるのか。これは概算でも解けるような選択肢になっているからです。もし、例題の解答の選択肢が下記の5択だったら概算で解くとほぼ不正解を引きます。

[A] 24%

[B] 25%

[C] 26%

[D] 27%

[E] 28%

 

 

ポイントになっているのはオーダー、スケールです。この問題の場合は、だいたい書く選択肢の差は概ね10%ぐらい開いています。つまり半分の5%ぐらいの差は無視しても良い、ということです。5%の差がどれほどなのか、を論理的に突き詰めようとすると難しいですが、この辺りは感覚です。

 

感覚がない人にはできないじゃないか。確かにできません。しかし、Webテストの数学、特に表問題は概算で解ける問題が多いことを理解しておくだけで十分です。まず、概算でやってみて答えが怪しかったらちゃんと計算する、とかでいいと思います。というよりも、全て正確な数値を算出しようとすると時間が足りません。問題が後半にさしかかってくると、5連立方程式を立てないと解けない、みたいな複雑度の問題も登場します。

 

あるいは、ネットに掲載されている数字も全く同じ問題が出ることを祈る、というのも現実的かもしれませんね。

仕事ができない先輩の、一言に非常に共感してしまった話

先日、私の目の前で繰り広げられる会話を小耳に挟んだ。

 

Aさん:

「この資料だとわかりづらいから修正しといて」

Bさん:

「また、修正するんですか?こういう資料の修正にどれだけ時間かかるかわかってます?だいたいあの人達(課長とか)が理解しようとしてないんじゃないですか!」

Aさん:

「でも、今のままだと課長にはわかりにくいよね?修正はしないと。」

Bさん:

「こんなことばっかりやってるから本当に大切な仕事ができなくてバグが出るんですよ!」

 

まだしばらくやりとりは続いていたが、内容としてはだいたいこんな感じである。ちなみにここで登場するBさん、というのが仕事ができない先輩である。

 

軽く補足をしておくと、仕事をする上で、お客さん向けとか上司向けの報告資料をその報告内容に合わせて作っているのだが、それを作ったり、わかりやすく整理することに時間を取られ過ぎて、本業であるシステム開発の仕事が疎かになっていることについてBさんは憤慨しているのだ。その結果バグが出て問題になる、と。

 

Bさんに問題がないわけではない、要領よく全てをこなしている(ように見える)人はいる。なので、この手の議論になってもBさんの主張はまともに受け入れられないことが多い。組織の中で仕事ができない(と思われている)と何をゆっても説得力が半減以下になってしまうのだ。

 

ただ、私はBさんの意見に共感した。というのも、私は報告資料には大した価値はなく、そこに膨大な時間をかけるのはバカバカしいと考えているからだ。確かに、ビジネスの現場では伝えることは非常に重要視されているし、実際伝えるべきことを誤ると、仕事が間違った方向に進んでしまうことは日常茶飯事だ。

 

また、たくさんのことを伝えすぎると、結局何が言いたいのかわかってもらえないことが多い。伝える上では要点に絞る必要もある。よって、相手に何かを伝える場合は、伝えるべき情報が正しいこと、その情報の中から重要度の高い情報を選定すること、さらにそれらが伝わりやすい可視化、そして伝わりやすい構成にすることが求められる。

 

お客さん向け資料ならここまでやるべきだし、ここまでやる必要はある。でも、上司に対してここまでやる必要あるのか?と私は常々思う。私たちと同じ立場で、私たち以上の収入をもらっているのに、一目で理解出来るような資料を私たちに望むのはいかがなものだろう。

 

理論的には情報さえ揃っていれば加工の問題であるので、部下が整理してまとめた内容を上司が作り上げることだってできるだろう。ん?上司は忙しいからそんな時間はない?じゃあその忙しい時間で一体どんな価値を創出しているのだろうか。それこそ部下が理解出来るように説明してほしいものだ。

 

例えば、上司の最も重要な役割の一つに、意思決定がある。ただし、意思決定が本当に決めるだけだと思っている人が多すぎる。

 

例えばこれから進むべき方向としての選択肢が三つある場合を想定しよう。優秀な人なら、選択肢とそれぞれの具体的なメリットやデメリット、それらの論拠がマトリクスに整理された状況で上司に見せて相談、という形になるのではなかろうか。部下としてはいい仕事のやり方なのかもしれない。

 

ただし、ここまで整理された上で意思決定をするのは、本当の意思決定ではない。そんなことは私でもできる。ただ承認しているだけだ。せめて、部下が出し切れていない観点をアドバイスする、とか別の方法を提案するなどがないなら、上司が存在する意味はない。

 

上司に求められているのは経験から来る大局観だと私は思う。大局観とは、将棋などでよく使われる言葉で、全体の状態から自分の形成が良いのか悪いのかを判断できる能力のことを言う。将棋が強い人はたいてい大局観を持っていると言われる。

 

大局観の特徴は、具体的な個別の論拠に基づいていないことだ。例えば、王の駒がこの位置にいるから今は優勢、とか成金が少ないから今劣勢、みたいな局所的な考え方ではなく、ただ盤面全体とかこれまでの流れから見て優勢、といったようにマクロ的考え方で判断する。

 

上司の意思決定もこうであるべきじゃないだろうか。なんでもかんでも部下に個別の状況を整理させて、それらの内容を積み上げさせて、その結果を統合して判断という仕方しかできないから意思決定が非常に遅くなる。将棋の世界でこんな意思決定の方法論ばかり使っていたらあっという間に持ち時間が無くなってしまう。

 

上司の大局観不足は、残業時間とも密接な関係がある。一度上司に何かを理解してもらうための稼働を計算してみる価値はあると思う。恐ろしく時間を取られているはずだ。一人当たりの時間はそこまでではないかもしれないが、階層構造の深い組織体制であれば、各人が抱える時間は膨大になる。

 

先に述べたように、上司の大局観が欠けているから個別の事象からデータを取り、積み上げ、そぎ落とし、それらの根拠を分析し、伝える必要が出てくる。メモで内容を伝えるだけで現状をわかってくれる上司とか、普段の働き方を観察する中で問題を検出出来る上司であれば、残業時間は圧倒的に少なくなるのだ。

 

大局観を持つために必要なことの一つは高いセンサーを持っていることだ。例えば、進捗報告資料上は問題無しとなっているが、全員が定常的に残業をしている、とかがわかりやすい例だ。こういった予兆に気づけないようであれば、マネージャーとしての意味はない。部下が問題だと認識していない部分を検知できなければ、部下と同じレベルの判断しかできないし、それでは上司としての存在価値はない。

人工知能とは

人工知能という言葉が最近また脚光を浴びだしているが、「ん?それって人工知能なのか?」と思う瞬間が多々ある。実は、人工知能という言葉の範囲は結構広いのだ。つまり、大したことない人工知能もめちゃくちゃ凄い人工知能も一口に人工知能という言葉で語られている。

 

例えば、OKGoogleやSiriなど、スマホに搭載されているアプリは人工知能が入っていると思う人もいるだろう。「〇〇への行き方を教えて」と聞けば、電車の乗り換え案内が表示されることは確かに凄いことではある。しかし、あれは単に、音声認識技術や字句解析技術が向上しただけであると私は思う。本質的には、特定の条件に対して特定の処理を実行する、という従来のプログラムの領域を超えていないように感じてしまう。

 

実際、これらの人工知能としては最も弱いAIだそうだ。物事を認識する力のみが人に近くなっているだけ、といったイメージである。これをAIと言われても正直あんまり腑に落ちない。

 

当然、ではお前の考える人工知能とは何なんだ?、という話になるだろう。その前に、従来のシステムやロボットにはできなくて人間にしかできないことが何なのか、について私の意見を述べたいと思う。

 

端的に言えば、演繹化と帰納化ができることである。例えば、私のやっているSEの仕事というのがまさにそれだ。プログラミングは既に自動化されつつあるが、SEの仕事がまだ自動化に至っていない最大の要因はここにある。

 

SEの仕事の本質は帰納化、すなわちお客さんの「こうしたい」を実現するための方法をプログラミング可能なレベルまで具体的にすることである。プログラマーは既に具体的になった手順書をプログラミング言語に翻訳していくだけの仕事である。(もちろん、実際にはSEの設計が悪く、プログラマーの試行錯誤が必要な場合が多いことも補足しておく。)

 

ちなみにSEに限らず、優秀な人間ほど、具体的な何かから抽象的な教訓を得たり、抽象的な教訓を具体的な別の事象に落とし込んだりするのが上手い、と個人的には思っている。 

 

例えば、プロのスポーツ選手に頭がいい人が多かったりするのも、学業で成果を出すための方法論と、スポーツで成果を出すための方法論には何らかの共通点があり、その共通点を意識できているからこそどちらも良い結果につなげることができる。実際、分野は違っても一流の人たちの考え方に共通点があることはよく知られた話である。

 

と、非常に前置きが長くなってしまったが、今まさに本当に注目されている人工知能というのが、この優秀な人間と同じようなことができるものを指す。すなわち、具体的な事象から抽象的な共通点を導き出し、その他の事例に適応できるのだ。

 

一つ、全世界に衝撃を与えたニュースとして、「猫を認識するAI」が少し前に開発されたのを覚えているだろうか。素人目にはSiriなど、人間らしく振る舞える方がすごいように見えるかもしれない。しかし、コンピュータが現実世界の概念を理解出来るというのは凄まじいことなのである。

 

すごい点は、ズバリ特徴量を抽出できる点である。

 

次の写真を見て欲しい。

f:id:n1dalap:20170302203218j:plain

 

この写真に写っているものが何かと問われれば、おそら誰でも”ネコ”と判別できる。ただ、この写真、このネコを見るのはほとんどの人は初めてのはずである。では、なぜ初めて見るものなのに、それが”ネコ”だとわかるかというと、それは私たちが”ネコ”という概念を理解しているからだ。

 

ネコの概念とは、簡単に言うと、ネコの特徴のことである。髭が3本ずつあって〜、小さめの動物で〜、色は白とかグレーとかベージュとか茶色とかマーブルとかで〜、耳が上についている〜。そんな生き物が”ネコ”なんだということを経験を通じて学んできたのだ。そして、私はネコの概念を学んだわけではなく、個体として存在している様々なネコを見る中で”ネコ”が何かを学んだのである。

 

そう、人間なら誰でも当たり前にやっていることを今までのコンピュータはできなかった。しかし、これからの人工知能はできるようになる。ちなみに膨大なデータを与えるだけで特徴量(概念)を自分で作り出すことができる技術がディープラーニングと呼ばれている。

 

これは画像に限った話ではない。例えば、同じGoogleが開発したAlpha Goという囲碁プログラムは強い棋士達の膨大な戦局データから強い囲碁の打ち方の特徴量を抽出しているからなのである。ネコの概念を理解するぐらいなら誰でもできるかもしれないが、良い戦術の概念や特徴を掴むのは人間なら誰でも、というわけにはいかない。

 

だから、人工知能は少し優秀ぐらいの人間であればあっさり超えてしまう可能性があり恐れられてる。ただ実際のところ、今はマシンの性能が追いついておらず、アルゴリズムであるソフトの技術は実用化されつつあるが、ハードウェアはまだまだ実用化できるレベルにはない。(例えば、ネコを理解するAIはCPU以上の性能を持つGPUを1000台ぐらい繋げて計算しなければ処理しきれないほどの計算量なのだ。)

 

今はまだ人間の方が低コストで利点があるから一安心だが、今後のためにも人工知能に何ができて何ができないのかぐらいは知っておいても損はないと思う。

 

 

 

ソリューションって何?

IT業界には横文字が蔓延っている。日本語で言えよ、てなるけど、みんなが当たり前に使っているのを日々聞いていると、いつのまにか自分も普通に使うようになる。でも、こういう言葉ってだいたい雰囲気で使われてるし、雰囲気で使ってしまいがち。

 

例えば、ITビジネスの中で「ソリューション」という言葉がしばしば使われる。直訳すれば解決策なので、なんとなく問題を解決するための方法、ぐらいのことは誰だってわかるとは思う。

 

じゃあソリューションビジネスとは何なのか。さっきの延長で考えれば、「解決策をお客さんに提案することで利益を得る仕事」のことだろう。もちろん、それはそれで間違ってはいないと思う。ただこれは、「カラスとは何ですか?」と聞かれて、「生き物です。」と答えているようなものだ。

 

例えば、ソリューションビジネスというものをもう少し具体的にイメージしてみる。例えば、お客さんが自分たちの商品を全世界に向けて販売したいと思っているけど、そういった物流ルートの確保が難しい、という状況だとする。

 

この場合の、解決策、ITソリューションの一つはオンラインショッピングサイトの構築ということになる。あー確かにーなるほどーと思うかもしれないが、これは単なるSI、システム開発である。

 

あるいは、お客さんが会計業務を効率化したいと考えているけど、どうしたらよいかわからない場合、一つのITソリューションは会計ソフトの販売である。でもこれはこれで単なるソフトウェアパッケージの販売とも言える。

 

以上を踏まえると、ソリューションというのはSIとかソフトウェアパッケージとかそういうものをもろもろ包含するビジネスのことを指しているのだろう。概念の関係としてはソリューション>SI>ソフトウェアパッケージだ。

 

教育などに喩えて考えてみるとわかりやすいかもしれない。

 

学力を上げたい人のために教科書を販売するのがソフトウェアパッケージ販売。活用の仕方とかは使う人次第、効果を大きくさせるかどうかも本人次第である。ユーザが目的達成のために活用することができるものを販売している。よって、他に必要なものもあり、それらを別で揃える必要があることも多い。

 

教科書・問題集・ノート・シャーペンなどを組み合わせたり、オリジナルの参考資料とかを作ってセット販売を行うのがSI。ユーザが活用方法を考える必要はほとんどなく、カスタマイズの余地もほとんどない。下手にカスタマイズすると効果が下がる可能性すらある。

 

そして、教材から効果の高い教育カリキュラムまでを提供するのがソリューション。効果の高い教材の活用方法を教えたりするところにSIやパッケージ販売にはなかった価値があるのだと思う。

 

ちゃんと知っている人がいたら教えて欲しい。

SIerは残業を減らせるのか

SIerの平均残業時間は月50時間ぐらいだと言われています。これはあくまでも平均の数値であって、会社の規模とか、プロジェクトの工程や状況、開発か維持かといった役割などにかなり左右されるのも事実です。まぁ、私個人としては数年の平均残業時間もだいたい月40〜50時間ぐらいなので間違った数値ではないと思います。

 

で、この残業時間って多いの?少ないの?って話ですが。同じ業界にいる人、特に上の世代の人から見ると少なめです。過労死のボーダーと言われている月80時間残業の半分ちょっとしかありませんし。

 

うん。この感覚が多分問題なんですよね。

 

私ずっと思ってるんですけどね、一度何らかのシステム開発プロジェクトが終わったら、必ず原価にの計画値に対して実績値がどれくらいだったのか、を振り返ることがあるはずなんですよ。システム開発の原価、中でも人件費は工数で算出されます。例えば30人が10ヶ月やってできるなら300人月なので、そこに単価を掛けた値が人件費でとなります。

 

一般的には1人月は20人日で、1人日は7.5人時として計算されているはずです。よって、もし残業時間が発生している場合、その残業した時間分だけ原価が増しているはずなんです。仮にメンバ全員が月50時間残業していたならば、30人×500時間=1500人時なので、1500÷7.5÷20=10人月分だけ原価が増えていることになります。よって見積が誤っていたと判断できるはずです。

 

であれば、次回開発時の見積の数値はこの反省点を踏まえた見積金額となっていなければおかしいですよね。単純に考えたとしても、50kステップのシステムが300人月でできると思っていたところが310人月かかったのであれば、次100kステップのシステムが600人月では終わらない、620人月はかかると考えるべきです。

 

つまり、何が言いたいのかというと、SIerは開発の経験値が蓄積されればされるほど、残業時間はなくなっていくはずだ、ということです。でもそうはならず、残業が状態かしている職場がほとんどではないでしょうか。これはいったいなぜなんでしょう。

 

考えられる要因は三つです。反省していない、楽観視、見積金額高騰の回避、です。

 

そもそも、見積金額の妥当性を振り返っていない、という組織は十分にあると思います。実を言うと、私の組織もやっていないんじゃないかと思います。というのも各工程の生産性とかは未だに数年前の数値を使ってたりしますし、誰かが開発完了時に生産性を計算しているのかもしれませんが、現場レベルの人間は全く意識していません。

 

また、プロジェクトとして黒字になればOKとか原価率このぐらいであればOKみたいな基準さえクリアされると、一切問題分析がされない可能性もあります。システム開発の場合は、原価の中にリスク費と呼ばれる、想定外の問題が起きた場合に対処するためのコストが積まれるものですが、残業によるコストもこのリスク費で吸収できれば問題がなかったと見なされてしまいかねません。成功したにしろ失敗したにしろ過去はちゃんと振り返るべきですね。

 

次が楽観視です。プロジェクトは一つとして同じものはありません。プログラムの規模だけで工数が決まるわけではなく、そのプロジェクトの特性とか、環境・要員のスキルなど、様々な特性を考慮して決める必要があります。過去の類似プロジェクトを参考にはできますが、その値をそのまま使えるということはほとんどないのです。

 

すると、ありがちなのが、過去のプロジェクトの生産性を基に考えした上で、「今回は有識者が多いからこのぐらい生産性が上がるだろう」とか「今回は開発の難易度が過去よりも低いからこのぐらいの期間でいけるだろう」みたいな意見がでます。そして、この場合に語られる「このぐらい」という数値には何の根拠もありません。

 

単なる楽観視です。この楽観視が原因で、簡単だと思われたプロジェクトも常にみんな忙しそうにしている光景はよく見受けられます。PMなどのポジションの方は安易に数値を変更してチームメンバを苦しめない様にしましょう。

 

最後の理由は、上記の2つを引き起こす原因ともなっている、見積高騰の回避です。

 

知っている人もいると思いますけど、システム開発費って、めちゃくちゃ高いんです。下っ端1人1ヶ月雇うだけで100万近くします。例えば、私が先日作ったAndroidのアプリですけど、あれをSIerに発注して作ってもらうと、たぶん500万ぐらいはかかると思います。本気です。

 

なぜそんなに高くなってしまうのかは、オーダーメイドとか多重下請構造とかいろいろ理由はあります。が、とにかく素人の方が直感でイメージするよりはるかに高い、ということです。

 

ただでさえ高いのに、10人月増えるということはさらに1000万円高くなる、ということです。無理です。そんな額をお客さんに提示したら受注できません。営業に怒られます。見積もり精査という名の、リスク許容、残業容認の末、受注を勝ち取っているのです。

 

つまり、今のSIerの働き方では残業減らせないよね。

あなたがやっているのは「設計」ではなく「仕様決定」です

今日は中々ノッてるので、3本目のエントリ突入。

 

テーマはシステム開発における仕様と設計の違いについて。私が業務系エンジニアから基盤系エンジニアに泣く泣くシフトチェンジした一つの大きな理由も、この仕様と設計の違いに関連しています。

 

仕様と設計の違い。それは端的に言えば「どうなるか」を定めたものが仕様、「どうするか」を定めたものが設計です。単純にログイン機能を例にとって説明しましょう。下記が仕様です。

 

ログイン画面にてユーザ名とパスワードを入力して、ログオンボタンを押下した場合、

  • ユーザ名とパスワードの組み合わせが正しければトップページ画面へ遷移
  • ユーザ名とパスワードの組み合わせが誤っていればエラー画面へ遷移

 

仕様から読み取れるのはあるべき動作であり、特定の条件下における処理の結果です。そして、これらはSEがお客さんと一緒に考え、合意した上で決めるものです。では、この仕様からプログラムを作ることはできるでしょうか。

 

もちろん、できる人もいるでしょう。しかし、これだけの情報からプログラムを作れる人は設計ができる人です。仕様をプログラムへ落とし込むためには、データ(およびその格納先)とロジック(条件分岐や順序)、そしてそれらの連携方法を考える必要があります。

 

上記のログオン画面を設計するには下記のようなことを考える必要があります。

  • ユーザ名とアカウント名を保存するためのデータベース・マスタ情報の定義
  • 各データの型(数字なのか英文字なのか真偽値なのか)
  • ログオン画面レイアウトの設計
  • ユーザ名・アカウント名を入力するための入力フォームの配置
  • ログオンボタンの配置
  • 入力フォームで受け取った情報からデータベースの値を取得するSQL
  • SQL文で取得した情報と入力情報をチェックする処理
  • チェック結果に応じて遷移先の画面を切り替えるロジック
  • トップページおよびエラー画面のレイアウト

などなど。今は順序性も考えず箇条書きで、かつパッと思いついたものしか書いていませんが、それでも仕様と設計では考えるべき項目の数が全然違うことがお分かりいただけるでしょう。さらに仕様を満たす最適な設計を考えるのはさらにハードルが上がります。それが面白いところでもあるんですけど。

 

私は業務系のエンジニアはこういうことを考える仕事だと思っていたんですよ。いや、実際こういうことをやっているエンジニアの方もたくさんいらっしゃると思うんです。でもITゼネコンの上の方に位置する会社がやるのは大抵仕様を決めるところまでなんですよね。

 

要するに設計してないんです。お客さんと調整して、仕様という名のゴールを決めるのがメイン。そのくせ、「あれはおれが設計した」みたいなこと言ってる人もいます。いやいや、あんたは仕様決めただけでしょ〜って。

 

ただそうならざるを得ない理由もあって。一つはお客さんと調整するのは結構ハードな仕事だということです。仕様を合意するためにはその仕様が最も良いという合理的な理由が必要です。そのために、あらゆる調査をして、あらゆる資料を作って説明をしに行かなければならない。規模にもよりますが、多くても数ヶ月ぐらいの期間内に収める必要があります。

 

もう一つの理由は、既に既存システムが運用されている場合です。要するに機能追加開発のことですが、0からのシステム開発でない場合、既存の機能の流用で済ませられる場合が多いです。

 

0からシステムを作るのは結構リスクがあります。一般的には、過去の類似プロジェクトの機能や処理を参考にプログラム規模や工数は見積もられますが、新規システムの場合は作ったことがないので、工数見積の精度がどうしても落ちてしまいます。なので、精度誤差分を踏まえてバッファを積むことになります。

 

加えて、前例のないことをやると、必ず想定外の問題にぶち当たりますから、問題が起こった場合のことを考えて、バッファを積むことになります。さらに問題の影響度も見切りにくいため、機能追加開発に比べてその割合は多くなるでしょう。

 

すると、どうなるかというと、お客さんへ提示する価格がめちゃくちゃ高額になってしまうわけです。すると、案件が受注できない。営業から怒られる。じゃあどうやって安くするかというと、最も代表的な手法として、既存システムをうまく流用することを考えるのです。

 

既存のものを活用した方が効率的に良いものを生み出せるので、これは会社としては全く悪いことではありません。ただ問題なのは、こういったやり方では、SEが本当の設計をする機会はない、ということです。

 

例えば、家を新築で建てるのも同じですよね。似たような家が既にあれば、その設計図を流用した方が早く作れる。でもそれはつまり、家全体の設計というフェーズをすっ飛ばしているということです。

 

うちの会社では近年開発力の低下が叫ばれていますが、ほとんどの社員が設計という設計をしていないのだから無理もありません。さっき言ったように、仕様を決めることを設計だと勘違いしている人さえいる次第です。

 

実際、今振り返ってみても、自分がやってきたことのほとんどはただの決め事でしかなく、既に出来上がった既存システムの枠組みに新しいデータを追加しただけ、という感じが拭い去れません。いと悲しや。

 

もちろん、SEとして働いていれば、今動いているシステムの設計を勉強することはできます。でも設計図の内容を把握したいからではなく、設計をしたいからSEになっているはずですよね。設計を理解していくことと、実際に設計することに圧倒的な違いがあることはアプリ開発を通じて実感しました。なので、次やるなら是非とも新規開発がいいですね。

 

正直、今の担当で業務系エンジニアをやっていても何の専門性も身につかないだろうなと思いました。(先輩や同期に聞いても、業務知識は身についたけど、設計スキルは身についていないと感じている人がほとんど。)確かに業務知識はつきましたが、金融みたいに大きな業界ならともかく、ニッチな業界相手だと汎用性が低すぎてエンジニアとしての価値はあんまり発揮できないでしょう。

 

私は、それが嫌で嫌で仕方なく、基盤系エンジニアになったというわけです。もうしばらくしたら、基盤系エンジニアが何たるかも書き連ねたいと思います。

クーラーシェアリング

私は「時を指定されたタスク」が嫌いである。時を指定されたタスクとは、「15時〜16時の間にこの書類を完成させてください」みたいな仕事のことだ。簡単にいえば、予定を入れたり、予約というのが嫌いなのだ。

 

ちなみにタスクとは言ったが、これは公私を問わない。極端な話、「8/1にバーベキューをやります」、みたいなのも嫌いだ。特に、前もって先の予定を決めるのが嫌いなのである。なぜなら、直前になって行きたくなくなることが往々にしてあるからだ。

 

その中でも、待機を強要される仕事が最も嫌いである。例えば、郵便物の受け取りなどは、受け取り自体には1分とかからないにも関わらず、午前中に届けますとか、13時〜15時の間に届けます、みたいなことを平気で言っている。そこに合わせて家で待機するというのは、自分の行動が非常に制限されている気がしてならない。

 

少し別の事例として、公共機関での移動も同じ話だ。移動時間中は行動に制限を受ける。もちろん、読書とか音楽聞いたりできるからいいじゃん、みたいに考える人もいると思う。さっきの郵便物の話でも家でできることやってればいいじゃん、という意見もあるだろう。

 

でも、つまりはそれが行動が制限されているということなのだ。例えば、郵便物を待っている最中に小腹がすいた、と思ってもコンビニには行けない、ということになる。電車の中で用を足したいと思ってもトイレには行けない、ということだ。やりたいことはできるが、その時一番やりたいことはできない、ということである。

 

そういう意味で、宅配ボックスというのはネットショッピングの亡者である私にとっては実に素晴らしいサービスである。宅配ボックスがついている家に住んでからこの手の煩わしさからはほとんど完全に解放された。

 

ただし、全ての荷物が無人で受け取れるわけではない、というのが今の宅配ボックスの残念なところでもある。

 

最も社会的にも課題だと感じているのが、ネットスーパーでの買い物である。実はネットスーパーでの購入品は、宅配ボックスに届けることができないのである。おそらく、食材とか生物を常温の空間に置き去りにすることは衛生面から許可されていないのだろう。ただ、私はこの宅配ボックスに届けられない、という理由でネットスーパーは最後まで利用しなかった。

 

もともと、ネットスーパーは普段は忙しくて買い物に行けない人、すなわち主婦以外の層がネットを通じて買い物をしてくるような企みで開始されたサービスだった。しかし、結果は真逆で、既に買い物に行っていた主婦たちがそのままネットを利用するようになった、という話を聞いたことがある。

 

そもそも主婦は基本的に家にいるので、この家での受け取りに煩わしさを感じる人は少ないのかもしれない。ただ、ネットスーパーが本当に忙しくて買い物に行けない人向けにサービスを展開したいのであれば、無人受け取りの仕組みも必要だと思う。

 

こう考えると、一つの選択肢として、宅配冷蔵庫というサービスはあってもいいと思う。マンションや団地に導入してもらう。ネットスーパーと提携して、生物はそれぞれの冷蔵ボックスに入れてもらう。今風に「クーラーシェアリング」とでも名付けてみて。住民から月額数百円とかでできれば最高だ。

 

ネットで調べた感じだとまだ誰もやってなさそうだけど、こういうアイデアもちょっとアリなんじゃなかろうか。