↓ここ数年にはなりますが、個人的な環境の変化としてフロントエンド系エンジニア、サーバー側の管理者の方など、技術寄りの方々と一緒にお仕事をする機会が増えております。一般的なウォータフォールの制作環境に於いて、”下流”に位置づけされやすいエンジニアのポジション。どことなく軽んじられやすく、上が決めた無理難題をパワーと根性で解決するいわゆる『IT土方』と自虐的な言い回しも聞こえる次第なのですが、プロジェクトマネジメントとして全体を俯瞰で見るうちに、いかにエンジニアの方が苦労されているのか、また、その問題解決の糸口が見えつつあるので、個人的備忘として。エンジニアが技術を振るえる環境作りディレクターないしクライアントからのメールによる作業指示。漠然とした内容が多く「これやっといて」的なニュアンスで投げといて「後で電話/席まで行って説明すればいいや」とお考えの方も多いかとは思いますが、そのメール内容を読み解く時間、作業モードのエンジニアの手を止めてる時間のコストを考慮された事はありますでしょうか。後者の場合、「詳しく説明するからこの時間空けといて」と事前にアポを取り、内容を整理した上でお話されるのならまだしも、エンジニアの席に行くまでのわずか数歩の間に考え、挙句の果てに「あれ何しに来たんだっけ?」と言われも「知らんがな」ってシーン。多く見る機会があります。言わずもがな、ウォータフォールと聞こえは良くても伝言ゲームの言い回し変えただけみたいなところは、正直あるところではあります。伝えるだけでも時間は消費しており、その間の作業時間はロスしていることを考慮し、いかにエンジニアへ端的にかつ整理した内容を伝えるのか。一緒に思案する事項なら何を考えて欲しいのかをオファーする姿勢は持っていたいところです。上記にも軽く挙げましたが、メール/口頭でのやりとりはリスクが大きいもの。できることなら避けるか必要最低限に留めたいところです。最近は、社内チャットやプロジェクト管理ツールの利用も当然のことになりつつあります。それら便利と思われるツールもエンジニアにとっては絶対的な便利さとは言えないようで。注意すべきは通知機能の使いドコロ。してもアテンション/アラートを伝えたく、些細なことでも@をつけてエンジニアに連絡するケースが多く、都度でエンジニアの意識がそちらに削がれるため「あー、またなんか来てるな。いいや」と本当に緊急度の高い通知などはスルーされてしまう可能性があります。チャット=即時会話ではなく、あくまで”ログを残しておけるツール”という意識での運用がエンジニアにとっては好ましいようです。@を入れての通知はプロジェクト管理ツールとの併用を念頭に適材適所に留めたいところ。技術者がプロジェクトマネジメントすることのメリット/デメリット該当の方の社内ないしプロジェクト内での立場や個人的な性格にもよるかとは思いますが、チームリーダー的な役割の方がプロジェクトマネジメントを担うケースがあります。個人的にはツールなどを活用しエンジニアにとって、手を動かしやすい環境が作れれば問題はないのですが、その時に注意したいのは”俯瞰の視点を持てるかどうか”にかかっています。端的に言うとエンジニア=深く、かつより研磨する視点プロジェクトマネジメント=浅く、他者に説明する視点の両面を持つ必要があり、プロジェクトが続く中で思考の切り替えだけでも、それなりの労力がかかります。ことプロジェクトマネジメントに於いては一箇所に留まっての深掘りは他所へのケアに手が回らず、まして自身でコードを書きながらとなると、”自分のコード”、”クライアント対応”、”社内リソース”の3つ+αへ気を配ることになり、効果的とは言い難いです。社内のテクニカルな品質管理の底上げという面では、その限りではないですし、スタッフ間の相対的な技術力の差(正確さ、スピード)を、細部の内容を理解した人が把握できるという面ではメリットは大変大きいです。テクニカルディレクターの必要性と役割については割愛しますが、プロジェクトマネジメントとの住み分けは明確にした上での配置が肝になると言えるでしょう。プロジェクトマネジメントだからできるエンジニアへのバックアップ前述の通り、まだまだエンジニアの作業環境の自由度は低く、制作スケジュール的にもエンジニアマターは五月雨開発は当たり前、「量産、流し込みだから」とか「コード書けばいいから」と、軽く思われるなど、理想的な状況には至ってはいないかもしれません。エンジニア側からも独自文化と一般との隔たりもまだあり、なかなか理解され難い状況も続いています。そんな納品の辻褄合わせの犠牲になりがちなエンジニアの方々にとって”理想的な環境とは何なのか”少し考えてみても良いのではないのでしょうか。技術者が大事にしている事は何なのか技術者に手を止めさせないために何が必要/不要か技術者以外のスタッフ間のコミュニケーション効果はどうあるべきかなど。コードや文法が理解できずともディレクター/プロジェクトマネジメントだから話せる本質の部分もありますし、エンジニアだからこそ拘っている技術的な美しさ、効率化への理解も重要です。そのためにお互い少々目を瞑るところはあるかもしれませんが、その試行錯誤ができるポジションにプロジェクトマネジメントはいるはずなので。コメントデータの処理方法の詳細はこちらをご覧ください。