know your project!! （己のプロジェクトを知れ）

ものの例えで話を始めると、潜水艦が潜行しているときには計画した通りの航路で進みながら、様々な計器を使用して安全を確かめる必要があります。

＃軍事専門家から見た時の表現的な誤りはご容赦

これ、何かに類似していますよね。そう、システム開発のプロジェクトそのものです。

ではどうして潜水艦の先行ではそうなってしまうかというと、視認できないからです。浮上していればハッチから出て確認すれば見ている海面より上は視認できますけど、相変わらず海面下はね、計器頼みな訳です。

元々が潜行して航行することを目的として建造されているのですから、常時海面に出ているわけにはいかないので。で、潜行するとまた計器頼みに。

一方のシステム開発は、プロジェクト計画書という計画した航路に沿って設計書を作成し、顧客と合意しつつコードを書くわけですが実際の動くシステムが組みあがらないとどんなシステムになっているのか誰も知らないのです。

いやいや、エンジニアは知っているじゃないか。だって自分たちで設計して、コーディングをしているんだろう、と、エンジニア以外の人は思っているんですよ。

でも、実は誰もどんなシステムに構成されるのか知らないわけです。

なぜなら、分業をしているから。

ただ、分業をしているからばかりじゃない。プロジェクトマネージャ以外は、誰もプロジェクトを知らないから、誰一人どんなシステムを作ろうとしているか知らないのです。

そしてプロジェクトマネージャもエンジニアにどんなシステムを作らなければならないのかを仔細に話をしないし、繰り返し説明もしない。

さて、これでプロジェクトという潜水艦に乗ったクルーを担うエンジニアと艦長のプロジェクトマネージャは航路の計画（プロジェクト計画書）どおりに計器頼みで安全に目的地に進むことができると思いますか。

航路の計画もただ海図に出発地と目的地に直線を引いいて進めばいいわけじゃないのです。湾内であれば決められた航路があるものだし、それは水深が浅いところがあって座礁しないように配慮されているという理由があったりするからです。

湾外に出たとしても同じように海中の隆起や他の船舶との衝突を避けて運行しなければならないわけです。

決められた航路はプラクティスや法律での制約と同じようなものだし、湾外での機器による検知はリスクマネジメントのようなものです。

know your boat!!　（己の艦を知れ）

ならぬ、

know your project!!　（己のプロジェクトを知れ）

なのではないか、と。

今のエンジニアはプロジェクトを安全に進度させたいと願っているなら、まず初めにしなければならないのは　know your project!!　なのではないでしょうか。

まあ、プロジェクトマネージャも繰り返し説明してエンジニアが期待する成果を出すようにしろよ、ってところですけどね。

米海軍で屈指の潜水艦艦長による「最強組織」の作り方

エンジニアの評価はマネージャに見えていた残像でされている

エンジニアの業績評価は難しいのです。何せ、誰一人として同じ仕事をしていないところで、1年分の労働に対する貢献度を評価しなければならないのですから。

評価方法と言えるかどうかも怪しいですが、それぞれの組織においてエンジニアの業績方法は通常、人事担当が主務として構成し、それをマネージャに指示するのが一般的でしょう。

エンジニアの業績評価での問題点というか曖昧さが生じる事項は次のようなものが挙げられます。

1. 同じ仕事でないエンジニアを1つの評価基準で評価しようとしていること
2. エンジニアの仕事をマネージャが全て知っているわけではないということ
3. エンジニア個人の絶対評価と組織の中での相対評価の2軸があること
4. 評価結果は次年度予算に組み込まれるので評価の上限があること
5. マネージャは人の評価方法を知らないこと

同じ仕事でないエンジニアを1つの評価基準で評価しようとしていること

製造業で、同じラインで働いているなら、 評価もしやすいでしょう。生産計画に従った生産量を確保でき、期待する品質を確保できるような監視と予防活動に取り組み、後進を指導し、勤怠も問題なければプラスの評価をされるでしょう。

ものを作ることには変わりはないですが、エンジニアは一人ひとりの作業が違います。まあ、大規模プロジェクトで同一サブシステムの機能を分担してプログラムを書くようなケースは割とニアリーイコールかもしれませんがやはり担当する機能の難易度が同じということはないです。何かしら違うので。

つまり、評価対象であるエンジニアの業務の成果は一品ものなのだ、という評価対象が違うというところの理解が必要です。

エンジニアの仕事をマネージャが全て知っているわけではないということ

 標題のとおり、エンジニアの仕事をマネージャが全部知っているわけではないです。マネージャもプロジェクトにどっぷり入って、プロマネ＝マネージャのようなアサイメントなら割と知っているかもしれませんが、それでもやはり、エンジニアのひとつ一つの成果までは知りようがありません。断片的に、進捗や品質評価でしか知りようがないのです。

エンジニア個人の絶対評価と組織の中での相対評価の2軸があること

 エンジニアの成果の評価は、個人の成果を評価する軸とそれを組織の中での貢献度合いを評価する2つの軸で評価するケースが多いです。なぜなら、前者だけで評価をしてしまうと、エンジニアの評価がインフレを起こしやすいからです。

どういうことかというと、評価項目に対して達成したかどうかになるのでやったと言いやすいし、エビデンスとしての成果が提示できれば評価せざるを得ないからです。

一方、組織としては有能なエンジニアは上に引っ張り挙げたいので序列をしたくなるのです。結果的に相対評価が必要になります。

評価結果は次年度予算に組み込まれるので評価の上限があること

 エンジニアの対価は予算措置をされた上で支払われています。つまり、前年の評価を考慮し、昇給を反映した上で労務費を計上しているわけです。

逆に言えば、労務費の予算枠があるよ、それ以上は評価＝昇給はできないよということです。

いくらエンジニアが評価しろ、昇給させろと言っても枠でキャップがかかるのでその中で調整が組織全体で入るよということです。

マネージャは人の評価方法を知らないこと

これが一番の問題なのですけれど…マネージャが正しい業績評価の手法を学び、習得しているなんて思ってはいけません。

例えば、オリジナルだとしても評価方法を持って、その評価方法で評価しているマネージャなんて一握りくらいなものです。ちなみに、これまでそうした評価方法をしているマネージャは一人を除いて聞いたことはありません。

つまり、エンジニアの評価はマネージャの印象で評価されているのです。これは、エンジニア同士の評価であっても同じです。基本的には持っている情報若しくは提供される情報の範囲だけで主観により評価されているのです。

問題だと思うことは、印象で評価をすることになるのでマネージャに見えているエンジニアほど良くも悪くも評価を受けやすいということです。マネージャが評価方法を持っていて、評価項目からエンジニアを見る場合は全てのエンジニアを評価項目の視点で見ようとするので同じ評価軸で評価する方向に働きますが、エンジニアの見えている部分だけで評価するマネージャはマネージャに対する見え方でバイアスが強く掛かるので評価軸で評価するマネージャとは違う評価結果を出します。

マネージャの見え方で評価しているから労働時間が長いエンジニアや炎上させて周りを巻き込んで鎮火に到るまで残ったエンジニアが評価をされるのです。

違いますよね。本来であれば、

求められているソフトウェアを、予定どおりに、計画より少ないコストで

— ふみさん (@finayama) 2017年11月21日

 実現できたエンジニアを評価しなければなりません。

こういったことも一切合切含めてそういうものだ、と思えるくらいの評価をしてくれるマネージャなら当たりなんだと思います。 

滅多にいませんが。

氷菓 (角川文庫)

ピーターの法則　創造的無能のすすめ

プロジェクトマネジメントは誰のものか

最近立ち上がった勉強会での一コマ。

「若いうちからプロジェクトマネージャにアサインするケースがあるじゃないですか。でも、プロジェクトマネジメントの全体をわかっているわけではないので、日々の転がしで精一杯なんですよ。そう言う状況で経営にも報告しなければならないのって、すごく無理がありませんか」

「プロジェクトマネジメント自体が経営者のものだからねぇ。経営の見通しをするために進捗中のプロジェクトの健全性を把握するためのツールだし」

「そこにたどり着くまでにどれだけ時間が掛かるか…」

「プロジェクトマネジメントは経営のものだという前提に立って、経営に報告するためのインタフェースがレポートに当たるわけで。プログラムと同じでインタフェースのお作法は守らないと通信できないでしょう。だから、進捗管理をレポートに合わせられるメッシュでデータを持っておく必要があるし、そうしておかないとレポート用にリソースを割かなければならなくなってしまうんだなぁ」

プロジェクトマネージャになるとやらなければならないことがそれこそPMBOKに書いている知識エリア以上のことをやらなければならないので。

現場のチームを向けば、システム開発手法による実際のものづくりを進めなければならないし、それこそプロジェクトを経営者の代行としてマネジメントしなければならないので。

場合によってはプレイングマネージャだったりすると、一部のリソースはエンジニアとしての自分に振り分けなければならないことになってしまうので。

3つも帽子を被ろうとすると、それはそれで無理が出てくるわけです。だからプロジェクトマネージャは専任に、と言うよりはエンジニアとは分離せよ、なのだと思うのですが。

話はさらに続きます。

「経営がアジャイルでやろうとか、どこで齧ってきたのか突然バズワードを言い始めることがありますよね」

「世間ではあるようですね」

「どうですか」

「どうなんです、そちらでは」

「やばいですね。手段が目的…もあるんですが、プロジェクトのレポートをみて『アジャイルじゃダメか』とか」

「ウォーターフォールの事故数の方が積算では絶対数が多いいのにね」

「そうなんですよ」

「だから小さく、成功度合いの高いプロジェクトから適用しないといけないと言われるんだよね」

新しい手法に好感を持っていたり、広めたいと思っていたら成功させたいと思うことは当然です。失敗するとそこから学ぼうとする経営でなければ打ち切られて、2度と採用できなくなってしまいますから。

じゃあウォーターフォールはどうなんだと。

「アジャイルには標準がないと思うんですけど、何かテンプレートになるものがないですか」

「みんな誤解をしていると思うんだけど、ウォーターフォールだって標準ってないですよ。亜種ばっかり」

「そんなことはないのでは。エンジニアは誰でも知っているじゃないですか。それに特段、学習しなくてもウォーターフォールで開発を始められますよね」

「それは、エンジニアが過去に経験してきた経験知で予測して対応しているだけの世界ですよ。それが成り立たない上でのプロジェクトはすぐに崩壊してしまうんです」

結局、何かしらこれがテンプレートだと一旦仮置きしてそれをその組織の標準とするか、手続きのプロシージャだけを決めておくしかないのではないかと。

まあ、これがテンプレとできるくらいなら、ウォーターフォールであって当然なんだけれどどれだけあるんだろうなぁと思っているうちに、勉強会は続くことが決まったようでした。

さて、大元のプロジェクトマネージャはどう育てるのかしら。

学習する組織――システム思考で未来を創造する

生きる失敗、無駄な失敗

振り返ると30代半ばまでの失敗はその失敗を生かすことができなかった「無駄な失敗」だったと思うのです。30代半ばがひとつのターニングポイントなのでそこからは全部が無駄な失敗ではなく、なんとか、そこそこにその失敗を生かせているのではないか、と。

生きる失敗

 生きる失敗としているのは、進捗させてみたら想定していたとおりにならない状態になってもその作業期間のお終いにはなんらかの修正をすることで失敗したことを作業期間内にフィードバックして別の手段を考えるように方向転換したりするケース。

別のパターンは、がっつりと心に2度と繰り返したくないほどの、謂わばトラウマのような失敗をして、同じリスクに対する感度を目一杯あげて同じようなケースの場面に遭遇したときには、2度と繰り返したくない経験を引っ張り出してきて同じ轍を踏まないようにすることかと。

前者の小さな失敗は、その作業内で上手くいかないことを経験的に識別して、別の選択肢にスイッチすることで辻褄を合わせる感じです。大事なことは、上手くいっているか、ダメダメそうなのかの判断ポイントの見極めです。

この判断をすると言うことに全力をかけておかないと、ズルズルと引っ張ってしまい、終いにはリカバリできなくなってしまうのです。そうならないように、どこまで我慢するか、スパッとスイッチするかは悩みそうなら、作業を始める前に決めておき、我慢し過ぎたり、逆に効果を得られる前に間違った判断をしないようにすることは気に留めておいた方が良いです。

無駄な失敗

 生きる失敗の真逆といってしまえば簡単でそれっぽいですが、実はそうじゃないのです。

まず、無駄な失敗とは失敗している状態で終わりにしてしまうことです。もちろん、プロジェクトを失敗したと組織が判断してプロジェクトを中止してしまったら何かしらの失敗があったと言うことですし、バサっと突然に終わることの方が多いのでそうしたケースでは取り戻すためのスイッチなり、後続する工程で修正策を行うことができません。

これはプロジェクトの特性としての有期限性のためなので、それはそう言うものだ、としておきます。

ではどうするのかといえば、失敗してしまったことの当事者として次はどうするのかと言うことを行動に移せるか移せないかが無駄な失敗にしてしまうかどうかの判断ポイントなのです。

失敗した当事者として、失敗した様々な要因を分解して、どこの判断からの積み重ねで方向を間違っていったのか。これを人が判断したからとしてしまうのもまた無駄な失敗となってしまいます。

しなければならないのはどこから判断を間違え続けたかの起点を探すこととどんな情報でどんな判断基準で判断をしたか、定量的にすることが無駄な失敗のままにしておくか、生きる失敗に質を変えるかの分岐点になります。

失敗はしていい、小さな失敗をたくさんしようと言うのは失敗のままにしておかないことを前提としているのです。

穿った見方をすれば、結局、コントロールできる範囲の持ち方の捉え方で辻褄を合わせているだけなのですけれど、そのくらいでないとオチオチと失敗できないので、このくらいのゆるさでいいのですよね。

仕事は楽しいかね?

失敗の本質―日本軍の組織論的研究 (中公文庫)

システムを「外注」するときに読む本

「変わるもの」と「変わらないもの」にどう立ち向かうかのヒントを見つけよう

まず、変わるってどういう意味かを確認しましょう。

一面的にしかものを見る癖がついてしまうと、辞書を引く前から一方的なものの見方、解釈の仕方しかできなくなってしまうので日頃から360度のビューワをぐるぐると回すように、ものを見るポジションを次々と変えられるように繰り返し試しておきましょう。

特に、エンジニアではない、別の役割、例えばマネージャ、顧客などの立場なら世界がどう見えているかを感情的な部分を切り離して意識を切り替えられることは日常の業務で有効なスキルになります。

それで、変わる＝変化という言葉の意味を確認しましょう。 

へん‐か〔‐クワ〕【変化】の意味
［名］(スル)
１ ある状態や性質などが他の状態や性質に変わること。「時代の変化についていけない」「変化に富む生活」「気温が急激に変化する」

２ 文法で、単語の語形が人称・数・格などに応じて変わること。「動詞の語尾が変化する」

引用　変化（へんか）の意味 - goo国語辞書

 どうして、役割を意識した視点の持ち方に触れたかというと、変化するということには、良い悪いという捉え方は間違いで、状態が変わるという捉え方をしなければ判断自体を誤ってしまうということがあるためです。

よくやってしまうのは、変化したときに基準を持たないで良し悪しを印象だけで考えようとしてしまうことで、その前には、変化することを評価するということが目的となっているかどうかで評価するしないをしなければならないということです。

言い換えれば、変化すること自体を意識して見る必要があるかどうかということなのです。

登場人物を揃える

エンジニアビューから見たときに状態が変わっていくものを登場人物として書き出してみましょう。

人物系（状態）

• エンジニア自身
• チームメンバ
• チーム
• 組織
• 顧客

人物以外（質）

• 経験（習熟度）
• 能力（できること、できるレベル）
• 技術（高度化）
• 価値観（判断基準・開発スピードなど）

ざっくりと思いつくままに書き出すとこんな感じでしょうか。 

さて、エンジニアを取り巻く要素全てがそれぞれで登場人物（状態）や人物以外（質）が変化する要素を持っていることに気づいたと思います。

これは仮にエンジニア自身が変わらないとしても、エンジニアと普段から接する登場人物が変化していくし、エンジニアが使う道具も質が変化していくのです。これでエンジニアが何も影響を受けないでいられるでしょうか。

こうしてエンジニアを取り巻く登場人物を取り揃えてみると、もはや変わらないという考え方自体が間違っているような気がしてきます。

「変わる」源泉は何か

 では何が源泉となってエンジニアを取り巻く状態や質が変わっていくのでしょうか。

それは時間の経過とともに経験知を積み重ねていくためだ、と思うのです。つまり、エンジニアとして生きていく以上、変わることが必然であり、状態や質を変えないということは、逆行する考え方である、というものの見方です。

「変わる」「変わらない」を取り違えている

状態や質を変えないという行為は、実はシステム開発ではよく行っていることです。

例えば、品質は、要求される品質へ到達している状態を維持しようとします。例えば、チームは作業で期待する成果を一定のレベルで得られるように活動をします。

これは普段変わらないと思っていることは、実は変わっているということであり、変わったと印象を持つことは、変化のスピードが体感できるほど状態や質が変質したということなのです。

更に言えば、変わらないということは状態や質を維持するために、刻々と変化している状態や質をリソースをかけて維持しているということになるのです。

これは、放っておいても無意識で変化するというということに対する、エンジニアが実現したいことをどう定義するかにかかっているということです。

チーズはどこへ消えた？ (扶桑社ＢＯＯＫＳ)

あなたの技術料はおいくらですか

このエントリを読みつつ思い浮かべていたのは、エンジニアで自分の技術料をどのくらいで売りたいかとか、それより以前の話で値付けをできる人がほとんどいないのではないかと思うのですがそんなことはないでしょうかね。

↓の無償、有償の話とは違う、エンジニアの値付けの話なのですので。

note103.hatenablog.com

エンジニアの労務単価も　JIS 単価 労務 - Google 検索　と同じように決まりがあれば誰も悩みはしないのですが、端的に言えばそれがないのでエンジニアが持っている技術料の価格設定をエンジニア自身は知らないし、知ろうともしないし、値付けをした経験もないわけです。

多くのエンジニアは良くも悪くもエンジニアの技術料を売るのは営業で、職種で販売と供給を分離していることがエンジニア自身の技術料をエンジニア自身が知らないし、売る技術料の価値の評価方法を誰も知らないから人月という拘束時間で人売りが生じるわけです。人月商売の話を今回はするつもりはないので、それは過去のエントリを検索してもらうかまた次の機会に。

あなたの技術料を教えてください

と言われたら何をいくらと答えますか。

ほとんどのエンジニアは回答に窮するのではないかなぁと思うのですが。答えらるエンジニアは転職の経験があって転職エージェントが年収いくらといったから、とか、提案で自社の人月単価を知っているからくらいなのではと思うのです。

なので、技術料でいくら、という値付けは答えられない、と。

これがサービスを提供している個人事業主のエンジニアになると提供するサービスに値付けをしているからこのサービスならいくら、とすぐに答えることができます。

やはり、売るものを持っていると提供する技術料の値付けを自分でやっているからある意味強いです。

安く値付けてしまう

 事業として売り物を持っていると売るまでや売った後のかかるコストを知っているのでそのコストに利益を乗せて売ればいいという理屈を知っていますし、実際にかかるコストが雑多でそのぶんを確実に回収しないとビジネスとして回らないので回収できる値付けをしてきます。

こうした技術料を提示するまでに必要となるコスト構造を知っているか知らないかでトンチンカンな値付けをしてしまったり、売ってはいけない価格で受注してしまうことが起きているわけです。

市場価値・コスト・提供する技術

市場価値についてもなんとはなく、買い手の希望である、－そりゃそうです、いくら売り手が値段をつけても買い手がいなければ商売は成立しないで－、と思っているのでそういう値段であることだと理解した上で、いくらくらいで自分が売れるのかというのは知っておく方がいいです。

ただ、そうした市場価値は年収というざっくりしたものですから技術料にするならまた別の価格設定の考え方が必要となります。

市場価値でも技術料でもコストを賄えなければ売る意味がないのでコストにどれだけかかるかを理解しておかないと手に入れられるはずの利益が飛んでしまうのでこうしたコスト構造を知っておく必要があります。提供する技術料に直接かかる費用については視界に入り安いので意識されますが、社会保障制度の費用や税金は間接的にかかる費用なのですが確実に持っていかれるので忘れてはいけない課目です。

提供する技術は、まあ専門家としてこれが専門技術だと言えればいいです。ただ、売りたい技術に買い手がつくと思っていたら痛い目にあいますよ。それに技術がコモデティ化すると技術料が沈下していくし、競合が勝手に価格競争を始めるので何を売るかは考えながら売らないといけないし、当たり前ですが独占し続けられなければ技術更新は欠かせないです。それもまたコストがかかのでる。

価格の値付けを知るための副業

 色々とエンジニアの副業は取り上げられていますが、副業とはせずに、税務上、雑所得として申告することを本業とは別にすることをオススメします。

書籍の執筆もそうですし、アプリを作ってリリースするのもそうです。びっくりするくらい増刷やダンロードされれば別な話ですが、そんなことはまずないので心配せずに、エンジニアとして作る技術料の値付けを実践するためにやりましょう。

やってみるとわかりますがコスト構造を知っていて、それに見合う対価を確保することを考えるようになると安く売ることがどれだけ何も考えずに取引しているか、楽をして商売をすることでその先のエンジニアの首を絞めていくかがよくわかりますし、エンジニア自身が技術の更新をしないと欲しい価格が得られずコストも賄えないことが身を以て経験できるのです。

さて、あなたの技術料はおいくらですか。

作業の中心にエンジニアを置くための情報と技術のあり方

人は起きて欲しくないことが起きるまでは、たとえそれが起きた時にどうなるか類似の経験をしていても見向きもしないし、どちらかと言えば思い出したくもないような経験であればあるほど自分の視界からそれを遠ざけるものです。

システム開発でのそれはトラブルがそれにあたります。

情報の流れ

ウォーターフォール型のシステム開発を採用している場合、システム開発に必要な情報は、チームの組織構造の上位層から下位層に流れます。

トップマネジメント層からプロジェクトマネージャへ、顧客からプロジェクトマネージャへ、プロジェクトマネージャからアーキテクトへ、プロジェクトマネージャからSEリーダへ。SEリーダからエンジニアへ。

プロジェクトの継続を左右する重要なことであればそうした情報の流れは強固になります。

作業の担い手 

ところでプロジェクトチームでシステム開発の作業プロセスの担い手は誰でしょう。

誰もが間違いなく答えられるとおり、プロジェクトチームでの作業プロセスの担い手はエンジニアです。トップ層であるトップマネジメントでもプロジェクトマネージャでもありません。

プロジェクトチームのエンジニアが作業を遅滞なく進めなければプロジェクトは緩やかにブレーキを踏んだ状態でアクセルを踏むことになり、知らず識らずのうちに取り戻せない負債を抱え込むことになります。

担い手と情報

 では、エンジニアの作業を滞らせることは何か。

それは、システム開発上で要件を実現するために要件を具体化するために必要な情報です。

エンジニアは無形の要件を情報の加工、つまり、情報の詳細化を繰り返し行うことでコードに変換できるサイズまで分解し、コードに組み替えて今度は、無形のシステムとして再構成を行います。

作業の担い手であるエンジニアは、情報がなければ何も作り出すことはできません。

共有のあり方

 冒頭のように、システム開発でトラブルが起きてから情報共有をエンジニア全員にし始めることが多いのは、作業の担い手と情報を誰が必要としているかという組織における情報を必要とする処理プロセスを理解できていないと見ることができます。

これは、階層型組織構造を取る組織においても同じことです。

トラぶれば、朝会や全体ミーティングを頻繁に開き、エンジニアの作業時間を奪ってまでプロジェクトチーム全体を巻き込んで情報共有をし始めます。

これは何のために行なっているのか。

作業の担い手に、必要な情報を確実に共有するために行なっているのです。

フラット化とロール

 組織をフラットにするという考え方があります。これは中間管理層を減らすことで情報共有と意思決定の速度を上げるというものです。

これと同じようにプロジェクトチームの中でも情報についてはチームの中でフラット化をすることが平時からの情報共有を確実にオペレーションするために必要な組織構造のあり方となるのです。

つまり、プロジェクトチーム内のロールは階層を示すものではなく、これまでの過去のエントリでも繰り返し述べて来たとおり、ロールは担う役割の識別子でしかないとう考え方を実現しなければならないということです。

平時の共有

 プロジェクトチーム内の情報のフラット化による共有は、全体で共有する仕組みを作り、継続して共有を続けなければどうしようもありません。

プロジェクトの中での方向性や今後の計画については集合形式の情報共有による1:Nの拡散で実現できるテーマもありますが、技術の共有についてはそれは成り立ちません。

聞いているだけでは技術は身につきません。

そこで出てくるのがモブプログラミングです。チーム全員でそれを行うことで技術の共有を一度に行うことができる多分ただ一つの方法です。

情報を平時からフラット化したチームの組織構造の中で共有し、作業の担い手であるエンジニアがシステム化するための適用技術をモブプログラミングにより技術情報の共有を図ることを実現できるからこそ、ここ1年でモブプログラミングが脚光を浴びつつあるのです。

エクストリームプログラミング

組織パターン (Object Oriented SELECTION)