『あなたの持っている価値観があなたが書くコードの品質を左右している』
『あなたの持っている価値観があなたが書くコードの品質を左右している』
さて、これを読んでどう感じるだろうか。そんなことはない、プロジェクト、プロダクトの品質要求に応じてコードを書いていると言うのだろうか。それとも、指示されたようにコードを書いているだけだから、品質は作業指示や仕様書次第だ、と言うのだろうか。
仕様書からコードにエンジニアが変換する際に、どのようなロジックで、どのような書きっぷりで日本語やモデルからコードに書き換えられるかは、それを書き換えるエンジニアに委ねられる。
そのコードが仕様を満たしているか、ケースを網羅しているかはエンジニアがどこまで仕様を読み込み、理解し、コードとして表現できるかに強く依存することになる。
なぜなら、仕様書からコードとして表現される際に起きているのは、エンジニアの主観による意思決定しか存在し得ないからである。その瞬間、誰も介入することはできない。
介入できなければ、そのコードは書いたエンジニアの考え方をそのまま映す。考え方は、情報を集め、整理し、数ある選択肢の中からエンジニアとして表現したい表現方法をエンジニアの価値観で選び、表される。
コードの品質はエンジニアの価値観で表現されるのである。
これは一人でコードを書く場合に限られる。一人でと限定したのは、モブプログラミングの存在があるからである。ドライバーがコードを書き、ナビゲーターがサポートをする役割でコードを書く場合、書いている最中にナビゲーターの価値観が割り込んでくる。
複数のナビゲーターの知見が混ざり合う中で、コードが決まっていく。コードを書きながら、あれこれとナビゲーター達の経験から予測される様々なケースを共有しながらコードに変換されていくのである。
一人ひとりのエンジニアがそれぞれでコードを書き続けるならば、コードの品質はエンジニアの価値観に依存するため、エンジニア次第で品質は左右される。
モブプログラミング でコードを書くのであれば、チームの共有されている価値観の範囲で品質がコードとして表現される。チームでどこまで価値観が共有されるかに依存するのだが。
パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)
- 作者: 江渡浩一郎
- 出版社/メーカー: 技術評論社
- 発売日: 2009/07/10
- メディア: 単行本（ソフトカバー）
- 購入: 75人 クリック: 1,306回
- この商品を含むブログ (159件) を見る
プロジェクトの中で人材を育てる
自分の部下のの中で、中堅以上のエンジニアには後進の育成を課している。課しているからには、評価を行い、業績に反映している。
もちろん、育成対象者である若手や伸ばしたいスキルを持つエンジニアにも自身でどのように取り組むのか、目標設定はしている。こちらは、自分で育つスキルを自分で選ばせ、自分のやりたいようにやらせる。
中堅以上のエンジニアには、若手エンジニアは『○○させたい』と具体的にテーマを渡す。次のプロジェクトではサブリーダをやらせたいので、リーダが担うタスクのうち、いくつかを分担するかブロックを任せられるか考え、実行して欲しいと言うように。
人材を育成するのは難しい、期待する人材が育たないと愚痴を聞かない日はない。でも、育つために必要なリソースを確保しているのかどうかと言えば、怪しいものである。やり方も同じである。
育成については何度も取り上げているが、どうやって、は書いていないような気がするのでそれを取り上げる。
基本
基本は、『テーマを設定する』『動機づけする』『アサインする』『モニタリングする』『フォローする』『自己評価させる』『エビデンスで評価する』の流れになる。
何も目新しいものはない。
当たり前のことを当たり前にやる他に、マネージャの仕事のやり方はない。チートもできない。
プロジェクトの中で育てる
基本をそのまま行う。ただし、プロジェクトではチームとしてのスキルセットを満たす必要がある。ブロックのリーダやサブリーダに経験値の少ない若手エンジニアを置けばチームとしてのスキルセットが足らないのは当然である。
そこの手当てをプロジェクトマネージャやリーダにする。例えば、中堅どころのエンジニアを入れ相談役にさせる、アドバイザをおく、マネージャとしてのプロジェクトのリスク評価を上げておく（＝モニタリングのためのリソースを増やす）など、何かしらプロジェクトに対するアテンションを上げておく。
将来のために無駄なことをする
今だけで見れば、プロジェクトで必要とするポジションにそれを満たすスキルのエンジニアを置く方がマネジメントとしては楽である。
でも、それではいつも同じメンツがリーダで後進が育たない。
上述した、期待する人材が育たない理由はこれである。
面倒臭い方を取らないからあとが続かない。楽をする分、将来にそのツケが回る。マネージャ自身が、今をやり過ごしたいと考えていると結果的にそう言うアサイメントになる。
外から見たら、いつものメンバだとしても、プロジェクトの中での役割、分担内容はいくらでも変えられる。そうした経験をさせるアサイメントをしないと期待するエンジニアが実は向いていないと言う事実さえわかるのは先になってしまう。
年次でそろそろリーダをやらせないととアサイメントしてプロジェクトを失敗するのはこれが原因である。
改めて、プロジェクトマネジメントをどうアプローチすれば良いかを考えている
ひと段落ついたので、改めて、プロジェクトマネジメントへどうアプローチすれば良いかを考えはじめている。
プロジェクトマネジメントへのアプローチと言いつつ、実際は、プロジェクトを回すマネージャ（＝プロジェクトでリーダーシップを発揮する人）が何から手をつけて行けば、プロジェクトを炎上させずにプロジェクトの目的を達成することができるか、である。
ペルソナ
対象読者のペルソナはこんな感じか。
- はじめてプロジェクトのリーダ役をすることになったエンジニア
- プロジェクトを一度も独力でキャリーしたことがないエンジニア
前提条件
ない方が良いが後から書き出すかもしれない。
例えば、『言語やプラットフォームは問わないが、何かしら開発経験を持っている』などは必要かもしれない。
ゴール
プロジェクトマネジメントをできるようになることが目的ではない。ここを間違えないように。あくまでも、プロジェクトの目的を達成することが目標である。
プロジェクトマネジメントは、プロジェクトをマネージする手法である。プロジェクトマネジメントの代表的な知識体系である『PMBOK』では開発方法まで言及していないことが証左である。
知識エリア
プロジェクトをいい感じにキャリーするために必要な知識エリアは4つある。
テーラリング
前述の4つの知識エリアが必要である。全部の知識エリアは必要だがその中の知識全部は使わない。必要なものだけ使う。必要なものだけ使うから、不要なものは知っていて、且つ、使わない判断をしなければならない。
取り扱う範囲
システム開発を受託や社内開発のイメージにするとシステム開発プロジェクトになるので、システム要件が提示された以降が範囲になりそうだ。
ただ、自社サービスの開発であれば、プロダクトマネジメントの要素が入ってくるので、範囲がぐっと広くなり、何を作るかからになる。
それでも、結局は、経営課題かビジネスモデルキャンバスのソリューションに当たるところがインプットになる。
その前のシステム要件や提供価値はビジネスオーナとしておく（がそれで良いか、あとで再考するかは考えどころ）
インプット
上述から、システム要件、提供価値がインプット。いずれにしろインプットは必要。自分でプロダクトを作る、何だかよくイメージできていない段階だとしても、ペーパーでモックを作るにしても、それを作るインプット（を作りながら形作るのかもしれないが）はあるのである。
手のつけ方
4つの知識エリアのどこから手をつけるか。これはこれから考える。
マネージャだけどメンバを対等に扱う理由
自分はマネージャである。随分、長い間マネージャをやっている気がする。かれこれ10数年か…管理職としてのマネージャもあるし、それよりプロジェクトマネージャの方が長いのだが。
もしかすると以前に書いたかもしれないし、多分、触れたのだろうと思うのだが、プロマネは単なる役割、ロールであって、プロマネだけがいてもプロジェクトは回らない。メンバがいて、それぞれがプロジェクトの役割を担うことを承諾してくれて初めてプロジェクトが始められる。メンバが役割分担、ロールを担うことで成立する仕組みなのである。
だから、メンバには対等であるとはっきりと伝える。それを伝えてから、である。では、あなたはプロジェクトチームの役割としての期待にどう応えてくれるのか、と。
マネージャ業でも同じように振る舞う。たまたま、この一瞬、あなたの上司を担っているに過ぎない。それは、そのときの組織が自分に役割を紐付けただけの話であって、明日は、別のプロジェクトに出向いているかもしれない。マネージャもやはり、ロールなのである。
そうした考え方のベースを持っている。
そのベースの上に立つとき、それぞれのメンバに期待することは、期待するロールを担うスキルを持ち、そのスキルを発揮してもらうことである。
ロールはスキルを持っているからアサイメントする。稀に、実戦でスキル上げをして欲しくてアサイメントすることもあるが、基本は担わせるスキルを持っているからアサイメントする。
役割を担う。その役割に必要とするスキルを持っていることは必要である。
そう、メンバは自分の持っていないスキルを持っている。
理由はこれである。持っていないものを持っている。そんなメンバを単なるリソースとして扱うことができるだろうか。
腫れ物を扱うようには扱わない。ただ、対等に扱う。あなたと自分は対等であるから、専門家として言いたいことは好きに言い給え。
それで咎められることはない。
逆に、専門家として自分の考え、やり方が間違っていたら何も気にせず指摘しなければならない。自分がそれを聞き、苛立ったり、不機嫌になったら、それは専門家として正しいことを言っているのだ。
ズバリ、痛いところを突いているということである。
そうしたやり取りをしたいのである。そこに、未だ未熟な自分を育てるチャンスがある。
平成でなくなった我が家のITガジェット
この『キーキーキー』『カーカーカー』が何の音かわかるのは40代以上なのかぁ、と思うのだが。
それと、人によりモデムの音の聞こえ方は違うのだとよく理解できる表現でもある。モデムの音は『ピーゴロゴロ』だとばかり思っていた。
この若宮さんの記事は色々と学びがあるのでオススメする。時間の無駄にはならないと思う。
電話回線を使った「キーキーキー」「カーカーカー」とか変な音がする仕組みを使って接続しました。
で、モデムである。
モデムを意識したのは自分の家用にというか、結婚したときに所謂マルチメディアパソコンを買ったのが始めで、まだniftyがパティオとかやっていた時代である。
なんかめちゃ高かった。30万以上した。CPUは486だったか。そのPCにモデムを設定して、ダイヤルアップ接続をするわけである。
とにかく、接続して、従量制で繋ぐ手順が面倒なのと、当時は全くネット依存症でもなかったのでTVの方をよく見ていたに違いない。
新婚でもあったし、眺めていたい対象はPCの中ではなかったということでもある。
ただ、オススメされたPCゲームがあり、それはやってみたがそれほど面白いとは思わなかった。ゲームも２−３やったきりである。
当時は。
そのモデムもなくなり…いや、なくなったのではなくケーブルモデムに置き換わり、常時接続になったので面倒臭さを感じなくなったのだ。
まあ、そのケーブルモデムも約10年に一度くらいは壊れるので、交換するときかwifiルータを変えるときにケーブルを繋ぎかえるときに意識するくらいである。
あと無くなったもの、意識しなくなったものと言えば、スキャナか。プリンタと一緒に、割と良いモデルを買ったが、ろくすっぽ使わないで箱に閉まっておしまいである。
そう言えば、デジタルカメラも２−３機種を使ったが、iPhoneに置き換わってしまった。これも便利さで淘汰されたのだ。
記録メディアも我が家では淘汰された方なのだが、一部残っているのはCD-R。これは車で音楽を聴く際に、焼いたCD-Rを持ち込むからなのだが、車を変えるまではCD-Rは生き残るだろう。
DVD-Rも一時期、録画保存用に使っていたが、Amazon PrimeやPS3で録画するようになったことと割とBDの円盤を買うようになったので、手間を掛けてデータを移すことはやめた。
共通しているのは、手間がない方サービスに利便性を感じてトランスファーしているのだということである。
次は何が無くなるのだろう。
