素人なので短期間でのアジャイルなエンジニアの育成方法を教えていただけませんか

アジャイルなエンジニアの育成は素人なので、ぜひ教えを請うことをご了解いただきたい。

 

tech.nikkeibp.co.jp

 

ところで、アジャイル開発には『アジャイルマニフェスト』というものがあり、度々引用されるので食傷気味かもしれない。もし、知らなければこれを機会にリンク先をご覧いただければと思う。

 

アジャイルマニフェストを読むと短い文章である。それでも、たった下記の数行で従来のSI案件の価値観とは違う方向性を持っていると認識している。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。

 従来のSI案件の契約は適用できない。何より、顧客も契約や役割分担などでの振る舞いを変えてもらわなければならない。一番変わらなければならないのはエンジニアや営業であることは間違いないが。

このアジャイルマニフェストで誤解され易い一文がある。それは2行目であることは有名かもしれない。これは決して『アジャイル開発ではドキュメントを作らないと言っているわけではない』ことに注意が必要である。

必要な文書は作るし、契約で顧客が求めれば話は変わってくる。必要なものは作るが、価値のない文書は作る必要がないということだ。

価値を知りたければ右辺を下から読めばいい。変化に対応できているか、顧客と協調しているか、動くソフトウェアをリリースできているか、対話を行なっているかを自問するのである。

 

アジャイルマニフェストはこのくらいにして、ベンダやSIerに重くのし掛かるのは『アジャイル宣言の背後にある原則』である。こちらもしばしば引用されるのでその内容に胃もたれされているかもしれない。こちらもご存知でなければこの機会で一読されると原則の濃厚さをご理解いただけると思う。

自分は素人であるから、この原則をある程度実務で実行できるエンジニアを育てるには相応の時間とバジェットを要求するだろう。間違っても、集合研修を1回や2回受講した程度ではアジャイル開発を出来るエンジニアだと他所様には言えない。

f:id:fumisan:20190218075807p:plain

引用 Q2 顧客システムのアジャイル開発プロジェクトに携わるエンジニアの数 | 日経 xTECH(クロステック)

 

さすが、日本を代表するベンダである。どうやってアジャイル宣言の背後にある原則を実行できるエンジニアをお湯をかけて待てば出来上がるように量産できるかを教えて欲しい。

従来のSI案件では、受け身で、指示待ちで、決められたスコープで、作業を工程で分断して、長い開発期間で、文書を求められるがままに作るエンジニアが重宝がられている印象を持っている。それが自分の間違った理解なら問題ないのだろう。

ただ、自分の経験としてSI案件をやっていたエンジニアのマインドを謂わゆる超上流のIT企画の業務を遂行できるように意識を変えるだけで数年かかっている(それでもまだ十分ではない)ことを念頭に置くと、一度刷り込まれた開発手法やプロジェクトマネジメントは早々変わらない。行動様式として意思決定の判断基準がそれになってしまっているからである。それはそう易々とは置き換えられない。

もしかすると、既にアジャイルなエンジニアをスタンばらせているのかもしれない。であれば、さすがベンダである。

 

 

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

 
スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

 
SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

 
アジャイルコーチング

アジャイルコーチング

 

 

 

調達 宇宙兄弟 「完璧なリーダー」は、もういらない。 Kindle版 今だけ?599円

 お?今だけ?

Kindle 価格: ¥ 599

¥ 913の割引 (60%)

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

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

 

 

エンジニアは猫とする

部下やプロジェクトチームのメンバを自分の視点、役割から見るときにどう捉えるかという考え方は、対象となる人と接する際に大きな影響を見えない形で影響を与える。

乳児・幼児に接するとき、中年以上の年齢層は、誰に強制されることもなく、笑顔で『〜でちゅねー』など語尾が幼児言葉になる。

同じように猫に接するとき、飼い猫であっても全くもって飼い主のいうことに聞く耳を持たないことを理解しているから、猫の要求には素直に応じる。

上記の2つの例では、接する対象を接するものが持っているモデル、属性を外的な情報から認識し、受け入れられる場合、対象の振る舞いが自分に対して不利益が生じても文句が出ないばかりか、好意的に受け入れられるという事実がある。

マネージャと部下、プロジェクトマネージャとチームメンバとの間で起きる問題に、しばしばコミュニケーションがテーマになる。

便宜上、マネージャと部下、プロジェクトマネージャとチームメンバを対向する関係があるとする。対向する関係は、1つの組織、1つのプロジェクトチームになろうと日々現場ごとに活動し、悩みを抱えているのも事実である。それを対向するという言葉が適切であるかは差し置き、一旦はその用語を適用する。

対向する関係でしばしば問題になるのがマネージャやプロジェクトマネージャの立場から見たときの、部下やメンバが合意事項や指示通りの成果を得られないという事象である。得られていない成果は、完了条件を満たさない、リソースの使い過ぎ、納期超過として現れる。

そうした事象はコミュニケーションが原因であり、相互に心理的安全や思考の言語化に依る意思伝達の改善で改善を図ることが提唱されている。

本質はそこなのだろうか。これこそがこのエントリでの議題である。

対向する他人と意思伝達をとるとき、暗黙で省略されていることがコミュニケーションを取ろうとする側にあるのではないだろうか。

コミュニケーションを取ろうと問いかける側は、暗黙にコミュニケーションを取ろうとしている相手に、コミュニケーションをとる側と同じ能力があることを前提としているのではないか。

これで考えるとマネージャやプロジェクトマネージャと部下やメンバ間のコミュニケーションで生じている様々な問題の理由が理解できる。

事象としては、伝える側、受け止める側の双方に問題があり、コミュニケーションストレスが可視化されているのである。その可視化として見えている原因が同じ能力を前提としたコミュニケーションなのではないか、ということである。

課題は、コミュニケーションストレスであり、仮説は、コミュニケーションの双方の能力ギャップを認知することでギャップの低い方でコミュニケーションを取るであり、ソリューションは、コミュニケーションを取る相手を猫と見做す、である。

コミュニケーションを取る相手を乳児や幼児としても良さそうだが、乳児・幼児は成長が著しい。一方、猫はマイペースである。よって、猫の方が適切であると導ける。

 

 

 

おじさまと猫(1) (ガンガンコミックスpixiv)

おじさまと猫(1) (ガンガンコミックスpixiv)

 

 

 

 

そのPDCAの『C』間違っていますよ、マネージャさん

本来の意味合いを理解せずに、ただ言われるがままにやらされて、その本質を理解せずに間違ったままにみにつけ、本来だったら得られる効果を得られず最悪は無駄なことをやっている現場はいくらでもある。

  • PDCA
    PDCAは、Plan/Do/Check/Actionであることはエンジニアであれば誰でも知っている。しばしば改善というスローガンで生産性を向上しろだとか、品質を上げろと課題を出されるやつで使われる。

    PDCAは、計画、実行、確認、対策の意味合いで使われていることが間違いの要因であることに気づいていない。どこが間違いなのかというと、『確認』である。Doである実行を見たところで意味はない。やってしまった結果だけしかない。それを見て何を得られるか、ということ自体に気づかない管理職が多いのである。

    CのCheckは『検証 』でなければならない。検証は、

    けん‐しょう【検証】出典:デジタル大辞泉小学館
    [名](スル)
    1 実際に物事に当たって調べ、仮説などを証明すること。「理論の正しさを検証する」
    2 裁判官や捜査機関が、直接現場の状況や人・物を観察して証拠調べをすること。「現場検証」「実地検証」
    検証(けんしょう)の意味 - goo国語辞書

     
    の意味のとおり、Doの実行の結果とPlanの計画を比較し、計画の妥当性を確かめなければならない。計画と実行の結果に差異があるのであれば、原因を分析し対策が必要かを判断しなければならない。 

    Actionの対策としてしばしばチェックリストを用いるが、これも機能しない。

    例えば、本番システムのプログラムデプロイを1人で作業を行い、作業中のエラーメッセージを見たにも関わらず進め、本番の運用で障害を引き起こしたとする。

    チェックシートで障害の再発防止に務めるのも、本当に再発防止ができるかは疑わしい。なぜなら、障害の原因は、プログラムのデプロイを1人でやっていることかも知れないし、デプロイを人手でやっているからかも知れない。

    障害は基本的に作業プロセス上に問題があり、そのプロセスを変える必要がある。人に原因があるとする判断も間違いである。

    問題が起きた箇所では、作業を安全に進められる条件が揃わないと先に進めないようになっていなければならない。

    その意味で、チェックリストを作ったとしても作業者がチェック項目に書かれていることを理解し、項目の合否により作業を止められなければ意味がないばかりか効果のない無駄な作業を増やすことになる。その典型がチェックリストなのである。

    単純に『それやってどうなる?』とやったあとの将来を見切れれば検証が妥当かは判断できるのだが、それをやらないのがアレなマネージャなんだな。

 

 

 

アオアシ (16) (ビッグ コミックス)

アオアシ (16) (ビッグ コミックス)

 
アオアシ(1) (ビッグコミックス)

アオアシ(1) (ビッグコミックス)

 

 

 

 

『共創』はITベンダが使うまやかし

事業会社のIT部門の技術力低下や頼りないと言われて随分経つような気がする。主要なベンダにシステム化を丸投げし、組織内の調整に翻弄するから適用技術の習得まで手が回らず次第に技術の主導権はベンダに移ってしまう、ようなケースも言われている。日経BPホニャララ系のサイトでは頼りないIT部門として辛辣に叩かれる対象でもある。

青い銀行の再構築も切り替えフェーズに入り、IT業界全体としての需要は低下するものだと思っていたら、相変わらず需要旺盛でエンジニアは売り切れていていると聞くし、実際、所属する組織でも対応できるエンジニアがいないのでビジネスを先送りしている状態らしい。

一方で、人に会うと何度となく聞くケースに様々なサービス、製品は提供されるが、提供までであって、それをインテグレートする、つまり業務に適用できるエンジニアなり、IT部門がいないのだという。

自分が知っている常識で言えば、業務にどう適用するかはIT部門の分掌であって、ITベンダが出てくる幕ではない。であるとの考えから共創などという言葉をITベンダが使うことに違和感を覚えるし、その共創という言葉自体に業務主管を曖昧にしてそこに漬け込むITベンダなりコンサルの魂胆が見え透けているところが微妙な気持ちにさせる。

共創について詳しく知らなかったのでgoogle先生に聞いてみたらここを教えてくれた。

 

www.netcommerce.co.jp

 

共創の定義は、

『企業が、様々なステークホルダーと協働して共に新たな価値を創造するとという概念「Co-Creation」の日本語訳です。』

なのだという。まんまの訳である。

共創が生まれた背景には、

「市場の変化に合わせて。戦略を動かし続ける」

ことをしなければ

『連続的に競合優位を生みだし続けることができなければ、生き残れない時代となったのです。』

 のだという。

で、である。それがそうだとして、ではなぜ様々なステークホルダと協働に結びつくのかが理解できない。本来は、事業主体者が自ら連続的な競合優位性を持った価値を作り出差なければならないのではないか。

そう考えるとステークホルダにITベンダやコンサルは入る余地はない。彼らは事業主体者の業務のアウトソースでしかないからだ。事業主体者が内製すれば入り込む余地はない。そう言った考えに基づくと、ITベンダやコンサルが共創というのは『だいぶ違うな』と思わざるを得ない。

ところで、割と昔からITベンダやコンサルから出向の形態でIT部門要員として受け入れている事業会社がいくつもある。IT部門のリソース不足もあるのだろうが、ITリテラシのない社員より事業課題の解決手段のITの専門性を持つエンジニアなりコンサルをテーマごとで有期限で置いた方が良いという考え方なのだろう。

もちろん、こうした形態は紐付き円借款のようなもので建前上は競争入札であっても紐付きになる。

そうした様式美はさておき、共創などと外野から得体も知れない概念でおこぼれを狙うより、出向形式でのIT部門への参加の方が本物の『共創』なのではないか。それは、一時期だとしても出向するIT部門の事業会社の所属になり、その責を担うからである。

であるから共創を前面に出しているITベンダやコンサルはまやかしだなぁと思うが違うのだろうか。

 

 

 

 

コ・イノベーション経営: 価値共創の未来に向けて

コ・イノベーション経営: 価値共創の未来に向けて

 

 

進捗で巻き込まれ事故を防止するために知っておくと助かるかもしれない

エンジニアがプロジェクトを俯瞰した視点で見れているかどうかはリーダ役を任せられるかどうかという判断の1つになると思う。俯瞰と言ってもどこまでの範囲を見れていればいいのかという感覚的なところに依るものもあるが。

例えとして、『アイツは猪突猛進のタイプだ』『視野が狭い』などと耳にすることは以前はちょくちょくあった。最近は聞かなくなったのは別の表現に置き換わったからか、それとも周囲の環境の変化だろうか。いずれにしろ、目の前の自分の仕事だけしか視界に入らないエンジニアでは担当エンジニアとしてさえ、分業化しているIT業界でやっていくことは難しい。なにせ自分の担当の仕事を進めるだけでも同じチームのメンバや外部のチームに頼みごとをしなければ進まない。

リーダ役を任せるなら俯瞰した視点を必要とするのは、自分の仕事と周囲の協力がないと進捗しない協力関係性を持っているからだ。明示的な協力関係性はWBSなどに現れる。自分のインプットに他のメンバの作業と前後関係がある、自分のタスクの後続に他のメンバのタスクがインプットとして待っている、などだ。暗黙的な協力関係性には、外のチームの進捗遅れに足を引っ張られるようなケースなどである。

自分や自分のチームの進捗でクローズしている作業、つまり外部からのインプットも制約も受けないタスクはリソースの確保と意思決定でどうにでもなる。この範囲であればリーダ的視点はなくても構わない。ただし、外部からの制約を受ける要素を持つのであれば、外の進捗も外部からの影響の把握を怠ればそのインパクトに巻き込まれるだけである。

言い方を変えれば、自分の範囲の作業は、進めることもできるし、進捗を止めることもできる。なぜなら必要なリソースの割り当てと進めるか止めるかの判断をする権限を持っているからである。ところが外部からの制約元にはそうしたリソースも意思決定も及ばないことから進んでいるのか停止しているのかは自ら情報を取りに行く他ないのである。

簡単な表で表すと自分のチームの進捗がよくても*印の組み合わせは実は拙いことがわかる。

 

     外部| 進捗している | 進捗してない

内部     |        | 

ーーーーーーー+ーーーーーーーー+ーーーーーーーー

進捗している |  オンスケ  | 巻き込まれ *

ーーーーーーー+ーーーーーーーー+ーーーーーーーー

進捗してない |ご迷惑かけてる | やばい

 

自チームの進捗が滞っているのであれば他所の進捗はどうであろうと、他所に影響を与えているので他に気を配るどころじゃない。全体としてはウォッチされるので半ば強制的に情報共有が行われる。ただし、*印は自分達から外に向けないと(遅れを隠蔽されることもあるので)情報を取れない。

そういう意味では自チームとそれを取り巻く他所のチームは二重構造をしていてそれぞれで進捗している。

 

          他チーム

       +ーーーーーーーー+

       |  自チーム  |

       +ーーーーーーーー+

 

それぞれで、という感覚を常時持っていることが大切で、それを失うと気づいたときには取り返しが難しい(手遅れ)、ということになっていることだってありうる。

プロジェクトは生き物だと表現されるときは、そういう意味合いもあるからなのだろうと思う。

 

 

 

 

 

エンジニアと飲みニケーション不要論

以前から割と書いていることに所属する組織での飲み会は全くもって面白くないのでよほどのことがない限り行かないというのがある。プロジェクトの飲み会はキックオフやメンバに感謝する場にしか行かない。前者は飲み会の会場やイベント自体の面白さがあれば行くこともあるがただの忘年会などには一切行かない。後者はメンバ同士(自分抜き)の方が気兼ねなく会話もできるだろうとも思っている、というのもある。

エンジニアになった頃、先輩たちに誘われて何度となく飲みに行ったものだ。今で言うオラオラ風の先輩エンジニアは『飲み会の場でなら何を言ってもいい』と放言していたので『飲まないと言えないんですか』とツッコミを入れたら『お前はそういう奴か。それならそれでもいいぞ』的な返しがあったことを思い出した。今なら60代になっているだろう。

実は色々と思うところがあって、酒を飲むのをピタリとやめている。理由は色々なのだが、1つは『験担ぎ』ということにしている。どうしてとしつこく聞かれた時の模範解答だ。『受験があるからお迎えがね』とでも言っておけば大体は納得してくれる。実際、お迎えをしているのは事実で嘘ではない。

お客との懇親会が数回あり、その時はどうしたものかと若干迷ったが元々飲まない人もいるのだから飲まない人がひとり増えたところで何も変わらないじゃないか。そう気づいたら何も身構える必要はないのだとわかった。

実際、烏龍茶を飲んているとビールを注がれることもないし、一見、ウイスキーか烏龍ハイを飲んでいるように見えるので思ったより気にしない。こちらは烏龍茶でつぎ返されることはなく、ひたすらついで回れる。

その上、シラフなので会話したい人のところに行って、話したいことをここぞとばかり会話することができる。

あれ、これ本当に酒が必要なのか、と思わなくもない。

Web界隈で多いのがmeetupやビアバッシュで酒を飲みながら語り合い、技術を共有しあい、あわよくば有望なエンジニアを取り込もうというイベントである。登壇しに行くこともあるので時々お邪魔することもある。

Web界隈のmeetupは食事がありきたりではなく、工夫されている会社さんもあって美味しいところもある。酒を飲むのをやめた自分としては、ちょっとだけ美味しいものをつまみながら若いエンジニアの方の話を聞いて、共有できるヒントがあればリンクを渡すようなことができると楽しい。

お酒を飲むことで自分を開放する人もいるようだが、自分はそうでもない(飲みすぎると帰りが大変だからというのもあるが)ので酒のバイアスはあまりかからない。それよりは箸にも棒にも引っかからない酒で仕方なく瓶ビールを流し込みながら話を聞くよりは、烏龍茶を飲みながらそうしたときにしか会話をするチャンスのない人を確保して話をする方が何倍もいい。

そんなことを思うようになってから、コミュニケーションに酒はいらないのではと思うようになった。

違うな。

プロジェクトやチームでコミュニケーションを取るのは業務中にやればいいというかやらなければならないことで、それ自体が業務だと思っている。だから、よく飲みニケーションは潤滑油的な物の言い方をされると業務時間内でやれよ、と思ってしまう。

 

そういう意味では、組織の中のメンツだけで飲みニケーションするのは業務がおかしいと言ってもいい(meetupはリクルーティングや外部に所属するエンジニアを引っ張り込むので意味が違う)。

マネージャなら業務時間内で必要十分なコミュニケーションを取れるような組織を作らなければいけない。

業務の終わった後、好きに飲むのは好きにしたらいい。それはそれで微笑ましいと思う。

 

 

アメリカ口語教本・入門用(最新改訂版)

アメリカ口語教本・入門用(最新改訂版)