属人化による『技術的負債』は誰も気にしない

まず、技術的負債とは何かを改めて確認しよう。技術的負債の検索結果の1番はQiitaである。でもwikipediaを参照する。

次に、誰の目線で技術的負債を見るか、を決めておこう。今回は、プロジェクトマネージャの視点でみる。このポジションは読み手の立場で変えて構わない。一度、自分の立場で見た後、一つ上の立場で見直すと差異を感じられるので、ぜひ試して欲しい。

 

技術的負債(英: Technical debt)とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である[1]。「設計上の負債(design debt)」とも言う。

1992年ウォード・カニンガムが、技術的な複雑さと債務の比較を経験報告で初めて行った。

引用 技術的負債 - Wikipedia

 

プロジェクトマネージャの立場であるから『余裕のないソフトウェア開発が引き起こす結果』という文章に、戒めを感じなければならない。自分がキャリーするプロジェクトでは、それを引きおこなさない手段を講じているとしても。

 

最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる[2]。

引用 同上

 

よくないものを作るとそれ自身が足枷となり、開発チームの首を絞める。まあ、誰がそれをつくるか、ということである。

あと、引用での負債そのものは、コードなりの成果物として存在するが、実際には、誰が作るかという根本原因=人という事実まで踏み込む必要があるのではないか、と思うのだが。

そうした原因や諸条件に引き起こされる事象として表された結果を目の当たりにして立ち竦んでいるのではないだろうか。

 

その他にも、技術的負債の例として、組織で共有されない知識や、複雑すぎて変更が難しいコードなどがある。

引用 同上

 

技術的負債のバリエーションについて述べられているとおり、世間はそうした共有されない個人の経験知をいかに引き継げるように仕組みを考えて来た。一つの現れは、ナレッジシステム(死語)であり、組織のポータルサイトリポジトリ、技術伝承のための仕組みである。

ではそうした取り組みでの成果はあったのだろうか。

結論から言えば、ナレッジシステムに代表される業務上の情報共有のデファクトがないことを見れば、個々に得られた知は蓄積し続けることはなく、活かされることも無い。

局所的、一時的にはあるが、組織として、継続しては活かされない。

なぜか。

知を有している個人において、各自で持っている知を他人にとって価値のあるものであると認識しないためである。それは、当人は自然に身につけたものであり、知を持っている本人にとっては付加価値を感じないためである。

さらに言えば、その知を第三者が認知することがないためである。それは当然で、知を持っている人がその知に価値を認知しないのだから形式知として現れることががない。よって、視界に入らないのだから、第三者には触れる機会がない。

よって、形式知は一向に共有されないし、強制的に知を出すことを求められなければ続くことはなく、消えていくのである。

で、『属人化による技術的負債』である。

上述を踏まえれば、プロジェクトチームの中で行なっているのは情報共有である。情報共有が行われるのは、SOWによる役割分担である。チームとしてのスキルセットを満たすために、技能を持つエンジニアを招集し、役割をアサイメントする。

そこで起きるのは小さなチームであっても役割で分断される縦割りである。その結果、情報は個人に属し、成果物もまた個人に属することになる。

プロジェクトが時系列を追うごとに増減する計画とした時点で無条件に属人化による技術的負債を生じることになる。それは前述した理由による。

では、道幅が同じであればそれを防止することができるか。

できないだろうし、ある対策を行えば防止することができる。

それは、役割において正副の担当をつけることである。なんてことはない。成果物に対する冗長化を行うことである。先に述べたとおり、原因は個人に情報を属させることなのであることから、そうしない策を最初からコストを支払い対策をしておく他ない。一つ、良い意味での副作用がある。それは開発を止めないという効能である。

この策をできないと頭から否定するのであれば、一生、属人化による技術的負債をしらってくれればいい。

なあに、あなたが支払うのだから誰も気にしない。

 

 

漫画家とヤクザ1【電子限定漫画付き】 (ラブコフレコミックス)

漫画家とヤクザ1【電子限定漫画付き】 (ラブコフレコミックス)

 

 

指示待ちとコンプラで壁を作るSIerエンジニアの乗り越え方

SIerのエンジニアの特徴はいくつかある。基本は指示すると文句をいうこともあるが『No』とは言わない。Noと言わないのは事業会社のIT部門でもよく見かけるが、ちょっと違う。事業会社だと自社の事業に関わるここと、指示するのが上司や先輩だったりするのでNoと言った後、色々面倒臭くなる。だから、言わない。

ところが、SIerのエンジニアはそうではない。プロジェクトが終わればまた次のプロジェクトに渡っていくので事業会社のそれのような縛りがない。多重請負であればことさらである。次のSESの常駐先に行けば良いのである。

でも、NOと言わない。基本的に、受け身であるからである。それもある意味、訓練されてた、調教された結果、であるのかもしれない。

もう1つの特徴は、壁を作る。これはコンプライアンスや契約を超えた作業に対する注意喚起がしっかりされているSIerのリーダに多い。担当レベルのエンジニアだとこの辺りの知識がなかったり、言われたらやるものだと調教されているのでやるのである。

しかし、スコープに関わるようになると管理部門などから何度も言われるし、コンプラ名目で教育をしていると、担当エンジニアだろうと壁は作るものだと刷り込まれる。

契約を理解し、契約のことを履行するために行動するのは正しいのだが、エンジニアも人の子でエンジニアにより、そうした特徴が強く出る人が出てくる。

多分に、前者は後者の後にその性質を身につけた方が柔軟である。

自分がエンジニアとしてプロジェクトを遂行するために、そして完了させるために何をしなければならないかを理解することは、良いことであるし、ぜひそうしていただきたい。プロジェクトとして、チームとして方向性を合わせるのは必須のことなので。

その上で、契約外のことは、それを判断する権限を持っていなければ、自分で判断できないという意味合いで『No』と言えばいい。

まあ、課題管理に載せておきましょう、と言い、自分からボールを手放せばいいのであるが。

こうした壁を意識することは、契約においては必要なことであるが、エンジニアとしての価値を上げていくための活動では、無意識にこれが出るとマイナスに働く。

ここまで、と線を切るのは契約で、権限を持ってからでよい(そういった話が来たらプロジェクトに引き渡すことは必要)。

普段の業務で繰り返し行っている振る舞いは、自然と身についてしまう。そうして身についたものは、後で色々と取り返しが効かなくなる。

新しい技術に取り組む必要がある場面で、無意識に壁を作ってしまうからだ。身についたものは、思考が行動を無意識に制御してしまうので、自分が気づくより先に口に出てしまう。

それが、なんでも『No』という言葉で表されるのである。

どちらもできるように、意識的に自分がつくる壁からはみ出すことをやろう。それも物理的に移動する行為を含んだ方が効果的である。

そして、壁からはみ出て見えるものに対して興味を持とう。

 

 

 

 

自分の小さな「箱」から脱出する方法

自分の小さな「箱」から脱出する方法

  • 作者: アービンジャーインスティチュート,金森重樹,冨永星
  • 出版社/メーカー: 大和書房
  • 発売日: 2006/10/19
  • メディア: 単行本(ソフトカバー)
  • 購入: 156人 クリック: 3,495回
  • この商品を含むブログ (418件) を見る
 

 

 

 

 

最近買ってよかったもの ポーター(porter)・コッピ・サコッシュ (ネイビー) 571-09747

最近買ってよかったもの。

 ワイフや子どもさんがサコッシュを持ってライブに行っているのをみて、あーあると便利そうと思ってライブ当日にお店でいくつかの候補の中からこれを。

オールスタンディングだと、小さめでもリュックは邪魔になるのを前回学んだので、サコッシュはいいわ。

 

 

日々是クエスト

例えば、チームの一人のエンジニアとしてプロジェクトに参画していて、自分の次のキャリアパスを考えるとき、どのようなことを思い、どのようにアプローチするだろうか。

ただ、ただ、一生懸命仕事をしてれば『いつかは』『誰かが』『自分の』『貢献を』『評価して』くれる、などと思ってはいないだろうか。

もっともらしい書き出しでもっともらしいことを書いている自分も、確かに20代のイケてない頃はそんな風にボーッと過ごしていたのである。

全く話にならない。今思えば、20代の数年をドブに捨ててきたようなものである。

このエントリを読んでいる若いエンジニアの方は同じ轍を踏むことはないだろうが、どうしたらいいかヒントを欲しい方の参考になるかもしれないので、1つの事例を示す。

属する組織のキャリアパスを確認する

組織の中に属して、その中でキャリアを積みたいと考えているのが今である。であれば、組織のルールを知らなければならない。

また、ルールと運用は違っていることが多い。ルールが理想すぎて運用が追いついていないかもしれないし、ルール通りにやっていたらポジションが詰まってしまい上に上げるための空き席が出るまで滞留させられるのかもしれない。

とにかく、キャリアパスと条件を確認する。 

その上で、同期がどこまで上がっているかを人事報や社内認定の告知などで知っておく。

キャリアパスの条件を知る

 キャリアパスはどこの組織でも段階化されている。ステップを上がるためには条件を満たしていなければならない。

それも通常、キャリアパスで求められるエンジニア像として明示されているものだ。もしそうした段階ごとに求められるエンジニアのスキルセットが文書化されていない場合は、かなり、評価者の感情でキャリアが振り回されると思った方が良い。

とはいえ、手を拱いている訳にもいかないので、ない場合は、キャリアパスで次だと思う上位者のエンジニアを二人くらい見つけてどのようなスキルを持っているかを観察する。

キャリアが上になればなるほど、技術はもちろん、推進力や統率力を持っていることが多いことに気づくはずだ。

日々是クエストする

 あとはクエストでレベル上げするだけである。どうするか。日々、毎日の仕事のなかで、次のキャリアだったらどうするか、どう考え、どう判断し、どう結果を出しているかを強く意識して仕事をクエストする。

ひたすら、クエストする。

Doneの定義は、次のキャリアの段階相当のスキルを持っていて、いつでも発揮できる状態かどうか、である。

 

 

ドラゴンクエストXを支える技術 ── 大規模オンラインRPGの舞台裏

ドラゴンクエストXを支える技術 ── 大規模オンラインRPGの舞台裏

 

 

リモートワークはしない

既に死語な印象を持っている働き方改革で在宅勤務や場所にとらわれない勤務形態が広まりつつある。ジワリ、ではあるが。

やはり、ITのインフラが整っているIT業界、それもSESのような客先常駐でない本社部門や営業職、サービサーなどの自社でサービスを提供している会社の方が進んでいる。まあ、もともと、仕事自体が他のメンバと疎結合であるからそれができるのであるが。

もう、10年くらい前だと思うが、マネージャとしてあちらこちらのプロジェクトや提案に週の半分くらいで歩いていた時期があった。スケジュールを見れば予定で埋まっており、自席は空いたままで、側から見れば仕事をしているように見えただろうし、当時の本人も仕事をした気になっていた。

あちらこちらに行くとなると、移動が発生するので実はとても効率は悪くなる。正味の仕事時間は減って行く。そうするとどこかでそのカバーをしようとするので無理するのである。

これはダメだな。そう思って、外出における負担の平準化をしたのである。

働き方改革は自宅や事業所に準ずる場所で仕事をすることで通勤時間や勤務時間帯を柔軟にしようというものである(大分意訳している)ので、上述の外出ばかりとはちょっと事情は違う。でも、やはり、移動を減らし、仕事のリソースを確保するという観点では共通的なところがある。

結局は、どちらもやりたいことは『リソースの確保』でしかない。

では、リソースが確保できるのなら、リモートワークでいいじゃないかと思うのは自然である。誰も、1時間も揺られて混雑する電車に乗る必要はない。

実際、リモートワークを広めるには、次の観点での仕事の仕方が必要である。それは、仕事をきりだせるということである。出す方は出す方で仕事の完了条件なりをしっかりと伝えなければならないが、仕事をする側も自分で色々と裁量を持って判断しなければいけなくなる。指示待ちのような仕事しかできないエンジニアにはリモートワークはできない。仕事の先を考えられないからである。

その点で言えば自分はリモートワークすべきなのであるが、1つ問題がある。家では仕事をする気になれないのである。以前、農家の働き方で良くないところは、家と仕事の境界線がないことであると聞いたことがある。1−2分でも場所を移動し、服装を作業着に変えないとスイッチが入らないし、オフれないらしい。

確かに、通勤というよりは、仕事場の方が仕事をする気になる。その点において、自分は仕事場を結局身近かなところに欲しくなる。そうすると本末転倒な気がしてならない。

結局、仕事場に行くか、となってしまう。まあ、通勤さえなければそれはそれで良いのだが。

 

 

職場の問題地図 ~「で、どこから変える?」残業だらけ・休めない働き方

職場の問題地図 ~「で、どこから変える?」残業だらけ・休めない働き方