都度編成のチームはギャンブルすぎる

プロジェクトで開発チームを編成して立ち上げ、改めてメンバの顔を見渡すと、一体どれくらいこれまでのプロジェクトで一緒に働いたことがあるメンバがいるだろうか。

プライムのSierだとプロジェクトの規模によるがリーダクラスが数人程度で、顔見知りだったとしても同じプロジェクトで活動したことがあるなんてないケースの方が多いのではないか。まだN次受けのSESの方が、案件ごとにプロジェクトルームにリソースとして供出されるので同じ組織のエンジニアがチャンクに纏められるのでいつもの仲間と同じプロジェクトをいくつも経験しているのかもしれない。

そうした寄せ集め的なプロジェクトチームでは、プロジェクトとしての形式知は集めにくく、個々のエンジニアの経験知として積み重ねられていくが、そうした経験知はエンジニアの中に収まったまま世に出てくることはない。

そうしたプロジェクトチームでは、所謂、統制型か調整型のリーダシップが発揮され、結果的にコマンド＆コントロールがなされる。

プロジェクトの形態をとっていることも、そのプロジェクトが終了すればチームは解散することがわかっているとプロジェクトを終了させることが目的に擦り変わることままあり、言われた通りにしておけばいいという受け身での関与が蔓延する。

保守、維持管理が計画され、開発したチームから残されることが判明しているとしてもそのチームに残るとは限らず、そうしたエンジニアは開発案件しか入れないとする組織であれば焼畑農法的なビジネスを繰り返すのでエンジニアのプロフェッショナリズムは発揮されることはない。

コマンド＆コントロールといえば軍隊組織を容易に想像することができるが、次の文献を読む限りそうした印象は誤ったものかもしれない。

われわれの指揮の哲学はまた、暗黙的に意思疎通する人間の能力を活用しなければならない。暗黙的コミュニケーションーーお互いを理解し合い、言葉の使用をよくわった重要なものだけにとどめ、あるいはさらにお互いの考えていることを察し合うことのほうが、コミュニケーションの手段としては、詳しい明示的な指令を使うよりもっと速くて効果的であると信じる。（『ウォーファイティング』243頁）
引用　知的機動力の本質　野中郁次郎

 これまで、経験知は形式知に、明示的なコミュニケーションを図ったほうが良いと思っていた。これは組織内でチームを都度編成していることを暗黙にしていたから前提のズレがあるかもしれない。

そう言えば、アジャイル開発チームのメンバを入れ替えない方がいいというのは、入れ替えてしまったり、チームを解散させてしまうとそれまでチーム内で醸成していたコンテクストが下がってしまったり、リセットされてしまうためだが、速く効果的な活動を求める切り口であれば指揮命令よりハイコンテクストである方が合理的だからであろう。

ビジネス形態が違うとチーム編成の方針も変わるし、チームに求める価値観も変わってくる。

ただ、そうした速く効率的なチームであっても人員の更新は避けられないが一定のサイクルであればサイクルに応じたレベルで期待はできるだろう。都度編成はギャンブルでしかない。

知的機動力の本質 - アメリカ海兵隊の組織論的研究

コミュニケーションにコストは存在するか

コミュニケーションにコスト感を感じることにとても違和感を覚える。他者がそう感じるのは別に構わないが、コスト感を感じる側がコストを下げる働きかけをしているかといえば残念ながらなさそうだ。

例えばこんなエントリがある。

anond.hatelabo.jp

簡単にまとめれば、依頼する側が依頼の条件を一度に伝えて欲しいと言うものだ。興味深いことに文脈（流れと表現）で推し量れるのであれば良いのだと言う。

確かに、依頼する側が依頼時に条件を全て提示すれば受ける側はそれで依頼側の期待に応える条件を認識することができるだろう。

ただ、ちょっと待って欲しい。依頼する側が依頼する際に条件を提示できるほど決まって依頼しているケースはどのくらいあるのだろうか。

依頼する条件がわかって依頼するのは作業指示書を出すようなものだ。期待する結果があり、その結果を再現できる手順が確立されており、必要とするスキルもしくはそうした条件もなく、手順書を読み、理解できれば期待している結果を得られる。

こうした作業にコミュニケーションコストという感覚は持ち合わせるのだろうか。多分にないだろうと思う。

ではどういったときにコミュニケーションコストだ、と感じるのだろうか。

自分の経験則では、コミュニケーションを取る時点で相手に期待する結果がある。例えば、先方の情報を提供して欲しいと言うケースがあったとする。その照会先が複数あるとすると、まずここで面倒くささを感じるが、予め想定できる作業だから面倒臭いだけである。

次に考えられるのは、照会先からの回答が期待とズレている場合である。再度、照会し直さなければならないためだ。引用した増田もそれをいっているのだろう。

照会先の回答のズレ度合いは、事前には既知な関係でなければ予測できない。大きく外れるか、期待どおりでしか無く、期待どおりをベースにするならそれ以外は全てマイナスでしかない。

そうしたマイナスをベースラインである期待値に戻す手間や時間をコストとと捉えるかどうかである。

コストと捉えると、対策としてはガイドなどを作り、配布することになる。またこれが誤解を生みかねないのだが。

経験則の続きを話すと、先方の数と依頼内容と手段でどのように進めるかを考える。

具体的には、照会内容以外の回答が得られないように仕組み化する。照会内容がアンケートであれば先方に自由度を与えない方式を提示する。枠組みを作り、リスト、単位など誰でも同じ理解可能な方式を取ることが多い。

言い換えれば、相手に考えさせることをさせないと言うことだ。

さて、こうした段取り的な仕組み化はコミュニケーションコストなのだろうか。

異文化理解力 ― 相手と自分の真意がわかる ビジネスパーソン必須の教養

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

プロジェクトが問題だらけな理由

エンジニアを続けていると感覚が麻痺するのかもしれない。プロジェクトが立ち上がるとどこからともなくメンバと称するエンジニアが集められ、具体的なプロジェクトの内容も知らないまま納期までに作業をするように指示される。

システムエンジニアリングだという人がいる。エンジニアリングなら開発手法もプロジェクトマネジメントも、様々な手法や方法論が確立され、技術的にはある程度決まったやり方で、システム開発ができることを期待しても良いだろうが、現実はそうではない。

ウォーターフォール開発にしろアジャイル開発にしろ、概念や思想があるが、これがテンプレートだという開発手法が存在しない。エンジニアの読み手や解釈、それまでに経験してきたノウハウが互いに影響し合い、読み手の解釈に基づくプロジェクト運営が行われる。

プロジェクトチームが編成され、メンバが召集され、そのメンバに示されるプロジェクトのやり方は過去に誰も経験したことがないやり方をプロジェクトに参画してから提示される。いきなり初見でこのやり方に合わせてやれとアドリブに完璧を求められるのだ。

メンバはメンバで、誰一人同じ経験をしていないから、示されたプロジェクトのやり方の解釈は必然と違うものになるし、解釈されたことは似ているかもしれないが根本の意思決定では違う判断をなされているのだ。

ではと、プロジェクトのやり方のテンプレートを作ったとする。そのテンプレートを素直に使ってくれるかと言えば、そんなようには受け入れられない。今まで経験してきたやり方と違うから使えない、このプロジェクトには合わない、などと使わない理由をいくらでも述べるのだ。

もちろん、テンプレートに問題もあって、テンプレートを作るタイミングでたまたま成功した事例を雛形にテンプレート化するから個別事情が色濃く反映される。それをやってきたらプロジェクトが成功したのだと言われるとモデルを抽出することに長けた才能を持つ人がテンプレート化しないとそうなってしまうのだ。

複数の事例からテンプレート化することを進めると原理主義がまかり通り、個別事情を徹底的に排除する勢力が台頭するため、テンプレート化されるのは概念モデルだけで、実務で必要なプラクティスが根刮ぎ削られてしまう。

プロジェクトの問題は得てして以下のことから起きている。

• 誰一人同じ経験を持っているエンジニアはいないことを認識していない。
• プロジェクトチームでやるやり方なのに当事者のエンジニアにそのやり方でやれるかを問われることがない。
• テンプレートは使わない理由をつけられ使われない。

プロジェクトの問題を減らしたいなら、逆のことをすればいい。

• 異なる経験を持ち寄り、違いを理解する。
• チームのやり方は全員で小さく試し、出来ることを確かめる。
• テンプレートをチームのやり方にカスタマイズする。

テンプレートが無いなら、これからやる作業を書き残すか写真に撮り、残しておくこと。

 
amazon kindle『50%OFF以上』　IT・専門書フェアから選り抜き書籍

ピープルウエア　第3版

パーフェクトソフトウエア

amazon kindle『50%OFF以上』 IT・専門書フェア～2018年7月5日（木） 23時59分

『50%OFF以上』　IT・専門書フェア
期間：2018年6月22（金） 00時00分～2018年7月5日（木） 23時59分（日本時間）
対象タイトルが、50%OFF以上！

amzn.to

 基礎スキル的なテーマのものをピックアップ。

プロフェッショナルプレゼン。　相手の納得をつくるプレゼンテーションの戦い方。

ひとつ上のチーム。［新装版］

デスマーチ 第2版　ソフトウエア開発プロジェクトはなぜ混乱するのか

あなたのセキュリティ対応間違っています

なぜ、システム開発は必ずモメるのか？

梲が上がらない中堅エンジニアの生存戦略

タイトルだけを読んで、氷河期世代のことを言っているのかとおもった（何分、不幸のオンパレードの象徴のように扱われている）が、よく良く読むと、90年前半の世代（平成一桁前半）なのだろう。

バブル期後半の大量採用組や人口の多い「団塊ジュニア」が40代に当たるが、管理職ポストに限りがあり、部長や課長への昇進が全体的に遅れていることが背景にある

headlines.yahoo.co.jp

 40代で課長職級に上がれていないのは結構辛いのではないか。まあ、仕事の責任範囲が担当職かサブリーダクラスでいいよというエンジニアは忙しければ残業手当もつくだろうからそこそこ安定していると当の本人は思っているかもしれない。

本当に辛くなるのはアラフィフのゾーンに入ってからだ。

所属する組織の構造を見ればCEOを長としてピラミッド構造を取っているだろう。最近のWebサービスを提供しているような組織だとフラットな組織構造を取っているケースもあるかもしれない。ただ、実態は何かしらのロールを持たされる組織のリーダが存在するものだ。

そうした組織の構造を、例えば組織表のようなものがあるとすれば、それを眺めると組織のポジションの人数を数えることができる。大雑把な捉え方は管理職か一般職か。細分化すれば役職ごとのレイヤとなる。それらの人数がいわゆるポジションだ。こうしたポジションは、事業が増えない限りそうそう増えることはなく、世代交代か事業場の評価で交代するのが流動性の起因だろう。

そこのポジションに割り込むか、専門技術のエキスパートとして別枠を確保する必要がある。

どちらで場所取りをするにしても、共通項としてのコンピテンシが求められる。それは、これまでのエントリで書いてきた二つのスキルのうち基礎スキルと読んでいる領域である。このスキル領域はその人の人柄に直結する。

例えばビジネスニーズを拾うとか、システム企画に携われるとか、メンバのメンタリングやチームビルディングなどの難易度の高そうなイメージを持つコンピテンシだ。

これらのキーワードで無理だと日和ってはいけない。いずれにしろ必要なスキルだし、そうしたスキルを身につければ今のサブリーダの仕事だって何倍も楽になる。

ビジネスニーズは顧客が困っていることの解決方法を探すことでも良いし、システム企画は業務課題のアプローチの仕方の仮説の組み立てなどがあるとすると、これらに共通することがある。

それは、現実に起きている課題を抽象化したり、抽象化した概念を確かめる仮説検証をモデル化するスキルだ。これを身につけるととてもいい。

顧客の要望が定まらないところでも使えるし、仕様の良し悪しを整理するときにも使える。こうした抽象化するスキルが必要なのは、担当エンジニアよりは、よりビジネスに近いところで必要となるのだ。

もう一度組織構造を見てみよう。レイヤを上がれば上がるだけ抽象化スキルが必要になるのだ。

メタ思考トレーニング (PHPビジネス新書)

具体と抽象 ―世界が変わって見える知性のしくみ

男性エンジニアも女性エンジニアもどちらも同じチームにいた方が自分の思考の狭さを学べる

Battle Conference U30の講演での発言が炎上し、所属組織がお詫びのプレスリリースを出していたようだ。

こう言ったとき、その炎上している発言の部分だけを切り出すとよくわからない状況にあることが少なくない。

ログミーに残っている（まさにログ）ので前後を含めて引用してみよう。

そして、これによって生じる問題は、男性エンジニアにとっては、「いいところを見せたい」というやる気が出ない。そして、女性エンジニアにとっては、女子トークができない。これは非常に重要な課題だと思います。

ただ、女性エンジニアを1から育成するっていうのは、非常にコストが大きいんですね。

これは正確なデータは取りづらいので、短大や私立の学費、卒業するまでにかかる費用にしたんですが、安くても300万、高いと800万といった、数百万単位でかかってしまいます。これはちょっと現実的じゃないですよね。

logmi.jp

炎上した発言のあとを読む限り、短大若しくは私学の費用を引き合いに出しているが正確なデーてはではないと断っていることと、特に男女を特定した費用には読めない。

引用している調査結果でも男女を分けていない。

育費負担の実態調査結果（2017年度）株式会社　日本政策金融公庫

このことから、炎上した箇所を女性という必要はないし、女性だけがコストが高いという因果関係は認められない。

個人的な経験から言えば、男性だろうと教育コストは同じように掛かる。特に自分は組織貢献までに時間が掛かっている（と自己評価している）ので、ある意味、いまだに教育コストがかかっているのでろくなエンジニアではないと上は思っているかもしれない。

エンジニアの教育コストの観点で言えば、早く独り立ちして組織貢献することを組織は期待している。ロールをステップアップし、リーダになり、チームを引っ張っていってくれる人材になると優秀だと認めているだろう。

あるプロジェクトに担当のエンジニアとして参画したとき、男性のエンジニアのリーダに優秀な人が多かったが、女性もリーダが多く、男性のリーダと同じように優秀だった。

男女の人数としては男性が多いためかもしれない（人数の母数が多くなれば優秀でない人が混入する確率が上がる）が、担当業務とのミスマッチと思われる印象を受けたのは男性だった。

ここで個人的に女性の方が優秀であると刷り込まれた感は少なからずあるのだろう。

その後、マネージャになったとき、ほぼ男性職場であった。部活の延長のような、粗雑な関係性が感じられた。このときマネージャとして決めたことの1つは、女性比率を上げることだった。

別に男性だけでも良い組織は作れる。だが、考え方が似通ってしまう嫌いがある。物事を見る視点が固定化されるのだ。

システム開発では様々な切り口で物事を見ることができるスキルが必要である。そうした視点の捉え方を学ぶには、違う切り口を持っている多くの人と交流し、過ごすことで体感するのが一番だ。

例えば、日程を組むと必ずやらなければいけないと決め込んで追い詰めているとする。そこに時短勤務の社員を入れると制御できない外的要因、つまりお子さんが急病でお迎えに行かなければならなくなることがまま出てくる。

チームで考えることはそうしたコントロールできない事象に耐えられるバッファを持つことと助け合える文化を作ることである。こうしたことは頭で理解できていたとしても自分のチームの中で起きると途端に理解不能になる。

多様性云々と言われて久しいが、日常に自分の都合と違うメンバがいて、お互いの都合を知ることから学べることが多い。

宇宙兄弟 「完璧なリーダー」は、もういらない。

ウォーターフォールとアジャイル開発の間に♡が足りない

初めて覚えたシステム開発手法がウォーターフォールだったので、覚えたシステム開発手法の順番は、ウォーターフォール→プロトタイプ手法→インクリメンタル開発…だったような気がする。暫くして、アジャイル開発のカンバンを使ってプロジェクトを運営した。

ネットでスクラムなどのスライドを見て、アジャイル界隈のコミュニティの存在を知り、イベントにもいくつかは参加してみた。スライドや書籍を読んだ理解の方向性があっているかそれとなく確かめたかったからだ。

2011年頃のアジャイル関連のいくつかのコミュニティに参加したときには、うんざりした気持ちになった。

冒頭に出てくるのが滝の写真でウォーターフォールは行けていないと揶揄するのだ。黙っていたが、正直、気分の良いものではなかった。登壇者にスライドの内容を批評するのが目的ではなかったし、そんなのトラブルの種でしかない。

自分の目的はどれだけやれるのか、理解の方向性をプラクティスから補強する材料が欲しかっただけだ。

でも、結局、自分のプロジェクトで試行錯誤することから得られる経験知の方が何倍もの価値があった。当たり前なことではあるが、人は少しでも自分の考えと似たことをした人がいると安心するのだ。論理的ではないが。

スコープに対する考え方は違うが、ショートタームのウォーターフォールであると捉えた。それを仮説とすると、アジャイルのコミュニティでうんざりしたスライドの登壇者は相当不幸なウォーターフォール型のプロジェクトにアサインされて懲り懲りな体験をしたか、ウォーターフォール型のプロジェクトは肌が合わなかったのかもしれない、と思った。もう一つのケースもあるがそれを書くと余計なことを引き起こすかもしれないのでそっとしまっておく。

そんな中で誰だったかがそうした揶揄することは止めて「仕事をしろ」「アジャイルの実績を作れ」と言うようにトレンドを必死に変えようとしていたことに、これは流れを変えないと後ろがないと危機感を感じているのだろうと思った。これは、自分にとって好ましく思った。実践フェーズに突入宣言をしたようなものと受け止めたからだ。

自分の（管理下の組織の）プロジェクトで欲しかったのは可視化と作業の流量制御と負荷の共有とプロジェクトの状況のメンバ全員の共通認識であった。

だから、カンバンだった。

プロマネを専門としているので、プロジェクトが目的どおりに成功するためにプロジェクトの目的達成ドブリンで考える。顧客とのインタフェースもある。スクラムではなかったのはそういった理由があったからだ。

目的がある。顧客や社内でのコミュニケーションプロトコルの制約などとプロジェクト内で抱えていた課題解決からウォーターフォールとカンバンを組み合わせて使うことにした。

そこには揶揄するような対立構造はなく、プロジェクトを成功させようとするチームが存在しただけだった。

ウォーターフォール　vs　アジャイル開発

ではなく

ウォーターフォール　♡　アジャイル開発

だけが存在した世界があった。

技術の間には♡を足そう。

CANSAY nu board ヌーボード A4判 NGA403FN08

カンバン仕事術