コンサルタントは嫌われることが仕事
コンサルタントの話
PGをしていると、「あんなSEにはなるまい」とか軽蔑しているようなSEが結構ちらほらいます。
ところが、いざSEになると、ちょっとでも気を抜くと、その軽蔑していたSEになってしまう時があって、自己嫌悪に陥るわけです。
同様に、SEをしていると「こんな無様なPMにはなるまい」とか「こんな雑な要件しか決められないコンサルタントにはなりたくない」とか思うわけです。
ところが、いざコンサルタントになると、やっぱり、その無様なコンサルやらPMになっちゃうみたいです。
私はPM側は経験ありますが、コンサルタント側は経験皆無なので、そっちについては本当は語る言葉はないんですけど。
コンサルタントはPMと違って、ハタから見ていて「あ、ダメだ」って思うのは一言で言える気がしたので、今日はそんな話をしようかなぁ、とか思います。
コンサルティングという仕事
PGから順に成り上がっていくようなコンサルタントだと特にそういう思いを抱くのは分かりますし、「もっと良い答えがあるはずだ！」とも私は思うのですが。
私のこれまでの経験則だけで、コンサルティングっていう仕事のゴールは何か、って定義を決めるならば、「企業の成長のための人柱」かなぁ、とか思います。
人柱ってのがミソですね。
言い方を換えると、「会社が怖くてできないようなことを後押しする」のがコンサルタントの仕事の中で結構重要なポイントなんですね。
ITでコンサルに業務効率化をお願いする場合なんかを例にしましょう。
これまで伝票登録に10分かかっていたものが5分で終わるようになったとしますね。
となると、伝票登録を行っていた経理担当者の人数を半分に減らすことができるわけです。
ここまでは開発していても分かる視点なので当たり前すぎてあくびが出るんですけど。
コンサルタントはそこから更に一歩進んで、営業担当者自身がリアルタイムで伝票登録できるようにして経理部門から伝票登録担当者を全員左遷させるだとか、そもそも伝票登録自体が不要となるように業務フローを変更するくらいは提案するわけですよ。
つまり、伝票登録を行っていた経理担当者の人数をゼロにするという大改変ができるのね。
となると、そりゃあ経理担当者から死ぬほど恨まれるわけです。リストラされるかもしれないわけですし。
そんな時に残った人たちが、「このクソ会社が！」と思わないようにする、っていうのがコンサルタントの大事な仕事の一つに当たる、と言えるんですね。
「あの似非ITコンサル野郎が来たせいで俺の仕事が無くなった！」と思わせることが大切。
だから、人柱なんです。
コンサルタントっていう嫌われ者の存在を礎にして、会社のリストラやらなにやらを成立させるわけです。
「上手いこと会社の敵として立ち回れる」コンサルタントって、やっぱり有能な人が多いですね。
類似の言葉に「海外の本社から来たCEO」とか「カルロス・ゴーン」とかありますけど、大体は同じ意味ですね。
誰だって嫌われるのは苦手
さて、大半の人は「好かれる」ことは得意でも「嫌われる」ことは苦手だと思います。
いや、好かれるのが苦手な人も勿論居ますけれど、それでも、「好かれよう」という意識の方が強いんですよね。
「上手く嫌われよう」なんて、一歩間違うとヒロイックな幻想で中二病の0.25歩手前の考え方ですし。
大体そういう患い方をした人って嫌われ方がすっごい下手で「なんか何言ってるか分かんない、ウザい」って言うただの説明不足なだけだったりするんですよ。
ところが、ここで、上手く嫌われないと、コンサルティングができないんですよね。
中二病患った感じの「俺が敵になれば良いんだっていうナウシカも真っ青の自己犠牲オーラ満載コンサルタント」とか単純に気持ち悪いので、孤立して（っていうか扱いに困るから放置されて）結果的に的確な情報収集ができなくなっちゃってるのも何度か見たことありますし。
「ひたすら正論をぶちあげまくった挙句根回しを一切していない」ようなコンサルタントとかだと当人を雇った会社ごと嫌われてしまって現場と経営で変な派閥ができて会社の雰囲気がどよーんとする感じになったりします。
かと言って変に好かれてしまうと、最後の最後で「コンサルタントの人は優しくて良い人だったけど会社最悪だな！」なんて思われちゃうし。
特に日本の企業って若干ウェットな関係が多いので、「社長や幹部のカリスマ」みたいなものでどうにかこうにかつないでいる場合も結構あるんですよね。
それが嫌われるって言うのは会社としてはマイナスになるわけで、そこのモチベーションを維持したまま効率化しないとパフォーマンスが落ちるだけじゃないですか。
だから、コンサルタントは人柱として、立ち去るときには石を投げつけられる勢いで、最後は嫌われる覚悟が必要なんですよね。
コンサルタントにはあんまりなりたくない
まぁ、こんな感じなので、「コンサルタントは口だけで適当な事を言って最終的に俺らに損させてるだけじゃん」って言う批判って言うのは、かなりの確度で正しい、と私は思っています。
むしろ、「でもコンサルタントってすごいよね」みたいなことを思われちゃったらそれただの「自称カリスマ美容師」みたいな感じの違和感しか残らないですし。
ただまぁ、「開発側」、つまり「一緒に会社の敵に回ってくれるはずの人」からも嫌われるような立ち回りをする人が多いなぁ、って感じることも多いので、もしかしたら「開発側から嫌われるメリット」ってのがどっかにあるのかなぁ、とか思ってたりします。
特に請負業務だったらコンサルタントが盾にならなくても会社との付き合いは開発が終わったら切れるんだから、あんまりそこでコンサルタントが間に立って壁にならなくても、って思うんですけど。
いや、開発の人たちが果たしてユーザーと戦えるかって言うと微妙なので、その代理の敵としてコンサルタントが藁人形の役割をしているのだとしたらすごい精神力だとは思うんですけど。
いずれにせよ、このままのやり方を続けいても、「そんなもん仕事にしたくないわ」って言う至極当然な感情が出てくることのほうが多いです。
単価は今の1.5倍〜2倍くらいもらえるんでしょうけれど、それこそ桁が違うんでしょうけれど、「お金をもらって嫌われる」って、ものすごい心が荒みそうです。
ということで、同期の人がコンサルタントを取った記念の、負け犬の遠吠えでした。
私は当面はSEかPMで回していきます！
あ、スケジュール？ なおすなおすー！ なおすよー！ 予算内で直すよー！
消費税増税にまつわる開発云々
備忘録としてメモるのまき
消費税増税するわけですけど、どうも、ユーザーからは「5を8にするだけでしょ？」って感覚でいる気がして仕方ないので、色々調べてました。
セミナーとか何回か行ったんだけど、まぁ、「え、これを半年でやるの？ 無理じゃね？」って思ってます。
その0:そもそも酷いプログラムがあるって話
前回の消費税増税（3->5）は1997年、流石にその時代から使っているプログラムは少ないので、「前回の対応をそのまま」という話にはならない。
でも、少なくとも自分が数年間見てきた中では、2001年とか2003年とかのプログラム程度ならそこら中にある、ということ。
これを機に作り直す、みたいなところもありそうだったけど、決まるのが遅すぎたので、これから半年で作り直すことはまず無さそう。
それよりも何よりも酷いのは、「直接1.05倍している」プログラムの衝撃的なまでの多さ。
これ大丈夫なの？ ホントに回ってるの？ って頭を抱えたくなるようなプログラムがゴロゴロしてる。
その1:返品の管理などの原則
原則として、「売上日基準」で消費税は決まる。
この辺はぶっちゃけ常識だからどうでも良いけれど、ちょっと前から話題になっているIFRSのせいで、これまでは「発送日に売上を立てる」仕組みから「着荷日に売上を立てる」仕組にシフトしている。
で、このやり方だと例えばコンビニなんかでも、「購入が1時間遅れるだけで税率が変わる」とか、通販だと「たまたま3/31に不在だった所為で税率が変わる」なんてことが起こるわけで、その期間の売上についての扱いがかなり恐ろしいことになる。
今年はまだIFRSは義務になっていないので、「発送日基準で売上を立てます」みたいな言い訳できそうだけど、次回の10%への引き上げがどうなるかが非常に恐ろしい。
特に通販業界とかどうなってるのか。
通販は法律の特例がある(他にも水道やら何やら特例は結構多いから要調査)ので、もしかしたらこの辺逃げ道あるかも。
もう一つ、返品周り。
返品時の税額と売上時の税額は必ず同額じゃないと意味がないので、返品時には「元の仕入/売上の転記日が何か？」が非常に重要。
いつ売ったかわかんないようなモノを返品とかする時にはどういうスタンスを取るか、とか、システム側ではその辺の良くわからない例外に心を砕く羽目になりそう。
ぶっちゃけ開発やってる場合じゃない。
その2:特例関係
とりあえずわかりやすいのは工事進行基準を用いる大規模開発やら何やら。
ああいうのは、進行基準と完工基準のどっちが良いか、ってのが重要になりそう。
-
- 2013年9月以前に契約されたものについては、完工基準が有利(2013年9月以前に契約されたものは、消費税率は5%が適用される)
- 2013年10月以降の契約については、「開発期間が2年以下であれば」進行基準が有利そう
二つ目のポイントの前提として、次回の勢消費税改正は2015年10月が有力だからなので、これが延期になるとまた別の話になりそう。
他にも電気代とかその辺の特例もありそうなので、当面は会計士に問い合わせして回る日々が続きそう。
ぶっちゃけ開発やってる場合じゃない。
その3:今後の展望
こんだけ面倒なことになると、「内税と外税併記」がそろそろなくなるんじゃないか、みたいな気がする。
消費者のことを考えれば併記がベストだけど、システムと言うか、逃げ道としては「内税表記」が流行ってきそう。
この話のポイントはこれだけじゃなくて、「どうせ次のステップは軽減税率になるんでしょ？」って言う部分にある。
例えば車やら何やらの税率がアホみたいに上がったり。そういうことになりそう。
ドーナツ5個までだと税率が高い、みたいな「欧州ではまれによくあること」が増えてくる前に、システム的にそれをどこまで対応できるかを調査しておくとベター。
次回の消費税増税は確定しているけれど、おそらくそれまでに低所得者層へのキャッシュバックはシステム化できそうにない。
そもそもマイナンバー制が未完成である以上、捕らぬ狸の皮算用をした上で三味線弾いているようなもんで、お話にならない。
今回のバタバタしている感じを見る限り、キャッシュバックキャンペーンを取るのか軽減税率を取るのか、どっちか決まるのはかなり土壇場になってからになりそう。
であれば、今のうちに調査しておかないと再来年の今頃にデスマーチが待っているのは不可避。
ぶっちゃけ開発やってる場合じゃない。
いずれこの会社を去るであろう後輩への言葉
うちの会社はあくまで「ハケン」業です
請負業務だとかなんだとか言っても、IT業界において、小規模な会社ができることって言うのは、なんか無茶なパッケージ組んでゲリラ的に殴りこむ一点突破型のWeb系か、SIerの下請のさらに下請、いわゆる「ハケン*1」くらいしか道が無いのかな、と思っています。
結果的に、うちの会社の仕事はコンサルタントになろうがプログラマをやろうが、「いろいろな会社を一定期間で転々とする」ことが求められる仕事です。
特にコンサルタントまでいくと、「開発からは好かれて、現場から嫌われる」ことが正解になる世界ですし。
どうしても色々な会社を転々とすることが求められます。
幸い私は今の現場に数年勤めることができましたが、昨今は開発案件の短期化も手伝って、転々とするサイクルが非常に短くなっているようです。
それでも、私達は「いずれ今の現場を去らなければならない」ことを覚悟した上で、仕事をしなければなりません。
すなわち、私達ハケンは基本的に「定期的に人間関係をリセットする」ことで成立しています。
人間関係をリセットするのは疲れる
別に私は感受性が高いワケではないと思うのですが、やっぱり現場を去ったりと言うのは疲れるんですよね。
携帯電話のアドレス帳に二度と電話することがないであろう客先の課長の電話番号とかが蓄積していくのも疲れるし、飲み会なんかも疲れるわけですよ。
なんにせよとてつもなく疲れます。
私はその対策として、「自分のキャラクターをグッズに転嫁」した上で、現場を去る際に「その設定を同時に捨てる」ことで誤魔化しています。
単純に、「いつもお昼にきつねうどんを食べてる」とか「いつ会いに行ってもキシリトールのボトルが置いてある」とか。
そういうキャラクター設定を、その現場にいる間だけ作っておいて、現場を去る時に、同時にその設定を破棄するんですね。
その儀式をすることで、「前の現場で働いていた深沢は今の自分とは別人である」っていう設定にして生活しているわけです。
実際そうやって距離をある程度離しておかないと、去る時にがっかりしちゃうんですよね。
「あ、結局ハケンなんだな、自分は」みたいな感じで。
このショックは、パフォーマンスにかなりの悪影響を与える事が多いんです。
少なくとも、私の後輩はそういうタイプでした。
人間関係でパフォーマンスが決定する人
私はその後輩としばらく同じ現場で働いていました。
彼は、とても頭の回転が速くて、正直「自分の技術者としての限界」をまざまざと見せつけられた気分にもなりましたが、まぁ、彼の教育を私は担当していたわけです。
研修でも高い成果を出していたので、鳴り物入りで私の下に来た感じでした。
ところが、最初の半年は、全く、何を言っても響かなかったし、現場でもずっとから回ってたんですね。
受ける相談は「自分の技術に自信がない」とか「○○さんとやっていける自信が無い」とか。あ、後者は私のことじゃないよ？
もちろん、彼に対しては少し説明するだけでしっかり理解するし、私が一ヶ月間かけて学んできたことも三日くらいかけて説明すれば私以上の理解度を示すようになったりするわけで。
それだけの技術力と技術に対する嗅覚を持ちながら、「自信がない」って言われたら私も立つ瀬ないわ、とか思うのですが、彼は本当に自信が無さそうで、かなりしんどそうでした。
なんか変わってきたかなぁ、と思ったのは、そこから更に半年くらい経った頃、現場の雰囲気や、私の性格に慣れてきた頃でしょうか。
途端にケアレスミスが減ったんですよね。
そこでようやく気づいたわけですよ。
「あ、この後輩は人間関係によってパフォーマンスが圧倒的に変わるタイプだ」ということと、同時に、「後輩は身内と判断した人に対しては徹底的に寛容だ」ということ。
うまくやっていける自信がない、と言っていた人とも、気が付けば二人で会話できる程度には仲良くなっていたし、自信が無いと言っていたのに、いつのまにか周囲を引っ張ろうとするだけの自信を備えていました。
後輩は「人間関係に慣れる」ことで仕事が習熟するタイプだったんですね。
いずれ、この会社を去る選択を取るということ
その後もしばらく後輩と仕事を続けてきて、「あ、この人はハケンと言う仕事には向かないかな」と確信するようになりました。
彼のスキルは誰の目にも分かるほどに、それこそずっと組んでた自分が感じるほどに、成長を見せつけてくれました。
主要因は、圧倒的に、「人間関係の慣れ」なんですよね。
私みたいな性格の上司なんて、多分イラつくと思うんですよ。私ならイラつきます。
現場の雰囲気も、アットホームではありますが、仕事に対してのスタンスは驚くほど厳しいんです。仕事になるとピリッとした空気になることも多いんです。
にも関わらず、彼は私みたいな気むずかしい上司にも、今の現場の空気にも「慣れる」ことができたわけです。
どうにも、彼はうちみたいな小さい会社で、様々な現場を転々とするのはあまりに勿体無い、と感じてしまんですよね。
多分うちのやり方では「人間関係に慣れる」前に力尽きてしまうんです。
スキルの向上に思考を切り替える前に納品し、撤退してしまう。
かと言って彼をずっと今の現場に縛ることは「うちの会社としては」マイナスにしかならない。
こういう後輩に、「新しい会社」や「新しい仕事」を準備できないっていうのは、ものすごく歯がゆいなぁ、と眺めています。
まぁ、私はその後輩とは九月で離れることになりましたが、次に一緒に仕事をする時は、彼がユーザー側のシステム部で、私が一介のハケンSE、みたいな関係になれば面白いかなぁ、と思うのでした。
*1:カタカナにしているのは厳密な派遣業務とは異なるため
将来なにをしたいです？
面談ってなんかうがった見方をされるなぁ
面談で上司に「お前は何をやりたいんだ？」と聞かれたらを読んで、「あ、そんなに穿った見方されるんだ」って思ったので、今回はこれについて。
根本的に、こっちは「なにをやりたいの？」って質問は、「分かりません」とか言われることを想定して質問していますよ。
的確に答えを出せるような人は、面談する必要なんかほとんどなくて、「あ、そうですか、じゃあ頑張ってください」って感じですぐ終わるんですね。
あとはこっちで「じゃああいつがその方向に進むんだったらこういう仕事を準備しておかないと意味が無いな」とか考えたり方々に相談するだけで、それは面談とは別の次元の話です。
面談の目的は、「会社が部下に対して描いている未来図」と「部下が描く未来図」のすりあわせです。（他にもあるけどここでは省略）
その二つに大きな齟齬があれば会社か部下に軌道修正が迫られるし、その二つが同じだったらこのまま続ければ良いって感じで。
部下が「自分がどうなりたいか」を描いていない状態であれば会社の方針に従わせれば良いのでしょうが、それで従わせた結果、「思ってたのと違う」って言われても上司としては困るので、「じゃあ、どうなりたいかを一緒に明文化しよう！」って作業がどうしても必要になります。
だから「お前はなにをやりたいんだ？」って質問に対して「じゃあ上司はなにがやりたいの？」って訊かれても、困るんですよ。
それを答えた所で、「部下がなにをやりたいのか」のヒントにならないことが多いので。
訊かれた時は、相手の位置に応じて「自分がお前ぐらいの時はもう少しPG続けていたいなぁとか思ってたけど」くらいの言い方になっちゃう。
具体的に「こういうことがしたい」とか言ってもヒントにならないし、それじゃあただの自分大好き人間でしょ。そういう人は面談じゃなくて講演をしたほうが良いです。
ということで、面談は「部下がなにをしたいのかを押さえる」「会社が何をして欲しいかを伝えて部下と会社の目標をすりあわせる」「直近の行動を決める」の３ステップでやってるんですよ。少なくとも私は。
そして多くの上司はそうやって面談していると思いますし、そういう形に落とし込めない面談はほとんど意味がないです。
「部下がなにをしたいのかを押さえる」
面談の中で一番ウェイトを占めるのがここです。
これをちゃんと決めないと、よく言われる「目標管理」も雑になるし、目標管理が雑になるっていうのは会社として成長システムを作れないってことなんですね。
なのでまぁ、探りとして「なにをやりたいの？」って質問をして、「部下がビジョンを明確に持っているか」を調べるところからスタートします。
ジャブですね、ジャブ。
大半の場合、質問してもちゃんと答えが出ないので、元の記事の通り、「じゃあなにがしたくないの？」とかそういう方向に水を向けます。
よく言われるのは「残業したくない」とかでしょうか。
もちろん、それ自体は別に構わないんですけど、IT業界における「残業したくない」って結構茨の道なんですよね。
例えばPGとして参加した場合、その時の見積を間違えればその時点で残業発生しちゃうでしょ。
「自分のミスで残業するのは良いけど、他人の尻拭いで残業するのはイヤ」とは言っても、普段からミスって残業している人の工数見積精度なんて誰が評価します？
問題発生時に「これすぐ終わらないので、ユーザーと調整してもらえますか？」って言って周囲が納得してくれるようなPGじゃないと、残業コントロールって殆どできないんですよ。
ってことで、「開発者、という立場のままで残業したくなかったら自分のスキルを的確に把握して、そのスキルを使って発言権を得るとかしないとダメじゃないかなぁ」みたいな感じで、「そのために必要なスキルは何か」を明文化していく作業を行うんですね。
もちろん、そんだけ開発できても残業が発生する可能性もありますから、その時のために、この面談以降、上司は「残業が発生しそうになったらスケジュールを見直す」とか「スケジュールが見直せなければ残業せずにすむような組立を考えなおす」とか、その辺をしなきゃいけないですけど。
他にも、「もう会計関係の保守はイヤです」とかも多いかも。
月末とか期末とかクソですもんね、会計の保守って。
その場合は、じゃあそれ以外ならなんでも良いのか？ って話をしていくわけです。
結構前に「地図が妥当な日本語で書かれているか調べる」みたいな仕事があったんですよ。
詳しい話を聞く前にその仕事は蹴ったんですけど。
仮に会計がイヤな部下にその仕事を回しても、そこで得られるものとか、得たものを使うフィールドとかが、うちの会社にはまぁ間違いなく無い、って思ったので。
実際蹴ってから部下に聞いてみると「それなにが面白いんですか」とか言ってたし、蹴ったのは正解でしょう。
他にも曖昧な目標だったら、それをどんどん具体化していくような話をしていきます。
「もうちょっとユーザーと接点を持ちたい」みたいな要望であれば、「どうすれば接点を増やせるか」っていうアプローチをかけます。
まぁ、そんな感じで、「部下が具体的になにがしたいか」っていうのを面談で詰めていくわけですよ。
「会社が何をして欲しいかを伝えて部下と会社の目標をすりあわせる」
部下のプランをひと通りヒアリングして、「あれだね、最終的には販売管理とかの開発に携わりたい感じだね」という感じで目標を決めたら、そこでようやく「会社としてはなにをして欲しいか」を伝えるんですね。
「いやぁ、実は会計の保守をお願いしたかったんだけどなぁ」って感じで。
もちろんもう会計の保守はイヤって言われているので無理強いはしないのですが、かといって会社が提案しているプランと同程度に稼げそうなプランにしてくれないと会社が困るので、「開発に携わるって言ってもPGだったら継続的に仕事もらえない感じだよなぁ」ってことで、すりあわせを行なっていくんですね。
「ちょうど販売関係の案件を回している人がいたから、ダメ元でそっちにアプローチはかけてみるよ」って感じで。
そうやって色々すりあわせても、どうしても会社の方向と合わないなぁってなったら、二択ですよね。
- 会社が折れる
- 部下が折れる
会社が折れるってのは、「この部下有能だし手放したくないから、部下のキャリアプランが作れるような仕組を作るかなー」って感じ。
部下が折れるってのは、「とは言っても、こいつ販売管理の勉強してる素振りないし今の話を聞いてもとんちんかんだから当面は会計の保守させつつ、勉強してくるかを観察してみるか」って方向に持っていく感じ。
面談するってことはある程度キャリアを積んできて、給与も上がってきているわけで、その段階で「全然詳しくないけど販売管理を一から勉強させて下さい、会社の金で」ってのはまぁ厳しいんですよ。
君が稼いできてくれないとうち潰れちゃうんで。
だから、やりたいんだったら「教えてくれる人」とか「使えそうなノウハウ」は教えるので時間外なりスキマ時間なりに勉強して、それである程度会得できたら仕事回すよって感じになっちゃうんですよね。
「販売管理については新人レベルなんで給料も新人レベルにしていいよね」なんて言葉は通用しないし。
（それが通用したらブラック企業でしょうどう考えても）
あ、話がそれた。
まぁ、そんな感じで、「会社と部下の妥協点を探る」のがこのフェイズですね。
「直近の行動を決める」
で、最後にようやく、行動計画です。
まぁここまで来たら大体もう計画出来上がってるんですけど。
「ひとまず販売管理の仕事回せるように、貿易について簡単に抑えておいてね。輸出管理の仕事なら回せるわ」って感じで。
「そのためには、輸出管理詳しいのはアイツとアイツだから、ちょっとその三人で引き継ぎとか説明が出来る場を設けるわ」みたいな。
このフェイズは、本当にすぐ近くの行動だけきめて、「それで本当にそのプランに進む気があるか」を探る部分ですね。
あんまりやる気無さそうだったら、また近日中に面談やり直しになりそうです。
その時はなんかもっと偉い人を呼ばないとダメなのかなぁとか私が憂鬱になる感じ。
一緒に答えを探す気がない面談は無駄です
ということで、上司も部下も双方に言えることですが「一緒に答えを探そうとする」つもりがない面談なんて、やるだけ時間の無駄です。
そういう意図があるから、わかりやすく、「何かやりたいことある？」とか「じゃあ、コレまでの仕事でいやだったこととか、良かったこととかある？」とか聞いているつもりなのですが、どうにも、上司っていう立場上、邪推されるんだなぁ、と思ったのでした。
あ、ちなみにこれは面談の話ですよ。
面接とかで「弊社に入ったら何がしたいですか？」って質問する人は死ねば良いと思います。
上に書いてある通りこういうのは「お互いに話し合って答えを探すもの」なので面接の場で聞いてもどうしようもないですから。
青い鳥はそこら中にいた、という話
要件定義とミチル
最近後輩が要件定義なるものに手を出していて、「えっ、早くね？」と、驚いています。
後輩のスキルが高いのは事実ですが、要件定義ってなまじっかスキルが高いとこっそりと炎上する可能性があって、非常にハラハラします。
あ、燃えた。
ということで、本日は開発の世界にある「要件定義」のお話です。
本当はもっと一般化できる話題なのですが、まぁ、今回はかなり（私がやってる）仕事の話に寄せてみました。
チルチルと要件
さて、開発の世界にある「要件定義」とはなんぞや、というお話から始めましょうか。
要件定義っていうのはユーザー（お客様）が考えている「こういうのがほしいなぁ」っていうのを「こういうこと？」って実現可能な形にまとめる作業です。
例えば、「なんか美味しいカレーが食べたい」って言うところからスタートしてみますね。
要件定義で行う作業は「美味しいカレーって、どんなもの？」って言うのを、お客様と、お店の間で合意する作業なんですね。
例えば「あんまり辛すぎても美味しくないよね」って話であれば、あんまりスパイスはバカスカ入れないほうが良いなぁ、って話になりますし。
「ジャガイモが入ってるカレーは日本的すぎて好きじゃない」って言う話であれば、具に何を入れるかを考えなおすことになります。
「シャバシャバなカレーってライスと絡まないから好きじゃないんだよね」って言われたら、まぁ、まずスープカレーは選択肢から外されますね。
こうやって、「どんな食材を使って、どんなカレーにするか？」を決めるのが要件定義です。
ここで重要なのは「本当にお客様が食べたいものは何か？」っていう「要求」を徹底的に調べ出すことにあります。
が、そんなもの、その要求をしっかりと言語化できるなら苦労しないんですよ。
料理に詳しくない限り、「美味しいカレーは何故美味しいのか？」を論じることはできません。
ところが料理に詳しくなくても、目の前のカレーが美味しいかどうかを判断することはできるんですね。
なので、非常に曖昧な「美味しいカレー」ってのをどうやって決めるか、がとっても重要です。
対話してどんどん理想の形を探る、的な。
青い鳥を探すという作業
さて。
「美味しいカレー」の定義がある程度できて、材料を買ってきて、カレーを作ったとしましょう。
ところが、なんか思ったより美味しくない。もう一声欲しい、ってことになってしまいました。
要件定義っていうのは、「お客様と料理人が相談して【美味しいカレーとは何か】を定義し、同意する作業」です。
で、同意の上で作ったカレーに対して、「いや、もうちょっと美味しくなるでしょ、おかしくね？」って言われるのは、何故なのでしょう。
火加減がまずかったのか？ ちょっとタマネギ入れすぎた？
そういう、「料理技術の問題」であれば料理人はキッチンで試行錯誤すれば何とかなりますね。
ところが、それでも何とかならない、なんてことがたまにあります。
この作業が意味することは、「話し合って決めたはずの【美味しいカレーの定義】が間違っている」ということです。
そう、ここから青い鳥を探す旅が始まります。
美味しいカレーとは何か、幸せとは何か。
そう、お客様（チルチル）と料理人（ミチル）はそれを追い求めて迷いの森へと入っていくのです。
青い鳥は何匹もいる
さて、たとえ話はここまでにして。
現実の要件定義においても、「他社から受信したテキストファイルをサーバへ取り込み、変換し、システムに伝票登録する」みたいな、すっごい一見単純そうな開発ですら、開発作業は衝撃的に難航します。
「ファイル取り込み機能と、それを変換する機能と、変換結果をそのまま登録する機能の三点セットで良いよね？」って話で開発を進めるのですが、
そのうち「なんかテキストファイルに誤りがあることがあるから、それを検知したらエラー発生のメールを担当者に送付する仕組みをつけて」とか言われます。
まぁここまでは、変換機能部分に入れれば良いので、特に困らないのですが。
それをOKして開発している時に「あ、エラーのリカバリは再度ファイル受信って言ってたけど、あれ勘違いだったわ」っていう衝撃的な勘違いから何もかもが瓦解していく、とか結構あります。*1
そもそも青い鳥（ユーザーが追い求める幸せ）っていうのは、そもそもユーザーの数だけあるし、仮にアンケートをとっても、大半のユーザーはまだ実感がわかないから適当な返事してくるんですよね。
そのシステムを頻繁に使うはずの、「ベテランだけど、職位がそこまで高くない（外部との連絡を取らない）人」の声が最初の要件定義には含まれてないことが非常に多いんです。
最初のカレーの例であれば、この「美味しいカレーの定義」をする人は実際にカレーを食べる人じゃなくて「カレーを食べる会の幹事を任された人」に過ぎないってことね。
なので、実際にカレーを食べる人たちがいざ食べて「なんか違う」ってなっちゃうんです。
と言うことで、迷いの森に入り込んだチルチルとミチルは、ここでようやく、予想以上に大量にいる青い鳥に愕然とするハメになるんですね。
要件定義って結局何なの？
絶対要件定義って、後になったらブレるんです。
会議なんかでも、「後からユーザーの要求を見つけていくこと」にこそ意義を見出している人がすごい多いんですよ。
「後から例外を見つけたヤツがかっこいい」みたいな風潮で。そんなもん、事前に見つけた方がもっとかっこいいんだからもっと前から本気で考えとけよ、と思うんですけど。*2
そうやってどんどん見つかる後から見つけた問題を改善するにしても予算は動かせないから残業でカバーみたいなザマになるので、自衛として、「要件定義で決めるとはどういうことか？」をちゃんと定義しなくちゃいけません。
つまり「要件定義フェイズってそもそもなにをするハズなの？」って話ですね。
大体この２つのどっちかでしょうか。
- 先に鳥かごに目一杯青い鳥（要件）を詰め込んで、後から見つかった青い鳥（追加要件）は無視する
- 鳥かごの大きさ（ユーザーの要求を満たせる限界）を決めることを要件定義にして、青い鳥（実際の要件）は後からかき集めるようにする
一つ目の方法は上に書いてあるようなやり方なんですけど、事前に徹底的に話し合って、「この範囲外のものはすべて追加請求します」って言う方法ですね。
あんまりこれで上手く行ったことがないんですけど、事前にいろんなユーザーに会うチャンスがもらえるならこの方法が良いと思います。
そもそも要件定義のポイントは、「どれだけの要望を引っ張り出せるか？」ってことで、それは一人の人から沢山ではなくて、沢山の人から少しずつ、っていうのが理想です。
一人の人から沢山貰うと、優先順位があまり高くない部分が要件に含まれちゃうので、実際に使っているいろんな人の声から、「声が多かったものから順に入れる」のが良いわけですね。
ところが、「いろんな人から声をもらう」ためにはその人たちみんなが「普段の仕事を止めて、アンケートに答えたくなる状況」にしなくてはいけないんですね。
だからいろんなユーザーの声が上がってくるのって、実際に完成直前になってデモを見せたりしてる時なんですよ。
いろんなユーザーの声をかき集めるためには、「デモを行うタイミングをどこまで早くできるか？」と「デモを行なってから導入までの間に長い時間を設けて問題ないか？」の二つをしっかりと話し合う必要があります。
そうすれば、一旦作ったあと、心に余裕を持って「青い鳥探し」に出かけることができるんですね。
ちなみに、後者の手段としてはアジャイルだとかプロトタイプを作っていくとかが重要なのですが、アレをやると無条件で工数が減るって言う誤解があって困ります……
乙武さんの一件は示唆に富みすぎてて論点が見えない
二日間、もやもやしてたのでまとめるためにも書く
この土日、すっごいモヤモヤしていて、なんかイライラしてたのですが、その理由がこれです。
乙武洋匡さん、銀座の「TRATTORIA GANZO」に「車椅子だから」と入店拒否される（追記あり）
これ、すっごい短絡的に、固有名詞を全部取っ払って話すと、「なんか店員が無礼だったので腹たった」って話です。
ところが、ココにいくつか追加されるキーワードによって、話が同時並行で４つくらい進んでいる気がして、またそれらが非常に「感情的」なので、どうにもイライラしてしまいました。
この話を受けて議論される点は４点、まとめに１つくらいかな、と思うのでまずはその整理。
- 全体の社会としてのお話
- 車椅子利用者など、何らかの障害を持った人は予約時に事前に連絡するべきなのか
- すべての施設は障害を持つ人を受け入れるべきなのか
- 個別としてのお話
- 総括として
- じゃあ、我々はどうするの？
って感じですかね。
ってことで、大体この４つの視点から、今回のことを眺めてみようかなぁ、と思いました。
社会的な話
まぁ、これは、おそらく、多くの場合、共通見解じゃないかなぁ、と思ってます。
障害を持つ人は予約時に連絡すべきか → 現行ではYesとしか言えない
まずは、一つ目。
障害を持つ人は事前に連絡すべきか、ですが、そりゃYesでしょう、と。
これを「No」と言うためには、「すべての店は障害を持つ人を常時受け入れることができなければならない」ということになります。
常時ですよ、常時。その整備は法でやらなきゃだめじゃないですか。
今だって法律はありますが、あくまで「努力義務」でしかありませんから、罰則はないんですね。
これ、バリアフリーだから理解が難しいんですけど、アレルギーの話だって同じじゃないですか。
例えば小麦アレルギーの人がいて、電話予約するときにそのことを告げずにお店に行って。
いざ、お店でメニューを開いたら、「全商品に小麦が入ってる！」ってなった時、お店に「小麦抜いて」なんて言えませんよね。
なので、事前に電話で確認しないとダメなんですよ。
お店の側が譲歩して伝えるべき、という考えも無くはないのですが、それを言い出すときりが無くて。
電話で予約するときに「お客様の中に車椅子など、お体が不自由な方はいますか？」とか「お子様は何歳程度で？」とか「何かアレルギーはありますか？」とか全部お店から聞いてきたら、「客の側が」ウザくて仕方ないですよね。
なので、お店も客もそんなの全部聞いてらんないから、客のほうからアナウンスしないといけません。
これ、結構当たり前だと思うんですけど、思いの外否定意見が多くてびっくりしてます。
すべての施設は障害を持つ人を受け入れるべきか → 理想はYes
次、すべての施設は障害を持つ人を受け入れる体制にすべきか、と言うと、そりゃーYesですよ。当たり前ですよ。
これをNoって言っちゃうのはあまりにもおかしいかな、と。
もちろん、「隠れ家的なレストランだから障害者を受け入れる余裕が無い」とか「すべての人を受け入れるとか言い出したらきりが無い」のは間違いないです。間違いないですが、それは「例外」であるべきで、「理想」は受け入れるべきなんです。
で、その理想を前提として、「じゃあこういう時は仕方ないね」って言う話に持って行かないとダメです。
最初から「仕方ないよね」って言っちゃうと、それは話が発展しません。
誰だって経験あるでしょう、例外の細かいところばっかり言い出しなんも方向性が定まらない会議とか。
出てて「時間の無駄だなぁ」って思いますよね。
なので、「理想として」あるいは「方向性として」どうあるべきか、って話を最初にするしかなくて。
その方向性としては、「すべての施設はオープンであるべき」でしょう。それ以上でもそれ以下でもない、と言う部分に収めないと。
ここを否定されてしまうと、ちょっと残念なんですけど。
私としてはここは理想として、そうあるべきだと考えないといけないんじゃないかな、と思います。
個別案件として
じゃあ、その前提から見て、今回の内容はどうなのかなぁ、という話。
今回の店主は乙武さんを受け入れるべきだったか → No、仕方ないよね
前述のとおり、「すべての店が障害を持つ人を常時受け入れる準備ができているわけではない」です。
そして、少なくともこのお店については「何らかの準備をせねば受け入れることができない」状況です。
その準備とは、要員の追加、店内レイアウトの変更など、いきなりできるものではないでしょう。
（写真見て分かるように、お店すごい狭いよね）
更に店主が降りてきたのは１５分後、なんですよね。
それだけ忙しいんだから、運ぶのは基本的に無理でしょう。
じゃあ、周囲の客が連れてくることは可能なのか？ と言うと、それまた難しいです。
このお店、お酒出してるんですよね。
- お店の中の人にお酒を飲んでいない人がいて
- その人が40kgくらいの人を運んで階段を昇り降りできるくらいには健康で
- さらにそれでいてそういう状況を快諾してくれる
そんなお客様を探さなければならないです。
もし仮にそれが上手くいっても、帰るときに同じ対応をしなければなりません。
つまり、乙武さんを運んで１階にお送りする仕事ですね。
そこまでできます？ っていうとできないでしょう。
なので、私は、店主が手伝おうとした店員を止めたのは英断だと思いますよ。
店主の発言で人としての尊厳を傷つけられるような思いをするのは「車いすユーザー」なのか → 他のツイート見る限りNoじゃないの？
この店主の発言を見る限り、単純に「車椅子の人を差別するとかしないとか以前に配慮してなかった」に過ぎないのでは。
もちろん、無意識っていう刃はすっごい鋭利で人を傷つけるものなのですが。
だってこのまとめに紹介されている他の発言をそのまま鵜呑みにすれば「個人商店を営む頑固親父」以上でも以下でもないじゃないですか。
だから、今回（仮に）店主が乙武さんを罵倒したとしても、それは「事前に確認もせずに車椅子で来たこと」でありそれ以上でもそれ以下でもないでしょう。
店主にとっては「ちょっと荷物重いんで一階まで取りに来てもらって良いですか？」って言われたような感じで返したんじゃないですか？ 詳しい状況が見えないのでなんとも言えませんが。
いずれにせよ、店主の発言の矛先は「乙武さん」であって「車椅子ユーザー」ではないのでは？
事前に電話で確認してたら「じゃあ○日ならスペース開けておきますよ」的な流れにできるでしょう。
「うちは受け入れるスペースありません、ガチャン ツー ツー ツー」みたいな感じでつっけんどんにされたら、それこそすべての車椅子ユーザーを罵倒していることになりますけど。
じゃあ、我々はどうするの？ → 結局、個人が意識しないとダメなのでは？
今回の一連の流れで「気持ち悪いなぁ」って思ったことがひとつ。
こんだけお店に対しての批判が多いと、「だったら普段どれだけやってるの？」とか思っちゃうんですよ。ちょっと意地が悪いですけれど。
良く地面に点字ブロックあるじゃないですか。アレ。
アレの上にね、自転車が乗っかってたりするとすっごい迷惑だ、って良く言われてますよね。
なので、私はそういうのを見かけて、かつ、数分くらい空いてたら、できるだけ動かすようにしてるんです。
「仮に盲目の人が歩いていて、その場に誰もいなかった時に、何らかの事故が発生するのはイヤ」じゃないですか。
で、結構前の話ですけど、駐輪場も駐車場もないコンビニの前で、そういうのを見かけたので、自転車を動かしてたんですね。
もちろん鍵かかってたから全部持ち上げて動かしてたんですけど。
その間、通行人も、コンビニでバイトしてる人でさえも手伝ってくれなかったんです。
いや、もう諦めてますけど。
実際、手伝ってくれるのなんてごくごく一部なんですよ。
他にも車椅子の人が電車に乗り込んで来た人を一瞥して、その上で、車椅子スペースを譲らずにもっかいスマホに視線を落とす人がどれだけいます？
そういった日常的な部分の啓蒙すらマトモにできてないのに、いきなりお店に、それらの「普段のちょっとした心がけ」の何倍も難しい要求を突きつけるのは私はどうしても好きになれません。
まずは、自分の目で、実際に周囲を見渡してみてはいかがでしょう。
案外、「できてないこと」の方が多いですから、それらを先に解決していかないといけないじゃないですか。
そういう自省が今回の店主叩きや乙武さん叩きの流れの中に含まれていなくて、「なんでやねん」って思ってしまったり。
まぁ、この話を突き詰めると、「できてないこと」を謗るんじゃなくて「できること」を褒めていきましょうよ、という、なんともやっすい話に帰着してしまうので、そんな感じで終わりますけど。
ちなみに
知らなかったのですが、ココロのバリアフリー計画なんてものがあるんですね。
面白いなぁ、と思った反面、「東京で２２件、大阪で２件か……」と思ったので、まだまだ認知度が低いみたいです。
こういうものの認知度が上がれば、個人の側面からいろいろフォローできて、なおかつそれが広がりやすくて良いなぁ、と思います。
あと、ベビーカーマークなんてものも国主導で動き出しているみたいで。
こんなかんじで、国の側からももっといろんな方向性を打ち出して欲しいなぁ、と思いますです。
少なくとも、今回みたいな「個人経営のお店をあげて批判する」と問題は「批判した人とそのお店単独の問題」になっちゃう。
それだと、やっぱり上の炎上みたいに「今回は仕方ないよね」とか「今回はアカンよね」って話にしかならなくて、なんの発展もないんですよね。
そうじゃなくて、こういう問題はもっと意図的に主語を大きくとって、「車椅子ユーザーにやさしくない店がたくさんある！」ってところから攻めないと、なんの発展もなくて、ただ燃えるだけ燃えて溝ができるだけ、って感じがして残念です。
（後輩に）伝えたい、この思い 【第三部: 責任は取るものです】
九割くらい私の責任なのであんまり書きたくない話
毎回書こうと思っていながら、「この話を掘り下げても面白い話にならないのでは」と思ったのと、「正直九割以上自分が悪いのでそれを客観的にどや顔で書くのも」って感じでちょっと躊躇していた話です。
後輩に伝えたい、って意味では多分これかなぁ、と思って。
責任を取ることが教育では一番大切、と考えています
私はOJTを何度か(片手で数える程度ですが)していますが、いつも強く意識しているのは、「最初のうちは失敗しても俺が責任を取るよ」って毎回伝えること、です。
例えば新人が遅刻した時に頭を下げるのは私の仕事ですし、スケジュールが遅延している時は私がソースコードを査読したりテストパターンをまとめたりする感じでフォローします。
もちろんその後新人に説教したりはしますが、その手前、「頭を下げたりスケジュールを回したり」っていうのは、教育する以上当然ですよね。
新人が残業することは可能な限り起きないようにするのがOJT担当の仕事ですし、それでも残業が発生するような現場であれば、「そもそもここでOJTをするべきではない」と上司に進言して、その新人を撤退させるように動いたり。
こんなもの、言うまでもなく、先輩としては当たり前の姿だと思いますし、OJTを担当する以上、できるできないは横に置いて、最低限このくらいはできるようになる、あるいはできるように意識しないとダメなのは自明でしょう。
もちろん、これだけできれば良いわけではなくて、「教え方に気をつける」とか「何でもかんでも勝手に自分でやりすぎないように」とか、「説明し過ぎない」とか、そういうのが無いと教育は成功しないのですが。
最低ラインとして求められるのは、「責任を取る」って部分です。
先輩として「新人の責任を取れること」ってのが最低条件だ、ってことですね。
ここで問題なの、この先輩像が、「当たり前すぎて新人に気付かれない」ことにあるようです。
責任を取らない後輩の話
なんか、私が教えた後輩だけかなぁ、とか思うのですが、どうも、「新人の責任を取る」ことがすっごい下手なんですね。
OJTを横で見ていたのですが、教え方はとても丁寧で、わかりやすくて、むしろ私が教わりたい！ みたいな感じでした。
何かあったら叱るとか良くできたら褒めるとかその辺も上手くコントロールできていて、「これぞコーチングの鑑やでぇ」と目頭が熱くなったのですが、一点、すごいマイナスポイントがあって。
責任を取ってくれないんですよ。
OJT中にその新人が失敗して、私のところに謝りに来ることがあったんですね。
ところがその後輩、新人に謝らせて、横に自分が立っていることが「教育」だと思ってるんですよ。
「失敗が表ざたになる前にフォローできなかった」っていうのは教育担当者の責任なんだから、新人の謝罪や今後の計画よりも重要度が高いのは、「教育担当者が今後同じようなことが起きないようにどうするか」を考えることにあります。
新人の半泣きの謝罪後もしばらく観察してたんですが、どうにもなんかその後輩、ソコに気づいてないんですよね。
あれれー？ と。
例えば新人が私に所に謝罪に来て、そこで更に失言をしたとしましょう。
そうすると、失敗の責任どころかなんか失言まで晒してもう大やけどするじゃないですか。
その新人は失敗を先輩に相談できなくなっちゃうんですよ。
先輩に相談しないから、もうその新人に仕事を回すことすらリスクになっちゃうんですね。
せっかくの勉強なのに、ビクビクしながらその新人は学ばなければいけないわけです。
これじゃあOJTとしては大失敗だし、このままでは現場デビューもかなり困難になりますよね。
なので、「新人の責任を取らない先輩」は、どんなに教えるのが丁寧でも、仕事ができても、どこかのラインで「仕事を任せられないなぁ」って思ってしまいます。
別に教育が全てではないのですが、「あぁ、きっと普段も他人の失敗の責任は取らないんだろうなぁ」みたいなことを考えちゃうんですよね。
集団責任社会システム
そもそも、即戦力を求めない傾向にある(新人をイチから鍛え上げる)目的をもった日本の会社は、先輩が責任を肩代わりすることで教育する、と言うシステムが構築されています。
そして、その教育システムが少し歪んだ形で、そのまま会社のシステムを作り上げています。
つまり、「責任はどんどん上位の人に回していくもの」という共通認識の上にシステムが成り立っているんですね。
部下の失敗を上司が責任を取る、と言う教育時のスタンスがそのまま会社全体に適応されているわけです。
それをダメだ、と言うことは簡単なのですが、そうすると、何故か「個人の失敗にのみ」フォーカスを当てた責任の取り方をやっちゃう。（つまり、失敗した人を左遷させるような雑なやり方）
「上司(≒組織)が責任を取る」前提で個人の作業範囲(≒責任範囲)が非常に膨大になりやすいシステムが構築されている今の状態で、いきなり個人に責任を求めると、そりゃー左遷くらいしか方法無いよね、って言う話ですよ。
それはやっぱりダメだ、ってことで、仕方なく、再度、「責任を上司が取る」形に戻しちゃってる、っていうのが今の形に見えます。
このため、「責任の取り方」の教育をしないといけないのですが、このシステムじゃあ責任を取らなければいけない局面が来るのって、大体2年目の終わりとか3年目とかなんですよ。
「実力主義万歳！」とか言う若手に仕事を任せると、「責任が取れない状況に陥る」のはそういう原因でして、多くの場合、大やけどを負うわけです。
なまじ仕事ができるから他の人の作業とかもどんどん回せるし、「おおできんじゃん」って周囲もどんどんその人に回すんだけど、例えばそんな中で仕様に不備があったりすると、もう身動き取れなくなっちゃうんですよね。
「どうやってこのリカバリのプランを立てて説得するか」みたいな話ができなくなっちゃうんですよ。
間に合わないとして、誰に頼るのか、とか、そういう話が全然できない。だからズルズルと間に合わなくなって、その責任を取るための立ち回りもできなくて、ボロクソに怒られたりするわけです。私だ。
責任は、どんどん増えていく
上述の通り、日本型の社員教育のスタイルでは、新人のうちは、そもそも個人で取れる責任範囲が非常に狭いため、その大半を先輩が肩代わりすることで成り立たせています。
OJTで「自分の責任は自分で取るように」なんてことを教えられながらも、その責任の半分以上は先輩が負担することで「自分の責任」を学び、先輩が肩代わりしなくなったら一人前の社会人だね！ みたいな扱いを受けるようになります。
もちろん、自分の仕事の全責任を自分で持つことができる人なんてなかなか居ないと思いますから、自分の仕事に責任を持つこと、それはとても大切ですよね。
ところが、ここまでやっても、当初その新人を教えていた「教育担当者」にはまだ及んでいません。
教育担当者が何をしていたかと言うと、「自分の仕事は自分で責任を取る」傍ら「新人の仕事の責任も引き受ける」ことで教育を成立させていたわけですから。
新人教育に関わらず、チームでの開発作業なんかになると、「スケジュールの遅れ」だとか「個々人のスキルギャップの対策」とかその辺りの「自分一人が頑張ったところでどうにもならないもの」の責任を取ることが求められるようになる局面はものすごい多いです。
それを避けたいのであれば、完全に一人で閉じた仕事を続けるしかないですから。
つまり、仕事を続けていくと、最初は「自分の責任を自分で取れるように」努力することが求められるのですが、そのうち、「後輩の責任を自分で取る」ことが求められ、最終的には「チームの責任を取る」だとかその辺りが求められます。
職位や経験年数に応じて、「責任」の範囲ってどんどん広くなるんですよね。
この「責任」を上手く取れないと、ちょっと大変だなぁ、と思いますので、まずは後輩が失敗した時には、責任を取ってあげてください、と言う話でした。
と言うか、責任の取り方のケーススタディをちゃんとできなかった私が悪いんですけどね……
