エンジニアにPM業をインクリメントした生き方で増えた領域についてふれてみる

はじめに

後3ヶ月程でクラスメソッドへのジョインから1年が経つくらいになりました。現職で施策に徹頭徹尾関わってみて、結果見えてくるものがエンジニア業務のみの頃よりボリューミーなことと、作る事自体は1フェイズにすぎなかったのだなと感じています。

ある意味プログラマのみに徹した状態からPM業も兼ねる生き方にチェンジして、増えた領域について書いてみることにしました。

スケジュールを見通す

ソフトウェアエンジニアは提示されたスケジュールの把握が勿論必要ですが、PM業になってくると以下の要素がマシマシになってきます。所謂リードエンジニア業で発生する領域とも重なっていると思います。

• ゼロからのスケジュール組み立て
• 過不足ない仕事の割り振り
• 幅をもたせた期間毎の予定工程
• 関係者との連絡での認識合わせ

スケジュールの組み立て

リリースまでの必要な工程を洗い出して、作業に必要な項目を見立つつ、実作業時間に割り振った場合に期待できる進捗量から日数を割り出します。ここらへんは経験ベースです。

ポイントは、作ることだけではなく関係者との連絡調整も入ってくることや、途中確約の約束が発生すると伴ってスケジュールの固定も生まれることです。

過不足ない仕事の割り振り

最近実感していることは、未知のタスクはボリューム把握がどうしてもズレるということです。見込み作業量が推測し難いタスク多めな時に発生しがちです。現状、過小すぎたり他にこなせる作業がある場合には、大体PJメンバーからの自己申告による対応で進めています。

幅をもたせた期間毎の予定工程

最初は週単位でつけていましたが、早く終わりすぎたり追加工程が増えたりと尽く虚空へと帰るため、月単位に変えました。月単位で実施したことを振り返る際に都合が良いのもポイントです。

関係者との連絡での認識合わせ

作業が発生する見込みのある社内関係者や、直接のやりとりが発生しているお客様との連絡が主になります。社内関係者の場合は儀礼的な挨拶文を差っ引く程度で、伝えたいことが伝わるようにする必要があるのはいずれも変わりません。大体ロジカルシンキングが役に立ってます。

[読書のススメ]日常会話や業務での意思疎通で論理的に伝える技術に踏み込んだ「ロジカル・シンキング」を読んでみた

現在、社内ではSlackで、お客様向けにはBacklogと、テキストメッセージ主体のために文面を推敲できるタイミングがあるのが有り難いと思ってます。

要件や仕様策定

前職まではこれらが単純に渡されるだけのものでした。当初は洗いだしてみると要件と仕様が融合しまくっているという有様でした。いずれも関係者からのレビューにて改善しつつ、抜け落ちている視点が出てくる度に頭を抱えることもよくあります。

• 揉まれつつ要件定義を形作る
• 必要なものをカバーする仕様
• もれのないテスト仕様

揉まれつつ要件定義を形作る

過去の業務では仕様レベルでのやりとりが多かったため、そもそも要件定義とはなんぞや状態だったところから始まりました。作る視点のみだと困難な段階だと実感しています。

[読書のススメ]要件定義について理解を深めるために「はじめよう！要件定義」を読んでみた

必要なものをカバーする仕様

どのあたりまでを決めるのか、と判断の問題は常に存在します。

• ○の出力はXXXXとする
• ○の出力にはXXXは含まれない

等、出力や状態になるということを決めつつ、利用するライブラリやロジックは状況に応じて変えるという流れになっています。

もれのないテスト仕様

仕様が成立することを確認するために、どのように確認するのかを網羅的に出していきます。

• ○の出力はXXXXとなっているか
• ○の出力にXXXがふくまれていない

内容によっては相当なボリュームになりますが、省くわけにはいきません。逆にテストする項目が余り見当たらないときも少々頭を抱えます。

常に頭によぎること

エンジニア業務主体の時も似たようなことを考えましたが、手堅く仕事を終わらせるという点で思考が変わった部分もあります。

• 敢えてロジック化しない
• 決めを作って思考から除外する
• アウトプットのネタにする

敢えてロジック化しない

ロジック化するコストがかさみそうなら運用でカバーしつつ、ウェイトが小さければ最小限に抑えるかバサっと削っています。

決めを作って思考から除外する

悩むのは決められないから、というのが最近の個人的な実感です。マネージャからの指摘も含めて、悩むことに時間を取られるのは勿体ないと感じるようになり、とりあえず妥協点を決めてしまうようになりました。

アウトプットのネタにする

案外、アウトプット前提にすると何らかの形を作り出す必要があり、それなりに捗る感じです。幸いなことにDevelopers.IOというメディアがあるため、アウトプット先は公開しても問題ないものであればブログ記事化、そうでないものは社内Confluenceに書き出しています。

まとめ

現在、サービスグループにて活動するようになって、セルフマネジメントを交えつつ、個人的にこれらのことを前提に置きつつ考えるようになりました。

エンジニアリング領域に対してAWSをプラスし、視野を広げて経験領域の拡大を検討している場合は、弊社へのジョインは一つの選択としてオススメです。