howの任せかた
こんにちは！ITプランナーのかみゅーです
私の所属する会社では「エンジニアがhow、プランナーがwhy/what」という仕事の区分けをしています。
プランナーは広く浅く、エンジニアは深く狭く。
プランナーはシステムだけでなく、P/L、法律、人間関係など、幅広さを求められるため、あまりhowの深掘りができません。一方、エンジニアは勉強会やOSS貢献など、howに特化していく動きをしています。
具体的には？
こんな会話が繰り広げられることになります。
プランナー「今度こういうことをやりたくて、これを実現しなきゃいけなくて、mustなのはこの要件、できたらこんなwant要件もやってほしい！」
エンジニア「わかった任せろ」
前の記事で成果物を書きましたが、これは、正確に伝えきるため。
「サンプルサイトマップ」「サンプルワイヤーフレーム」「サンプルI/F仕様」「サンプル開発要件一覧」「サンプルWBS」のような資料を作って説明しますが、これはあくまで「サンプル」＝プランナーが考えたhow。
WhyとWhatが達成されている限り、作った成果物とまるで違うつくりで仕上がっても大丈夫です。
メリット
この区分けは、SEの「上流/下流」を進化させたようなものだと思っています。「Agile受託開発」という感じでしょうか。
- 技術的負債を抑えられる
- 技術的により良いシステムができる
- やらされ仕事では無いので開発が楽しい
- 開発に集中できる
- 仕様変更のようなことが少ない
- etc...
デメリット
何が出てくるかわからない
あ、そうしちゃった…？となることがたまにあります。
特に、UIやインタラクションの面で「ゔっ…これを説明するのか…」となることが多い印象。社内利用システムならまだ良いですが…、顧客に販売するような商品の場合、結構ハードルが高くなります。
また、営業上で事前告知をしなければならないケースだと、ここはある程度ハンドリングする必要があります。
テスト計画を作りづらい
どうなるのかわからないわけですから、テスト計画は作りづらいです。探索的テストを中心に組み立てることになりますが、なかなかこれは顧客を納得させづらいです。
株価予想系案件
例えば、こんな話です
プランナー「明日の株価を機械学習を使って予測するシステムを作ることになりました！！儲かるんです！！承認済みです！！howは任せます！！！」エンジニア「いや…無理だろ…」
いくら howは任せると言っても、ある程度プランナー側も知識を持っている必要がありそうです。うちでは、株価ではないですが、同じような 複雑なロジックで何かを当てるような案件でトラブルがありました。
うまく回すコツ
- UIなどのインターフェース部分はしっかりめに作っておく
- スケジュールに余裕を持つ
- 深堀りしなくても、書籍や勉強会に顔を出し、肌感は掴んでおく
というのがうまく回すコツかなと思っています。
では。