概要
SI企業でアプリケーションSEとして仕事をしています。
年間総労働時間2000時間程度を心掛けて仕事を進めており、役に立った開発プロセス論を4つ共有します。
残業体質が中々改善せず悩む人へのヒントになれば幸いです。
チェックしてみよう！常に忙しいSIerさんの4か条
１．何かと新しいルールを増やしがち
２．常に要員が遊ばない様にタスクを組むことを大切にしている
３．WBSなどのファイルが散らかりっぱなし、フォルダの構成がめちゃくちゃ
４．案件Aに0.5人月、案件Bに0.5人月の様なアサインをしている
１．ルールは増やすのではなく変えよう
「バグへの対応策としてダブルチェックからトリプルチェックに強化します」
といった往年の現場あるあるなど、システム開発では道中の問題対応のために何かとルールが足されていきがちです。
一方で、それを棚卸して最適化したり減らしたりする運動は少なく、開発の歴史と共にルールは積み上がり非効率な開発プロセスになっていきます。
ルールやプロセスは増やすのではなく「変える」「研ぐ」意識で作りましょう。
顧客標準など大局的な部分は直ぐには出来ないと思うかもしれませんが、手の届く範囲から実践しましょう。
× トリプルチェックに増やす
〇 静的解析にして人為ミスをなくす
関連する開発プロセス論
大規模スクラムのフレームワークにLeSSがあります。
LeSSではスクラムをスケールさせるためにあえて組織やルールをがんじがらめに組み上げない「More with LeSS」を方針としています。
複雑性に取り組むには複雑さを減らしていくしかないのだけれど、別の複雑さを足して、さらに複雑にしちゃうのをよく見ますねぇ。たいへん。
— HARADA Kiro (@haradakiro) June 24, 2021
２．タスクではなく価値にフォーカスしよう
プロジェクトマネジメントをしていると人的リソースにタスクを張り続けることに追われ続けてしまう時があります。
「全員が毎日7.5時間余すことなく何かをし続けられる様に計画すること」が目標になってしまっている状態です。
この状態では「マルチタスク」や「リソース効率＞フロー効率」といった昨今の開発プロセス論において推奨されない考え方が正義になってきます。
タスクと結果（アウトプット）ではなく、出すべき成果（アウトカム）に注目しましょう。
そのために必要なプロセス、効率的なプロセスを見つけることが重要です。
そのために、週次など定期的にプロセスなどに対するふりかえりを入れる方法がおすすめです。
関連する開発プロセス論
フロー効率とリソース効率について初耳の方は以下の記事が判り易くおすすめです。
OutputよりOutcomeなので、生産性という言葉は注意が必要だと思う今日このごろです pic.twitter.com/pFBfXHLiDK
— Ryutaro YOSHIBA (@ryuzee) May 14, 2021
３．0.8人月の力で1.0人月分の成果を挙げるイメージで働こう
Done-Done-Done
従来のプロジェクト開発では「Done（動く）」か「Done-Done（リリース可能である）」あたりをゴールとして計画されがちと感じています。
この結果「Done-Done-Done（リファクタリングなど整頓も含めた完了）」が抜けていて技術的負債がたまったり、Done-Done-Doneを残業で対応する未来が待っています。
実装のみならず、SI開発で大層を過ごすコンサルティングや設計でもDone-Done-Doneは重要です。
検討資料や設計書が書きっぱなし散らかしっぱなしになっていませんか？後々になって手癖の様に毎回フォルダの海を泳いでいませんか？
出典：【イベント参加レポート】Builders Box ON AIR #1 レガシーコードからの脱却
ボーイスカウト・ルール
Done-Done-Doneを果たすためには「進め方を掴むこと」「時間を確保すること」が必要です。
進め方はボーイスカウト・ルールが標語として定着しやすくおすすめです。
ボーイスカウトには大切なルールがあります．
それは，「来た時より美しく」です．
たとえ自分が来た時にキャンプ場が汚くなっていたとしても，
そして，たとえ汚したのが自分ではなかったとしても，
きれいにしてからその場を去る，というルールです．そうやって，次にキャンプに来る人達が気持ちよく過ごせるようにするのです．
アンダーコミット
時間の確保は日頃考えている0.8人月位が本来の1.0人月と捉えて計画するイメージがおすすめです。
これはDone-Done-Doneの達成のみならず、期間とタスクを気持ち少なめに見積り、早く終われば先のタスクを先食いする考え方が結果的に良い生産性に寄与するというプラクティスにも沿っています。
私はほぼ連続して、2つのチームを訪ねました。
チームの1つが言ったのは、私たちは自分たちができると言ったすべてのことをデリバリすると嬉しく思います。
自分たちが成し遂げることのできる以上のものが常にリストにあると、やる気がそがれます.... 。そして次のチームはこう言いました。私たちは自分たちがやり遂げられる以上のことがリストにあるほうが好きです。
その場合、次に何をするかを心配する必要はありません - 常にピックアップされるのを待っているものがあるのです。
４．0.5人月と0.5人月は、合わせて1.5人月と計算しよう
従来のSIerでは何かと兼務が発生しがちでした。PjMと開発リーダー。A案件とB案件など。
特に、0.5人月＆0.5人月で兼務するケースはあまり良いことが無いと思っています。
- 0.5人月のアサインは実態上は0.7~1.0人月分の成果を期待されている
- 0.5人月アサインはどちらもインプットすべき情報量がそれなりに多いため切替にかかるオーバーヘッドがかかる
0.5人月を2案件兼務すると実態上0.75+0.75=1.5人月などとなり、無事に働き方改革は霧の中へ消えます。
今こうなっている人は今年度中に辞めましょう
マルチタスクと生産性についてはアジャイルな計画と見積もりの下図が参考になります。
生産性を得るには2つまでのマルチタスクはOK、3つ以上はNGというものです。
出典：アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
おすすめは専任、または0.8人月と0.2人月などメリハリをつけたアサインにすることです。
0.1～0.2人月アサインは役割が研がれ、役割の肥大化やオーバーヘッドのコストを抑えながら価値を提供することが出来ます。
おわりに
生み出す成果はそのままに労働時間を抑えて仕事を進めるポイントを4点あげてみました。
近年注目の開発プロセス論をコンサルや設計など日頃の業務全体に応用している実感が強いです。
早く仕事を終わらす⇒開発プロセス論を学ぶ⇒早く仕事が終わる⇒学ぶ・・・という正の循環を堅持することが重要だなと考えています。