天はエンジニアに二物を与えず

天はエンジニアに二物を与えず

経営者にもしかり

経営者が求めればそれは無い物ねだり

天はエンジニアに二物を与えず 経営者にもしかり 経営者が求めればそれは無い物ねだり / “スタートアップベンチャーはスーパーエンジニアを求めるけどエンジニア界隈と起業家界隈で想像しているスーパーエンジニアの定義が違う件 - LA…” https://t.co/J9TbvFcdG3

— ふみさん (@finayama) 2017年7月12日

確かにエンジニアの技術は専門性を持たせ過ぎてサイロ化している。技術のサイロ化とはその技術しか知見を持ち合わせていないために、いわゆる潰しが効かない、と言うアレです。今はどうか知りませんが、大学の学部で潰しが効かない、なんて言う表現を聞いたことがあるのでそれと意味合いは同じなんでしょう。

技術のサイロ化は、ソフトウェアベンダが技術者を囲い込みしたくてそうなるように振舞っていることも一因があるでしょうし、マネージャもローテーションをしないから本人が動かなければじっとサイロの奥でコツコツと技術のレンガを積みサイロを高くするわけです。

そのピークがITSSだったのではないかと思うのですよね。見た瞬間、こまけーと思いましたから。もう少し、ざっくりした分類の方が流動性が生まれていいのではないかと思ったものです。

そんなことは忘れて、やれフルスッタクエンジニア（廃れましたね！）やらスーパーエンジニア（聞いたことないですよ！）とか言われるわけです。

じゃあさ、経営者ならどうなの？経営のプロなの？と思うじゃないですか。でもね、世の中の肩書きを見てごらんなさい。CEO、COO、CFO、CTO、CISOとこれまた細分化されているわけです。

ただ、そうも言っていられないのがスタートアップ。お金の切れ目がスタートアップした事業の破産。

1人じゃマーケも開発もバックオフィスもできないから（そりゃそうだ）、2人くらいでやれよって言っているわけです。

スタートアップの"共同創業者"を選ぶ技術 from Takaaki Umada

www.slideshare.net

それでもやはり兼務でいくつかの役割はやらなければならないのは変わりませんけど。

同じなんですよ。だから、経営者がエンジニアに全てを1人で担えって言うのは、そう言うお前はどうなんだ、と言うことなんですよ。自分に自分の人差し指を向けろよってことです。

ただ、その上で複数の役割を担えることはできないとエンジニアは技術のサイロから抜け出せず、サイロに仕事という備蓄飼料が供給されなければ仕事から溢れてしまうんですよ。

そうならないための技術的なスケールアウトしなければならないんです。上手に持っている技術的なアセットを活かしながら。

なので、天はエンジニアに二物を与えなかったが、エンジニアは自らスケールアウトして二物を得た、を目指すのです。

モブが潜在的な問題にスポットライトを当ててくれる

モブの良いところは、タイプする人（ドライバ）はキーボードを打つだけ、モニターを見てアドバイスをする人（ナビゲータ（ドライバ以外））は何を打てばいいか教えることと役割を分担するんですが、全員でアウトプットに関与できるんですね。

モブのいいところは、モブで物作りをしている最中にコードなりを書くわけで、そこでナビゲータが何をタイプするかを発言するときに他のモブとこれからタイプすることの背景や仕様についてコンセンサスを醸成させながらドライバに伝えることになるんですね。

そのとき、モブ同士で背景や仕様についての理解、解釈についてどう捉えていたかがズレを可視化するんです。さらにいいところが可視化した上で、共通の理解をコードなどで具現化していくんですね。

そうなんですよ、モブをすると理解したことがアウトプットされるから違ったまま解釈していたなんてことがなくなるんですね。

これ、すごいことなんですよ。

仕事は複数の技術を組み合わせないと実現できなくなってしまったので、技術を持っている人を集めて、分業するようになっています。

そういう人たちでチームを編成して運営するとチームの目的を達成するために、目的の刷り込みと自分の担当の仕事を終わらせるためにインプットの要求とアウトプットの仕様をチームのメンバに伝え続けるのが仕事の大半になってしまっているんですね。

つまり、コミュニケーションが仕事の大半なんです。それをモブだとその場で完結してしまうわけです。

モブがコミュニケーションに問題があるとスポットライトを当ててくれるし、モブで解決する手段を担ってくれるんですね。

ただ、本当に解決するかどうかはメンバ同士、チームとしてタックマンモデルの平常化期くらいにはなっていないとモブをしながらナビゲータ同士で衝突をすることになるのでコンセンサスが取れずにアウトプットできない、なんてことになりかねませんけど。

Kindle本50%OFF大型セール エンジニア向けビジネス4冊

ビジョナリー・カンパニー　時代を超える生存の原則

ビジョナリー・カンパニー２　飛躍の法則

イノベーションのジレンマ 増補改訂版 Harvard business school press

リーン・スタートアップ　ムダのない起業プロセスでイノベーションを生みだす

資料作りはトップダウン志向の方が断然早い

ちょっと年次が上だと思う（同僚でも部下でも年齢とか全く興味がないので確かめてもいないで…）メンバにアサインした仕事がどうも怪しい。

状況証拠として、以前にも資料作成を任せたとき

「期待するようなイメージとは違うな」

と感じていましたが、出来上がった資料は、資料としての目的は達成していたのでそのままで通したんですね。だって、イメージと違うというのは感性の違いのようなものですから。細かく言えば、イメージも伝えていたけれど、伝え方を考えないといけないな、と思った方がちょっとばかり強かった、と思ったくらいで。

アサインした資料作りは企画の資料なので、企画の目的とか、達成したいこととかあるわけです。それで1回目の打ち合わせで関係者でざっくばらんに思いがある人は言いたいことを言って、じゃあ、ざっくりとできたらもう一度やりましょうとなって解散、と。

次回の日程を先に決めてしまったあと、デスクでなんとなく悶え唸っている感じなんですよ。なんとなく「嵌っているな」と分かる感じです。程なく、メンバから声を掛けてきたところは、さすがベテランです。抱え込まない程度に周りを巻き込もうとする。これはいいですよね。

「例の件、相談に乗って欲しい」

なんだかんだ、相談に来るまでに２−3日使っています。その間に作った資料で説明してくれるとのことなので最初は黙って見ていようと思ったのですが…。

構成から考える

企画の資料に関わらず、文書は伝えたいことがあります。要件なのか、仕様なのか、操作手順なのか、事故内容なのか。何かしら伝え、残したいことがあるから文書という形態で作成するのです。でなければ、口頭説明で済ませますから。

口頭説明だって、伝えようとする内容を相手に伝えたあとに相手の行動を変えようと思うなら、伝え方の順序や伝え方を考えます。そうしないと結局何の話をしたのか、相手も何をすれば良いのか明確でなくなってしまうからです。

文書の場合は、形にしながら伝える手段を作っていくことができます。文書で何をしようとするか頭に思い浮かぶまま形作るのは必ず手戻りが発生するのでいけません。

伝えようとすることは、話の持って行き方を考え、構成として表現しなければなりません。

エンジニアはボトムアップで構築してしまう

ざっくばらんに話をしたときに好き勝手に話すものだから、枝葉末節なことや具体的な例でイメージアップします。これはこれでいいのです。ただ、企画の文書にはそうした具体的なイメージは出すタイミングがあります。でもその前に骨格、シナリオを作らねばなりません。

エンジニアに任せると得てして多いいのは、具体的な事象とか製品とか諸元とか

「詳細設計しているの？」

と聞きたくなるような資料作りです。相談に乗って欲しいと会議室に誘われたときに作りかけの資料も同じでした。

いいから図を描け

ボトムアップで考えていく人は、文章を多用します。結局、言葉はその言葉の意味を持っている人により意味合いが変わって来るので初見で同じイメージを複数のメンバで持つことはできません（キッパリ）。

企画や上流の場合、順次詳細化は企画や上流の下工程でやることです。今やらなければならないことは、企画の資料を作ることです。

どうしていいかわからないときは、まずは頭に浮かぶことを全部、手書きで、イラストにすることです。

企画なら、仔細なことを考えるのは企画案の検証と事例を挙げるときだけで十分です。ホワイトボードに1人でブレスとするようにイラストを描いて自分に向かってイメージアップしろよ、です。

目的、範囲、方針、規模感、日程感

構成を考えるというとなんだか難しいですが、標題の5つを目次にしてそれを必要に応じて、ちょっとだけイメージできるページをつければいいのです。

・目的は、なぜそれをやるのか
・範囲は、どの世界の中で境界線を引いて対象範囲とするか
・方針は、考え方で後々の行動基準になるものです
・規模感は、必要なリソースのざっくりしたもので、3人で半年とかそんなイメージです
・日程感は、平たく言えばスケジュールですが四半期程度でレベル１くらいの作業が記載したようなものです

なぜこれを作らないといけないのか。相談にきたメンバが持ってきた資料の説明の出だしで聞いたのはこれです。

「なぜそれをやるの」

やれと言ったから、ではダメです。それでは、仕事が進んだ後に声の大きな少数の人達に振り回されます。一番最初に、こうした全体の考え方を握って、何かあったら立ちもどれる場所を作っておくのです。

そしてこうした考え方で進めていて後々都合が悪くなったとき、考え方のパラメータを調整するだけでほとんどのことは吸収できます。

これをボトムアップで作るものから、詳細な事例から積み上げていったらいつになっても範囲も決まりませんし、全容にたどり着きませんから、穴が開いた状態でものを考えるようなものです。

ということで、資料作りはトップダウン志向でざっくり方針ぎめすればたたき台作りなんて1日もかかりません。まあ、コンセプト作りは別に時間が必要ですけど。

普通に終わらす方を評価しよう

togetter.com

プロジェクトXは嫌いではないけれど、録画したり、時間を確保してまで見ようとは思わないですね。取り上げられるテーマに興味がある場合、例えば杜氏だとか自分の興味がある場合だけ録画する程度なので1年に数回あれば見た方なんですね。

なんでもそういう傾向があるんだけれど、やたらと感動を前面に持ってきて評価するのにうんざりとしているんですね。映画や書籍ならわかります。エンターテインメントですから。

でも、プロジェクトに感動はいらない。

頑張ったという扇情的な言葉もいらない。

チームビルディングをして、計画を立て、実行して、計画と実績の乖離を計測しつつ、計画を修正しながら当初の目的を達成できるように手持ちのリソースをタイミングを逃さずに投入する。

これのどこに感動する要因があるのでしょうね。フィクションならいいですし、試行錯誤するような結果により次を決めていくような活動ならそれもまたありかなと思うのです。

ただ、計画を立てて活動するものに感動はいらないし、頑張ったという意味のわからない評価基準を持ち出すような評価はしないです。

無計画で、行き当たりばったりで、周りを（悪い意味で）巻き込んでやりきったなんて評価しません。それよりは、計画どおりに目的を達成できるように、運営する方を評価します。

無計画で、感情を前面に出す方は、プロジェクトXでも必須アイテムの残業、徹夜など無理をする方を選びます。コストまで感動的な数字に跳ね上がっています。

でも、計画を修正しながら、できる限り定時で帰る方を評価します。

計画立てて修正しながら進めるのはそれそれでやならないければならないことをやっているから計画どおりに進むのです。

当たり前のことを当たり前にやることの難しさはやらなければならないことをやるということの積み重ねだからです。

当たり前のように終わらせる方を評価しましょう。

タックマンモデル（動乱期と安定期）が混在したままチーム運営せざるを得ないのが今のプロマネの限界なのではないか

PMBOKなんてデカくて重いし、改訂の度にページは増えるし、なので滅多にpdfを開くこともよほどのことがない限りはないのですが、タックマンモデルというチーム育成のモデルの初掲載はいつだろうと調べてみたら「PMP資格取得に向けてPMBOKガイド第４版を解剖する（2010年）」に記載があったので遅くとも2008年第3版か2009年の第4版に記載されていたのかもしれません。

＃第1版1996年、第2版2000年、第3版2004年、第4版2009年

タックマンモデル

タックマンモデルはご存知かもしれないが掲載すれば次の5つの段階をチームは経ることになるようです。

成立期

この段階では、チームが顔を合わせプロジェクトの内容とメンバの公式な役割と責任について学ぶ。この段階では、チーム・メンバは、ここに独立しており、心を開いていないことが多い。

動乱期

この段階になると、チームはプロジェクト作業、技術的な決定、プロジェクトマネジメントに活動に取り組み始める。チーム・メンバが協力的でなく、異なる考えや観点に心を開かない場合は、チーム環境は非生産的なものになる。

安定期

安定期には、チーム・メンバが一緒に作業を始め、チームを支援するための自らの習慣や行動を調整し始める。ここでチームの間に信頼関係が築かれていく。

遂行期

遂行期に到達したチームは、よく組織されたグループとして機能する。相互に依存関係を保ち、課題に円滑かつ効果的に対処できる。

解散期

解散期には、チームは作業を完了して、プロジェクトから転出していく。これは、成果物を完了したり、プロジェクトやフェーズの終結プロセスが実行される一部として、プロジェクトから要因が離任されたりするときの一般的な段階である。

この5つの段階は、シーケンスにステップアップするとは限らず、チームの関係性から停滞したり、戻ったりすることもあるようです。

また、メンバの一部が以前に一緒に働いたことがある場合は、いきなり途中から始まることもあると注意書きとはいかないけれど、説明文があるのです…。

これらの段階を順次に経ていくが、特定の段階で停滞してしまったり、以前の段階に逆戻りしてしまったりすることも珍しくはない。過去に一緒に働いていたことのあるチーム・メンバがいるプロジェクトでは、ある段階を飛ばしてしまうこともある。

です…と引きずっているのは、暗黙で安定期以降に飛ぶんだろうなと思うのですが、その前提もさらにあるのではないかと思うのです。

もし以前のプロジェクトで信頼関係が築けられていなければ、動乱期のままのプロジェクトできちんとプロジェクトは終了しなかったでしょうし、そのようなメンバで新しいプロジェクトをチーミングしようなんて思わないでしょうから。

まあ、PMBOK自体がプロジェクトを成功させるための知的体系の共有なので当然と言えば当然なのですけれど。

現実には、動乱期と安定期が混在したまま続くプロジェクトが多いのではないかと思うのです。

そしてその2つの段階から脱却できないままプロジェクトを四苦八苦させながら終了させているのが今のソフトウエアエンジニアリングなのではないか、と。

プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第５版 (A Guide to the Project Management Body of Knowledge)

積み本候補

すごいチーム　結果を出すチームマネジメント１２の方程式

「学習する組織」入門 ― 自分・チーム・会社が変わる 持続的成長の技術と実践

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

チームビルディングの技術―みんなを本気にさせるマネジメントの基本18