SIerのエンジニアは自分の組織ではやれないと言っている限り価値は理解できない

顧客やユーザと対話することが価値とか、ドキュメントを作るより動くソフトウェアを作ることに価値があるとか、契約を盾にして交渉するより顧客と一緒になって働くくことに価値があるとか、作った計画どおりに作るより必要なものを必要なときに作る方に価値があるとか言うけれど、どれだけのエンジニアがそうした思想、考え方を理解できるのだろう。

上述はアジャイルソフトウェア開発宣言をくだけた語調で書き直したのだが、エンジニアはこれを読んだだけで理解して実践できるのだろうか。

SIerのエンジニアにシステム開発における価値に対する理解を変えようと言ったところで変わることは期待できない。変われるエンジニアはごく少数だろうし、そんなエンジニアは言われる前から勝手にやっている。アーリーアダプタに相当するエンジニアは、もう、ずっと先に、３週くらい前を走っている。

では、なぜSIerのエンジニアは価値観を変えられないのだろう。

Sierのエンジニアは組織の中で駒のように動かされる。ほとんどのエンジニアは維持管理プロジェクトに押し込められ、駒なのに動かされることもなく、同じ場所でじっとしているだけである。

エンジニアのマネージャも数年おきに配置転換されればまだマシな方で、エンジニアと同じように固定化されていることも多い。最前線のマネージャとして顧客のインタフェースをさせられているからだ。

価値観を変えられないのは、変える必要のない環境で身体の芯までSIerのビジネスの価値観が染み付いているためだ。だから物事を捉える、決めることの所作がSierの意思決定の基準で行われる。

若手のエンジニアであっても、日々、SIerの価値観で意思決定を繰り返し見聞きし、そうすることを求められればどういった行動を取るかは手に取るようにわかるはずだ。

こうしたSierがアジャイル系のカンファレンスで見かけるようになった。名刺交換をしてロゴを見ればそういった傾向であることがわかる。

SIerもそういったカンファレンスに参加するようになったのは良いことではないかと思うのだが、ちょっと違いがある。自分たちの仕事を、ビジネスを変えるために来ているのではなく、単なる情報収集に来ているのである。

講演を聞きたら自分のプロジェクトやチームで試したくなるものだ。ワークショップに参画すれば、自分の周りでやってみたくなるものだ。実際、何かしら良さそうだ、と思ったことはやってみるだろう。

SIerの参加者の多くは、良かったが自分の組織ではやれない、という。それはそうだろう。正しい。なぜなら、自分の組織ではやれないとい思う、判断した基準＝価値が違うからだ。その価値を入れ替えないと試すことさえできないのだ。

ただ、SIerでも一部の身の回りを良くしたいと思っているエンジニアは組織の価値が及ばない自分の範疇で始めてしまうのだ。そして良さが、価値の重さがわかるとSIerを去っていく。

アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?

まだプロジェクトマネジメント＝ウォーターフォールやアジャイル開発」とか間違ったこと言っているの

ネットで出回っているスライドに、

　プロジェクトマネジメント＝ウォーターフォール

　プロジェクトマネジメント＝アジャイル開発

としたものや、PERT図やはたまたMindMapが手法だ、的な説明をしているサイトがあるがそれは間違いだ。

標題の「現場にあった」が現場で行われる「プロジェクト」に合った且つシステム開発手法を選ぶのであれば合意するが、プロジェクトマネジメントしてアジャイル開発を持ち出してくるならそれは違う。

プロジェクトマネジメント とは、以下の定義がある。

プロジェクトマネジメント とは、プロジェクトの要求事項を満足させるために、知識、スキル、ツール、および技法をプロジェクト活動へ適用することである。

引用　PMBOK

 一方、ウォーターフォールは次の定義がある。

ウォーターフォール・モデルは、ソフトウェア工学では非常に古くからある、もっともポピュラーな開発モデル。

ウォーターフォール・モデル - Wikipedia

開発モデルである。プロジェクトマネジメント ではない。アジャイル開発の定義も確認しよう。

アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。

アジャイルソフトウェア開発 - Wikipedia

ウォーターフォールと同じである。

なぜ、違うと指摘しているかと言うと、使う目的が違うからだ。エンジニアであれば理解しているとおり、システム開発手法はシステム開発のプロジェクトでシステムを開発するために適用する開発手法である。

システム開発はエンジニアが行うのだから、これはエンジニアがプロジェクトの目的を達成するためにある。

一方、プロジェクトマネジメントを必要としているのはプロジェクトのオーナである。プロジェクトの成功、失敗が経営にインパクトを与えるような規模であればプロジェクトオーナはプロジェクトに関心を持つ。

プロジェクトオーナはプロジェクトマネージャにプロジェクトの状態、健全性をレポートするように要求する。その報告手段、レポーティングのためのプロトコルがプロジェクトマネジメントである。

プロジェクトオーナーとプロジェクトの代表であるプロジェクトマネージャがプロジェクトの状態を共通の考え方、指標で理解し、プロジェクトマネージャからのレポートを読み、事業に関わるプロジェクトを継続するか中止するか意思決定するための材料でしかない。

プロジェクトマネジメントの解説で進捗管理やWBSなどのツールだけを紹介しているようなサイトはとんでもサイトでしかない。それは前述のプロジェクトマネジメントの定義から当然である。

プロジェクトマネジメントは、プロジェクトオーナへのレポートツールであるため、経営サイドの要求するサイクルでレポーティングできなければならない。

システム開発はプロジェクトの特性から適合するシステム開発手法を選ばなければならない。

PERT図やMIndMapなどはシステム開発手法を助ける１つのツールでしかない。

人と組織の「アイデア実行力」を高める――OST(オープン・スペース・テクノロジー)実践ガイド

経験を評価できないエンジニアは失敗を繰り返す

エンジニアがそれぞれ立てた目標管理のフォローアップの仕方はいくつかある。１つは期初、期末の中間や四半期に行うもの。もう１つが1on1のように小まめに短時間で行うもの。最後が全くやらないもの。耳にしたとことだと、最後のやらない、やったことにするようなケースがあるのを知って驚いている。エンジニアに貢献してもらおうと言う気がないのだ、最後のは。

あるエンジニアがいて、目標管理の１つのテーマに昨年成果として実現できなかったことを改善することを取り上げた。KPTのProblemをTryで挑戦するようなイメージだ。

フォローアップの面談で進捗を尋ねるとどうも様子がおかしい。何がおかしいかと言うと、改善のために作ったツールは一度作ったまま放置し、改善するはずだったことが何一つ試されていない。状況を尋ねれば、一緒にワークをする他の組織に対する文句ばかりだ。自分はここまでやった、相手のところまで足を運んで、機会を作ったのに協力してもらえない…。

エンジニアが話す内容を聴きながら、思ったことがある。

優秀なエンジニアであっても、自分の考え方を変えることは難しいのだ。そうしたことを思いながら聞いていた。

さらにエンジニアはこれで上手くいかなくて評価がされないのは辛いと言う。

このエンジニアは、自分で目標を立てたときに何が目標の本当の真因だかを突き詰めていなかったのではないか。そんな言葉が過ぎる。

目標を設定するときに定量的に設定できない場合は、具体的に何をどの状態にする、と言うようなリアリティを持った目標にしないと目標に流されてゴールを見失ってしまう。

エンジニアに伝えたことは次のことだ。

• 話を聞いていると改善するとして作ったツールが実際は使っていないのではないか
• ツールは手段だが、ツールを媒介にして変えたかったことができていないのではないか
• 変えたかったことはなんだったのか
• もし、ツールが実は不要だったとわかったら、そのツールは捨てても構わない
• 変えたかったことをツールでできないことがわかったら、それを評価することが必要だ
• その評価を共有することで失敗事例がノウハウになる
• そこまでやって、目標なりアプローチをピボットすればいい

同じ思いをしたいならそのまま続ければいいが、そうじゃないから目標を立てたのだろう、と。

でも、多分、自分の考え方は変えられないかもしれない。それでも、挑戦をして上手くいかない経験を共有してくれればそれはそれで１つの成果だと思う。

データ分析の力　因果関係に迫る思考法 (光文社新書)

エンジニア自身が説明できなければ成果と呼べない

同じ担当チームのエンジニアが終わったから見て欲しいと言うのでレビューをすると一見良さそうな成果物があるきっかけを境に「なんじゃこりゃ」となってしまう。

そのエンジニアには、過去の作業のリポジトリと言うかまとめたものがあって自分で作業した結果が客観的に外れていないかを確認することができる。もちろん、ググって情報を集めて自分の判断を下すこともできる。

仕事にアサインする際にも、局所的な作業手順は後回しに全体の作業の流れ、作業のポイント（外してはいけない考え方）を繰り返し説明し、仔細なプロシージャを実物をハンズオンしながらスキルトランスファーしている。

ところが実際に起きているのは、そういった勘所の意思決定で外してはいけない考え方をわざわざ踏むのである。

これを見抜くのはとても簡単で、意思決定したところの根拠を説明してもらうことで判別ができる。

インプットがこれとこれで、評価基準がこれだから、結果はこうなった、と説明してくれれば結果が間違っていたとしても、インプットの不足なり、評価基準の捉え方なりを修正すれば良いので軽傷で済む。

ところが、説明できないとこれは次元が違う。説明できないケースでは、自分がそう思ったから、と言う意思決定の再現性がない判断方法を返してくる。これでは判断する基準に合致しておらず説明になってもいないので、どうしようもない。

エンジニアが担当した成果物は、エンジニア自身が説明できなければ成果と呼べない。

こうしたことはシステム開発の仕様の設計やコードのデザインでも同じである。何をインプットにして、制約を受ける様々な条件を並べた上で、処理を並べて、アウトプットする。ロジックを構築する際のロジックの作り方が自分なりに構築出来ていないのかもしれない。

エンジニアの仕事も様々で、全部を経験しているわけではないのだから、先行して作業しているエンジニアやリーダやマネージャに聞けばいい。忙しそうだからとか時間をとって悪いからと変な気を使って成果になっていない成果物を作られるより、こう作るがいいかとか、最初の１つ、２つを見て欲しいとかいってもらった方が何倍もいい。

何がいいかと言えば分かりきっていることは、手戻りのインパクトが小さくて済む。もう１つは、どう作るかが予めわかるので、やばさ加減とかどこでポーリングすればいいとか、レビューするときの不安材料が少なくて済むことだ。

体系的に学ぶ 安全なWebアプリケーションの作り方［リフロー版］　脆弱性が生まれる原理と対策の実践

AWSエンジニアの恩返し

二人のシニアエンジニアで切り盛りしている維持管理プロジェクトがあった。リーダ役のエンジニアが久しぶりに本社に戻り、事務処理をしていると協力会社のIDを下げた若手の女性エンジニアが上司にこっ酷く叱られて、そのあと暫く肩を震わせているのが目に入った。

若手の、それも女性のエンジニアを見かけたのは数年振りだったので、珍しく声を掛けて事情を聴き、それなら今月手が足りなくて困っていたからうちのプロジェクトに参加したらいいと、優しく慰めた。

名前と所属を尋ねると以前一緒に仕事をしたことがある人が上司だということがわかったので、上司役のマネージャに挨拶がてら暫く若手エンジニアに手伝ってもらいたいと伝えたところ、渋っていたが押し切った。

激しく雪が降り積もる月曜の朝、若手の女性エンジニアが維持管理プロジェクトの常駐先にやってきた。

もう一人いるエンジニアに事情を共有しようと若手エンジニアに最近あったことを話してもらうと、上司のマネージャに叱られ、今は仕事も外されたというので快く維持管理プロジェクトに迎えた。

維持管理プロジェクトは珍しくインベント的な対応が必要でタスクがなかなか減らない一方、若手エンジニアは戻っても仕事があるわけでもなかったので毎日その常駐先にやってきた。

若手エンジニアは二人のシニアエンジニアの作業を甲斐甲斐しく手伝い、二人を大そう喜ばせた。

数日後、若手エンジニアは今更自社に戻るよりここの常駐先で働かせて欲しいという。リーダ役のエンジニアはずっと顧客からリソースを増やして対応を早くして欲しいと言われていたので予算をいつでも執行できる状態だったので喜んで承知し、顧客に諸手続きと見積もりを出した。

その後もシニアエンジニアを助けていた若手エンジニアがある日、「ちょっと、ツールを効率化したいので顧客に承認をもらってきてほしい」といい、承認をもらってくると「ツールを作っている間は会議室を覗かないで欲しい」と言い渡した。３労働日後に出来上がったツールはこれまで手作業でテストしていたテスト実施を自動化したものだった。テストの進捗が早く、正確になり、顧客の評判が良かった。

「また効率化を図りたいので顧客にこのツールの使用許可をもらってきて欲しい」と頼まれ許可をもらってくるとリリースまでを自動デプロイするツールを作り、顧客が承認メールで承認を押下すると環境にデプロイする仕掛けになっていた。

維持管理プロジェクトはタスクが徐々にDoneして、プロジェクト単体での収益も残業が減ったため好転化し始めた。

しかし、若手エンジニアが3つ目の効率化のために会議室に篭ると、すっかり冷めていた技術への欲求が焼け棒杭に火が付いたリーダ役のシニアエンジニアは、どうしてこんなにも若手なのに効率化ができるのだろうという好奇心が押さえられず、端末にパケットキャプチャツールを仕込み、何をしているか覗いてしまう。

若手エンジニアの姿があるはずのそこには、AWSのエンジニアがいた。AWSエンジニアは自分でAWSサーバに環境を構築し、自分のクレカで身銭を切り、効率化を図るツールを作っていた。

驚いてシニアエンジニアが会議室に入ると、自分は自社には内緒でJAWSでいくつかの講演したことがあるエンジニアで、ちょうど助けてもらったときにたまたまやらかしてひどく叱責されたところを助けてもらったのだという。暫くここで勉強がてら、お世話になろうと思っていたが、正体を知られてしまったのでここを去らねばならないというと、環境をパージするalexaスキルを発動して、常駐先を後にしてしまった。

このお話は次のエントリを参考に作ったものです。

oscillograph.hateblo.jp

Echo Spot (エコースポット) - スマートスピーカー with Alexa、ブラック

1週間デプロイと週次報告の親和性

エンジニアになってしばらくした頃、某プロジェクトで年配のエンジニアの仕事ぶりを見ていて「こりゃやばいな」と思ったことがある。トラブルが起きると１週間なんてあっという間に過ぎるのだが、もちろん、トラブルの当事者の年配のエンジニアのその期間に計画していた進捗なんてゼロだ。

当たり前のことなのだが、こうしたトラブったときに予定していた作業の遅延を気にしていないエンジニアが多い。

初めてプロマネになったとき、顧客とのミーティングは１週間に一度に設定した。要は週次で進捗ミーティングを会議体として設定したわけだ。

この会議体では、SIerと顧客のそれぞれの進捗の他、課題管理が主な議題だったので１時間程度（だったはず）で、あとは別の会議体を設け、ほぼそちらに使っていた。別の会議体とは、いわゆる局面ごとのテーマを検討する場で、ほにゃらら検討会的な名前をつけていた。

上流の設計工程では、要件から仕様決めやデータ項目設計の項目や導出条件などをセッション形式で片付けていく。この片付けていくという言葉そのものだったのは、WBSに成果物のドキュメントと章立てを決めておき、セッションのコマを割り当て、ほにゃらら検討会で合意していくとWBSが完了するような仕組みを取っていたためだ。

これのどこが１週間デプロイかというと、翌週の会議体に合わせて検討するための資料を用意しなければならない。そのサイクルが１週間なのである。さらに言えば、工程の納期（＝完了時期）を設けていたので、局面内で合意が得られるようにカレンダを睨みながら、どのテーマが延べで時間が必要かの当たりをつけて組み替えなければならない。

そんな工夫をして毎週のセッションに資料をデプロイし、宿題が必要であれば種担当を決め、調査が必要であれば担当をアサイメントする。宿題も調査のどちらもSIerも顧客になることもある。

下工程になると局面と後に作成単位ごと、つまりWBSごとの進捗を確認することになるので単工程の進捗でしかないが、１週間ごとに成果を確認する。

ちょっと、今考えると、仕様決めまで進めたら、１週間単位で動くシステムを部分的にリリースすることができたのだろうあ。

機能のパラメータ設定、ワークフローの設定、アドオンの開発、ハウスキーピングなどの運用ツール、外部インタフェースの開発、プロビジョニングのカスタマイズなどがあったがなんとなくできそうな気がするし、当時それに近いところはあったような気がする。多分、アドオン開発や外部インタフェース周りだろう。

１週間デプロイと週次は一見全く無関係と思ったり、並べて関係があるなんて発想をしないと思うが、作業のリズムで考えるとエンジニアに影響を与える同質の部分が多いのである。

まあ、仕様に落とし込むところで１週間デプロイできるように準備をするのも、まるで週次ミーティングでセッション資料をまとめ、仕様決めするのと同じなのだ。そこのサイクルができれ上がれば１週間デプロイもレディなのだ。

あとはやってみればいい。やってない、できないは食わず嫌いなだけだ。

変革の軌跡 【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】

エンジニアにルールを作る側になることを勧める理由

これもまた、facebookでシェアされていたのでまとめを見たのだが「そうそう」と頷いてしまった。

togetter.com

頷いたのは2つの理由がある。1つは、このゲームというかワークショップでの先生の狙いについてである。

これまで何度かエントリで直接的に、間接的にエンジニアもマネジメントを経験することを勧めると書いていた。なぜなら、エンジニアでは持てる裁量が限られるが、マネジメントになると担当する事業の範囲の中で多くの裁量を持てるようになるからだ。

裁量を持つということは、担当事業の範疇で、やったこと、やらなかったことの全ての責任を負うが、担当事業の範囲であれば、組織の規程の中ではコンプライアンスのキャップはあるが何をやっても良いのだ。

言い換えれば、組織の中において、ルールを作る側になれるということである。

部下のチームやメンバにあれこれと業務上の指示が出来る。これは好き勝手にエンジニアをこき使うという意味ではない。自分で優先度の高いと判断した事業にリソースを投下するとか、事業の優先度を意思決定するとか、そういったことで、である。

もちろん、ルールを作る側になるのでチームの文化を作ることになる。稀にマネージャが変わると組織の文化が180度変わることがある。これはマネージャが変わる前と変わった後のマネージャと価値観が違ったために起きる事象である。価値観が変わったので、意思決定が変わり、意思決定が変わると組織の中での文化に浸透する。

マネジメントが変われば、統制型のチーム運営からサーバントリーダーシップに変わることだってある。そうした組織活動における全てを変えられる経験を積むことは、その後にまたエンジニアに戻ってリーダーシップを発揮するにしても、その経験は役に立つ。

もちろん、マネジメントになっても上長の言いなりになっていたり、従来の路線を変えずに引きずっていては何も得られないが。

2つ目は、ルール①とルール②の説明である。

ルール①

ルール説明①
・紙に『1000円』と書いて10cm×5cmに切り取った物を1000円と見なす。
・紙に『500円』と書いて直径3cmの円形に切り抜いたものを500円と見なす。
・規定より5mm以上小さかったり大きかったりするお金は無効。
・1時間後に最も多くのお金を保持していたチームの勝利。

— 昆布山葵 (@43ismamorigami) July 13, 2018

 ルール②

ルール説明②
・それぞれのチームには紙を無制限で支給する。
・ハサミ、鉛筆、定規、コンパスなどの道具はランダムで1チーム2つづつ支給する。
・各チーム1回づつ先生から『情報』を聞くことができる。
・製造したお金は自由に使用しても構わない。
・ルールに無いことは何をやってもOK。

— 昆布山葵 (@43ismamorigami) July 13, 2018

 説明の順番にも意図を感じられる。これはゲームだと言った後、ゲームに勝つ条件を提示（ルール①）する。その後にリソースとしれっと制限事項を特記のように付け加える（ルール②）。

自分もワークショップを持っている。意識したことがないが、同じような説明の順番になっている。

エンジニアの特性上、アウトプットすることにフォーカスしてしまう。毎日、進捗を確認され、毎日80％だと言っているのだろうが、それはさておき、ゲームの勝ち方を理解し、勝つためにリソースを集中投下することを考える。

エンジニア自身が、勝つ条件だけを考え、効率化と生産性を考える。こうしたアプローチを否定することはしないが、高効率性を求めるとリソースがキャップになって生産性の停滞が起きる。

ここで必要なのは、システム開発でいうシステム開発手法に何を適用するかという判断である。エンジニアに限らないが人は、過去に経験した手法でしか発想ができない。だから、物作りを経験した範疇で組み上げてしまう。定規を使い、線を引き、ハサミで切り取る。その手順に必要なリソースだけにフォーカスしてやりくりしようとする。

このゲームに限らない（自分のワークショップも同じだ）が、ポイントは最後のおまけでつけた特記である。

・製造したお金は自由に使用しても構わない。
・ルールに無いことは何をやってもOK。

このような気にもならないことをわざわざいうかに引っ掛かりを気付けるか、気づけないかで世界が変わってしまうのだ。

商売の基本はモノを内製か調達し、高く売ることである。もしくは、安く仕入れ、高い市場価値を維持することである。

市場を作り、市場のルールを整備し、支配することである。市場の中で、決められたルールの中でやっていては、市場のオーナにピンハネされるだけの存在でしかない。いわゆるプラットフォーム戦略と言われるものだ。

こういったことがマネジメントで（意志を持っていれば）経験できる。経験すると意思決定の手段を選ぶ選択肢がものすごく増えるのだ。

長々と書いたが、とりあえず、ゲームを作る側になると楽しいということが伝われば。

ゲーム界のトップに立った天才プログラマー　岩田聡の原点: 高校同期生26人の証言