正常に動作するソフトウェアを開発することは、開発者にとって非常に大きな挑戦です。しかし同時に、ソフトウェアは、正常な動作を超える機能を備えていなければなりません。セキュリティとアクセシビリティを確保し、ユーザーのニーズを反映できる必要があるのです。次のような方法で、開発者のモチベーションを高めて、基本を超える機能を実現してもらいましょう。

ソフトウェア開発者に対して不満があるのではありません。アプリケーションを設計して、基本的な機能の目標を達成し、バグをほとんど出さず、納期と予算を守る。それだけでも大変です。
しかし、「機能する」の意味が変化しています。ソフトウェアは、セキュリティ機能 (最近のセキュリティ侵害についてはご存じの通り) や、幅広いユーザーがアクセスできる実用的なユーザーインターフェイスを備えている必要があります。また、アプリケーションの機能は、特定の上司の指示だけでなく、エンドユーザーと利害関係者のニーズを真に反映したものでなければなりません。私たちは数多くの不満を耳にしたり、口に出したりしていますが、それは、開発者がこうした目標をほとんど達成できていないことを示しています。
その一方で、開発者は、数多くの障壁に阻まれてコードを簡単に製品化できず、すでにストレスを感じています。適切なこと、つまりあなたが開発者に望むことが既存の開発プロセスに含まれていない場合、どうすれば、彼らのモチベーションを高めてそれを実現できるでしょうか。
私は、知ったかぶりの傲慢な若者だったときでさえ、自分の仕事に人々が不満を抱いていることを知るのが非常にショックでした。
ソフトウェア開発者、Anca
私は、経験豊かなマネージャ、ユーザー、経営者に、効果が得られる方法と得られない方法を尋ねました。たとえば、どうすればソフトウェア開発者が、設計とプログラミングにソフトウェアセキュリティのベストプラクティスを適用してくれるか、アクセシビリティと優れたユーザーエクスペリエンスを効果的に設計するには何が励みになるのか、また、何が「ユーザーに質問する」スキルを磨くための動機付けになるのかについて質問しました。この記事では、業界の専門家から得られた回答をご紹介します (プライバシーに配慮し、個人情報に関しては詳細を記載していません)。

 

管理上の優先事項として扱う

ここには2つのシナリオがあります。アセンブリ言語に例えてみましょう。あなたが管理職の場合、「ジャンプせよ」というあなたの指示に、開発者が「条件付きですか? 条件なしですか?」と返答します。その後、あなたは「今後はアプリケーションセキュリティが最優先である」と宣言することで、望んだ効果が得られます。つまり、短期間でそうなるのです。上級管理者が、開発スケジュールに影響が出るのを認めず、非現実的な期限を求める場合、プログラマたちは消極的になり、手を抜くでしょう。
ポリシーは上から発せられるべきだと、システム管理者のRaumaは語ります。「そうでなければ、開発者は忠実にはなれません。いずれにしろ反感を抱きます」。

 

説得によって得られる効果

さほど強力ではないもう1つのシナリオでは、あなたは別の部門で働いており、開発スタッフに指示を与える必要があります。おそらく、アプリケーションの要件をしっかり聞いてもらうために、彼らをおだてる必要があるでしょう。ソフトウェアの最終バージョンがユーザーに不評で、UIの改善が求められ、あなたはこの機会にそれに取り組むことにします。
望んだ結果を得るための最も直接的な方法は、経営者を説得して、開発者が順守すべき指示を出してもらうことです。しかし、それがいつも可能であるとは限らず、長期的に見ると最善の方法とは言えないこともあります。チームの垣根を越えて関係を築く方が、はるかに良い方法であり、全員が心から協力したいと考えるようになります。
「ここでは2つの問題があります。相手に、そのタスクを完了すべきことに同意してもらうことと、そのタスクを優先すべきことに同意してもらうことです」と、ITコンサルタントのHarwell Thrasher氏は指摘します。「私たちは、説得と動機付けを組み合わせようと努めています」。どんな説得様式が最も適切かを考えるための観点として、同氏は次の4つを挙げます。積極的な説得 (事実と論理的主張を示す)、共通のビジョン (他の人を刺激して、より良い将来のためにビジョンを共有してもらう)、参加と信頼 (あなたの価値を認めて信頼を寄せる人たちに、指示に従ってもらう)、そして報酬と処罰 (飴と鞭のアプローチ) です。
たとえば、開発中のコードを侵害しようとしている実際の攻撃者を指摘すれば、エンジニアの完全性のニーズに訴えかけることができます。これは、共通のビジョンと、積極的な説得の両方に役立つでしょう。対照的に、あるシステム管理者は、「安全でないコードの行ごとに、JIRAの (トラブル) チケットを発行しています」と回答しました。これは明らかに飴と鞭の対応です。
「重要なのは、最終的に両者に利益をもたらす解決策によって、モチベーションを高められる方法を見つけることです」と、Paula Cizek氏は語ります。同氏は、コンサルタント会社、NOBLで最高調査責任者を務めています。「その方法は、人によって異なるでしょう。そのため、時間を取って彼らのモチベーションについて知り、それを理解することが不可欠です」。

 

求める結果を定量化する

セキュリティ、アクセシビリティ、利害関係者の参加など、解決しようとしている問題が何であれ、最善の方法は、測定基準を要件に結び付けることです。測定できないものは実現できません。つまり、あるアプリケーションで、パフォーマンスの要件を満たすことが重要な場合 (1時間当たり15,000件のレコードを処理するなど)、その要件が満たされるまでは、誰もそのアプリケーションが完成したとは認めないのです。ソフトウェアがセキュリティの標準を満たす、あるいはアクセシビリティテストに合格することを望むなら、それらを品質保証の過程に含める必要があります。
たとえば、アプリケーションのアクセシビリティを高めたい場合、それを設計の要件として作業範囲記述書に含めるべきだと、ソフトウェア開発者のJohnnyはアドバイスします。「アクセシビリティを、ソフトウェア開発の基本におけるモットーにします。テスト部門には、アクセシビリティを特にテストしてもらいます。こうしたテストに合格するまで、製品化の準備が整ったことにはなりません」。また、Johnnyは、協働できない人たちを統率することも重要であると述べています。
また、適切な測定基準と、測定すべき対象を知ることも、課題の1つです。
標準的な業界慣行の採用を求めることで、定量化できる測定値を得られることもあります。たとえば、セキュリティに関して、情報セキュリティの専門家であるIrenaは、継続的な教育、継続したリマインド (これには「OWASP Top 10」が役立ちます) を行うほか、同業者の設計とコードをレビューすることを推奨しています。

 

共感による効果を知る

長期的なアプローチの1つは、開発部門とあなたの部門との間で、スタッフの連携を促すことです。そうすれば、部門同士で学び合うことができます。
「部門を超えてレビューや業務を行うグループがあれば、非常に効果的です」とBethは語ります。「会社が、各チームからエンジニアを1名選出するようになったことが、セキュリティについて考えるきっかけになりました。そのエンジニアは、「セキュリティワーキンググループ」のメンバーで、自身のチームのセキュリティ監査を担当していました。休憩中に (お菓子を食べながら) 会話したことで、未解決の問題を解決できそうなベストプラクティスを、互いに学ぶことができました」。
意識を高められるチャンスもお菓子も、決して逃さないようにしましょう。
「終える必要のある仕事が放置されていれば、エンジニアの多くが、それを片付けようとします」とBethは指摘します。「ですから、これは完了すべきなのに誰も手を付けていない業務、という予測を立てて、それを「特別なプロジェクト」のように扱います。そうすれば、多くのエンジニアがその業務に気付いてくれます」。
Cizek氏も、開発者と、彼らの仕事の影響を受ける人たちとをつなぐことで共感を得られる、とアドバイスします。たとえば、Facebook社は「2G Tuesdays」という取り組みを行いました。低速のインターネット接続をシミュレーションして、発展途上世界でページがどのように読み込まれるのかを、スタッフに体験させました。

 

開発者が効果的に質問できるように支援する

共感の程度をテストする方法の1つは、開発者がユーザーに質問することです。しかし、利害関係者が、自身やエンドユーザーの要求とニーズを常に理解しているとは限りません。
そのため、ソフトウェア開発者が効果的に質問し、相手に耳を傾け、将来を予測できるようにすることがますます重要になります。これは簡単な仕事ではありません。「プログラマのほとんどは、プログラマではない人の気持ちになって考えることが苦手です」とMatthewは語ります。「開発者は、オンかオフ、または1か0でものごとを考えますが、利害関係者は「大抵の場合、この…の機能がほしい」という考え方をします」。
それに取り組む方法の1つは、利害関係者に何を達成したいかを尋ねることです (例: 「製品配送の追跡」)。ソリューション (例: 「データベースで…を処理する必要があります」) を提案するのを避け、解決すべき問題を説明するように、開発者を誘導します。
利害関係者に、システムの機能と、現在のワークフローを説明するように依頼します。「ある時間内に質問を受けなかったら、こちらから質問します」と、James Schweitzer氏は語ります。同氏は以前Raytheon社でシニア主任ソフトウェアエンジニアを務めており、主に制御システム、暗号法、信号処理に携わっていました。「「なぜそのように判断したのですか」や 「どのようなアプローチですか」などのフレーズに沿って質問します。ガイダンスドキュメントには常に、少なくとも1つは曖昧な点があります。それがいつでも、質問につながる良い話題になります」。

 

セキュリティはプロセスに不可欠

共感の話が長くなりました。誰もが少なくとも20年間にわたって、セキュリティを不可欠なものにするようにと、開発者に強く求めてきました。しかし、脆弱なアプリケーションの製品化を防ぐことはできていません。
開発者に、別の何かを、開発ワークフローに追加してもらう前に、まず、その「何か」の所有者として、彼らが適切であるかどうかを冷静に考えましょう。
「コードセキュリティの実践は、管理者が上から押し付ける必要があるようです」と、あるシステム管理者は語ります。「私たちが行える最善の方法は、現場でのベストプラクティスに従って、リスクを最小化することです」。たとえば、安全でないコードを切り離したり、ファイアウォールを構成したりします。
「彼らに選択させてはなりません」。情報セキュリティの専門家であるJeffは、そうアドバイスします。「従うべきプロセスを、詳しく説明しましょう」。また、開発者がセキュリティについてすべてを理解しているとは考えないでください。それを担うのは、企業のセキュリティチームです。セキュリティチームは、ソフトウェアセキュリティの実践を求める任務を負い、上級経営者の支援を必要とします。「セキュリティチームを誰も支援しなければ、そのチームは、不足を補いながら前進することになります」とJeffは語ります。
複数のセキュリティの専門家が、最新技術への対応を開発者に依頼するのではなく、その分野のエキスパートを雇用することを提案しています。コンピューターサイエンティストのAlex Mueller氏は、標準化したリリースシステムを構成するようにと語ります。このシステムによって、ソフトウェアリリースの前に、セキュリティ監査と品質保証の確認を義務付けるのです。「組織でこれを行うには、明らかに専任の担当者が必要です。ソフトウェア開発者は、大抵この業務には向いていません」。
Jeffも同じ意見で、セキュリティチームは、現在の業界セキュリティ標準に基づいて、ソフトウェア開発に対して、セキュリティへの適切な考察を求める必要があると語ります。また、タスクに適した標準を選択できるように、開発者を導かなければなりません。
全力を尽くして開発者がおびえるような状況を作るという手もあります。あるソフトウェア設計者は、ニュースになったデータ侵害をプログラマに伝えることを勧めています。また、「データ侵害が発生した会社の名前が履歴書にあると、出世に響きますよ」と念押しするようにとも語ります。控えめに言う必要はありません。「私は普段、そうした内容を会社のSlackに投稿して、こうコメントしています。「汚点が付くのは最悪ですが、そうなるのは、安全なコードを書かない人だけです」」。

 

アクセシビリティへの認識を高める

アプリケーションの機能には、設計に最初から含める必要のないものもあります。たとえば、ユーザーエクスペリエンスとアクセシビリティの機能の最適化がそれに当たります。
ここでも、プロセスと教育の組み合わせを利用します。最初のステップとして「展開の妨げを自動的にチェックする機能を実装します」とUIの専門家、Connieは語ります。2番目のステップでは、頻繁に有益な情報を交換することで、認識を高めるとともに、草の根的に実装を進めます。さらに、Connieは、こうした話題が管理者に評価されることを示すようにするとよい、とも述べています。
「開発者は、ソフトウェアに対して、エンドユーザーとは異なる関連性を持ちます」とMishaは語ります。「たとえば、ほとんどの人にとって、ソフトウェアは目的を達成するための手段ですが、開発者にとっては、それ自体が最終目的です。ですから、それを理解して、そうした考えを変えさせようとするのは止めましょう」。
代わりに、Mishaは「言葉で説明せずに伝える」アプローチを採ることを勧めます。「ユーザー調査の考察が非常に役に立つことが分かりました。調査には、チームの誰もが驚くような内容も含まれています。また、製品について議論するときには、調査から学んだことに常に立ち返るようにします。次のプロジェクトでは、開発者に、ユーザーを中心に据えた仮説とタスクフローを設定することに最初から専念してもらいます」。
他にも、実際の行動を観察するという方法があります。あるシステム管理者は、カスタマーサポート担当者のそばでプロセスを1時間観察することを提案しています。
そうすることで、アプリケーション要件の項目に対する意識以上に、開発者の意識を高められます。「ソフトウェアエンジニアになりたての頃、私は、ユーザーエクスペリエンスに熱心に取り組もうとはしませんでした。そうした態度を改めるきっかけになったのは、どのように動作するのかを私からそこで聞くことなく、私のソフトウェアを使おうとしている人たちを見たことです」と、チームリーダーのAncaは語ります。「開発者を招待してユーザーテストを観察してもらえますよね。私は、知ったかぶりの傲慢な若者だったときでさえ、自分の仕事に人々が不満を抱いていることを知るのが非常にショックでした」。
突き詰めると、あなたが望むことを開発者に実現させる最善の方法は、それが、開発者と彼らの仕事にとってプラスになると納得してもらうことなのです。

 

開発者に耳を傾けてもらう方法: リーダーへのアドバイス

• 経営者の命令を動機付けにします。上司に「ノー」と言うのは誰にとっても簡単ではありません。
  
  
• それが重要な場合、テストスイートに組み入れるようにします。テストに合格しなければ、ソフトウェアはリリースできません。
  
  
• 「新たな機能」を追加すれば、自尊心であれ、キャリア形成への制約を避けるためであれ、メリットを個人的に享受できることを開発者に納得してもらいましょう。
  
  
• レビュープロセスで、専門家にタスクを割り当てる必要があるかどうかを検討します。彼らは、特定分野の高度な専門技術を開発する立場にあります。