前回投稿した記事 向こう2年くらいまでの生存戦略 - 主夫ときどきプログラマ を書くに当たり、影響を受けないように読むのを控えていた記事があります。
こちらの記事です。
無事投稿できたので読んでみたら、自分の戦略には発注者視点というものが抜けいました。 これについては働きながら意識している部分がいくつかあるので、せっかくだから書いておこうと思います。 僕の場合は対等に1つのブロジェクトを進めていくという感じでやっているので、パートナーと呼んだほうがしっくりくるのでそうします。
パートナー視点での成果を提供する
不十分な仕様を開発者視点で補強する
いつも一緒に仕事をするマネージャーさんは開発をするにあたり仕様書をつくってくれます。 けれど、時間的な部分やクライアントの問題もあり抜けや考慮漏れが発生します。
それは仕方のないことだし、それでも開発できないこともないので必要な部分を一つ一つ埋めていく作業をこちらでしてあげると、たいがい喜んでくれます。 ドキュメントがGoogleDocsで作られている場合はこちらで加筆・修正してあげるとなおさら喜んでくれます。
相手が十分なスキルを持つマネージャーやエンジニアの場合、漏れがある原因はだいたいリソース(時間)不足なので、それを補ってあげることを重視します。
不足しがちなリソースを補強する
一方、相手が若かったり経験が少ない場合は、こちらで補いつつ、叱責し正しい方法などを示してあげます。 これは教育・指導すべき人たちのリソース(時間)不足が原因であることが多いので、そこを補ってあげます。
中小企業と一緒に仕事をしているとリソース不足がよく発生するので、そのへんを補ってあげられるような動きをするとだいたい喜んでくれていい関係を築けます。
その現場に不足してるスキルを示す
プログラミング経験の少ないメンバーが多いチームでは、オブジェクト指向であったりアプリケーションアーキテクチャの部分を担当したり、 データベースの扱いに長けてないチームではDB設計・構築・管理などを担当します。 モダン開発への理解が乏しいチームでは、スクラム、スプリント、CIなどの基盤を作るサポートをします。 それぞれのチーム・現場で不足していたり、最後の1ピースとなるようなスキルセットで参画すれば 長く良好な関係を築いていくことができます。
評価してくれる人のところへ流れていく
僕のことをよく思わない人ももちろんいるし、「いいね!」って言ってくれる人もいます。 「いいね!」って言ってる人の方へ流れていけばとりあえずいい気分で仕事はできます。
同じことをやっても、良い評価をする人も悪い評価をする人もいるので、良い評価をしてくれる場所へ行くのがWin-Winの関係になりやすいですよね。
評価してくれない現場や人たちと一緒に働いてもいいことないですから。
技術だけじゃないよ
エンジニアリングだけで仕事をするわけじゃありません。 お金を払ってくれる人が喜ぶことをしてあげることがビジネスの基本なので、エンジニアリング意外の部分で何が貢献できるかを考えると良いと思います。