現行の社内システムを最速でキャッチアップする方法

当サイトはPR広告を利用しています。

エンジニアの業務の中の大半を占める"調査"ですが、調査対象は大きく2つに分けられます。

一つ目が"外"の調査です。これはプロダクトの新機能の開発だったり技術選定の時に行う調査で、インターネットや書籍を通じて勤め先にはまだ存在しない情報を探しに行く調査になります。二つ目が"内"の調査です。こちらは勤め先で現行動作しているシステムや販売しているプロダクトがどのようなロジックで動作しているのかを調査するものです。

この記事では後者である"内"の調査方法について、これまで複数のプロダクトの開発に関わってきた私が考えるベストな方法を説明します。

この記事のポイント

これから内の調査のやり方について詳しくお話ししますが、割と長いですし一般的な話が多いです。そこでまず最初に他ではあまり見ない、この記事で特に大事だと思っているポイントをお伝えしておきます。

重要なポイントは以下です。

  • 調査のロードマップを可能なタイミングで可能な限り詳細に描きながら進める
  • 詰まったら何に詰まっているのかを明文化する
  • すぐ人に聞く

それぞれ詳しく話します。

ロードマップを描く

キャッチアップや調査にはゴールがあります。本来はゴールに向かって作業を進めるべきなのですが、ゴールを意識せず漠然と進めてしまう人が少なくありません。その結果何が起こるかというと、本来知っておきたかった情報を得られず覚えられず、しかも時間は長くかかるという事象です。

ゴールが明確になっていて、そこに至るまでの道筋(ロードマップ)が明らかになっていれば、重要な内容もわかって重点的に調べることが可能になります。その結果短時間で必要な情報を得ることができます。

また調べる中で当初の想定とは違う部分が出てくることもあるでしょう。その際にはロードマップを修正します。ポイントになるのはゴールに向かうために作業のうち、今どの作業をしているのかを明確にしながら進めることです。これができれば的外れで意味のない調査をしないですみます。

調査に時間がかかる大体の理由は不要なことに首を突っ込みすぎていることです。無駄をなくせば圧倒的に質の高い調査が可能です。

内の調査の場合は確認対象が限られているのでロードマップが描きやすいです。

詰まったら何に詰まっているのかを明文化する

調査を進めていると煮詰まって進まなくなる時がきます。色々調べてみても答えが見つからず時間がすぎていく事象です。これが起きた時には何が分からなくて詰まっているのかを文字に起こすことが重要です。

煮詰まっている時は特にそうなのですが、"とりあえず早く解決したい"という気持ちが強くあるとがむしゃらに色々調べてしまい結局答えは見つかりません。もし何か堂々廻りになっているタイミングがあったり、詰まってしまったと感じた時には、知りたいことを明文化しましょう。

頭の中にあるだけではダメで、紙に書いたりメモ帳ソフトに書き出す必要があります。そうすることで事象を自分から切り離して客観視できるようになり、答えに近づくための道筋も見えてきます。

すぐ人に聞く

人に聞くことをできるだけ避ける人が多いです。まずは自分で調べてから確認するという心がけは素晴らしいとは思います。なんでもかんでも確認していると、確認された側の人の時間を奪ってしまうからです。

しかしあなたがもし数年エンジニアとして活動しているのであれば話は別です。確認したい内容の難易度も上がっているはずですし、確認する回数も減っていると考えられるからです。

なのですぐ聞きましょう。むしろ人に聞くことに慣れて、質問力を鍛えて欲しい回答が得やすい人材になるのがおすすめです。

“内"の調査の場合、詳しく知っている方が身近に可能性が高いので特に重要です。

小まとめ

この三点がこの記事で最もお伝えしたかったことです。

ここから先はより詳細にゴールのことや私なりのキャッチアップの進め方として良かったものを書いているので、時間があればお読みください。

内の調査の分析

一見、内の調査と比較して、外の調査の方が難しそうに思えます。というのも内の調査は答えがあることが分かっているのに対し、外の調査は答えがあるか不明だからです。しかし状況によっては内の調査の方が段違いに難しくなるのであなどれません。

というのも内の調査には以下のような性質があるためです。

  • ドキュメントが限られている
    • 外の調査:ンターネットやAIを利用して多くの媒体を対象に調査が可能
    • 内の調査:前任者が作成したドキュメントとコードのみが利用できる媒体になる
  • 一箇所に複数の思想が含まれている可能性がある
    • 外の調査:実現したい内容がはっきりしている
    • 内の調査:一見ただの一つの関数であっても複数の事象を考慮した設計・コードになっていることがある。

まとめると、確認できるドキュメントが限られていて、かつ複雑に色々な要素を考慮する必要があるのが内の調査になります。

手段

社内システムを理解するために利用できる手段を列挙します。

  • 経験者
  • ドキュメント
  • コード
  • 動作確認

それぞれ簡単に説明します。

経験者とは、過去・もしく現在そのシステムに関わっている人のことを指します。経験者には積極的に頼るべきです。頼ることによって経験者の時間は多少奪われますが、早くキャッチアップが完了し一人前の仕事ができる人間が早く増えた方がチーム的には必ずプラスです。

ドキュメントはコード以外の資料全てが該当します。代表的なドキュメントはマニュアルや仕様書です。調査したい内容がシステムのアウトプットなのかロジックなのかによって確認すべき資料は変わります。

コードは、実際にシステムを作り上げているコードのことを指します。大半の会社ではgithub, gitlab, bitbucket, SVNなどで管理しているコードが該当します。

動作確認は、自分でシステムを構築したり試験用のシステムを利用することで調査対象のシステムの動きを確認することになります。

難易度ランキング

確認の難易度で並べると以下の通りです。

動作確認 > ドキュメント > コード > 経験者

動作確認は容易ではありません。何がどう出力されるのか事前にある程度知っていないとそもそも何を確認すれば良いのかが分からないからです。動作確認をするタイミングは別の手段を用いて大体の調査が完了した後の確認として利用するのが吉です。

ドキュメントは質にもよりますが、必要な情報のみを文章や図でまとめたものになるので、コードよりも確認は簡単です。ただしドキュメントの配置場所を確認する必要があったり、記載内容が難しい場合もありますので人に聞くよりも難易度は上がります。

コードは基本読むことには時間がかかります。ピンポイントの調査であれば簡単ですが、広範囲にわたる調査の場合は難易度が上がります。

経験者は何が知りたいのかを漠然と聞いても答えてくれる可能性が高く、また困ったことがあればその人に聞けば良いだけなのでもっとも簡単に調査ができます。

正確さランキング

正確さのランキングは以下です。

動作確認 = コード > ドキュメント = 経験者

動作確認の場合はインプットとアウトプットは確実に正確です。コードはロジックは確実に正確です。これら二つはシステム自体を確認しているので正確さ度合いはMAXです。

ドキュメントと経験者は知識が古い可能性や、そもそも誤りがある可能性があります。なので、システム自体の確認と比較すると正確さは落ちます。

具体的手順

ここでは上記で列挙した手段をどのように順番で利用していけば良いのかを具体的にお伝えします。

1.調査目的をはっきりさせる

まずは目的を明確にします。ただ漠然と"キャッチアップをする"という目的を持つだけではダメです。何のためにキャッチアップをするのか、キャッチアップをした後に任されるタスクは何なのかを具体的に挙げます。例えば以下のようなレベルです。

  • バックエンドのバグ修正ができるようになる
  • フロントエンドの機能追加実装ができるようになる
  • 他部門の人に仕様を説明できるようにする
  • 既存の問題点を明らかにする

目的を決める理由はキャッチアップで学ぶ範囲の明確化とモチベーションアップです。目的を明確化することで"どの箇所"を"どれだけ詳細"に学ぶ必要があるのか判断がつくようになります。また、目的があるとただ漠然と学ぶよりもモチベーションが高まります。

2.経験者の確認

キャッチアップ対象の経験者を見つけます。キャッチアップをするように指示をくれた方に誰に話を聞くのが適切か確認するのが良いでしょう。

3.ドキュメントの種類確認

どんな種類のドキュメントが存在するのか確認します。前のフェーズで行った経験者に聞くのも良いでしょう。わざわざフォルダから資料を新参者が探すのは効率が悪すぎるからです。どんどん頼りましょう。頼ることには慣れた方が良いです。自分がサボるために行う"頼り"は良くありませんが、仕事を効率よくこなし質が高いアウトプットを出すための頼りなら圧倒的に良いことです。

ドキュメントの種類が分かったらどのドキュメントがキャッチアップに利用できるか検討します。検討のポイントは目的を達成するために必要がドキュメントか否かです。

4.経験者に概要ヒアリング

経験者に概要をヒアリングします。どんな目的でキャッチアップを行なっているのかを伝えた後、概要を説明してもらいます。この段階では概要を聞くことで全体像をイメージできるようにします。最初に全体像が分かってからキャッチアップをするのと、ゼロから少しずつ学んでいくのとでは理解の速度も理解の結果も大きく異なります。細かいことは置いておき最初に全体像を掴むことを意識してください。

もし経験者の方の時間が業務都合上取れないようであれば、参考になるドキュメントを教えてもらいましょう。

5.ドキュメントの確認

詳細を理解するためにドキュメントを詳細に確認します。分からないことがあったらその内容が今後の調査に響く内容かを確認します。響く、もしくは響くかもしれないという場合はすぐに経験者の方に確認しましょう。少し調べてからというやり方もありますが、私の経験上すぐに聞いてしまった方が良いです。奪う時間よりも効率化される時間の方が圧倒的に大きいからです。

確実に次に響かない内容であればメモしておきある程度まとまった段階で経験者に確認しましょう。

まとめ

最後に重要なポイントをおさらいしておきます。

  • 調査のロードマップを可能なタイミングで可能な限り詳細に描きながら進める
  • 詰まったら何に詰まっているのかを明文化する
  • すぐ人に聞く

詳細な手順には完全に従う必要はないのですが、この3点だけは守っていただきたいです。キャッチアップスピードと質が大幅に改善されます。ぜひお試しください。

直近でおすすめの本

直近十数冊読んだ中で一番おすすめの本です。

ビジネスデザイナーという肩書きを持つイノベーションシンキングの世界的第一人者である濱口秀司さんの書かれた本です。肩書きだけだとどのようなことをしている人か分かりにくいかもしれませんが、USBメモリやマイナスイオンドライヤーなど誰もが知る有名商品の産みの親の方です。

アメリカのコンサルタントの中でも最高額のコンサルティングフィーを受け取っている方で、私の友人から聞いた話だとこの人のコンサルティングを受けるためには1時間でも7桁の額は準備する必要があるとのことでした。

濱口秀司さんは自分の中でイノベーションを起こすための型を持っており、その型について本の中でかなり詳しく教えてくれています。革新的なアイデアを出す方法をここで詳細にはお伝えしませんが、とてもざっくりとまとめると以下の手順になります。

バイアスの特定→バイアスの破壊

革新とは現状の破壊です。現在世の中にあるバイアスを認知するところからアイデアの創出は始まります。この本ではバイアスを認知する方法、そして破壊する方法を詳しく述べてくれています。個人開発をしようとしているけど何を作れば良いか思い浮かばない方やや会社を立ち上げようとしている方に特におすすめの本です。

過去におすすめした本は以下の記事にまとめています。

コラム調査

Posted by ラプラス