アクシア社の米村歩さんが、技術者の働きぶりをロールプレイングゲームに例えていました。これは面白い例え方だと思います。

毎日残業まみれで仕事をするということは、HPもMPも回復してない状態で敵と闘い続けるようなものという説明はとても理解しやすいです。実際、薬草をたくさん買い込んで戦闘を繰り返すのはダンジョンや塔の探索を行うという短期の目標が設定されているときに限られます。

現実には薬草の代わりにエナジードリンクを常用している人もいるようですが、エナジードリンクを常用している人がカフェイン中毒により死亡したという事故を起こしたのは記憶に新しいところですね。

「国内初、カフェイン中毒死　エナジードリンク日常的に大量摂取か」（産経ニュース、2015年12月22日）

適切な休暇を取らせないブラック企業は、社員から一番確実な睡眠という手段を奪い、対処療法で健康管理をさせた上、死亡リスクを社員に負わせているのかもしれません。

米村さんのロールプレイングゲームに例える方法は面白いので、ほかの面も同様にロールプレイングゲームの視点から考察してみたいと思います。

冒険のはじまり

「坊や、今日はお前の16歳の誕生日。さあ、早く起きなさい。お城の王さまに会いに行く日でしょう？」

こうやってエンドユーザに呼ばれて開発プロジェクトというものは始まります。16歳というのは、実年齢ではなく開発経験年数を考えましょう。経験16年というと脂の乗った技術者としてバリバリ働いている中年差し掛かりのオッサン技術者であることでしょう。

お城の王様、もといエンドユーザが提示する業務要件に従って、見積もりを行い、無事契約が交わされればめでたくプロジェクトがキックオフされます。

「そこにある宝箱で身支度するがよい」

王様はこのように述べ、城下町でそこそこ値の張る武器と、それよりも少ない支度金をくれるでしょう。実務でもそこそこの性能の開発機と、若干足りないのではないかという支度金をくれる構図はとても似ています。

モンスターを倒すように、次々現れる追加要望を倒しても資金が増えないところがゲームと違うところです。次に資金が増えるのは運用フェーズに入ってから追加案件を倒したときまでお預けです。

ですから、見積もりは正確に行う必要があります。工数見積もりについては、平田豊さんの記事が参考になると思います。

工数見積もりのコツ
https://qiita.com/yutakakn/items/b0e36196df474acf9359

クリアできない！

冒険を進めてみた結果、どうも納期までにはうまくプロジェクトが進みそうがないこともあります。当初の計画を鑑みて、破綻しかけている、あるいは破綻してしまったプロジェクトは「炎上プロジェクト」と呼ばれます。
プロジェクトが炎上してしまう原因には色々ありますが、パッと思いつくものを挙げます。

・戦いに備えて装備を整えなかった
・装備を購入するのをケチった
・そもそも装備を買うお金がない
・困ってから強い仲間を現地調達する気でいた
・でも自ら鍛練しないので強い仲間は応じない
・そもそも見積もりが間違っていた

この中で一番重たいのは最後の見積もりが間違っていたケースです。これは倒すべきラスボスの力量を見極めかれなかったことが一番の敗因ですから致命的です。見積もり違いはまさに混乱した自分が自分に繰り出す痛恨の一撃です。

見積もりが甘くなる素因として、王様が要件を出してこないケースもあります。実務はロールプレイングゲームと違って、プロジェクトは町の人の話を聞きながら少しずつヒントを集め、ゴールまで進むようなものではありませんから、要件を小出しにされたらたまったものではないでしょう。

とくとエンドユーザの話を聞き出すことが大切になります。もしかしたら「捕らわれている娘を見つけたら、連れて帰ってきて欲しい」という要望をこっそり出してくるかもしれません。

話を聞き出すときに注意が必要なのは、印籠を出したあとの水戸黄門の立場で聞くのではなく、出す前の光衛門として聞く心がけが必要です。水戸黄門の例えが適切かどうかは不明ですが、SESでは身分を隠してこれを行うことがありますから、まあ、いいということにしましょう。

時間的な制約もありますね。こつこつとレベル上げをしたり、強い武器を手に入れるために足しげくカジノに通って油を売っているヒマはないのです。ゲームセンターでバイトしていたことがありますが、油を売ることができるのは外回り担当の人くらいな感じでした。

炎上するプロジェクトについて知るにはアクシア社の米山歩さんのブログやスクエア・エニックス社の橋本善久さんのプレゼン資料が参考になるでしょう。

「システム開発のプロジェクトが炎上する理由」

「炎上したシステム開発プロジェクトを鎮火させる方法」

「ゲーム開発プロジェクトマネジメント講座」

学ばない技術者

学習が苦手な技術者はいます。学習は義務ではありませんが、学んだ人とは差がつきます。

たとえば、「メラ」という呪文があることをググって見つけたとしましょう。しかし、それだけではメラを使えるようにはなりません。メラを唱える練習する必要があります。

そこまで行ってはじめて応用できることが増えます。

・命中精度を上げるには？
・もっと少ないMPで唱える方法がないか？
・もっと短い時間で発動できないものか？
・どのような場面で使うのが効果的なのか？

基礎ができて応用する段階ではじめて「ハウツー」というものが役に立ちます。座学（What）→実践→座学（How）→実践という手順を踏むのです。ここまでできて、やっと実戦で使えるレベルになります。即戦力の若手に求められる最低限の技量は、この辺りだと思います。

そうしていると今度は、上級呪文に「メラミ」というものがあることを知るでしょう。学ばない技術者は「メラなら誰にも負けないからメラミなんかいらない」と考える傾向にあります。

よしんば頑張ってメラミを使えるようになっても、さらに上位の呪文「メラゾーマ」があります。メラミの何十倍も努力しなければ身につかないのではないでしょうか。少なくともレベルが上がれば勝手に呪文を憶えるということはありません。

ゲームでレベルが上がると勝手に呪文を憶えるのは、プレイヤーに驚きを与えるための仕掛けです。

現実世界でどのようにレベルアップするのかというと技術書を読むとか、技術者交流サイトを活用するのがよいと思います。ググってもよいのですが、高セキュリティのプロジェクトでは、検閲に引っかかることもあります。

qiita

teratail

技術者交流サイトの弱点は、重箱の隅をつつく赤ペン大先生や、技量でマウンティングしてくるトロルが跋扈している可能性が高いことです。彼らに遭遇すると、本題が進まず赤入れされるだけで終わったり、痛恨の一撃を喰らって著しくHPやMPを消費することがあります。とくに疲れているときには注意しましょう。

冒険の書が消えました

ロールプレイングゲームにおける冒険の書は、旅を再開するための情報が記されたものですが、技術者にとっての冒険の書は開発リソースそのものであると言えるでしょう。

一番致命的なのが、誤って冒険の書、もとい設計書やプログラムを消してしまうことです。

いまだに多くのプロジェクトではファイル名に日付や修正者をつけて管理している場合がありますね。この場合は間違ってファイルを消してしまっても直近のリソースが残っている可能性はあります。

たとえば、こんな感じでファイルが増えていきます。

設計書_20180318.xlsx
設計書_20180322_齋藤修正.xlsx
設計書_20180323_野比修正.xlsx
設計書_20180330（最終版）.xlsx
設計書_20180412（最終版）_修正１.xlsx

こうなってしまうと、つねにファイルがコンフリクトしている可能性が高くなります。修正者の名前がついたファイルがあるのは、コンフリクトを起こしているためです。これはどこかのタイミングで誰かが手動マージしなければなりません。こういう無駄な作業が蓄積するので工数不足になります。

ファイルの共有を行って同時編集を可能にすることもできます。しかし、ファイルを開いたまま保存を繰り返すとテンポラリファイルがたくさんできてしまい、ファイルが壊れることがあります。よくファイルを開いたまま離席する人がいますが、自覚なきファイルクラッシャーの行動であると教えてあげましょう。

本来ならバージョン管理システムなどを用いてシステマティックに管理すべきものです。SIerの開発を見てきていますが、バージョン管理が適切に行われていることはほぼないように思います。ライブラリ管理ですら人の目を使ってやっているという実状もあります。

バージョン管理については、ITmediaの記事が参考になるでしょう。

「成果物・文書管理にすぐ使えるオープンソース～効果的な成果物・文書管理手法～」

そのプロジェクト、クリアできますか？

ほかにも「名前を入れてください」はコーディング規約、繰り返す減員や増員は「Aは逃げ出した！」「Aは仲間を呼んだ！」という例え方もできると思います。

ロールプレイングゲームに例えられる事例はたくさんあると思います。今回は、パッと思いついた3つの事柄についてだけ書いてみました。

あなたの従事する冒険、もといプロジェクトは、ちゃんとクリアできるようにしっかり調整されていますか？