知見のないことにハマったとき、やっておきたい3つのアクション
きっかけ
知見のない分野のプロジェクトを任されて約6週間。 技術調査からユースケース定義、仕様決め、設計まで旗振りをしまして、ようやく形になってきました。
プロジェクトを進める経験は何度もありますが、今回は技術的にわからないことが多く、思うように進めないときもありました。
知見のないことにハマった時、どのように進めるのがいいか？
振り返りをして気づいた点を書いてみます。
まずは結論
以下の3つを優先してやってみましょう。
- 知見がある人に聞く
- チュートリアルを試す
- 他社のヘルプを見る
「知見がない」ときに困ることって何？
まずは課題の確認。 困ることは色々ありますが、わたしは以下のようなことで困りました。
- 何から手を付けていいかわからない
- 選択肢があるとき、何を基準に選んでいいかわからない
- どのように設計・実装していいかわからない
何から手を付けていいかわからない
この状態になると、
- キーワードがわからずググれない
- 何が重要かわからず、どう情報整理するのがいいかわからない
- 前提知識がないので斜め読みできず時間がかかる
といった状態に陥ってしまいます。
個人的には最後の「斜め読みできず時間がかかる」が地味に苦しかったです。 いつもより時間がかかることでリズムが狂い、理解が深まらないのも相まって変な焦りが増えましたね。。
選択肢があるとき、何を基準に選んでいいかわからない
この状態では、
- 判断軸がわからない
- 判断のしきい値をどう設定するのがいいかわからない
といったことが起きます。
技術選定や設計をする際には、複数の選択肢があります。
「なぜその方法を選択するか？」
質問された時、知見があることなら自然と判断できますが、 知見が無いとどう判断していいか悩み、説明が苦しいことがありました。
どのように設計・実装していいかわからない
これによって、
- 見積もりができない
- 具体的なアウトプットが出せない
- 手戻りリスクが高まる
といった問題が起きます。
何箇所設計して、何箇所ファイルをどの程度触るか、を踏まえて見積もりをするかと思いますが、それができない。
「あとどのぐらい期間があればいいか？」 POから聞かれたときの回答が苦しかった。。
対策はそれらの逆
こういった問題は、知見がないから起きています。 であれば、「知見があるときの状態に近づける」ことで、回避できます。
知見がある人に聞く
王道ですが、知見がある人に聞くのが早いです。
聞くことで、
- 全体像のイメージが持ちやすい
- 技術選定時など、世間のスタンダードを知れる
- 先人の判断基準を知れる
といったメリットがあります。
特に「先人の判断基準を知れる」は大きいです。 なぜなら判断基準を聞くことで、自分たちに必要な情報の範囲を絞ることができるからです。
チュートリアルを試す
こちらも王道ですが、オフィシャルが出しているチュートリアルをやるのが結果的に早かったです。 実装先は開発中のプロジェクトに追加できればベストですが、難しければ別リポジトリをつくって実装するのもありです。 余計な変数を減らして、試したい機能の動作確認に集中できるからです。
他社のヘルプを見る
他社サービスのヘルプは情報の宝庫です。
- ユーザーが操作できるレベルで操作手順が書かれている
- キャプチャを元に、利用している文言やUIも参考にできる
とりあえずそのまま パク 参考にすることで、オーソドックスな仕様を作ることができます。
仕様をイチから考えるのは大変なので、オーソドックスな仕様を叩きで用意して、それを自分のサービスに合うよう改善しましょう。
そのほうが早いし、改善案に脳リソースを集中投下できます。
改めて結論
- 知見がある人に聞く
- チュートリアルを試す
- 他社のヘルプを見る
基本的なアクションもありますが、 行き詰まって、納期が迫ると、ついテンパってやみくもにアクションしてしまうのが人間というものです（話広げすぎ
焦った時に立ち返る指針として、お役に立てばなによりです。
