SIerは残業を減らせるのか

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

クーラーシェアリング

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

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

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

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

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

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

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

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

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

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

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

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

日本で画期的なサービスが生まれないワケ

Amazonがまた新しいサービスをリリースするようです。ネットの覇者だったアマゾンですが、今回はリアル店舗でのサービス。動画を見ればどういうサービスなのかはだいたい見当がつくでしょう。

youtube

UX（ユーザエクスペリエンス）という言葉の象徴とも言えるサービスですね。今まで買い物といえば、買い物かごに自分が欲しいものを入れて、レジに並んで精算する、というスタイルが主流でした。

もちろん、これまでも、様々なシステムが導入されレジ業務は改善されていました。例えば、POSシステムというのも今ではほとんどのレジで採用されていますし、セルフレジなる買う人が自分で精算する仕組みもありますし、精算機をレジと分類することによって作業効率を高めるといった仕組みもあります。

ですが、基本的に買い物の中で「レジ業務」というものは効率的にはなったものの、店員もしくは購入者、すなわち人間がやらなければならない業務として残っていたのも事実です。しかし、Amazon goは買い物の中からレジ業務を完全に排除しました。

背景として、IT技術の進歩があったのは言うまでもありません。センサーの高精度化、画像認識技術の向上によって、誰が何を買い物かごに入れたのかを正確に検知することができれば、システムがリアルタイムでレジ打ちすることが可能です。なので、ゲートを潜り抜けさえすれば勝手に決済が済んでしまう。非常に画期的だと思います。

ここで疑問になるのはどうして日本人はこんな発想ができないのだろう、ということです。日本人のクリエイティビティが足りないからでしょうか。

個人的には、日本人の中にもこのような発想をしている人はきっといたのだと思います。ただ、日本人の場合、画期的なサービスを思いついたとしても、そのサービスを導入した場合の弊害とか導入した結果付随する問題にすぐに着目しがちです。

あなたは、このAmazon goというサービスを見て、何を思ったでしょう。すげえサービスだ、と思った反面、でもこれで上手く機能するのか？とも思ったんじゃないでしょうか。

例として、私が思いついた問題点をいくつか挙げてみます。

• 事業性があるのか（この技術の導入コストより削減可能な要員コストの方が大きいのか）
• 本当に正しく認識されるのか（カメラの死角だと認識されないあるいは誤認識されるのではないか）
• 残高を超える額の買い物をした人がゲートから出た時に請求はどうなるのか
• いくら使ったかわかるのか
• そもそもお客さんはやってくるのか（ネットで済ませるんじゃ？）

上はほんの一部です。こんな風に新しい仕組みを導入すると必ず問題点が上がります。で、日本の会社だと特に、この想定される問題についてどう対処する予定なのかを事前に深く検討させられます。そして、その障害をクリアできないと、まず可決されません。

日本人はリスクをとにかく避けようとする人種です。なので、事前に懸念が思い浮かぶのであれば、それに対し万全の対策を打った上でしか新しいことを始められません。しかし、アメリカはリスクに対し寛容です。とりあえずやってみて、もし問題が起こったらその時に考える、というスタンスです。（このあたらいはUAI指標という形に表れています。）

今回のAmazon goも、まずシアトルで検証も兼ねてやってみる、というスタンスなのだと思います。ただ、こういう取り組みはマーケティング的にも非常に重要だし、本当の問題が何かを知るためにも良いと思います。日本企業も海外で生まれたサービス自体だけでなく、こういう姿勢を是非マネしてほしいですね。

一億総クリエイター時代の幕開け

ここ数年でヒットしているITサービスは、生産活動を促進する仕組みが非常に多くなってきている、と私は考えています。一億総クリエイター時代に本格的に突入しつつある、というのが正直な感想です。

ここで言っている生産活動とは、「何かをアウトプットする」ことです。それは知識なり、作品なり、サービスのことです。例えば、今私が書いているブログも生産活動だし、Youtubeに動画をアップロードするのも生産活動です。音楽を演奏するのも生産活動です。しかし、読書とか映画鑑賞とかは生産活動ではなく、消費です。食事も消費です。おわかりいただけるでしょうか。

そもそも兆候としては、カメラ付きケータイの大ブレイク時代からあったのでしょう。確かに当時カメラ付き携帯が流行ったのは、思い出を手軽に残せるのが良かったからだったのかもしれません。しかし、今はどうでしょうね。

例えば、風景だけの写真を撮る人がいます。そんな写真ならネットに同じものがあるやないか、と言いたいところですが、これも本当の価値は、「自分がその場で撮影したこと」にあると思うんですよ。で、自分の手で撮影した風景だからそれは生産活動なんです。

今インスタグラムとかにアップロードされる写真も結構拘ってる人が多いですよね。あれも自分ならではの撮影、ようするに作品としてネットにアップロードしているわけなんです。もちろん、そういう活動が盛んになったのはインスタグラムの影響でしょうが、既に人々の潜在的なニーズとして「何かを生み出したい」というものがあったのでしょう。

ブログやYoutubeが流行ったのも全く同じ理由です。アップされる動画が面白い、というのは結果的に生まれた価値であり、動画を作ってアップすること自体に喜びを感じる人がいたから急成長したプラットフォームです。

そして、最近のITトレンドの一つであるシェアリングエコノミーというのは、本質的には、今まで無駄になっていた価値を、その価値を必要とする人とリアルタイムでマッチングするサービスです。が、これは個人の行動領域が、趣味のしての生産活動からビジネスとしての生産活動に変化している兆しでもあります。

ブログやYoutubeも元々は収益を期待して投稿する人はさほど多くなかったと思いますが、ブロガーやYouTuberなどとして、個人として稼ぐためのプラットフォームへすっかりと変貌しています。

ある意味、今なお人気のあるソーシャルゲームのアプリなども、自分だけの最強のキャラを作っている、みたいな意味では生産活動に近いのかもしれません。個人的には、ゲームを生産活動に分類する気はありませんが、一時期レアなカードを現金で取引されることが問題となったように、ゲームの中に閉じれば価値あるものと言えます。

こんなふうに、今、消費者は単なる消費者ではなくなろうとしています。さらに、「趣味で生産する」から「生産してビジネスにする」人が増えています。その理由は、世の中がすごく便利になったから、そして場としてのサービスが整ったからです。

例えば、ショッピングといえば昔は娯楽の一つだったと思います。私も高校生ぐらいまでは服を買いに出かけたりするのが好きでした。でも、今はほとんどショッピングに行くことはありません。ほぼ全てネットショッピングで済ませます。

なぜならば、ネットの方が在庫も多いし、種類も多い。しかもレコメンドまでしてくれる。決済も簡単だし、店員との無駄なやり取りが必要ない。さらに、決定的なのが、いつでもどこでも変える。ネットショッピングの方が明らかに合理的なんです。

ゲームも同じです。昔は家に帰ってから数時間だけしかできない環境でした。また友達を家に呼んだりしなければ、複数人で遊ぶことはできなかったはずです。でも、今はいつでも、どこでも、誰とでもできます。しかもほとんどのスマホアプリであれば無料で色んなゲームを遊ぶことができます。

でもこれ、俗に言う不便益が損なわれた状態です。いつでも、どこでも、だれとでもできるようになったことで、それ自体の価値が薄まってきているんですね。たぶん、電話とかも同じです。今の私たちにとっては電話とはただの連絡手段でしかありませんが、私たちより一世代前の人たちは、「電話」という行為自体が娯楽のようなものに感じていたんじゃないかと思います。

つまり、これまでの消費活動が徐々につまらないものになってきた最中、現れたのが生産活動を公表できる場としてのサービスの登場、そして、自分のリソースをて提供することで収益を得られる場としてのサービスの登場です。消費への飽きと生産ハードルの低下が個人の生産活動を促進しているんです。

と、ここまでは、消費者についての話でしたが、実は労働の現場でも同じようなことが起こっています。労働は基本的に何かを生産する活動ですが、生産するもの自体が事務的なものからアーティスティックなものへと変わってきています。

例えば、単純な事務処理とかは既に業務システムに置き換えられていますが、さらに今後は人工知能の発達により、コールセンターの受付業務など、やや高度ではあるが単純、といった作業もどんどん無くなっていきます。よって、人間の仕事はより創造的でクリエイティブなものにならざるを得ないのです。

まとめると、消費者の消費活動はより創造的になり、労働者の生産活動もより創造的になっていくということで、これすなわち一億総クリエイター時代ということです。もし、何の創造活動もしていないとしたらこの先の時代に置いていかれますよ。

こんな上司や先輩には気をつけろ

あなたは一緒に仕事をする自分の先輩や上司に何を望むだろうか。 的確に指示を出して欲しいとか、ある程度自分に任せて欲しいとか、人によりけりだとは思う。

ただ、残念なことに部下の期待が様々であるように、上司の特性も当然様々である。そして、組織に入る以上は上司や先輩のタイプを自ら選ぶことはできない。そもそも自分にはどういう先輩や上司が向いているのかさえよくわからない、といった人もいるのではないだろうか。

個人的には、何のための仕事で、どんな成果物を作る必要があるのか、そしてインプットとなる情報は何かさえ教えてもらえれば、後はあんまり干渉されたくないと思っている。要するに「裁量」があった方が良いということだ。

ただ、自分の上司は裁量を与えるタイプなのか与えないタイプなのか、という一つの軸だけで考えていると、仕事を進める上で面倒になることも多い。そこで、私は「裁量を与える」という状態を少し掘り下げて「指示」と「決定権」の二つの観点から下記のような上司の分類を考えてみた。

上司タイプ

	指示が曖昧	指示が的確
決定権を委ねる	Aタイプ	Bタイプ
決定権を握る	Cタイプ	Dタイプ

上の表において、左上（Aタイプ）がもっとも裁量があり、右下（Dタイプ）へ行くほど裁量が小さい。なので、「裁量」という一つの軸で考えてしまうと、ほとんどの人はAかDの二択で分類してしまっているのでは？というのが私の仮説である。追ってそれぞれのタイプを説明しよう。

▪️最も自由なAタイプ

まず、わかりやすいAタイプとDタイプから。Aタイプの上司を持つと、最も自由に仕事ができる。反面、あまり能力がない人がこの上司にぶつかると、「何をやればいいかわからない状態」になる。ただ、始めからAタイプの上司や先輩のもとで働くことはない、と断言しても良い。もしそんな先輩がいるとしたら監督能力ゼロの無能社員である。

Aタイプの振る舞いは基本的に部下の能力を評価、信頼していなければできない。部下にとって、先輩や上司をAタイプへ変貌させることが一つのゴールだと私は思う。

課長とか部長クラスの立場の離れた上司はだいたいこうで、細かい指示も出さなければ、成果物も細かくチェックしない。なぜなら、あなたと課長の間にいる先輩が何とかすると考えているからだ。逆にいうと、あなたの仕事の価値を高める上ではあまり助けにはならない、ということでもある。

▪️家庭教師Dタイプ

Dタイプの上司は最も不自由である。仕事のやり方も決めつけられ、わからないことがあったら、すぐ報告・相談を求められる。試行錯誤の余地も小さく、ただただ自分が作業員でしかないと痛感させられるだろう。

ただ、このタイプの先輩や上司も基本的には存在しない。せいぜい会社に入って数ヶ月の新入社員期間限定で現れたりするぐらいだ。誰にもメリットがないので、もしこんな先輩に付きまとわれているなら、さっさと仕事を覚えて信頼を勝ち取ろう。

▪️実は最も理想的なBタイプ

Bタイプの先輩を持つと仕事がやりやすい、と個人的には思っている。要点については的確な指示を出し、あとは任せてもらえる。先輩としては、重要な点は伝えてあるので、その部分の要件さえクリアしていれば、多少プロセスや成果物に問題があっても大きな仕事の後戻りにはならない。

仕事を受け取る側としても、何をやらなければならないかの全体像は把握しやすいので、何から始めて良いかわからない、といった状態にはならない。その上、細かい部分については自分で考えたり、調査したりと工夫を凝らす余地がある。

これがあるかないかで、本人がやっているものが「作業」なのか「仕事」なのかのモチベーションにもつながると思う。Aタイプに比べると自由度は劣るが、正解らしきものが欲しい人にとっては最も理想となる上司だと思う。ただ、こういう上司や先輩も絶対数としてはそれほど多くない。

▪️要注意のCタイプ

Cタイプが最も危険である。このタイプの上司を持った部下は苦労する。指示は曖昧だが、決定権は持ちたがるタイプである。指示の抽象度だけではかれば裁量を与えてくれているように勘違いしてしまうが、決定権を委ねているわけではないので、実際には裁量は小さい。

例えば、Cタイプの先輩を持つとこんな問題が発生する。

Cタイプの先輩：「ここのプログラムの再試験やっといて。前にやった試験項目があるから参考に。」

私：「了解です。」

試験完了から数日後…

Cタイプの先輩：「この間の試験項目間違ってない？」

私：「参考にした過去の試験項目と同じです。」

Cタイプの先輩：「じゃあその部分直してもう一回やり直そうか。」

私：「はい…。」

Cタイプの先輩：「あと、ここの手順もこういうやり方の方が良いと思うから修正しといて。」

私：「…」

こんな風に裁量があるつもりで行動する、と手戻りが発生する。だからこそ、事前に細部まで確認合意しておくことが求められる。スコープは？品質のレベルは？参考資料の妥当性の確認方法は？いつまでに？などなど。あとは作業途中で段階的にチェックしてもらう、というのも一つである。これも手戻りを防ぐ方法ではある。が、こういった仕事のやり方は非常に窮屈に感じるので、対策を打つか打たないかは自由意志に任せるとする。

ーーーーー

もう一度、上司タイプを見返して欲しい。実は上司のタイプはあなたの行動によって変えられるものと変えられないものがある。指示の的確さはあなたが成長すれば曖昧になっていく。逆にあなたの理解度が浅いと感じたら、かなり的確に指示を出してくる。

しかしながら、先輩や上司が持つ決定権についてはあなたの行動で変えることは難しい。というのも、先輩や上司の役職・権限などに依存する部分が大きいからだ。また、生まれもった性格によって、自分で決めたい、人に決めてもらいたい、などの価値観にも依存する。

よって、必然的にあなたが成長すると、あなたの上司はAタイプかCタイプということになるだろう。だからこそ、Cタイプへの対処法は早めに理解しておくことをお勧めする。

「作る」と「売る」の壁

自作のアプリを開発して、1ヶ月が経った。気になるダウンロード数であるが、漸く二桁に突入、といったところである。アクティブユーザはその半分ぐらいしかいない。わかってはいたが、「売る」というのは相当に難しい行為である。

とりあえず宣伝。

インストールはこちらから↓↓↓

まず、第一の壁は「認知」である。既にAndroidには100万以上のアプリが存在するが、この中に一つのアプリが追加されたからと言って、誰が気づくのだろうか。検索でヒットするところまでが遠い。

特に、個人や無名の会社ではプロモーションの手段がない。例えば、各種メディアで取り上げられれば認知度は上がるが、お金もかかる。一応アプリを公開して少し経つと、アプリ紹介会社のページに掲載されたりはするんだけど、ほぼ全ての新着アプリを紹介しているから他との差別化にはならない。

直接Gmailを送ってくる海外の会社とかもあって、たぶん有料プランに入れば優遇して紹介しますよ的なことを英語で提案してきたりはするので、結局良いプロモーションをするにはお金が必要ってことらしい。

本ブログがもう少しメディアとして機能するものであれば良かったが、到底そんなレベルではない。なので、タダでできる事というと、ASOぐらいの方法論に落ち着く。アプリストアには検索エンジンでのSEOならぬ、ASOという考え方がある。なるべく、アプリを上位に表示させるためのテクニックだと思ってもらえればいい。最も簡単な例としては、検索されやすいワードを説明やタイトルの中に含める、といったものだ。

しかし、もちろんこれも単純ではない。検索されやすいワード、というのは多くのアプリに含まれており、レッドオーシャン状態なのだ。結局ASOの効果を生みにくい。だから、私は「WBS」というキーワードで押している。そもそものコンセプトがWBSであったし、プロジェクト型の仕事をしている人ならば、そのワードで検索する可能性は十分にあると考えたからだ。

実際、「ToDo」や「タスク管理」などで検索しても、私のアプリは検索結果に表示すらされないが、「WBS」で検索すれば、上から数えて6番目ぐらいには表示される。実際インストールした人が存在しているのは、このブルーオーシャン戦略の功績ではないだろうか。ただ、どのくらいの数の人が検索しているのかがわからないので確かなことは言えない。

次は、認知の先、「インストール」の壁である。今時点で、少なくとも、私のアプリのページにたどり着いた人は70人程度存在する。（これはGoogle Play Developer Consoleという、アプリを公開するために使う管理ページから確認できる。）ただ、インストールまで至っているのは、たった10人ちょっとなのだ。しかも全世界で。

これには様々な仮説が立てられる。

1. イメージしていたものと違った。ワールドビジネスサテライト（WBS）のアプリを求めていた、とか。
2. 画像のサンプルが日本語だった。海外の人が見つけたが、日本語だったので断念した、など。
3. 「〇〇万ダウンロード」みたいな表示がなく、使う気を削がれた。
4. 機能が不十分だと感じた。
5. 使い方がわからなかった。

　　　：

　　　：

キリがない。ただ、個人的には無料なんだからとりあえずインストールしてみては？と思ってしまうのだけど、このあたりは庶民の感覚とずれているのだろうか。信頼できないアプリを入れてスマホがバグるのを恐れているとか、そもそもよくわからないものはインストールしたくない、みたいな考え方があるのかもしれない。UAI指数の高い日本人にはありそうな話ではある。このあたりは分析のためのデータが少なくて検討が難しい。

インストールしてもらった後も、まだまだ壁はある。次の壁は、「継続利用」の壁だ。たとえインストールされても、使ってもらえなければ意味はない。最悪の場合、アンインストールされる。冒頭で述べた「アクティブユーザが半分しかいない」というのは半分ぐらいが既にアンインストールしてしまったという意味である。

ただ、この原因については大方予想はついている。実は開発したアプリがインストールやアンインストールされると、そのアカウントの国籍や、Androidバージョンなどの情報が開発者にはわかるようになっている。その結果によると、面白いことにアンインストールしたのは全て海外の人であった。

私のアプリは日本人以外が閲覧すると、タイトルや説明文は全て英語で表記されるようになっている。グローバリゼーションへの対応はASOの基本でもある。しかし、肝心のアプリ本体は全て日本語での表記となっている。

なるべく、言語要素を無くした設計にしたが、それでも知らない言語が出てくると、使いたくなくなってしまうのだろう。よく、中国のアプリとかで、説明はギリ日本語なのでとりあえずインストールしてみたが、中身は全て中国語だと気づいた瞬間に私がアンインストールするのときっと同じだ。ただ、このあたりは対策の余地が残っている気がする。

ここまででもかなりやる気が失せてしまうが、最後の「課金」の壁が残っている。ちなみに私のアプリは現時点では課金の仕組みそのものがない。「売る」ことを全く視野に入れていないのだ。だから、なぜ課金してもらえないかを考えるための材料すらないし、「売る」ために必要な基盤さえ揃っていない。ただ、壁としては存在している、その点についてだけここでは言及しておく。

ーーーーー

営業をやっている方には失礼なのだろうけど、会社、特に大きい会社において、営業というのはそれほど難しくはないと私は思っている。もちろん、会社が大きくなるまでにはとてつもなく大変だった過程はあっただろう。しかし、既に大きくなった会社の営業は、本当に0からモノやサービスを売るまでに必要となるはずの障壁のほとんどは既にクリアされている前提から戦うことができる。

自分たちを認知してくれるユーザが存在し、商品を宣伝するための広告チャネルも存在している。開発部門が優秀なら尚よしだ。ただ、それですら営業という仕事の方が、開発よりも難しいと個人的には思う。

モノを作るのは、数学によく似ている。全ての数学の問題はあらゆる定義の組み合わせで解ける。モノやシステムを作ることが問題だとすれば、あとはどういう技術（定義）を組み合わせて実現するか、それだけの話である。もちろん、方法論はたった一つではない。ただし、それぞれのやり方は類似しているし、合理的に考えれば、自ずと良い選択肢は定まってくる。

ただ、モノを売るという問題の方法論は全く異なる。例えば、収益を上げる上で、市場規模の大きいマーケットを狙うべき、という考え方に対し、ニッチな市場向けのビジネスを展開するべき、という相反する解がありうる。さらに、それらの選択肢は合理性だけでは選択できない。

改善の方法も無限だ。今回のアプリ開発で、壁がたくさんああって、それらの原因も多種多用であることはわかった。しかも、それらへの対策がどう影響を及ぼすのか、ということは数字などのデータでしか見ることができない。ひたすら仮説と検証の繰り返しである。具体的な答えは得られないし、そもそも具体的な答えなどないのだ。だから私は売ることに対し積極的になれないのだと思う。

強いて良い点を上げるなら、答えがないからこそ自分のやりたいようにできる、ということぐらいだろうか。

トイレビジネス

私は胃腸があんまり強くありません。なので、朝会社に出社したちょっと経ったら、だいたいお腹が痛くなります。それがほぼ毎日です。

当然、トイレに駆け込むわけです。でも、トイレの入り口に近づくと見えてしまうんですね。既に並んでいる人の影が。並んでいる人の数が2を超えていたら、上下のフロアのトイレへ行きます。でも、今までの統計的に朝の時間帯はどの階も一人か二人は並んでいることが多いです。

で、このトイレに並んでいる時間ってめちゃくちゃ無駄なんですね。私にとっても無駄ですけど、会社にとっても本当に無駄。例えば、社員の給料が時給換算で2000円ぐらいだとすると、この並んでいる10分ぐらいの時間は300円をゴミ箱に捨ててるようなもんなんです。トイレ待ちながら仕事はできませんから。

いや、べつに一人くらいなら気にする必要もない些細な損失です。でもこれが各フロアで起こっていて、かつ一時間に数回の頻度で起こっていて、それが毎日起こっているとしたら。。。大きい会社なら年間数百万ぐらいの労働力は損しているでしょうね。

ただ、そんなに沢山人が待っているような印象は受けないと思います。これはさっきの私と同じような行動をする人が沢山いるからです。要するに、2人以上並んでいたら空いている他のフロアを探す、あるいは少し時間を置いてからまた行くといった具合に。フロアが狭ければ構わないでしょうが、この単純往復作業も何回もやると積み重なっていきますし、疲れます。

この問題について私は対策案を二つ考えてます。

１つはトイレ課金制度の導入です。例えば、今日本において、ほとんどのトイレは無料で使うことができますが、そのせいで、トイレを使いたい時に使えない人がたくさんいます。というのも、無料だと、一人の人間が長時間利用することができてしまうからです。

トイレに入ってから5分までは無料、それを超えたら100円払わないとトイレから出られない、という仕組みを入れてほしいと思います。個人的には3分でもいいくらいです。トイレが長い人やトイレで休憩する人が少しでも減れば、みんなハッピーになります。

トイレのロックにセンサーをつければ、一人の人間がいつからいつまで使ったかがわかりますし、お金を払わないとロックが解除されない仕組みがあれば、お金を払わざるを得ない、というわけです。

ただ、現実的には財布を忘れてしまった人は出られなくなってしまうので、指紋で電子通貨の支払いができる社会が実現していることが理想ですかね。とはいえ、今の技術でも工夫すれば可能なのではないでしょうか。

もう一つの案は、トイレのIoT化、トイレの稼働率を監視する仕組みの導入です。自席やスマホからトイレの稼働状況を見ることができれば、今トイレに駆け込むべきなのか、少し待った方が良いのか判断できます。こうすることで、無駄な待ち時間が排除できる寸法です。

ただ、これはあまり良い解決策にはなっていないんですね。なぜなら、トイレの稼働状況を全員がウォッチできるようになると、「あ、今ここのトイレ空いてる！」と気付いた人が一斉に駆け込んで、トイレについた時にはすでに行列が出来上がっていた、みたいな事態が発生してしまうからです。このリアルタイム性の壁を超えない限り、あまり現実的な解とはならないでしょう。

少し調べてみると、チームラボとかがこういうアプリを作ってるみたいですが、どのくらい役に立っているんでしょうね。

おばかアプリ勉強会資料 チームラボ from atmarkit

www.slideshare.net

そういう急激なトイレへの人員駆け込みを避けるとなると、結局今の技術では、5分間隔でトイレを予約する、みたいなとこが落としどころになってしまうのか。うーん、予約してまでトイレに行くというのはどうも堅苦しいし面倒くさい気もします。

なんか、いいアイデアはないもんでしょうか。

インプットとアウトプットのスタンス

私が受験で成功した主たる要因は自分のアウトプットを最適化する学習方法を実施していたことにある。テストというのは本来、当人の理解度を推し量るためのものであるが、その実そういう風にはできていない。要するに、深く理解していることがテストで良い点を取れることを保証するものではないのである。

仕事も全く同じである。与えられた資料を読み込み、深く理解したから良いアウトプットが出せるか、というとそうではない。どんなに理解していても、期待される成果物を作れるかどうかは別なのである。

頭がいい人の多くは、理解すなわちインプットに重きを置く人が多い。仕事でわからないことがあれば納得いくまで話を聞き、自分で調べたりする。ただ、インプットに時間をかけた分だけ、アウトプットの時間が減ってしまうことは考慮しておくべきだ。仕事の現場において理解することは単なる手段でしかない。

例えば、プログラムを作る場合はアウトプットに最適化すべきである。ネット上に使えるリファレンスがあるならそれをコピペして使いまわした方が早い。Googleのアルゴリズムのおかげで信頼性の高いものがヒットする。実際に動かしてみて問題がなければOKとする。その方が早い。

もちろん、自分で一つ一つプログラミング言語の文法を調べて、少しずつ段階的に作った方が時間はかかるが、次に同じものを０から作り上げることができる可能性は格段にあがる。しかしながら、０からプログラムを作る必要があるケースなどほとんどないので、このあたりは残念ながら自己満足でしかない。

ただ、アウトプットに最適化することが必ずしも良いか、というとそれも違う。確かにアウトプットに最適化したインプットをしていると、生産性は高いし、良い成果物も作れるだろう。ただし、それは短期的な成果に限る。上に述べたように、付け焼き刃で身につけた、本質的な理解を伴わない知識はすぐに忘れてしまうからだ。

また、アウトプットに最適化していると、どうしてもイレギュラーに弱くなってしまう。特に、説明資料を作る場合などは、目的や経緯、問題点、原因と対策案などを深く理解している必要がある。説明の伴う成果物については、どちらかといえばインプットを重視した方が良いのだ。

最近気づいたのが、こんな風に状況に応じて、インプットとアウトプットのバランスを変えられる人間は非常に少ない。成人した頃には、インプット重視なのかアウトプット重視なのかが大方決まっているからではないか、と思う。

インプット重視型は他人への説明が得意であるし、ある程度のイレギュラーにも即座に対応できる傾向が強い。これは事前準備を綿密に行う資質からくる対応力であろう。ただし、色んなことにスピード感が欠ける。

アウトプット重視型は説明が不得意で、とりあえずやってみてから考えるスタンスを取る。最低限の準備でスタートを切るので、仕事は早い。準備を嫌い、想定外の問題が発生した時は、発生してからトライ&エラーで問題解決にあたる傾向がある。いうまでもなく、私もアウトプット重視型である。

ただ、これらも意識的に変えることは可能である。説明が苦手なのだとしたら、少しインプットに比重をかけてやればいいし、仕事が遅いと感じるのであれば、少しアウトプットに比重をかけてやる。

無意識に仕事を進めると、自分の基本スタンスで仕事を進めてしまうため、問題が顕在化してしまうが、仕事の種類に応じてこれらを使い分けられるようになれば、特に致命的な問題にはならない。

企業がグローバルリーダーを求めるわけ

今日からグローバル研修初回。これから半年間、月一で実施される。グローバルリーダーなんて微塵も興味はないのだけれど、部長命令で泣く泣く参加することになったのだ。中途半端に英語ができるとこういう悲劇を招いてしまうことがよくわかった。

私は基本的にグローバルで働きたいという感覚がない。また、グローバルに働きたいという人の気持ちに一切共感できないし、非論理的だと思っている。なぜなら、グローバルに働きたいならば、日本の会社に入るべきではないからだ。

留学経験などから「海外の人とコミュニケーションをとるのが楽しいから」とかいう人もいるけれど、はっきり言ってあきれてしまう。外国人と話をするのと、海外で仕事をするのは全く違う話だし、それが同じだったら、人と話すのが好きな人はみんな仕事大好きってことになる。そんなわけはない。

そう、「グローバル」という言葉を付けた分だけ、仕事の抽象度が上がってしまうのだ。だって「グローバルな仕事」がそもそも何なのかが全くわからない。営業、開発、研究、人事、これらの分類だって決して具体的なわけでもないが、これらすらわからない。グローバルな場で働けたらこれら全て何でもいいのだろうか。このあたりが不可解極まりないのだ。

ちなみに企業がグローバル人材を求めているのは、グローバルという言葉の抽象度とも私は密接に関係していると考えている。今世の中の流れは非常に早くなっているし、グローバリゼーションも進んでいる。当然、そこそこ大きい会社であれば、従業員を養っていくためには国外の需要に目を向けていかなければならない。かつ、経営の多角化を進めていかなければならないのだ。

となると、会社としてはどんな国でビジネスをするのかも予測できなければ、どんなビジネスをすることになるのかも予測はできないのだ。そして、それはいつから始めなければならないかもわからない。明日から必要、という可能性だってある。

となると、会社としてはどんなビジネスをすることになるかわからないが日本以外の国でも仕事ができる（仕事を引き受けてくれる）人が欲しいのである。こういったふわっっとした人物像のことをカッコよくグローバル人材と定義しているのである。煌びやかなイメージがあるが、企業にとってはただの便利屋さんなのである。

リーダーも同じ話だ。仕事内容を表す言葉ではなく、役割である。とどのつまり、グローバルリーダーは、「抽象」＋「抽象」で本質的な何かを指しているわけではなく、ただ単に華やかな印象を与えるためだけに作られた言葉なのだ。日本人がこういう言葉に弱いことを知った上で使っているのも癪だし、こういう言葉に釣られてグローバルな仕事がしたいという人にも少し嫌悪感を抱いてしまう。

なのでおそらく、「アフリカの貧困問題を解決するための仕事がしたい」みたいに具体的な欲求を持っていると、グローバルで活躍するチャンスは激減する。逆にそういう仕事にチャレンジさせてもらえる企業であれば、非常に良い会社だと考えていいだろう。

何にせよ、グローバルな場で何がしたいか、の方がよっぽど大切だと思う。というかそれがないと、グローバルな場で働くことなんて不可能だろうし、生きた英語も学べない。TOEICで高得点を叩き出して満足していても現場でビジネスマンとして通用しない、みたいなことになるのだ。

自分はこういうことをやりたくて、それをするには今の日本では難しいし、海外の人とも協力する必要があるから、グローバルな場で働きたい、みたいな考えを持っていると応援したくなると思う。

例えば、最新の人工知能を使った新しいサービスを作りたくて、そのためには最先端の海外で情報を獲得する必要があり、そしてそれらの情報を理解するためには英語が必要だし、現地の人からの投資が必要、だからグローバルで働きたい、みたいな。

ただ、まぁこういうことを本気で考えている人はやっぱりもう海外の会社で働いていると思うんだよなー。

目標を達成したい全ての人に 〜アプリリリースのお知らせ〜

Androidアプリ、作りました。

無料です。課金制度も広告もありません（少なくとも今は）。単純なアプリですが、ブログも書かずに結構真剣に作ったので是非とも使って下さい。

はい。サブタイトルの通り、タスク管理のアプリです。ただ、普通のToDoリストではなくWBS用のアプリです。

私が今の会社に入ってよかったと思えることの一つに、「WBSを頭の中で考えられるようになったこと」というのがあります。

WBSとはWork Breakdown Structure の略で、直訳は作業分解図などとも言われるみたいです。とある大きなゴールを達成するために必要な作業を分解し、それを繰り返して、細かい作業（タスク）に分解したものです。主にシステム開発の現場などプロジェクト型業務の組織で使われてます。

WBSの重要なポイントはMECEである（漏れや重複がない）こと、そして実行可能なレベルまで具体的になっていることです。この2点が不十分なWBSをもとにプロジェクトを進めると必ず問題が起きます。

タスクの漏れがあると、誰もその仕事をやらないのは当然として、最も注意が必要なのが具体性です。人間は何から手をつけてわからない仕事をついつい後回しにしてしまいがちだからです。だからこそ、実行可能な具体度で記述しないといけないんです。

逆にこの2点さえ満たされていれば、プロジェクトの成功確率はぐっと上がります。他にも、そのプロジェクトを完遂するためには何をしなければならないのか、今やっていることは何に繋がっていて、他にはどんなタスクが残っているのかを理解することができるんです。

で、これはチームで仕事するからでしょ？と思うかもしれませんが、個人だって全く同じ話です。例えば、「ダイエットする」を目標に掲げたものの、結局先延ばしにして、気がついたら年が明けて「今年こそは！」なんて言っていないですか。こうなってしまうのは意志が弱いからではありません。「ダイエットする」が何をすることなのかが漠然としてしまっているからです。

例えば、「ダイエットする」といっても、大きく二つのやり方があります。それは「食事を減らす」こと、そして「運動をする」ことです。さらに食事を減らすといっても、朝食を抜くのか、夕食を抜くのか、間食をやめるのか、いろいろと選択肢があります。

そしてそれを決めない限り、いつまでたってもダイエットはできないのです。つまり、「ダイエットする」という目標達成のためには「ダイエット方法を決める」というタスクが必要なのです。

加えて、「ダイエット方法を決める」ためには、どんなダイエット方法があるのか、そして、それぞれのダイエット効果およびメリットやデメリットを知っておく必要があります。すると「ダイエット方法について調査する」というタスクも必要なことがわかります。

そして、「調査」の仕方も具体的にすると、「ダイエットの特番を見る」、「ダイエット本を読む」、「ダイエットに成功した友人の話を聞く」などの方法が考えられます。どうでしょうか。今すぐダイエットはできないですが、「ダイエット本を読む」ぐらいなら簡単にできる気がしませんかね。

と、上記のような思考を助けてくれるのがWBSです。実際には下記のようなツリー構造のリストを作るイメージです。

ダイエットをする

　ダイエット方法決定

　　ダイエット方法調査

　　　ダイエット本読む

　　　ダイエット成功者の話聞く

　　　ダイエットの特番見る

　　ダイエット方法比較検討

　　　代表的な方法を5つピックアップ

　　　メリットデメリット整理

　　　ダイエット方法選択

　ダイエット実施

　：

　効果測定

　：

こんな風に表現すると、今何をやっていて、あと何をやれば目標達成できるのかもわかりやすいですし、シンプルに「進んでいる感じ」がしてモチベーションもあがります。あなたが普段たった一行で表現してしまっている行動も実はもっと細かい作業が積み重なってできている、ということがわかるでしょう。

正直言うと、このアプリは私自身が使うために開発しました。仕事でバリバリ使うほどにリッチではなく、かつToDoリストほど柔ではないものに仕上がっています。なので、個人として使うのに最適なのではと考えてます。

「まぁ無料だし試しに」ぐらいの感覚でインストールしてもらえれば、と。ぜひともよろしくお願いいたします。

人生を消費するフェーズ

人生を消費するフェーズに入っている。最近は強くそう思う。

厳密には生まれた瞬間から我々は人生を消費している。しかし、子供の頃は消費というよりは投資としての側面が大きかった。なせならば、色んな経験から様々なことを吸収し成長していけるからだ。どんなに無駄なことをしても、それが将来何らかの役に立つという名目があり、それすなわち投資だったのである。

一方で、大人になると、投資という側面は非常に小さくなる。将来のために苦しい時間を過ごしていることを投資と呼べば聞こえはいいが、実際にはただただ時間を消費しているだけかもしれない。

大人に対して使う「成長」という言葉も最近は違和感を感じるようになった。正しくは今対峙している仕事に順応しているにすぎない。子供の頃なら新しい知識やスキルをどんどん蓄積していくことはできたが、大人は何かを得るとその代償に何らかの知識やスキルを失っていったりする。

だから、人は創出することを望むのかもしれない。自分の中に何かを蓄積し続けることはできないけれど、一時的に蓄積したものを使って何かを外部に残すことはできる。例えば、今の私に3年前に自分が書いたことと同じことは書けないけれど、今になっても自分が書いたものとして残っている。

実績とか経験もどちらかというと、残せるものではある。ただ、私は過去の実績とか経験とかよりも、今の自分がどうか、というところにどちらかと言えば重きを置いてきた。

ただ、今の自分を維持していくのもこれからは大変になっていくのだろう。昔なら当たり前にできていたことができなくなったりすると、人の能力というのは絶えず失われていくものだと痛感する。

私は何を残したいのだろうか。

社内業務最適化を阻む要因

私の会社には無駄な仕事が多い。というより、ほとんどの中規模以上の会社であれば、無駄と思える仕事がゴロゴロしているはずだ。正確に言えば、かける労力、コストに対しての入りが少ない仕事である。

撤廃する方向で進めても、「この仕事をやらないとこういうリスクがある」とか「こういう場合に困る」とか言い出すコンサバ軍団が必ずいるからだ。本当に価値が全くない仕事であれば、議論に上がる前に誰もやらなくなっている。

というわけで、私はこの手の仕事、特に定常的な業務に関しては割と積極的にツール化を進める。あるエクセルのシートの内容を別のシートに転記する、ある条件にマッチするデータだけを抽出する、とか、お決まりのメールテンプレートで依頼するとか。なるべく、長期的に使うことになりそうなものを優先的に作っている。

ただ、私は自作のツールを社内の標準にはしないことにしている。

普通に考えれば、自分以外の人もツールを使った方が組織全体としての効果は増える。だから、私も若手の多くがやらなければならない面倒な仕事を最適化したことがある。

ただし、ツールありきの仕事を標準化してしまうことにはリスクがある。それは大きく２点、保守・運用が必要になること、ツールに習熟する必要があることである。

1点目の理由「保守・運用」の担当を逃れるため、私は自作ツールは展開しない。ツールと言うとチープな印象を受けるが、単純なシステムである。世の中で今なお大多数の人に使われているシステムには必ず保守・運用を担当する人がいる。会社としてシステムを作っているのであれば、保守部門、運用部門など専属の要員が必ずいるのだ。

システムを使う人はただシステムを使うだけなので、自分でシステムを直すことはできない。そんな、「壊れた時に自分ではどうしようもないもの」を自分の生活基盤に組み込むことはできないのが人間である。

別にシステムに限った話ではない。例えば車。直してくれる人がいないのであれば、車を買う人は激減するだろう。ただ、モノで言えば寿命と共に故障していく場合がほとんどなので、最悪新品に買い換えれば済む話であるが、システムは言ってみれば、新品の時点で既に故障していることがほとんどであるので、保守・運用は必須と言える。

で、個人でツールを作ると、必ず保守・運用も自分でやる羽目になる。「だってそのツールのことわかっているのは作ったあなただけでしょ？」という理屈である。当然社内のこととは言え、ボランティアでやっているだけなので、こんな理不尽なことはない。だから他の人に使ってもらうことになっても、私は非公式に渡すことにしている。

さらに長期的に見ても、自分（開発者兼保守者）がいなくなってしまった時に、残された担当者だけでそのツールを運用していくことができなくなってしまう。結果的に、使われなくなり、また手作業に戻る、ということがままならないのだ。

２点目がツールの習熟。これはシステムを導入する時も同じ話で、業務のやり方が変わるとやっぱり戸惑ってしまう人が多い。で、だいたいの場合、「前の方が使いやすかった」とか、「どうすればいいかわからない」、などと言い出す人が後を絶たない。

何かを変えたときに聞こえてくるコンサバ軍団の決まり文句である。もちろん、ツール自体をいかに使いやすく、直感的にできるかという点について、開発者は考えなければならないのは事実だ。

しかし、恩恵を授かるつもりがあるなら、自ら習熟する姿勢を持つべきではなかろうか。車の運転に技能が必要だから車に乗らない、などと言っている人は技術の恩恵を決して受けることはできない。自転車だって同じだ。どんな道具もある程度使い方を覚える必要はある。

ただ、会社にいる人というのは、総じて今の自分のままでできる仕事を好む傾向にある。先ほどの保守についても全く同じである。別に開発者が私だからと言って、私が保守をしなければならない、なんて買い被り過ぎである。

私に言わせれば、誰でも少し調べれば、マクロの仕組みを理解して、自分の思い通りに直すことは可能だ。そのぐらいのレベルのものしか作っていない、というより一人で仕事の空き時間に作れるものなんてその程度が限界だ。

しかし、これまたそういう活動には興味がない人が多い。顧客に直結しない仕事、裏方の仕事、地味な仕事、そして評価されない仕事をやる人は少ない。これは組織としての問題ではあるのだけれど。

これが一般の企業なら別に上記に述べた問題からツール化を避けるのもいいのかもしれない（生産性が停滞するのでお勧めはしないが）。ただ、私たちはシステムを作っている会社である。だから、私は言いたい。お前たちは技術者ではないのか？と。

他人が作ったツールを使いにくいと言う前に、どうすれば使いやすくなるのか考えろ。ツールにバグがあった場合の心配をするのではなく、ツールのバグを直すためにはどういうスキルが必要なのかを考えろ。こんな姿勢の人達が良いシステムの提案ができるはずもない、と私は思うが。

でも、私たちはもう技術者の集団ではないのだ。だから同僚の技術に対する姿勢を問題視したところで仕方がないと諦めている。私はそもそも自分がやりたくない仕事をやらないためにツール化しただけなので、そのせいで自分の仕事が増えたら本末転倒であるし。

新年に「今年の目標」を設定するという奇妙な行いについて

あけましておめでとうございます。新年になったということで「今年の目標」的な投稿を色んなところで見かけますね。で、まぁ私も今年の目標とかを少しは考えてみました。

が、何も思いつきませんでしたね。というか、今年の目標を新年に考える意味なんてあるのか？という疑念の方が強くなってしまいました。だって去年考えた「今年の目標」なんてもう忘れてますし。逆に覚えてる人いんの？

うん。確かに、年が明けたら「今年の目標は・・・」みたいなこと考えるのは結構恒例行事になってる節があるけど、今年が終わるときに今年一年どうだったか振り返ってる人なんていないっしょ。

念のため言っとくと、「去年は楽しい一年だった」とか、「どこどこへ旅行へ行けてよかった」とかそういうことを思い出すことが振り返ることではないですからね。昨年立てた目標設定に対してどうだったか考える。これが本当の振り返りですよ。まぁやらないでしょうね。仕事みたいだし。

でも新年になってから設定する目標を考えるぐらいなら昨年を振り返った方がはるかに意味はあるんですね。てか後で振り返らないなら目標なんて立てる意味ないでしょう。

あと、”今年の”目標というのも考えてみると変な言葉ですよね。例えば、「今年こそは痩せる」という目標はありがちですけど、いやいやいや。それ”今の”目標じゃないの？って感じです。今すぐはやらないけど、今年中には・・・みたいなニュアンスで使ってる時点で努力する気ないでしょう。

本当の目標は常に「今の目標」であるべきですね。結果を出すには時間がかかりそうとか、オーディションが1年後だから、といった理由で”今年の”目標だったとしても、そこに対して今から進捗させる覚悟があるならもう今この瞬間の目標といって差し支えありません。だから、今年の目標は・・・なんて言ってる時点でスタート負けしてますし、叶う確率も下がります。

こうやってよくよく考えていくと、新年に今年の目標を考える行動というのは、本当に何の役に立つのかわからない奇妙な行動なんですよね。「目標があった方が人生は充実する」という格言めいた言葉だけを鵜呑みにした結果と察します。

残念ながら新年の目標を考えたくらいで人生は充実しませんが（涙）、これは言ってみればもう文化なんでしょうね。正月には初詣に行く、ぐらいの慣習です。そこに深い意味や合理性はないんです。だから、あまり気張らず、おみくじを引くぐらいの遊び感覚でやるのが正解なんでしょう。

分業体制に潜むデメリット

今世の中は分業が加速している。というよりは、分業して、専門性に特化していかなければ、競合他社との差別化を図ることが難しいからだ。そもそもの原則として、分業した方が効率的に仕事を進めることができるのは明白である。

ただ、分業したばっかりに上手く行かないと感じることも結構多いんじゃないだろうか。つまり、分業にもデメリットはありますよ、というお話だ。

私が今のチームでよく感じるのは、分業が進みすぎたばかりに作業の重複が結構発生することである。システム開発なんかをやっていると、業務系のSEと基盤系のSEに分かれて分業することも多いのだが、結局結合試験とかを始め出すと、全く同じ試験を別々に二回やる、みたいなことが頻発する。

そもそもシステムの構造上、基盤システムの上に業務APが乗っかっているので、業務APの試験を実施するためには、基盤システムを動かさなければならないし、基盤システムの試験を実施するためには、何かしら業務APを利用しなければならない場合もあるのだ。

分業していなければこれらの試験は一度で済む。まぁ分業が悪い、というよりは分業するための仕掛け作りを怠っていることが真の原因なんだけど。特に分業しているものを連結する場合には、分業したまま進められる作業、一緒にやった方が効率的なものをキチンと仕分けておく必要がある。

でも、この「仕分け」という作業をほとんどの人が意識していない。なぜならば、分業した人たちの責任範囲を超えてしまっているからだ。自分たちが考えるべき範囲でもあるけど、相手が考えるべき範囲でもあるよね、という仕事は総じて責任が不明確になり、問題を起こしやすい。システム開発でもインタフェース部分で故障が多く発生するのはこういった人間の心理も大きく関係している。

なので、プロジェクトマネージャーならグレーゾーンについて注意をしなければならないし、もし自ら監視しきれないのであれば、キックオフ（プロジェクト開始）の段階で、チームの中で主となるチームを決めておくのが良いと思う。さっきの例で言えば、業務Tにも方式（基盤）Tにも影響があるものについては業務Tが主管とする、といった感じで。少しでも曖昧な部分を無くさなければならない。

同じような話として、分業体制にすると、自分たちの仕事を進める上で、他チームの情報なりスキルなりが必要になる場合が必ずある。この他チームへの依頼作業というのが不毛で、非常に骨が折れる。以下はかなり極端な例ではあるが、こんな感じである。

1日目：

「この資料を元に〇〇の設定を反映して下さい」（業務T　→　方式T）

2日目：

「この資料だけだと具体的な設定値に落とし込むことができないので、条件を整理してください」（方式T　→　業務T）

3日目：

「どういう形で整理すればいいのかわからないので、フォーマットを提供して下さい」（業務T　→　方式T）

もはや、要件定義の縮図である。全く持っているスキルや知識が違うチームに対して何かを依頼して、期待通りの結果を得るというのは実は結構難しいのである。

加えて、これは私の予想だけど、どうも分業体制に慣れている社会人は自分がボールを持っている状態を必要以上に嫌う傾向がある。理由は簡単で、「この仕事については〇〇チームへ依頼中です。」と言えれば、自分たちには何も非がないように振る舞えるからだ。

よって、一度依頼が発生すると、本当の仕事が全く進まない不毛なキャッチボールが繰り広げられる。結果進捗が遅延すると、「そんなもん連帯責任だ」といってもほとんど響かない。分業体制は個々の責任を明確にしているだけに連帯責任は追求されにくいのだ。

分業をしていなければこうはならない。しかし、分業をしていても、こういった機会を極力少なく余地はあるように思う。

ほとんどの場合、特にチームレベルの分業なんてものは十分に最適化されていない。なんとなくこの仕事はこのチーム、あの仕事はあのチームぐらいで分けられている。

できれば、各チームが持ち得る情報とスキルを整理した上で分業した方が良い。体制を考える上で、その人が持っているスキルをベースで考えることが多いが、その人が持ち得る情報という観点もあった方が良いと個人的には思う。

なぜなら、ぼぼ全ての仕事は、必ずスキルと情報をセットにしなければ成し得ないからだ。この辺はプログラムと全く同じである。だから、情報のやりとりが煩雑になりすぎるようであれば、分業化する意味はない。情報を仕入れるルートを変更したり、そもそもの体制を見直す必要がある。

とりあえず、分業こそが最も効率的だ、と考えるのは浅はかで、分業化するからこそ注意しなければならない点があり、それは大きく、責任範囲の明確化と伝達情報量の極小化である。これらを踏まえて仕事を進めることが大切なんじゃないか。