私はこの業界に身を置いてもうすぐ10年です。(2024年現在)
経歴としては、ヒアリング（営業に近いこともしていた）・設計・開発・テスト・納品・運用保守までを一貫して行う、いわゆる一貫型の受託開発を行っていたある意味ではフルスタックエンジニアがほとんど。
節目を迎えるにあたって、今までの経験からうまくいっていた方法を棚卸の意味も込めてまとめてみます。
ちなみにフリーランスではなく会社員です。
プロジェクト管理
プロジェクト管理にはExcelと各種webサービスを使っていました。使うツールは十人十色といえど、本質は同じものだと思います。
議事録・ヒアリング・見積もり作成
正式な見積もりは社内の基幹システムに登録していましたが、そこに至るまではExcelベース。
議事録含め打ち合わせに使った資料も「案件別日付別」でフォルダを切って保存。時系列で追える、かつ資料と議事録が結びつくようにしてます。
見積もりに関しては基幹システムが融通利かないというのもあってExcelでテーブル作って作成してます。
基本的には機能毎に「設計・開発・テスト・受入（調整）」それぞれで工数(日)を算出。総工数に対して日単価を掛けたものを機能毎の金額として計算。これによってウォーターフォール的な案件にしろアジャイル寄りな案件にしろ、規模感と原価感を把握するイメージ。これを基に客先へ提出する正式な見積書を仕上げます。
要件定義・設計
こちらも基本的にはExcelやWordベース。というのも客先と共有する可能性があるからです。要件定義においては「目的」「背景」「提案内容」「達成目標」を意識して記入しています。この資料をみて客先の管理者層と現場層のどちらもが理解・納得できるように気を付けます。
設計に関しては一緒にプロジェクトを回すパートナーにもよりますが、ドキュメントとしての設計資料はExcel、開発時に確認する設計資料としてはdraw.ioを使っています。
Excelは保存するべきドキュメント作成機能としては足りるものの、開発者が直感的に理解できる資料の作成は難しいです。
顧客やマネージャ層との共有資料はExcel&Word、好きにできるところはdraw.ioといった感じ。
進捗管理
プロジェクトを進めていく上ではスケジュールや進捗管理が必要ですが、これは素直にwebサービスを使っています。あると便利だと感じる機能としては、
・工数ベースでの予実管理
予定工数との乖離を確認することで、順調に進むかの確認は勿論、見積もりの甘さにも気付くことができる。
・プロジェクトにぶら下がって子プロジェクトを表示できるガントチャート
一目で時間軸での現在地とプロジェクト全体の進み具合が確認できる。
・スケジュール機能
プロジェクトメンバー含め現在抱えている他の案件や今後の作業時間確保状況も確認することができる。
ですね。またGithubのissueも欠かせないものになっています。
テスト管理
こちらも基本的にExcelベース。なぜなら客先やマネージャ層と共有する必要があるからです。
どんなテストを行うかにもよりますが、「内容」「合否確認方法」「実施者」「実施日時」「合否判定」「備考」は必要かと。
納品後問題管理
本来ゼロが好ましいものの、納品後（デプロイ後）にも問題は発生してしまいます。その場合には「発生日時」「内容」「情報提供者」「重要度」「対応者」「対応方針」「対応状況」「完了フラグ」が報告のためにも管理してあると便利。
また意外と開発者は「仕様によるもの」と「バグによるもの」を曖昧に管理しがちです。開発者目線では「改善して動けば良い」と考えがちですが、マネージャや営業、顧客担当者は「仕様」なのか「バグ」なのかによって身の振り方が変わってくるので、このあたりも区分を作るなりして管理するのが良いかと。
プロジェクト振り返り
特にウォーターフォールに近い開発では流されがちですが、落ち着いたタイミングで振り返るのも大事です。この際、予実対比といった絶対的指数のみを話し合うのではなく、「チームの空気感について思ったこと」や「何となくよかったこと・悪かったこと」というような曖昧で感情的な事も共有することで、今後の人間関係の構築や働きやすさにも寄与することが多かったイメージです。
コーディング・開発ルール
以下は使っている言語やフレームワーク、会社の風土にもよるかと思いますが。
また、作って納めて終わりではなく、運用保守・引継ぎ可能性まで考慮してます。
技術力の差を把握・使用する技術や機能のボーダーライン設定
まず各メンバーが担当した過去の案件等からコードを共有し、どの程度技術レベルに差があるかを把握します。そしてあまりにも技術力が追い付いていないメンバーがいる場合は、その人に使用する技術レベルを寄せることも大事です。基本的に他人は信用することが大切だと考えていますが、だからと言ってプロジェクトを通して成長できるかは別のお話。それならできる人に技術のボーダーラインを下げてもらう方がチームとして健全に活動できる、と思っています。
テーブル名でマスタorトランザクションを把握できるようにする
まず、DBに保存される値は大きく２つのカテゴリに分けることが可能です。
■マスタ
「担当者」や「取引先」というような企業活動を構成する基礎となるデータ。
■トランザクション
「売上」や「仕入」といった企業活動によって日々登録されていくデータ。
そして、テーブル名の接頭語（プレフィックス）としてマスタの場合は「m_」、トランザクションの場合は「t_」を付与します。
これによってプログラムに精通していない人でも問い合わせ時にある程度目星をつけて調査が出来たり、ER図が無くてもリレーションの目星がつけやすかったりします。また、GUIツールでDBを覗いたときにテーブル名順で並んでいればマスタとトランザクションそれぞれ一目で把握できるというのもメリットです。
命名時に略さない
特にCOBOL上がりやベテランの方が陥りがちですが、「SHR＝仕入」「dtValue=date型の変数名」とかですね。この場合、「染まってないメンバー」や「業務知識が少ないメンバー」が困り果てたり、本来意図しない意味で伝わってしまったりします。
dt=date, datetime, data, …という風に、解釈の幅を増やしてしまうと保守性が落ちてしまいます。あと作った本人でも一体何の略なのかわからなくなっていることもしばしば。
「自分のコードも３か月もたてば他人が書いたコード」「いずれプロジェクト丸々別の担当に代わる」ということを意識すれば、安易に略すことはなくなるかと思います。
命名時にも可読性を意識する
まずあまりにも長すぎる変数名や処理名はNG。そのような名前を付けたくなった時は「分解する必要があるのでは」と疑ってみましょう。経験上、長すぎる処理名になっている時は複数の処理に分割するべき中身な時が多いです。
１つの変数や処理に責務を持たせすぎていないか、見直してみてください。
また、「処理名は動詞を先頭に持ってくる」「真偽値はisCreatedやcanCreateのようにする」というような「一般的プログラマが持っている共通認識」を意識すると、ぱっと見で目的や意味を理解しやすくなります。
無駄なコメントを記述しない
まるで理解がない上司に怒られないための布石として、
//データを読む
data.Read()....というような、「コードを読めばわかる」ことをコメントに残す方が一定数います。まず不要ですし、たまに呼び出した先のメソッドが仕様変更で少し処理が変わっているにもかかわらずコメントがそのまま旧仕様を説明していたり。リファクタリング先を増やしてしまうというのは保守の観点からもよろしくないので、なるべくコメントを書かなくても伝わるコードや命名を日頃から意識しましょう。
最新機能を使った書き方＝チームの最適解ではない
1つ目とも繋がることですが。
この記事を読むような方には考えられないかもしれませんが、「ラムダって何？」「（javaやC#の開発で）オブジェクト指向って何？」な人だっているのです。
上記は極端な例ですが、あまりにもキャッチアップすること前提なコードを使いまくるとチーム全体としての生産性は落ちてしまいます。
「知識量・成長ペースは人それぞれ」な前提で「順調なペースで開発を進めていく」事を意識することが大切なのかなと思っています。
まとめ
概念的な話が多かったですが、個人的にはうまく回っているプロジェクトは今回取り上げたことが担保されていた気がします。
人それぞれ、組織それぞれ最適解はあるでしょうが、もし良ければ使ってみてください。
