はじめに
プロセス改善に関して個人的に有益だと感じた知見と思いつきを蓄えていきます。随時追記します。
本記事に記載したことは、「聞いたこと」、「聞いたことの私の解釈」、「聞いて私が思ったこと」などが混在していますので、ご注意ください。
知見
松尾谷さんからのコメント（2016年）
- 現場のナレッジをツール化することがポイント。
- 意外とツールが活用できていない現場は多い。
- ツールに任せられるところは、ツールに任せる。
にしさんの研修（2016年）
- プロセス能力成熟度レベルは、継続的に成長をする組織に取っては、レベル5がスタートライン。
- 判断の早さは価値。
- 同じ工程でもフェーズによって、目的や範囲、対象等が異なるなら、そのことを表現し説明できるようにする必要あり。
- 枯れた技術を組み合わせると、新しいものが生まれるかも。１つの技術じゃ弱くても、3つくらい重ねると強くなる。ある技術の成果を別の技術の入力として活かす。
- Wモデルで大切なのは、テスト要求分析やテスト設計で、作り込み工程の問題が見つかるという実感。問題が見つけられる活動や技術を前倒しで使う。
- 人は自分が今困っていないことについては、共感しない。
参考記事：
https://zuuonline.com/archives/185323
松尾谷徹さんとのお話（2016年）
- 世の中にアイデアを発信して、フィードバックを得ることで、世の中が必要としている価値、自分のアイデアが持っている価値に気づく。
- 当たり前かつやるのが難しいことを、伝えることの難しさ。
- 低いレベルのチームを改善しようとするが、高いレベルのチームの良さを分析していないことが多い。
- 寛容な組織のほうが、クイエイティブな人が集まりやすい、育ちやすい。組織の寛容性の測り方、モヒカン頭の数。茶髪の数でも良さそう。
- 人に必要な経験。貧乏、失恋、入院。
小川清さんとのお話（2016年）
- 機械化自動化できる作業やその作業に必要なデータを分離する。制約があって、機械化自動化できないと思っていた作業が、一部機械化自動化できるようになる。機械化自動化できる作業の範囲は少しずつ増やす。
- 技法・技術は、全範囲に対して適用する必要はない。適用しやすいところ、効果が高いところを選定して、一部に適用するだけでも、十分。
- 人に「よい」と思わせるためには、その人が何を誰を信用しているか、何を誰を気にしているかを知ることが重要。
- すごいと思った人の師匠を辿る、影響を与えたことを辿る。
武田匡広さんとのお話（2016年）
- プロジェクト計画など、テンプレートを変えずにそのまま使うプロジェクトは失敗する。テンプレートの例で書かれている言葉が、そのまま残っているプロジェクトはアウト。
清水吉男さんとのお話（2017年）
- 問題は、具体化し、明らかにしたあと、抽象化する。具体的な問題を明らかにしていないうちに、抽象化しないこと。
- 守破離の守が大切。まずは、よいとされる型をそのまま守る。型を理解し、意識せず実行できるようになるまで。
- 継続できることは、大切な力。
SPA研究会での雑談（2019年）
個人目標管理の仕組みで、人（自分含む）が成長するのは難しい。何年もやってるけど、今だにうまく機能させられる気がしない。
- 目標達成が、人事評価（昇格・賞与等）と結びつくと、どうしても安全な目標になりがち。
- 半年前に立てた目標（半年後を見て立てた目標）は、状況の変化や前提が明らかになることで、価値がない目標になりがち。楽に達成できる目標で、あることが多い。
- 日々成長するために頑張るという行動を生み出すではなく、半年毎に数字を合わせるために・説明を考えるために頑張るになりがちり。
個人的には、面白くない・つまらないです。でも、人事評価と結びつくので、しっかり・真面目にやってます。
目標評価の期間を短くして、達成確率が低い目標しかたてないのがよいかも。期間は1ヶ月毎でもよいかも。
ただ、目標達成と人事評価と結びついていたら、結局うまくいかないかなぁ。でも、結びついてるから、しっかり・真面目にやる側面もあるなぁ。個人目標管理って、そもそも、うまく行きにくい・難しい仕組みなのかなぁ。
参考記事：
https://president.jp/articles/-/27886
http://katsuaki.co/?p=465
https://logmi.jp/business/articles/320320
永田敦さんとのお話
価値が測れない限り、"早く達成"ということが評価できないので難しいのではないでしょうか
※以下は「私が思ったこと」
- ユーザ・顧客・組織への価値の視点が抜けていた。早くたくさんのゴミを生み出しても意味ない。生み出したい価値が関係者と共有され、価値が出たかが確認できれば、つまらなくないし・面白い。
- 当たり前かもしれないが、組織目標ではなく、価値とプロジェクト目標・個人目標を直接結びつけておいたほうがよい気がする（それで誰がどう嬉しいの？嬉しさが得られたことはどう確認するの？）。
- 行動した結果、価値が表現れるのは、時が経ってからの場合が多い。また、自分が関わらないところで、時と共に、ユーザーが増えるなど価値が増えることもある。行動をしたあと直ぐに、その価値を評価するのは、難しそう。行動を評価するタイミングと価値を評価するタイミングは別で考えないといけないのかもしれない。
SPI Japan 2019の講演（2019年）
- エスノグラフィーは、師匠弟子モデルで観察する。弟子として師匠を見て学ぶ。そういった、意識・言動・行動をとることにより、よい関係が気づけ、事実が見えてくる。
- 判断のスピードを求めすぎて、決められた組織構造を無視すると、痛い目をみる。
大島啓二さんとのお話（2019年？）
■村上治，「リスクとインシデント」，経営・情報研究 多摩大学研究紀要 No.20，2016
https://tama.repo.nii.ac.jp/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=300&item_no=1&page_id=32&block_id=88
上記文献をみて、『放置しておくと大きな問題に発展することがらや状態』は、インシデントという言葉を使ってもいいのかなと思った。
■「ヒヤリハットとは何か～その意味と定義を事例と法則をつかって解説」，2018
https://resilient-medical.com/incident/hiyarihatto
上記記事をみて思ったこと
- インシデントを認識していても、ヒヤリハットしないと、主体的な行動は起きにくい（自分自身もにも当てはまる）。
- 行動を起こすためにヒヤリハット（被害が小さい状態でインシデントを経験する）ことが大切ではないか。更に、チームでそのヒヤリハットを共有するのも大切ではないか。つまり、特定の人の経験を、チームのみんなの経験にする。
- レビューやテストで見つけたバクとその原因を共有して原因潰しているのは、ヒヤリハットを共有して行動していることだと理解した。
- 例えば、似てる名前の変数の取り違えを、レビューで発見して、該当箇所の修正だけでなく、『これはみんなやらかすね。そもそも名前変えておこう。』という行動をしたのは、１つのよい事例だった気がする。
- こういったことが、常にできているチームをどうやって作るか維持するかは課題。
JaSST'19 Tokai（2019）
- やらないことを提案・合意する
- テストすることを合意する だけじゃなくて、テストしないことを合意する。
- やることを提案する だけじゃなくて、やらないことを提案する。
- 転職をとめる じゃなくて、転職をすすめる（当たり前にする）。
昔家を建てたときに工務店の方から「2階にトイレって本当にいりますか？」「クローゼットの扉って本当に今いりますか？」「食洗機って本当に今いりますか？」等、”いらない”ほうに誘導する質問を受けたことを思い出した。儲からないほうに誘導する不思議な工務店だった。
- 問題を共感していない状態（自分にとっても、いつ起きてもおかしくない問題だと思っていない状態）で、未然防止のためのルールを増やされても、エンジニアはモチベーションが下がる。
CEST技術交流会（2020年）
- 車載組み込みソフトウェアの業界は、昔から（昔は?）アジャイル宣言に示されている価値観で、開発しているのでは？ウォーターフォールではないと思う。フィードバックが得られるまでの期間が長いかもしれないけど。
- 学習したこと・気づいたことを半年後に活かすのではなく、学習したこと・気づいたことを1週間後に活かせるとよい、学習したこと・気づいたことを翌日に活かせるとよい。学習したこと・気づいたことを、早く活かせるようにするための、仕掛けをつくる。
- 機能性は品質特性の一部。非機能の品質特性もある。非機能要求を満たすことを早く検証することが大切。開発期間の終盤に非機能要求を満たさないことが発覚することで、プロジェクトが炎上する事例を見聞きしている。
- ソースコードを修正する行為だけでなく、品質を満たすか不確定なソースコードを検証する行為でも、価値を生み出す。ソースコードの修正を伴う要求を洗い出し優先順を決めるのではなく、確認したい品質（機能はその一部）を洗い出し優先順を決める。機能を積み上げるのではなく、品質を積み上げるという考え方が大切。
- 性能の計測は、必要な機能を全部入れないとできない。早く全部の機能要求を満たした状態を作ること大事。
- 非機能要求に対する計測がしやすい環境を整えておくこと大切。機能を追加したら、すぐに性能の計測ができる状態だとよい。
- 組み込みソフトは、機能要求に対応するフェーズ（試作するフェーズ）と、非機能要求に対応するフェーズ（仕上げるフェーズ）を、明確に分けてしまったほうが、開発がしやすそう。
- 後工程はお客様。前工程は神様。後工程となる量産フェーズの評価が楽になるように、前工程の先行開発で設計する。基本的には、前工程（前フェーズ）が高い立場で、後工程（後フェーズ）が低い立場ということはない。例えば、多くのものを手間をかけて量産し、最終的なコストへの影響が大きい、工場の意見は尊重される。
- 予算は、誰によってどこに多く投入されているか（どこに金がかかっているか、誰が金を出しているか）が、声の大きさに（誰の意見を尊重するかに）影響を与える。
- 試行錯誤で試作するのが得意・好きな人と、地道に仕上げるのが得意・好きな人がいるように思う。人の特性を把握して、適材適所になると良さそう。
参考資料
https://www.haramasahiko.com/kaizen/maekoutei
https://www.kaizen-base.com/contents/qc-43052/
思いつき
自給自足
野菜を家庭菜園で自給自足することは、以下の良い点がある。
- 旬の状態・新鮮な状態で食べられる。
取り立てのキュウリはパリポリでうまいですね。
ブルーベリーは熟すまで待つとめっちゃ甘くなりますね。 - 少しくらい問題があっても許せる。せっかく作ったものだから、少しくらい問題があってもなんとか価値を得ようと工夫する。
キュウリは大きくなりすぎたら漬物に。 - どうやって作られたものかわかっているから安心。
無農薬。 - 勉強になる。
農家さんは大変だ。
ソフト開発で使う道具も、できる限り自給自足したほうが良いかもしれない。
- 必要なときに必要なものを無駄なく用意できる。
- 少しくらい問題があっても許せる。せっかく作ったものだから、少しくらい問題があってもなんとか価値を得ようと工夫する。
- どうやって作られたものかわかっているから安心だし改善できる。
- 勉強になる。
健康管理
プロセスの測定・診断・改善だけでなく（よりも）、体の測定・診断・改善が大切かもしれない。
工場の機械はメンテナンスする。ソフトウェアは機械ではなく人間が知的生産活動により生み出すものなので、人間の心と体のメンテナンスをするのは当たり前。健康だからこそ、自分の能力が十分に発揮できる。
チームビルディング
知識より、手法より、プロセスより、ツールより、チームビルディングが大切かもしれない。
チームビルディングが、もっともQCDに影響を与えられるかもしれない。
組込みソフト開発における炎上の原因
炎上している大きな要因、開発終盤での性能問題である。
全部の機能が入らないと最終的な性能（リソース、時間）はわからない。
開発終盤だから、大きな設計変更はせず、ごまかすことが大半。
設計変更をした場合は、デグレがよく起きる。
ごまかした場合は、イレギュラーなことをやっており、次の開発で、埋め込まれた設計制約や分かりにくいコードの地雷にはまる。
炎上を退けるためには、先行開発で早く性能の検証ができることが、ポイント。
派生開発案件のコーディング
派生開発案件のコーディングを複数ステージに分けるやり方は、スピード・品質の面で、結構いいかも。
【前提】
要求定義は完了、開発者は要求を理解済
【必要なもの】
既存機能単体テストやデバッグがいつでもできる環境
インタフェース定義等の詳細設計は、コードにコメントで示すためのルール・仕組み
【開発ステップ】
1 追加機能、変更機能を実装、デバッグ
2 USDMで変更仕様の抜けを検証し、不足を実装、デバッグ
3 設計制約の変化を特定し、必要となる変更を洗い出し、実装、デバッグ
4 変更に伴い、既存機能にデグレードが発生しないかテストし、修正が必要な箇所を洗い出し、実装、デバッグ（もちろん変更仕様に対するテストも実施）
5 性能を計測し、設計を見直し、実装、性能再計測
6 保守性・拡張性の観点で設計レビューし、設計を見直し、実装、回帰テスト
7 信頼性・安全性を確保するために、検証活動を実施し、リスク箇所にガード処理・フェールセーフ処理の追加を検討し、実装、テスト
上記の全てのステップで、コーディング。徐々に、ベースソフトや仕様に関する理解が深まり、理解したことを知識として整理し、次のステップの開発にフィードフォアード。1から7は、それぞれ2週間程度で回せるとよい。機能を徐々に作り込むのではなく、品質を徐々に作り込む考え方のアジャイル開発。
これをやるには相当の技術力が入りそう。いま、結構できているきがする。
7回もコーディングする計画って、面白い。
お客様のご要望への迅速かつ適切な対応
お客様のご要望に迅速かつ適切に対応するには、「お客様の興味をタイムリーに把握しておく」「要求の出所となっている人から直接情報を得る」ことが大切になりそう。
- 先輩（加藤真史さんだった気がする）から教えていただいたこと
「お客様のご要望に対して迅速に対応するためには、お客様の興味を早く把握し、お客様の先回りをして興味の対象を理解しておくことが重要。そのために、お客様の席に置いてある書籍に注目する。お客様のところにお伺いしたら、どのような書籍が置かれているか見てくる。」 - 小川清さんから教えていただいたこと
「要求を出すお客様だけではなく、その要求の出所となっている人を特定し、パイプ作る。要求の理由を知るために。例えば、車載ソフトウェア開発をしている場合、テストコースに行ってみるといい。また、例えば、OEMの方が参加するシンポジウム等で、社外発表をしてOEMの方からの意見を引き出すといい。」※例えばの部分は表現が少し異なっている可能性がある。
監査
プロジェクトに対する監査報告で、流出不具合が発生する確率を示せるとよい。また、一緒に発生する可能性の高いリスク(不具合)の種類や場所を、示せるとよい。
「問題ないです。」という言葉だけの報告はしないほうがいい。絶対に、リスクはあるはず。
防止したい不具合や達成したい品質をサブゴールとし、その下にゴール達成のための条件(活動など)を示したゴールツリーに、重みと確率を示すといいのかも。
ひっくり返る
大型のリクガメ「アルダブラゾウガメ」と触れ合ってきました。
リクガメって、ひっくり返ると、自分で起き上がれないんですね。
外からみんなが、いくら応援しても、起き上がれませんでした。
飼育員さんが、中に入り手を貸して助けて、もとにもどれました。
プロジェクトも、ひっくり返ると（炎上すると）、そのときのプロジェクトメンバだけでは、健全な状態に戻すのが難しい気がします。
外からみんなが、いくら応援？提案？指摘？しても、起き上がれない気がします。
中に入って立て直す火消しのプロみたいな人が組織にはいるべきかもしれません。
ひっくり返ったら終わりなので、ひっくり返る可能性のある行動はとらないように、注意しないといけませんね。
カメのひっくり返った状態は目で見てわかりやすいけど、プロジェクトのひっくり返った状態ってわかりにくいです。ひっくり返ってるか判断しやすくしておきたいです。
田中晃博さんとのお話
「ひっくり返る可能性のある行動」はひっくり返ったことのある人しかわからないので、一度はひっくり返らないといけない気もします。（戻れないぐらいのひっくり返りは致命傷になるので、戻せるような環境下でのひっくり返るが必要だと最近思います）
ひっくり返る可能性のある行動をとらないことで、みんなの可動範囲が減り、ものすごくこじんまりしたチームが多い気もしています。
もとに戻してくれる人・仕組みがあれば、安心してひっくり返れますね。もとに戻す人・仕組みを用意して、一回思い切ってひっくり返ってみるのは、確かに必要かもしれませんね。
プロセス改善の議論
プロセス改善の議論って楽しいだけじゃなく苦しい。
べき論と現実論は、分けて話をしないといけない。
自分の担当工程への作用だけじゃなく周りへの副作用を考えないといけない。
自分が担当しているタスクが関わるプロセスの場合、現実論で考えてしまう、自分への作用を主に考えてしまう。
やはり、立場の違う人が集まって議論する場が必要。一緒に議論してくれる人に感謝。ありがとう。
関連記事