80'sのYOKOHAMA ASPECのCMが素晴らしい
エンジニアと権力
エンジニアに必要なのは権力である。権力とは職務上の裁量であり、職位を上げれば裁量の幅は増える。
あの開発手法をやりたい、この手法をやりたいと言っても聞いてもらえない。
OK。だったら、少し遠回りかもしれないが権力を手に入れよう。そのための活動に励もう。それが嫌なら自分でそのやりたい開発手法を取り入れている他社を探し、移ればいい。だってやりたいのだろう、であれば、そのどちらかを選ぶ他ないだろう。選ばないのだとすれば、その程度の思いでしかないということだ。
もう一つ、やり方はある。自分のタスクだけその手法を適用すればいい。もちろん、見かけ上は他のメンバと同じようにインタフェースを維持しなければならない。二重管理になるかもしれないがやりたいことのためならやれるだろう。それも嫌だというなら、ますます持ってその程度の思いで騒ぐな、と言いたい。
どのアプローチにするかにしても、共通しているのは覚悟と策を自分の頭で考え、結果に責任を持つということだ。
権力とは、組織上の制度に紐づくものだから、権力を手に入れるためには組織の構造を知らなければならないし、それは誰かが教えてくれるものではない。そうしたことも自分の実現したいことに対する思いと秤にかけて、決めれば良い。
どうなるか誰にもわからないものに、自分で責任を持つ意思決定するだけの話だ。
こんな風に書くと、萎えてしまったり、腹がたつかもしれないが、その気持ちの矛先は、自分であることに気づかなければならない。何もできていない自分を無闇にせめているだけだ。
それはとても無駄なことだ。凹んでいる時間があるなら少しだけ、調べられる範囲で調べれば良い。そこそこの組織であれば、職務や組織の決まりごとが共有されているはずだ。
決まりごとと実際の組織をみて、どういう構造になっているか、人事報を見て、どのくらいのサイクルで世代交代をしているか。そうしたことも知ることでどのようなアプローチを選ぶか補助情報となる。
エンジニアが成果の出やすいやり方を選ぶことが望ましい。それには権力が少なからず必要である。
さん付けと愛称の距離感
経験に基づく感覚でしかないのだが、腹を割ってストレートにものを言い合える相手の呼び方があると思う。
進捗を気にしていたプロジェクトがあり、進捗がまずいとある意味正しくプロマネを飛び越えて、そのやばさ加減を知ったとき、フレンドリーに顔を出すようにして裏をざっくりと掴んで、プロマネとこれどうするつもりかと聞いた。
プロマネは自分の感覚で（全部ものが丸く収まって＝次工程に必要なものは一揃えするまるでお花畑のような世界）目一杯工程のギリギリを示すから、現状からあり得ないだろう、五月雨で解決してもひと月前にはコア部分が定まらないと進められらないと指摘すると、ムキになって議論をし始める。
もともと愛称で呼んでいたから、過去にも意見がぶつかることはままあったのではあるが、愛称で呼び合うくらいに相手に思いをぶつけられる仲だったから、グサリと急所を指摘して、プロマネも取り繕うこともなく、素直に話を聞いてくれたのかもしれない。
これが苗字＋さんだったらどうかと思うと同じような結論にたどり着けたかはイメージできない。互いに仮面を被り、お行儀よく、言葉を選んでいたかもしれない。
要は、相手のパーソナルスペースにどこまで入れて、相手に多少不快感を与え（それはそうだ、本人は上手くやろうとしているのだから）ながらも、耳を貸してくれなければ意味がない。
そこには相手に対してのリスペクトというか、形式張りすぎない個人の尊重がベースにある。あの人が言うからではなく、個人の意見はまず受け止める。その上で、違う意見を持ったら違うと言う。言う必要があれば。
これは仕事ばかりではなく、家庭でも同じで、特に夫婦の間でも同じかそれ以上なのだと思う。
自分はワイフを名前で呼ぶ。これは結婚する前からそうだったし、結婚してからも変えていないし、変えるつもりはない。いつまでも、愛称で呼ぶ。
子どもさんたちのご両親は、子どもさんと同じようにパパママと呼び合う風景をよく見かける。いや、ほぼ、そう呼んでいる。改めて考えると、パパママという呼び方には個人が無いように思えてる。子どもさんたちの父親、母親という意味合いとしか受け取れない。
愛称で呼ぶことは、個人であることを理解し、尊重している。そうすることで相手から相談をしてもらえる資格を作っているような気がするし、相談を聞いてもらえる対等な立場のベースになっているような気がする。
くだんのプロマネもワイフもそうなのだが、自分の考えのベースにそれぞれが役割を担っているだけのことで、立場は対等であると信じているからもしれない。
それでも馴れ合いにならないのは、役割をになっているというのあり、それのバリューを発揮していないとそれなりにグサリと切り込むからかもしれない。
ただ、ワイフ様にはそれはしない。
内製化でやりたい気持ち
SIerだと受託になるので、契約を介して委託元とプロジェクト業務を分担する。得てして、RFPや見積もり依頼書がザルだとリスクてんこ盛りでコンテンジェンシを山のように盛らざるを得ない。顧客第一とかカスタマーサクセスと言いつつも、契約は最後の砦だから、掛け声と実態の溝は埋まらない。ここを上手に運用するプロジェクトマネージャは手練れであるから委託元も手羽さない。
一方、委託元である事業会社の立場で見れば、自分たちでできない技術領域やリソースを確保できないから業務委託をするのであり、事業会社のプロジェクトの成功（実現したいことを実現する）のために、それを一緒に実現してくれる業務委託先とやりたいと考える。
SIのプロジェクトをSIerの立場で意識していたのは、プロジェクト全体として成功するための意思決定かどうかだ。もちろん、契約以上のことをしてしまうと利益供与になってしまうし、大概そうしたことをすると小さなことが大きくトラぶる。良かれと思ってやったのに、というアレである。
そうならないように念頭にあることは忘れずに、上手にバーターをするとお互い納得感を得られてプロジェクトも回せる。その追加でやりたいと言っている課題をうちでやるなら、もともとうちでやる作業のここを同じ程度の工数だから、引き取ってくれないか、的なイメージだ。
SIerでも事業会社でも自社のみのリソースで賄えない規模だと業務委託にjoinしてもらう。やはりここでも契約をベースに業務を委託することになる。これはこれで良いというか当たり前なのだが、何せプロジェクト全体での成功をしたいと思っている自分と契約の範囲を我武者羅に履行しようとするから壁を作られる。いくらスコープを変えるときは再契約なり、追加発注するからと言っても壁はなくならない。
別な面で見れば、発注サイドの自分たちでできない業務の委託をするということは、委託契約が終わったら、それを引き継がなければならない。言い換えれば、業務委託を開始する時点で、指示をしなければならないし、終わった後は自分で面倒をみる覚悟をしなければならない。
フリーランスを何度か使ったこともあるが、たまたまなのか、体系的な開発手法を知らないことが散見された。SIerのエンジニアの方がいいのかというとそう簡単に割り切れるものでもない。SIerのエンジニアは分業だからフルスタックでできるエンジニアは少ない。やはり自分の担当領域をやることで一生懸命で、全体を俯瞰していない。それにSIerだと工数のボリュームが出ないと受けないこともままある。1人だけ優秀なエンジニアを出すわけにはビジネス的にはできないからだ。
こうなってくると、ものすごく業務委託を使うことにメリットを感じない。条件さえフィットすれば手軽に始められるが、ものすごく面倒でしかない。だから、ついつい内製化でやりたい気持ちになってしまう。しかし、なかなかチームのカルチャーに合うエンジニアと巡り会えない。
最近の仕事をした気になれるツール
5年くらい前はメールをいかに見ないようにして自分の仕事を進めるかを考えていた。仕事場に着いて、PCを開いてメールでも見はじめたらあっという間に30分や1時間は立ってしまう。メールの内容はプロジェクトの進捗上の障害であれば見過ごすこともできないから、あれこれと指示をするなり、手配をしたりする事になる。
それが今ではslackに置き換わった。メールのinboxからチャンネルになり、情報が分断されるようになった。だからか、チャンネルはopenであることが望まれ、KPIのようにopenと鍵の付いたチャンネルとDMの比率を比べる。
メールはinboxの中で探しにくいがslackも流れが早くどこにレスをつけて、どれに返さないといけないのかすぐに分からなくなる。
結局、メールのinboxのサブフォルダはチャンネルになったに過ぎない。
仕事上のコミュニケーションは、ブレストのようなものであればオンラインでも構わないが集まってテーマに付いてあれこれとやるが、実作業はそれの方向性を決めれば個々に振られるからコミュニケーションで取り交わしたい情報量は少なくてよくなる。だから、slackでのコミュニケーションは短い。
メールは元メールを引用した上でやり取りを冒頭なりインライン（このやり方はとても合わない）で往復させるので、気が向けば大元に戻って記憶を整理し直せる。しかし、小さな情報量となっているslackは自分の記憶なりスレッドなりで追いかけなければならない。その上、レスが付いても見つけにくいから結果的に放置をしてしまう。
メールもそうだが、slackも投げっぱした方が主導権を取るコミュニケーションである。メンションをつけてどうかを確認するポーズを取る。噛み合っていればまだマシだが、そうとは限らないから堪らない。
気づくと自分の仕事をする時間より、slackで溶けていく時間の方が多いのはメールと同じだ。メールも絶滅していないから、そっちも時間を溶かす一因である。
生産性をあげるのがコミュニケーションツールだった気がするのだが、返って生産性を悪くしているような気がしてならない。
23日のローストチキン
23日は天皇誕生日ではなくなったから、休みではなくなった。去年までなら、23日にクリスマスケーキと食事を用意して、家族の団欒をしていた。美味しいもの買い込み、テーブルクロスを広げ、CAVAなり、ノンアルのスパークリングなりを開けて、最後に小さめのブティックのクリスマスケーキを食べてお開きだ。
23日が休みで無くなるというのは昭和に戻るような感覚を持つ。24日や25日クリスマスケーキを買うのだ。平成に代わり23日が祝日となったため、ホリデーシーズンは長くなった。クリスマスケーキも23日から注文することができた。今年のカタログを眺めると、23日にクリスマスケーキを用意するブティックは減った。
子どもさん達も大きくなり、それぞれのスケジュールで生活をしている。恋人がいれば恋人と過ごすようになる。クリスマスケーキは24日か25日だから仕事帰りにと考えると早仕舞いしなければ、支度も大変だから食事にありつけるのは遅い時間になってしまう。
ワイフとどうしようかと話して、クリスマスケーキは止めることにした。食事も日にちをずらして機会を設ければいい。そういう話になった。
これが10月下旬だったか、11月上旬の頃の話だ。
今月に入り、ワイフが短期の入院をすることが急に決まり、それが23日だった。本来の手続きなら3ヶ月後とかになるらしい。話の展開が早く、あっという間に決まった。
子どもさん達が小さい頃は、peckのチキンを注文していた。過去形なのは、取り扱いがなくなってしまったからだ。フィリングにレバーが使われていてお気に入りだった。その扱いがなくなったので、別のお店に変えてみたが、どうも違う。有名ホテルのチキンで半ば妥協して数年が経っていた。
23日は日曜日で、デパートではクリスマスムードを押し出していたが去年ほどクリスマス感の客はいなかった。そんなとき、生の丸鷄が手頃な値段で並んでいた。確か、去年までは売り切れていたような記憶があった。
クリスマスの食事をするつもりはなかったけれど、中に詰め物をしてローストチキンを作ってみようと思い、手頃なサイズを買い物カゴにいれる。
ピラフを作り、鶏を処理してフィリングを詰める。230度で40分、200度で20分、そのまま余熱で10分。塩胡椒の鶏、3種のハーブをアクセントにしたピラフは鶏の油を吸って甘みを増す。
ワイフに声をかけて、ローストチキンをテーブルに出す。どうやら口にあったらしい。もう23日にローストチキンをどれにしようかと悩む必要がなくなった。
![ダッチオーブン極楽クッキング[雑誌] エイ出版社のアウトドアムック](https://images-fe.ssl-images-amazon.com/images/I/51D-HOM%2BhvL._SL160_.jpg "ダッチオーブン極楽クッキング[雑誌] エイ出版社のアウトドアムック")
プロジェクトで失敗しないチームの要素
システム開発のプロジェクトで割と結果を出せていたのはある意味不思議と言えば不思議なのかもしれない。
世の中では、プロジェクト自体かなりの割合で失敗しているとか（古いPMIのNetwork誌だったか）とかウォーターフォールの失敗の割合とかアジャイルのプロジェクトの失敗とかをときどき見かける。
ご想像のとおり金額で言えば大規模なプロジェクトではないし、小さい方かもしれない。ただ、プロジェクトの規模が小さければ、案件数は大規模に比べて数桁も多い。規模の小さいプロジェクトは元々のQCDのリソースのサイズは小さいので1つ間違えると致命的になるのは想像に難くないだろう。
どのプロジェクトでも、その中で特に立て直しのプロジェクトに巻き込まれたり、召喚された場合、何をやっていたかと言う言えば、色々と思いつくことやらなければならないことをあれこれとやっていたのであるが、思いつくことを書き出してみるとこんなことをやっていた（はず）。
- プロジェクト目的の刷り込み
- プロジェクトのカルチャー作り
- 自律したマインド作り
- 個々のエンジニアのスキルの理解
- エンジニア同士で言い合える関係
１は、プロジェクトの仕事のゴールである。これを曖昧にしておく理由はない。終わるまで続ける。
２はプロマネの考え方、例えば項番3以降を実現できるチームをプロマネが作りたいと思っているから、それを具現化できるチームの文化を作ることである。
3は、プロマネが指示するは、プロジェクトの目的の設定、向かう方向、進むスピードであって、エンジニアへの箸の上げ下げではない。であるから、それに少なくとも理解してもらえるためのマインドをチームとして持たなければならない。
4はプロジェクトであるからプロジェクト目的の達成に必要なチームとしてのスキルセットがあるはずで（これについては何度もこのブログで取り上げている）、個々に違うスキルとスキルレベルを持ったエンジニアを招集している。それが前提になければおかしい。その前提を理解し、エンジニアひとり一人違うバリューを持っていることを受け止められるチーム作りを必要とする。これがないとただ経験の長いエンジニアがろくに成果を出せないのに若手エンジニアにマウントしたり、若手エンジニアが忖度してしまいかねない。そんなのは求めていない。ここに違いがあることを受け止め、相互に尊敬がなければならない。
5はプロジェクトチームは4を前提として1を目指すのだから、それぞれのスキルやレベルを根底に、ロールの役割を果たさなければならない。そのミッションを履行するためには、つまらないと思ったことでも言える関係でなければならないし、他のメンバの視点は自分にないものだとして、ニュートラルに傾聴する心根を持ち合わせていなければならない。決めつけや思い込みをなくすための1つの方法でもある。
この他に当たり前のようにプロセスデザインやプロジェクトマネジメントなど色々とするのであるが、それもやるし、そうした成果に直接結びつくことと並行してチーム作りをしていると案外とプロジェクトは失敗しない。
