ソフトウエアの開発ノウハウを自社に蓄積しようと、外部委託から内製への切り替えを推進しています。しかし、初めて手掛けた小規模なシステムで不具合が多発しています。中止どころか、失敗体験として内製化の芽を摘んでしまいかねない状況です。

(ユーザー企業/システム企画)

 ソフトウエアの重要性は日々高まっています。競争力の向上につなげるため、内製化にチャレンジする現場もよく目にします。ただし、外部委託を上回るコストや品質を可能にするには、「組織的な開発業務」のための文化が必要です。外部委託中心だったユーザーの多くはこうした文化がなく、新たに作らなければなりません。

 ここで役立つ考え方が、古くから武道で伝えられている「守破離」という学ぶ姿勢を表す言葉です。本質を身につけるためには守る、破る、離れる、という3つのステージを経る必要があるのです。これは開発組織の立ち上げにも応用できます。

 最初の「守」では、自分たちの理想に近い観点や開発スタイルを持つ社外のチームを手本にします。小さな目標を決めたパイロットプロジェクトを立ち上げ、そのチームに参加してもらいます。コンサルタントやトレーナーに一方的に教えてもらうのではうまくいきません。必ず一緒に働くようにしましょう。そして、その外部のチームと同じように行動し、開発ができる状態を目指します。

 外部のチームに持ち込んでもらった開発スタイルを何度も繰り返し、自分たちだけで自信を持って開発ができるようになったら、次のステージである「破」に進みます。ここで、忠実に守ってきたルールを破ります。

 行動の意味を理解し、結果を体験しているからこそ、破るべきものが見えてきます。筆者が内製化を支援した現場では、「リーダーが設計レビューを必ず実施していたが、類似の設計になる機能が多いため、設計者による申告制に変更する」といったルール変更を実施していました。「守」のステージを経ているから、変更後の影響を想定できます。想定外のトラブルがあっても自信を持って対処できます。

 「守」のステージを飛ばして、いきなり「破」に入ってしまうのがよくある失敗パターンです。前述した設計レビューのルールを変えた例は、設計レビューの意味を理解して初めて破る発想が出てきました。もともとの習慣がない状態で設計レビューを省略すると、単純にソフトウエアの品質を下げるだけに終わっていたでしょう。

 最後のステージは「離」です。ここまで来たら、組織の1人ひとりに開発スタイルとその根底にある思想が浸透しています。外部から持ち込んだスタイルだと覚えていないほど定着している状況です。「破」のステージと違い、ルール変更に身構える必要もありません。要求定義も設計も実装もテストも当たり前の行動になっており、自然と適切な判断ができます。

 組織の意思として統制や調整が働くため、メンバーが交代になったり、ほかの組織に展開したりしても大きな破綻が起こりません。ルールから離れ、自分たちの意思で行動できるようになっているからです。