SIer思考とサービサー思考を眺める
別のエントリを用意していたのだけれど、お節介かもしれない（確実にお節介ではある）だろうが、ブコメを読むと書き手がどこの立場で話していて、読み手はどこの立場で読んでいるか、一度足元を確認してから読み直してはどうだろうか（別に仲裁するつもりもないし、燃料を投下するつもりもない）。
まあ、1つ目のエントリを読みつつ、どこの立ち位置から話しているかを読み手に委ねているので読み違いを誘発しそうだな、と思いながら読んだ。そういうこともあり、読んだ人だけわかればいいかと思い1つ目のエントリを踏まえ書いたのだが、なにせニッチなエントリである。
1つ目のエントリは案の定、ブコメは色々なコメントで賑わっている。
当ブログは物好きしか読まないから、読者の方だけでも参考になればと思い、事業会社の業務とIT、並びに、SIerの立ち位置を下図のように表現してみた。
正月早々、賑わっているエントリの書き手の方は、2つ目のエントリに書かれているとおり、事業会社側での見識しか知らないと書かれている。
私はSIerにいたことがないので、そのあたりどうも疎いのですが、私としては「業務知識といえば、業務実現に必要な知識すべて」のことで、それは担当する業務によって変わってくる、ということではないかな、と思っております。そういう筋で前回のエントリを書きました。
配慮の行き届いた親切である。
で、もう一度、図である。
件のエントリの書き手は、四象限の中の人の立場で語っている。一方、ブコメで『業務知識とは…』と書かれているいつくかのコメントはL字のSIerの立場でエントリを読み、それぞれのご経験で書かれている。
まあ、そうだな、でしかない。
自分も事業者側の仕事の経験を持っているので、言いたいことがよくわかる。もちろん、SIerとして、事業会社の業務のIT化を外部リソースの立場で業務委託を受けたこと経験もあるので、その立場でのものの見方もわかる。
事業会社の経営者は、業務を分掌した担当に業務（IT化を含め）を任せているのが現状である。それはサービサーにおいても同じである。業務主体は組織であるから組織で権限分掌を行い、事業を遂行する。
その際に、経営者はITに対して見識なり、事業計画を実現する上でキーファクターとなる技術を見極める知見を有していれば、業務のIT化に関与、つまり意思決定（図の右上から左下への点線矢印）において的確に格段に早く判断できるようになる、ということである。
それで書き手の方は、事業者として生き残るいはAIやIoTや様々な最新のITで業務自体を事業者側自身で変えていく必要がある（MSの事例などがそれ）のだろうから、経営者の判断で業務自体をITに置き換えていく（金融機関のトレーダーの話がそれ）主体者にならないと事業を継続していくだけでもしんどいのでは、と言っているのではないだろうか。
それで結局、業務知識にITは云々の話である。
業務知識を持たない（事業会社）のリーダ（経営者）で大丈夫かヤバいかであるが、経験的にITに詳しい経営者の方だと話（意思決定）が早い。もちろん、詳しい分、業務担当者へのプレッシャは高くなるし、色々とハードルも上がる。ただし、課題解決への意思決定に伴う予算の付け方は格段に良くなる。
さらに、経営者は先をみているので（その上、先行分で失敗する時間もできるので）生き残る可能性は少し高い。つまり、そういうことである。
決定版 猫と一緒に生き残る 防災BOOK (いちばん役立つペットシリーズ)
- 作者: ANICE(アナイス),村中志朗,富田園子,猫びより編集部
- 出版社/メーカー: 日東書院本社
- 発売日: 2018/12/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
新人エンジニアを抱き合わせで連れてこられて大丈夫か
プロジェクトの立ち上げでは、その大小に関わらずプロジェクトとしてのスキルセットを持ち合わせていないとプロジェクトは必ず行き詰まる。ろくに考えもせず、モグラ叩きの好きなマネージャや間抜けなプロマネが人数だけいれば、後はメンバでなんとかしてくれるだろうとやるから確実にやれるウォーターフォールのプロジェクトでもお祭り騒ぎになるのである。
そして、なんとかしてくれと泣き付かれる。個人的にこんな采配をヨシと意思決定するマネージャやプロマネはそのロールから引き摺り降ろしたい。やるなら保険（リスク対策）まで掛けた上でon goingなプロジェクトにしないとそれを丸投げされたエンジニアはたまったものではない。
そうしたプロジェクトをレスキューしたとき、バサバサと人を斬った、じゃない、ご退場願った。切られた協力会社のマネージャや営業は売り上げを確保したいらしく、その代替としていい感じのエンジニア＋新人エンジニアを連れてきた。これで手を打ってほしいという。
貴社の売りなんて自分には全く関心を持っていないのでそんな事情は考慮しない。こっちとしては、これまでいくらドブに捨てたかわかっているのか、と問いたいところだ。同じようにドブに捨てるくらいなら人的リソースを補給せず、自分の懐に納めておきたいくらいである。
総合的判断を行い、できそうなエンジニア＋新人エンジニアを採用することとした。このとき、どのように判断したか。ここはほとんど明らかにされないものであるから、こうした機会を通じて以下に記すので参考にして欲しい。
抱き合わせでも採用した理由。
- コストの観点
予算的には全く問題がない。元々の見積もり工数の山積みと採用時の人員では余裕がある状態であった。 - 作業工数の観点
色々と諸事情のあるプロジェクトを常識の通じるプロジェクトに変える見通しがつき始めたころ。見通しがつき始めた頃、という点がポイント。まだ、実質のリソースは不足しているが、この採用でできそうなエンジニアが期待に応えてくれると見通しの確度が上がる。新人エンジニアについては、作業のオペレータとして手順書通りにやってくれれば、それはそれで進捗を伴う。そうした期待を持てた。 - 品質の観点
バサバサと斬り、新チーム体制に変え、メンバの顔を同じ方向に向かせ、一つひとつのタスクの完了条件（doneの基準）を検査し始めると途端に品質を確保できるようになる（なにせ、基準を満たしていなければ受け入れないので必死にやってくれる）。そうした途上であったから、同じルールでやってもらうので影響は受けない（受けたら斬ればいいと決めておく）。 - タイムの観点
無秩序なスケジュールを日々の生活、１週間の過ごし方、１ヶ月の過ごし方とそれぞれのサイクルを示すと、そのマイルストーンに合わせてくれる（さすが日本人気質である）。作業量とリソースとパフォーマンスを把握し、やれそうだと見極めておく。メンバにやって欲しいことを詰め込みし過ぎないように示せば自分たちで考える。大人であるし、ここまで立て直してくれているメンバに入れ替えでの採用の二人でやりきるように調整してくれる。 - リスクの識別
内部的なリスクは、入れ替えで採用するエンジニア二人である。どの作業を誰がするかはメンバに任せる。やりたいメンバがやってくれて、終われば良いのである。最初のタスクで出来不出来さえ見ておけばいい。後、新人エンジニアがTPOを弁え、指示どおりにやらなければならないところでは指示どおり（言葉どおりで、新人エンジニアが独自で解釈して勝手に指示されない作業をすることがない）にやってくれればそれで支払う費用の対価くらいにはなる。外部的には、自分が識別すればいい（もちろんメンバにヒヤリングを掛ける）し、そうしたリスク対策用にプロジェクトバッファを持っておくくらいにはなっていたからどうにかなると見極められる状態になっていた（これができないと即死である）。
これが自社の新人エンジニアであれば、育てるという観点が入るので話は全く変わってくる。最初からちゃんと育てることを意識してタスクを渡さないと将来困るのは自分たちなのである。ビジネスをキャリーしてもらう候補であるのだから。
身につけるまで10年掛かる業務知識、トレンドを追う業務知識
昨日の業務知識をテーマとしたエントリを書いた後、20年くらい前に『それはやばいな』と思い出した。
その前に、昨日書いた業務知識の元のエントリでは、どうやら最後に述べたことがそのエントリで言いたかったことだったようだ。端的に言えば、ユーザ業務ではなく、ユーザ業務を実現するITを含む、というものである。
20年前のことに話を戻そう。
当時、所蔵する組織のミーティングか研修か何かしらの集まりの場でエンジニアが一人前になるまでどのくらい時間が必要かというものだったと思う。
- 身につけるまでに10年掛かる業務知識
ある事業所では、事業会社のアプリケーションを開発しているが、一人前に育つまでに10年かかるのだという。10年掛かるのはそれだけ知識として必要となる業務が複雑で難易度も高いことが考えられる（詳しくは知らないので想定でしかないがそうでなければ辻褄が合わない）。さらに予算的な制約があり、何人もエンジニアをつけることはできない。一見、同じようなアプリを維持するからなり手も無いのだという。
ただ、育成するための準備を十分できているかどうか、業務知識を学ぶための環境を整備しているかどうかという疑念は残る。前述の制約からこうしたところまで手が回らず、悪循環になっているのかもしれないし、教える側が旧態依然とした見て覚えろ系かもしれない。これについての真偽はわからない。
こうした書き方をすると、そのビジネスから撤退すればいいじゃ無いかと考える人もいるかもしれない。補足しておくと、その事業は全体では大きい事業であるからそこだけ撤退することはビジネス的にはできないのという事情がある。
極端であるが、このようなビジネスにおいてマネージャやリーダに必要な業務知識とは、身につけるまでに10年掛かる業務知識でも実現するIT技術でも無い。
若かったかもしれないし、必要性はあるとしても、その10年も業務を知るために時間を要する現場はたまったものでは無いな、と思ったものである。
特に、1年でどのような成果を出すか＝どのような新しい技術を身につけるか、ロールを上げるかを考えるようになると、そうした業務には考えさせられるものがある。
- トレンドを追う業務知識
業務知識とは、事業者のセクターに根を下ろすドメインに依存するものばかりでは無い。どのセクターの業務でも共通する業務があり、その業務を切り出して共通業務と捉えることもできる。本社管理系はそれに該当するし、業務システムやインフラ基盤でも共通の業務として必要な業務知識もある。
こうしたものに該当する業務知識のなかで、技術的にトレンドを伴う業務もある。そうした業務では技術トレンドが速いため、実現するIT技術も新しい技術を適用することが多い。こうした業務では、業務知識の他にIT技術まで含めた知識を必要とする。要は、業務＋IT＝業務知識の構図となっている。
トレンドを追う業務知識では、潮流が速いため意思決定を遅らせると致命傷となる。よって、リーダやマネージャは業務＋ITである業務知識を持ち合わせなければ即死するかもしれない。ただ、それが無理であるなら、業務知識としてITをわかるロールをリーダやマネージャにおかなければならないだろう。
これから前者から後者に移るかといえば、そうだろうし、その転換は急な業務もあるだろうし、影響を受けない業務もあるだろう。リーダやマネージャは、担当しているビジネスがどれに当たるか見極められる能力がないとエンジニアは巻き添いを食うかもしれない。
いや、エンジニア自身がそれを嗅ぎ分ける必要があるのであるが。
10年後、君に仕事はあるのか?―――未来を生きるための「雇われる力」
- 作者: 藤原和博
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2017/02/10
- メディア: 単行本
- この商品を含むブログ (3件) を見る
その業務知識、リーダが持たなければなりませんか
昨日見かけたブログで『業務知識を持たないリーダーで大丈夫か？』という問いかけがあり、自分が携わっている事業会社のことや組織の中でのリーダの分掌とは、などをモニョモニョと考えていた。
きっかけのブログでは、組織づくりばかりしていても製品は良くならない、と戒め的なことを書かれていて、ごもっともだなぁと思う。
さて、観測の範囲（携わっている事業会社や過去の別の事業会社など）を一般論として考えると、組織構造は、現業である事業部門と本社IT部門で構成されている。もちろん、事業部門は製品開発や販売をするのでそのトップはその事業を経験されてきている方がされている。製品開発もIT投資も主体者は、事業部門であり、本社IT部門から見れば事業部門主管のIT投資は関与できない。できて予算管理だけである。こうした形態を取っている事業会社のリーダは、必然的に業務知識を身に着ける。
本社IT部門は、事業部門でのITを担っていた人が異動するか生粋のIT部門のメンバで構成する。場合によっては、情報システム子会社やベンダから出向というケースもあるようだ。多分にこの本社IT部門で生粋に育ってしまうと件の『業務知識を持たない』部員を育てることになってしまう。リーダ（要はマネージャ）が事業部門経験者であれば、そうした危惧を抱くことはままあるようで、『一度現場を経験させないとあとあとIT企画で現場を知らない計画を作るから本人のためにも良くない』と言う。
上述の事業部門と本社IT部門を比較すると、リーダで『業務知識を持たないリーダ』になる可能性が高いのは本社IT部門しかない。
他の可能性を考えると、所謂、MBA持ちのエリートがトップやそれなりの役員のポジションに就くケースだと『業務知識を持たないリーダー』を産んでしまう。ただ、そうした人たちは、仮説検証型で進めるから、仮説を立てる際に相応の情報を収集し、意思決定する（ハズ）である。
そうすると、それ以外でどのようなケースがあるかを考えると中間管理職で担当事業の業務知識を持たないリーダがいる場合を思いつく。リーダ（マネージャ）になっているのでもともと勉強ができる人たちだった（ハズ）だが、それをしなくても仕事としてなんとかなってしまっていると業務知識を持たなくてもそのポジションであれば生き延びているのかもしれない。ここのポジションこそ、エンジニアのコンタクトが多いロールである。
製品開発であると部門長かその下の部長級のイメージを持つのだが、そうした役割の人はメンバのやっていることに対する説明責任を持つから、概念的には理解できている（ハズ）だが、ここでの問題は、意思決定にウェイトの軸を移しているから、技術の良し悪しまでは結果的に手薄になってしまうと言うことが問題なのかもしれない。
製品を早くリリースすることで市場の反応をみて、開発にフィードバックするようなビジネスニーズがあるのであれば、分掌を見直し、技術まで見極められる職務とする調整を行う必要があるかもしれない。
結局、組織としてどうしたいかがないと分掌の見直しはできない。それはトップが指示すれば良いのである（組織デザインをするのは経営者）。そのトップに意識づけをするのは、ビジネスニーズ（ざっくりとまとめ過ぎ感はあるが）である。
ここまで書いて、事業部門と本社IT部門と分離していないケースであったらどうかと思いつく。多分、こっちの方が本命なのかもしれない。事業をしていて自らシステムを作り上げる。SaaSer的な事業などがそれにあたるのだろう。
この場合は、事業とITが同じ役割なので前述した分掌の概念が当てはまらない。つまり、製品開発を間違えるとダメージが高い割に分掌出来ていないために、リーダやメンバのリソースをミッションレベルで奪い合うためムラが出る。それを回避する前提を設けないとITに専念できない。組織を弄くり回すことは一切無駄であり、しなければならないのは、業務知識を持つロールを置くことである。それはリーダである必要はないが、リーダはどこで意思決定するか、そちらの特性を持っていなければならなくなる。
その見積もり、見積もりになっていません。
元旦から 今年の褒める心構えはちょっと違う と心に決めたので、今日も褒めようと思う。メンバのことではないのでそこまで自分を縛らなくてもいいのだが。
年末、ひょんなことから見積もり本を手にした。それを年末年始に掛けて読んだのだが、読んでいて辛い。見積もりを知らないエンジニアに見積もりを知って欲しい、参考にして欲しいと前書きに書かれているので、自分のようなおじさんは対象読者ではないのかもしれない。であれば、自分がそれを読み、辛く感じても良いのだろうし、対象読者の絞り込みに応じた書きっぷりとして正しい。
それを踏まえて、どう消化したか、である。
おじさんの自分は、いわゆるWeb界隈のエンジニアから見れば対極にあるSIerのエンジニアであり、マネージャである。開発部門に属すれば、引き合いに応じて多くのコストを掛けてプリセールス活動し、見積もりをする。自分で書くときも稀にあるがほとんどはメンバにやってもらう。構成や過去に資料で使えるスライドを引っ張り出すのも役目である。コストを積み上げ、営業と値付けをつける。そこまでの間にリスク識別や組織内のプロセスを回す。案件によるが、RFPや入札では時間との勝負なので、遅くまで資料作りをすることもあるし、それに掛かるレビューでは多くの関連部門の協力を乞うのである。
SIerのおじさんにとっての見積もりとは、こうした組織だったものだ。
件の本を読むと前半は基礎で、後半は事例である。多分に若いエンジニアの方々により執筆されているということを確認できる。
まず、若いうちからこうした執筆をしたということを褒めたい。自分に置き換えたら、やっていなかった。基本的に、自分より先にやっている人や自分より挑戦する人などをとても素晴らしい才能を持っていると思っている。
ワイフも色々とできる人で尊敬するのはそうしたことを幾つも持っているからである。
人は、経験したこと、得た知識からでしか言葉を紡げない。あとできることは写経になってしまう。写経も写し、自分の中に取り込み、消化し、自分の言葉で表現しなおせれば良いのである。
さて、見積もりのコンテンツの中に相見積もりとRFPを比較したコンテントがある。先に述べた自分の背景から言えば、RFPも相見積もりである。何せ、入札なのだから、応札で複数の業者が札を入れれば競争入札の体をなす。これは見積もり条件をapple to appleとして相見積もりを取りたいからそれをするのである。
1つ勉強になったのは、RFPで入札価格を発注者側が提示するということである。これまで、競争入札、RFPで入札価格の提示を見た経験はない。
検索してみると、発注者側が入札価格を提示するケースは半々で、提示することに対して賛否両論なのだという。
【記載すべきでない派】
「ベンダーの過去の経験を買うのだから，実績あるベンダーの見積もりは安くなるはず。提案の金額にはそれを反映できるはず。だから予算を記載する必要はない」（発注者）
【記載すべき派】
「少なくともどの程度の規模のものを想定しているのかをはっきりさせなければ，レベルの全く合わない競合になってしまう。ある時，A社は1000万円，B社は1億円の見積もりを持ってきたことがある」（発注者）
ただ、記載すべきではない派の方が多数なようだ。
もし知らなかったのなら、参考にして欲しい（執筆者には届かないだろうが）ことの1つに、RFPの前にRFIを行い、プロジェクト化したいテーマについて複数のベンダに情報提供と過去事例での参考価格を照会するのである。
これをインプットに発注者側である事業者はRFPを書くのである。であるから、発注者側はベンダの費用感や発注者側としてのプロジェクト全体の予算を立てるのである。さらに、複数のベンダに照会をすることで見積もり上の諸条件を揃える（抜け漏れ防止）のである。
脱線をしたので話を件の本に戻すと後半の事例の中で2つほど読みながらつらみ（あるあるでその気持ちを理解できる）を感じた。
今年の褒める心構えはちょっと違う
以前に比べれば、去年はそこそこメンバを褒めることができたのではないか。でも会話の中でどのくらい褒めてあげられたのだろうかと思い出してもよく思い出せない。やはり、あれこれと（やっていいかとか、確認を聞きに来ることが多いので）事務的に指示するシーンばかり思い出してしまう。それでも、それまでより去年は笑顔で褒める機会を意識し、褒めることができたはずだ。
褒めるために意識すること。
無意識に褒めようともせずに褒められるとしたら、それは素晴らしい才能である。そのような才能をお持ちなら色々と勉強させて欲しい。ごく稀にそういう人がいるのが世の中の不思議ではある。
才能のない自分なりの褒めるために意識をする。心構え的なものである。
- 話しかけられたら、一呼吸おく。
- すぐに応えない。
- 感情を感じたら黙る。
褒めるのはメンバである（上長を褒めることはしない）から、基本的なハンドシェイクはメンバからである。つまり、自分は受け身であることが多い。もちろん、自分から声を掛け、話を聞きに行くこともある。そうしたときは、不意を突かれることはないから、心構えは取りやすい。
一呼吸おくのは、一旦、メンバの話を全部聞く、というポーズである。ポーズである。
すぐに応えず間を取るのは、メンバが何をしたいのか、どんな許可をもらいたいのかを知るためである。その時間をこちらから取りに行く。これはメンバの実現したいことを全部聞いた上で、意思決定すれば良いのか、情報提供（知っている人を紹介するとか）すればいいのか、却下するのかを意思決定するためである。
肝心なのは、この３番目の感情を感じるかどうかである。もちろん、この感情は自分のものでメンバの表情から読み取るようなものではない。メンバから何か尋ねられて、感情を感じるようなメンタル的なゆらぎを感じたら、それは多分に、自分にとって都合の悪いことか、準備不足などの痛みを突かれたときである。
そうなのだ。年齢に関係なく、ウィークポイントに触れられるとまるで地雷を踏んだよに相手の思考は飛び、感情だけで切り返して来るのである。
そうしないためのもう1つの心の準備がある。それは、
- ゆっくり話す。
である。ただ、このゆっくり話すも不意には弱い。メンバのスピードに巻き込まれるためだ。
そこで、秘蔵の技を備えておく。
- そうきたか。
これは孤独のグルメの五郎ちゃんが食事のときによく使う。自分の想定と違う場面に想定したときや、不意打ちを突かれたとき、とても使い勝手が良い。ただ、切り返しの難易度が高いので、身体を伴う反応を身につけてからの方が良いだろう。
今年は、『（そうきたか）』と内心で思いつつ、去年より褒めることに努めよう。
