不安を認識することの重要性

久々のエントリなので,ちょっと長文。 ソフトウェア開発のゴール,それは当然「仕様通り正しく動くこと」である。これは,簡単なようで非常に難しい。どんな工夫をしたとしても,完璧な結果を残すことは困難である。まだまだ職人技の集合なソフトウェア開発について,ゴールをめでたく迎えるためには,常に「不安」と「安心」がコントロールされた状態になければならない。 プロジェクトに参加した大多数の人間は,「漠然」とした不安と安心を持っているだろう。全く何も感じない人間はいないはずである。しかし,各個人の性格的な問題,人間関係,業務上での上司の評価,さらに利害関係などが複雑に絡み,その結果,そのような不安や安心を言葉として口にされることは稀である。つまり,プロジェクトメンバーのほとんどは,悶々とした気持ちで開発を行っている。 この状態は,最もいけない状態である。 不安に感じるということは,解決できない問題に直面しているということ。そして,安心しているということは,問題の解決に自信を持っているということだろう。一切不安がなくなれば,それは安心しているということになる。プロジェクトの始まりは「どんなことが待ち受けているのだろうか」と不安だらけなはず。その不安を安心に変えていくことこそが,プロジェクトを遂行していくことに違いない。 では,不安を安心に変えるためにはどうすればいいか。まずは,不安を正しく認識し,表面化させることが必要だ。 漠然とした不安は誰しも簡単に持つことができるが,そのままでは安心には変えられない。何が理由で不安に思っているのか,これがちゃんと表面化する必要がある。基本的に仕事について「言われたことをやればいい」としか思っていなかったり,「誰かが何とかしてくれる」と思っている人が大多数なので,自分がやっていることについて不安を自覚していないことが一般的だろう。しかし,現状のままで進めた場合のリスクを経験から導き出し,それを当事者に指摘して,はっきりとした不安(=問題意識)を持ってもらうための,第3者的な発言がここで必要となる。例えば「おぃ,このままだと○○が作れないぞ」といった技術的な指摘や,「おぃおぃ,これじゃあとどれくらい工数かかるかわかんないじゃん」といった管理的な指摘などだ。 これは,上下関係を超えてプロジェクトに関係する全ての人に指摘できる役割の人間がやることであり,やはりそれはアーキテクトの仕事だと思う。 明確な不安であれば,それを認識した各個人は,不安を解消して安心するための手立てを考えようとする。不安に思ってもらうことはかなり難しいが,不安に思ってもらえれば,その後の好転は比較的スムーズに訪れるものだ。 ただし,不安を口にすることは,かなり勇気が必要になる。結果として個人攻撃に陥ることもあるだろうし,プロジェクトの主要メンバーの気持ちをどん底に 突き落とすことになるかもしれない。権限のある人間(〜管理者って肩書きの人など)から「何でもっと早く言わなかったんだ!?」と逆に責められてしまうことも考えられる。さらに「じゃあ,おまえがやれよ」と逆ギレされることもあるだろう。そのような逆風を覚悟してでも,明確な不安を持ってもらうための発言は勇気を持ってしなければならない。さらに,政治的な面も多く絡んでくるはずなので,いろいろな関係者と交渉をするための勇気も求められるだろう。 プロジェクトの状況や技術的な詳細知識,さらに各個人の実装内容などを広く正しく把握できるアーキテクトだからこそ,そういった役回りを率先して行う責任があると思う。 さて,プロジェクト内のさまざまな「潜在的不安を探す」ために,アーキテクトは開発プロセスやプロジェクト管理にまで口を出すことが必要となる(もちろん「潜在的な不安を見つけなくちゃ」という不安を持っていることが前提)。TDDなどはその際たる例だろう。単体テストという粒度の中で,何が正しいのかを事前に定義し,それを例えばJUnitという機構で自動化する。常に実装コードに対して「チェックされた」状態を保つことで,自分が書いたコードが果たして正しいのかどうかという不安を実装者から解消する。 さらに僕は,TDDを開発全体にまで広げることが最低限必要だと思っている。 俗に言うウォーターフォールでの「設計→実装→テスト」では,実装した後で「正しく動作するかどうかを検証するための手順」を定義していくことになる。これでは,実装したコードは「単に書きなぐったもの」であり,必要となる実装コードが揃っているかどうかもわからないし,実装工程の完了まで現状(の品質)がどうなのかを把握することすらできない。長期間にわたって不安を持ち続けることになる。 であれば,少なくともテスト部隊は実装部隊とは全く別の人間で組閣し,何が正しいのか,そしてそれをどう検証するかを並行で考えてもらうことが必要だろう。実装の早い段階からテストを適用し,全てを網羅するテストシナリオを何度も何度も繰り返し行ってもらうことで,実装コードの現状をメンバー全員で共有する。 もちろん最初のうちは「テストにならねーよ」って結果になるだろう。機能を呼び出した瞬間に「ぬるぽ発生」かもしれない。でも,それによって実装メンバーが不安を持つことが重要なのだ。

  • 実装している裏でテスト部隊が常にチェックをしてくれている

  • そして常に実装メンバーを不安にさせてくれている これが健全な姿なのだと思う。 これを行うためには,実装→テストという流れで行った際のそれぞれの密度と比べて,作業時間がそれぞれ長くかかるため密度が薄まる。しかし,明確な指針から導き出された不安に基づいて算出される残作業の量を知ることができるようなるため,例えば「あとどれくらいで終わるの?」という質問に対しても論理的,定量的に答えることが可能になる。そして,統計学もそこに適用しやすくなるはずだ。 今まで書いてきた話をいざ実践するとなると,多くのリーダーやマネージャはその適用を渋る。なぜなら,単にWBSで引いた期間とその進捗度合いを観察するだけでは,管理が済まなくなるからだ。期間なんて最初に決めて「それで終わるはずだ」と思ってるのがそもそも間違っているのだが,それが管理者にとって単純であり,理解しやすいのだろう。しかし,作業の遅れが出だして「予定通りにいかないよ〜」となったときには,残りどれくらいなのかを日々観察することの方が単純だということが直感的にわかるはず(そのときにはもう手遅れなんだけど)。本来管理者は,現状把握がどれだけ行われているのかが勝負の分かれ目。その把握をしやすい開発プロセスや体制を説明し,理解してもらい,実践の継続を導くことも,アーキテクトの仕事なんだと思う。 「あれ?これってどうなっているんだろう」と不安に思った瞬間,それはあなたがプロジェクトを好転させるチャンスを握ったことに他ならない。

このエントリーをはてなブックマークに追加

関連記事

40%キーボードに慣れるためにやったこと

Lunakey PicoでQMK Firmwareを動かしてみました

Googleアシスタント向け会話型アクションが1年後にシャットダウンされます

Google I/O 2022でのGoogleアシスタント関連のセッション

Remap Organizations feature has been released