やりたいビジネスがあるならエンジニアも権力が必要で

20代からできていれば10年は早く手をつけてられたことになるので、10年早く手をつけた分がリターンとして帰って来ていたかもしれないけれど、30歳で気づけたからまだいいのかもしれない。いづれにしても、自分のやって来たことですから。

少し前に、社外のお友達が企画された手頃な人数で飲む機会があって、すっかり顔馴染みだったり、初めましてで名刺交換などをしながら文字通りワイワイと楽しく歓談をしたわけです。

プログラミング言語はみなさん宗派があるというか、一過言ある方ばかりなようで「swfitは」「phytonは」とかお話しされるとプログラミングが得意でないフレンズなワタシはボッチになれるんですよ。ええ。

だんだんと話の行方が分からなくなった頃に

「偉くなりたくない」

とおっしゃる中堅の方がおられてそう主張されるので、思わず、

「エンジニアにも権力は必要だと思うよ」

とそっと優しく返すと、周りの方もそれに同調される事態にことが広がって、偉くなりたくないと言い放ったエンジニアさんは

「えええ。だって企画を上申するときになんども会議を通して、１案件を承認されるまで何週間もかかるんですよ。そんな会議ばかりやってられないじゃないですか」

と頑張っている。

確かに数週間もの間、説明ばかりで、説明をすれば指摘されて資料を修正しての繰り返しで嫌に思えるかもしれないけれど、それはそれで、

「共犯を作るプロセスなんだよ」

とネガティブに取られるかもしれない言葉を差し出しつつ、周りからも権力が必要だという方向になってエンジニアさん、いや、ある意味全員エンジニアなんですけれど、はどうも納得されないご様子で。

誰も説得なんてするつもりもないし、好き勝手に話しているだけですけれどね。

幾層の会議もなく、１回きりの経営者へのプレゼン15分で決めるスピードもいいけれど、それは１回きりであるからこそのギャンブルだという見方もできるのです。

だからと言って、幾層の会議が良いとい言っているわけではないですが。それでは意思決定までのスピードが遅くてまどろっこしいのも事実です。

ただ、組織としては決めたルールに従ってプロセスしている記録を残すことも必要で、それは規模が大きければ大きいほどそうなるのですよね。

そうした組織構造の中で自分のやりたいこと＝実現したいビジネスがあるならそこに影響を与えられる程度まではエンジニアも権力を手に入れるのが必要ですし、そのためには日頃からの実績に基づくアピールが必要です。

評価者であるマネージャに認知され、アピールがこちらからマネージャにリーチしないとやりたいビジネスが進まないんですよ。

仕掛かり中のアウトプットを共有することが見られる耐性を強くする

プロジェクトでも提案でもですが、何かしらのアクティビティを仕掛かると途中であってもアウトプットができます。そのアウトプットは、提案のために集めた情報かもしれませんし、共有されたインプットから作業している設計書かもしれません。いづれにしてもエンジニアが作業とするとアウトプットが生まれます。

習慣的に仕掛かり途中のアウトプットは、PCのローカルディスクに保存します。しますよね。例えファイルサーバがあったとしても。

アウトプットは見られるために作っている

これ、とっても当たり前なのですが、でも明示的に言われないのであえて書きますが、アウトプットはその作業を依頼した人が必要だから作業として切り出して、担当を決めて実施しているのです。ですから、その作業が終わったら依頼した人が回収することになります。

ですから、誰かに必ず見られる特性を持っているのです。

見られるなら早いうちから

他でも書いていますが、完全に出来上がってからアウトプットを見せるやり方はおすすめしません。ちゃぶ台返しが待っています。

アウトプットをするために、それも具体的なイメージがなければないほど、出来上がる前から見せる作戦が功を奏します。

・方向性を合意すること
・マイルストーンやキーファクターなどで区切ること
この２つのポイントを押さえて行動をすると、結果的に出来上がるずっと前から仕掛かり途中のアウトプットを見せることになります。

普段から見せることで出来上がったときは合意済みのアウトプットが出来上がっている次第です。すっかり出来上がったと思ってから「篠沢教授に全部」と言って掛け金を使うようなチャレンジはそれまで掛けてきた時間をギャンブルするようなものです

早く共有することはGithubと同じ

セキュリティが厳しくてとか、旧態依然としているからとか理由は様々ですが、Githubを使えない環境はまだまだ多いです。

どうしてもツールとして使いたいなら、個人的に週末プログラマーでもしてソースを公開して満足してもらうとして、仕事でそれが使えなくても共有する開発環境でもファイルサーバでも自分のローカルから毎日リリースしてしまうことは、仕組みは違います。

でも、関係者にアウトプットを早いうちから見られると云う環境を作ることと実際に見てもらってフィードバックをもらえると云う点においてはGithubも同じです。

見せ合うことで２つのメリットがある

一つ目は、お互いにアウトプットを見ることで、自分がやらないやり方、考え方を知る機会が作れます。例えば、論理図の表現の仕方、情報の整理の仕方、プログラミング。

二つ目は、見られることに対する耐性がつきます。このスキル、見られることに対する耐性が強くなると、何言われても全く気にならなくなります。それより、

「こいつグダグダ言っているけど本質は」
「もっともらしいこと言っているけど中身ゼロ」

などが冷静に見抜けるようになります。

再発防止策には「べからず」集より「開発プロセス」の見直しを

エンジニアに関わらず何か作業ミスがあると、やれなぜなぜをやれだの、再発防止策はどうしただのと、面倒なことばかり要求します。そうしたことを真面目に要求しているなら作業ミスをした真の原因を見極めたり、再発防止策の効果を検証したり効果測定まで求めて再発防止策の有効性を確かめるまでがお仕事になるはずですが、そのあとのモニタリングなんて求めませんから、形だけだけなんだとすぐにわかってしまうのです。だから、策を作る方も…以下略。

「べからず」集で作業プロセスを見直してはいけない

何かの作業ミスがあり、それが甚大な損害を与えてもべからず集で作業プロセスを見直してはいけません。

当たり前です。

例えばコード設計を上流設計でするときに、コード値とコードの意味合いをピンポイントで設計するかという話です。いきなり、「3＝○○エラー」だけを定義するかといえばそんなことはしないです。コードの取りうる値の範囲とそれ以外を定義して、取りうる値を個別に定義するものです。そうでなければ「3」以外のときの対処に困るからです。

「こうしましょう」では強制ができない

べからず集ではケースの抜けがあるなら、「こうしましょう」でいいじゃない、と思うかもしれません。というか、思いましたよね、ね。

「こうしましょう」は例えばチームの中ではどれだけ強制力があるか曖昧です。チームのメンバは必ず守らなければならないものなのでしょうか。それともできる限り守ってね、なのでしょうか。

確かに、ホワイトな職場で仲良くチーム運営をしましょうという方針であれば、ソフトな言葉で言っているだけで実際は守らないとやんわりと窘められるかもしれませんが。

作業プロセスを見直すチャンス！

今、作業ミスをしたために何かしら再発防止策を打たなければならないのであれば、それは現行の作業プロセスを見直すチャンスです。

今までなんでこれをやっていたのか意味がわからなかった作業までひっくるめて再発防止策を大儀に見直せるチャンスなのです。

作業プロセスは少なくとも初期の頃に想定して設計したとしても、実際のプロジェクトが進捗し、メンバの特性がわかってくると細々と運用で回避しているものです。

そうした明確なプロセスとして定義されていないもののうち、作業プロセスに取り込むことで、メンバ全員がそれを実行することを前提とした方がコンテキストを高めてより高い次元から会話を話すことで意思疎通を効率的に進めることもできます。

逆に、メンバの意思疎通が思ったより取れていないくて、作業品質も低ければ作業プロセスを一段と仔細化することで確実に作業のチェックをできるようにゲートウェイを儲けることもできます。それも慣れて確実にできるようになればチェックポイトを一段上げれば（元に戻せば）いいだけです。

SIerがイノベーションできないのは

SIerではイノベーションを起こせないのです。なぜなら、採用や選別の背景となる組織的な文化に原因があるからです。

誰が判断しているか

採用は新卒でも中途でも数段階を経て採用に至ります。その採用プロセスでは部長クラスや役員のマネージャとの面接を行います。

既存のエンジニアから選ぶ場合も所轄するマネージャが候補者を選択することになります。

彼らがイノベーションビジネスを行なっておらず、人月商売をしているとしたらどういった候補者を選ぶことになるかを考えてみましょう。

判断基準は安心できるかどうか

採用は組織の文化、家風を最も無意識に表します。なぜなら、同じ属性を持っている候補者と働きたいと無意識に選ぶようにバイアスを掛けるからです。

なぜ、無意識に同じ属性を持っている候補者を選ぶか。

それは、同質な候補者は会話が成立するからです。コミュニケーションが交わせる候補者となかなかコミュニケーションを取れない候補者がいたらどちらを選ぶかを考えればわかりやすいでしょう。

イノベーションを起こすような特異な性質を持っている候補者は、採用プロセスの段階で突出するので目立ちます。目立つことより同種の性質を持つ候補者を選びたくなるのは、安心できるからです。

なぜ安心できる候補者を選ぶか

これは、現状のビジネスが人月商売だからです。人月商売では、エンジニアであっても指示され期待したように動くエンジニアが重宝されます。

つまり、指示されて動くオペレータとしてのエンジニアが望ましいのです。そうしたビジネスを日常行っているマネージャがイノベーションビジネスの観点でものを考えられるかどうかと言えば、普段から馴染みのない領域ですからハードルは高いことがわかります。

採用でイノベーションを起こす人材を候補者から選びたいとしても、採用判断をする側がそれに対応できていないのですから無理なのです。

上位のマネージャから変えないと実現しない

それは既存のエンジニアから選抜してイノベーションビジネスを立ち上げようとしても既存ビジネスの延長線でしかアイデアが出てこないのは前述の組織的な背景があるからです。

人月商売をしているSIerでは、イノベーションビジネスを立ち上げることができないのは、組織的な文化的背景があるためであり、そうした組織に根ざしてしまっている家風については上位のマネージャが治外法権の領域を確保し、今までの採用基準や選抜をするリーダシップを発揮しないと実現はできないのです。

通販を不在で受ける方法はリスクと初期コストが見合わない

news.livedoor.com

「コメント欄に玄関先に置いて」はちょっとなぁ、と思います。ブクマに書きましたが、クロネコとしては、

「クロネコメンバーズで在宅の時間を指定して」

でしょう。空き巣が見つけたら誰が責任を負うかまで考慮するのが運用設計ですから。

以下は１つのアイデアなので検証をしていません。よって、実施することは許可しません。もし実施した場合、何がおきても実施した者が責任を負うものとします。

クロネコメンバーズをした上で不在時の受け取りをしたいなら、次の案が挙げられます。

運用対処案
・施錠できる収納ボックスを用意する
・施錠用の鍵が掛けられることを確認する
・しかるべき手段で配送業者に不在時の対応を伝える
　・収納ボックスに入る場合は、収納し、施錠する
　・収納ボックスに収容できない場合は再配達する
前提事項
・この運用による責任は荷物を受け取る側に責任がある
・運送業者が荷物を入れないまま入れたと主張した場合、それを証明するのは荷物を受ける側である
・防犯ビデオが必須
・通販の箱は中身より大きい
・特に当日配送はその傾向がある
・集合住宅（アパート、マンション）では使えない
・収納ボックスの設置場所は路面から見えない場所が望ましいと思われる
・収納ボックスには、所有者がわかる表記を付す

上記の他にも前提事項はいくつも挙げられます。

運用対処案を実施すると家庭を置いた場合、掛ける手間、前提として準備すること及び負う責任範囲を明確にした上で新たに線引きし直す範囲を荷物を受け取る側の対処と初期投資を考慮するとクロネコメンバーズで在宅時間を指定する方が低コスト、低リスクであることが明らかです。

得てして、少額の通販時にトラブルが起きることはあるあるですし。

エンジニアの報酬は投資として捉える

エンジニアも組織の中で働いているなら、報酬は仕事に対する給与の形で示されます。目標管理制度が導入されている組織であれば、前年の目標達成に対する評価の結果が今年１年の月棒なり、年収なりの形で返ってくる仕組みになっているでしょう。

ではエンジニアの報酬は給与だけなのでしょうか。

エンジニアの広い意味での報酬

給与は労働のかなりを占める目的でしょう。さて、他にあるか。こうした質問は社員意識調査など社員の組織での満足度を図るアンケートの中で多岐にわたり並べられる選択肢で表現されているものです。例えば、スキルを発揮できる仕事についているかとか、仕事量の不平感はないかとか、オフィス環境に満足しているか、などです。

では、マネージャが裁量でエンジニアに与えられる報酬とするとどのようなものがあるでしょうか。

マネージャが与えられる報酬の種類

マネージャのロールのポジションにより裁量は広く又は限られますがいくつかあるものです。それを意識することでメンバに対し、様々な働きかけをできるのです。

・期待する業務の成果に対する評価
・技術的なスキル範囲又はレベルの成長に対する評価
・期待する技術習得の機会
・期待するロールに対するアサイメントの機会

これらの報酬は、大別すると実績に対する配当の意味合いとこれからの期待に対する投資の意味合いがあるのがわかるでしょう。

人材開発が投資であると言われる理由

事業で、特にエンジニアはプロジェクトや事業で大きな割合を占めるリソースで、人的リソースとも言われます。

オチは前に出ているのですが、実績に対する配当の意味合いのある給与への反映と将来の事業のために事業の多くのリソースを支える人的リソースであるエンジニアに対して直接、資本を投下する投資の二つがマネージャのできる報酬の使い方です。

人的投資の捉え方を変える

 例えば、エンジニアに対して教育を選抜することはこれからの事業に対して優先的に組織が投資していると見ることができます。

枠があるからただ行かせるのではなく、（例えそうであったとしても）投資として選抜して教育の機会を与えていると明示的にメッセージすることで講座に行くメンバをその気にさせることができます。

駆け出しマネジャーの成長論 - 7つの挑戦課題を「科学」する (中公新書ラクレ)

経営学習論: 人材育成を科学する

フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術 (PHPビジネス新書)

エンジニアに「おやつタイム」を

外から見るとなんともひどいプロジェクトに応援というか立て直しを請われたときの３ヶ月の働きぶりは、労働時間的には超ブラックではないかと思われるだろうなぁと思うのですが、当事者であった自分の感想は、

「まだ時間的に余裕があるからな。完全に詰んではないし、限界までののりしろはあるかな」

っていう感じでした。その際に習慣にしていたのは午後のおやつタイムです。

おやつタイム

打ち合わせがあればその時々で時間を変えていましたが、３時まで頑張ると意思力を働かせておやつタイムまで雑多な仕事を片付けることに集中することを言い聞かせて処理していました。

今思えば、あのおやつタイムは自分を甘えさせていたのだなぁと思うのです。だって、今必要ないもの。もちろん、今は当時のような労働時間的にハードな働き方をしていませんが、クリエイティブ性については仕組み化などの仕事の建てつけを考えたりステークホルダー間の調整をしていたりするので難しい仕事はどっちと言えば、今の方です。

なので、もし、仕事の難易度で脳が疲れるのであれば、今の方が疲れるはずです。

意思力のないところをおやつタイムで誤魔化している

これらの体験から比較すると、おやつタイムがあろうがなかろうが仕事に集中するために糖分はおやつタイムを設けてまでは必要ないというのが経験則です。

これは逆に意思力がないことをおやつタイムで包んで隠していただけなのです。おやつタイムで得られるのは、萎れた意思力のリセットとスイーツの脂肪だけです。

仕事を片付ける意思と気分転換には役に立つ

では、全くもっておやつタイムは仕事に良い影響を与えないのからやめた方がいいのかと言えばそうでもありません。何事も一面から見て判断していてはよりベターな結果を自ら捨ててしまうことになります。

おやつタイムは、意思力を復活させる呪術として使えば良いのです。

例えばこんな感じの1日だったらどうでしょう。 

9:00	朝会
	各自作業・打ち合わせ
12:00	お昼
	各自作業・打ち合わせ
17:30	定時

 意志力を保って２時間以上作業を続けるのはしんどそうです。メンバだって同じでしょう。

人は目標がある方が集中しやすいですし、集中していた方が成果が得やすいです。

であれば、○○時まで仕事の区切りをつけよう、と仕事をする方法をとってもいいのです。ですから、おやつタイムを15:00にセットします。 

9:00	朝会
	各自作業・打ち合わせ
12:00	お昼
	各自作業・打ち合わせ
15:00	おやつタイム
	各自作業・打ち合わせ
17:30	定時

おやつタイムに雑談してリラックスをしても良いですが、集中している状態を切ってしまうとまた集中するところからになってしまうので、コンテンツをスイッチするのが良いです。

例えば、おやつを頬張りながら、気になっていることを話すとか、技術的な相談の場にすると情報共有が進むのでおすすめです。

このおやつタイムはおやつを頬張るためのマイルストーンとして使うので、ある意味スイッチの切り替えで使いますから、リラックスしすぎないようにした方が良いです。

意志力が続けば不要なのですが、続かない気移りする動物が人なのです。意志力が続かないことや、情報共有や相談の場を設けること全てをおやつタイムでオブラートに包んでしまい、チームの成果を出すことも一つの方法です。