０．まえおき
プロジェクトを推進していく中で、技術的な問題以上に、技術の周りにある問題に今年も数多くぶつかってきました。
過去結構いろいろなプロジェクトでSEPGとして割とかっちり目にやってきた自分ですが、ここ最近やってることっていわゆるプロジェクト自体に当たらない部分も多くなってきたな、ということで振り返りを兼ねた記事です。
開発というよりは、プロジェクトを推進していくうえで意識したいことをメインに書かせていただければと思います。
１．お客さんから指摘をもらいまくった話
いわゆる
終わり良ければヨシ！
の状態。（何を見てヨシって言ったんですか？）
背景・発生したこと
ウォーターフォールでゴリゴリにアプリケーションを開発するものではなく、移行・導入支援のプロジェクト。
結果の正解値が開発サイドで把握しきれない状態（予想外の指摘が飛んできて、指摘から再度仕様を調整した）
データ変換についてのコードとドキュメントのバージョン管理が甘くてデグレードが多発。
プロジェクト自体は前に進んでいるのだけど、ドキュメントがおろそかだったり、仕様・コードが属人化して「これってどこ見て正しいって判断したらいいんや？」の状態に。（でもたぶん書かれてるコードから出力されたものが正しいからヨシ！（よくねぇ））
やったこと
プロジェクト中は結果として検証を繰り返すことで、最終OKを取るというパワープレイになり、後から履歴を追いながら設計書を総ざらいしたり、検証回数が当初よりも増えたことなどで余分な工数が増えてしまいました。
プロジェクトの振り返りとして、指摘項目に対してなぜなぜ分析からスタートして、主にドキュメント類の標準化やプロジェクトを進めるフレーム化を図りました。
- 指摘分析
プロジェクトを通して発生した指摘内容を分類化したうえで、どの分類が多かったかを分析。
【他責】ではなく【自責】の視点で改善できた点はなかったかを振り返り。
他プロジェクトで同事象が発生した場合のケース共有。 - 当時出た課題点、懸案を改めて整理
あらかじめ共通認識を持っておくべき点を資料として整理。 - 資料標準化・フォーマット作成
各種ドキュメントのフォーマット化と、セルフレビューチェックシートの作成。 - オンボーディング資料の整備
プロジェクトを進めるうえで前提知識として触れておくべき資料の置き場を整理。
実作業する上での前段階教育用のブートキャンプの整備。
振り返り
検証のたびにお客様から指摘をもらうたびに「いつになったら全部修正されるの？」「ちゃんとテストしたの？」と言われるんじゃないかと内心かなりヒヤヒヤしていた記憶があります。苦笑
あまりにもデグレードや検証不足が発生すると品質的な問題からお客様からの信用を損なうことになります。そうなるとこちらからなにか仕様や障害内容を確認するにもコミュニケーションがうまくいかなくなったり、スケジュールの見直し、犯人探しなど悪い方向にスパイラルする事例もあり得ると思います。
また、お客様は基本的に不安を抱えるものと個人的に思っているので、その不安をいかに一緒に解消しながらデータを修正していくかが常に意識の中にありました。
分析からの、ケース共有、資料標準化・フォーマット化に関しては他プロジェクトのメンバの方にも大いにご協力いただいたので、共通する課題意識を持って今後の対策に取り組めたことは本当に感謝しかないです。
あと、あるある話で盛り上がったのは、笑えないけど笑える話という感じで楽しかったです。
２．設計書フォーマット全部キレイにするマン
納品ファイルのフォーマットがぐちゃぐちゃのぐちゃ。
ExcelファイルをGSSで開いて編集していたり、少し古いフォーマットが混ざっていたり、各々が好きに編集したことでフォーマットが不統一でした。
それ、マクロで解決したらええやん
正直、各ファイルを開いて全部修正するのはかなり骨も心も折れます。
だいたい全部マクロで修正しました。
実装したマクロ
内容はどれも検索したらヒットするものなので割愛しますが、主に実装したものは下記。
- サブフォルダ含めてフォルダ階層内のExcelを再帰的に読み込み編集して上書き保存
- 読み込んだファイルについては、実行用のExcelマクロファイル上にファイルパスとリンクをつけて一覧化
- 一覧からPDFファイル出力できるようにボタンを設置
- Book内に非表示のシートが含まれている場合は一覧に注意ファイルとして記載
- Book内のSheetをすべてループで処理
- ヘッダ、フッタ部の文字入れとフォントの編集
- シート内の文字フォントの統一
- すべてのシートの表示サイズを100%に
- すべてのシートの選択セルをA1セルの位置にするとともに表示位置をスクロール
- 図形オブジェクトの文字フォントの統一
（処理的にかなり重たかったので、後日処理を切り出してファイルごとに実行できる仕組みにしました）
3回以上実行が必要なものはワンポチでできるようにしておきたい思いがあったので、楽をするために割りとガッツリ実装しました。
過去に取り組んできたプロジェクトで設計書についてはかなり細かなところまで気にすることが多かったので、微に入り細を穿つためにも面倒くさいことこそ自動化することは結構大事だなと思ってます。
３．ファイル名みんなまとめてリネームマクロ
他にもリネームできる便利ツールあるのはわかってるんですが、ほぼ遊び心だけで作ったツールです。笑
マクロのファイル名は略して「ファミマ」になるようになっています。
実装したマクロ
処理は本当に簡単なものです。
- フォルダ内にある現在のファイル名を取得してExcelマクロのシートの左の欄へ出力
- リネームしたいファイル名をExcelマクロのシートの右の欄に記載してからボタンを押すと一括でリネームする
リネーム前のファイル名も残るので、後から元のファイル名に戻したい時にリカバリが効くようになっているのもポイントです。
４．テスト項目書の進捗確認マクロ
テストの項目数が増えるほど進捗管理をどうやるか問題は発生するものです。
各自の管理や報告に任せる場合もあるとは思いますが、
この項目書ってあと何件終わったら完了なんだっけ？
NGがあった設計書どれだっけ？
ということが起こったり、消化率が見えないと残り作業の見積もりも立てづらくなります。
それもマクロで解決したらええやん
「一覧で見える化しましょうね」というだけの話ではあるのですが、ワンポチで誰かがマクロで集計取ってみんなで状況がわかるようにするものが１個あれば今後も使い回せるので、さっくり作りました。
マクロではなくBookをまたいでのCOUNT系の関数を使っても集計は取れるのですが、関数を多用すると集計ファイル自体が重くなるので、軽量化したいこともありマクロにしています。
実装したマクロ
関数をセルに出力する形式と、マクロ内で関数を実行し集計、編集する形式とを活用しています。
一覧の中で可変にしたいものは関数、手で修正する可能性があるものはマクロ内で編集という切り分けにしました。
- フォルダ内のExcelファイルを読み込み、Bookの全Sheetの情報を取得、Excelマクロファイルへ下記の項目を一覧化
- Book、Sheet名、Sheetへのリンク（HYPER関数をセルへ出力する形式）
- テスト項目数、実行済数、NG件数
- 項目数に対しての実行済件数のパーセンテージ（進捗率）（関数で出力）
- 日付ごとの消化数
- 全体の集計数がわかるよう、ヘッダ部の下のサマリ行へSUM関数を埋め込み
- 集計結果のセルの条件付き書式を設定（NGがあるものは背景色と文字色を変更するなど）
標準化することで何が嬉しいのか、誰が嬉しいのか
私の場合、２０代の頃は「最悪自分がなんとかする！」という感じで乗り切ってきた場面がかなり多くあって、結果的に周囲のメンバのスキルアップに繋がらなかったことは苦い経験でした。
// 未だにやってしまうことは少なくない。
早く行きたければ一人で行け、遠くへ行きたければみんなで行け
「自分でやったほうが早いし正確だから」という気持ちはめちゃくちゃわかるのですが、自己満足と紙一重、と切り捨てて、自分がいなくても回る状態をつくっていくことでプロジェクトもうまく回っていくようになるのではないかと思います。
「あの人がなんとかしてくれるから」「あの人がいないと、この部分わからないなぁ」という状態に陥るよりも、積極的に仕事を振って周囲のメンバのスキルや理解度を高めていくことで、自分自身の身動きを取りやすくするということでもあります。
ある程度自分になんとかできる能力があることを自覚していたとしても、それはどうしてもこの場面で馬力がいる！というタイミングで力を発揮すればいいのであって、普段は昼行灯を気取るくらいの気持ちでいたほうが周囲も動きやすくなります。
作業と判断とフォローを切り分ける
「何かしらみんな不便に思ったりしても、今まで何とかなってきたんじゃろうな」って部分こそ、みんなで走り続けるために道をきれいに整えていく。
自分自身が道の真ん中を走り続けるのではなく、走れるためのレールを敷いたり周囲のインフラを整えてあげる。
誰がやっても同程度のクオリティの成果が出せるように作業領域の標準化を行うことで、自分自身が判断領域や、更に新たに着手すべきことに注力する。
任せた仕事については、任せた相手がしっかり走れるようにフォローしていく。
このあたりは山本五十六の名言は本当に名言だなとしみじみ思います。
やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。 話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。 やっている、姿を感謝で見守って、信頼せねば、人は実らず。
標準化することで、自分も周囲のメンバも、これから後に引き継ぐ人も、お客様も、みんなが嬉しくなるような取り組みにつながればいいな、と思いながら私はこれらの取り組みを実行してきました。
とんでもない事象が発生したときこそ、笑い飛ばせる自分でいたいよね
標準化とはちとずれるのですが、どんな状況でも笑える余裕って大事だよねって話です。
いろいろな修羅場も経験したからこそ、というところはもちろんあるのですが、全然笑えない状況でも冗談を言って周囲を少し和ませるくらいのリーダーでいたほうがメンバの困ったを拾いやすくなると思ってます。
// とはいえ、もちろん締めるところはきっちり締めないとなぁなぁになるので、そこはうまく切り替える必要はありますが…
特にお互いの顔をみて作業することがずいぶんと減ったからこそ、SlackだったりWeb会議の場が重くなってしまうと、より怖いというか。笑
あとは、カオスな状況に放り込まれても「これはひどい！さぁ、どうしていきましょうか！」というテンション感で望むことで、強者の余裕感みたいな感じで乗り切れるような気持ちもあります。
自分たちのValueを磨き、よりよいものをつくるために
弊社、ALH株式会社の行動指針に「５つのキョウソウ」と呼ばれるものがあります。
WHIさんのValueに通ずるところがあると思ったので引用します。
All for one / 協奏
ひとつの目的に向かって仲間と力を合わせる
Level up / 競争
切磋琢磨し自分の能力を常に高める
Over drive / 狂騒
組織の力を信じ、時には限界を突破する機会に挑戦する
High motivation / 強壮
仕事にも組織にも高いモチベーションで向き合う
Agile partner / 共創
お客様とパートナーとして接し、新たな価値を生み出す
WHIさんのアドベントカレンダーの概要にも下記のように記載されています。
わたしたちがチームとして活動する上で、ひいては社会に価値を提供していく上で大切にしている価値観ですが、これらはWHIだけでなく、エンジニアリングやビジネスに向き合う上で広く共通するものだと考えています。
コーディングやシステムだけではなく、これから先のよりよきものを次代に残していくためにも、今やれることを他ならぬエンジニアとして呼ばれる我々自身が、当事者として挑戦していくことが未来に繋がっていくのだと思います。
蛇足：ほとんどマクロの話じゃね？
過去にこんな記事を書いてるくらいにはマクロ実装するのも、なんだかんだいって好きなんだろうなぁと思ってます。
別にマクロじゃなくてもいいとは思うのですが、Excelを活用している場合にまとめて編集したり集計したい場面は多いので、１つ作っておけば他に流用ができることと、自動化を考える上でパッと作りやすいことが利点です。
とはいえ、野良マクロが増える可能性も捨てきれないので、こちらも標準化と合わせて対応するからこそ効果を発揮してくれるかな、と思います。